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.

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.

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.

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."