WHITEPAPER · APRIL 2026
A Framework for AI Code Observability in the Enterprise
For CTOs, VPs of Engineering, and CIOs accountable for AI investment outcomes.
Section 1
Enterprises increased AI coding tool budgets by an average of 86% in 2026[1]. Yet only 5% report measurable ROI[2]. The gap is not the technology — it is the absence of observability.
Standard engineering intelligence platforms (DX, LinearB, Faros) measure team-level activity: cycle time, deployment frequency, PR velocity. None of them measure what fraction of a commit was authored by AI, which agent produced it, or whether that code survives in production.
Without per-line attribution, three critical questions remain unanswered:
This paper proposes a measurement framework based on three KPIs (Adoption, Durability, Churn) and an open standard (git-ai v3.0.0) for capturing per-line AI attribution at commit time. The approach is local-first, vendor-portable, and compatible with existing engineering intelligence tools.
Section 2
AI coding adoption is at saturation. The relevant question is no longer "should we use AI?" but "is our AI investment producing measurable outcomes?"
of tech leaders integrated AI into their backends[3]
have not saved a single human headcount[3]
advertised productivity gains from AI coding tools[4]
actual measured slowdown in some studies[5]
of AI-generated code contains security vulnerabilities[6]
lost per developer per week to AI rework when AI > 40%[7]
The 39-point perception gap. Developers feel 20% faster with AI but, in measured studies, are 19% slower due to longer reviews and higher bug density[5]. Self-reported productivity is no longer a reliable signal.
Section 3
Engineering organizations have invested in measurement platforms for over a decade. DORA metrics, SPACE framework, DXI scores. None of them measure AI authorship.
Only 16.8% of organizations track investment per AI tool versus benefit[8]. Of the remaining 83.2%, most rely on developer surveys, anecdotal feedback, or no measurement at all. When the board asks if the AI budget is paying off, the honest answer is "we don't know."
| Platform category | What it tracks | Measures AI? |
|---|---|---|
| Engineering intelligence (DX, LinearB, Faros) | Cycle time, throughput, PR velocity, DORA | No |
| Code quality (SonarQube, Code Climate) | Static analysis, test coverage, complexity | No |
| AI gateways (LLM proxies) | Token consumption, API cost | Inputs only |
| Developer surveys | Self-reported satisfaction | Subjective |
| AI code observability (Obsly AI, git-ai) | Per-line attribution, durability, churn | Yes |
The gap is not in the data — git already stores everything needed. The gap is in capturing AI authorship at the moment of creation, before the signal disappears.
Section 4
The framework is built on three principles:
AI agents (Claude Code, Cursor, Codex, Windsurf) emit PreToolUse and PostToolUse hooks when they edit files. Capturing the diff at this moment is deterministic. Detection after the fact (e.g., AI classifiers on diffs) achieves <60% accuracy.
Attribution data is stored in refs/notes/ai as structured git notes following the open git-ai v3.0.0 standard. The data travels with the code, survives rebases via post-rewrite hooks, and is accessible to any tool that reads git.
Only metadata leaves the developer's machine: line numbers, agent identifiers, model names, timestamps. Source code is never transmitted. Compliance reviews pass on day one.
Section 5
Per-line attribution is the foundation, but the value comes from three derived metrics. These are the numbers a CTO should be able to recite for any quarter, repository, or vendor.
% of code lines attributed to AI agents in a given period
Adoption alone is not a quality metric. A vendor at 80% AI may be performing better or worse than one at 30%. The value of Adoption is contextual: it sets the denominator for the other two KPIs.
Industry benchmark: Healthy teams operate between 25–40%. Above 40%, rework rates increase 20–25%[7].
% of AI-attributed lines still present in HEAD after N days
The single most important metric. Durability separates valuable AI code from rework. A line that survives 30 days in production was worth generating. A line rewritten the same week was not — it consumed prompt tokens, review time, and trust.
Why it matters: Two vendors at 70% Adoption can have wildly different outcomes. One at 90% Durability is delivering value. One at 55% is generating rework you pay for twice.
% of AI-attributed lines rewritten by humans within N days
Churn is the inverse signal of Durability and the leading indicator of trouble. High churn means humans are systematically correcting AI output. It points to wrong tool choice, wrong prompts, or wrong domain fit.
Diagnostic value: Churn segmented by agent reveals whether the issue is the tool (Cursor 18% vs Claude 6% on the same repo) or the developer (one team 4%, another team 22% on the same agent).
The reading order matters. Adoption tells you the volume. Durability tells you the value. Churn tells you the friction. Reporting any of these three in isolation is misleading.
Section 6
AI code observability does not require a new SDLC. It is a layer added to existing repositories without disturbing developer workflow.
Week 1 — Pilot on a single repository
Install the CLI on three engineers' machines. Confirm hooks fire on every commit. Validate git notes appear under refs/notes/ai.
Week 2 — Connect the dashboard
Install the GitHub App. Verify that pushed commits appear with their attribution. Establish baseline Adoption / Durability / Churn for the pilot repo.
Weeks 3–4 — Roll out to one team
Onboard a complete engineering team. Compare per-developer metrics privately. Identify high-Durability and high-Churn patterns for coaching.
Month 2 — Vendor visibility
For organizations with external vendors, invite them as data providers. Establish quarterly review cadence with KPIs as agenda.
Quarter 1 — Board-ready report
First quarterly report with three numbers: Adoption, Durability, Churn. Trend line. Vendor comparison. The report your CFO has been asking for.
Section 7
The following scenario is illustrative and based on patterns observed in 2026 industry research. Names are anonymized.
A European retail bank engages two consultancies to deliver a new mobile banking platform. Both vendors charge equivalent rates per developer. After Q1, the bank's procurement team requests AI code attribution data from both vendors.
Vendor A
Vendor B
The reading: Vendor B uses AI more aggressively (82% vs 68%) but produces code that gets rewritten almost a quarter of the time. The bank pays for both the original generation and the rework. Vendor A uses AI less but with substantially better outcomes.
The conversation that follows: The bank does not need to terminate Vendor B. With this data, they can ask specific questions: which agents are being used, on which file types, by which teams. The data turns a vague concern into a structured procurement discussion.
Section 8
AI coding tools are not the problem. The absence of measurement is. Enterprise budgets have grown faster than the instruments to evaluate their return.
The framework proposed in this paper is intentionally minimal: three KPIs, one open standard, no source code transmission. It complements rather than replaces existing engineering intelligence platforms. It produces numbers a CTO can take to a board meeting and a procurement team can take to a vendor review.
The companies that adopt this layer in 2026 will be the ones that can answer, in twelve months, the only question that matters: did the AI investment pay off?
In one sentence
Without per-line attribution, AI coding investment is a faith-based exercise. With it, it becomes a managed program with KPIs the same as any other infrastructure spend.
Appendix
Obsly AI implements the git-ai v3.0.0 specification, an open standard for AI code attribution stored as git notes under refs/notes/ai. The format is human-readable, version-controlled, and portable across tools.
Organizations adopting the standard retain full data portability. If a tool change is required for any reason, the underlying attribution data is independent of the analytics platform reading it. This is the same principle that made OpenTelemetry the default for observability instrumentation: the data outlives the vendor.
For the technical specification, see github.com/git-ai-project/git-ai.
References
Obsly AI is the reference implementation of the framework described in this paper. Free for individual developers. Per-seat for teams. Custom for enterprise.