Organization
How organizations adapt to the age of agents. From "buy licenses" to "agent fleet management".
Maturity →
AI Adoption Model
How your organization rolls out AI tools - from individual experiments to org-wide strategy.
- Adoption via bulk license purchaseThe big-bang license purchase is the most common first move in enterprise AI adoption, and the most reliable predictor of failure.guide→
- Initial enthusiasm fades to low usageEnthusiasm → Silence → Shelfware is the name for the failure arc that almost every unstructured AI tool deployment follows.guide→
- Powerful tools on an unprepared processThe Ferrari Engine in Fiat 126p is a metaphor for a specific and common failure pattern: installing powerful AI capability into an engineering process that cannot take advantage of it.guide→
- 01AI tools have been adopted (licenses acquired)
- 02Adoption is tracked informally
- 03At least some developers are experimenting with AI tools
- 04Organization has not banned AI tool usage outright
- Pilot teams (2-3 teams)A structured pilot is the antidote to the big-bang license deployment.guide→
- Internal championThe internal champion is the single most important structural element of a successful AI adoption program.guide→
- Pilot metrics; track cost-per-merged-PR from day onePilot metrics are the set of measurements you define before a pilot starts that determine whether the pilot succeeded and whether to expand.guide→
- 012-3 pilot teams are designated with explicit AI adoption goals
- 02An internal champion (or AI lead) is identified and has allocated time for the role
- 03Pilot metrics are defined and tracked (adoption rate, usage frequency, developer satisfaction)
- 04Pilot results are shared with the broader organization
- 05Champion has direct access to leadership for escalation
- Platform team owns AI toolingWhen AI tool adoption is owned by individual champions or informal volunteers, it scales up to a point and then stops.guide→
- Internal Developer Platform with AI layerAn Internal Developer Platform (IDP) is the set of self-service tools, workflows, and infrastructure that product teams use to build, test, and deploy software without requiring maguide→
- Standardized agent setup per team; "bad day protocol" - documented rollback when models or harnesses regress (Anthropic Apr 23 postmortem template)A standardized agent setup means that every team starts from the same baseline agent environment - the same tools available, the same context injection approach, the same permissioguide→
- 01Platform team formally owns AI tooling (selection, provisioning, security, baseline configuration)
- 02Internal Developer Platform includes an AI layer (standardized agent setup, self-service provisioning)
- 03Standardized agent setup exists per team (every team has a working AI environment by default)
- 04New developer onboarding includes AI tool setup that completes in under 30 minutes
- 05Platform team tracks adoption breadth (% of developers with active AI setup)
- AI-first development culture (Cursor 3, Zapier 97%)An AI-first development culture is one where agents are the default approach to development tasks, not an option that some developers use sometimes.guide→
- Agent fleet management as disciplineAgent fleet management is the practice of treating multiple concurrent AI agents as a managed resource pool, applying the same operational discipline to agent orchestration that maguide→
- Developer = agent supervisor (Yegge Stage 6-7)In Steve Yegge's model of AI adoption stages, Stages 6 and 7 represent a fundamental shift in what a developer does.guide→
- 01AI-first development culture: 80%+ of developers use AI tools daily
- 02Agent fleet management is a recognized discipline with defined practices
- 03Developer role has shifted toward agent supervision (Yegge Stage 6-7)
- 04"Span of control" metric is tracked (how many agents a developer can effectively supervise)
- 05Organization benchmarks against industry AI adoption data (Zapier 97%, Cursor 3 adoption rates)
- "Kubernetes for agents" - centralized orchestration"Kubernetes for agents" describes the centralized orchestration infrastructure that enables large-scale agent deployment across an organization - analogous to how Kubernetes manageguide→
- Human-at-the-wheel, not human-in-the-loop"Human-in-the-loop" describes an approval model where humans review and approve individual agent actions before they execute.guide→
- Organization optimized for agent throughput, not human throughputOrganizations are designed around assumptions about how work gets done.guide→
- 01Centralized agent orchestration system exists ("Kubernetes for agents")
- 02Developer role is "human-at-the-wheel" (strategic direction, not task-level involvement)
- 03Organization is optimized for agent throughput, not human throughput (meetings, processes, tooling all agent-aware)
- 04Agent orchestration system handles scheduling, resource allocation, and failure recovery
- 05Organization measures agent utilization as a key infrastructure metric
Knowledge Management
How institutional knowledge is captured, shared, and made available to both humans and agents.
- Processes passed on verbally, not documentedFolk tradition knowledge is the undocumented institutional lore that accumulates around every long-lived codebase.guide→
- Little written documentationThe documentation chicken-and-egg problem is one of the most persistent failure modes in software organizations.guide→
- Key knowledge held by senior staffTribal knowledge in seniors' heads is the organizational pattern where the critical understanding of a codebase — the architectural decisions, the historical context, the dangerousguide→
- 01The team has working knowledge of its systems
- 02Onboarding includes a README or equivalent starting point
- 03Team acknowledges that tribal knowledge is a risk
- 04Some informal knowledge sharing exists (Slack threads, meeting notes)
- Docs refresh initiativeA docs refresh initiative is the structured, time-boxed effort to bring existing documentation back into alignment with reality.guide→
- Architecture Decision Records (ADRs)Architecture Decision Records are short, structured documents that capture why a significant technical decision was made — not just what was decided, but the context, the options cguide→
- Written onboarding pathsA written onboarding path is a structured, step-by-step guide that takes a new engineer from zero access to productive contribution on a specific codebase or team.guide→
- 01Documentation refresh initiative is active with measurable progress
- 02Architecture Decision Records (ADRs) are written for significant technical decisions
- 03Written onboarding path exists (new developer can self-serve key setup steps)
- 04ADRs are indexed and searchable
- 05Onboarding path has been validated by at least one new hire completing it solo
- Documentation = infrastructure (not an HR problem)Most engineering organizations treat documentation as a people problem: if engineers wrote better docs, if seniors were more generous with their knowledge, if new hires asked more questions.guide→
- Lint rules > docs (enforced > suggested)Documentation that says "we use camelCase for variable names" is a suggestion.guide→
- Knowledge graph codebase (CodeTale, Graph Buddy)A knowledge graph codebase tool transforms a source repository into a queryable graph of relationships: which functions call which, which modules depend on which, which teams own wguide→
- 01Documentation is treated as infrastructure (owned by engineering, not HR or PMO)
- 02Lint rules enforce conventions rather than relying on documentation alone (enforced > suggested)
- 03Knowledge graph of the codebase (CodeTale, Graph Buddy, or equivalent) is operational
- 04Documentation freshness is tracked (pages older than 90 days are flagged for review)
- 05Knowledge graph is integrated with agent context pipeline (agents query it at runtime)
- Context Fabric: MCP servers feed agents automaticallyThe Context Fabric is the sum of all MCP (Model Context Protocol) servers that an organization deploys to feed relevant information to agents automatically, without requiring enginguide→
- Autonomous Requirements: unclear ticket → spec autoAutonomous Requirements is the capability of AI agents to receive a vague or underspecified ticket — "add dark mode to the settings page" or "fix the slowness in the search endpoinguide→
- Docs auto-updated by agents on code changeDocumentation auto-update is the practice of triggering an agent to update relevant documentation whenever a code change is committed, rather than relying on the engineer making thguide→
- 01Context Fabric: MCP servers automatically feed institutional knowledge to agents
- 02Autonomous Requirements pipeline: unclear tickets are auto-expanded into specs with acceptance criteria
- 03Agents auto-update documentation when code changes (no manual doc maintenance)
- 04Context Fabric covers 80%+ of active repositories
- 05Doc auto-update PRs are reviewed and merged within 24 hours
- Self-evolving knowledge baseA self-evolving knowledge base is a knowledge infrastructure that improves itself without requiring humans to initiate updates.guide→
- Agent detects stale context → updates → validatesStale context detection is the capability of an agent to recognize that the documentation, runbooks, or contextual information it is working with no longer accurately describes theguide→
- Organizational memory = Git-backed, agent-readable, always currentOrganizational memory — the accumulated knowledge of how a system was built, why it was designed as it was, how it operates, and what was tried and failed — has traditionally livedguide→
- 01Knowledge base is self-evolving (agents add, update, and validate knowledge entries continuously)
- 02Agent detects stale context, updates it, and validates the update - without human initiation
- 03Organizational memory is Git-backed, agent-readable, and provably current
- 04Knowledge base freshness score exceeds 95% (% of entries updated within their defined freshness window)
- 05Self-evolving updates are validated against codebase to prevent knowledge drift
Team Structure & Roles
How teams are organized and what roles exist to support AI-augmented engineering.
- Traditional roles: dev, QA, PMThe traditional engineering team organizes work into three primary roles: developers who write code, QA engineers who test it, and product managers who translate business requiremeguide→
- Seniors review and fix AI-generated codeThe "senior debugs AI code" anti-pattern emerges when junior and mid-level developers use AI agents to generate code faster than they can verify quality, and the resulting problemsguide→
- AI being evaluated in the team's stack"AI doesn't work in our environment" is the most common organizational statement that blocks progress at L1.guide→
- 01The team has standard engineering roles (developer, QA, PM)
- 02Senior developers review and fix AI-generated code
- 03Team is open to experimenting with AI-assisted workflows
- 04At least one person informally champions AI tool usage
- AI champion per teamAn AI champion per team is a senior or staff engineer who takes on informal or formal ownership of making AI tooling work for their specific team.guide→
- Context engineer role (initial)Context engineering is the practice of making information legible to AI agents: writing CLAUDE.md files that explain codebase conventions, building MCP server integrations that givguide→
- Training: how to write good prompts/tasksTraining in how to write good prompts and tasks is the L2 investment in the fundamental skill that determines whether AI agents are useful or frustrating.guide→
- 01AI champion is designated per team with allocated time (not just informal interest)
- 02Context engineer role exists (initial, possibly part-time) for maintaining agent instruction files
- 03Developer training on effective agent interaction (prompt writing, task decomposition) has been conducted
- 04Champion has a regular cadence for sharing learnings across the team
- 05Training materials are documented and available for new hires
- Platform Engineer (AI tooling)The Platform Engineer specializing in AI tooling is the person who builds the infrastructure that makes AI agents effective at scale.guide→
- Context Engineer = full role (now mainstream - dedicated job postings across industry)At L3, context engineering graduates from "something the champion does in their spare time" to a full-time engineering role with its own scope, career path, and organizational standing.guide→
- Review shifts: from writing to evaluating codeWhen most code in a PR is agent-generated, the reviewer's job changes fundamentally.guide→
- 01Platform Engineer role with AI tooling responsibility exists on the platform team
- 02Context Engineer is a full dedicated role (not part-time, not combined with other duties)
- 03Team's primary activity has shifted from writing code to evaluating and reviewing AI-generated code
- 04Role definitions are updated to reflect AI-augmented responsibilities
- 05Hiring criteria include AI tool proficiency
- Developer = manager of agent fleetAt L4, the developer's primary job is not to write code - it's to manage a fleet of AI agents that write code.guide→
- "Keep your Tamagotchi alive" (Yegge); Buddy/Clyde-style gamified observabilitySteve Yegge's "keep your Tamagotchi alive" framing captures a crucial insight about working with AI agents at L4: they are not fire-and-forget automations.guide→
- Span of control = how many agents you can effectively superviseSpan of control is a management concept from organizational science: how many direct reports can one manager effectively supervise? The answer for human teams is typically 5-9, witguide→
- IPETs (Innovation & Practices Enabling Teams) - Team Topologies pattern for AI stewardship and knowledge diffusionAt L4, the developer's primary job is not to write code - it's to manage a fleet of AI agents that write code.guide→
- 01Developer role is formally defined as "manager of agent fleet"
- 02Span of control is measured: how many parallel agents each developer effectively supervises
- 03Performance evaluation includes agent supervision effectiveness (not just personal code output)
- 04Span of control target is defined per role (e.g., 3-5 agents for standard developers, 5-10 for senior)
- 05Agent supervision training is part of standard developer onboarding
- Agentic Engineer: orchestration + supervision + architectureThe Agentic Engineer is the L5 role that emerges when AI agents become the primary development modality and the human's job is to architect, orchestrate, and supervise rather than implement.guide→
- PEV loop: Plan → Execute → VerifyThe PEV loop - Plan, Execute, Verify - is the fundamental operating model for working with AI agents at high maturity.guide→
- Non-coder contributors via agent interfacesNon-coder contributors via agent interfaces is the L5 capability where product managers, designers, business analysts, domain experts, and other non-engineering professionals can dguide→
- 01Agentic Engineer role combines orchestration, supervision, and architecture responsibilities
- 02PEV (Plan, Execute, Verify) loop is the standard workflow for all engineering tasks
- 03Non-coder contributors can produce software changes via agent interfaces
- 04Agentic Engineer career ladder exists with defined progression criteria
- 05Non-coder contribution rate is tracked as an organizational capability metric
Tech Debt & Modernization
How AI accelerates paying down tech debt and modernizing legacy systems.
- Tech debt accumulatesDebt grows is the default state of software engineering in organizations that have not made debt management a deliberate practice.guide→
- Legacy code left untouched"Legacy = don't touch it" is the fear-based approach to old or poorly understood code that characterizes L1 organizations.guide→
- Multi-year migration backlogA migration backlog measured in years is the state where an organization's known modernization work - framework upgrades, language version migrations, deprecated API replacements,guide→
- 01The team is aware of its main tech-debt areas
- 02Legacy systems are kept stable
- 03Team acknowledges tech debt exists and can enumerate major items
- 04Migration backlog exists (even if years long with no progress)
- Debt categorized and prioritized; track "context debt" and "verification debt" separately from classic legacy debtDebt categorized and prioritized is the L2 state where an organization has moved from informal awareness of technical debt to a structured system for tracking, classifying, and ordering debt items.guide→
- Manual migration attemptsManual migration attempts are the L2 approach to executing framework upgrades, library replacements, and platform modernization: a developer (or small team) manually updates code tguide→
- OpenRewrite basic recipesOpenRewrite is an open-source automated refactoring tool for Java and other JVM languages that executes structured code transformations called "recipes." A recipe is a reusable, teguide→
- 01Tech debt is categorized and prioritized (severity, impact, effort)
- 02At least one manual migration attempt has been completed or is in progress
- 03OpenRewrite or equivalent automated refactoring tool has been evaluated or adopted for basic recipes
- 04Tech debt reduction is allocated time in sprint planning (even if small)
- 05Migration attempts are documented with lessons learned
- Continuous Modernization: agent pays off debt in backgroundContinuous modernization is the L3 shift from treating tech debt reduction as a project - something that competes with features for engineering time - to treating it as infrastructguide→
- Library bumps, version upgrades autoAutomated library bumps and version upgrades are the L3 practice of delegating dependency version management to an automated system that monitors upstream releases, identifies whenguide→
- OpenRewrite + agent = systematic refactoringOpenRewrite combined with an AI agent is the L3 pattern where structured code transformation (OpenRewrite recipes) is orchestrated by an AI agent that selects which recipes to applguide→
- 01Continuous modernization: agents work on tech debt reduction in background (non-blocking to feature work)
- 02Library version bumps and dependency upgrades are automated via agent PRs
- 03OpenRewrite + agent combination is used for systematic refactoring campaigns
- 04Agent tech debt PRs follow the same review process as feature PRs
- 05Dependency freshness score is tracked (% of dependencies within N versions of latest)
- "Dead project too expensive to modernize" → agent modernizes for pennies"Dead project too expensive to modernize" describes the category of software that an organization has written off as permanently unmaintainable - typically an internal tool, a legaguide→
- Cross-repo migration agentsCross-repo migration agents are AI agents configured to execute a consistent modernization task across dozens or hundreds of repositories simultaneously, opening PRs in each, handlguide→
- Java 8 → 21, Angular.js → Angular 17 via agentsJava 8 to Java 21 and AngularJS to Angular 17 are two of the most common large-scale migration challenges in enterprise software engineering.guide→
- 01Projects previously deemed "too expensive to modernize" are being modernized by agents at low cost
- 02Cross-repository migration agents operate across multiple codebases simultaneously
- 03Major version migrations (e.g., Java 8 to 21, Angular.js to Angular 17) are agent-driven
- 04Cost-per-migration-PR is tracked and decreasing
- 05Cross-repo migrations complete within defined SLAs (e.g., 100 repos migrated in 30 days)
- Tech debt = near-zero steady stateTech debt near-zero steady state is the L5 condition where technical debt does not accumulate over time because the rate of debt remediation equals or exceeds the rate of debt creation.guide→
- Agent fleet maintains, upgrades, patches 24/7An agent fleet that maintains, upgrades, and patches 24/7 is the L5 state where codebase maintenance is operationalized as infrastructure rather than treated as engineering work.guide→
- CVE remediation: detect → fix → test → ship autonomousAutonomous CVE remediation is the L5 capability where a security vulnerability announcement triggers a fully automated pipeline that identifies which repositories are affected, appguide→
- 01Tech debt is at near-zero steady state (new debt is paid down within the same sprint it is created)
- 02Agent fleet maintains, upgrades, and patches codebases 24/7 without human scheduling
- 03CVE remediation is autonomous: detect vulnerability, generate fix, test, and ship
- 04Mean time from CVE disclosure to deployed fix is under 24 hours for critical vulnerabilities
- 05Tech debt score (measured by static analysis) has been stable or improving for 6+ months
You don't have to figure this out alone.
Every level in this matrix has a path. Read the playbooks the teams that have climbed it wrote. Run the assessment with our consultants. Start where you are.
Book an AI Maturity Assessment session with your team.
We walk you through all four perspectives, score where you actually are, and leave you with a 90-day plan to climb in the dimensions that matter most.
May 2026 update: the Q1 layoff data is now in and it is uglier than the press release tour suggested.
78,557 tech jobs lost in Q1 2026, 47.9% AI-attributed, with junior and entry-level roles disproportionately affected (new SWE postings down 15%). 55% of employers report regretting AI-driven layoffs - the "AI layoff trap" is being quietly reversed. Forrester finds only 16% of workers have high AI readiness, projected to 25% by year-end. The lesson: cutting humans before maturing the AI stack creates a permanent capability gap.
Healthy adoption now includes a "bad day protocol" - a documented rollback when the model or harness regresses (the template here is Anthropic's April 23 postmortem; the diagnostic is Stella Laurenzo's 6,852-session audit). On the org side, the most interesting new pattern is IPETs (Innovation and Practices Enabling Teams) - a Team Topologies adaptation where a small enabling team owns AI stewardship, knowledge diffusion and security boundaries across product teams. New tech debt categories matter too: "context debt" (rapid iteration without architectural integrity, hits a 12-week unmaintainability cliff) and "verification debt" (3x velocity gain offset by 125% verification overhead). Yegge's 8 stages are still the best individual-maturity model. The org that makes Stage 6+ work without burning out its seniors will be the one with IPETs and a working bad-day protocol.