Re:Jonathan Blow – If AI Solved Coding, Why Is My Software S...
by hansvm on Saturday November 14, 2026 @03:47AM
(#50495285)
> why this happens?
Different tasks, different tools, different prompts, or different ability to evaluate the results, likely some combination of all of the above.
- Tools: I can't get the ChatGPT web interface, with any prompts, any models, any amount of retries, with any combination of settings, to respond to a coding task with anything other than <snippet ignoring multiple explicit requirements for what should be a 20 SLOC task> <here's how you make it actually prod-ready (often stating that it just refused to implement something I asked for)> <paternalistic essay about how I shouldn't use my vibe-coded URL parser to send a man to the moon>. The underlying models are a fair bit better. Fully controlling the system prompt helps a lot. Agentic flows paper over a lot of those deficiencies. Anthropic models (and web interfaces) work a lot better for codegen for me out of the box. Agentic flows make that delineation much sharper.
- Tasks: I don't like the concurrent data structures LLMs write. Its opinions about the novel pseudo-probabilistic algorithms I care about are wrong. The level of hand-holding I need to get proper matrix codegen is insane. It works extremely poorly when operating at a meta-type level and trying to design a cohesive API. But, if you're not doing those things, who cares? I vibe-slopped a new programming language yesterday just to try it out with a new harness I previously vibe-slopped. At this stage, it doesn't have to be correct. If I get it kind of working just a little and think the results look promising then I can do better later if I want. A lot of companies are in (or at least think they're in -- IME this mentality bites founders much earlier than they expect much of the time) that stage.
- Prompts: LLMs are much more sensitive than you might expect to minor variations in prompts. The classic example I hope everyone knows by now: There are precious few scenarios where your interaction with an LLM should be a very long session repeatedly telling it the mistakes it's made. Almost anything else is better, up to and including (as a bad solution but still better for codegen output than the baseline) still having a very long session but asking the agent to rewrite the previous messages as if it had succeeded and then having the person manually edit the conversation.
- Evaluation Ability: Really? You thought +3k SLOC was the best way to solve that feature? I have a whole SOTA event loop and multi-processing framework in 3k SLOC, and when interacting with most companies' codebases you really ought to be deleting code with the average feature you implement, not adding code. Like you said, the code smells are everywhere. Like, slop is fine from time to time (easily 30% of the code I write for work is slop, largely because it serves one-off tasks), but some of the people pushing it just can't tell the difference. Just a month ago, somebody (outside of $WORK) was showing off a fancy new UI feature on some geo-rich project. It had a small bug. The implementor said they knew about it. The problem is that "if you know you know," and the only reasonable way the code for that kind of feature should have that kind of bug is if it has major problems which just aren't surfacing much in this particular demo. I suggested a couple alternative test cases to optimize toward, and a week and a couple rewrites later it was in a much better place. There were tens of thousands of tests before I made that suggestion, dozens of times the LLM confirmed the system was working as intended, and on and on and on. None of that matters if you need to build something that works and know that it works. The tests were all shit, as were the false assurances.
If you're looking to make it better, there are some tweaks you can make to your CLAUDE.md or what have you to help a bit. I have a lot that I do to make mine generate passable code without requiring constant human intervention, but something it responds well to is (1) pinning down what you care about re abstractions, and (2) giving it explicit permission/guidance to spawn sub-agents to make that happen. A lot of the problems with LLM-generated code are fixed if you fix the abstraction issue, and many of those fixes are relatively "mechanical" checks you can apply:
1. When reading the name of an abstraction, do you have a good idea of what it does?
2. What about the name and signature?
3. Does the implementation match that intuition?
4. Does any part of the codebase reach past the intended abstraction?
5. Does your code require nonlocal reasoning? (side-note: this is very important for humans, but it's more important for models since their harnesses aggressively try to avoid bloating context windows, so it's quite common that if you need two lines of code far apart in a file to relate to one another then you'll see downstream bugs)
6. Do all of the abstractions pull their weight? Are they all even used?
7. Is it possible to delete 80% of the suggested code and have an equivalently working product?
8. Do existing abstractions/conventions solve the problem you wrote a new abstraction for?
And so on. You obviously can't compress all good engineering judgement into a brief model context window, but you can get a lot more than you might expect. Whatever it is that you see agents doing poorly, try to come up with a general principle you think it should try to respect, and write that down for your future projects.
Different tasks, different tools, different prompts, or different ability to evaluate the results, likely some combination of all of the above.
- Tools: I can't get the ChatGPT web interface, with any prompts, any models, any amount of retries, with any combination of settings, to respond to a coding task with anything other than <snippet ignoring multiple explicit requirements for what should be a 20 SLOC task> <here's how you make it actually prod-ready (often stating that it just refused to implement something I asked for)> <paternalistic essay about how I shouldn't use my vibe-coded URL parser to send a man to the moon>. The underlying models are a fair bit better. Fully controlling the system prompt helps a lot. Agentic flows paper over a lot of those deficiencies. Anthropic models (and web interfaces) work a lot better for codegen for me out of the box. Agentic flows make that delineation much sharper.
- Tasks: I don't like the concurrent data structures LLMs write. Its opinions about the novel pseudo-probabilistic algorithms I care about are wrong. The level of hand-holding I need to get proper matrix codegen is insane. It works extremely poorly when operating at a meta-type level and trying to design a cohesive API. But, if you're not doing those things, who cares? I vibe-slopped a new programming language yesterday just to try it out with a new harness I previously vibe-slopped. At this stage, it doesn't have to be correct. If I get it kind of working just a little and think the results look promising then I can do better later if I want. A lot of companies are in (or at least think they're in -- IME this mentality bites founders much earlier than they expect much of the time) that stage.
- Prompts: LLMs are much more sensitive than you might expect to minor variations in prompts. The classic example I hope everyone knows by now: There are precious few scenarios where your interaction with an LLM should be a very long session repeatedly telling it the mistakes it's made. Almost anything else is better, up to and including (as a bad solution but still better for codegen output than the baseline) still having a very long session but asking the agent to rewrite the previous messages as if it had succeeded and then having the person manually edit the conversation.
- Evaluation Ability: Really? You thought +3k SLOC was the best way to solve that feature? I have a whole SOTA event loop and multi-processing framework in 3k SLOC, and when interacting with most companies' codebases you really ought to be deleting code with the average feature you implement, not adding code. Like you said, the code smells are everywhere. Like, slop is fine from time to time (easily 30% of the code I write for work is slop, largely because it serves one-off tasks), but some of the people pushing it just can't tell the difference. Just a month ago, somebody (outside of $WORK) was showing off a fancy new UI feature on some geo-rich project. It had a small bug. The implementor said they knew about it. The problem is that "if you know you know," and the only reasonable way the code for that kind of feature should have that kind of bug is if it has major problems which just aren't surfacing much in this particular demo. I suggested a couple alternative test cases to optimize toward, and a week and a couple rewrites later it was in a much better place. There were tens of thousands of tests before I made that suggestion, dozens of times the LLM confirmed the system was working as intended, and on and on and on. None of that matters if you need to build something that works and know that it works. The tests were all shit, as were the false assurances.
If you're looking to make it better, there are some tweaks you can make to your CLAUDE.md or what have you to help a bit. I have a lot that I do to make mine generate passable code without requiring constant human intervention, but something it responds well to is (1) pinning down what you care about re abstractions, and (2) giving it explicit permission/guidance to spawn sub-agents to make that happen. A lot of the problems with LLM-generated code are fixed if you fix the abstraction issue, and many of those fixes are relatively "mechanical" checks you can apply:
1. When reading the name of an abstraction, do you have a good idea of what it does?
2. What about the name and signature?
3. Does the implementation match that intuition?
4. Does any part of the codebase reach past the intended abstraction?
5. Does your code require nonlocal reasoning? (side-note: this is very important for humans, but it's more important for models since their harnesses aggressively try to avoid bloating context windows, so it's quite common that if you need two lines of code far apart in a file to relate to one another then you'll see downstream bugs)
6. Do all of the abstractions pull their weight? Are they all even used?
7. Is it possible to delete 80% of the suggested code and have an equivalently working product?
8. Do existing abstractions/conventions solve the problem you wrote a new abstraction for?
And so on. You obviously can't compress all good engineering judgement into a brief model context window, but you can get a lot more than you might expect. Whatever it is that you see agents doing poorly, try to come up with a general principle you think it should try to respect, and write that down for your future projects.