Ask HN: Anyone struggling to get value out of coding LLMs?
- solving tasks that just require applying knowledge ("here's a paste of my python import structure. I don't write Python often and I'm aware I'm doing something wrong here because I get this error, tell me the proper way organise the package").
- writing self-contained throwaway pieces of code ("here's a paste of my DESCRIBE TABLE output, write an SQL query to show the median [...]").
- as a debugging partner ("I can SSH to this host directly, but Ansible fails to connect with this error, what could be causing this difference").
All these use cases work great, I save a lot of time. But with the core work of writing the code that I work on, I've almost never had any success. I've tried:
- Cursor (can't remember which model, the default)
- Google's Jules
- OpenAI Codex with o4
I found in all cases that the underlying capability is clearly there (the model can understand and write code) but the end-to-end value is not at all. It could write code that _worked_, but trying to get it to generate code that I am willing to maintain and "put my name on" took longer than writing the code would have.
I had to micromanage them infinitely ("be sure to rerun the formatter, make sure all tests pass" and "please follow the coding style of the repository". "You've added irrelevant comments remove those". "You've refactored most of the file but forgot a single function"). It would take many many iterations on trivial issues, and because these iterations are slow that just meant I had to context switch a lot, which is also exhausting.
Basically it was like having an intern who has successfully learned the core skill of programming but is not really capable of good collaboration and needs to be babysat all the time.
I asked friends who are enthusiastic vibe coders and they basically said "your standards are too high".
Is the model for success here that you just say "I don't care about code quality because I don't have to maintain it because I will use LLMs for that too?" Am I just not using the tools correctly?
292 comments
[ 0.75 ms ] story [ 243 ms ] threadBut then resources became cheap and it stoped matter. Yeah, the tight well designed machine code is still some sort of art expression but for practical purpose it makes sense to write a program in higher level language and waste a few MB...
But you trust a C compiler, or a Python intepreter, to do their job in a deterministic way. You will never be able to trust Copilot telling you that "this should be the code you are using".
It may suggest you using AWS, or Google, or Microsoft, or Tencent infrastructure. An LLM can even push you a specific style, or political agenda, without even you realizing it.
I hate polarized discussion all-or-nothing thinking about LLMs. See how perfectly and reliably they can translate text in whatever language. See them fail at aligning a table with a monospace font.
An llm project that can be generated from scratch every time is maybe understandable if you use very good prompts and a lot of grounding text. It is not deterministic unless you use zero temperature and stick with the same model forever. Something that's impossible now. Six months ago the state of the art model was deepseek r1.
It finally clicked for me when I tried Gemini and ChatGPT side by side. I found that my style of working is more iterative than starting with a fully formed plan. Gemini did well on oneshots, but my lack of experience made the output messy. This made it clear to me that the more chatty ChatGPT was working for me since it seems to incorporate new stuff better. Great for those "Oh, crap I didn't think of that" moments that come up for inexperienced devs like me.
With ChatGPT I use a modular approach. I first plan a high level concept with 03, then we consider best practices for each. After that I get best results with 4o and Canvas since that model doesn't seem to overthink and change direction as much. Granted, my creations are not pushing up against the limits of human knowledge, but I consistently get clean maintainable results this way.
Recently I made a browser extension to show me local times when I hover over text on a website that shows an international time. It uses regex to find the text, and I would never have been able to crank this out myself without spending considerable time learning it.
This weekend I made a Linux app to help rice a spare monitor so it shows scrolling cheat sheets to help me memorize stuff. This turned out so well, that I might put it up on GitHub.
For dilettantes like me this opens up a whole new world of fun and possibilities.
Fast food, assembly line, factory may be examples, but there is a HUGE catch: When a machine with a good setup makes your burger, car or wristwatch, you can be sure that at 99.99% it is as specified. You trust the machine.
With LLMs, you have to verify each single step, and if you don't, it simply doesn't work. You cannot trust them to work autonomously 24/7.
That's why you ain't losing your job, yet.
As you say, it's great for automating away boring things; as a more complicated search & replace, for instance. Or, "Implement methods so that it satisfies this interface", where the methods are pretty obvious. Or even "Fill out stub CRUD operations for this set of resources in the API".
I've recently started asking Claude Opus 4 to review my patches when I'm done, and it's occasionally caught errors, and sometimes has been good at prompting me to do something I know I really should be doing.
But once you get past a certain complexity level -- which isn't really that far - it just stops being useful.
For one thing, the changes which need to be made often span multiple files, each of which is fairly large; so I try to think carefully about which files would need to be touched to make a change; after which point I find I have an idea what needs to be changed anyway.
That said, using the AI like a "rubber duck" programmer isn't necessarily bad. Basically, I ask it to make a change; if it makes it and it's good, great! If it's a bit random, I just take over and do it myself. I've only wasted the time of reviewing the LLM's very first change, as nearly everything else I'd've had to do if I wrote the patch myself from scratch anyway.
Furthermore, I often find it much easier to take a framework that's mostly in the right direction and modify it the way that I want, than to code up everything from scratch. So if I say, "Implement this", and then end up modifying nearly everything, it still seems like less effort than starting from scratch myself.
The key thing is that I don't work hard at trying to make the LLM do something it's clearly having trouble with. Sometimes the specification was unclear and it made a reasonable assumption; but if I tell it to do something and it's still having trouble, I just finish the task myself.
That’s immensely valuable and pretty game changing
> Am I just not using the tools correctly?
No, there is no secret sauce and no secret prompting. If LLMs were capable, we'll see lots of new software generated by it given how fast LLMs are at writing code. Theoretically, assuming a conservative 10token/s speed and a 100M token for Chromium code base, you could write a new browser with LLMs in only 115 days.
> How I program with LLMs
— https://news.ycombinator.com/item?id=42617645
Those who can’t stop raving about how much of a superpower LLMs are for coding, how it’s made them 100x more productive, and is unlocking things they could’ve never done before.
And those who, like you, find it to be an extremely finicky process that requires extreme amount of coddling to get average results at best.
The only thing I don’t understand is why people from the former group aren’t all utterly dominating the market and obliterating their competitors with their revolutionary products and blazing fast iteration speed.
Most people don't work on anything technically hard, most problems are business logic issues that aren't solved technically or legacy code workarounds for which you need to put 3-10 domain experts in a room for a few hours to solve.
I think it's helpful to think of engineering as a _process_ instead of a role, and the reality is that a lot of development work doesn't necessarily rely on the strong engineering methodology (e.g. measurement, material properties, tolerances, modelling, etc.) that the people developing the software might imagine just based on the number of job adverts for 'engineers'.
This isn't a bad thing. There are hundreds or thousands of different but equally valid solutions to getting a program to do a thing, but not recognising that most code writing is somewhere between a art and engineering and is neither a purely artistic discipline but also rarely a purely engineering one is useful.
The kinds of engineering and architecture that people think of in software development only really represent common practices and shared language (e.g. design patterns, architectural patterns) and not a strong engineering practice or any kind of truth about how software actually runs.
(Unless you're writing software for launching rockets, in which case the engineering _process_ porbably should be strong).
It's probably true that a lot of development work doesn't rely on those. It's probably also true that the work other kinds of engineers do also don't.
That said, when engineering software systems, those are very important. Measurement: resource sizing, observability; tolerances: backoffs, back pressure, queues, topics, buffers; modelling: types, syntax, data analytics...
There's a whole class of developers out there that are not aware or very good at those. And that's fine. There's a place for them in the market. You don't need an engineer to work on your floor joists or your plumbing. Sure you can have one, but you can also hire a builder or DIY it all yourself.
All of theses middling developers who are so excited about these tools don't seem to realize that they are perfectly primed to eventually eliminate precisely the kind of worker responsible for hooking up existing APIs for solved problems into a web app, the kind of work the market hitherto greatly over esteemed and overpaid for isn't my going to be so esteemed or highly valued anymore. The only real work that will remain is actual hard engineering work (solving novel technical modeling problems, not just plugging apis together). All of these lazy devs are hyped for precisely the automation that's goin. to significantly reduce their pay and labor prospects in the long term lol. I'm shocked at times at how people can fail to see the writing on the wall when it's been written in gargantuan red ink
Cursor autocompletes a lot of stuff I would have typed anyway, and LLM search is a strong complement to Google, though not a direct replacement. Generating more than a few lines usually gives me bad code, but often suggests libraries I didn't know about, especially outside my area of expertise.
There's just not a lot of people talking about middling results because the extremes tend to eat up the conversation.
2x may not sound like much compared to what you read in the media, but if a few years ago you had told companies that you can provably make their engineers even 2x more productive on average you'd probably be swimming in billions of dollars now. That kind of productivity increase is absolutely huge.
then company decide to hire less, the market flooded with junior AI powered skill, mid level programmer cant asking rise as easy anymore unless you are senior dealing with really specific stuff that need know how
I understand how to use LLMs, it's just a much worse workflow. Writing code isn't the hard part, reviewing code is much slower and painful process than writing it from scratch, when you actually know what you're doing.
I'm absolutely convinced that people who are saying LLMs are making them more productive either weren't very productive to begin with or they don't know what they're doing enough to realize what a bad job the LLM is doing
LLM are useful to me personally as a learning tool. It’s valuable to have it talk through something or explain why something is designed a certain way. So it’s definitely helped me grow as an engineer. But I have not come close to being 2x as productive, I don’t think my workload would be done by 2 people in the pre-LLM era. Maybe 1.25?
Because for the most part being a computer programmer is not about programming the computer but about… everything else.
Overall, LLM are a net negative for humanity in my opinion. The amount of slop on the internet now is absurd. I can never be sure if I’m reading the writing of a real person or a machine, which makes me feel like I’m slowly becoming brain poisoned by the devil himself on a psychological level. I have to think twice when I read any email longer than 2 paragraphs, or did my coworker start using more em dashes?
And also if it’s so damn easy for a machine to do all of this complex valuable work for a few kilojoules how complex or valuable is it anyway? Maybe it’s all just a fiction, that any of this stuff provides any value to anyone. Is another app really actually necessary? What about a hundred million new apps?! Even if we all became 100x as “productive,” what would that actually mean, in the real world you know the one that’s outside that has smells and textures and objects and people in it talking to one another face to face with their wet vocal chords??
These things are going to drive us all absolutely insane I can guarantee it. The logical end of this is complete madness.
How do you account for the latter? It's nearly impossible and I have seen no improvement in that realm. As the good suggestions have become better, the ratio of good to bad hasn't really changed for me.
People are building sophisticated products in days not months now. If you can't see that, it's your issue.
Edit: This says a quarter, where did you get the 30% figure from?
https://techcrunch.com/2025/03/06/a-quarter-of-startups-in-y...
> shouldn't almost all of them be built by LLM if LLM is that much better
a) not every yc company is a software company
b) these things take time, and not everyone knows how to use these tools
this stuff should be pretty self evident.
Learn some real skills or prepare to not have a job.
What real skill do you have exactly
A few years I did it with something similar to Math Academy (from the Universiteit of Amsterdam). ChatGPT wasn't intelligent enough back then so I didn't use it. It felt a lot tougher.
ChatGPT answers questions that a teacher would find obscure nonsense, but I'm the type of student that needs to know the culture behind math so I can empathize with the people doing it and can think of solutions via that way. Like why is the letter m used when talked about an angle? Mathematically, it shouldn't matter. But it irritates me as I'd use a instead, it makes more sense as you want to lower the cognitive burden and focus as much on the math as possible. So I ask ChatGPT and one of the things it said is that historically it meant "measure". Now, I get it and can focus on the actual math again.
Another example is the fast variance calculation: average_of_squares - square_of_the_average
how does that come from (1/n) * sum((x - mean)^2) ?
It just shows it.
World domination? Nope, but I'm learning something I otherwise wouldn't. But as you can tell, YouTube and Math Academy play their own roll in it.
This is a great example of why using LLMs to learn is perilous. This is nonsense.
This is what it wrote by the way.
I posted an image and asked:
Why is this m
m for angle mangle?
ChatGPT:
In geometry we often need to distinguish the angle itself (a geometric object) from the numerical size of that angle (a real-number measurement, usually in degrees or radians). To keep the two ideas separate we put a little “m” in front of the angle symbol:
m∠B reads as “the measure of angle B.”
* ∠B refers to the actual wedge-shaped region determined by the two rays that meet at vertex .
* m∠B is the single number—e.g. \90∘—that tells you how “wide” that wedge is.
So in the worked example the author writes
m∠A + m∠B + m∠C + m∠D = 360∘
because they are adding the sizes of the four interior angles of a quadrilateral, not the angles themselves.
If you dropped the m you’d be adding geometric objects, which doesn’t make sense; the m reminds the reader that what’s being added are real-number measures. (Some textbooks use ∣∠B∣ or simply write the letter with a bar over it, but “m∠” is by far the most common in U.S. and many international curricula.)
So the mysterious “m” isn’t another variable—just a shorthand for “measure of.”
---
Edit: this took quite some work to write well as ChatGPT answers don't copy/paste neatly into HN. So I won't be doing this for the other example.
It isn't customarily used for angles (those get Greek letters).
The m stands for mystery.
Edit: ah, but I see that this prefixed m for "measure" is also used sometimes. It appears at https://en.wikipedia.org/wiki/Angle#Combining_angle_pairs though I'm not sure why it's necessary. Maybe because you want to clarify absolute magnitude is meant, to avoid adding negative values.
It is really hard to follow you if you don't explain yourself.
I'm not saying it's factual. The reason I showed that answer was simply to verify to see if it was what you thought it was (hence I asked "is it?"). It turns out that it wasn't fully.
∠ is traditionally a function from points to axiomatic geometric objects. ∠ABC is the angle at B oriented so that we start at A, go to B, then to C.
Your text seems to be using ∠ either as a kind of type annotation (indicating by ∠B that B is an angle) or (perhaps more likely) is just suppressing the other letters in the triangle and is short for something like ∠ABC.
Since ∠B is an axiomatic Euclidean object, it has no particular relation to the real numbers. m is an operator or function that maps axiomatic angles to real numbers in such a way that the calculations with real numbers provide a model for the Euclidean geometry. Why call it m? I'm not aware of it being historical, but almost certainly it comes from measure, like the μ in measure theory.
Obviously ∠ is a graphical depiction of an angle, and my guess is it probably evolved as a shorthand from the more explicit diagrams in Euclid.
Traditionally angles are named with variables from the beginning of the Greek alphabet: α, β, γ. Then we skip to θ presumably to avoid the Greek letters that look nearly identical to Roman letters.
I conflated this with another ChatGPT conversation where it gave 3 possible historical sources for another symbol that I fell over and then had trouble proceeding.
These type of answers from teachers, co-students, web communities, blogs etc. are – I would assume – why people ask LLMs in the first place.
Could you please assume a good faith discussion?
But I don't believe anyone is entitled to an explanation. I find things out by looking up books and testing things. Any explanation someone deigns to give me is a bonus and doubted until corroborated.
I don't know why anyone would think they are owed a custom explanation for their specific questions and thinking like that will get you in trouble when you come to depend on what anyone (or anything) is willing to chew up for you.
Maybe I was terse but I don't think I was rude or illogical.
I can see that you experience it as such but I think it's more of a spectrum. Often times, LLMs give good answers. Often enough times they don't. One needs to keep that in mind. In my example, given that it was just a symbol, all I needed was knowledge at the level of a memnonic which would, on average, at least somewhat also point directionally to the truth. But that's a bonus. I could make up a memnonic myself, but I like having that bonus.
Given that ChatGPT is directionally towards the truth, but not fully (on average), I'd need to test it or verify it if I want a better level of knowledge than that. If that's the case, then ChatGPT is basically acts as a sort of cache as it's quicker to ask a question to ChatGPT than to research on one's own. One can experience a cache hit or cache miss. Such a thing will happen in the verification stage. Specifically, for math this is quicker, in my experience.
But anyways that's my experience. Your experience is that it's spurious nonsense slop. And I suppose you therefore find it a problem. I don't see the issue as there are different levels of knowledge and different time commitments you need to give to them. A lot of my knowledge is based on trust anyway and sometimes it's broken (e.g. replication crisis in psychology, I felt betrayed having studied the field).
> I don't know why anyone would think they are owed a custom explanation for their specific questions
I'm not sure if anyone said anything like it. Regardless of that, the need still exists. People will still act on that need. I suspect you see that as a problem. I'm neutral on it.
> thinking like that will get you in trouble when you come to depend on what anyone (or anything) is willing to chew up for you.
IMO teaching and learning is a 2 way street. It's the teacher's job to explain it well enough. It's the student's job to do their best to understand it. Math Academy offers exercises and explanations. Sometimes I find their explanations a bit lacking. So I use other sources to augment it.
> Maybe I was terse but I don't think I was rude or illogical.
Reading/writing text is tough, which is why I stated how I felt. It'd probably have been easier in an actual conversation. I didn't mean to imply you were being rude or illogical.
Of course, some of it is a bit strange for modern audience, the way lots of things in calculus are taught nowadays is completely different. If you are looking for rigorous formal proofs, you won't find them on this book.
But it is a quite funny and quirk book that gives you a different perspective on math concepts and will satisfy your hunger for knowing the people and the historical context behind it.
This isn’t the best example, because a simple Google search gives you immediate results for that as well, and arguably more nuanced ones. You’ll learn, for example, that m is also the standard letter for slope, which may or may not be related.
Also, if a teacher finds that question “obscure nonsense”, I’d argue that they are a bad teacher.
If I want to create a React app with X amount of pages, some Redux stores, Auth, etc. then it can smash that out in minutes. I can say "now add X" and it'll do it. Generally with good results.
But when it comes to maintaining existing systems, or adding more complicated features, or needing to know business domain details, a LLM is usually not that great for me. They're still great as a code suggestion tool, finishing lines and functions. But as far as delivering whole features, they're pretty useless once you get past the easy stuff. And you'll spend as much time directing the LLM to do this kind of this as you would just writing it yourself.
What I tend to do is write stubbed out code in the design I like, then I'll get an LLM to just fill in the gaps.
These people who say LLMs make them 100x more productive probably are only working on greenfield stuff and haven't got to the hard bit yet.
Like everyone says, the first 90% is the easy bit. The last 10% is where you'll spend most of your time, and I don't see LLMs doing the hard bit that well currently.
I have yet to see an LLM-generated app not collapse under it’s own weight after enough iterations/prompts. It gets stuck in loops (removing and adding the same code/concept), it gets hung up on simple errors, etc.
For greenfield it’s amazing, no doubt, but unless you are watching it very closely and approving/reviewing the code along the way it will go off the rails. At a certain point it’s easier to add the new feature or make the modification yourself. Even if the LLM could do it, it would burn tons of money and time.
I expect things to get better, this will not always be the state of things, but for now “vibe coding” (specifically not reviewing/writing code yourself) is not sustainable.
Most people doing it have a github profile that is a mile wide and a meter deep.
LLM’s are amazing and useful, but “vibe coding” with them is not sustainable currently.
Then specify the need to conclude the work by a deadline.
These kinds of things cause the LLM to “finish” tasks and try to move on or say it is done when it is.
This won’t let you skip the curation of output along the way, but at least some of the stumbling around can be handled with prompting.
It will not.
And I say this as someone whose been building internal LLM tools since 2021.
The issue is their context window. If you increase the context window so they can see more code costs skyrocket as n^2 the size of the code base. If you don't then you have all the issues people have in this thread.
The reason why I have a job right now is that you can get around this by building tooling for intelligent search that limits the overfill of each context window. This is neither easy, fast, or cheap when done at scale. Worse the problems that you have when doing this are at best very weakly related to the problems the major AI labs are focusing on currently - I've interviewed at two of the top five AI labs and none of the people I talked to cared or really understood what a _real_ agentic system that solves coding should look like.
I'm interested to know what you mean by this, in our system we've been trying to compress the context but this is the first I've seen about filtering it down.
For source code, you are even luckier since there are a lot of deterministic tools which provide solid grounding, e.g., etags, and the languages themselves enforce a hierarchical tree-like structure on the source code, viz. block statements. The above means that ranking and chunking strategies are solved already - which is a huge pain for general text.
The vector search is then just an enrichment layer on top which brings in documentation and other soft grounding text that keeps the LLM from going berserk.
Of course, none of the commercial offerings come even close to letting you do this well. Even the dumb version of search needs to be a self-recursive agent which comes with a good set of vector embeddings and the ability to decide if it's searched enough before it starts answering your questions.
If you're interested drop a line on my profile email.
As a human, I don't need to remember the content of every file I work on to be effective, but I do need to understand how to navigate my way around, and enough of how the codebase hangs together to be able to make good decisions about where new code belongs, when and how to refactor etc.. I'm pretty sure I don't have the memory or reading comprehension to match a computer, but I do have the ability to form context maps at different scales and switch 'resolution' depending on what I'm hoping to achieve.
I'll preface this comment with: I am a recent startup owner (so only dev, which is important) and my entire codebase has been generated via Sonnet (mostly 3.7, now using 4.0). If you actually looked at the work I'm (personally) producing, I guess I'm more of a product-owner/project-manager as I'm really just overseeing the development.
> I have yet to see an LLM-generated app not collapse under it’s own weight after enough iterations/prompts.
There's a few crucial steps to make an LLM-generated app maintainable (by the LLM):
- _have a very, very strong SWE background_; ideally as a "strong" Lead Dev, _this is critical_
- your entire workflow NEEDS to be centered around LLM-development (or even model-specific):
This is off the top of my head so it's pretty broad/messy but I can expand on my points.LLM-coding requires a complete overhaul of your workflow so it is tailored specifically to an LLM, not a human, but this is also a massive learning curve (that take's a lot of time to figure out and optimize). Would I bother doing this if I were still working on a team? Probably not, I don't think it would've saved me much time in a "regular" codebase. As a single developer at a startup? This is the only way I've been able to get "other startup-y" work done while also progressing the codebase - the value of being able to do multiple things at a time, let the LLM and intermittently review the output while you get to work on other things.
The biggest tip I can give: LLMs struggle at "coding like a human" and are much better at "bad-practice" workflows (e.g. throwing away large parts of code in favour of a total rewrite) - let the LLM lead the development process, with the rules/prompts as guardrails, and try stay out of it's way while it works (instead of saying "hey X thing didn't work, go fix that now") - hold its hand but let it experiment before jumping in.
```
# Ticket Management Guidelines
This document outlines the standardized approach to ticket management in the <redacted> project. All team members should follow these guidelines when creating, updating, or completing tickets.
## Ticket Organization
Tickets are organized by status and area in the following structure:
TICKETS/ COMPLETED/ - Finished tickets BACKEND/ - Backend-related tickets FRONTEND/ - Frontend-related tickets IN_PROGRESS/ - Tickets currently being worked on BACKEND/ FRONTEND/ BACKLOG/ - Tickets planned but not yet started BACKEND/ FRONTEND/
## Ticket Status Indicators
All tickets must use consistent status indicators:
- *BACKLOG* - Planned but not yet started - *IN_PROGRESS* - Currently being implemented - *COMPLETED* - Implementation is finished - *ABANDONED* - Work was stopped and will not continue
## Required Ticket Files
Each ticket directory must contain these files:
1. *Main Ticket File* (TICKET_.md): - Problem statement and background - Detailed analysis - Implementation plan - Acceptance criteria
2. *Implementation Plan* (IMPLEMENTATION_PLAN.md): - Detailed breakdown of tasks - Timeline estimates - Success metrics
3. *Implementation Progress* (IMPLEMENTATION_PROGRESS.md): - Status updates - Issues encountered - Decisions made
4. *Design Documentation* (DESIGN_RECOMMENDATIONS.md), when relevant: - Architecture recommendations - Code patterns and examples - Error handling strategies
5. *API Documentation* (API_DOCUMENTATION.md), when applicable: - Interface definitions - Usage examples - Configuration options
## Ticket Workflow Rules
### Creating Tickets
1. Create tickets in the appropriate BACKLOG directory 2. Use standard templates from .templates/ticket_template.md 3. Set status to *Status: BACKLOG* 4. Update the TICKET_INDEX.md file
### Updating Tickets
1. Move tickets to the appropriate status directory when status changes 2. Update the status indicator in the main ticket file 3. Update the "Last Updated" date when making significant changes 4. Document progress in IMPLEMENTATION_PROGRESS.md 5. Check off completed tasks in IMPLEMENTATION_PLAN.md
### Completing Tickets
1. Ensure all acceptance criteria are met 2. Move the ticket to the COMPLETED directory 3. Set status to *Status: COMPLETED* 4. Update the TICKET_INDEX.md file 5. Create a completion summary in the main ticket file
### Abandoning Tickets
1. Document reasons for abandonment 2. Move to COMPLETED/ABANDONED directory 3. Set status to *Status: ABANDONED* 4. Update the TICKET_INDEX.md file
## Ticket Linking
When referencing other tickets, use relative links with appropriate paths:
markdown @TICKET_NAME
Ensure all links are updated when tickets change status.
## Ticket Cleanup and Streamlining
### When to Streamline Tickets
Tickets should be streamlined and cleaned up at major transition points to maintain focus on remaining work:
1. *Major Phase Transitions* - When moving between phases (e.g., from implementation to testing) 2. *Milestone Achievements* - After completing significant portions of work (e.g., 80%+ complete) 3. *Infrastructure Readiness* - When moving from setup/building to operational phases 4. *Team Handoffs* - When different team members will be taking over the work
### What to Streamline
*Replace Historical Implementation Details With:* - Brief completed tasks checklist ( high-level achievements) - Current status summary - Forward-focused remaining work
*Remove or Simplify:* - Detailed session-by-session progress logs - Extensive implementation decision histories - Verbose research findings documentation - H...
Not discounting your experience, but a lot of these examples are about frameworks that never had good bootstrapping, such as Rails does/did. LLMs are really good at boilerplate, but maybe this points to these such stacks needing too much fiddling to get going, vs 10x coder AI.
LLM makes that a bit easier and faster to do, but is also a bit more error prone than a template project.
1. You have to remember all the technologies you need included, my company template already has them.
2. LLM doesn’t have a standardized directory structure, so you end up with different projects having different structures and file naming conventions. This makes later refactoring or upgrades across multiple projects less automatable (sometimes this can be solved by having an LLM do those, but they often are unsuccessful in some projects still)
3. LLMs have a knowledge cutoff. If your company has already moved to a version after that knowledge cutoff, you need to upgrade the LLM generated code.
I very much prefer having a company template to asking an LLM to generate the initial project.
Not 100x more productive, that's an exaggeration... not even 10x. But it helps. It is an extremely competent rubber duck [1].
[1] https://en.wikipedia.org/wiki/Rubber_duck_debugging
I just rewrote 300ish advanced PostgreSQL queries to mysql queries. The process is not magical, but it will take me 1 week rather than 3 days. Now I'm on testing phase, seems promising.
The point is if we can find a work to work along with the agent, can be very productive.
Translation from one set of tokens to another is exactly the primary use case of LLMs. This is exactly what it should be good at. Developing new queries, much less so. Translation from one set of database queries to another was already very well defined and well covered before LLMs came about.
It can do pieces in isolation, but requires significant handholding on refactors to get things correct (ie, it’s initial version has subtle bugs) — and sometimes requires me to read the docs to find the right function because it hallucinates things from other frameworks will work in its code.
Greenfield != boilerplate and basic CRUD app.
I'm a consultant writing greenfield apps solo, and 90% of my time is spent away from my editor thinking, planning, designing, meeting with stakeholders. I see no benefit in using a low-IQ autocomplete tool to automate a small part of the remaining 10% of the job, the easiest and most enjoyable part in fact.
Personally I find most of coding I do is unsuitable for LLMs anyway, because I don't need them to regurgitate standard logic when libraries are available, so most of that 10% is writing business logic tailored for the program/client.
Call me elitist (I don't care) but LLMs are mostly useful to two kinds of people: inexperienced developers, and those that think that hard problems are solved with more code. After almost two decades writing software, I find I need fewer and fewer code to ship a new project, most of my worth is thinking hard away from a keyboard. I really don't see the use of a machine that egregiously and happily writes a ton of code. Less is more, and I appreciate programming-as-an-art rather than being a code monkey paid by the line of code I commit.
Disclaimer: I am anti-LLM by choice so my bias is opposite than most of HN.
This is where both sides are basically just accusing the other of not getting it
The AI coders are saying "These tools are a gamechanger in the hands of skilled developers" implying if you aren't getting gamechanging results you aren't skilled
The non-AI coders are basically saying the same thing back to them. "You only think this is gamechanging because you aren't skilled enough to realize how bad they are"
Personally, I've tried to use LLMs for coding quite a bit and found them really lacking
If people are finding a lot of success with them, either I'm using them wrong and other people have figured out a better way, or their standards are way, way lower than mine, or maybe they wind up spending just as long fixing the broken code as it would take me to write it
But something like o4-mini-high is a domain expert in all versions of React, Redux, RN etc. and knows every internal SDK change over the last 10 years (or goes out and reads the changelogs and code itself). Countless times I've had it port old code to new and it figures it out 100%. It formulates good modern canonical ways to solve stuff. It knows all the stupid tricks you have to do to get RN stuff run well on Android and iOS that I would never be able to keep in my head unless I work full-time on that. And it does the eye-watering boring styling code that nobody likes, you can even just upload a screenshot of another app or a sketch on paper and it will correctly output code for the style in a matter of seconds.
The end result is that I can, without investing a full-time of keeping myself current, do a professional RN dual Android/iOS app development cycle because I have the general skill to understand what to ask it and how to merge its output properly. This leaves me time to do other stuff and generally be more productive.
My guess is that many who gave up on the AI coding stuff tried the bad tools like the default chatgpt 4o-mini (or tried the tools available 2 years ago) and got a bad experience. There are light-years of differences between these and something like o4-mini-high.
TL;DR: use the correct model for the job, and it doesn't really need to be an argument - if it makes you more productive it's a good tool, if it doesn't, nobody is forcing you to use it. But I don't think you should imply that everybody who likes these tools are stupid.
What does it add that you couldn't have written yourself faster if you're so skilled?
I think this is needlessly snarky and also presupposes something that wasn't said. No one said it can write something that the developer couldn't write (faster) themselves. Tab complete and refactoring tools in your IDE/editor don't do anything you can't write on your own but it's hard to argue that they don't increase productivity.
I have only used cline for about a week, but honestly I find it useful in a (imo badly organized) codebase at work as an auto-grepper. Just asking it "Where does the check for X take place" where there's tons of inheritance and auto-constructor magic in a codebase I rarely touch, it does a pretty good job of showing me the flow of logic.
Indie hackers just did an article on 4 vibe coded Startups and they all seem like a joke.
And they could only find 4!
I didn't look at them all, but the flight sim is spectacularly bad, the revenue numbers obviously unsustainable and it looks like something moderately motivated school children might have made for a school project in a week.
The question is, are companies going to use fewer people to do the same, or the same amount of people and just create better products?
For prototyping new ideas this is also an invaluable turbocharge for startups who can't really afford to have hordes of developers trying out alternative solutions.
Unless you're a contractor making basic websites for small businesses, how many of these do you need to make? This really a small fraction of the job of most developers, except for entry-level devs.
> when it comes to maintaining existing systems, or adding more complicated features, or needing to know business domain details,
This is what experienced developers will spend 90% of their time doing.
So yes, LLMs can replace entry-level devs, but not the more experienced ones.
This begs the question: if companies stop hiring entry-level devs because LLMs can do their job, how will new devs get experience?
An LLM is very capable of implementing all of that… if only someone who knows all of that stuff tell them first.
And most importantly: LLMs don’t challenge the task given. Engineers do. Many times, problems are solved without code.
Knowing what’s possible, difficult, easy, risky, cheap, expensive, etc.
I agree with you, but I don't think it's the entry-level dev who is going to be interfacing with the client to discuss and resolve all the questions you posed, and/or decide on them. That was part of the OP's point -- that much of their time is spent interfacing with the client to very precisely determine the requirements.
It is something that future versions could fix, if the context a llm can handle grows and also if you could fix it so it could handle debugging itself. Right now it can do it for short burst and it is not bad at it, but it will get distracted quickly and do other things I did not ask for
One of these problems has a technical fix that is only limited by money; the other does not
I mean that in the sense that Excel is the tool that non developers could take the farthest to meet their needs without actually becoming a full time developer. But then to take it past that point a professional developer needs to step in.
I imagine non devs vibe coding their way to solutions far more complex than Excel can handle. But once they get past the greenfield vibe coding stage they will need a pro to maintain it, scale it, secure it, operationalize it, etc.
Michael Feathers book comes to mind when thinking about the topic. One gets the idea that you have to write a lot of tests. But what happens when there are no tests, comments, documents etc?
This seems like an interesting approach, though to me it begs the question: what does "stubbed out code" look like? How much stubbing is done? Have you considered using pseudocode as comments within a larger "stubbed out" portion?
The importance of rules and context has begun to elevate its significance (...that is, if context wasn't always very important), and finding ways to articulate that context seems to be a skill of greater importance...
1. The ones writing Medium posts about being 100x more productive. 2. The skeptics, like yourself, who construct made-up examples to prove it’s impossible to get value, framing things in a way where failure is the only plausible outcome. 3. And then there’s the middle group, people quietly getting real, uneven, but worthwhile value.
You’d be surprised. The vast majority of engineering isn’t that unique. Usefulness often depends on the age of the codebase and the dynamics of the team. I’m firmly in the middle camp: far from perfect, but I get real value from these tools as they stand today. It’s like having a junior engineer who can scaffold out the basics so I can spend my mental energy on the parts that actually matter.
Seriously, why is every comment hyping up AI generated code like this. No concrete evidence, just turtles all the way down. But when actual examples do show up, it's a complete clown show [1][2].
[1]: https://news.ycombinator.com/item?id=44050152
[2]: https://news.ycombinator.com/item?id=43907376
Your links about GitHub agents may be spot-on, I haven’t used them myself, so no strong opinion there. Same with Codex; it’s early. But why not mention tools like Cursor or Windsurf? Or the open source alternatives. That’s where people are seeing actual gains today. Why go all-in on anti-hype without talking about your direct experience?
Anyways if you want to hear my direct experience, I reviewed AI generated code. It couldn't get a simple map, reduce, and filter right. I personally wouldn't waste my coworker's time with such slop. I'm happier coding with existing tools for boilerplate generation and code completion, along with my own brain. Much more predictable and reliable.
I am very much in that category.
I would describe my experience as the old adage "why keep a dog and bark yourself".
And no, I don't buy into people who say you have to engage in "prompt engineering". That's bullshit. Let's face it "prompt engineering" is a synonym for "I have to waste time coming up with hacky workarounds to make this dumb LLM come up with something usable".
In the end, its always quicker and easier to do it myself. And unless you are fresh out of school, if you've got more than 10 minutes of coding experience, you will always do a better job than the LLM.
Every time a new LLM model comes out, I fall into the same old trap "oh well, this one must be better, surely" I say to myself.
And yet its always the same "you can't polish a turd but you can roll it in glitter" experience.
I'm sick and tired of LLMs hallucinating shit.
I'm sick and tired of LLMs inventing functions that have been available in stdlib for years.
I'm sick and tired of LLMs generating useless code with boilerplate subfunctions that just contain a single commented "implement it yourself" line.
On top of that LLMs are simply terrible for the environment, guzzling up all that electricity, producing nothing but hot air and bullshit results in return.
Basically I'm sick and tired of LLMs and all the LLM fetishists that surround them.
To be fair, I'm not sure the quality of the code is much worse than all the boatloads of crapware in all the app stores out there.
I suspect that the reason "revolutionary products" and "blazing fast iteration" isn't blowing our minds is because the problem was never the code - it was always the people around it, who know better than their customers. The best way to make good software is to test it on real people and iterate - that's going to take a long time no matter how fast the coding part is.
LLMs have only made this to 100x moderately competent programmers and may be 2xed extremely competent ones?
I think something like a graph where nodes are specified clearly with inputs and outputs (or pre- and post-conditions, if you prefer), and agents iteratively generate and refine the implementation details could have some utility, but that would require programmers to know how to think about program design (and have a usable UI/UX for such a tool) instead of hastily stumbling through patches and modifications to existing code they already don’t understand.
The new LLM systems are carrying us farther from that world, not closer to it.
I've found great success with LLMs in the research phase of coding. Last week I needed to write some domain-specific linear algebra and because of some other restrictions, I couldn't just pull in LAPACK. So I had to hand code the work (yes, I know you shouldn't hand code this kind of stuff, but it was a small slice and the domain didn't require the fully-optimized LAPACK stuff). I used an LLM to do the research part that I normally would have had to resort to a couple of math texts to fully understand. So in that case it did make me 100x more effective because it found what I needed and summarized it so that I could convert it to code really quickly.
For the fun of it, I did ask the LLM to generate the code for me too, and it made very subtle mistakes that wouldn't have been obvious unless you were already an expert in the field. I could see how a junior engineer would have been impressed by it and probably just check it in and go on.
I'm still a firm believer in understanding every bit of code you check in, so even if LLMs get really good, the "code writing" part of my work probably won't ever get faster. But for figuring out what code to write - I think LLMs will make people much faster. The research and summarize part is amazing.
The real value in the world is synthesis and novel ideas. And maybe I'm a luddite, but I still think that takes human creativity. LLMs will be a critical support structure, but I'm not sold on them actually writing high-value code.
If you’re near that ceiling you get most value out of code reviews and those side features you don’t care about that allow you to focus more on the actual problem.
That’s a 10-20% lift instead of 10/100x.
This is what I've found it most helpful for. Typically I want an example specific to my scenario and use an LLM to generate the scenario that I ask questions about. It helps me go from understanding a process at a high level, to learning more about what components are involved at a lower level which let's me then go do more research on those components elsewhere.
Apparently there are at least three as I fit neither of these molds of yours. They are neither making me 100x more productive, nor am I putting in an extreme amount of coddling.
For context, in the 30ish years I've been writing code professionally, I've *always* needed to look stuff up constantly. I know what I want, and I know what's possible. I just can never remember things like syntax, specifics, that sort of thing. It doesn't help that I often wind up in jobs where I'm switching between languages often.
Before quality search engines like Google, this meant I was always flipping through reference books, man pages, and worse. Then came search engines and that was a step more productive. Then came things like SO, and that was a step more productive. I find LLMs to be another step forward, but not like a quantum leap or anything. Take autocomplete suggestions for instance: Sometimes it's exactly the prompt (pardon the pun) that I need to jog my memory. Other times I know it's not what i want and I ignore it. And the chat interfaces I find better than Googling SO as I can have a back & forth with it.
I have gone from Senior II, to Lead Architect, to Principal Engineer in the years LLMs have been available.
It's not literally a 100x multiplier, but I have leveraged their ability to both fill in details where I lack specific knowledge, and as a first point of contact when researching a new space.
LLMs have enabled me to widen my sphere of influence by deepening my abilities at every point of my T-shaped knowledge curve.
My game dev is going to be a hybrid approach going forward. I’ll ask it to create a new project with the desired functionality and see how the solution was proposed and then incorporate that into my main code branch.
I find this easier than the Cursor roll back or being overly cautious with suggested edits. I’m just getting to this realization so tbd if it works well. FYI, I’m good at programming generally but game dev is my Achilles. We’ll see how it it goes.
And realistically, there is also the question of where this claim is coming from. Someone being 100 times faster with AI is probably not starting from a place of high competence. Of the 100x, 90x are probably just for filling the gap to peak devs. So at the end they would be probably as productive as a highly competent dev of some domain, just that they can more easily access any domain without years of experience in that domain. And if we are honest, we somewhat have that already without AI, just by people copying and cookie cutting any sh*t
The result you described is coming soon. CheepCode[0] agents already produce working code in a satisfying percentage of cases, and I am at most 3 months away from it producing end-to-end apps and complex changes that are at least human-quality. It would take way less if I got funded to work on it full time.
Given that I'm this close as a solo founder with no employees, you can imagine what's cooking inside large companies.
[0] My product, cloud-based headless coding agents that connect directly to Linear, accept tickets, and submit GitHub PRs
This is a strong claim. I'm not aware of any AI model or system that can consistently and correctly make complex changes in existing codebases. What makes you so confident that you can achieve this, alone, in the next 3 months?
I'm finding that these tools are supporting an ever expanding portion of my work, while remaining frustrating frequently.
I think it'll calm down a bit. People are just making huge claims right now which is music to the ears of many.
I like the tools don't get me wrong, but they aren't going to make a huge difference day to day. The area they will make a huge difference is in helping people work out issues faster. You know those multi-hour or multi-day issues you run into where you go crazy reading and re-reading the code. The LLMs are good at giving you a fresh look at the code that you'd otherwise need to get more people to help with or go sleep on it for a day.
This time savings here is probably the most significant time savings AI code editors or agents will ever provide.
Everything AI generated today is hot garbage but hey, just wait 2 years and the road to eldorado will show itself.
pfft.
I find that so far their quality is horizontal, not vertical.
A project that involves small depth across 5 languages/silos? Extremely useful.
A long project in a single language? Nearly useless.
I feel like its token memory. And I also feel like the solution will be deeper code modularisation.
What LLMs are good at and their main value I'd argue, is nudging you along and removing the need to implement things that "just take time".
Like some days back I needed to construct a string with some information for a log entry, and the LLM that we have suggested a solution that was both elegant and provided a nicer formatted string than what I had in mind. Instead of spending 10-15 minutes on it, I spent 30 seconds and got something that was nicer than what I would have done.
It's these little things that add up and create value, in my opinion.
I was still learning Java at uni (while being a Python/Lisp fanboy) when I realised this:
- Complex and wordy languages need tooling (like autocomplete, autoformatting) to handle the tedious parts.
- Simple and expressive languages can get away with coding in notepad.exe.
- Lisp, as simple and powerful as it is, needs brace highlighting. You. Simply. Just. Can't.
Now 10, 20 years later you can look back at the evolution of many of these languages; some trends I've observed:
- Java, C#, C++, have all borrowed a lot from functional languages.
- JVM has Clojure.
- Go stubbornly insists on "if err != nil" - which isn't even the worst part; the following fmt.Errorf is.
- Rust (post-1.0) cautiously moved towards "?"; Zig (still pre-1.0) also has specific syntax for errors.
- Python is slowly getting more verbose, mostly because of type annotations.
- Autoformatters are actually great, you don't even have to care about indenting code as you spit it out, but... Python, being whitespace-sensitive, makes them a bit less useful.
Good tooling helps you with wordy languages. Expressive languages help you write concise code. Code is read much more often than it's written. Deterministic tooling can work with the structure of the code, but LMs (being probabilistic) can help you work with its intent. Language models are an evolution of automated tooling - they will get better, just like autocomplete got better; but they will never "solve" coding.
In my opinion, there's no truth here, only opinions.
I tried to use many LLM tools. They are generally not capable of doing anything useful in a real project.
Maybe solutions like MCP, that allow the LLM to access the git history make the LLM become useful for someone that actually works on a project.
> I cannot see the Create Project button as user project-admin@domain.com. Please use Supabase MCP to see if I have the correct permissions, if so, are we handling it correctly in the UI?
I reflected once that very little of my time as a senior engineer is actually spent just banging out code. The actual writing of the code is never the hard part or time-consuming part for me - it's figuring out the right architecture, figuring out how to properly refactor someone else's hairball, finding performance issues, debugging rare bugs, etc. Yes, LLMs accelerate the process of writing the boilerplate, but unless you're building brand new products from scratch every 2nd week, how much boilerplate are you really writing? If the answer is "a lot", you might consider how to solve that problem without relying on LLMs!
The limits of what can be automated have been clear for almost a century now. Yet people insist in selling ways to automate your way out of social, political, economical problems. Come to think about it, people should also read Comways's paper as well.
https://www.melconway.com/Home/pdf/committees.pdf
LLMs are better at reading terrible documentation than the average programmer. So in that sense, "obscure text reading and explain it better" there seems to be a clear value add.
> If the answer is "a lot", you might consider how to solve that problem without relying on LLMs!
Aren't there languages with a lot of boilerplate though?
LLMs don't go and read the terrible documentation for you when prompted. They reproduce the information posted by other people that struggled with said terrible documentation, if it was posted somewhere.
It's still better than a modern web search or struggling with the terrible documentation on your own - for introductory stuff.
For going into production you have to review the output, and reading code has always been harder than writing it...
What matters: - the model -> choose the SOTA (currently Claude 4 Opus). I use it mostly in Cursor. - the prompt: give it enough context to go by, reference files (especially the ones where it can start delving deeper from), be very clear in your intentions. Do bullet points.
- for a complex problem: ask it to break down its plan for you first. Then have a look to make sure it’s ok. If you need to change anything in your plan, now’s the time. Only then ask it to build the code.
- be patient: SOTA models currently aren’t very fast
I work at a company with millions of MAU, as well as do side projects - for the company, I do spend a bit more time checking and cleaning code, but lately with the new models less and less.
For my side projects, I just bang through with the flow above.
Good luck!
I have collected similar requests over time and I don't have to remind GH copilot/Claude as much anymore.
https://newsroom.ibm.com/2025-05-06-ibm-study-ceos-double-do...
What works for me is collecting it manually and going one implementation chunk at a time. If it fails, I either do it myself or break it down into smaller chunks. As models got better these chunks got larger and larger.
Collecting context manually forces me to really consider what information is necessary to solve the problem, and it's much easier to then jump in to fix issues or break it down compared to sending it off blind. It also makes it a lot faster, since I shortcircuit the context collection step and it's easier to course-correct it.
Collecting manually is about 10 seconds of work as I have an extension that copies all files I have opened to the clipboard.
As the project becomes non-trivial (>1000 lines), they get increasingly likely to get confused. They can still seem helpful, but they may be confidently incorrect. This makes checking their outputs harder. Eventually silly bugs slip through, cost me more time than all of the time LLMs saved previously.
Most of the time, the output isn't perfect, but it's good enough to keep moving forward. And since I’ve already written most of the code, Jules tends to follow my style. The final result isn’t just 100%, it’s more like 120%. Because of those little refactors and improvements I’d probably be too lazy to do if I were writing everything myself.
1. Use a high quality model with big context windows via API (I recommend Openrouter). E.g. Google Gemini 2.5 Pro is one of the best which keeps constant good quality (OpenAI reasoning models can be better in problem solving but it's kinda a mixed bag). Other people swear by the Claude Sonnet models.
2. Upgrade your code tools you combine with this high quality models. Google Jules and OpenAI Codex are so brand new and have a totally different aim than Cursor. Don't use them (yet). Maybe they will get good enough in future. I would focus on established tools like aider (steepest learning curve), roo code (easier) to be paired with Openrouter and if you want to have it really easy claude code (only useful with a 100-200 USD Anthropic subscription IMHO). On average you will get better results with Aider, roo, claude code than with Cursor or Windsurf.
Btw. I think Cursor and Windsurf are great as a starter because you buy a subscription with 15-20 USD and are set. It can be most likely that the more high quality tools burn more tokens and you spent more per month but you also get better quality back in return.
Last but not least and can be applied to every coding assistant: Improve your coding prompts (be more specific in regards to files or sources), do smaller and more iterations until reaching your final result.
Op said literally "Am I just not using the tools correctly?" and I said for the 2 of 3 tools OP tried are so new and experimental I would put them away (for now).
And I use a wide range of model/versions.I mostly use Claude, from 3.5 to the newest 4.0. I also use Gemini and with Copilot.
Roo code is smarter with this problem, Claude Code is also pretty smart with it and in aider the problem does not exist if you as a human understand the project structure and tell aider the important context files to send to the AI.
The usual word is "drivel" rather than "dribble".
When I start to stray into even moderately complex work, LLMs become pretty useless quick. Tell me your setup, and I will give a quick sample task that it will fail at. Stop the fanboyism please
I said people are saying the models are PhD level intelligent not that you need to be. I get a ton of value from them and I don't have a PhD.
Well, that's the point. As long as they are using a recent-ish model it really doesn't matter. Not that there are no differences in performances between models, it's that there is no model today that even comes close not requiring extensive hand-holding to accomplish real-world software engineering of even slightly moderate complexity.
Case in point: I have been frustrated that most markdown viewers don't do automatic indentation of section levels. I thought, this is a perfect test of coding assistants: the problem and solution is straightforward conceptually, and I don't even care about the platform and architecture used to accomplish it.
I've asked all the major models to implement a simple markdown viewer that could do automatic indentation, and they all fall flat. Some even give me code that will not run; of the rest, none has provided code that basically does the thing I've asked for.
The LLMs advance and so does the quality. What e.g. OpenAIs o3 can do is so much better than what GPT 3.5 can do.
I'm convinced every developer who does not stay up to date with AI coding tools and know how to use them will become obsolete sooner or later.
I don't suppose there's any solution where you can somehow further train a LLM on your code base to make it become part of the neural net and not part of the prompt?
This could be useful on a large ish code base for helping with onboarding at the least.
Of course you'd have to do both the running and training locally, so there's no incentive for the LLM peddlers to offer that...
On a large code base it would probably work better if you didn't need to put it all in the context... if you even could...
So it doesn't only suggest what can be found on w3schools and geeks4geeks and maybe stackoverflow, but also whatever idioms and utility functions my code base has.
Now with webui what's important is to constantly add tests around the code base, also if it gets stuck, go through the logs and understand why.
It's more of a management role of ,,unblocking'' the LLM if it gets stuck and working with it than fitting it to my previous workflow.
You are missing a crucial part of the process - writing rules