.png)
Almost every conversation we have with our clients about AI-driven development starts the same way: a team wants to launch a pilot project. They want to select one team, try it out for one or two sprints, and see how it works. This part of the conversation is straightforward and, by now, well understood. What happens after the successful completion of the pilot project is discussed much less often and, in my experience, is much more complicated.
Because this approach usually does work. A unified team under careful guidance, supervised by a senior staff member, can streamline virtually any process. This isn’t a criticism of this approach; it’s just not conclusive proof of anything. The pilot project proves that AI-driven development can work under careful supervision. But it says almost nothing about whether it will work with fifteen teams that have never met the person who led the pilot project, that are working on different codebases, with different habits, and varying degrees of tolerance for change.
It is precisely in this gap between “it worked for one team” and “it works across the entire organization” that most AI-driven development initiatives quietly fizzle out. Not because the technology fails, but because no one has thought through what is actually required to scale it.
What a pilot doesn't tell you
A pilot project answers a specific question: Does this process allow you to produce acceptable, peer-reviewed code that can be safely deployed to production faster than before? This is truly important and useful information. But it doesn’t answer the question of whether your quality checkpoints are clearly enough documented for a team that wasn’t present during their development. It doesn’t show whether your review system will hold up against a skeptical team lead or tighter deadlines than those the pilot project ever faced. And it won’t tell you how you’ll notice early on, rather than six months down the line, if the team ranked fifteenth on the rollout list quietly starts cutting corners.
These are the very issues that become critical as soon as you move beyond a single team. These are organizational and operational issues, not technical ones, and they must be addressed from the very beginning, not fixed on the fly after the first team runs into difficulties.
Why "just repeat the pilot" doesn't scale
Naturally, there’s a tendency to view implementation as simply repeating the pilot project over and over. In practice, this is exactly where problems arise. The team implementing the pilot project usually has informal and immediate access to the person who developed the process, someone they can turn to if a rule doesn’t quite fit their situation. That kind of access doesn’t scale. By the time you begin rolling out the initiative to the tenth or fifteenth team, most of your process must function without an expert on site, whether you like it or not.
This means that the actual outcome of a mature AI-driven development initiative is not a one-off pilot project, but an entire program: a management system consistent enough to work across teams that have never communicated with one another; support materials that answer the questions a coach would typically address in real time; and a way to simultaneously track, across all these teams, where the process is actually being followed and where it deviates from the norm.
This is particularly evident when implementation takes place through a partner network rather than within a single organization, when the participating teams do not share a common leader, codebase, or even a company, but share only the process itself. Under such conditions, there is no room for “tribal knowledge” to fall back on. Everything that was informally overlooked in the pilot project must be clearly defined before it can be passed on to the second team, let alone the twentieth.
What we've learned running this at scale
We have already applied this approach during workshops with engineering teams across a wide range of industries: corporate software, financial services, and, most recently, construction, and one pattern remains consistent regardless of the industry: the questions that arise during discussions are never actually about AI. They concern who decides what to release to the market, whether speed comes at the expense of quality. Once a pilot project succeeds, how do you scale it from one team to many without letting it quietly morph into something else along the way?
It is this last question that we are currently devoting the most time to. Not because it’s the most exciting part of the conversation, but because it’s the part that people usually don’t think about when they come to a meeting. This part determines whether an AI-based development becomes part of an organization’s workflow or remains a promising pilot project that never makes it beyond the single team that implemented it.
If you’ve already moved past the pilot project stage and are starting to think about what it takes to properly implement this technology, whether across ten teams or within a partner network comprising dozens of participants, I’d be happy to share my thoughts on what’s truly required to make it happen.
.svg)
