Building an AI Transformation Roadmap for Engineering
Anyone asked to produce an AI transformation roadmap for an engineering organization runs into the same contradiction. A roadmap wants phases: do this, then that, then the other. But the three layers of an AI-native transformation, technology, process, and organization, cannot be sequenced. Move one alone and it snaps back.
So the roadmap cannot be a phased rollout of layers. What it can be is a series of horizons, each one narrow in scope, each one moving all three layers together, and each one required to prove something specific before the next begins. What widens across horizons is the blast radius, not the layer count.
Horizon 1 (0 to 90 days): one stream, all three layers
Pick a single real stream. Not a sandbox, not an internal tool nobody depends on, and not the most business-critical system either. Something that ships to real users and whose failure is survivable.
On that stream, change all three layers at once. Technology: the agent and the pipeline it deploys through. Process: specifications precise enough for an agent to build and acceptance a machine can check. Organization: a small senior execution team with one accountable owner of vision and acceptance, and a forward-deployed pair that turns intent into specifications and prototypes.
What this horizon must prove: that a specified, gated change reaches production reliably, and that the idea-to-production clock, not the commit-to-production clock, actually shortened. Instrument both from day one, because the first will go elite quickly and mean very little.
What kills it: running a tools pilot and calling it Horizon 1. A tools pilot with the old process and the old team shape is the failure mode with a project code name.
Horizon 2 (3 to 9 months): make it repeatable, then transfer it
The second horizon is not “roll it out.” It is turning what one team learned into something a second and third team can adopt without the original people in the room.
That means the working setup moves out of one team’s habits and into the shared environment: the specification format, the gates, the pipeline configuration, the prompt and agent scaffolding, all of it as artifacts rather than folklore. Everything as Code is the discipline that makes this transferable rather than a story people tell.
At the same time, start the measurement layer properly. Keep your existing scorecard as guardrails, and read it correctly: deployment frequency and lead time will look elite by construction, so manage to accepted-work throughput, the idea-to-production clock, and quality at the gates instead.
What this horizon must prove: a second team reaches the first team’s outcomes materially faster than the first team did. If team two takes as long as team one, you have not built anything transferable and Horizon 3 will not work.
What kills it: declaring victory from Horizon 1 and reorganizing the whole department. You will be reorganizing around practices that only exist in a handful of people’s heads.
Horizon 3 (9 to 18 months): the constraint moves, and the roadmap follows it
If the first two horizons worked, engineering stops being the binding constraint, and the roadmap has to change target. The pace is now set by how fast the business can decide what it wants and accept what it gets.
That has concrete consequences. Staffing stops being “how many engineers” and becomes a question of matching capacity to how fast the client side can specify and accept. Governance shifts from tracking effort to tracking accepted value. And the economics finally show up as a choice rather than a hope: at held quality, you take the gain as more scope, less cost, or faster delivery, and someone has to decide which.
What this horizon must prove: that the organization can pick one of those three and actually collect it. Plenty of transformations reach real capacity gains and then spend them on nothing in particular.
What kills it: measuring engineering productivity harder while the actual queue sits upstream in decision-making.
What does not belong on the roadmap
A department-wide survey of current process. It looks like diligence and produces a tidy restatement of what people are supposed to do, not what they actually do. Start from one real workplace instead.
A tools-first phase. Tools are an input to every horizon, not a stage of their own.
A reorganization as the finale. If organizational change is only ever the last item, it never happens, because by the time you reach it the program has already been judged.
Velocity as the success metric. Once the agent writes the code, counting human output measures the wrong actor, and it will tell you nothing changed.
The honest part
The gating factor is not model capability. It is how fast people learn to direct this well: to specify precisely, to delegate, and to validate. That is a skills problem, and skills develop on a human timetable no roadmap can compress.
Which is why the horizons above are defined by what they prove rather than by what they install. A transformation roadmap that lists deployments will be finished on schedule and change nothing. One that lists proofs will take longer to write and will actually tell you where you are.
Written by Pavel Khodalev, author of RACE Programming and CTO of First Line Software. Follow new essays via RSS.