Fast Code, Bad Decisions: The New Software Crisis

Cursor can scaffold entire features in seconds. Models like Opus, Codex, and Composer can refactor complex codebases, analyse full repositories, and help shape architectural decisions before you've finished your coffee. Tools like Claude Code are pushing this even further, and the rapid progress around things like OpenClaw could fill an article on its own.

And yet, teams are still building the wrong thing. Faster than ever.

That's the part nobody talks about. When the cost of writing code drops towards zero, every other weakness in your process gets amplified. Bad architecture decisions that used to take three months to build now take three days, and you still have to throw them away.

The bottleneck has moved. Writing code is no longer the hard part. Planning is.

Speed Exposes Weak Planning

When implementation was slow, poor planning hid behind long development cycles. A team could spend six weeks building a feature and call it "iterating." The pace disguised the fact that nobody had properly thought through what they were building, or why.

With AI-assisted development, that cover disappears. You can scaffold an entire feature in an afternoon. If the direction was wrong, you find out by Wednesday instead of next quarter. That sounds like progress (and it is), but it also means teams burn through bad ideas at an alarming rate if nobody is doing the thinking upfront.

Fast tools reward clear thinking. They punish vague plans.

Good Plans Emerge Through Iteration

One misconception about planning is that it happens in a single sitting. You gather requirements, you produce a document, you hand it off. Done.

That almost never works in practice.

A useful plan usually takes shape over multiple passes. You write an initial version, then challenge it. You simplify sections that feel overcomplicated. You remove steps that don't earn their place. You restructure the sequence of development so dependencies flow cleanly.

Then you do it again. And again.

Each pass brings more clarity. Eventually, the plan reaches a state where you can start building with confidence, knowing the foundation is solid.

Even then, it isn't finished. The moment code meets reality, new constraints appear. Assumptions break. Parts of the system that looked simple on paper turn out to be anything but. So the process becomes a loop:

Plan. Build. Adjust the plan. Continue.

The teams that treat planning as a living process (rather than a one-off document) tend to ship faster and waste less effort over the long run.

Phases Beat Grand Plans

One technique that makes a significant difference: split the project into phases.

Instead of treating the product as a single monolithic delivery, break it into smaller milestones. Each phase answers one question: What is the smallest usable version we can build at this stage?

This prevents a trap that catches a lot of software projects: trying to build everything at once. When scope grows unchecked, complexity compounds. Every feature interacts with every other feature. Testing slows down. Decision-making stalls. The "big release" that was supposed to take three months quietly becomes six.

Phases solve this by creating controlled forward motion. Each milestone moves the system forward while keeping the scope manageable. Each one produces something you can test, demonstrate, and learn from.

Functional at Every Stage

There's a well-known product development analogy by Henrik Kniberg that's worth repeating here.

The traditional approach to building products looks like assembling a car piece by piece: wheels, then chassis, then engine, then a finished car. Until the very end, nothing is usable. The entire investment is a bet on that final moment when everything comes together.

A better approach looks more like: scooter, then bicycle, then motorcycle, then car. Each stage is functional. Each stage can move. Each stage teaches you something real about how people will use the final product.

This is what an MVP should actually mean: something functional that you can put in front of real users, not a half-finished version of the full product. The scooter isn't a broken car. It's a complete thing that solves a simpler version of the same problem.

Building this way reduces risk dramatically. Instead of betting months of effort on a single launch, the product evolves through usable versions, each one informed by feedback from the last.

Where AI Tools Become Genuinely Useful

Once you have a clear plan, well-defined phases, and a solid sense of the architecture, tools like Cursor become extremely effective. The structure already exists. The decisions have been made. The AI just has to execute.

Features get built faster. Refactoring becomes less painful. Iteration cycles shorten from weeks to days.

But the key word is "once". These tools accelerate execution. They don't replace the thinking that should come before it. Without a clear plan, faster tools just produce faster chaos. You can scaffold an entire wrong architecture in a day and spend the next month untangling it.

The Skill That Matters Most Now

For years, the most valued skill in software development was the ability to write code. That's shifting.

The developers and teams that move fastest today are the ones who think clearly before they build. They understand the system they're designing. They break work into meaningful phases. They define a real MVP (not a wish list with a deadline). They know when to simplify and when to push for completeness.

Once those decisions are made well, building the system becomes the straightforward part. Sometimes surprisingly so.

The most valuable skill in modern software development might be the one that happens before a single line of code gets written.