PERSPECTIVES — 02 · AI-ACCELERATED DEVELOPMENT
Why AI Acceleration Breaks at the Team Level
One developer with AI is fast. A team with AI is a coordination problem.
By Chip Wilson, Michael Mayrell, and Chris Byler, with Erik Parr · geniant
“Claude is so much better at doing the refinement. If I was on a team and they were still doing refinement in a meeting, that would be one of my big questions: what value are you getting out of that now?”
Michael Mayrell
The Challenge
The tooling holds up fine. Coordination is what breaks.
A client recently put a sharp question to us. You say you are experts at AI-accelerated development. What we keep seeing everywhere else is that it works for one person, then falls apart the moment a team is involved. Adoption stalls, developers push back, and the acceleration everyone was promised never shows up. So how do you actually do it with a team?
It is a fair challenge, and the honest answer is that most of the difficulty was never about the AI. A single developer with a good model and a good harness gets fast almost immediately. The hard part starts when four or five people point that same speed at the same codebase. A handful of practices are what actually hold a team together once AI enters the picture.
Shared Enablement
Get everyone to the same level of AI enablement
The most common failure we see is a team where everyone is using AI differently. Two developers are pasting snippets out of ChatGPT, one is on Copilot inside their editor, one is running Claude inside Cursor, and one is deep in an agentic setup with custom skills and commands. Each person is individually more productive, and yet the team gets slower, because the work no longer fits together.
When one developer builds shared skills, commands, and project guidelines that teach the AI how the codebase works, most of the team cannot use them. The gains stay locked to one person. Standardizing is not the goal for its own sake. The point is giving the whole team access to the same shared context, so no one has to negotiate with the AI alone.
The Constitution
Give every agent the same constitution
Before any agent writes code, it needs the same ground rules everyone else is working from. We think of this as a constitution: one shared reference that defines naming conventions, interaction patterns, and what “done” actually means. It can live as a skill, as an MCP server, or as a simple set of project files. The format matters less than the fact that every agent reads from it.
The point is to set hard guidelines up front rather than letting each agent infer the patterns and hope it does not miss something. AI is good at reading a codebase and following what it finds. It is far more reliable when it does not have to guess.
Orchestration
Orchestrate the backlog before you accelerate
This is the part that does the most work, and the part most teams skip. If you hand a raw backlog to a group of agents and tell them to get started, you get a mess. Two agents build the same function. Two people style the same screen. The collisions happen because nobody mapped how the pieces connect.
The fix starts with architecture: build a strong separation of concerns into the solution itself, microservices being one common way to do that, then delegate each piece of work with a real contract, explicit inputs and outputs, not vague instructions. Once that separation exists, agentic task management takes over: order the tasks, build a real dependency graph, and let agents work through it in waves. Everything independent runs together. Everything with a dependency waits its turn. That sequencing, not the raw backlog, is what actually produces team-level acceleration. It is also living work, not a one-time setup: as each story completes, the plan has to be checked again for dependencies that only became clear once the code existed.
Architecture
Draw hard boundaries, and let the boundaries carry the context
As teams grow, the way you keep agents out of each other's way is architecture. Backend business logic, the core engine, and front-end aesthetics need real separation, built into the structure rather than assumed. One of the clearest examples came up secondhand in conversation: a large company bringing together 10 to 15 legacy systems split the work into a strict front-end/back-end separation, then hosted that separation as literal infrastructure rather than a diagram. Each layer runs its own MCP server exposing its documentation, its contracts, and its current state, so any agent on any sub-team can query what it needs instead of a human relaying it.
The front-end team even inverted the usual flow: designers work in a prototyping tool, and the prototype itself is the requirements document, changes committed there are read directly as what needs to be built, with tickets generated automatically as developers pick up the work. By the account we heard, that company went from no version of this system to a fully running one in about a month, and shipped more in the following three months than a comparable team would typically manage in two to four years.
The same pattern shows up in miniature with design systems. Shadcn, the popular component library, now ships its own MCP server, so an agent working against it can just ask the design system directly how a component works instead of guessing from the codebase. Boundaries stop being a diagram on a wall and start being something the AI can actually query.
Review at Scale
Rebuild the review pipeline for the volume AI creates
AI changes how much code arrives for review just as much as it changes how code gets written. As Chip Wilson put it: “PRs have to have a defined scope that's reviewable by a human. With all of these people using AI and all these agents running at the same time, PR review becomes the thing that slows us down the most.” When a developer can have three pull requests out in a day, the bottleneck moves squarely onto human review, and it moves fast. Review starts taking longer than the build.
Two things help. First, risk-gating: let an automated reviewer clear the genuinely low-risk changes, the kind with low odds of a merge conflict or a real failure, so humans spend their attention where it matters. Second, engineer the review itself so it surfaces meaningful problems instead of burying developers in cosmetic notes. A review that flags a real break is worth reading. A review that suggests a more readable variable name, and then forces a human round-trip to apply it, just stalls the team. That kind of feedback is better logged as technical debt to fix later than allowed to block a merge.
“You have items that are analyzed in a bubble, and items that are analyzed in the forest. You analyze the trees and the forest.”
Chris Byler
Where the Human Fits
The human job moves up, not out
The most interesting shift is what happens to the people. In the old rhythm, a team spent hours in refinement meetings hunting for dependencies, checking what already existed, and trying to catch every exception case. AI is genuinely better at that mechanical work, a point Michael Mayrell put sharply above: once the AI is doing the refinement, a standing meeting for it stops earning its place on the calendar.
What it cannot do is decide what the business actually needs, or carry the alignment from leadership down into the work. That is where human judgment now earns its keep. The role does not disappear so much as move up the stack, from managing the mechanics to owning the intent.
The Economics
The math has to be part of the pitch
None of this is free, and pretending otherwise undersells it. Running an AI coding agent around the clock costs real money, more than most teams initially budget for. The comparison that actually matters is one AI-accelerated developer against a team of five, not AI against no AI. A developer costing an extra couple thousand dollars a month in model spend who is now doing the work of ten is, by a wide margin, the best deal a business will make, even though that line item on its own can make a finance team blink.
Bring the spend question into the client conversation early. Skip that conversation, and the client just discovers the cost later, usually after they have already built their expectations around acceleration being free.
The Takeaway
Acceleration at the team level is an operating model, not a license
At the individual level, the tools deliver acceleration almost for free. At the team level, it is an operating model: shared enablement, a common constitution, orchestrated dependencies, hard boundaries, a review pipeline built for volume, people focused on intent rather than mechanics, and an honest conversation about what it costs. That is the difference between a team that says it does AI-accelerated development and one that actually gets faster when the team grows.