There's a metric missing from every engineering dashboard I've ever seen.

Velocity? Covered. Deployment frequency? Tracked. Code review turnaround? Obsessed over. But nobody is measuring the most fundamental shift to happen to software development in decades: how much of your shipped code was actually written by a human.

Not estimated. Not surveyed. Measured.

---

The AI Adoption Illusion

Most engineering organisations will tell you they've "adopted AI". Tooling is installed. Usage dashboards show completions accepted, lines suggested, time saved.

But those metrics answer the wrong question.

They tell you how often a developer pressed a key. They don't tell you whether the code that ended up in your main branch — the code that runs in production, that carries your business logic, that your team will maintain for the next three years — was understood, shaped, and owned by the person who committed it. Or whether it was accepted wholesale, skimmed, and shipped.

That distinction matters more than any productivity metric.

---

The Hidden Split in Every Commit

When a developer pushes code today, that commit contains a mixture. Some lines they typed character by character. Some were suggested by an AI and accepted as-is. Some were AI-generated and then meaningfully edited. Some were deleted entirely after review.

Right now, that split is invisible. It lives nowhere. No tool surfaces it. No report captures it. Engineering leaders are making decisions about team structure, hiring, code quality, and technical risk without knowing one of the most important facts about their codebase.

---

What We Measure

At the commit level, for every file, across every developer in your organisation, we track:

• Lines of code attributable to AI generation
• Lines written or meaningfully modified by a human
• AI-generated lines that were subsequently edited by a human
• Lines that were deleted before shipping

Every commit produces a clean report. AI written, human written, the ratio, the trend over time.

No self-reporting. No surveys. No guesswork.

---

Why This Is a Leadership Question, Not a Developer Question

Individual developers know roughly how much AI they're using. What they can't tell you is what that looks like at the team level, the repo level, or the organisation level — and how it's changing week over week.

That's a leadership visibility problem.

Consider what becomes possible when you have this data:

Code review calibration. A commit that is 80% AI-generated probably warrants a different review posture than one that is 80% hand-written. Not necessarily more scrutiny — but different scrutiny. Reviewers who know the provenance of code can ask better questions.

Onboarding and ownership signals. A new hire whose commits are 95% AI-accepted from day one is not learning your codebase the same way as one who is reading, writing, and iterating. That's not a judgement — it's a signal worth understanding.

Technical debt attribution. When something breaks six months from now, knowing whether the relevant section was AI-generated and never meaningfully reviewed is genuinely useful diagnostic information.

Honest AI ROI. If your AI tooling is generating 70% of committed lines and your deployment frequency hasn't changed, that's a conversation worth having. If it's generating 30% and velocity has doubled, that's a different conversation.

None of these conversations are possible without the underlying measurement.

---

The Number Will Surprise You

In our experience, the AI/human split in teams that consider themselves "moderately AI-assisted" is almost always higher than anyone expects. Not because developers are being careless. Because AI tools are genuinely good now, and accepting a well-formed suggestion is often the right call.

But there's a difference between a team that knows their split is 65% AI and is making deliberate decisions because of it, and a team that assumes it's 30% and has never checked.

The first team is in control. The second team is flying blind.

---

What This Is Not

This is not a tool to surveil developers or penalise AI usage. The goal is not to drive the number down.

Some of the most effective engineers we've seen in practice use AI heavily and produce exceptional output. The ratio is not a quality score.

It is a data point — one that belongs in the same category as test coverage, review cycle time, and incident frequency. Background signal that, when something goes wrong or something goes unusually right, helps you understand why.

---

Where We Are

SignalsAI is currently in early access with a small cohort of engineering organisations. We are working with teams who want to understand their codebase at a level that existing tooling doesn't support.

If you lead an engineering team and this is a number you want to know — we'd like to talk.