AI can write code faster than ever, and the bottleneck was never the coding
What actually slows down teams? Spoiler: it's not the developers.
I just left a project where five senior engineers (all with 10+ years of experience) spent more time fighting processes than writing code.
We had AI coding assistants. We had the skills. We had the stack.
And we still moved slowly.
Here’s what actually went wrong.
The Setup
Five developers. A complex product. Tight deadlines. Everyone was senior. The youngest had slightly less than a decade of experience… and turned out to be the best full-stack engineer on the team.
On paper, this should have been a machine. In practice, it was a mess.
The Real Bottlenecks
1. The Ticketing System Was Broken
Not technically broken, but functionally broken. Tickets were vague. Acceptance criteria was missing or unclear. Scope was undefined.
So what did we do? We wrote our own specs. We did our own research. We broke tickets into subtasks ourselves.
That’s not engineering. That’s project management by committee.
2. Nobody Was Doing Peer Reviews Properly
Code got merged without approvals. Not once — regularly.
When you skip peer review, you’re not moving faster. You’re borrowing time from your future self. That debt came due every sprint in the form of bugs, regressions, and “wait, who changed this?”
3. Team Decisions Got Bypassed
Last-minute changes pushed without the team knowing. Architectural choices made by individuals instead of discussed in the group. People going solo when the whole point of a team is alignment.
This isn’t a skill problem. This is a discipline problem.
4. The Product Owner Wasn’t Doing Their Job
I’ll say it plainly: the product owner didn’t do their job.
No clear priorities. No well-groomed backlog. No proper scoping. The developers became the product managers by default and that’s an expensive substitution.
When your €100+/hour engineers are spending 40% of their time doing PM work, you’re not saving on headcount. You’re wasting your most expensive resource.
What AI Didn’t Fix
We had Copilot. We had AI assistants helping with code generation, refactoring, test writing.
It didn’t matter.
AI can autocomplete a function in seconds. But it can’t:
• Write a clear ticket
• Enforce a review process
• Align a team on priorities
• Hold a product owner accountable
• Stop someone from merging without approval
The bottleneck was never “how fast can we write code.” It was everything upstream and around the code.
What Actually Matters
After weeks of pain, we reorganized. We fixed the processes. We defined clear guidelines. And things got better.
Better tickets — Clear scope, acceptance criteria, subtasks defined before development starts. Not during. Not after.
Enforced reviews — No merge without at least one approval. No exceptions. Branch protection rules exist for a reason.
Team alignment — Weekly syncs that actually addressed blockers instead of status theater. Decisions documented and shared.
Clear ownership — Every feature had one owner. Not “the team.” One person accountable.
A product owner who products — Someone whose job is to make sure the developers are building the right thing, not figuring out what to build.
The Uncomfortable Truth
The tech industry is obsessed with developer productivity. Faster CI. Better tools. AI pair programmers. Shorter feedback loops.
All useful. None of them fix the real problem.
The real problem is that most teams are slow not because their engineers can’t code fast enough, but because the organization around the engineering is broken.
Communication is slow. Context is missing. Decisions are unclear. Ownership is diffused.
You can give a team the best AI tools in the world. If your tickets are garbage and your reviews are optional, you’ll still ship slowly.
Better tickets > better models.
Clear ownership > faster autocomplete.
Team discipline > individual speed.
The bottleneck is never the code. It’s everything around it.
—
I’m Rocco, a software engineer who’s spent 10+ years watching teams struggle with the same problems. I write about what actually works — and what doesn’t — when building software with real teams.
What’s the biggest process failure you’ve seen on a dev team? I’d genuinely like to hear — it helps to know we’re not alone.