AI didn't just make coding faster. It broke the economic logic that justified perfect planning.
When building is cheap, "plan perfectly" stops paying off. The new advantage is getting to something evaluable fast, then iterating through review.
5 Rules for Try-and-Improve Development
- Treat plans as hypotheses, not contracts.
- Optimize for an evaluable prototype, not a perfect spec.
- Move effort from creation to evaluation (reviews, tests, checklists).
- Restart by rolling back context, not by "going back in time."
- Plan deeply only for irreversible decisions.
The Old Equation
In traditional development, changing code is expensive.
Writing takes time. Testing takes time. Debugging takes time. Every iteration costs hours or days.
So we learned to plan perfectly - front-load the thinking, minimize the rework.
That made sense when production cost was high.
The New Equation
AI rewrites the cost structure:
- Code generation: minutes, not hours
- Test creation: minutes, not hours
- Iteration: cheap, not expensive
When production cost drops dramatically, the balance of investment shifts.
| Before | After |
|---|---|
| 70% planning, 30% building | 20% planning/building, 80% review/check |
| Get it right on paper first | Get it working, then evaluate relentlessly |
| Mistakes are expensive | Mistakes are discovered through review |
The majority of effort moves to evaluation, not creation.
Why Perfect Plans Fail
Here's the uncomfortable truth: you don't know what you want until you see it.
Plans are abstractions. Working software is concrete.
When you plan:
- You imagine how it will work
- You predict what problems will arise
- You assume you understand the requirements
When you build:
- You see how it actually works
- You discover problems you didn't predict
- You realize your understanding was incomplete
Planning operates on assumptions. Building reveals reality.
The gap between plan and reality isn't a failure of planning. It's inherent to complex work.
The Ksql.Linq Story
From June to August, I rebuilt my library from scratch four times.
Not small adjustments - complete rewrites. Architecture changed. APIs changed. Core concepts changed.
Each rebuild revealed something specific:
- First rebuild: We hadn't shared basic premises. The AI and I were solving different problems.
- Second rebuild: Our priority ordering was misaligned. What I thought was critical, the AI treated as optional.
- Third rebuild: My intent wasn't clear enough to communicate.
- Fourth rebuild: Shared understanding finally emerged.
Each full rewrite wasn't failure - it was diagnosis. Building and reviewing exposed exactly where alignment broke down.
In traditional development, four rewrites in three months would be catastrophic. With AI-assisted development, each cycle took days. The cost of discovery dropped dramatically.
One technique that helped: when restarting, don't think of it as "going back in time." Think of it as rolling back context. Rewind the shared understanding to a known-good point, then proceed differently. This works best when you preserve context somewhere durable - which is why shared memory systems matter.
(More on context management and shared memory in a later article in this series.)
The Core Insight
Once something has form, anyone can evaluate it.
A plan requires imagination to assess. People simulate differently. Agreement is hard.
A working implementation requires no imagination. You run it. You see what happens. Evaluation is direct.
| Planning-First | Building-First |
|---|---|
| Long planning sessions to align everyone | Short planning, build something quickly |
| Document extensively before coding | Build something to discuss |
| Evaluate proposals abstractly | Evaluate against requirements concretely |
Get to an evaluable state as fast as possible.
What Changes in Practice
Prototypes Are Cheap
When building costs days instead of weeks, prototypes become normal workflow, not special investments.
"Should we do A or B?" becomes "Let's build both and see."
Specifications Follow Implementation
Instead of:
Spec -> Build -> Discover gaps -> Revise spec -> Rebuild
Try:
Rough idea -> Build -> Evaluate -> Refine understanding -> Rebuild
The second path sounds wasteful. With AI-speed development, it's often faster.
Failure Loses Its Sting
When each attempt costs a day, "failure" is just "learning."
The question isn't "How do we avoid building the wrong thing?" It's "How do we learn what's right as quickly as possible?"
The 30-Minute Loop (A Practical Starting Point)
- 5 min: Write success criteria + constraints (what must be true, what cannot change)
- 10 min: Build the smallest slice that can be evaluated
- 10 min: Review against criteria (add tests/checklist items as you discover them)
- 5 min: Decide: refine, rebuild, or roll back context
This is not about moving fast blindly. It's about moving fast toward clarity.
When Perfect Planning Still Matters
This isn't "don't plan at all." Some decisions deserve deliberation:
- Irreversible choices: external API contracts, data schemas others depend on
- High-cost pivots: architecture that requires coordinated changes across teams
- Compliance/legal constraints: where "try and see" has real consequences
For these, plan carefully. For everything else, bias toward building.
The Mental Shift
The hardest part isn't process - it's psychology.
We're trained to value careful planning. "Measure twice, cut once." Building something you might throw away feels wrong.
But with AI, the cost of "cutting" dropped an order of magnitude. The old wisdom needs updating:
Measure once, cut, evaluate, cut again if needed.
It's not reckless. It's efficient given new constraints.
Summary
| Old Model | New Model |
|---|---|
| Planning is investment | Planning is hypothesis |
| Building is expensive | Building is cheap |
| Rework is waste | Rework is learning |
| Perfect before starting | Evaluable as soon as possible |
| Specification-driven | Evaluation-driven |
When AI makes building fast, the optimal strategy shifts from plan-perfectly to try-and-improve.
Don't plan what you can build. Build what you need to learn.
Top comments (0)