Six months in, the conversation moves beyond seat activation.
| Stage | Observation | Key Insight |
|---|---|---|
| Six Months In | The adoption dashboard still glows green. | Visible adoption is not the same as impact. |
| The Hard Question | Are delivery outcomes actually moving? | The answer requires delivery metrics. |
| The Stall Signal | Tool usage rises faster than throughput. | Activity and outcomes can decouple. |
| The Missing Work | Role enablement, validation flow, and outcome metrics. | Sustainment is a program, not an event. |
The six-month review arrives without fanfare in most engineering organizations. There was a launch meeting, a kickoff deck, an all-hands announcement. There was a ninety-day check-in that confirmed seat activation was on track. Then, somewhere around month six, a senior leader pulls the full picture together — adoption metrics alongside delivery metrics — and the conversation changes tone.
The adoption side of the room is easy. Usage hours are up. Acceptance rates have stabilized. The seat-utilization dashboard that was shared so proudly at the initial all-hands still shows green. These are the numbers that went into the quarterly board update.
The delivery side is harder. Lead time for changes: roughly where it was before the rollout. Deployment frequency: minimal movement. Change failure rate: actually, slightly elevated in some teams, though causality is unclear. The CFO’s question from month two — where, exactly, is the productivity gain showing up in the delivery numbers? — still does not have a clean answer.
In the field, this is the pattern I see most consistently. Not a failure of individual productivity — the per-developer gains from AI are real and the data from Faros, DX, and METR has established that clearly across this series. The gap is between individual productivity and organizational delivery, and it does not close automatically. It closes when organizations do the Phase Two work. Most rollout plans never fund Phase Two.
Article 01 of this series opened with the same question framed as a paradox: more code written, more pull requests merged, but deployment frequency and lead time unchanged. Faros AI’s telemetry across ten thousand developers gave the mechanism — pull request review time up ninety-one percent, context switching up forty-seven percent, PRs themselves one hundred fifty-four percent larger. The individual gains were real. The system downstream of them was absorbing the gains faster than they could reach a delivery metric.
Articles 02 and 03 traced that dynamic to two root causes: the roles closest to the bottleneck were not enabled, and the measurement systems were tracking the wrong tier of signal. Article 04 is about what happens when both of those problems have been recognized and the organization is six months into a rollout — and momentum is stalling anyway. Not because the diagnosis was wrong. Because most rollout plans end at deployment. They do not plan for what sustains.
Phase One is what most organizations fund: procurement, licensing, onboarding sessions, a Slack channel, a PDF guide, a ninety-day adoption target. Phase One ends when the dashboard turns green. Phase Two — the work that actually determines whether Phase One’s adoption translates into delivery impact — is slower, cross-functional, and rarely budgeted in the original business case. It requires answering questions that the adoption dashboard was not built to surface.
What the ninety-day mark signals
Article 03 closed with a tease: Article 04 would examine what happens at the ninety-day mark. The answer, from the data, is this: ninety days is not when rollouts fail. It is when the pattern that will determine their outcome becomes visible — if you are looking at the right signals.
A 2025 paired-interview study of fifty-four developers across twenty-seven teams (arXiv 2507.21280) is the most precise analysis of why AI tool adoption diverges within the same organization. The researchers matched one frequent and one infrequent AI user from each team, ensuring identical structural context: same codebase, same manager, same organizational policies. Same tools. Same rollout. Different outcomes.
The divergence came from three factors: how developers perceived the tool, how they approached integration, and how they responded when they hit challenges. Frequent users perceived AI as a collaborative partner. They adopted a continuous, experimental approach — trying things, iterating, adjusting. When the tool produced wrong output or an unfamiliar workflow, they worked through the problem adaptively, building more sophisticated usage over time. Infrequent users perceived AI as a feature — one option among many in the IDE. They used it for bounded tasks, integrated it conservatively, and when they hit friction — a hallucinated suggestion, a mismatch with their workflow, output that needed as much correction as writing from scratch — they abandoned the tool and returned to what they knew. The friction became a conclusion rather than a problem to solve.
By ninety days, these patterns had calcified. The frequent users had built habits that compounded. The infrequent users had formed beliefs that did not.
The researchers named the organizational dynamic that produces this split: the Productivity Pressure Paradox. When organizations signal urgency around AI productivity without investing in learning support — without giving infrequent users a structured path through early friction — they create the conditions that prevent the gains they are pressing for. The pressure produces exactly the quick-abandonment response that stalls adoption beneath the surface.
Ninety days is when you can first tell whether the adoption pattern will compound or plateau. Most organizations are looking at seat utilization. That number cannot see the split.
What surfaces at six months is not a single failure mode, but three patterns that reinforce one another.
What surfaces at six months is not a single failure mode, but three patterns that often reinforce one another.
Key Indicators
Adoption is necessary for impact, but it is not sufficient when usage patterns diverge from delivery outcomes.
Diagnostic focus: usage by role and seniority band.
Key Indicators
More generated work enters review, testing, integration, and recovery queues than downstream processes can absorb.
Diagnostic focus: where AI-generated work queues.
Key Indicators
The same AI tool can improve or degrade outcomes depending on the quality of the learning and support system surrounding it.
Diagnostic focus: enablement structure, not attendance volume.
The first is the adoption plateau
DX’s 2026 analysis across more than four hundred companies found that a sixty-five percent increase in AI tool usage correlated with only an eight percent increase in median pull request throughput. The two metrics, which every rollout plan treats as directly connected, are nearly decoupled in practice. Adoption is a necessary condition for impact. It is not sufficient. And the infrequent users described by arXiv 2507.21280 — the ones who have formed conclusions rather than built habits — are the mechanism. They count as active license holders on the adoption dashboard while extracting a fraction of the available value.
The second pattern is the validation accumulation. CircleCI’s 2026 State of Software Delivery report, analyzing twenty-eight million CI workflows across twenty-two thousand organizations, found that average workflow throughput increased fifty-nine percent year over year — the largest single-year increase in the report’s history. But the distribution of that increase is what matters. The top five percent of teams nearly doubled their throughput. The median team grew just four percent. Critically, the median team’s main-branch activity — the code that actually reaches customers — declined seven percent. Success rates across the dataset hit a five-year low. Recovery times were climbing.
CircleCI’s conclusion connects directly to Article 02’s argument: the bottleneck is no longer the speed at which developers write code. It is the ability to validate, integrate, and recover at scale. The Faros finding that Article 01 introduced — PR review time up ninety-one percent, PRs themselves one hundred fifty-four percent larger — is the downstream expression of exactly this constraint. More code entering the review queue, harder to review, more likely to contain errors that escape into production. The system that was sized for pre-AI commit volumes is now the binding constraint. Article 02 argued that enabling only developers while leaving QA, security, and platform teams unchanged is what creates this constraint. The CircleCI data is what that argument looks like at organizational scale, measured across twenty-two thousand teams.
The third pattern is the learning debt. DX’s Q4 2025 structured enablement research measured what happens when AI tools are deployed without formal learning programs, and the direction of outcomes is not neutral. Organizations with structured enablement saw code maintainability improve eight percent, change confidence improve ten-point-six percent, engagement improve seven-point-four percent. Organizations without it saw knowledge gaps increase sixteen percent and time loss increase eighteen percent. The tool was the same in both cases. The investment in how people learn to use it determined which direction the outcomes moved. Phase One makes adoption visible. Phase Two makes delivery impact durable.
| Phase One: Deployment | The Gap: Impact Risk | Phase Two: Sustainment |
|---|---|---|
| Procurement and Licensing | Delivery metrics remain flat | Usage audit by role |
| Onboarding Sessions | Validation queues grow | Role-specific enablement |
| Adoption Target Met | High-leverage roles remain under-enabled | AI value stream mapping |
These three patterns are not independent. The adoption plateau creates a visible-but-hollow adoption metric. The validation accumulation creates a downstream queue that grows faster than the system can clear. The learning debt means that the organizations that did not invest early are falling further behind, not holding steady. Each pattern compounds the others.
The DX data on seniority is the most pointed expression of this dynamic. Staff-plus engineers — the developers who review code, make architectural decisions, and multiply the throughput of everyone around them — report saving four-point-four hours per week when they use AI daily, the highest figure of any seniority band in DX’s dataset. They also have the lowest adoption rates. The gap between what they would save and what they are currently saving represents the largest pool of uncaptured value in most AI rollout portfolios.
That pool is not being captured because Phase One enablement was not designed for the people who are hardest to pull out of high-leverage work for training sessions, and who are least likely to persist through early friction without a structured learning path. They are also the people whose adoption would most directly unblock the review and architectural bottlenecks that are absorbing the gains from everyone else.
Adoption that does not reach the highest-leverage roles is not a success. It is Phase One performance on a Phase Two problem.
What sustained momentum requires
The top five percent of teams in the CircleCI data did not get there by adopting better AI tools. They got there by building better systems. The distinguishing factor was validation infrastructure — smarter test selection, faster feedback loops, recovery automation that did not require a human to diagnose every failure. The code generation feeding those systems was the same AI tools everyone else had. The system downstream of it was different.
The tool stays the same. What changes outcomes is the learning system that surrounds it.
Organizations that invest in role-specific learning, coaching, and operational support are more likely to translate AI adoption into measurable improvements in work quality and delivery outcomes.
When AI is introduced without ongoing learning support, teams often experience inconsistent usage patterns, growing knowledge gaps, and reductions in realized productivity gains.
Effective enablement extends beyond orientation sessions. It creates repeatable learning mechanisms that help teams build capability over time.
The DX structured enablement research describes the human-side equivalent. A twenty-five percent increase in structured enablement support — actual curriculum, live rollout programs, role-specific guidance — produced improvements across every outcome dimension measured. Not because the tool changed, but because the organizational investment in how people build capability with it changed.
DORA’s 2025 AI Capabilities Model frames the organizational form of this as a specific cultural practice: get better at getting better. Three mechanisms appear in the research. Celebrating progress rather than attainment — setting improvement as the target rather than a fixed bar, so each team has a meaningful goal regardless of starting point, and struggling teams see their progress acknowledged rather than their distance from best performance. Embracing failure as learning infrastructure — creating the sandbox environments, retrospective structures, and cultural norms that allow developers to share what they tried and what failed, without those experiments reflecting negatively on their performance. And building communities of practice that transfer institutional knowledge across team boundaries.
The community of practice is the mechanism most absent from rollout plans, and the one with the clearest theoretical link to the adoption plateau problem. When frequent and infrequent users share only a Slack channel and a PDF, the sophisticated prompt patterns, workflow innovations, and hard-won workarounds that frequent users have developed are not systematically transferred to the people who would benefit most from them. A community of practice — with shared libraries, peer recognition for capability growth, and regular retrospectives on what the tool is producing at the system level — converts isolated individual progress into organizational compound growth.
Structured enablement at organizational scale, built around role-specific learning paths and measurement tied to delivery outcomes rather than training attendance, is exactly the work that separates a Phase One rollout from a Phase Two program. At Accenture LearnVantage, the engineering enablement programs we build are designed around this distinction — starting from the bottleneck, enabling by role, measuring at the seam, and building the practice rituals that make the new way of working durable rather than optional.
This is Article 04 of 05 in the Field Notes on AI Enablement series.
,Article 01, The Bottleneck Just Moved introduced the Theory of Constraints framing.
Article 02, Widening the Circle, examined cross-role enablement.
Article 03, From Activity to Impact, built the measurement framework.
This article, Article 04, named the Phase Two problem: most rollout plans fund deployment and declare success. But the work that sustains momentum (structured enablement, community infrastructure, value stream diagnosis) is not in the business case.
Article 05 will bring the picture together: what the three transformations look like when they are complete, and what an organization that has closed the Phase Two gap actually delivers.
For engineering leaders reading this after six months into a rollout: which of the three stall patterns is the one your organization is running into — the adoption plateau, the validation accumulation, or the learning debt? And which is the one you are best positioned to address first? Reach out to me on LinkedIn: https://www.linkedin.com/in/vijayk-kloudlinq/ I would be genuinely interested to hear where teams are landing.
Sources
Ascendient Learning Offers Live AI and Agentic AI Training
Browse Courses
Building on Part 1 of the "Generative AI Toolkit," where we uncovered the common challenges enterprises face when integrating AI, this installment discusses the solutions and core building blocks that form a robust GenAI strategy.
Your developers arrive in class already using Generative AI tools in their daily coding. But are they using these tools correctly and responsibly?
Ensuring cybersecurity is vital for all businesses online. Learn how to improve your password security with our seven simple tips.
Ascendient Learning is the coming together of three highly respected brands; Accelebrate, ExitCertified, and Web Age Solutions - renowned for their training expertise - to form one company committed to providing excellence in outcomes-based technical training.
With our winning team, we provide a full suite of customizable training to help organizations and teams upskill, reskill, and meet the growing demand for technical development because we believe that when talent meets drive, individuals rise, and businesses thrive.
