AI Changed Software Development, but Software Development Didn't Change

With AI, we've never produced so much code so quickly. Yet features aren't reaching our customers proportionally faster. Why?

Because code was never the bottleneck. AI has changed the way we work, but the fundamentals of software development haven't moved. And the teams that forgot them are paying for it more than ever.

You're Going to Be Wrong, by Design

Building a bridge is complicated, but the variables are mostly known: there's a right answer, and you can calculate it in advance. Software is more like medicine or biology. It belongs to the complex domain, where there are more unknowns than knowns, including the things we don't know we don't know. The only way to find out is to form hypotheses, experiment, and observe.

In practice, people think they know what they want, but reality says otherwise. A well-known anecdote among product designers illustrates this. In a Sony focus group, participants all said they preferred the new yellow Walkman, which looked more exciting. On the way out, they were offered one to take home… and almost all of them picked the black one. So you're almost certain to fall into one of these three traps:

• The customer says they want something, then changes their mind.
• You misunderstand what they want.
• You get the implementation wrong, or information gets lost in a handoff.

That's normal, and it happens to every team. So rather than trying to avoid it at all costs, let's use it to our advantage: since we're likely to be wrong, what matters is realizing it as fast as possible. The whole game is the speed of the feedback loop.

The longer the cycle between an idea and its release to production, the longer you build on a hypothesis that may be wrong, and the later you learn. So what makes this cycle longer?

What Kills Your Productivity: Waiting

We often believe that going faster means "producing more." Yet if you follow a task from idea to production, you'll see it spends the vast majority of its life waiting: for clarification, a code review, QA, an approval, a deployment.

This is called flow efficiency. Flow efficiency is the share of a task's total lead time during which someone is actively working on it. According to Kanban University, teams that don't pay attention to it typically hover around 15%, while flow efficiency above 40% is considered good. In other words, a typical task spends about 85% of its life waiting.

It's counterintuitive, but it's great news. If a task spends 2 days in active work and 10 days waiting, making the developer twice as fast saves one day. Cutting the waiting in half saves five.

Every handoff adds a queue, and every queue adds delay, context switching, and a risk of losing information. So the biggest gains aren't in each individual's speed, but in the time between individuals.

AI Is an Amplifier… Including of Your Wait Times

AI has drastically lowered the cost of producing code, a prototype, or a spec. POs, QA, and designers are getting closer to the code, and developers are becoming more product-minded. That's a real change.

But when something gets cheaper, we do more of it. When the internet made finding information almost free, we didn't just run the same searches faster: we started searching far more often. It's the same with code. And if producing code wasn't the bottleneck, we're only piling more work in front of the real one. That's Eliyahu Goldratt's theory of constraints: optimizing a step that isn't the constraint doesn't speed up the system. It increases inventory.

With AI, the coding step has shrunk, so the bottleneck has shifted to review and QA. We produce more pull requests, often bigger ones, and they pile up in front of the same humans. Even Anthropic, studying how its own teams work, found that Claude spends about 80% of its time waiting for human input. Today, the scarce resource is human attention.

That's why AI acts as an amplifier of your existing system, which is also the main finding of the 2025 DORA report on AI-assisted software development. If your teams ship in small batches that are easy to review, they'll speed up. If they lean toward large pull requests and multiple approvals… AI will amplify that too. Producing a large pull request has never been easier, but reviewing one costs as much as ever.

Back to the Fundamentals

Some principles were true yesterday, are true today, and will still be true tomorrow. AI doesn't make them obsolete: it makes them pay off more than ever.

But be careful about what you're trying to speed up. Do you want to ship features faster, or win customers? Shipping more features isn't a goal in itself, and your customers can see right through the half-finished ones. Going fast means getting to market before others, learning what really creates value, and keeping that cycle fast over time. Speed was the only real competitive advantage yesterday, and it will be tomorrow too.

Work in Small Batches

Just because you can generate a pull request in one shot doesn't mean you should. One pull request, one intent: for example, separate the refactoring from the feature, and slice the feature into shippable increments. A small batch is quick to review, easy to test, and low-risk to deploy.

A large pull request only adds inventory in front of review: it waits longer, gets reviewed less thoroughly, and delays everything after it. It's also a matter of respect. A large pull request is easy for you to produce, but your colleague inherits a long, costly, and frankly painful review. A simple rule helps keep everyone accountable: you land it, you own it. If you send a 2,000-line pull request and it causes an incident, you're the one who answers for it, not the reviewer.

Avoid the Perfect Planning Trap

It's never been easier to plan your next 15 features in detail. Yet it's a recipe for failure: requirements will change along the way, you'll change the solution, and all that inventory of specs turns into waste and rework. Think big, but iterate small and fast.

Don't get me wrong: use AI and team discussions to build better specs and validate the design. But do it just in time, for the next small slice of value to deliver, not for all the ones that follow. Bonus: you'll spend less time in refinement meetings, and it's far more useful to discuss a working prototype than a description in a ticket.

Build Quality Into the Whole Process

Quality isn't a step at the end: it's part of how you work. In practice, that means:

• A testable architecture and tests designed up front (shift-left): know in advance what you need to test, then integrate those tests so they run automatically on every change.
• Simple, readable code that explains itself. Even if you didn't write it, you own it.
• A decoupled architecture: less complexity means cheaper changes, and therefore faster iterations.

As a result, code review should focus on risk (how likely is this change to cause a bug or an incident, and what would the impact be?), not on code quality. Quality is built before the pull request.

Eliminate Handoffs and Approvals

Every handoff is a queue. Here are a few ways to reduce them:

• Shift left: know what success looks like, and how it will be monitored in production, before implementing.
• Make the big decisions at the start, not at the end.
• Pair or mob on risky work: review happens continuously, and the pull request no longer waits for anyone.
• Integrate continuously (trunk-based development) and decouple deployment from release with feature flags.
• Invest in the ability to detect and fix issues fast (rollback, hotfix, monitoring, self-healing) rather than adding one more approval.
• When a bug slips through, ask which guardrail the system was missing, not who made the mistake.

Build the System That Builds the System

AI opens up new ways to automate your continuous delivery: automated reviews, security checks, more thorough QA, and proactive production monitoring. The goal is for every role on the team, not just developers, to contribute to building the product and ship production-ready changes with confidence. To get there, it's worth investing in a development platform that supports your entire delivery cycle. It won't be built in one sprint, but every automated guardrail brings you closer to that vision.

Conclusion

AI changed software development. But software development itself hasn't changed: speed still matters. You win by getting to market, and learning, faster than others. To get there, you have two levers:

• Lower the cost of building: remove complexity and work in small batches.
• Lower the cost of reviewing: automate, reduce risk, build trust, and eliminate waiting.

Which one should you pull first? It depends on where your bottleneck is, and it's not always where you think. Working alongside development teams over the years, we've seen it again and again: everyone felt the work was waiting, but no one could say where. That's why we built value stream mapping into Axify. It shows, stage by stage, how much time your tasks spend in active work and how much time they spend waiting. If your teams have adopted AI, you'll also see whether it reduced those wait times or simply moved them.

So before asking your teams to produce more, ask yourself: where is our work waiting?