Comment by svachalek
6 hours ago
I agree. The latest models are getting quite good at validation, as long as they are clear on what the requirements are. Recently I got frustrated that while we have a huge test suite I noticed the LLM was hardly ever breaking a test with its changes (PRs only added tests, never changed old ones) which seemed suspicious.
I had it do a full audit. There were about 100k lines of tests, of which it determined about 60k were near useless. Many were overly mocked, some mocked to the point that they really weren't testing anything at all. It deleted those and wrote more expansive scenario tests to replace them, caught a lot of bugs on the way and fixed those too. Total time was about 2 hours.
I think humans need to review requirements, specifications, and test scenarios. And for some industries and uses they're still going to have to review every detail. But for a typical CRUD app, I think we're at a point where we can already set the process and quality bar higher than ever, in addition to moving faster.
I chuckle a little bit at this specification thing. We used to do this. We used to write big binders of specifications, and then we'd set about implementing them. We stopped doing it because it didn't really work. We'd learn things in the process of building which negated the value of the big specs we wrote. That's why we stopped doing it. This is where continuous improvement, CI/CD, tighter release cycles, etc. were all born.
But why? On reason is that implementation was a bottleneck. That made it expensive to change a system once it was entirely implemented. It was better to get the feedback sooner so you didn't waste time implementing the wrong thing.
The calculus on a lot of these old adages is changing.
I don't think this was only about implementation being the bottleneck. It was also because implementation forces you to think about the thing you're building at a very grannular level of detail, at which point you might discover flaws or opportunities that weren't obvious at the higher level.
And I find that, when it reasons through and encounters some of those, it just makes assumptions rather than asking the user.
That phrase, “once it was entirely implemented,” is doing a lot of work.
If you go back and read the literature on this stuff, one constant pattern is that technical leaders are constantly advocating for iterative development with frequent integration testing, and pushing back against management types’ impulse to favor giant up front over-specified design by committee plans. It’s not a phenomenon that’s unique to software, either,
But managers love meticulous up-front specification because it gives them the illusion of control and predictability. They are always being asked, “How much will it cost? How long will it take?”, and this approach gets you there.
I would argue that that’s the basic instinct behind meticulous up front specification for AI coding projects, too. It makes it easier to believe that, come implementation time, you can reliably one-shot it with an agent and have a working implementation that satisfies all design goals by next morning.
It is _still_ better to get the feedback sooner. Writing up some big specification, spending a bunch of tokens on implementation, and then shipping a massive PR to match the spec only to then find out it's wrong is a big waste of time. Nothing about writing grand plans in the face of unknown unknowns has changed.
The more things change, the more they stay the same.
Fred Brooks famously advised us to plan to throw one away. That was in the days of waterfall engineering.
The reason he said that is because the best way to learn how to properly build a complex system is by going through the process of building it. Sure, implementation is a bottleneck, but the real problem is that the experience of development is the best teacher.
Personally, I try to bring this lesson into my agentic coding practice by doing spikes and trial implementations first. This is where the AIs really deliver value: they can quickly build something out that touches a lot of the architecture so both it and I can get the proper shape of it. Only after that do I unleash it, constrained by what we learned.
Well, kind of. I think this is an interesting opinion on that: https://www.mountaingoatsoftware.com/agile/the-cost-of-chang...
Which could be summarised by a single line: "In other words, the primary cost of change increasingly becomes feedback delay, not development effort."
The problem with that was lack of iteration, not presence of specifications.
It is funny. At some point the code is the specification.
Remember when it was time to fire all the engineers because your business-analysts could just make UML diagrams?
If the code is the specification, then the only word on what the system is supposed to do is what it actually does.
When what it actually does is surprising, maybe you can make sense of it by asking the author what they were thinking. But that only works if the author is an entity that is both capable of thinking, and of remembering what it was thinking.
Yet software quality has been in deep dive for a while, long before AI.
Glad to see someone else notice this. I dread looking at or dealing with AI written unit tests because of the incredible amount of whiteboxing that goes on, though usually for the opposite reason because AI testing is almost entirely whitebox testing which fails if some internal details change
Funnily enough I've found that LLMs can be effective at mitigating many of the drawbacks of black-box testing and i've significantly expanded our usage of it over the past year
Yes, unfortunately a lot of requirements and specifications are now AI slop, thus developers stop reading them, and agent produce even more slop.
We need to take back writing requirements and specifications to humans.
Adopting high level BDD style testing of human written user stories (cucumber) is probably a good idea.
Just have AI write requirements then another AI write specs based on the requirements then another AI write tests based on the specs and another AI write the implementation based on the tests then another AI write the PR based on the implementation then another AI approve the PR and another AI deploy approved PRs to production!
Don't forget: let the user's AI use the product, find flaws, submit AI-generated bug-reports, which get turned into AI-generated tickets, etc.
3 replies →
FWIW, it's a great little "trick" to always ask for red-green tests. In my experience it's enough to ask for that and LLMs know what to do.
Same, although I use "TDD red phase"
https://simonwillison.net/guides/agentic-engineering-pattern...
If before AI you couldn't deploy to production without a code review, what makes you think you will be able to with AI?
To be fair, when I was a kid we'd connect the editor to the server using an unencrypted ftp connection and modify php files in production.
This worked perfectly fine, and phpmyadmin made schema changes super easy.
These days we do tests, schema migrations, terraform, staging sites, traffic migration, monitoring, logging, revision control, etc.
... it's a lot of boring work, and for most CRUD apps, its entirely unnecessary :)
That said: I doubt we'll abandon these practices for things that matter.
Because while modifying php files in production can increase velocity, it can also get very "exciting" if you have a few co-workers on the same project :)
I just don't understand the hype for this. "AI can do $x" quickly needs softening to "AI can try to do $x" which then becomes "humans need to verify $x has been done." If humans still have to oversee every part of the processes then what exactly is being automated!?
This would be like if we had our first factory producing cars but each car was like a die roll in terms of getting a car, a washing machine, a pile of scrap metal, or a baby. And people just asserting over and over that this was the future of making cars, no matter how much scrap metal keeps coming out.