Use case

Fix CI failures with Codna

A red pipeline blocks everyone behind it. Codna reads the failing job, maps what it touches deterministically, fixes the cause, and opens a pull request your own tests have already proven green.

The problem

A failing check is a symptom, not a location

The job log shows where CI gave up, not why it gave up. A build error, a broken import, or a failing assertion usually traces back to a change several files away, so the line that throws is rarely the line to edit. Engineers lose hours scrolling logs, re-running jobs, and bisecting commits just to localize the cause before any real work starts. To fix a failing build, you first have to understand how the failing step connects to the rest of the repo — and that context is exactly what a raw log leaves out. Codna anchors the failing step to its dependency and blast-radius graph, so the agent fixes the change that broke the pipeline instead of patching the symptom.

How Codna fixes it

How Codna turns red back to green

1

Triage the failing job deterministically

Codna maps the whole repo in about 60ms for zero LLM tokens and pins the failing CI step to the files and call paths behind it — no embeddings, no log copy-paste.

2

Fix from a ~600-token evidence bundle

Codna hands the agent a focused evidence bundle scoped to the real cause — 162x less context than reading the repo, so the fix targets the change that broke the build.

3

Open a test-verified PR

The patch runs against your own test suite before it lands, then the GitHub App opens a pull request with the root cause and a passing check attached.

codna fix . --issue "CI build failed: type error in checkout handler"

What you get

What you get on every red pipeline

Zero-token deterministic triage

A deterministic engine maps your repo and locates the failing job's blast radius for zero LLM tokens — no RAG, no embeddings, no waiting for an index to build.

Every fix verified by your own tests

A patch only lands after it passes the project's existing test suite, so a green PR means the failing build is genuinely fixed, not just quieted.

Runs on your real CI via the GitHub App

The native GitHub App watches the failing check and opens a fix PR directly. Codna also ships as a CLI and an MCP server for Cursor and Claude.

The proof

Fewer tokens. Faster. Verified.

Codna16K
Cline65K
Cursor81K
Total tokens to fix 8 verified bug-fix scenarios — measured head-to-head vs the Codex and Gemini CLIs.

Frequently asked

Point Codna at the failing job. It maps the repo deterministically, anchors the failing step to the files and call paths behind it, and works from a ~600-token evidence bundle — so you skip the manual log archaeology and go straight to the cause.

Yes. Codna produces a real patch and verifies it against your own test suite before anything lands. The GitHub App then opens a pull request with the fix, the root cause, and a passing check attached.

Yes. The native GitHub App watches the failing check, triages the job, and opens a fix PR automatically — no log copy-paste required. The same flow is available from the CLI and the MCP server.

Most assistants feed the log into an LLM and guess. Codna maps the dependency and blast-radius graph deterministically first, so the agent fixes the change that broke the pipeline instead of patching the line that happened to throw.

Codna maps the blast radius before it edits and then runs your test suite on the patch. A fix only opens as a PR when the checks pass, so regressions are caught before they reach you.

About $0.04 per verified fix. Codna does the repository understanding for zero LLM tokens, so the agent works from roughly 600 tokens instead of the entire repo.

Understand. Fix. Evolve.