Written by: Mark Hull, Co-Founder and CEO, Exceeds AI | Last updated: July 4, 2026
Key Takeaways on Jellyfish and AI Code Quality
- Jellyfish relies on metadata signals like code churn, PR throughput, and DORA metrics to evaluate AI-generated code quality without inspecting the code itself.
- Its integrations with Git, Jira, CI/CD, and SonarQube provide broad visibility but lack line-level attribution of which AI tool produced specific commits.
- Proxy metrics such as review iterations and churn rates cannot distinguish between AI-authored and human-authored code or track long-term technical debt.
- Limitations in multi-tool visibility and longitudinal tracking make it difficult for leaders to justify AI spend or identify which tools deliver the strongest outcomes.
- Exceeds AI fills this gap by delivering code-level provenance and actionable insights that track which AI tools produce specific code outcomes.
How Jellyfish Connects to Your SDLC Stack
Jellyfish connects to the core SDLC stack: Git hosts (GitHub, GitLab, Bitbucket), work-tracking systems (Jira, Linear, Azure DevOps), CI/CD pipelines, and static analysis tools including SonarQube. These integrations feed a unified engineering management dashboard that surfaces allocation breakdowns, delivery forecasts, and throughput trends. Some configurations also ingest AI tooling telemetry, such as acceptance rates from GitHub Copilot, when vendors expose that data via API. The integrations are broad, but every signal they produce is metadata: event timestamps, state transitions, and aggregate counts rather than the contents of the code itself.
Jellyfish AI Code Quality Metrics and Their Limits
Jellyfish surfaces four primary proxy signals for evaluating AI-assisted development. Code churn tracks lines rewritten or deleted shortly after merge, a signal that GitClear’s analysis of 211 million lines of code found rising from a 3.3% pre-AI baseline to between 5.7% and 7.1% as AI coding tools gained adoption. Review iterations count how many cycles a PR requires before approval, a proxy for initial code quality. PR throughput measures merged PRs per engineer per period, a metric that Jellyfish’s own analysis of 20 million pull requests found correlating with roughly 2x output under full AI adoption, though Faros AI telemetry showed PR review times simultaneously increased 91% and PR sizes inflated 154%. DORA metrics, including deployment frequency, lead time for changes, change failure rate, and time to restore service, round out the framework as lagging indicators of delivery health.
Each of these signals is useful in isolation and helps describe overall delivery patterns. None of them can tell you whether the code that produced them was written by Cursor, Claude Code, GitHub Copilot, or a human engineer working without AI assistance at all.
How Jellyfish Uses SonarQube for Quality Signals
Jellyfish ingests SonarQube findings as an additional quality proxy, surfacing static analysis results such as security vulnerabilities, code smells, and coverage gaps alongside throughput and DORA data in a single dashboard. SonarQube performs automatic PR and branch analysis triggered with every build, providing early insight into proposed changes before merging. When Jellyfish pulls those results, engineering leaders gain a richer picture of quality trends over time.
The limitation is structural. SonarQube reports what static analysis found in the diff, but it does not record which AI tool generated the lines that triggered the finding. Classic SonarQube-era metrics such as debt ratio and maintainability grade were calibrated for human-authored code and under-report the duplication and inlined-complexity patterns specific to AI output. Jellyfish inherits that blind spot when it ingests SonarQube data, so the findings are real, but their provenance is invisible. This SonarQube limitation is one symptom of a broader architectural constraint in Jellyfish’s metadata-only approach.
Jellyfish vs Code-Level AI Provenance
Three documented limitations define the boundary of what Jellyfish’s proxy model can answer for engineering leaders who must justify AI spend.
First, per-tool attribution is structurally absent. When a team runs Cursor for feature work, Claude Code for refactoring, and GitHub Copilot for autocomplete simultaneously, the dominant pattern today where 95% of professional developers use AI coding tools at least weekly with Claude Code as the most popular tool, Jellyfish’s dashboard shows aggregate throughput with no per-tool breakdown. A VP of Engineering cannot determine which tool is driving outcomes from metadata alone.
Second, Jellyfish has no longitudinal technical-debt tracking anchored to AI authorship. An empirical study of 302,579 verified AI-generated commits found that more than 15% introduce at least one issue, and 22.7% of those issues survived the latest repository revisions. Metadata dashboards that measure churn at merge time cannot track whether AI-touched code causes incidents 30, 60, or 90 days later, because they never recorded which lines were AI-generated in the first place.
Third, multi-tool visibility is structurally absent. Surveys show 67-75% of organizations lack full visibility into AI deployment or software usage, with no data confirming 81% for the development lifecycle, and Jellyfish’s integration model, dependent on vendor-exposed telemetry, goes dark when engineers use tools that do not publish acceptance-rate APIs. Without visibility into which tools are being used and how they perform, engineering leaders cannot make data-driven decisions about AI investments.
See which AI tools are actually driving outcomes—book a demo
Measuring AI Code Quality Beyond Metadata
Exceeds Ink is the provenance layer that supplies what Jellyfish’s proxy signals cannot. It is a lightweight on-machine capture tool that writes a structured attestation as a Git Note alongside every commit, recording which AI tool produced which lines, in which interaction mode (plan, ask, agent, edit, or headless), at what token cost, and in which session. That attestation lives in the repository itself, travels across forks and mirrors, and is readable by any Git client without requiring access to Exceeds’ platform.
Per-tool checkpoint materializers for Claude Code, Cursor, and Codex resolve edit evidence against the actual working tree at commit finalization. A multi-edit Cursor session correctly retains human-typed lines, and a Claude Code rewrite is attributed to Claude, not collapsed into an undifferentiated “AI-assisted” bucket. Lines that cannot be confidently attributed are recorded as unknown rather than silently assigned to either category.
The platform then tracks those attested lines longitudinally. Where Jellyfish’s churn metric measures rework at the PR level without knowing whether the churned lines were AI-generated, Exceeds AI monitors AI-touched code over 30-plus days for incident rates, follow-on edits, and maintainability patterns, the exact signals that DORA 2025 research identified as the stability dimension that AI adoption continues to pressure even as throughput improves.
For engineering leaders running Cursor, Claude Code, Codex, GitHub Copilot, and Windsurf concurrently, Exceeds AI provides a cross-tool outcome comparison that no metadata platform can replicate. Leaders can see which tool produces code with lower rework rates, which interaction mode correlates with higher test coverage, and which teams have adoption patterns worth scaling across the organization.
Setup is hours, not months. First insights are available within an hour of connecting your GitHub repository. Board-ready ROI reports are available within weeks, compared to the multi-month integration timelines typical of metadata platforms.
Get ROI visibility in hours, not months—book a demo
Frequently Asked Questions
Does Jellyfish inspect the code?
No. Jellyfish operates on metadata: event timestamps, state transitions, PR counts, and aggregate signals from Git, Jira, SonarQube, and CI/CD systems. It does not read code diffs at the line level, does not record which lines were AI-generated versus human-authored, and does not analyze the contents of commits to determine authorship. SonarQube findings ingested by Jellyfish reflect static analysis results, but those results carry no record of which AI tool, if any, produced the flagged lines. The practical consequence is that Jellyfish can report that a PR had high churn or required many review iterations, but it cannot show whether that churn originated from AI-generated code, which tool produced it, or whether the pattern is improving or worsening over time.
Can Jellyfish tell which AI tool produced a given commit?
Not with line-level fidelity. Jellyfish can ingest telemetry that AI vendors expose via API, such as GitHub Copilot’s acceptance rate data, but this depends entirely on what each vendor chooses to publish. When engineers use terminal-based agents like Claude Code or Codex, IDE agents like Cursor, or any tool that does not expose a telemetry API, those contributions are invisible to Jellyfish’s integration layer. In a multi-tool environment where engineers switch between several assistants across a single sprint, Jellyfish’s dashboard shows aggregate throughput with no per-tool attribution. Answering which tool drove a specific outcome requires client-level capture at the moment the work is done, the architectural approach Exceeds Ink takes, rather than post-hoc ingestion of vendor-published telemetry.
How long does it take Jellyfish to show AI ROI?
Jellyfish implementations commonly take approximately nine months before delivering meaningful ROI visibility. That timeline reflects the complexity of connecting Git, Jira, financial systems, and SDLC tooling into a coherent allocation model, plus the time required to establish baselines before trend analysis becomes actionable. For engineering leaders who must answer board questions about AI spend in the current quarter, a nine-month runway is a structural problem. Exceeds AI delivers first insights within 60 minutes of GitHub authorization and complete historical analysis within four hours, because its analysis starts from the repository rather than requiring a multi-system integration project.
What visibility do engineering managers actually receive from Jellyfish?
Jellyfish is primarily positioned as an executive and financial reporting tool, surfacing engineering allocation, throughput trends, and DORA metrics for CTOs and CFOs. Engineering managers receive the same metadata dashboards: PR cycle times, review latency, commit volume, and DORA breakdowns by team. They do not receive guidance on what to do next. There are no coaching surfaces, no per-tool outcome comparisons, no interaction-mode breakdowns that reveal whether engineers are using AI in plan mode versus agent mode, and no longitudinal tracking of whether AI-touched code in their team’s repositories is accumulating technical debt. Jellyfish describes what happened; it does not prescribe what to change.
Get actionable coaching insights for your engineering teams—book a demo
Decision Lenses for Engineering Leaders
Engineering leaders evaluating measurement approaches for AI-generated code quality should apply eight decision criteria before committing to a platform. These criteria fall into three categories: deployment complexity, measurement depth, and organizational fit. Each criterion reveals a fundamental tradeoff between metadata-based and code-level approaches.
Implementation model. Proxy-based platforms like Jellyfish require multi-system integration projects measured in months. Client-level provenance tools like Exceeds Ink deliver attestations from the first commit after installation. The implementation model directly determines what data sources become available.
Data sources. Metadata platforms read event logs and vendor telemetry. Code-level platforms read the diffs themselves, capturing what was actually written and by which tool. The choice of data sources then shapes how deeply a platform can describe engineering work.
Visibility depth. Metadata visibility stops at the PR boundary. Line-level visibility extends to individual commits, interaction modes, session context, and token cost. Deeper visibility supports more precise coaching and more confident AI investment decisions.
Actionability. Dashboards that describe throughput leave managers to infer what to change. Platforms with coaching surfaces and best-practices insights distribute guidance directly into the workflows where engineers work. That guidance turns raw metrics into concrete behavior change.
Security. Repo access is the prerequisite for code-level analysis. Leaders should evaluate whether the platform stores source code permanently, how it handles prompt content, and whether attestations live in their own repository or in a vendor’s proprietary cloud.
Integrations. Teams should confirm that the platform supports every AI tool they use, not just the one that publishes a telemetry API, and that it connects to their existing Git host, work-tracking system, and data warehouse. Broad integration coverage prevents blind spots in AI usage.
Pricing. Per-contributor pricing penalizes team growth. Outcome-aligned pricing tied to manager seats keeps incentives pointed at results rather than headcount and aligns spend with decision-makers.
Team-size fit. Metadata platforms built for financial reporting deliver the most value at the executive layer in large organizations. Code-level AI analytics platforms deliver the most value to engineering managers at companies with 50 to 1,000 engineers who need to prove ROI and scale adoption simultaneously.