Artificial Intelligence, zBlog
What a Number Between 1 and 5 Actually Tells You About Your AI-Assisted SDLC
trantorindia | Updated: August 28, 2026
Two weeks ago we started auditing one system’s AI-assisted software development lifecycle. We scored it across nine dimensions, re-scored it after every significant change, and tracked the number as it moved toward 5. The score went 0, 0.9, 1.0, 1.3, 2.0, 2.6, 3.0, 3.2, 3.3, then down to 2.8, and back up to 3.4. That drop is not a footnote. It is the most important thing this assessment produced.
Every engineering organization now says some version of “we use AI in our development process.” Almost none of them can say what that actually means. A developer with Copilot on, a gate in CI that blocks a merge, and a skill file nobody has opened in three months are three completely different realities, and “we use AI” collapses all of them into one sentence. You cannot improve what you cannot tell apart.
What is an agentic SDLC maturity assessment?
An agentic SDLC maturity assessment scores an engineering organization across multiple dimensions of AI-assisted software delivery, from context engineering and tool adoption through governance controls and CI/CD AI gates. A single aggregate score hides more than it reveals. Scoring dimensions separately shows where to invest next and whether gains are coming from fast-moving engineering work or slow-moving organizational approvals.
Why One Score Is Not Enough
A team can have excellent AI code review and no test generation whatsoever. A team can have beautifully documented context for its agents and zero CI/CD gates enforcing anything. Averaging those into one number erases the information you actually need: where to invest next.
We used nine dimensions instead.
| Dimension | What it actually measures | Score |
|---|---|---|
| context_engineering | Is there a single, current source of truth the agent reads, or scattered and stale docs? | 4/5 |
| tool_adoption | Are agentic tools (skills, MCP servers, CLIs) actually wired in and used? | 4/5 |
| workflow_integration | Do agents participate in real dev workflows, or sit off to the side? | 4/5 |
| code_review_ai | Is there AI review in the loop, and does a human still sign off? | 5/5 |
| governance_controls | Are permissions, allow/deny lists, and escalation paths defined? | 2/5 |
| skill_coverage | Do domain-specific skills exist for the repo’s actual recurring tasks? | 4/5 |
| agentic_autonomy | How much can an agent do unsupervised, safely? | 3/5 |
| test_generation | Can the system generate or gap-fill tests that match repo conventions? | 3/5 |
| cicd_ai_gates | Does any of this actually block a bad merge, or is it all advisory? | 1/5 |
We did not score any of this by hand. We built a dedicated skill that walks the repo against the nine-dimension rubric and renders the result the same way every time. The audit is a rerunnable measurement rather than a one-off opinion.
Five of nine dimensions are still short of a 5. That is exactly the point. A scorecard that looks good across every dimension on the first pass is a scorecard that was not measuring anything hard.
The Score Journey Was Not a Line
That 0 is Level 0, Unaware: the score before any audit had run at all. The sequence was 0, 0.9, 1.0, 1.3, 2.0, 2.6, 3.0, 3.2, 3.3, then 2.8, then 3.4.
“A maturity assessment that only ever goes up is not measuring anything real.”
context_engineering had been the strongest dimension, sitting at 5, on the strength of a single document tree every agent config pointed back to. Then the code changed shape, the way code does, and the docs did not. Five stale file references crashed that dimension from 5 to 1 and dragged the whole score down half a point.
STALE REFERENCE INCIDENT: The fix was not clever: find the stale references and correct them. The finding is worth keeping. A maturity dimension built on documentation is only as durable as the process keeping that documentation in sync with the code it describes. A 5 achieved once and never re-verified is not a 5. It is a snapshot with an expiration date nobody wrote down.
What Moved Fast, and What Did Not
Some gains were cheap. Formalizing an “Explorer” role, a read-only skill that only produces a design document and touches no code, moved skill_coverage and workflow_integration at once. Low-risk work that is immediately useful is close to free maturity.
Other gains were not up to engineering at all.
cicd_ai_gates stayed at 1 out of 5 for the entire two weeks. Not for lack of work. The two things that would have moved it, an IAM trust policy and a fine-grained PAT, were both waiting on organizational approval. The workflow was designed. The config existed. The number did not move because a permissions request was sitting in a queue.
KEY FINDING: The lowest-scoring dimension in an assessment like this is often blocked by governance latency, not technical debt. The fix for one looks nothing like the fix for the other. Tracking the blocker type is as important as tracking the score.
governance_controls flagged a quieter version of the same problem: a danger-zone sign-off list that exists only in prose, with nothing in the tool’s own permission config stopping an edit it is supposed to require approval for. Documented scope is not enforced scope. A dimension should stay capped until that gap closes.
Three Things That Actually Generalize
Score dimensions separately.
Documentation-adjacent scores jump and regress fast. Governance-adjacent scores move slowly because they depend on people outside engineering. Averaging hides that difference and points you at the wrong fix.
Re-verify. Do not just audit once.
The biggest swing in two weeks came from a dimension nobody re-checked after the underlying system changed. Your highest scores are usually your oldest ones and the most likely to have quietly drifted.
Separate “not done” from “done but blocked.”
A dimension stuck at 1 on an unapproved IAM policy needs a completely different intervention than one stuck at 1 because nobody built the gate. Track the blocker type, or the score sends people toward the wrong work.
Where This Leaves Us
We are at 3.4 across nine dimensions. The target is 5 on every row, not a good-looking average. What matters is that it is a 3.4 we can defend line by line, with a specific next action for anything below 5, and we will run it again on the same rubric next month to see what moved.
If your engineering organization is saying “we use AI in our development process” without being able to say what that means in measurable terms, this is what measuring it looks like. The number is not the goal. The line-by-line defensibility is.
At Trantor, we run agentic SDLC maturity assessments as a structured engagement: nine-dimension scoring against a consistent rubric, re-runnable as a tracked measurement rather than a one-off opinion, with specific next actions for every dimension below 5. If your organization wants to know what “we use AI” actually means in your development process, we are ready to help you find out.
Explore Trantor’s AI Engineering Services: Artificial Intelligence
