Book a Free Consultation
Trusted by leading businesses worldwide
Table of contents
Every week I get on a call with a CEO who opens with some version of the same line: "We want full AI automation in our engineering org by next quarter."
And every week I deliver the same uncomfortable answer. Your team isn't ready. Your codebase isn't ready. Neither is technology.
Not because AI isn't powerful. It is, more than most people realize. But there's a brutal gap between what AI does in a demo and what it does inside your actual delivery process.
That gap has a name. We call it the Delivery Level, or DL.
I'll say this publicly and I mean it: if you don't know which DL your team sits at, you don't have an AI strategy. You have a budget line and a hope.
AI Delivery Levels (DLs) are a five-stage maturity framework. They measure how deeply and reliably AI is integrated across an engineering organization's software delivery lifecycle. DL1 is minimal AI use. DL5 is full automation.
The framework spans all six core phases of the SDLC. Not just the IDE, where most teams stop looking.
That distinction is what makes DL3 meaningful and DL5 nearly impossible.
My working estimate from what we see in delivery teams across the DACH region:
Roughly 70% of teams sit at DL2. They use AI for autocomplete and the occasional code generation. It feels productive. Mostly it isn't, in any compounding way.
A small minority have reached DL3. AI participates across the lifecycle. They've built the context infrastructure to make that participation reliable.
Less than 1% are at DL5. Full automation, in any honest definition, is essentially nonexistent.
The biggest single jump in this framework isn't DL4 to DL5. It's DL2 to DL3.
That's where most teams fail, stall, or quietly pretend they've succeeded.
I'll admit something. I defended individual prompt skill through most of 2025. I thought the next 2-3x was hiding inside better prompts.
Then everyone hit the same wall.
Individual prompt skill plateaued at 1.25x. The math changed. The next jump doesn't come from any single engineer prompting better. It comes from the team's compounding context.
DL2 is easy. Hand engineers a license to Claude or Cursor and they start using it. Productivity feels higher. Some of it is.
DL3 is hard because it requires something most engineering organizations have never done. Making tribal knowledge explicit, structured, and machine-readable.
The senior engineer who knows the payment service can't be touched on Fridays because of the legacy batch job? That lives in his head. AI can't access it. So AI keeps making the same mistake, and your team keeps blaming AI.
Your developers are not the problem. Your context is.
I've watched this transition work. I've watched it fail. Here's what actually works, in the order I'd run it.
1. Run a 4-session knowledge extraction with each senior engineer. Architecture, conventions, decisions, gotchas. 60-90 minutes per session. → Tribal knowledge moves from heads to markdown files.
2. Write your project constitution as CLAUDE.md (or .cursorrules). The rules, structure, non-negotiables, services. → AI loads it on every run. You stop paying the tax of "let me first understand your project" on every single prompt.
3. Build the supporting context file suite. architecture.md, decisions.md, gotchas.md, plus domain files where they matter. → AI gets what a senior usually learns after 90 days of onboarding.
4. Define a team AI standard. Which tool for which task. How output is reviewed. What is never accepted blindly. → Quality stops depending only on individual habits.
5. Expand AI usage beyond coding. Requirements, architecture, testing, review, documentation, CI/CD. → AI participates across the full lifecycle, not just inside the IDE.
6. Add context-file maintenance to the Definition of Done. Every PR updates the relevant context file. → The AI system compounds with every PR instead of decaying every sprint.
7. Train at least 2 engineers per team in context engineering. Not AI usage. Context engineering. → The team has owners of the AI workflow, not just AI users.
8. Train PMs and POs to write AI-ready specs. Acceptance criteria, edge cases, affected services, constraints. → AI delivers from the spec without back-and-forth between PM and engineers.
9. Build a structured review methodology. Spec compliance, architectural patterns, conventions, security, test coverage. → AI mistakes get caught systematically, not randomly.
10. Validate against the DL3 completeness threshold. All 6 core SDLC phases at DL3+. → You know if you reached DL3 or only painted DL2.
Pros of DL3: rapid, conversational problem-solving. Onboarding compresses. The team moves faster on more interesting problems.
Cons: relying only on compound knowledge can kill innovation, unique workarounds, and the specialized processes that made the team good in the first place. Standardize too hard and you flatten what made you sharp.
Part of doing DL3 well is preserving the space for engineers to deviate from the codified path when the problem demands it. That's not a contradiction. That's the discipline.
Back to where I started. The CEO who wants full AI automation next quarter.
My view: the human is never out of the loop. Not at DL3. Not at DL4. Not even at the hypothetical DL5 almost no one has reached.
What changes is what the human does.
At DL2, the human is fighting AI.
At DL3, the human is directing it.
At DL4, the human is governing systems of agents.
The role keeps shifting up the stack. It never disappears.
If anyone, a vendor, a consultant, a viral LinkedIn post, is telling you they can take the humans out of your engineering loop, they're either selling you something or they haven't tried to actually do it.
At Intertec, we are moving all our engineers from "AI as a tool" to "AI as a systematic delivery engine" over the next six months. That's the work. Not the automation fantasy.
Pick your DL. Build your context. Move fast.
The AI Delivery Levels framework is a five-stage model (DL1 through DL5) that measures how mature an engineering organization is in integrating AI across its full software delivery lifecycle, from requirements through CI/CD. It exists because most teams overestimate where they are.
A CLAUDE.md file is a project-level instruction document that tells AI coding assistants the rules, architecture, conventions, and non-negotiables of your codebase. It functions as a project constitution that AI loads on every run, eliminating the repeated "let me understand your project" overhead.
No. As of 2026, less than 1% of engineering teams operate at DL5, and even at that level the human remains in the loop. AI shifts what engineers do, from writing code to directing, reviewing, and governing AI output, but it does not remove them from the delivery process.
Based on Intertec's observations across client delivery teams, roughly 70% of teams sit at DL2 (basic AI usage in the IDE), a small minority have reached DL3, and less than 1% have achieved DL5.
For a typical delivery team, the transition takes three to six months when executed deliberately across all ten steps. Teams that skip context engineering or treat it as a one-time project rather than ongoing maintenance stall and regress to DL2.
Context engineering is the discipline of structuring codebase knowledge, architectural decisions, and project conventions into machine-readable files so AI coding assistants produce reliable, on-pattern output. It's the core skill that separates DL2 teams from DL3 teams.
Table of contents
Trusted by leading businesses worldwide