If you’ve ever presented the design of a product after the fact, you know the most interesting bit is the surprises. What broke at scale? Where did you change course? What did the customers do that you didn’t expect? What were the interesting metrics? These are impossible to predict in advance. They’re also the most important parts—the punch lines. When we talk to folks about how they use coding agents they usually fall near one end of a spectrum: planners, who work on a spec or design with an agent, and iterators, who write a short prompt, and iterate on (or throw out) the results. Of course, this is all new, and none of us knows what we’re doing yet. (This is the time to let a thousand flowers bloom. Build your own software factory.)
But the debate on planning vs iteration is not new. (And neither side is right, though you should consider about what works for your team, and why). We’ve read clear PRDs or slides that have set the direction for a product or project. We’ve been in meetings where the prototype carried the day after weeks of failed paper designs. And everything in between.
If your most precious commodity is your attention, ask your agents for the design after they’ve built the thing. Ask it for the surprising things. The sticky bits. The workarounds. The contentious topics in review. The traditional funny quote here is from Frank Westheimer, who said “Why spend a day in the library when you can learn the same thing by working in the laboratory for a month?” If it’s the coding agent—and not you—in the lab, however, this is turned upside down: let the agent spend some extra cycles in the lab, and get one layer deeper on the design. The planners and iterators are closer than they think: a plan that’s been prototyped is a better plan.