The Software Development Process Is Broken. AI Just Made It Obvious.

For twenty years, the software development process did one job. It moved a spec from the people who decided what to build to the people who wrote the code. Plan it, design it, build it, test it, ship it, maintain it. Every stage existed to keep that handoff moving.

That process turned a lot of good engineers into order takers. Somebody else figured out what mattered, wrote it up as a ticket, and the engineer’s job was to turn the ticket into working code. For two decades that was fine, because writing the code was the hard, slow, expensive part.

Then AI made writing code cheap. And the whole process built around that one slow step stopped making sense.

I’ve been writing software for over twenty years, and I’ve run engineering at three companies. Engineers who think like owners outperform the ones who wait for tickets. That was true before AI. Now it’s the only thing that matters, because the ticket work is the part AI does best. The companies that figure this out are going to pull away from the ones that don’t.

What the software development process was actually built to do

Open any textbook and the software development life cycle (SDLC) looks like a clean assembly line with six or seven stages.

You start with planning and requirements, where you decide what the software needs to do. Then design and architecture, where you decide how it’ll be built. Then development, the actual coding, which is where most of the time and money goes. Then testing and quality assurance (QA), where you catch the bugs. Then deployment, where it goes live. Then monitoring and maintenance, where you keep it running and fix what breaks.

The methodology on top of those stages changed over the years. Waterfall ran the stages in one long line, months of requirements followed by months of design followed by months of coding. Agile chopped them into two-week sprints so teams did a little of everything at once. Continuous integration and continuous deployment automated the path from a code commit to production. Every one of those changes made the assembly line faster.

But the line itself never changed. It was always a machine for turning a decision about what to build into a pile of working code. And the slowest, most expensive station on that line was always the same one: a human being typing the code.

So the whole process got optimized around that bottleneck. We hired more engineers to type faster. We groomed backlogs to keep them fed with work. We measured velocity, story points, and lines shipped. We built an entire industry around feeding the coding machine.

Here’s what that table looks like now.

Stage	What it was built to do	What AI does to it
Planning and requirements	Write the spec for engineers to follow	Bottleneck moves here: deciding what to build is now the hard part
Design and architecture	Decide how to build it	AI proposes designs in minutes, but won’t defend your conventions
Development	Type the code (the slow step)	Cheap and fast, so it stops being the constraint
Testing and QA	Catch bugs a human introduced	Now you’re catching bugs a machine introduced, at machine speed
Deployment	Ship the finished code	Easy, and never the real problem
Monitoring and maintenance	Keep it running	More code shipped faster means more to maintain

The old process turned your best engineers into order takers

The clearest symptom of the old process is the backlog.

Walk through almost any engineering team’s backlog and you’ll find a museum of things nobody is ever going to do: a feature request from a customer who churned two years ago, a bug nobody can reproduce, a refactor everyone agreed was important and never started, and a research spike meant to inform a decision that got made six months ago without it.

The backlog was never an asset. It was a liability of all the crap we thought we had to do, a graveyard with a project management interface.

Teams hid in the backlog because it was safe. Grooming tickets for ninety minutes feels productive. It looks like the team is thinking ahead and nothing is being forgotten. Nobody has to sit in a room and argue with product about what actually matters.

That’s the real reason the backlog existed. It was a peace treaty between product and engineering. Both sides agreed not to have the hard conversations as long as everyone stayed busy. Product kept the queue full, engineering kept it moving, and nobody had to make the call about whether any of it was worth building.

The cost of that treaty was the engineer. A good developer who could have been helping decide what to build was instead heads-down, turning someone else’s half-baked idea into code. We took people who could think and paid them to take orders.

AI broke every stage of the process

Once code got cheap to produce, every station on the assembly line cracked at once.

Estimation stopped meaning anything

The old promise was “on time, on budget.” You estimated the work, staffed it, and tracked it to a date.

That promise depended on coding speed being roughly predictable. It isn’t anymore. One engineer with the right tools and a clear problem can finish in an afternoon what used to take a sprint. Another engineer on a messy part of the codebase gets almost no lift at all. When the speed of the slowest stage swings that wildly, every project timeline you commit to is a guess wearing a suit. The planning stage was built on a number that no longer holds still.

Requirements became the whole ballgame

When typing the code was the bottleneck, a vague spec was survivable. The engineer would grind through it slowly, ask questions along the way, and you’d course-correct over the weeks it took.

Now the code comes back in hours. If the requirement was wrong, you just got the wrong thing built faster. You don’t need rockstar developers anymore. You need rockstar requirements. The bottleneck moved upstream, from the hands that write the code to the mind that decides what the code should do. Most teams have not moved their best people upstream with it. It’s the clearest sign that communication has become the real bottleneck in software development, not typing speed.

Development stopped being a place to hide

This is the big one. Tools like Claude Code can chew through a well-defined backlog in a weekend, including the engineering wish list of refactors and migrations that sat untouched for years.

Which means “we’re heads-down working through the backlog” stopped being a real answer. You can’t justify a quarter of cleanup when cleanup is exactly what AI is best at. Execution stopped being the constraint, so execution stopped being a place anyone can hide. For teams that are good at deciding what matters, that’s a gift. For teams that have been deferring that decision for years, there’s suddenly nothing left to do except the thing they’ve been avoiding.

Review and quality became the bottleneck nobody staffed

When a team ships two or five times the code, somebody still has to read it.

Pull requests pile up faster than humans can review them. Most of the code looks fine on the surface. But somewhere in the diff is a subtle bug, a wrong abstraction, or a solution to the problem you described instead of the problem the user actually has. You can’t tell which pull request hides that without careful review, and careful review at machine speed is exhausting.

The data already shows the strain. The 2024 DORA report found that more than 75% of developers now lean on AI for at least one daily task, but that same AI adoption came with an estimated 7.2% drop in delivery stability and a 1.5% drop in throughput. Almost 40% of respondents said they had little or no trust in AI-generated code. The 2025 Stack Overflow Developer Survey found the same thing from the developer’s seat: the single biggest frustration, named by two-thirds of them, is AI code that’s almost right but not quite, and nearly 40% say reviewing it takes more effort than reviewing a colleague’s work. More speed at the keyboard doesn’t add up to faster delivery when the work stalls in review. That’s the new failure point, and it lands on the review and QA stages that were never staffed to handle the volume.

The talent pipeline started eating itself

Junior engineers used to learn the craft on exactly the work AI now does: the small tickets, the boilerplate, the simple bug fixes. That was the apprenticeship.

Senior engineers who used to mentor juniors through code review now spend that time reviewing the AI’s code instead, which has quietly changed what pair programming actually means now, while the junior waits to be told whether to accept it. The rung of the ladder people used to climb is missing, and entry-level tech hiring has already dropped sharply as companies let AI absorb the work juniors used to learn on. Most developers have leaned in anyway: in the 2024 Stack Overflow Developer Survey, 62% already used AI tools and 82% used them to write code, even though many doubt the tools on hard problems. Someone still has to know when the AI is wrong. The honest truth about vibe coding is that it only works if you’ve been coding long enough to spot the mistake. We’re automating away the years that teach people how to spot it.

Now everyone thinks they can do everyone else’s job

The old process at least had clear lanes. A product manager decided what to build. A product designer or user experience (UX) person decided how it should look and feel. The developers built it. Three roles, three kinds of expertise, and people mostly stayed in their own lane.

AI blurred all three lines at once. A product manager opens an AI tool, describes a feature, and watches working code come out the other end, so now a developer feels optional for the small stuff. Designers prototype a whole flow and wire up something clickable without filing a single ticket. And the developers themselves use AI to mock up the interface and draft the product spec they used to wait around for. Everyone can suddenly do a passable version of everyone else’s job.

The catch is that passable is not expert. AI really is good at the basic version of all three jobs, good enough that the first draft looks finished. So people take that first draft and ship it. It’s like having an eager intern who hands you exactly what you asked for, instantly, with total confidence. The output looks right. What’s missing is the experienced person who looks at it and knows it’s shallow, or wrong, or solving a problem nobody actually has.

This is the part I find fascinating to watch. The productivity tools turned everyone into a generalist before anyone worked out what the new specialties should be. Nobody has the new process figured out yet, including me. We’re all going to spend the next few years sorting out what the right software development process looks like in a world where AI can do a B-minus version of every role. The teams that treat that as a real question, instead of pretending the intern’s first draft is good enough, are the ones who’ll land on the answer first.

Product thinking is the whole job now

Strip out every stage that AI now handles and look at what’s left. What’s left is the work that requires judgment, taste, customer empathy, and the willingness to say “we shouldn’t build this.”

The problem in most software organizations was never code quality or technical skill. It was product thinking. This is the argument I make in my book, Product Driven: the bottleneck has never been whether your team can build the thing, it’s whether they know which thing is worth building. The hard part of software development isn’t writing the code. It’s understanding the problem you’re trying to solve.

For most of the last decade you could ignore that argument. You could keep a team busy on tickets, ship features that didn’t matter, and call it engineering. The backlog gave you cover. That cover is gone. The engineers worth hiring now are the ones who can sit in a planning meeting and ask whether the team is solving the right problem at all. That skill was always valuable. Now it’s the price of entry.

AMC Theatres is the clearest example I’ve seen of a leader getting this right. Their CIO, Derrick Leggett, built a global engineering organization where the developers are treated as full AMC engineers rather than contractors waiting for tickets. His take on AI is blunt: “People who don’t adopt AI and learn how to use it are going to be working at 30%, 50%, 80% of what the person sitting next to them is.” The teams winning right now treat their engineers as people who own outcomes, then hand them the tools to move fast.

Pure coders will be replaced by AI. Problem solvers will run technology organizations.

How to rebuild your process around product thinking

You don’t fix this with another process. You fix it by pointing the process at a different job, in a few concrete ways.

Start by killing the backlog. Delete the whole thing. If something in there actually mattered, you’ll hear about it again, because real bugs get reported again and real customer needs get raised again. The rest was junk you were never going to do. Deleting it forces the conversation you’ve been avoiding about what’s actually worth building.

Then staff review like it’s the constraint, because it is. The team’s senior judgment now lives in the review, not the keyboard. Protect that time, and stop measuring people on how much code they produce when producing code is the easy part.

Put your engineers back in front of customers. The reason most teams build the wrong thing is that the people building it never see who they’re building it for. Done isn’t when the code ships. It’s when the customer sees value. Measure outcomes, not output.

And when you hire, screen for product thinking. AI already handles the typing, so the people you put on the team matter more than ever. At Full Scale, the engineers our clients value most aren’t the fastest builders, they’re the ones who push back when a requirement is wrong and ask who the feature is even for. Whether you’re building an in-house team or augmenting it with offshore developers, screen for the judgment AI can’t replace. If you’re trying to hire developers who think like owners, that’s the bar now, and it’s a higher one than “can write clean code.”

If you want a framework for all of that, it’s what I wrote Product Driven to be. The book breaks product thinking into five things a team needs more than it needs another process:

• Vision: everyone can see why the work matters, so they make good calls when you’re not in the room.
• Focus: the team guards its attention and says no to the wrong things, including your own pet ideas.
• Clarity: product, scope, and technical clarity practiced every day, not handed down once in a spec.
• Ownership: engineers own outcomes, built on trust and safety instead of accountability pressure.
• Courage: people feel safe to speak up, push back, and ask why before the code ever gets written.

None of those five come from a new tool or a new ritual. They come from people who think like owners, which is the exact muscle AI now makes non-negotiable. If you want the full playbook, you can grab a free copy of Product Driven.

The old software development process optimized for the wrong bottleneck for twenty years and got away with it because the bottleneck was real. AI removed it. The teams that build the product-thinking muscle right now are going to win the next decade. The teams that don’t will look back in a year wondering why their AI-cleared backlog produced nothing anyone wanted.

Software development is back. The companies that remember what that ever meant are going to win.