Keep your own record of what the agent got wrong

If your team uses Copilot’s coding agent or Claude Code, developers can already flag a bad change, and Codex lists a /feedback command. Each channel was built by the vendor. Anthropic’s page says reports go to Anthropic. Codex’s says logs go to its maintainers. None of the three says your team can get them back. If you want a record of what the agent gets wrong in your own code, plan on keeping it yourself.

A pilot has an end date. The agent doesn’t.

How fast it feels can point the wrong way

DORA’s survey changed its answer on speed in a year. METR’s studies of experienced open-source developers moved too.

• 2024: as AI adoption increased, it went with an estimated 1.5% decrease in delivery throughput and a 7.2% reduction in delivery stability.
• 2025: across nearly 5,000 technology professionals, AI adoption had a positive relationship with throughput and still a negative one with stability.

DORA report announcements, Google Cloud, 22 Oct 2024 and 23 Sep 2025. Survey relationships, which don’t show cause.

July 2025. 16 developers worked 246 issues in their own large repos, mostly with Cursor Pro and Claude 3.5 and 3.7 Sonnet, from Feb to Jun 2025.

• Before starting, they expected AI to speed them up by 24%.
• Measured, they took 19% longer.
• Afterward, they still believed AI had sped them up by 20%.

February 2026. 57 developers did 800+ tasks in an experiment that began in August 2025.

• Original developers: an estimated 18% less time with AI (interval: 38% less to 9% more).
• New developers: an estimated 4% less (interval: 15% less to 9% more).

METR, 10 Jul 2025 and 24 Feb 2026. METR calls the newer data “very weak evidence” of how much the effect has grown, and is redesigning the study.

So the speed question is open, and the people measuring it say so. One finding held still. DORA’s link between AI adoption and lower stability showed up in both years. And in early 2025, METR’s 16 developers believed the opposite of what was measured.

How fast the agent feels to your team is an impression, and an impression can point the wrong way. When I built a model monitor, nothing in production told me whether a prediction was right, so I watched what I could see: inputs, errors and latency. With a coding agent, you can watch each fix a developer makes.

The developer who rewrites it is your answer key

• 46% of 33,244 respondents said they distrust the accuracy of AI output in their workflow, and 33% said they trust it.
• The most-picked frustration, chosen by 66% of 31,476 respondents, was AI solutions that are “almost right, but not quite.”

Stack Overflow Developer Survey 2025, AI section

If your team reviews the agent’s changes before they merge, a person sees every one, and the almost-right ones get fixed right there. But unless someone writes it down, the fix is the only trace. And a fix doesn’t flag the agent’s mistake.

At SpaceX, my team owned three apps that tracked rocket parts. I built for all three. One of them, Issues, caught defects reported by shop-floor engineers. A coding agent’s mistakes get caught the same way, by the developer working on the change. So after the pilot, the developer who rewrites an almost-right change is the closest thing you have to an answer key.

None of the three vendor pages says your team gets the reports back

• GitHub Copilot coding agent: buttons to rate its pull requests and comments, plus @copilot mentions to iterate. GitHub says “Your feedback helps improve Copilot’s quality,” but the page doesn’t say where ratings go or whether your team can see them.
• Claude Code: a /bug command to report issues from inside the tool. The README says Anthropic collects feedback, including usage data such as code acceptances and rejections.
• Codex: /feedback sends logs to “the Codex maintainers,” per the CLI’s command list, but the page doesn’t say whether your team can see them.

Each vendor’s own page as of 22 Oct 2026: GitHub Docs; the anthropics/claude-code README; OpenAI’s “Slash commands in Codex CLI” page

That’s a fair design for a vendor. But a report you can’t get back can’t tell you how this model did in your code. If I were the vendor, I’d let a team export its own developers’ reports, each stamped with the model version and the date.

The record belongs with your team

Diagram: a developer rewrites an almost-right change. One arrow goes to the vendor channel (rating, /bug, /feedback) and on to the vendor’s next model. The other goes to your record (a label in your tracker) and on to your team, security, compliance. A dashed arrow marked with a question mark runs from the vendor’s next model back toward your team.

developer rewrites an almost-right change

vendor channel (rating, /bug, /feedback)

your record (a label in your tracker)

vendor’s next model

?

your team, security, compliance

I’d put a record your team owns even over a better next model from the vendor. A better model is the vendor’s job. Showing security and compliance what the agent got wrong, and what you did about it, is yours.

Log four things each time a developer overrides the agent

Keep the record where your developers already work, such as a label in your issue tracker. Each entry needs four things, and the last one is what lets you compare this quarter’s list with the last.

1. The task and the agent’s change, linked
2. Whether the developer rewrote it or rejected it
3. Why, in one line
4. The tool, the model version and the date

Before your next pilot review or renewal, ask each vendor where your developers’ reports go and whether your team can get them back. Then start the label anyway.