> In my experience, most people don’t know what should be developed. Even users don’t know if you ask them.

That's also my experience. The most productive use of coding agents I've found so far is rooted in this.

I wanted to build a tool, for my own use, to let me specify a simple 2D geometry using a textual representation that looks like a simple version of the geometry itself. I'm the user and the implementer, so it should be easy right? I had some ideas for the basics of the textual representation, but the details were far from obvious.

I spent ~10 hours having AI give me suggestions and refinements for the textual representation along with evolving code to parse the representation. It turned out to be a highly productive way to explore the space of trade-offs. This representation looks really good, but it's ambiguous in some cases. That one is not ambiguous, but parsing is tricky. That one is too annoying for the user. It was all about quickly gathering the knowledge and therefore understanding what to build.

When I finally settled on a representation that had a good set of trade-offs, the code was pretty ugly. It worked, but it was about 1,200 lines of code, with weak tests. I tried to have the AI refactor it, and even restart from the final representation choices. Its best version was 1,000 lines of code that were difficult to understand.

I was getting on a plane with no internet the next day. So, armed with all the gathered knowledge, I decided to see what I could do with the code on the plane. It was too complicated to refactor as I went. So I rewrote it from scratch, employing the knowledge I'd built up. In 2-3 hours, I had a complete implementation that was simple to understand and less than 300 lines of code. ~40% of those lines of code were tests that were quite robust.

That amount of iteration in the knowledge gathering step would have taken me closer to a couple of weeks without the AI. And, by employing Fred Brooks' "build one to throw away" (a concept that I think is largely about the same thing as the article), I had a solid implementation without much more work.

I'm sure this workflow is not for everyone. But it (accidentally) leaned into the topic of the article, and I think that's exactly why it worked so well for me.