AI Made Your Developers 10x Faster.
Did Your Engineering Practices Keep Up?

We Have a Measurement Problem

If you run an engineering org right now, you're getting asked two things at once: "Are we using AI?" and "How healthy is our engineering?" The first question is easy. The second one is where things fall apart.

DORA metrics are the closest thing we have to a standard. Deployment frequency, lead time, change failure rate, MTTR. They're useful for what they measure. But they were designed to answer a specific question about delivery throughput, and that question isn't the one engineering leaders are being asked anymore. The 2025 DORA Report found that AI adoption is actually increasing delivery instability even as individual developer velocity goes up. Teams are moving faster and breaking more things. DORA will tell you the "faster" part. It won't tell you why things are breaking.

Then McKinsey published their developer productivity framework, and the pushback was immediate and widespread. Kent Beck called it "absurdly naive." Gergely Orosz wrote a two-part takedown. Dan North did a line-by-line review. The core problem: McKinsey reduced software engineering to "time spent coding" and missed that the hard part of building software was never the typing.

On the other end you've got Gartner selling maturity assessments as consulting engagements. These are survey-based. You tell a consultant how mature you think you are, they put it in a proprietary model you can't see, and three months later you get a PDF with a score and some recommendations. It works for large enterprises with budget to burn, but it's a snapshot that starts going stale the moment it's delivered.

That quote stuck with me. The demand for engineering measurement isn't going away. If engineering leaders don't provide something constructive, someone else will impose something destructive. So I started thinking about what a useful answer would actually look like.

The AI Amplifier Effect

Here's what the 2025 DORA data showed that I think matters most: AI amplifies whatever's already there. Teams with strong engineering foundations used AI to get even better. Teams with weak foundations just produced more problems, faster. The AI didn't fix anything. It accelerated everything, including the dysfunction.

I've seen this play out firsthand. A team with solid code review culture adopts Copilot and their throughput jumps because reviews catch the AI's blind spots quickly. A team with rubber-stamp reviews adopts the same tools and now they're merging AI-generated code that nobody actually read. Same tool. Wildly different outcomes. The difference was the practices around the code, not the code itself.

There's a more practical angle too. AI lets smaller teams punch above their weight. Five engineers can cover what used to take fifteen. But that means each person is more critical, institutional knowledge is more concentrated, and the impact of someone leaving is bigger. Documentation, code ownership, runbooks, operational processes — all of that is higher stakes with a lean team.

The teams that got CI/CD right early won the last decade. I think the teams that build engineering maturity around AI adoption are the ones that will win this one.

Practices, Not People

I want to be clear about what this framework does and doesn't do. It does not measure individual developer productivity. That debate has been settled. Every serious researcher has landed in the same place: individual metrics create perverse incentives and corrode team culture. We're not going there.

What we measure is engineering practice maturity. The organizational habits that determine whether a team can ship reliably regardless of how fast they're moving. Is main protected? Do PRs get meaningful reviews? Is CI gating merges? Are incidents followed by postmortems? Does someone own each service?

You can have great DORA numbers with terrible security scanning, zero documentation, no incident response process, and no tech debt tracking. I've seen it. Velocity metrics won't catch it. A practice maturity assessment will.

The other thing that matters: these scores come from observable evidence in your existing tools. Branch protection settings. CI workflow configurations. Commit history. Release tags. Issue labels. The data is already sitting there in your GitHub, your Jira, your PagerDuty. Nobody's been reading it systematically until now.

The Framework

50 standards across 6 phases of the SDLC. Each scored 1–5 based on what we can actually observe.

How Scoring Works

Every standard gets scored 1–5 based on what we can observe in your tools. Branch protection is either configured or it isn't. Your CI workflow either runs security scans or it doesn't. Your last 100 commits either follow a convention or they don't. Some signals are strong (branch rules are binary), some are weaker (inferring test quality from CI config). So every score carries a confidence weight.

The whole thing is transparent. Every threshold, every scoring rule, every piece of evidence is visible. You can look at any score and see exactly what drove it. No black box. If you disagree with how a standard is scored, you can see the logic and decide whether it applies to your context.

Why Not Just Use What Exists?

Who This Is For

This was built for the people who get asked "how mature is our engineering?" and need a better answer than "I think we're doing okay." VPs of Engineering, Directors, CTOs, Staff+ engineers who own technical strategy.

It's especially relevant if you're in the middle of AI adoption and someone on the leadership team wants proof that engineering quality isn't slipping as output increases. Or if you've been told to "measure engineering productivity" and you'd rather steer that conversation somewhere useful before a consulting firm steers it somewhere harmful.

The framework is open. Use it directly if you want. Adapt it. Throw out the standards that don't apply to your stack. The point isn't to create another rigid model that everyone argues about. It's to make engineering maturity something you can observe and talk about concretely.