Ask an agent to build a product, and it will. Badly. You’ll get something bloated, insecure, unmaintainable, and probably not quite what you wanted. But ask it to implement a small, well-specified feature, and it’s brilliant at it.
Agents are astonishingly good at writing code. The problem is that they also make decisions, lots of them, and when requirements are vague, those decisions are often wrong. At their speed, you can end up with a mountain of code built on bad assumptions before you realize what’s happened.
The bottleneck in agentic software development isn’t the speed of writing code. It’s the quality of the decisions that lead to that code.
So I’ve changed how I use agents. Instead of asking them to build software, I have them help design it, challenge it, plan it, and implement it in small bites. Nibbles, really.
First, design. I work with an agent through requirements, edge cases, security, performance, and failure scenarios. We challenge each other, but the final call is mine. Then a fresh agent attacks the design, looking for holes and bad assumptions. Where we’re uncertain, agents build quick spikes. Why debate whether something works when an agent can go and find out? We iterate until the design holds up, without expanding the scope. Agents love doing that.
Next, planning. An agent breaks the design into dependency-ordered nibbles, each with explicit tests and acceptance criteria. Another agent challenges the plan for gaps, assumptions, and scope creep.
Finally, coding. A fresh agent implements one nibble, tests it, and proves it works. Another checks its work. Only then do we move to the next. No inventing requirements or quietly redesigning things along the way.
Take our current SSO project. We’re replacing authentication across several applications. Sounds simple until you consider identity, permissions, existing users, migration, security, and backwards compatibility. Rather than asking an agent to “implement SSO,” we worked through those decisions, tested uncertain approaches, and divided the implementation into independently verifiable stages. Small, controlled changes instead of one enormous leap of faith.
Sounds like a lot of work? It is. Certainly more than throwing a prompt at an agent and watching thousands of lines of code appear.
But that’s the wrong measure of productivity.
Writing code used to be expensive. Now it’s remarkably cheap. Bad decisions, however, are just as expensive as ever, possibly more so when agents implement them at extraordinary speed.
The economics have changed.
We can afford more rigorous design, independent challenges, and experimentation because agents make those cheap too.
Isn’t this waterfall? No. The design isn’t frozen. Spikes validate assumptions, nibbles validate the design, and when something doesn’t work, we revisit it.
The result, at least in my experience, is a shorter overall project. Less rework, debugging, architectural drift, and code thrown away.
I’m not trying to make agents better programmers. I’m giving them fewer opportunities to make bad decisions.
Spend more time deciding what to build, and less time fixing what got built.
That’s Agentic Nibbles.