Stop trusting polished AI code: enforce standards before merge
Two pull requests land in your queue. Both are formatted, summarized, and passing tests. One came from Cursor. The other from Claude Code. Your review process cannot tell you whether either change followed your architecture rules, reused approved helpers, or proved the behavior it touched.
A clean-looking PR now hides the work your reviewers still need to do. And picking one approved coding agent won’t fix that, because the approved tool will change. What needs to survive the next agent is your standard for what every code change must demonstrate before it merges.
Why Your Old Review Signals Broke
Reviewers used to rely on informal proxies. Sloppy formatting suggested a rushed change. A 900-line diff with no tests suggested weak scope control. A focused change in your team’s usual style suggested care.
AI-generated code breaks those links. An agent can produce formatted, confident code that still calls the wrong API, duplicates an existing helper, or misses an edge case. Polish is no longer a signal of quality.
The data backs this up. Stack Overflow’s 2025 developer survey found that 84% of developers use or plan to use AI tools, while 46% distrust the results. Another 45% say debugging AI-generated code takes more time. That’s widespread adoption paired with low trust and reported overhead on the back end.
The Maintenance Debt That Hides in Your Velocity Numbers
The debugging overhead shows up first in review comments and incidents. The maintainability debt arrives more quietly in your roadmap.
When AI-generated code duplicates existing logic instead of reusing it, you end up with near-matching helpers, copied business rules, and one-off implementations scattered across the codebase. The next change becomes harder. The next bug becomes harder to trace.
GitClear’s maintainability research, based on 623 million changes, found that moved code (existing logic relocated during refactoring rather than duplicated) fell from 21% of changed lines in 2022 to 3.8% so far in 2026. Copy-pasted code rose to 15.7% over the same period.
Your velocity dashboard can show more code shipped while missing the consolidation work that disappeared. Five copies of a pricing rule look productive until the rule changes and a developer updates only three. Those missing copies turn yesterday’s output into a production incident. Every hour tracing them comes out of next year’s roadmap capacity.
️ Layer 1: Write the Standard Where Agents Will Read It
The duplication and debugging problems share one missing control: your repository doesn’t tell coding agents what good work means for your codebase. The fix is an AGENTS.md file at your repository root. Compatible coding agents look there for repository-specific guidance.
For teams managing multiple repositories, a platform team should own a version-controlled AGENTS.md template covering shared security rules, dependency policy, and required evidence. Each service team adds local commands, ownership boundaries, and architecture rules in its own copy.
Give each repository’s AGENTS.md a named owner who removes outdated rules as well as adding new ones. Keep only three categories of content in the file:
- The exact build, test, and lint commands that CI checks run
- Local decisions an agent would otherwise guess: which module owns persistence, which shared utility already solves a problem
- Files the agent cannot change without approval: generated clients, vendored dependencies, migrations, permission checks
The placement rule matters. AGENTS.md holds guidance an agent must interpret. CI checks hold rules a machine can enforce. Don’t mix them.
⚙️ Layer 2: Let CI Enforce What Prose Can Only Request
A sentence in AGENTS.md can be misunderstood or skipped. A required CI check blocks the merge. Your CI pipeline should enforce formatting, strict type checks, tests, changed-lines coverage, dependency allowlists, and security scans.
Coverage needs one additional safeguard. An agent can raise coverage numbers without proving behavior. Require every meaningful new test to fail against the pre-change code. A pre-change failure gives reviewers evidence that the test exercises the changed behavior. Reviewers still need to confirm the intended reason for the failure, but at least the test isn’t decorative.
Keep the CI evidence after merge. NIST’s Secure Software Development Framework organizes secure development into practices, tasks, and implementation examples. Test reports, scan results, and build artifacts give auditors timestamped records. A reminder to be careful does not.
Layer 3: Make the Pull Request Carry Its Own Proof
CI catches configured rules. Architecture-fit questions are still reviewer judgments. And polish no longer proves careful work.
The security gap is measurable. Veracode’s spring 2026 code security update reports that AI coding assistants exceeded 95% syntax correctness while only about 55% of generated samples passed security testing. Code can look finished without being sound.
Your pull-request template should require evidence for the judgments CI can’t encode:
- Scope. Connect the diff to the ticket and identify any unrelated changes.
- Source evidence. Link the documentation or internal standard used for new dependencies, unfamiliar SDK calls, and security-sensitive patterns.
- Interfaces. Name any change to a public API, database schema, event schema, or permission model, along with the migration or approval record.
- Execution evidence. Attach test output, build logs, scan results, migration logs, and screenshots for UI changes.
An AI-written description saying all tests pass is a claim, not proof. When execution evidence is missing, return the PR before reviewing the diff.
How to Roll This Out Without Breaking Your Team
The strongest objection to this system is process weight. Controls that turn a five-minute change into an hour of gate-clearing invite people to route around them.
Keep each control in its right layer: CI owns deterministic rules, AGENTS.md owns repository-specific guidance, and the PR template owns required proof. Human reviewers then focus on two questions: does the change fit the architecture, and was the ticket the right change to make?
- Start with your highest-traffic repository.
- Record the rules your reviewers already enforce informally.
- Move three repeated review comments into CI checks.
- Add the four evidence fields to the PR template.
- Run the process for two sprints before expanding.
As you expand, the instruction format needs to outlive your current agent. The AGENTS.md format is now stewarded by the Linux Foundation’s Agentic AI Foundation. A durable standard is a system every tool has to survive. The tool can change. The receipt cannot.
I’m founder of BizStack at Cagri Sarigoz LLC and a passionate advocate for entrepreneurs.
With over 14 years in tech, marketing, and AI, including my role as Head of SEO at CitizenShipper and co-founder of TaleBot at Intale AI, I’m dedicated to sharing genuine, useful product insights and tips.
At BizStack, I aim to cut through the digital noise to provide clear, actionable advice.
And more than all else, I’m a father to a (always) little girl and a husband.
Contact me at [email protected] for assistance.
