The standard

AI Delivery Levels

Five levels. One question: who starts the work?

The Delivery Levels describe how a team really works with AI, not which tools it has bought. One thing separates each level from the next: how much of the work the AI starts on its own, and how much you still have to start for it. Below you will find each level in plain terms, what it looks like in every phase of your delivery, and how we decide where a team sits.

Six core phasesObjective gatesDL1 to DL5
Core principle

The progression of initiative

One thing separates each level from the next. Not the number of licences, not the size of the tool budget. Just this: who starts the work.

LevelWhat the AI doesWhat the people doIn one word
DL1NothingEverythingManual
DL2Reacts to keystrokesDrive everything, AI assists per taskReactive
DL3Understands project context, contributes proactivelyDrive each phase, AI contributes within itContextual
DL4Takes initiative across the full SDLC from a business inputReview and approve the AI’s proactive outputCollaborative
DL5Operates autonomously at organisation scaleHandle exceptions and approve at gatesAutonomous
DL1
1.0×productivity

Manual / no AI

No AI. Pure human software delivery.

All code is human-written. All tests are human-designed. All documentation is human-authored. All reviews are human-conducted. The traditional SDLC operates exactly as it has for decades.

Characteristics

  • All code human-written, line by line.
  • Test coverage depends on developer discipline and team culture.
  • Review quality depends on reviewer experience and available time.
  • Knowledge lives in people’s heads, not in systems.
  • IDE support limited to syntax highlighting, linting and basic refactoring.

When this is appropriate

  • Air-gapped systems and classified environments.
  • Strict compliance regimes that prohibit AI tool usage.
  • Increasingly rare: less than 10 to 15% of teams industry-wide.
Productivity

1.0× baseline. Delivery speed scales only with headcount.

DL2
reactive
1.25×productivity

Individual AI Assistant

AI reacts to your keystrokes. Individual, isolated, reactive assistance.

Engineers use AI tools (ChatGPT, Copilot, Cursor, Claude) on their own terms. AI provides autocomplete, code snippets, chat-based Q&A, and basic suggestions. Each task is handled independently. AI doesn’t understand your project as a whole. It reacts to what you type, file by file, prompt by prompt.

The developer adjusts the prompt (“fix this, use this framework, do not use that class”) instead of building a feedback loop that can be shared with the rest of the team.

Key characteristics

  • Individual engineers decide when and how to use AI.
  • No shared configuration: no rules files, no team context.
  • AI output is generic. It doesn’t know project conventions, architecture, or patterns.
  • Every developer on the same team gets different quality output from the same AI tool.
  • No team consensus on AI methodology: “everyone does their own thing.”
  • AI is used predominantly for implementation, occasionally for testing or docs.

What’s missing vs DL3

  • No project-level context fed to AI (no CLAUDE.md, no .cursorrules, no architecture docs).
  • No AI awareness of cross-service connections, integration points, or project-wide patterns.
  • No team AI standard: no documented methodology, no shared practices.
  • No structured AI output review methodology.
  • AI is reactive, not proactive: it doesn’t flag issues, suggest improvements, or understand scope.
Example

Developer asks AI “write a function to validate email.” AI produces a generic validation function using a library the project doesn’t use, with naming conventions that don’t match the project’s style. Developer manually fixes it.

Productivity: ~1.25× (individual gain, unstructured).

DL3
contextual
2–5×productivity

Collective Intelligence

AI understands your project and contributes proactively. Context-aware, multi-phase, team-standardised.

AI is deeply aware of your architecture, project standards, service connections and testing approach. It doesn’t just react to prompts, it proactively contributes. When a feature involves three services, AI recognises the connections between them, generates unit and integration tests that cover cross-service interactions, flags potential conflicts before code review, and drafts requirement summaries from stakeholder input.

The team has a shared AI methodology: rules files, architecture documentation as AI context, structured review practices, and a documented standard for how AI is used across the project.

Key characteristics

  • Rules file (CLAUDE.md / .cursorrules) with project conventions, architecture patterns and constraints, shared across the team.
  • Architecture documentation, API specs and domain knowledge fed to AI as persistent context.
  • AI used across 5+ SDLC phases: requirements, architecture, implementation, testing, review, CI/CD, docs.
  • AI understands service connections, integration points and project-wide patterns.
  • AI proactively suggests tests for edge cases, conflicts between services, optimisation opportunities.
  • A documented AI usage standard: everyone uses AI the same way.
  • Structured review methodology: AI output reviewed with checklists, against project standards.
  • Context files maintained as part of the Definition of Done for every PR.

What’s missing vs DL4

  • Human still initiates each phase separately: “now implementation,” “now testing.”
  • AI doesn’t generate the spec. Humans define WHAT to build, AI helps with HOW.
  • AI works within the phase it is directed to, not across the full SDLC.
  • Feature-level work still requires multiple human-directed prompts or sessions.
Example

“Implement the password reset flow.” The AI knows the project uses Express with a specific auth middleware pattern, Prisma and Resend, and produces the full implementation matching all project conventions on the first try. Review finds it 90% correct; one follow-up prompt fixes the edge case.

Productivity: ~2–5× (team-wide, structured).

DL4
collaborative
10×productivity

Automated Agentic SDLC

AI takes initiative across the full SDLC from a business input.

Given a business requirement or product conversation, AI proactively generates everything: user stories, functional blocks, architecture proposals, implementation, test suites with coverage optimisation, deployment configurations, and documentation. The engineer doesn’t need to direct AI phase by phase. AI takes initiative across the entire lifecycle.

The engineer’s primary deliverable shifts from code to judgment. They review AI’s proposals and make the calls: approve, adjust, or override. The spec is what AI drafts; the human validates and enriches it rather than writing it from scratch.

Key characteristics

  • AI generates user stories and functional specifications from business conversations or requirements documents.
  • AI proposes architecture decisions aligned with technical and business strategy.
  • AI generates complete features: implementation across all required files, tests with coverage optimisation, documentation, CI/CD configuration.
  • AI generates full test suites including integration, edge cases and security checks.
  • The “spec” is something AI drafts and a human approves, not something a human writes from scratch.
  • AI proactively identifies gaps in requirements before implementation begins.
  • Change classification: AI distinguishes routine changes from significant changes that require human review.
  • Quality gates are structured and measurable, not gut-feeling reviews.

What’s missing vs DL5

  • AI operates per-project, not organisation-wide.
  • Human still orchestrates the overall workflow, deciding when to kick off AI and reviewing at each major output.
  • No multi-agent coordination. A single AI context handles the work.
  • No autonomous operation. AI proposes, human approves at each phase.
Example

PM describes a feature in a conversation: “Users need to be able to reset their passwords.” AI generates a structured spec covering all flows, edge cases, security requirements and rate limiting; an architecture proposal showing which services are affected; complete implementation; a test suite with 15 tests covering happy path, error cases and security; API documentation updates; and a migration script. Engineer reviews the spec (“add session invalidation on reset”), approves the rest. Ships.

Productivity: ~10× (team output).

DL5
autonomous
100×productivity

Autonomous SDLC

AI operates autonomously at organisation scale. Humans at gates only.

Multiple AI agents orchestrate the full SDLC. One agent refines requirements, another architects, another implements, another tests, another reviews. The workflow runs itself. Humans sit at gates between major phases: approving transitions, catching what agents missed, making judgment calls on strategic decisions.

The distinction from DL4 is not the technology, it is the scope and the autonomy. At DL4, AI is a proactive collaborator on individual projects with human oversight per phase. At DL5, AI operates across the entire organisation, routine tasks run autonomously, and humans focus only on exceptions and strategic decisions.

Key characteristics

  • Multi-agent orchestration: specialised agents for requirements, architecture, implementation, testing, review, deployment.
  • Agents communicate mid-task, sharing discoveries, resolving conflicts, updating context.
  • Autonomous execution of routine work. Humans don’t direct each step.
  • Human intervention at defined gates: Gate 1 (spec approval), Gate 2 (final output approval).
  • Change classification drives autonomy: routine changes auto-approved, significant changes human-reviewed.
  • Full audit logging, traceability and rollback for all autonomous decisions.
  • A governance framework defines what AI may decide alone.
  • Documentation, changelogs and release notes stay in sync with code automatically.

What’s still developing

  • Multi-agent tooling shipped only in February 2026. Weeks old, not years old.
  • Governance frameworks for a multi-agent SDLC are being invented in real time.
  • 40% of deployed AI agents have zero safety monitoring (MIT AI Agent Index).
  • Production failure modes are not well understood.
  • The agent framework landscape is volatile. No industry standard yet.
Example

PM creates a ticket: “Add password reset.” The requirements agent generates the spec: all flows, edge cases, rate limiting, session handling. Gate 1: engineer reviews in 2 minutes, adds “CAPTCHA after 3 failed attempts.” Architecture agent plans the changes. Implementation agent writes the code. Testing agent runs 18 tests, one fails. Implementation agent fixes it, all pass. Review agent checks implementation against spec. Gate 2: engineer reviews the final PR. Approves. Ships.

Productivity: ~10–100×, depending on execution quality.

Phase by phase

What each level looks like across the delivery lifecycle

Almost no team sits at the same level everywhere. You can be at DL3 when writing code and DL1 when testing it. So we look at every phase on its own. Pick one and see how it changes from level to level.

Next step

Which level is your team on?

In 30 minutes we go through your six phases with you, place your team on the scale, name the one thing holding the rest back, and show you what the next level is worth. You get it in writing within a week.

Assessment · Free

Delivery-Level Assessment for your organisation

  • 30-minute conversation with a senior practitioner
  • Evaluation of your six delivery phases
  • Placement on DL1–DL5
  • One bottleneck, one next step - in writing
Please enter your first name.
Please enter your last name.
Please enter your company name.
Please enter a valid email address.
Fields marked with * are required

Free, 30 minutes, no system access. We use your details only to arrange the assessment.