Fewer moving goal posts for more reliable commits
An agent hit a blocking finding on commit, fixed it, introduced a second one, caught that too, and committed once both passed. It only worked because the gate said the same thing every time.
What the corpus shows: incident analysis, defect patterns, and the numbers behind them.
An agent hit a blocking finding on commit, fixed it, introduced a second one, caught that too, and committed once both passed. It only worked because the gate said the same thing every time.
The catch during review comes down to a memory someone happened to have. If remembering can be made cheap and put in the diff, review can stay thorough while code volume climbs.
Security moved from a late scan to a check where developers work, and it worked. The same shift is available for reliability, at authorship time, before commit.
In a 2025 study of 470 pull requests, AI-written code shipped ~1.7x more issues and ~1.4x more critical defects. Catch reliability risk before you commit.
We had an AI quality metric that was stable across model tiers, improved when we refined the system, and measured something tied to proprietary knowledge. Then we built a counterfeit with almost none of the relevant expertise and it scored 0.99. A metric is not trustworthy because the real system passes. It becomes trustworthy when the fake fails.
GitHub's February availability report documents two incidents an hour apart with the same root cause. The first mitigation was correct for what the team could see, and it was not the fix. This is a reading of the public report through two lenses, one heuristic and one systems-theoretic.
The DORA 2026 ROI report names the productivity dip of AI adoption and prices it. The verification tax it names is the same cost vibe coding pushes onto a tired reviewer.