AI didn't just make coding faster. It broke the economic logic that justified perfect planning.
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.
This 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: trivial, 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 the nature of 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: Discovered we hadn't shared basic premises. AI and I were solving different problems.
- Second rebuild: Found our priority ordering was misaligned. What I thought was critical, AI treated as optional.
- Third rebuild: Realized my own intent wasn't clear enough to communicate.
- Fourth rebuild: Finally, shared understanding emerged.
Each full rewrite wasn't failure—it was diagnosis. The act of 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 to nearly zero.
One key technique: when restarting, don't think of it as "going back in time." Think of it as rolling back context. You rewind the shared understanding to a known good point, then proceed differently. This requires having that context preserved somewhere—which is where shared memory systems become essential.
(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. You have to simulate it mentally. Different people simulate differently. Agreement is hard.
A working implementation requires no imagination. You run it. You see what happens. Evaluation is direct.
This changes the strategy:
| 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 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 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?"
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 10x. 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.
This is part of the "Beyond Prompt Engineering" series, exploring how structural and cultural approaches outperform prompt optimization in AI-assisted development.
Top comments (0)