{ "@context": "https://schema.org", "@id": "https://aggr.aymericbeaumet.com/items/ampcode-com/2026-02-04-liberating-code-review/#webpage", "@type": [ "WebPage", "ArchiveComponent" ], "articleBody": "Code review has traditionally been tied to an interface where a human reads diffs. Now, we've fully decoupled the review agent from any UI, making it a composable and extensible subroutine that can be invoked from many different places where it is useful:\n\n- You can run `amp review` in the CLI to run the review agent directly\n- You can request a review in any thread using natural language like \"review the outstanding changes\" or \"review changes since diverging from main\"\n\nThis composability also means you can more easily close the loop by asking the main agent to automatically fix the issues found or by piping review comments into another command.\n\nInvoking the review agent directly using `amp review`:\n\nRequesting a review from within a thread: ![Review tool](https://static.ampcode.com/news/review-skill/cli_review.png)\n\n## Customizing Review with Checks\n\nYou can also define [*Checks*](https://ampcode.com/manual#checks) within your codebase. Checks are user-defined invariants or review criteria scoped to specific parts of your codebase. They are defined in `.agents/checks/` directories.\n\nHere's an example performance check, which you could save to `.agents/checks/perf.md`:\n\n```markdown\n---\nname: performance\ndescription: Flags common performance anti-patterns\n---\n\nLook for these patterns:\n\n- Nested loops over the same collection (O(n²) → O(n) with a Set/Map)\n- Repeated `array.includes()` in a loop\n- Sorting inside a loop\n- String concatenation in a loop (use array + join)\n\nReport the line, why it matters, and how to fix it.\n```\n\nThe `code_review` tool will kick off a separate agent for each check. This provides a stronger guarantee that each check will actually be checked than if the checks were embedded in a general context file like `AGENTS.md`.\n\nHere are some more examples of useful checks:\n\n- Performance best practices specific to your stack\n- Common anti-patterns your team has hit before\n- Security best practices or invariants\n- Migration reminders for deprecated APIs\n- Stylistic conventions that aren't in the linter\n- Compliance requirements\n\nChecks are scoped to the directory that contains `.agents/`, so a root `.agents/checks` directory would cover the entire codebase while `api/.agents/checks` would cover files under `api/`.\n", "authors": [], "captured_at": "2026-10-03T23:09:50.514863041+00:00", "category": "programming", "content_html": "

Code review has traditionally been tied to an interface where a human reads diffs. Now, we've fully decoupled the review agent from any UI, making it a composable and extensible subroutine that can be invoked from many different places where it is useful:

\n\n

This composability also means you can more easily close the loop by asking the main agent to automatically fix the issues found or by piping review comments into another command.

\n

Invoking the review agent directly using amp review:

\n

Requesting a review from within a thread: \"Review

\n

Customizing Review with Checks

\n

You can also define Checks within your codebase. Checks are user-defined invariants or review criteria scoped to specific parts of your codebase. They are defined in .agents/checks/ directories.

\n

Here's an example performance check, which you could save to .agents/checks/perf.md:

\n
---\nname: performance\ndescription: Flags common performance anti-patterns\n---\n\nLook for these patterns:\n\n- Nested loops over the same collection (O(n²) → O(n) with a Set/Map)\n- Repeated `array.includes()` in a loop\n- Sorting inside a loop\n- String concatenation in a loop (use array + join)\n\nReport the line, why it matters, and how to fix it.\n
\n

The code_review tool will kick off a separate agent for each check. This provides a stronger guarantee that each check will actually be checked than if the checks were embedded in a general context file like AGENTS.md.

\n

Here are some more examples of useful checks:

\n\n

Checks are scoped to the directory that contains .agents/, so a root .agents/checks directory would cover the entire codebase while api/.agents/checks would cover files under api/.

\n", "content_markdown": "Code review has traditionally been tied to an interface where a human reads diffs. Now, we've fully decoupled the review agent from any UI, making it a composable and extensible subroutine that can be invoked from many different places where it is useful:\n\n- You can run `amp review` in the CLI to run the review agent directly\n- You can request a review in any thread using natural language like \"review the outstanding changes\" or \"review changes since diverging from main\"\n\nThis composability also means you can more easily close the loop by asking the main agent to automatically fix the issues found or by piping review comments into another command.\n\nInvoking the review agent directly using `amp review`:\n\nRequesting a review from within a thread: ![Review tool](https://static.ampcode.com/news/review-skill/cli_review.png)\n\n## Customizing Review with Checks\n\nYou can also define [*Checks*](https://ampcode.com/manual#checks) within your codebase. Checks are user-defined invariants or review criteria scoped to specific parts of your codebase. They are defined in `.agents/checks/` directories.\n\nHere's an example performance check, which you could save to `.agents/checks/perf.md`:\n\n```markdown\n---\nname: performance\ndescription: Flags common performance anti-patterns\n---\n\nLook for these patterns:\n\n- Nested loops over the same collection (O(n²) → O(n) with a Set/Map)\n- Repeated `array.includes()` in a loop\n- Sorting inside a loop\n- String concatenation in a loop (use array + join)\n\nReport the line, why it matters, and how to fix it.\n```\n\nThe `code_review` tool will kick off a separate agent for each check. This provides a stronger guarantee that each check will actually be checked than if the checks were embedded in a general context file like `AGENTS.md`.\n\nHere are some more examples of useful checks:\n\n- Performance best practices specific to your stack\n- Common anti-patterns your team has hit before\n- Security best practices or invariants\n- Migration reminders for deprecated APIs\n- Stylistic conventions that aren't in the linter\n- Compliance requirements\n\nChecks are scoped to the directory that contains `.agents/`, so a root `.agents/checks` directory would cover the entire codebase while `api/.agents/checks` would cover files under `api/`.\n", "dateCreated": "2026-10-03T23:09:50.514863041+00:00", "date_created": "2026-02-04T00:00:00+00:00", "date_modified": "2026-02-04T00:00:00+00:00", "date_published": "2026-02-04T00:00:00+00:00", "description": "Code review has traditionally been tied to an interface where a human reads diffs. Now, we've fully decoupled the review agent from any UI, making it a composable and extensible subroutine that can be invoked from many different places…", "external_url": "https://ampcode.com/news/liberating-code-review", "git": { "commit": "ebb0941c5c06a2ab2377342d607535262a3e969e", "path": "items/ampcode-com/2026/02/2026-02-04-liberating-code-review.md", "permalink": "https://github.com/aymericbeaumet/aggr-instance/blob/ebb0941c5c06a2ab2377342d607535262a3e969e/items/ampcode-com/2026/02/2026-02-04-liberating-code-review.md" }, "id": "urn:aggr:item:c730e1dd069ee95024e0edc6830034a22c7ea589", "isBasedOn": { "@id": "https://ampcode.com/news/liberating-code-review" }, "mainEntity": { "@id": "https://ampcode.com/news/liberating-code-review", "@type": "CreativeWork", "archivedAt": { "@id": "https://aggr.aymericbeaumet.com/items/ampcode-com/2026-02-04-liberating-code-review/#webpage" }, "dateModified": "2026-02-04T00:00:00+00:00", "datePublished": "2026-02-04T00:00:00+00:00", "headline": "Liberating Code Review", "timeRequired": "PT2M", "url": "https://ampcode.com/news/liberating-code-review", "wordCount": 335 }, "name": "Archived snapshot: Liberating Code Review", "preview": null, "reading_minutes": 2, "replicated_at": null, "source": "ampcode-com", "source_name": "Amp News", "summary": "Code review has traditionally been tied to an interface where a human reads diffs. Now, we've fully decoupled the review agent from any UI, making it a composable and extensible subroutine that can be invoked from many different places where it is useful: You can run amp review in the CLI to run the review agent directly You can request a review in any thread using natural language like \"review the outstanding changes\" or \"review changes since diverging from main\" This composability also means you can more easily close the loop by asking the main agent to automatically fix the issues found or by piping review comments into another command. Invoking the review agent directly using amp review: Requesting a review from within a thread: Customizing Review with Checks You can also define Checks within your codebase. Checks are user-defined invariants or review criteria scoped to specific parts of your codebase. They are defined in .agents/checks/ directories. Here's an example performance check, which you could save to .agents/checks/perf.md: --- name: performance description: Flags common performance anti-patterns --- Look for these patterns: - Nested loops over the same collection (O(n²) → O(n) with a Set/Map) - Repeated `array.includes()` in a loop - Sorting inside a loop - String concatenation in a loop (use array + join) Report the line, why it matters, and how to fix it. The code_review tool will kick off a separate agent for each check. This provides a stronger guarantee that each check will actually be checked than if the checks were embedded in a general context file like AGENTS.md. Here are some more examples of useful checks: Performance best practices specific to your stack Common anti-patterns your team has hit before Security best practices or invariants Migration reminders for deprecated APIs Stylistic conventions that aren't in the linter Compliance requirements Checks are scoped to the directory that contains .agents/, so a root .agents/checks directory would cover the entire codebase while api/.agents/checks would cover files under api/.", "tags": [], "temporalCoverage": "2026-10-03T23:09:50.514863041+00:00", "title": "Liberating Code Review", "url": "https://aggr.aymericbeaumet.com/items/ampcode-com/2026-02-04-liberating-code-review/", "word_count": 335 }