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.
How do you expect us to take your views on LLM code quality and durability seriously when a) you don’t even look at the code and b) you’ve only been doing this for two months?
I've been working on the app for four months, and I am clearly not talking about code quality.
I am talking about product quality and maintainability. Both are more than adequate.
I know this because I have worked on it for an estimated 300 hours. Has the author practiced a similar approach for even a week? I doubt it.
I work on my project for 2 years now and using an LLM always came back to bite me. Learning how something works is needed, slow and painful - but pain is gain.
If this works for you - awesome. Until it doesn't.
As always there is 0 code or link. All talk.
And when do you expect my approach will stop to work? The core features are complete and the codebase is already sizable.
I will not publish my app on GitHub for free. It's a paid app, and I am putting in the hours not for your approval, but for commercial gain.
I also do not think it wise to link my HN account to my real name and expose my opinions and comments to my employer and colleagues.
Then you may as well said you've solved P=NP.
We do not require links to your app. What people are expecting is a description of your approach and sample outputs. So that someone else can try it and have the same standard of output. That's how you make a point that your approach is good.
When we buy books like "The Practice of Programming" or "The Pragmatic Programmer", it's because we are hoping to learn useful and productive behaviors. It isn't to hear boasts about how good the authors are good at using tools.
Even self-help books follow this pattern: Do this, expect that. They're not "Have you tried this too" or "I don't know about you, but I've got good results myself".
I am here to discuss my opinions on AI for software development because it's interesting. Not because I am selling a book or to prove anything to you.
If I had any special approach, I would be reluctant to share it with my potential competitors.
That said, I do not. It just works.
Meanwhile people here are posting the thesis that agentic development without careful code review results in an unmaintainable application.
I theorize that this is not something they experienced in practice, because it did not happen for me.
> Meanwhile people here are posting the thesis that agentic development without careful code review results in an unmaintainable application.
> I theorize that this is not something they experienced in practice, because it did not happen for me.
Are you currently maintaining the application? Like it's in production with paying users? You've only been on the app for 4 months. Compare that to something like Emacs that has been going for 40+ years. You can make a better case when you've been on prod for a few years.
By that standard, we could have AGI tomorrow, and I should still not comment.
No, my app is not published yet. It will probably take another month, with hopefully no complications arising out of the AppStore review process.
Then, I hope the ad campaign financials work out to compete with old apps of a lower quality that already boast no less than a million reviews.
I get it, you want me to make a case that can objectively convince you of the usefulness of agentic development without code review.
From my perspective, I have no interest in doing so, and I can only share my experience so far. In a few months time we will know more objectively whether my ambitions paid off.
Until then, you will either have to take my word for the quality of the product, or spend tens to hundreds of hours of effort in trying the approach for yourself. OP's article does not contain any specifics for where and how supposedly agentic development failed him either.
more talk
Prompt injection. Solved.
But accidentally breaking systems is not an issue either, obviously. Even though the system prompt asks for safety rails, and other prompts wouldn't accidentally violate that.
https://www.abc.net.au/news/2026-08-10/ai-assistant-hacks-gy...
Alignment of the latest models is questionable, yes. That's a different topic.
For this particular gym incident, supposedly Opus 4.6 was used in OpenClaw, predating the current safety guardrails of Fable and co.
I tried this recently and the results were total banana cakes. They couldn't even make changes to Pong without breaking it.
I did not try it on games.
Many features in my iOS app at first come out technically working, but with poor UX and verbose text in the UI.
One or two rounds of testing and refinement and they typically work well.