The maturity levels

A level is not an opinion about a company. It is the result of testing that company's published, cited facts against a fixed external framework, not a scale we invented ourselves. We use the AI-SDLC Maturity Model, published by Sergii Bataiev, Technology & Architecture Director at ELEKS, on February 16, 2026. Same facts in, same level out; no vendor, including Port, gets a thumb on the scale.

Bataiev's model is deliberately not about how good one coding agent is at one task. It scores a company across five activities that span the whole software factory at once: code generation, testing, code review, documentation, and deployment. A level is a claim about how far AI's role has advanced across all five together, not about any single agent in isolation. His own framing: "human expertise becomes more critical, not less" as the levels climb, and organisations that treat AI purely as a cost-reduction tool risk "declining stability, growing technical debt, and compounding security risks."

The five activities, side by side

Each climbs from Traditional to AI-supported to AI-assisted to AI-native to AI-autonomous on its own track:

• Code generation. Manual, then suggestions, then multi-file, then full features from a specification, then autonomous.
• Testing. Manual, then suggested, then generated and human-validated, then comprehensive and reviewed, then auto-generated and auto-executed.
• Code review. Human-only, then human plus automated flags, then human validation required on every output, then human review reserved for critical workflows, then tiered approval by change type.
• Documentation. Manual, then transcription-aided, then suggested, then auto-generated, then auto-synchronized.
• Deployment. Manual, then manual, then manual, then human-reviewed, then auto-approved for routine changes.

A company can advance unevenly across these five, and often does. Where the record shows that, name the specific row rather than forcing one row's evidence to stand in for all five.

Two things worth establishing before anything level-specific

1. Where do agents actually run: an IDE, a CI/CD pipeline, a workflow tool like n8n, a cloud agent service, something else? This is usually answered by the company's own stack description.
2. Could the company produce a full list of every agent running in the org and what each one is authorized to touch? Most public accounts never address this directly. When a source is silent on it, that silence is itself worth recording (see "Gaps.")

How to place a company: don't read the levels in order

Work through the published facts, not through the level list top to bottom. A single strong piece of evidence (a described auto-approved deployment tier, say) can place a company at a higher level for that one row even if other rows (documentation, testing) were never disclosed at the same depth. Don't hold a high-level finding hostage to confirming every lower level first.

Maturity is not always one number. A company can clear the bar for one activity at Level 5 (an auto-approved, no-human-reviewer path for a narrow, well-defined change type, say) while sitting at Level 3 everywhere else. When the record shows that kind of split, name the specific row and say so in the entry rather than forcing one level to describe the whole company. The assigned level should reflect the most advanced practice that is widely and credibly disclosed, not the average, and not the single best anecdote.

Human review remaining mandatory on every merge is not a tiebreaker, it's a hard ceiling. Under this model, Level 5 requires a described change-classification framework with at least one tier that ships without a human in the loop. A company where every source states human approval gates every merge, no exceptions, cannot be placed at Level 5 regardless of how sophisticated its agents are elsewhere. Sophistication and autonomy are different axes; this model scores the second.

---

Level 1: Traditional SDLC

What this looks like. Developers write all code manually with only basic tooling support: IDEs, linters, version control. In Bataiev's words, "every workflow is human-initiated, human-executed, and human-decided." Human sign-off is required for every change.

What would place a company here, cited:

• No named AI coding tool in production use anywhere in the SDLC
• Testing, documentation, and code review all described as fully manual

Level 2: AI-supported SDLC

What this looks like. AI provides passive, reactive assistance: autocomplete, function- signature suggestions, automated linting before commit. Humans remain fully in control and the tool responds to what a developer is already doing rather than anticipating it.

What would place a company here, cited:

• A named autocomplete or suggestion-only tool in use, described as reactive
• No account of the tool generating a complete function, a test, or documentation on its own

What would move a company past this level:

• A described tool that generates multi-file code or complete test cases, not just single-line suggestions

Level 3: AI-assisted SDLC

What this looks like. AI takes a more proactive role: generating larger, multi-file code blocks, understanding cross-module context, generating unit and integration tests, and flagging conflicts before code review. Every output still requires human validation before it counts as done.

What would place a company here, cited:

• A named tool or agent that generates multi-file code and is described as producing its own tests, with every source agreeing that a human validates the result before it ships
• Code review, documentation, and deployment all still described as human-executed

What would move a company past this level:

• A described case of an agent generating a full feature from a specification, or producing architecture proposals, rather than working inside a change a human already scoped

Level 4: AI-native SDLC

What this looks like. AI becomes a collaborator with architectural awareness: generating full features from specifications, proposing structural changes aligned with technical strategy, producing comprehensive test suites, and auto-generating documentation. Agentic teammates work asynchronously and communicate proactively. Human review remains mandatory for critical workflows, and deployment is human-reviewed, not auto-approved.

What would place a company here, cited:

• A named agent that produces a full feature or a full pull request from a task description, operating across code, tests, and often documentation at once
• Every source agreeing that deployment and merge still require a human reviewer, with no described exception

What would move a company past this level:

• A described change-classification framework with at least one tier of change (documentation- only, say, or a narrowly defined low-risk category) that ships without a human reviewer

Level 5: AI-autonomous SDLC

What this looks like. AI is the primary implementer, end to end: analysis, code, testing, and updates, with humans reserved for strategic decisions, security-critical code, and verification. Deployment includes a real auto-approved path for at least one defined category of routine change, sitting inside a tiered approval framework (routine auto-approved; larger changes escalate to AI or human review by risk).

What would place a company here, cited:

• A described, quantified case of a change category shipping to production with no human reviewer in the loop, inside a stated risk- or category-based approval tier
• Automatic incident resolution or continuous architecture optimisation, with novel cases escalating to a human rather than every case requiring one

Confirm before crediting this level:

• Whether the auto-approved tier is narrow and explicitly bounded (a real Level 5 case) or the record is silent on what happens to most changes, which is an absence, not evidence
• Whether "AI-native" sophistication (rich context, full-feature generation) is being mistaken for autonomy at the deployment gate specifically, the row this model treats as decisive

---

Rules

1. Every claim toward a level must be citable. If a fact isn't in a source that can be linked, it doesn't count. No inference.
2. Placement is capped by disclosure, not by capability. A company may operate above its assigned level. That is a limit on the record, not a claim about the company.
3. State which of the five activities support the level and which don't, with citations, for every entry. A level without that breakdown is not publishable.
4. A level number is not a compliment or a criticism. A company can be disciplined and trustworthy at Level 2, and reckless at Level 4. This model scores how far a defined set of responsibilities has moved from human to AI, not how well an engineering org runs.
5. Note domain-specific maturity explicitly when the record shows it, rather than collapsing an uneven company into one flat number. An agent that makes production business decisions outside the software development lifecycle (a risk or fraud model, say) doesn't score against this model at all; say so rather than forcing a fit.