Software Engineering fundamentals matter more
TL;DR
Coding agents can now write code that works and passes tests, the author argues. They still can't judge how software should fit together, or make it debuggable and maintainable. That makes engineering fundamentals matter more than before.
The article
- In the past year, agent harnesses crossed the "can it be done" line. The big providers' economics don't look viable to him. But the capability won't go away. Open-weight models on a strong personal computer trail the frontier by only a small margin.
- Agents get you to "it works". A prompt like "develop with red/green TDD" also gets you to "it's testable". Above that, the results get shaky. A component's API and how it fits with other software are subjective calls, shaped by experience and by how long you'll live with the code.
- He compares this to learning to weld in his 20s. He quickly built things too heavy to lift or to get out the shop door. He learned that how the parts go together makes the difference.
- LLMs predict rather than reason. They can only echo reasoning that was in their training text. Debuggable, layered, composable design needs sustained reasoning. Even frontier models fall short there. He cites the paper "The Illusion of Thinking" on how poorly LLMs reason. For a different approach, he points to LeCun's JEPA work.
- The wins he sees come from feeding the model concise data at the right moment. They also come from deterministic validation tools whose plain-language output the model can use to correct itself. Tool calling and instruction following impress him more than the code generation.
- Instruction following cuts both ways. Models can't tell good instructions from bad ones. So Simon Willison's "lethal trifecta" and prompt injection remain open holes. Sandboxes and alignment only narrow them. He hopes post-training will start rewarding clean interfaces and maintainability.
Why it matters
The article is short and personal, closer to a position statement than an argument with evidence. It has no benchmarks or worked examples. Read it for its links to The Illusion of Thinking, JEPA and the lethal trifecta. It also gives one veteran engineer's view of where agents stop helping.
The discussion
A heated, sprawling thread. The top comment's IKEA analogy pulled dozens of replies into an argument about furniture quality. One commenter's claim to maintain a 150k-line app without reading the code drew the angriest exchange. Underneath both ran the article's question of whether agents can do design work or only implementation.
Agents implement but don't design
Many working engineers agreed with the article that generated code works at the function level. Directory layout, interfaces and state management come out a mess, and the model quietly makes product decisions nobody asked for. Others called this a usage problem, fixed by a fuller spec, a reference repo or a configured test suite with red/green TDD. Critics answered that defining the requirements is the job, and that a spec complete enough to remove guessing is the code. One commenter blamed the architecture failures on context length, since a model can't hold the whole codebase in mind.
But what really gets me is the model often tries to make assumptions for me that I didn't specify in the prompt. Subtle things like which error states are "oh shit we need to bail" vs "this isn't a deal breaker."
But a big part of software engineering is literally defining the requirements.
The no-review app
One commenter stopped reading his iOS app's code two months ago, and says the agent still maintains all 150k lines, half of them tests. His 300 hours went into QA, UX and product taste instead. Replies called four months with zero users far too early to judge maintainability, which only shows once requirements change and other developers arrive. They also pointed to the major agent harnesses, which are largely vibe-coded and full of regressions. A few defended him, arguing that the split in experiences comes from people not putting in the time to learn the tools.
150k LOC, around half of that in tests, and the AI still has no problem maintaining the code on my behalf.
You don't get to know if your code is maintainable until the use cases have expanded and usually other devs will come on board, and what guarantee is there that they will direct the ai the same way?
AI code as IKEA furniture
The top comment predicted AI code will be like IKEA, consistently good enough, and cut demand for engineers to perhaps 1% of today's. Critics said the analogy breaks because IKEA sells identical items, while AI produces bespoke software full of hidden decisions that still needs expert supervision. Supporters countered that most software really is standard fittings joined together, and that AI is finally delivering what scripting tools promised office workers. Much of the subthread then turned into an argument about whether IKEA furniture lasts.
AI gives software that is bespoke with hundreds of decisions made, hidden from you, in the background.
Every other engineering discipline coalesced on standard operating procedures decades ago, maybe we software engineers have to swallow our pride a bit and start accepting them in our discipline too.
Is prompt injection solved?
Citing a third-party evaluation in which none of 720 injection attempts beat Anthropic's latest models in auto mode, one commenter called the problem largely solved. Others said passing a fixed benchmark shows fitting to the benchmark, not robustness. A security researcher who trusts the research still got an injection through Opus 5 in his own experiments. Another argued that any nonzero rate is unacceptable when an agent has broad permissions.
You do not solve "losing russian roulette" by adding more empty chambers. One bullet in 600 chambers is still one bullet too much.
In general, there are almost infinite possibilities for the prompt injection payloads, it's a matter of creativity and trial and error.
Do LLMs reason?
On the article's claim that LLMs "predict", one side said prediction is only the training objective and reasoning can emerge from it. The definitions used to deny it, they added, would also rule out humans. The other side said looking like reasoning isn't reasoning, comparing it to a photocopier fed a maths paper. Several commenters found the debate circular and suggested talking about concrete failures like context rot and the reversal curse.
Prediction is the training objective. The ability to reason can be, and very arguably is, an emergent property of that.
Calling it a "simulation" is assuming the conclusion.
Consensus
Agents write working code quickly when the task is scoped and backed by tests. But someone still has to decide structure, interfaces and requirements. Experienced engineers mostly see that as their job for now.
Dissent
A vocal minority said design judgment is a training problem that will be solved like any other. They expect AI to beat the average engineer, who they said writes poor code anyway, and to shrink the profession sharply.