BLUF: Most orgs fail at AI adoption because they lack organizational capability, not technology. This post gives you the complete playbook: diagnostic clarity (what to optimize for), guiding principles (how to stay safe), and coherent actions (systematic rollout plan).
Jump to: Diagnosis, Principles, Actions
“Fast forward one year. You have two engineers. One delivered significant impact using AI agents. The other delivered comparable impact without them. How do you assess their performance?”
A leader on my team asked me this. I paused.
Because every answer reveals a different failure mode:
- Reward the AI user? You’re incentivizing tool adoption over impact.
- Reward the non-AI user? You’re disincentivizing innovation.
- Reward both equally? You’ve admitted AI didn’t create leverage.
- Reward neither? You’ve told your team outcomes don’t matter.
This isn’t a performance review question. It’s a systems design question.
78% of organizations use AI in at least one function, yet only 1% call themselves truly AI mature. That gap isn’t a technology problem. It’s a systems problem—we don’t know what to measure, what to reward, or how to make AI productive beyond the pilot.
I’ve spent the past year using coding assistants and talking to engineering leaders across companies of different sizes. The pattern across all is consistent: impressive demos, enthusiastic pilots, then nothing. Projects stall. Security panics. Trust erodes.
The companies getting past this treat AI adoption as a systems problem—not a tooling problem.
The Organizational Capability Gap
Most engineering leaders focus on the wrong blockers.
They obsess over which model to use, which tools to deploy, how to secure their infrastructure. They debate Copilot vs. Cursor. They benchmark token costs. They pilot autonomous agents.
These matter. But they’re not why 78% of companies claim to be “adopting” AI while only 1% reach maturity.
The real blocker is organizational capability.
Your infrastructure might struggle with AI agents operating 24/7, but that’s solvable. Your auth systems might not handle “Alice’s agent acting on Alice’s behalf,” but you can fix that. Your metrics might measure lines of code instead of outcomes, but you can change what you track.
What’s harder: Building an organization where AI amplifies human impact instead of just creating more activity. Where engineers deliver more customer-facing value, not just more code. Where you can answer the performance review question with confidence.
That requires more than technical fixes.
What Successful Organizations Do Differently
It comes down to three dimensions:
Diagnosis — Strategic clarity on where your organization is currently, what problems you’re solving for your users and why
Guiding Principles — How you make AI work safely in production; the constraints, the tradeoffs, the time horizon you’re optimizing for
Coherent Actions — Your systematic rollout plan for your org to accelerate value delivery from pilots to production
Skip diagnosis, and you’ll build impressive demos that don’t move business metrics. Skip principles, and you’ll ship AI that works in pilots but fails catastrophically in production. Skip coherent actions, and you’ll have great plans but no organizational buy-in.
Diagnosis: Where Are We Today → Where Do We Need to Be?
Most organizations skip the hardest question: What does high-performing AI adoption actually look like? And how will we know?
They jump straight to tools—choosing between Copilot vs. Cursor, debating models and prompts. But that’s optimizing the wrong variable.
At Apollo, when we think about high-performing engineering, we evaluate any initiative—AI or otherwise—through the lens of: Precision, Speed, Quality, and Impact (I wrote about this framework in more detail in Debugging Engineering Velocity).
Precision: Are we building the right things? Clarity on what problem we’re solving and why.
Speed: Not just coding speed, but end-to-end delivery velocity—from idea to production, accounting for review time, integration time, and all the downstream costs.
Quality: Production confidence. Code maintainability. How many incidents are we causing? Mean time between failures.
Impact: Are we truly moving the needle on key outcomes for users or the business?
Here’s what we’re seeing at Apollo when we apply this lens to AI adoption:
Speed is up for certain use cases—engineers generating boilerplate, tests, and runbooks faster. 0→1 prototyping for early customer validation is dramatically faster.
Quality is mixed—some AI-generated code is excellent, some requires significant rework. The variance is high.
Impact is flat—when we measure actual features shipped to customers and business outcomes delivered, we’re not seeing meaningful lift yet.
Why the Gap?
We’re optimizing one part of the pipeline without accounting for downstream costs. The 2026 AI Benchmarks (a study of AI-assisted development across 4,800+ organizations, which I discussed in a LinearB roundtable) validated what we’ve been seeing: creating more code faster through AI adoption does not translate to higher value delivery.
AI PRs are 2.5x larger, take 5x longer to be picked up, have 2x lower acceptance rates at 30 days. When reviewers finally look at them, they move fast—but that’s hesitation followed by rubber-stamping, not efficiency. They’re scanning for obvious red flags (Does it compile? Do tests pass?) not evaluating deep design decisions. We are seeing high individual productivity at the expense of high systemic complexity.
This is anti-agile. We spent 20 years drilling agile principles into engineering teams—work in small batches, ship incrementally, get feedback fast, reduce blast radius. Current usage patterns with AI do the opposite, generating hundreds of lines to complete a task instead of thinking in incremental PRs.
Just yesterday, one of my senior engineers had to review a 30K-line PR that clearly felt “vibe coded.” This isn’t theoretical.
And here’s what makes it worse: code becomes a liability, not an asset. You’re not just creating more code faster—you’re creating more code to maintain, more surface area for bugs, more complexity to understand when you get paged at 2am. The real cost isn’t generation time. It’s the downstream maintenance burden.
The Real Question
The real question isn’t “Are we using AI?” It’s “Are we delivering more value?”
Here’s my hot take: the metrics haven’t settled because the workflows haven’t settled. We’re so early in this journey. One part of the pipeline—code generation—is super optimized. But we haven’t figured out the downstream costs in review time, debugging time, maintenance burden, ongoing feature development. The metrics are trailing indicators of workflows we’re still designing.
The answer requires measuring beyond lines of code:
- Precision: Are we building the right things? (Customer value delivered)
- Speed: Lead time for changes? (Idea to production, end-to-end)
- Quality: Change failure rate (Is AI-generated code causing more incidents?)
- Impact: Did this move business metrics we care about?
Diagnosis is about clarity on what you’re optimizing for. Most organizations are optimizing for “AI usage.” The ones getting results are optimizing for end-to-end value delivery.
Guiding Principles: Making AI Work in Production
Diagnostic clarity tells you what to build and why. Principles tell you how not to break things along the way. (I explored the foundational platform principles behind this in Building AI Platforms That Scale Human Agency — the Five Cs below are how those ideas translate to production.)
Most organizations stumble here. Great strategy, right problems identified. But when they deploy AI at scale, things break. Code reviews become bottlenecks. Security teams panic. Incidents multiply. Engineers lose trust.
The Five Cs: Non-Negotiable Principles for Production AI
Clarity. Every AI-generated output needs clarity—why was this code written, what alternatives were considered, what constraints were applied. Without this clarity, reviewers can’t evaluate correctness. This isn’t just good practice. Without it, reviewers are rubber-stamping code they can’t reason about.
Context. Context management is the difference between an AI agent that writes code matching your patterns and one that suggests solutions that violate your architecture.
Engineering talent and habits are not the limiting factors. The LinearB report confirms this: “foundational infrastructure—data quality, tooling, and organizational alignment—has become the new bottleneck to high-performing, AI-ready software delivery.”
If your data is scattered across systems, poorly documented, or hard to access, AI workflows immediately break down. Models hallucinate. Recommendations degrade. Teams lose trust. AI needs access to the right information—your codebase, your docs, your schemas, your historical decisions. But it also needs to understand what information is sensitive, what can be shared, and what must stay private.
Coupling. Loosely coupled systems are easier to evolve with AI. Use vendor abstractions (for LLM APIs, agent SDKs), clear contracts across interfaces, and deterministic guardrails. Design your architecture for graceful degradation—when an AI agent generates incorrect code, the blast radius should be contained, not spread across your entire system. Avoid tight coupling that creates vendor lock-in or cascading failures when AI makes mistakes.
Controls. Guardrails aren’t anti-innovation, they enable experimentation. We’ve found that teams move faster when they have clear boundaries, not when they have unlimited freedom. This means rate limiting on agent actions, scope restrictions on what agents can modify, review requirements before production deployment, explicit ownership clarity and circuit breakers that disable AI when error rates spike.
Confidence. Engineers need confidence that AI is helping, not creating technical debt. Build feedback loops that surface when AI is working and when it’s not. Make it easy to override AI decisions without friction. Confidence comes from transparency, observability, and the ability to understand AI’s reasoning.
Applying the Five Cs in Practice
These aren’t abstract principles—they’re design constraints. When we built Apollo’s Model Context Protocol (MCP) server, every decision filtered through these five: schema-driven APIs that agents can understand (Clarity + Context), secure access to graph topology with proper scoping (Controls), loose integration that doesn’t require wholesale platform adoption (Coupling), and observable agent behavior with full audit trails (Confidence).
Coherent Actions: Rolling Out AI Systematically
You have diagnostic clarity. You understand the principles. Now the hardest part: rolling it out without breaking things or losing trust.
The Five E’s framework is your tactical playbook for moving from pilots to production. Key insight: for every tool, you’ll have early adopters, early majority, and late majority. Your strategy depends on where your organization is on that journey.
The rollout timeline also depends on the size of your organization, the executive sponsorship and buy-in for this change and how change-ready your org collectively is.
1. Experimentation: Let Early Adopters Explore (Weeks 1-4)
This is your discovery phase, driven by the engineers who are already using AI—whether you know it or not.
Cultural principle: If engineers feel like they have to hide their AI usage, you’ve already lost. Shadow AI is inevitable—you can ignore it, fight it, or harness it. Choose to harness it.
What to do:
- Give early adopters a few select tools to experiment with
- Create a shared space where people document what works and what doesn’t
- Map engineering workflows to find high-friction points and AI-ready use cases
- Run “innovation days” for prototyping AI solutions
- Identify where AI creates leverage vs. where it creates overhead
Success looks like: Prioritized use cases ranked by value and feasibility, baseline metrics established, engineers excited to share experiments openly.
2. Evaluation: Building the Business Case (Weeks 5-8)
Now you need to be ruthlessly honest about readiness and ROI.
What to do:
- Assess infrastructure gaps: data quality, API consistency, observability capabilities
- Calculate full cost: tooling costs plus review time, debugging time, maintenance overhead
- Define northstar metrics using Precision-Speed-Quality-Impact framework
- Identify security and compliance requirements
- Build decision framework: what’s allowed, what requires review, what’s prohibited
The uncomfortable truth: Engineering talent isn’t your limiting factor—infrastructure is. If your data is scattered, your APIs are undocumented, or your deployment is manual, AI workflows will break down immediately.
Red flags that mean you’re not ready:
- Undocumented or inconsistent APIs
- No secrets management or access control
- Manual deployment processes
- Code review already a bottleneck
- No baseline engineering metrics
- Unclear data classification or sensitivity policies
Success looks like: Executive buy-in, approved budget, clear go/no-go framework, identified infrastructure investments needed.
3. Education & Enablement: Creating the Foundation (Month 3)
This is where you move from early adopters to early majority. Do not skip Experimentation and Evaluation.
What to do:
- Deploy AI tools to pilot group (10-20% of engineering)
- Run monthly “AI show-and-tells” where engineers demo workflows
- Share rulesets, prompts, successful patterns, and failures
- Educate on where not to use AI (as important as where to use it)
- Build governance: what’s allowed, what requires review, what requires human ownership
- Set up observability for AI workloads
- Create an “AI Runbook”: documented prompts, workflows, anti-patterns
The Tactical Setup
Explicit human sponsors: Every AI-generated PR needs a human owner accountable for merging. No orphaned AI code.
This isn’t just about accountability—it’s about the work of getting code reviewed. When you write code, part of your job is shepherding it through review: the Slack pings, the standup mentions, knowing when to nudge reviewers. AI agents don’t do this soft skills work. Humans must.
Quality gates: Train reviewers to ask:
- “Why this architectural choice?”
- “What edge cases might this miss?”
- “What are you optimizing for?”
- “How would you debug this at 2am?”
Guardrails:
- Reject or flag PRs over 200 lines
- Require decomposition for complex tasks
- Set time-box SLAs for review (review or close, don’t let AI PRs linger)
Success looks like: Pilot teams showing measurable productivity gains, clear best practices documented, engineers excited (not resistant) about AI adoption.
Common pitfalls:
- No training or guidelines
- Treating AI as “set it and forget it”
- Not measuring end-to-end velocity impact
- Allowing AI to become a crutch instead of a tool that raises the bar
4. Expansion: Scaling What Works (Months 4-6)
Scale only what’s proven to work. This is critical—don’t scale experiments, scale validated practices.
What to do:
- Roll out successful tools organization-wide
- Standardize your tooling; one primary tool for common use cases (reduces fragmentation and cognitive overhead)
- Graduate pilots to production with safeguards in place
- Build custom solutions for high-value, company-specific problems
- Create AI “champions” in each team to coach others
- Share wins and failures through regular knowledge-sharing sessions
- Be surgical about where you apply AI
Track metrics beyond lines of code:
- Precision: Are we building the right things? (Feature alignment with customer needs)
- Speed: Lead time for changes—idea to production, end-to-end (Has AI actually reduced this?)
- Quality: Change failure rate (Is AI code causing more incidents?)
- Impact: Did this move business metrics? (Revenue, customer satisfaction, retention)
Success looks like: 80%+ of engineering using AI productively, measurable delivery improvements, declining AI-related incidents over time.
Watch out for:
- Inconsistent quality patterns across teams
- Lost institutional knowledge (engineers who can’t explain the code)
- Fragmented tooling creating support overhead
- Code slop (verbose, poorly structured AI-generated code)
5. Enforcement & Evolution: Making It the New Normal (Ongoing)
Enforcement (lightweight, not bureaucratic):
- Establish team norms for PR size, review quality, ownership accountability
- Time-box review SLAs—review promptly or close
- Require documentation for experimental tools before wider adoption
- Make it easy to do things right, hard to do things wrong (design systems for success)
Evolution (continuous improvement):
- Measure impact quarterly against northstar metrics
- Sunset tools that aren’t delivering value (be willing to kill experiments)
- Invest in advanced capabilities where ROI is proven (fine-tuned models, agent orchestration)
- Build feedback loops from production back into strategy
- Share learnings externally (conference talks, blog posts, open source contributions)
Success looks like: AI is just part of how you build software—not a separate initiative. End-to-end delivery velocity is measurably up, and you’re shipping more value, not just more code.
Pacing Your Rollout: Crawl-Walk-Run
Crawl (Experimentation + Evaluation): Go slow. Understand before committing. Build muscle memory. This phase should feel deliberately slow. That’s correct.
Walk (Education & Enablement): Measured progress with tight feedback loops. Expect surprises and output variance. This is where you learn what actually works in your specific context.
Run (Expansion + Evolution): Move fast on solid foundation. Infrastructure is ready, processes are proven, organization is aligned. You’re not just creating more code—you’re delivering more value.
Don’t try to transform everything at once. Small, proven improvements compound fast when your foundation is solid.
Answering the Hard Question
Remember the question from the beginning? Two engineers, comparable impact, one used AI and one didn’t—how do you assess them?
Here’s what I’ve learned implementing this framework:
You don’t reward tool adoption. You reward impact and capability.
I’ve heard of organizations doing performance reviews based on how often engineers use AI coding tools. That’s exactly the wrong incentive. It optimizes for activity, not outcomes. (I’ve written extensively about how to navigate performance reviews well in Part One and Part Two — the same principles apply here.)
The engineer who used AI effectively should be assessed on:
- Did they deliver more value than they could have without AI?
- Did they elevate their work to solve harder problems?
- Did they use the leverage to take on challenges previously out of reach?
- Are they teaching others to do the same?
The engineer who didn’t use AI should be assessed on:
- Did they deliver the impact your organization needed?
- Are they continuously improving their craft and capability?
- Are they creating leverage in other ways—mentoring, tooling, architecture?
Both can be exceptional performers. Both can be mediocre. The tool isn’t the differentiator. The impact is.
But here’s the deeper question that should make you uncomfortable: If the non-AI engineer is delivering comparable impact in comparable time with comparable quality… what does that tell you about your AI adoption?
It might mean:
- Your AI infrastructure isn’t creating leverage (Diagnosis problem)
- Your AI tools are generating busywork, not capability (Principles problem)
- Your organization isn’t measuring the right things (Execution problem)
The worst outcome isn’t having engineers who don’t use AI. It’s having engineers who use AI extensively but deliver the same impact they would have without it.
That’s expensive theater, not organizational transformation. And amplifying human impact means staying ruthlessly honest about whether AI is actually moving that needle.
What’s Next
AI won’t replace engineers. But it will replace the parts of engineering nobody enjoys—context switching, boilerplate, toil. The interesting question is what engineers do with that freed-up capacity: harder problems, better architecture, work that actually requires judgment and taste.
Getting there requires the same rigor we apply to any infrastructure initiative—diagnosis, principles, and disciplined execution. Nothing in this post is AI-specific. It’s just good engineering leadership applied to a new tool.
The companies that win here won’t be the ones who adopted AI fastest. They’ll be the ones who were honest about what’s working, killed what isn’t, and kept shipping value through the hype. That’s how you actually amplify human impact—not by adding more AI, but by using it where it genuinely matters.
But getting the technology and strategy right is necessary, not sufficient. The hardest part is the culture shift. If AI is going to amplify curiosity, creativity and craftsmanship, you have to change what you measure, what you reward, and what “great engineering” looks like.
That’s the topic of my next post.
What are your thoughts on AI adoption in engineering organizations? Reach out on LinkedIn.