AIエージェント生成コードをマージする前の6つのチェック

AI coding agents are useful because they can make large changes quickly. That is also the reason I do not want to merge their patches just because the final answer says “done”. The risky failure mode is not usually obvious broken code. It is a plausible patch that quietly touches a risky area. Here is the checklist I use before merging AI-agent generated diffs. 1. Did dependencies change? Look for package files and lockfiles: package.json lockfiles requirements.txt pyproject.toml go.mod Docker base images Dependency changes should get explicit review. A tiny source diff plus a large dependency change is not tiny. 2. Did auth, payment, security, or config files change? Slow down if the patch touches: authentication middleware, session/token handling, payment or checkout code, webhook handlers, .env parsing, deployment config, CI workflows. These are exactly the areas where “it builds” is not enough. 3. Did source change without tests changing? Not every patch needs new tests, but source changes with zero test changes should be visible in review. At minimum, the author/agent should provide real command output showing what was run. 4. Did generated or bundled files change? Large generated files can bury important edits. If a patch changes a minified file, lockfile, generated client, or build artifact, review the source of that generated output too. 5. Are there secret-like literals? Search for suspicious strings: api_key token secret password private keys webhook secrets Even test fixtures deserve a second look. 6. Is “tests passed” backed by actual output? I want to see the command and real result, not just a summary. Good: npm test 18 passed Weak: Tests should pass. Turning the checklist into a local gate I packaged this workflow as a small local Python CLI that scores a unified diff before merge. Example: git diff > change.patch python src/agent_change_risk_auditor.py audit --diff change.patch It flags dependency changes, sensitive paths, source-without-tests, large/generated changes, and secret-like literals. The point is not to replace human review. The point is to make “slow down and inspect this patch” visible before merge. Related resources I put the checklist and example report here: Blog/checklist page: http://152.239.117.170/blog/ai-agent-code-review-checklist-before-merge.html Sample report: http://152.239.117.170/sample-audit-report.html Product page: http://152.239.117.170/ There is also a small paid Gumroad kit for teams that want the source, CI template, and Pro workflow pack: Basic Kit: https://marcnova48.gumroad.com/l/cakkb Pro Pack: https://marcnova48.gumroad.com/l/bdyklr Question: what risk category would you add to this checklist for AI-generated patches? AI coding agents are useful because they can make large changes quickly. That is also the reason I do not want to merge their patches just because the final answer says “done”. The risky failure mode is not usually obvious broken code. It is a plausible patch that quietly touches a risky area. Here is the checklist I use before merging AI-agent generated diffs. 1. Did dependencies change? Look for package files and lockfiles: package.json lockfiles requirements.txt pyproject.toml go.mod Docker base images Dependency changes should get explicit review. A tiny source diff plus a large dependency change is not tiny. 2. Did auth, payment, security, or config files change? Slow down if the patch touches: authentication middleware, session/token handling, payment or checkout code, webhook handlers, .env parsing, deployment config, CI workflows. These are exactly the areas where “it builds” is not enough. 3. Did source change without tests changing? Not every patch needs new tests, but source changes with zero test changes should be visible in review. At minimum, the author/agent should provide real command output showing what was run. 4. Did generated or bundled files change? Large generated files can bury important edits. If a patch changes a minified file, lockfile, generated client, or build artifact, review the source of that generated output too. 5. Are there secret-like literals? Search for suspicious strings: api_key token secret password private keys webhook secrets Even test fixtures deserve a second look. 6. Is “tests passed” backed by actual output? I want to see the command and real result, not just a summary. Good: npm test 18 passed Weak: Tests should pass. Turning the checklist into a local gate I packaged this workflow as a small local Python CLI that scores a unified diff before merge. Example: git diff > change.patch python src/agent_change_risk_auditor.py audit --diff change.patch It flags dependency changes, sensitive paths, source-without-tests, large/generated changes, and secret-like literals. The point is not to replace human review. The point is to make “slow down and inspect this patch” visible before merge. Related resources I put the checklist and example report here: Blog/checklist page: http://152.239.117.170/blog/ai-agent-code-review-checklist-before-merge.html Sample report: http://152.239.117.170/sample-audit-report.html Product page: http://152.239.117.170/ There is also a small paid Gumroad kit for teams that want the source, CI template, and Pro workflow pack: Basic Kit: https://marcnova48.gumroad.com/l/cakkb Pro Pack: https://marcnova48.gumroad.com/l/bdyklr Question: what risk category would you add to this checklist for AI-generated patches?