The calculus on a lot of these old adages is changing.
And I find that, when it reasons through and encounters some of those, it just makes assumptions rather than asking the user.
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.
If you go back and read the literature on this stuff, one constant pattern is that technical leaders are repeatedly 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.
The more things change, the more they stay the same.
Which could be summarised by a single line: "In other words, the primary cost of change increasingly becomes feedback delay, not development effort."
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.
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.
Wait, no, that's ACTUAL HUMAN pensions, because plenty of AI companies are still "investment grade"
https://www.forbes.com/sites/brandonkochkodin/2026/10/12/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 :)
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.