From Plan-Perfectly to Try-and-Improve

Source: Dev.to

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.

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. Each rebuild was a full rewrite—architecture, APIs, and core concepts changed.

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 a failure—it was diagnosis. The act of building and reviewing exposed exactly where alignment broke down. With AI‑assisted development, each cycle took days, dropping the cost of discovery to near zero.

Key technique: When restarting, think of it as rolling back context—rewind the shared understanding to a known good point, then proceed differently. This requires preserving context, 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; different people simulate differently, making agreement hard.
• A working implementation requires no imagination—you run it and see what happens. Evaluation is direct.

This changes the strategy:

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 a normal workflow, not a special investment.
“Should we do A or B?” becomes “Let’s build both and see.”

Specifications Follow Implementation

Traditional flow: Spec → Build → Discover gaps → Revise spec → Rebuild
AI‑enabled flow: Rough idea → Build → Evaluate → Refine understanding → Rebuild
The second path may sound wasteful, but with AI‑speed development it’s faster.

Failure Loses Its Sting

When each attempt costs a day, “failure” is just “learning.”
The question shifts from “how do we avoid building the wrong thing?” to “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 requiring 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 the process—it’s psychology. We’re trained to value careful planning: “Measure twice, cut once.” Building something you might discard feels wrong. With AI, the cost of “cutting” dropped 10×, so 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.

This is part of the “Beyond Prompt Engineering” series, exploring how structural and cultural approaches outperform prompt optimization in AI‑assisted development.