Sample
audit.

This is what you receive at the end of the two weeks. The company below, Lantern Freight, is fictional. The numbers and the failure modes are the ones I see most often, scaled to a 34-engineer team.

Prepared for the VP Engineering, Lantern Freight. Audit window: 90 days of history across 4 repositories, 1,212 merged pull requests.

1. Summary

Lantern Freight pays for 34 Cursor seats and 12 Claude Code seats. Sixty-one percent of merged pull requests in the window carried AI-assisted commits. Those changes were reworked within three weeks at more than twice the rate of hand-written changes, and they took a day longer to get through review. The cause is not the tools. It is five workflow gaps, four of which can be closed in 30 days on one team. The target for the pilot is to bring AI-assisted rework from 23.8% to under 16% on the Dispatch team, measured on the same git history that produced the baseline.

2. Baseline

All figures come from commit history and pull request metadata. AI-assisted changes were identified by Cursor and Claude Code co-author trailers plus the team's own PR label, cross-checked on a random sample of 60 pull requests with 93% agreement.

For comparison, the DORA 2025 programme reports that most teams see AI raise throughput while also raising instability, and that only teams with strong review and testing practices capture the gains. Lantern Freight is in the common position: more code, more rework, net velocity roughly flat.

3. Findings

Ranked by share of reworked lines they explain. I read every reverted pull request and a sample of 80 reworked ones to assign causes.

Finding 1. The model never sees the rules. (31% of rework)

None of the four repositories has a project instruction file. Engineers paste the same context into every prompt, and most do not. Generated code uses the wrong HTTP client, ignores the error-wrapping convention, and reinvents three internal helpers. Reviewers catch some of it. The rest is rewritten after merge when it breaks a pattern someone else depends on.

Fix: One instruction file per repository covering conventions, forbidden patterns and the helpers that already exist, plus a shared skill library for the six most common task shapes. Half a day per repository with the team lead.

Finding 2. Tests are written after the model is finished. (24% of rework)

Forty-four percent of AI-assisted pull requests add no test. In interviews, five of six engineers said they ask the model for the implementation first and the test "if there is time". The model writes code that satisfies the prompt, not the behaviour, and the gap surfaces in production two weeks later.

Fix: Flip the order. A prompt template that asks for the failing test first, a CI check that blocks merge when a change to src/ arrives without a change to tests/, and a one-hour session on how to read a generated test for what it does not assert.

Finding 3. Review is reading diffs, not checking claims. (19% of rework)

Median AI-assisted PR is 412 lines against 180 for hand-written. Reviewers scroll. The comments cluster on naming and formatting, which the model gets right, and miss behaviour, which it gets wrong. Three of the five reverts in the window were approved with a single comment.

Fix: A size gate at 300 lines, a review checklist for generated code focused on the five things models get wrong most often, and a code-review bot configured to flag untested branches and silent exception handling. The checklist is taken from chapter 12 of Debugging Is the Skill and adapted to Lantern's stack.

Finding 4. The wrong work is being delegated. (14% of rework)

Rework concentrates in two areas: the pricing engine and anything touching the legacy dispatch scheduler. Both are poorly documented, have thin tests, and are exactly where engineers lean on the model hardest because they do not understand the code themselves. The model does not understand it either.

Fix: A short written map of which areas are safe for generation, which need a human design first, and which should only be touched with a senior pairing. Document the scheduler's invariants once, with the model's help, so both humans and the tool stop guessing.

Finding 5. Tool configuration is a security gap, not yet an incident. (not a rework cause)

Nine Claude Code installations run with permission prompts disabled. Two have MCP servers configured with write access to the production ticketing system. One shared skill file contains a staging database connection string. No data left the company, but there is nothing that would have stopped it.

Fix: A baseline permission profile, MCP servers reviewed and scoped to read-only where possible, secrets moved out of shared files, and a two-paragraph policy engineers can actually follow. One day.

4. What is working

The Platform team's rework rate on AI-assisted changes is 11.2%, in line with hand-written code. They have an instruction file, write tests first by habit, and keep pull requests small. The pilot plan below copies what they already do rather than inventing something new. Two of their engineers have agreed to act as champions for the Dispatch team.

5. The 30-day pilot

Team: Dispatch, 9 engineers, the highest rework rate in the company at 29.4%. Metric: rework rate on AI-assisted changes, measured from git on days 0, 7, 14, 21 and 30. Target: below 20% by day 30, a reduction of one third. If the target is missed, the pilot is free.

• Week 1. Instruction files and skill library for both Dispatch repositories. Permission profile applied. Test-first prompt template introduced. Baseline confirmed with the team.
• Week 2. Size gate and test-presence check in CI. Review checklist adopted. Code-review bot configured. First weekly number.
• Week 3. Scheduler invariants documented. Delegation map agreed. Pairing on the three riskiest open tickets.
• Week 4. Hand-over. Champions run the weekly review. Final number. Written recommendation on whether, and how, to roll out to the other three teams.

6. What I need from you

• Read access to the four repositories and the pull request history for the pilot period. Revoked at day 30.
• Two hours a week from the Dispatch team lead, and one hour from each engineer in week one.
• Agreement on the metric and target above before day 0, in writing, so neither of us can move the goalposts.

7. Risks

The pilot can look better than it is if the team ships less. I report pull request volume alongside rework so a drop in output is visible. It can look worse than it is if a large planned refactor lands in the window. We agree before day 0 which work is excluded. Thirty days is short for a 21-day rework window, so the day-30 figure uses changes merged in the first three weeks, and I send a day-45 confirmation at no charge.

Request a free teardown of your repository