Build, Learn, Delete, Repeat

Everyone's telling you to make your AI agents plan first. To have them break down tasks, outline their approach, and get your approval before proceeding. But after thousands of agent runs, I've discovered the exact opposite works better: Skip the planning. Just let them build. Then throw it all away.

This sounds wasteful and wrong, but it's how prototyping and engineering worked long before coding agents.

The Conventional Wisdom: "Make a plan first"

Spend five minutes reading about AI coding agents and you'll encounter the same advice for large tasks:

  • "Tell the agent to make a plan first"
  • "Have it outline what it would do before starting"
  • "Break the task into subtasks for verification"

This makes intuitive sense. Planning prevents mistakes. It gives you control. It stops the agent from going off the rails on some wild implementation you never wanted. This is not bad advice, but it only really works well if you know what you want and how to go about it.

If you don't know what you want, this advice isn't helpful. What's helpful is just building the wrong thing and learning from it.

Build, Learn, Delete, Repeat

Here's what I found myself doing when tackling anything non-trivial with agents:

  1. Build: Give the agent the task. Tell it what you want with detail if possible, but no worries if you don't know exactly what you want yet. For me, this is often light on details, sometimes intentionally so because I'm curious what the agent will come up with.
  2. Learn: Skim the thinking, approach and output. Not necessarily to use it, but to understand the problem better. Is this what you'd do? Is this better? Did it do something you didn't expect?
  3. Delete: Throw it away. /clear the context. Start fresh.
  4. Repeat: New conversation, better and more nuanced prompt, incorporating what I learned.

After a couple iterations, my prompt evolves from a high-level feature request to something fairly specific and prescriptive. Sometimes one prompt becomes multiple prompts because I realize this task is actually better as multiple separate tasks. What really helps is that reviewing the agent's output becomes much easier with each repetition because you become more familiar with the task.

This Mirrors Pre-AI Engineering

Before AI, how did we actually build things? We prototyped. We spiked. We built proof-of-concepts that we knew we'd throw away. We learned by doing, not by planning in a vacuum. Often, the first version did not work at all.

Remember your last big feature? You probably:

  • Built a hacky version to understand the constraints
  • Discovered three things that made your original plan impossible
  • Threw it away and built the real version

This is just the same process with agents. Now, instead of building the prototype, the agent does it. You spend time reviewing the agent's prototypes, and instead of one exploration, you can do multiple in parallel.

The Background Agent Unlock

Two big things enable this approach:

  1. Claude Code + Claude Max is a steal and a very very good agent.
  2. Background agents allow you to run multiple agents in parallel without actively waiting for them, significantly reducing the cost of starting tasks and deleting them.

Disclaimer: I work on Terragon, which is a background agent platform for Claude Code.

When does this work?

Of course, bug fixes, small tweaks, and well-scoped tasks don't benefit from this. This approach is mostly useful for large, ambiguous tasks where you're not sure what you want yet or how to do it.

You need to be able to evaluate and review what the agent built at least semi-effectively. Otherwise this process gets really painful because you end up going back and forth a lot to understand what the agent built. These throwaway attempts often contain a lot that's wrong, but the bits that are right are incredibly helpful for prototyping.

I've found that this works well for cross-cutting and end-to-end changes that are hard to scope out in advance—changes that span multiple complex parts of the codebase that you might not be familiar with.

I've found that this doesn't work well when the task is mostly visual. I've had much better luck with visual changes when I'm more hands-on with the agent and am able to iteratively refine the output together. Visual doesn't mean front-end heavy! This approach is very helpful for complex frontend changes too—just not the part about how it looks.

For now...

Though I'm sure this is all going to change and evolve with new agents and models and we'll be able to do more and more with less and less planning. For now, I thought it was interesting to share this approach. Do you do this too? Or do you have a different approach?