The iteration capability of modern AI coding tools is so powerful that it forces a question most engineers have not yet confronted: what is still worth building as permanent software? The answer, I think, is that software now operates at two speeds — and the interesting work is learning to move between them.
The first speed is exploration. You place an AI agent into a problem space with the right scaffolding — API access, an execution trace, a feedback signal — and you give it time. It does not need a grand plan. It does not need a detailed specification. It runs, fails, adjusts, runs again. Through sheer volume of iteration, effective approaches crystallize on their own. I have watched agents discover solutions in hours that would have taken me days of careful design, not because the agent is smarter but because it can attempt a thousand variations while I am still sketching my second.
This is not a metaphor for brute force. It is closer to dynamic programming. The agent decomposes the problem, explores sub-solutions ahead of time, and caches what works. Each failed attempt narrows the search space. Each partial success becomes a building block. The process looks chaotic from the outside but is structurally efficient — it is search with memory.
The Sparring Partner
The pattern that has proven most effective is using a coding agent as a sparring partner — the methodology I described in detail in Testing AI Agents. The coding agent reads your specification and writes graders; you verify the graders are reasonable; then you launch dozens or hundreds of parallel runs, each tweaking a different variable. What emerges is a landscape of solutions with clear peaks and valleys.
The sparring partner does not replace your judgment. It multiplies it. You make one decision — "this grader is reasonable" — and the system extracts a thousand data points from that single act of verification.
From Exploration to Crystallization
The second speed is crystallization — what I called the memoization shift. When enough parallel experiments run, successful configurations cluster around structural choices: particular phrasings that prevent hallucination, particular tool schemas that minimize backtracking, particular validation rules that catch the most errors per token spent.
You freeze these patterns: remove the exploratory scaffolding, encapsulate the logic, make interfaces rigid and predictable. The result is conventional software — a library, a service, a CLI tool — that embodies the distilled knowledge of all that exploration. Black-boxed, deterministic, fast. No AI agent needed to run it. Products for regular users who just want something that works reliably every time.
The Feedback Mechanism
The piece that ties the two speeds together is the feedback mechanism. Without it, exploration is just random flailing and crystallization is just premature optimization. The feedback does not need to be fine-grained — you are not looking for framework-level diagnostics or line-by-line debugging output. What you need is a directional signal after each system iteration. Did the overall behavior get better or worse? Did the grader score go up or down? Did the agent use fewer tokens or more? Did it hit the edge case it missed last time?
Think of it as meta-level feedback rather than implementation-level feedback. You are not debugging a function; you are evaluating a system's trajectory. The instrumentation you need is closer to A/B testing infrastructure than to a traditional debugger. Replay capabilities, so you can re-examine a run after the fact. Comparison views, so you can see two configurations side by side. Aggregate statistics, so patterns become visible across dozens of runs rather than hiding in individual traces.
This feedback mechanism is itself software worth crystallizing. It is costly to get right — false positives in your grader waste enormous amounts of compute, and false negatives let bad configurations slip through — and once it works, it is cheap to reuse across projects. It is the meta-layer: the infrastructure that enables exploration, which in turn produces the artifacts worth hardening into products.
Two Speeds, One Process
The mental model I keep returning to is that software development with AI is not one activity but two, running at very different clock rates. The fast clock is exploration: high-volume, parallel, disposable, scored by automated graders. The slow clock is crystallization: careful, deliberate, designed for durability, shaped by patterns that emerged from the fast clock. Neither speed is optional. Exploration without crystallization produces impressive demos that no one can depend on. Crystallization without exploration produces rigid software built on guesswork rather than evidence.
The engineers who will thrive in this environment are the ones who learn to operate at both speeds — who can set up the scaffolding for a thousand parallel experiments in the morning, review the results after lunch, and by evening have identified the three patterns worth hardening into a shipped artifact. The skill is not in writing the code. The skill is in designing the feedback loop, verifying the grader, reading the landscape of results, and knowing when to stop exploring and start building. The AI handles the volume. The human handles the judgment. And the software that comes out the other end is better for having been found rather than merely designed.