> In the past year, agent harnesses crossed the “can it be done” rubicon.

Brother, I'm still in "Can you get it right?"-mode. What am I doing wrong? (Rhetorical, but advice welcomed).

With generated code, the directory structure, interface design and general state management is usually a haphazard mess. Even with the best frontier models. 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." Sometimes it will ask, but more often than not it will just make a decision and it's often the wrong one. If I don't have a fully kitted out test suit and a good type checker to verify the final product against, the the whole looping thing is just useless to me and I'm back to reviewing every line of code it puts out and having to draw on my years of architecture experience to make sure we don't build a giant pile of trash.

> It helps to know that LLMs don’t “reason”. They predict ..

Semantics. Prediction is the training objective. The ability to reason can be, and very arguably is, an emergent property of that.

"They’re foundationally incapable of always and consistently preventing prompt injection attacks. “Alignment work”, safety harnesses, and sandboxes all help to add barriers against the worst, but there are fundamental gap" ...

They seem to be very good at a lot of rudimentary best practices, more so than humans, but more accurately - if you run and audit pass with specific instructions ... they're very good at that.

I mean - it's what they're the best at which is applying 'fuzzy heuristics' in a mechanical way. If can describe issues concisely, the patterns, the styles, the rules then LLMs can very mechanistically and methodologically grind through them.

I don't even see how this is controversial - without getting into 'what their reasoning means' - we can all agree that their synthetic reasoning is pretty good at narrow scales, and they've been 'trained by compilers' and are extremely good at spotting common patterns.

If you back that up with a lot of tokens ... they excel.

Designing architecture, that's difficult, but hammering away at all the 'known-knows across a system' especially to identify things ... they're pretty good at that.

LLM is the new Excel

The article says what many here like to hear, but in my opinion the core arguments are false.

> Making software debuggable, maintainable, layered, and composable – that’s still quite a trick

Not really. I have been working on a mobile app for months, and I stopped even glancing at the code about two months ago.

150k LOC, around half of that in tests, and the AI still has no problem maintaining the code on my behalf.

Debuggable? It can add extensive instrumentation in seconds.

None of this requires expertise, prompting, or mention of TDD. It's the default.

Frankly I do not believe the author tried developing a large codebase fully agentic and without reviewing the code. I believe many here look at the code produced, deem it substandard, and go hands on.

> They’re foundationally incapable of always and consistently preventing prompt injection attacks

From Anthropic's article about the Auto mode:

> We commissioned an evaluation from a third party, Trajectory Labs, who tested different models within the latest publicly available versions of Claude Code and Codex as of July 17th 2026.1 They tested 72 indirect prompt injection scenarios held out from Anthropic

> In this evaluation, none of the 720 attack attempts succeeded against Claude Fable 5, Opus 5, or Sonnet 5 running auto mode. On the other hand, 5.83% of the attacks succeeded against GPT-5.6 Sol running Codex's Auto-review mode. Notably, this is greater than the 0.09% average attack success rate against our latest models running in bypassPermissions mode without additional safeguards. The tests showed a 19.03% attack success rate against GPT-5.6 Sol when running in Full Access mode

I'm sure someone is going to reply with how they do not trust Antrophic's research, but lacking other data, prompt injection appears to be largely solved already.

AI generated code is like IKEA furniture.

IKEA furniture embodies many elements of good cabinet making but skips many nonessential elements. And does this more consistently than cabinet makers who can be bored, incompetent, depressed, burnt out, resentful, tired, having a bad day.

In the future AI code inevitably will embody most good software engineering practices. And will do this more consistently than software engineers who can be bored, incompetent, depressed, burnt out, resentful, tired, having a bad day.

Just look at the messages on HN or around you at your colleagues to see how mediocre the average software engineer is..

Today's IKEA is good enough for most people.

Tomorrow's AI coding will be good enough for most corporations.

Good enough to vastly reduce the need for fine craftsmen and women / software engineers.

Good enough to deskill those who call themselves cabinet makers / senior software engineers. These days the cabinet makers I personally know just do contract kitchens for project builders.

But IKEA is and AI will be, bad enough that at the high end with special requirements / taste / money / an inflated sense of self worth, some furniture makers still exist and thrive.

Perhaps 1% percent of current software engineers of today will be needed in the future when AI code inevitably has the ability to follow good software engineering practice.......

And as usual it will mainly be the mediocrities that remain ( so there is hope for you too ), with occasional islands of excellence.

It seems people have forgotten that engineering is actually a thing, and there are many aspects of SWE that can be dealt with like a real engineer. As an example, if you have a producer-consumer system, you can model it using a queue, and you can use queue theory to calculate what it would take to achieve certain guarantees. Hard, cold, calculations, like a civil engineer evaluating a structure. I chose to be a SWE, in the real sense of the word, because I believe this kind of approach and expertise in missing from many companies and software projects.

But do the same SWE fundamentals apply if the one doing the programming is many times smarter than us?