Comment by user43928
21 hours ago
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.
2 months simply isn't enough time for evolving system needs. 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? Your core features today may be solid, but expanding and adding cases coupled with debugability is what shows off maintainable code. Two months simply isn't enough time. Two years, maybe. I have maintained the same aggressively growing software from start up to public company to begin acquired. Two months is literally nothing in the maintenance lifecycle
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.
12 replies →
> worked on it for an estimated 300 hours
If humans aren't needed why have you had to spend 300 hours?
I upvoted your comment BTW because I think you might be right, but I'm not sure. I still see people doing a lot of work, despite LLMs.
“Debuggable? It can add extensive instrumentation in seconds.
None of this requires expertise, prompting, or mention of TDD. It's the default.”
I’m pretty sure it takes some level of expertise just to use the term “instrumentation” correctly in a sentence.
There are nasty things we can do in software that can indeed make debugging difficult (for instance in the “make everything reactive” craze, some random subscriber could trigger from some piece of state changing that isn’t obvious at all and fully asynchronous and in a totally different part of the code).
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.
Not really a different topic. All commands go into the same prompt system. If one part can accidentally be breached, then it can also deliberately be breached. Injection remains a problem.
1 reply →
> prompt injection appears to be largely solved
That's about as correct as saying cyber security is largely solved by referring to a "benchmark" that a particular virus scanner is able to detect and prevent infection with 720 known computer viruses. All this shows is that the model has been fitted to the benchmark, not that it is hardened against any conceivable way of prompt injection.
And regarding vibe-coding a mobile app with zero users, probably zero monitoring and zero everything like all the other vibe-coded apps that have zero users. Sure you can do that but what is the point?
I tried this recently and the results were total banana cakes. They couldn't even make changes to Pong without breaking it.
If something is bananas, it is silly/crazy. If something is banana cakes, I don't know. Banana pancakes are specifically pancakes and are delicious.
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.