AI solved coding. Turns out coding was never the real problem.

A few years ago, writing code felt like the core of software development. Now it often feels like the fastest part.

I can sketch an idea, use AI to generate a working version, refine it, and get something functional in minutes. Things that used to take hours — sometimes days — are suddenly trivial.

And yet… shipping still feels slow. Not because of coding. Because of everything around it.

Coding is no longer the bottleneck

With modern AI tools, a lot of the heavy lifting in development has changed:

The gap between idea → working code has shrunk dramatically. For many tasks, the limiting factor is no longer "can I implement this?" but rather "what happens after I implement this?" And that's where things start to feel slow.

The real bottlenecks were never addressed

While coding sped up, the surrounding system didn't. The same friction points still exist — but now they're more visible than ever.

🚧 Pipelines

You finish a feature in 15 minutes. Then you wait.

  • CI runs for 10–20 minutes
  • Builds fail for unrelated reasons
  • You re-run, re-wait, re-check

🧪 Testing

We can generate code quickly. But verifying it?

  • Manual testing still takes time
  • Automated tests are slow or brittle
  • Coverage is unclear

You can produce more code than your system can confidently validate.

👀 Code reviews

Pull requests are created faster than ever. But reviews?

  • Reviewers are overloaded
  • Feedback loops are slow
  • Context switching kills momentum

It's not unusual for a PR to sit longer than it took to build the feature.

🗂️ Backlog and planning

This is the one that often gets ignored.

  • Tickets are outdated or unclear
  • Backlogs grow endlessly
  • Refinement meetings drag on

AI increases idea generation. But if decision-making doesn't scale with it, the backlog turns into noise.

We optimized execution — but not flow

For years, we focused on writing better code: cleaner abstractions, better architectures, more efficient implementations. That made sense — because coding was the bottleneck.

But now the bottleneck has shifted. The real problem isn't how fast we write code. It's how smoothly work flows through the system.

AI didn't create new problems. It made existing ones impossible to ignore.

When coding was slow, inefficiencies elsewhere were hidden. Now they stand out: waiting becomes visible, delays feel disproportionate, friction becomes frustrating. You generate something in minutes… and then spend hours getting it through the system.

What this forces teams to do differently

Faster pipelines

If development speeds up, feedback loops must follow — shorter CI cycles, more reliable builds.

Smarter testing strategies

Not just "more tests", but faster feedback and clearer confidence in changes.

Faster decision-making

Fewer synchronous meetings, more async collaboration, clearer ownership of decisions. Because if coding becomes cheap — deciding what to build becomes expensive.

The new bottleneck: clarity

One area where this becomes very obvious is backlog management. If generating features becomes trivial, then:

You don't struggle with implementation. You struggle with decision-making.

What the best teams will do differently

The teams that benefit most from AI won't just write code faster. They will reduce unnecessary meetings, streamline decision processes, and shorten feedback loops everywhere. They'll treat their development process as a system to optimize — not just their code.

Final thought

AI didn't make development simple. It made inefficiencies visible. And that's a good thing — because now we can finally see where the real problems are: not in writing code, but in everything that happens before and after.

One lever I see to speed up the overall process is improving how we handle backlog refinement. If generating features becomes easier, then deciding what actually matters needs to become faster too.

Instead of long, synchronous meetings, there's a lot of potential in shifting parts of refinement into asynchronous preparation: letting team members review tickets in small time slots, gathering signals early, and focusing discussions only where they're really needed.