AI Broke Perfect Planning. Here Are 5 Rules.

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

1. Treat plans as hypotheses, not contracts.


2. Optimize for an evaluable prototype, not a perfect spec.


3. Move effort from creation to evaluation (reviews, tests, checklists).


4. Restart by rolling back context, not by "going back in time."


5. 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.

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.

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

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.