Over the past several weeks, four of the CTOs I've been coaching have asked me the same question: “Why can't I get the rest of my team to ship as fast as I am?”

The seats are bought. The Slack channel is set up. The prompts are shared. And the team is… basically working the way they did six months ago. Meanwhile, these CTOs are pushing thousands of lines of code themselves, every week, on their side projects.

My friend and colleague Bruno Bergher (co-author on this piece) is on the founding team at Roomote, an agentic coding startup where every person on the team ships 10+ PRs per day, regardless of technical background. 100% of PRs are agent-generated. No one's written code by hand in 2026.

Between us, we've worked with dozens of leaders over the past few months, all flummoxed by the same challenge. Agentic coding works mind-blowingly well in single-player mode — one person, a fresh project, no legacy code, no stakeholders. That's what lights you up in your side project at 11pm – it’s greenfield

But the conditions most teams work in are the opposite: a product team with a bold roadmap, a real codebase carrying years of decisions, a QA process made for human pace, customers in production with bugs and demands – the brownfield. 

So how do you make multi-player mode as fast as single-player mode?

Most leaders treat AI adoption as a tooling or training problem. Try this new agent. Swap models. Lunch-and-learn. "Team, here are some prompts that worked for me." Watch the token burn leaderboard. Maybe hire someone with "AI" in the title.

It fizzles. You're optimizing existing tasks and processes — the game-changing AI-driven boosts don’t come in incremental optimization. They come in doing things wildly differently.

The most fundamental shift in the AI era is that coding is no longer the bottleneck for growth. For twenty years, everything we came up with in product development — waterfall, agile, sprint planning, PRDs, story points, code review queues, low-fidelity prototypes, design handoffs — stemmed from the (then correct) assumption that coding was the expensive part. That assumption is dying. You feel it every night when an agent ships in 30 minutes what would have taken your team days.

But your codebase, your review process, your backlog, your PRD template — heck, your entire org chart — none of those have caught up. You’re trying to teleport from an airport – and why the hell is that guy in frame 2 packing luggage? When you can return home instantly, you don’t need to pack anything. That’s you and your team trying to use AI and work the same way you always have.

Across the teams we work with, four impediments slow adoption:

Let’s take them one at a time.

Agents need context and breadth, but codebases and architectures have historically been designed with human cognition as a key constraint. This leads to:

In a context like that, the agent guesses wrong and builds something weird. Engineers roll their eyes — see, it's all hype — and go back to writing code by hand. Faith dies on the first bad diff, and aversion rises when AI slop takes production down.

While codebases were designed for the scarcity of human RAM, processes were designed with the belief that code is scarce and expensive to write. Agents flip that.

When coding accelerates:

Systems designed to protect quality at human velocity prevent the acceleration AI could unlock.

Software was hard, so humans specialized. But AI rewards breadth and ambition: a backend engineer who can also build UI, a PM who reviews and tweaks working software, a designer who builds directly from the code. Your narrow org chart punishes that breadth. People who color outside the lines get subtle (and sometimes not-so-subtle) slaps on the wrist.

Most people don't notice this, and nobody wants to name if they do. Agentic coding requires constant mistakes on two fronts:

But engineers have tied their professional reputation to shipping clean code and finding bugs in everyone else's. Now you're asking them to merge half their PRs and throw the rest away. To ship something that might be wrong, on purpose, for learning. Their nervous system reads that as a threat — because at the level of identity, it is. This is the complete opposite of what learning fast requires.

The senior leaders we help don't face this in the same way. Their job security doesn't hinge on the quality of their individual code, so when they start building at breakneck speed, they don't hit this obstacle — and then wonder why so many of their engineers are resisting the change.

Even if you fix all four, something stranger waits on the other side.

Once code is genuinely cheap, Product can't stay ahead of engineering. Not because Product is slow, but because the old cadence was paced by how long building took. Spec, build, test, learn. PMs had time to flesh out PRDs while engineers built. Cut the build phase by 10–100x and the rhythm collapses. Engineers run out of work mid-sprint and make calls on their own. In an effort to stay caught up, PRDs are rushed and arrive half-baked. Mockups lag the built product.

The teams getting it right aren't trying to ship more code. They're shortening the loop between idea and validated learning. What looks like accelerated delivery quietly crumbles the foundation that teams were built on, and exposes that the real job had always been discovery.

When it works:

At Roomote, we merge around half of all PRs. The unmerged ones are some of the most valuable work that gets done, like trying out how a new feature could work or how a redesigned interface would feel.

The real upstream question is not How do we get our engineers using Claude Code — that's downstream. It's How do we shrink the distance between an insight and a customer telling us we got it right? Without an answer, agentic coding gives you a faster feature factory, not a better product.

The details change from team to team, but the patterns are clear:

The hype focuses on generating faster, but each piece is useless without the others. 

In mid-2026, if your agent isn’t producing good code, it’s your fault, not the agent’s. Which means it’s within your control.

Strong teams invest in test coverage, git pre-commit and pre-push hooks, and clear agent guidance. The best ones make it easy for the agent to run projects locally with relevant seed data, using browser control to verify the end-user experience by actually clicking around like a user would.

Not every PR ships. Some PRs exist to ask a question, spark an exploration, unlock a new idea. This goes way beyond running spikes: you can build fully functional features just to see if they're worth it, or try a new app layout before committing to it. You and your customers will make much better decisions when you see and interact with various possibilities before choosing one. Throwing away the ones that don't work is the point, running more experiments to learn faster. This is harder than it sounds because most engineers have spent their careers being told their output was precious. Now it's the learning their output unlocks that matters.

Because AI makes people so much more versatile, it confuses the heck out of roles. People feel insecure when colleagues step into what used to be their lane.

As a leader, it's not your job to clarify every role — that would be exhausting and futile, since they'll keep changing. Your job is to facilitate the team as you collectively:

What you'll find is that AI agents excel in areas with clear, stable targets and fast, reliable feedback loops. Humans are best suited for the fuzzy, ambiguous work that remains — like deciding what's worth building in the first place.

Expect initial failure and encourage it. Celebrate the experiments that taught you something — especially when they didn't ship. Make it normal, even praiseworthy, to explain what didn't work. Do this as publicly as possible (see Shopify's example).

The ethos matters, and so does a structural shift: focus both initially and regularly on Discovery Goals, not Outcome Goals. Outcomes still matter; we're saying you can't hit the outcome if you don't yet know how to get there.

Goals focus attention. Frame them as Discovery or Learning, and people will experiment more broadly because they're not expecting immediate progress.

Fear not — several studies show that in environments of high uncertainty and complexity, Discovery Goals yield better outcomes than Outcome Goals, with the added benefit of increasing long-term performance. (Like SMART goals or OKRs, Discovery Goals still need to be specific, challenging, and time-bound.)

···

When building is no longer the bottleneck, you can organize around what companies exist to do in the first place: learning. Discovering 

When you can build on your discoveries in a flash and observe users' real reactions, you get faster, richer insights into both questions.

If you recognize your team in any of this, reply to this email. We help teams adopt and adapt to AI.

Thanks to Tal Raviv, Chris Jones, and Hervé Labas for valuable feedback on this piece.