Ai Coding 5 min read

Stop Over-Planning, Start Building: How AI Changed the Cost of Being Wrong

AI collapsed the cost of building software. That changes how you should think about planning, prototyping, and experimentation.

So much of software development used to be spent planning, precisely because building was expensive. You’d spend days in design documents trying to get the approach right before writing a single line of code, because starting over meant losing weeks of work.

That math changed.

The Cost of Building Dropped

Things that used to take a team weeks can now be done by one person in days. The problems didn’t get simpler, but the mechanical overhead got handled: the boilerplate, the setup, the repetitive patterns.

Think about what goes into building a typical web application feature. You need the API endpoint, the database queries, the data validation, the error handling, the frontend components, the state management, the tests. Most of this work is pattern-heavy. It follows conventions. There’s a “right way” to do it that you’ve done a hundred times before. The thinking was done long ago; what remained was the typing.

That typing is largely handled now. What’s left is the thinking.

The Barrier to Attempting Things Disappeared

There’s a whole category of projects that never got started because the upfront cost was too high. “I’d need to learn a new framework.” “I’d need to set up infrastructure I’ve never touched.” “It would take months before I had anything working.”

Those barriers are lower now. Not gone, because you still need to understand what you’re building and why. But low enough that the calculus changed. You can describe what you want, get a working skeleton, and iterate from there. The AI handles the parts you don’t know while you handle the parts you do: what the tool should do, how it should behave, and what problems it should solve. Things that weren’t worth attempting are reasonable weekend projects now.

The Feedback Loop Got Tighter

You can prototype an idea, see if it works, and throw it away in a fraction of the time it used to take. That changes how you think about problems. You stop over-planning and start building faster, because the cost of being wrong dropped.

This matters more than it sounds. When building is fast and cheap, you can just build it and see. If the approach doesn’t work, try another one. Your learning happens through building instead of through speculating.

The gap between “I have an idea” and “I can see whether this idea works” shrank from days to hours, sometimes minutes.

Try More Things

When building is cheaper, you can afford to try more things. You can prototype three approaches and pick the best one instead of committing to the first approach because you can’t afford to start over. You can build the feature, show it to users, learn it’s wrong, and rebuild it, all in the time it used to take to build it once.

The economics of experimentation changed. And experimentation is how you find out what actually works, not planning documents or architectural debates or whiteboard sessions that go in circles.

This doesn’t mean planning is useless. It means the balance shifted: less time speculating about what might work, more time building and finding out.

The Hard Parts Are Different Now

None of this means the work got easier. It means the work changed shape.

If you were good at the mechanical parts of typing fast, knowing APIs, and setting up projects from scratch, those skills matter less now. If you were good at the thinking parts of architecture, trade-offs, and understanding what to build and why, you just got dramatically more powerful.

The person who understands the problem deeply, who knows what “good” looks like in their domain, who can evaluate trade-offs and make decisions: that person gets dramatically more out of AI than someone who’s copying and pasting prompts from a tutorial. The tool amplifies the gap. It doesn’t close it.

Start With Something Real

Don’t start with a toy problem like “write me a poem” or “explain quantum physics.” Start with something you’re doing at work right now: a function you need to write, a bug you need to fix, or a piece of documentation you need to draft. Use the tool on something where you can evaluate the quality of the output because you know what good looks like.

That’s where the learning happens: when you can see where the tool helps and where it falls short, because you have the expertise to judge.

The cost of engaging early is low. You try the tools, you learn what works, you adjust. And the learning compounds, because every hour you spend figuring out how these tools work makes the next hour more productive. The cost of waiting is different. It’s gradual, which is what makes it dangerous.

Every month you wait, the gap gets a little wider. Not because you got worse, but because everyone else got better.


This post is adapted from Get Insanely Good at AI. The book covers how AI actually works, how to use it for coding, building, and thinking, and what comes next.

Get Insanely Good at AI

Get Insanely Good at AI

The book for developers who want to understand how AI actually works. LLMs, prompt engineering, RAG, AI agents, and production systems.

Keep Reading