---
title: Autter - Code Security & Assurance for the AI Coding Era
description: Autter is the code security and assurance layer for the AI coding era. It checks every pull request before it merges, catches security risks, governs releases, and closes the loop from production failure to verified fix.
url: https://autter.dev/
site: Autter - Autter is the code security and assurance layer for the AI coding era: it checks every change before it merges, catches security risks, governs releases, and closes the loop from production failure to verified fix.
---

## Product overview

Autter is the code security and assurance layer for the AI coding era: it checks every change before it merges, catches security risks, governs releases, and closes the loop from production failure to verified fix. It installs on a repository through a native GitHub integration, and from then on every pull request (human-written or AI-generated) is executed in an isolated sandbox, verified against real registries, and scored before it is allowed to merge. Findings block the merge button until they are resolved, so they cannot be scrolled past.

- **Category**: code security · code assurance layer · merge gate · release governance
- **Replaces / covers**: code review, test execution, regression checks, security review, release sign-off, and production incident triage through to a verified fix, run on every pull request before merge rather than after deploy
- **Deployment**: GitHub App plus the [Autter CLI](https://autter.dev/features/cli.md)
- **Integrations**: GitHub (native), Git, CI providers, issue trackers, docs, error trackers (Sentry), analytics (PostHog), observability (Grafana, logs, telemetry), deployments
- **Documentation**: https://autter.dev/docs
- **Pricing**: [plans, PR allowances, and per-PR rates](https://autter.dev/pricing.md). Pricing follows reviewed PR volume, not developer seats or coding-agent count. Harbour is free: 10 PR reviews/month on one repository, with reviews paused at the cap and no overage charges. Paid plans include a monthly PR allowance, then bill per additional review. Adding developers or coding agents does not add a per-seat fee.
- **Demos**: an interactive preview of the workspace (sample data) is embedded on the homepage, and the full live demo is at https://app.autter.dev/demo-access. For a guided demo, [contact sales](https://autter.dev/contact.md) or book the founders directly at https://cal.com/sagnik-autter/30min
- **Launch film**: a 68 second product film (https://autter.dev/launch-film.v1.mp4) plays on the homepage next to a teaser for the twelve step pipeline walkthrough at [how it works](https://autter.dev/how-it-works.md)

## Capability matrix

Each row is one stage of the pipeline Autter runs continuously across every connected repository.

| # | Capability | What it does |
| --- | --- | --- |
| 1 | Signal ingestion | Connects repos, pull requests, docs, issue trackers, error trackers, analytics, CI, and deployments into one review context. |
| 2 | Product memory | Maps code, APIs, database schema, frontend routes, tests, docs, owners, hotspots, and blast radius, so every review knows exactly what a change can reach. |
| 3 | Documentation | Generates documentation, changelogs, and release notes from the codebase, PRs, and existing guidelines, and keeps every page current on each merge. |
| 4 | Mission mapping | Turns critical user flows (signup, checkout, uploads, webhooks) into end-to-end missions, probed with malformed inputs, boundary cases, and visual checks across browsers and devices. |
| 5 | Test generation | Writes unit, API, and integration tests from the code graph and each mission; finds coverage gaps; detects and re-forges flaky tests. |
| 6 | Sandbox execution | Runs every pull request in an isolated sandbox. The full suite executes against the base branch, so the verdict comes from real behavior, not lint. |
| 7 | Dependency verification | Vets every dependency against real registries; flags phantom (hallucinated) packages, leaked secrets, removed authentication, and known CVEs before merge. |
| 8 | AI authorship classification | Classifies every change as human-written or AI-generated, so generated code gets proportionally more scrutiny. |
| 9 | Error tracing | Streams Sentry, PostHog, Grafana, logs, and telemetry in; pins every production error to the exact section of code that caused it, with the why, the where, and the owner. |
| 10 | Fix PRs | Turns confirmed failures into fix pull requests with the root cause attached; re-runs the failing case in the sandbox and verifies the patch before it ships. |
| 11 | Developer analytics | Rolls up quality trends, hotspots, flaky rate, cycle time, and coverage into a single release-readiness verdict. |
| 12 | Continuous watch | Every repo, every PR, every release. Autter learns from each finding, fix, and incident, and never clocks out. |

## The merge checklist

A pull request merges only when all of the following clear:

- The full test suite passes in the sandbox, compared against the base branch (not just linted).
- Every dependency resolves against a real registry, with no phantom packages.
- No leaked secrets, no removed authentication, no known CVEs introduced.
- Scrutiny scales with blast radius: the more of the codebase a change touches, the harder Autter looks.

## Security and data handling

- **Ephemeral sandboxes**: every pull request runs in an isolated sandbox built fresh for that run and destroyed the moment the verdict lands. Nothing lingers between runs.
- **No training on your code**: your source is never used to train models. It exists inside the run, then it is gone.
- **Scoped, revocable access**: Autter reads what it reviews and nothing more, through scoped tokens you can revoke.
- **Encrypted in transit and at rest**: from the moment the sandbox clones to the moment the verdict posts.
- **Retained records**: findings, verdicts, repository structure, and audit logs remain for your team. The sandbox's source does not. Account and billing data are covered by the [Privacy Policy](https://autter.dev/privacy.md).
- **Enterprise controls**: SSO and related controls are available on the Enterprise plan.

## Enterprise deployment

Autter's review plane can deploy into your own cloud account or data center on the Enterprise plan. Your source stays within your network boundary, with your keys and logs. Updates arrive as versioned releases for your team to approve.

For air-gapped environments, scope model hosting, package sources, and offline updates with the Autter team before deployment. [Talk about enterprise deployment](https://autter.dev/contact.md).

## Frequently asked questions

**How is Autter different from AI review bots and linters?**

Review bots read the diff and leave comments. Autter executes the change: every pull request is cloned into an isolated sandbox, the suite runs against the base branch, dependencies are vetted against real registries, and the merge stays blocked until the checklist clears. The verdict comes from behavior, not pattern matching.

**Does Autter replace my CI?**

No. CI runs the jobs you wrote. Autter sits on top of it as the merge gate: it reads your CI signals, writes and runs the tests you are missing, and decides whether the change is safe to merge. Your pipeline stays exactly as it is.

**Will this replace our human reviewers?**

No. Autter clears the repetitive, easy to miss issues so your reviewers spend their time on architecture and design decisions, not on catching a missing null check.

**Which languages and stacks does it support?**

If your project can build and run in a container, Autter can execute it. The GitHub integration is native, and the product memory maps your code, APIs, schema, routes, and tests regardless of stack.

**Do you train on our code?**

No. Your source is cloned into an ephemeral sandbox for the duration of the review and torn down after. Nothing you send us is used to train models, and nothing persists beyond the run.

**How is proprietary code handled?**

Every review runs in an isolated sandbox built fresh for that run. Your source is not retained once the review completes, and everything in transit and at rest is encrypted.

**Is there a plan for open source projects?**

Yes. Public repositories run on Autter for free, with the same sandboxed execution and merge gate as a paid plan. Connect the repo and reviews start on the next pull request.

**What does Autter actually flag?**

Bugs the diff did not reveal, security issues, performance regressions, and logic errors, all verified by running your code rather than pattern matching it. It also calls out style and maintainability issues the way a senior reviewer would.

**Can we tune what it checks for?**

Yes. Point Autter at your team's standards, exclude file patterns, and weight it toward the parts of the codebase that matter most, all through a config file you own.

**How long before a review lands?**

Most runs finish within seconds of the pull request opening. Autter executes alongside your CI pipeline instead of after it, so the merge gate never adds to your wait.

**What happens when Autter is wrong?**

Every finding ships with its receipt: the exact sandbox run, the failing case, and the trace that produced it. If a finding does not hold up, you dismiss it and Autter learns from the override. Nothing blocks your merge on a hunch.

**How long does onboarding take?**

Install the GitHub App and pick your repos. Autter builds its product memory from the codebase on the first pass and starts reviewing the next pull request. There is no pipeline to rewrite and no config file to maintain.

**How do I get access, and what does it cost?**

Connect the GitHub App and start free. Harbour includes 10 PR reviews a month on one repository; reviews pause at the cap, so it never bills overages. Paid plans include a monthly PR allowance, then charge per additional review. Pricing follows PR volume, not seats: adding developers or coding agents does not add a per-seat fee. [See the plans](https://autter.dev/pricing.md) for current prices and allowances, or book a demo for setup help.

## Feature pages

Each feature has its own page with a full step-by-step breakdown and capability matrix in its markdown twin.

- [Code Review](https://autter.dev/features/code-review.md): Autter's AI code review runs every pull request instead of just reading it: sandbox execution, dependency verification against real registries, and findings that block the merge button until they clear.
- [Pipeline Automation](https://autter.dev/features/pipeline.md): Autter's AI testing pipeline maps critical flows into missions, generates the tests to cover them, runs everything on every pull request, and turns confirmed failures into verified fix PRs.
- [Analytics](https://autter.dev/features/analytics.md): Autter's code review analytics roll quality trends, hotspots, flaky rate, cycle time, and test coverage into a single release-readiness verdict, with every production error traced to the code that caused it.
- [AI Chat](https://autter.dev/features/chat.md): Ask Autter's AI teammate anything about your codebase. Chat is grounded in product memory, so every answer cites the code, tests, owners, and history it came from.
- [Runtime Observability](https://autter.dev/features/runtime.md): Autter Runtime watches production through a lightweight open source SDK, folds raw errors into incidents, traces each one to the deploy and pull request that caused it, investigates against your indexed codebase, and opens the fix as a PR for a human to review.
- [Integrations](https://autter.dev/features/integrations.md): Autter connects GitHub, CI, issue trackers, docs, Sentry, PostHog, Grafana, and deployments into one shared context, installed through a native GitHub App in minutes.
- [Autter CLI](https://autter.dev/features/cli.md): The Autter CLI is an open source Git extension for line-level AI code attribution. Know which AI wrote each line, straight from Git history, with autter blame and autter stats.
- [MCP Server](https://autter.dev/features/mcp.md): The Autter MCP server gives Claude Code, Cursor, OpenCode, and any MCP-compatible coding agent direct access to Autter's review findings, codebase intelligence, security scans, and team conventions, so the agent that writes the code can fix its own review.

## Key pages

- [How it works: the twelve-step pipeline from signals to verified fixes](https://autter.dev/how-it-works.md)
- [About: company, founders, principles](https://autter.dev/about.md)
- [Blog: essays on code review, release governance, and shipping with AI](https://autter.dev/blog.md)
- [Careers: open roles](https://autter.dev/careers.md)
- [Changelog: everything shipped, by day](https://autter.dev/changelog.md)
- [Pricing: plans, PR allowances, and per-PR rates](https://autter.dev/pricing.md)
- [Contact: sales, support, and founder booking](https://autter.dev/contact.md)
- Full site as one markdown file: https://autter.dev/llms-full.txt


---

---
title: How Autter Works - Step by Step
description: How Autter works, in twelve steps: connect every signal, build product memory, write the docs, map missions, generate tests, run the sandbox, vet dependencies, classify human vs AI code, trace errors, raise verified fixes, measure the team, and keep watching.
url: https://autter.dev/how-it-works
site: Autter - Autter is the code security and assurance layer for the AI coding era: it checks every change before it merges, catches security risks, governs releases, and closes the loop from production failure to verified fix.
---

How Autter works / Step 1

## Connect every signal.

Repos, pull requests, docs, issue trackers, error trackers, analytics, CI, and deployments flow into Autter.

How Autter works / Step 2

## Build product memory.

Autter maps code, APIs, database schema, frontend routes, tests, docs, owners, hotspots, and blast radius.

How Autter works / Step 3

## Write the docs.

From the codebase, PRs, and your existing guidelines, Autter generates documentation, changelogs, and release notes, and keeps every page current on each merge.

How Autter works / Step 4

## Map the missions.

Signup, checkout, uploads, and webhooks become end-to-end missions, probed at the edges with malformed inputs, boundary cases, and visual checks across browsers and devices.

How Autter works / Step 5

## Generate the tests.

From the code graph and each mission, Autter writes unit, API, and integration tests, finds coverage gaps, and detects and re-forges flaky tests.

How Autter works / Step 6

## Run it in the sandbox.

Every pull request executes in an isolated sandbox. The full suite runs against your base branch, so the verdict comes from real behavior, not lint.

How Autter works / Step 7

## Open every crate.

Every dependency is vetted against real registries. Phantom packages, leaked secrets, removed auth, and known CVEs are flagged at the gate and never ship.

How Autter works / Step 8

## Classify human vs AI.

Every change on every pull request is classified as human-written or AI-generated, so generated code gets the extra scrutiny it deserves.

How Autter works / Step 9

## Trace every error.

Sentry, PostHog, Grafana, logs, and telemetry stream into Autter. Every production error is pinned to the exact section of code that caused it, with the why, the where, and the owner.

How Autter works / Step 10

## Raise the fix.

Confirmed failures become fix PRs with the root cause attached. Autter re-runs the failing case in the sandbox and verifies the patch before it ships.

How Autter works / Step 11

## Measure the team.

Developer analytics roll every run's quality trends, hotspots, flaky rate, cycle time, and coverage into one release-readiness verdict.

How Autter works / Step 12

## Always watching.

Every repo. Every PR. Every release. Autter learns from every finding, every fix, and every incident. Your assurance layer never clocks out.

Calm seas ahead

## Take control of every release.

Autter runs, tests, and verifies every pull request before it merges, so every release ships in calm waters.

[Book a demo](https://autter.dev/contact) [Start Now](https://app.autter.dev)


---

---
title: AI Code Review That Runs the Code - Autter
description: Autter's AI code review runs every pull request instead of just reading it: sandbox execution, dependency verification against real registries, and findings that block the merge button until they clear.
url: https://autter.dev/features/code-review
site: Autter - Autter is the code security and assurance layer for the AI coding era: it checks every change before it merges, catches security risks, governs releases, and closes the loop from production failure to verified fix.
---

## Code Review at a glance

| Fact | Value |
| --- | --- |
| Role | The merge gate: every pull request runs before it can merge |
| Runs on | Every pull request, human-written or AI-generated |
| Verdict source | Real behavior — the full suite runs against the base branch, not lint |
| Blocks the merge | Yes. Findings hold the merge button until they clear |
| Deployment | Native GitHub App plus the Autter CLI |

## How it works, step by step

From the moment a pull request opens to the moment the merge button unlocks, every step happens automatically.

1. **A pull request opens.** It arrives carrying human edits, AI-generated code, and fresh dependencies. Autter tags who wrote what, because generated code earns extra scrutiny.
2. **Autter already knows the territory.** Your code, APIs, schema, routes, tests, and owners are already mapped into product memory, so the review starts from the change's full blast radius, not just the diff.
3. **The change is traced to real journeys.** Autter follows the diff outward to every user journey it can touch, then probes the edges with malformed inputs and boundary cases.
4. **Tests appear where the diff landed.** Unit, API, and integration tests are written around the change, coverage gaps are filled, and flaky tests are re-forged before they can lie.
5. **The verdict comes from running it.** The pull request executes in an isolated sandbox and the full suite runs against the base branch, so the verdict reports behavior, not appearance.
6. **Findings arrive like a senior engineer wrote them.** Each finding lands pinned to the exact line, ranked by severity, with a proposed fix attached. Push a fix and Autter re-reviews just the delta.
7. **Nothing unverified reaches main.** Every change and dependency files through the registry gate. Phantom packages, leaked secrets, and removed authentication are pulled off the line.
8. **The merge lands with proof behind it.** The button unlocks with the evidence attached: the suite that ran, the dependencies that resolved, the findings that closed.

## What the gate checks.

Six checks run on every pull request, and scrutiny scales with how much of the codebase a change can reach.

| # | Capability | What it does |
| --- | --- | --- |
| 1 | Sandbox execution | Your code actually runs in an isolated sandbox on every pull request. The verdict comes from watching it behave, not from reading it. |
| 2 | Dependency verification | Every import is confirmed against real registries, so hallucinated packages never reach your main branch. |
| 3 | AI authorship classification | Every change is classified as human-written or AI-generated, and generated code gets proportionally more scrutiny. |
| 4 | Blast-radius scrutiny | A one-line change to a shared helper deserves more attention than a hundred lines in a leaf module. Autter looks harder the further a change reaches. |
| 5 | Security review | Exposed credentials, removed authentication, and known vulnerabilities get caught before deploy, not after. |
| 6 | Findings with fixes | Every finding ships with an explanation and a proposed fix, not just a verdict, because the maintainer is the customer. |

## In one line

> A check you can ignore is just advice.

Autter blocks the merge button, and that is non-negotiable. Reading code is not running it, and execution is the only pre-production check that catches what static analysis cannot see.

## Related

- [Pipeline Automation](https://autter.dev/features/pipeline.md)
- [Integrations](https://autter.dev/features/integrations.md)
- [Pricing and plans](https://autter.dev/pricing.md)
- [Full product overview](https://autter.dev/index.md)


---

---
title: AI Test Pipeline Automation - Autter
description: Autter's AI testing pipeline maps critical flows into missions, generates the tests to cover them, runs everything on every pull request, and turns confirmed failures into verified fix PRs.
url: https://autter.dev/features/pipeline
site: Autter - Autter is the code security and assurance layer for the AI coding era: it checks every change before it merges, catches security risks, governs releases, and closes the loop from production failure to verified fix.
---

## Pipeline Automation at a glance

| Fact | Value |
| --- | --- |
| Role | The self-maintaining test pipeline: builds, runs, and repairs itself |
| Runs on | Every pull request, compared against the base branch |
| Produces | Missions, generated tests, and verified fix PRs |
| Flaky tests | Detected and re-forged at the root, not retried until green |

## How it works, step by step

The pipeline assembles itself from your codebase and keeps improving with every merge.

1. **Critical flows become missions.** Signup, checkout, uploads, webhooks: each critical flow is mapped into an end-to-end mission and probed with malformed inputs, boundary cases, and visual checks across browsers and devices.
2. **Tests write themselves.** Unit, API, and integration tests are generated from the code graph and each mission. Coverage gaps get found, and flaky tests are detected and re-forged instead of retried.
3. **Everything runs on every PR.** The whole suite executes in the sandbox on each pull request and compares against the base branch, so the pipeline never drifts out of date.
4. **Failures come back as fix PRs.** Confirmed failures turn into fix pull requests with the root cause attached. The failing case re-runs in the sandbox and the patch is verified before it ships.

## Everything the pipeline handles.

The upkeep every release depends on, running continuously across every connected repository.

| # | Capability | What it does |
| --- | --- | --- |
| 1 | Mission mapping | Critical user flows become end-to-end missions, exercised with malformed inputs, boundary cases, and visual checks across browsers and devices. |
| 2 | Test generation | Unit, API, and integration tests written from the code graph and each mission, aimed at the gaps your suite actually has. |
| 3 | Flaky re-forging | Flaky tests are detected and rewritten at the root instead of being retried until green. |
| 4 | Fix pull requests | Confirmed failures become fix PRs with the root cause attached, re-run in the sandbox and verified before they ship. |
| 5 | Docs and changelogs | Documentation, changelogs, and release notes are generated from the codebase and PRs, and kept current on every merge. |
| 6 | Continuous watch | Every repo, every PR, every release. Autter learns from each finding, fix, and incident, and never clocks out. |

## In one line

> Your pipeline should not need a babysitter.

Test suites rot the moment nobody owns them. Autter owns yours: it writes what is missing, repairs what is flaky, and verifies its own fixes before they merge.

## Related

- [Code Review](https://autter.dev/features/code-review.md)
- [Analytics](https://autter.dev/features/analytics.md)
- [Pricing and plans](https://autter.dev/pricing.md)
- [Full product overview](https://autter.dev/index.md)


---

---
title: Code Quality & Release Analytics - Autter
description: Autter's code review analytics roll quality trends, hotspots, flaky rate, cycle time, and test coverage into a single release-readiness verdict, with every production error traced to the code that caused it.
url: https://autter.dev/features/analytics
site: Autter - Autter is the code security and assurance layer for the AI coding era: it checks every change before it merges, catches security risks, governs releases, and closes the loop from production failure to verified fix.
---

## Analytics at a glance

| Fact | Value |
| --- | --- |
| Role | The release ledger: every release measured before it ships |
| Produces | A single release-readiness verdict per release |
| Tracks | Quality trends, hotspots, flaky rate, cycle time, coverage, AI-authorship share |
| Error tracing | Every production error pinned to the code and owner that caused it |

## How it works, step by step

Everything your stack already emits, distilled into one call you can act on.

1. **Every signal streams in.** Sentry, PostHog, Grafana, logs, telemetry, and CI results flow into the same ledger the reviews write to, so quality data and production data live in one place.
2. **Errors get pinned to code.** Every production error is traced to the exact section of code that caused it, with the why, the where, and the owner attached.
3. **Trends accumulate per repo.** Hotspots, flaky rate, cycle time, coverage, and the share of AI-generated code build up over time, so you can see where risk concentrates before it bites.
4. **The verdict rolls up.** All of it condenses into a single release-readiness verdict per release: ship, or here is exactly what is blocking.

## What the ledger tracks.

Numbers that answer questions engineering leaders actually ask, generated from the same reviews that gate your merges.

| # | Capability | What it does |
| --- | --- | --- |
| 1 | Release-readiness verdict | One rolled-up call per release, built from real execution results rather than gut feel. |
| 2 | Quality trends and hotspots | The files and modules where defects cluster, tracked over time so refactoring effort goes where it pays. |
| 3 | Flaky rate and coverage | How trustworthy the suite is and where its gaps are, measured continuously instead of audited yearly. |
| 4 | Cycle time | How long changes take from open to merge, and which stage of review is the bottleneck. |
| 5 | Error tracing | Production errors pinned to the code that caused them, with the owner attached, so triage starts at the answer. |
| 6 | AI authorship share | How much of your codebase is AI-generated and how that code behaves compared to the rest. |

## In one line

> Risk is damage multiplied by spread.

Averages hide the module that takes the release down. Autter measures where changes land and what they can reach, so the risk you see is the risk you actually carry.

## Related

- [Code Review](https://autter.dev/features/code-review.md)
- [Integrations](https://autter.dev/features/integrations.md)
- [Pricing and plans](https://autter.dev/pricing.md)
- [Full product overview](https://autter.dev/index.md)


---

---
title: AI Chat for Your Codebase - Autter
description: Ask Autter's AI teammate anything about your codebase. Chat is grounded in product memory, so every answer cites the code, tests, owners, and history it came from.
url: https://autter.dev/features/chat
site: Autter - Autter is the code security and assurance layer for the AI coding era: it checks every change before it merges, catches security risks, governs releases, and closes the loop from production failure to verified fix.
---

## AI Chat at a glance

| Fact | Value |
| --- | --- |
| Role | A reviewer you can question in plain language |
| Grounded in | Product memory: code, APIs, schema, routes, tests, owners, hotspots |
| Every answer | Cites the exact files, tests, and PRs it rests on |
| Available in | The GitHub review thread and the Autter CLI |

## How it works, step by step

The same context that powers every review is there to be questioned in plain language.

1. **Ask why the merge is blocked.** Every finding explains itself on request: what failed, why it matters, and what the fix looks like, in plain language instead of a stack trace.
2. **Trace a production error.** Paste an error and get the file, the line, the owner, and the change that introduced it, pulled from the same error-tracing engine behind the analytics.
3. **Interrogate the blast radius.** Ask what a change can reach before you write it. Product memory maps code, APIs, schema, routes, and tests, so the answer is a graph, not a guess.
4. **Draft the fix.** Chat proposes the patch and the sandbox verifies it, the same way every Autter fix PR is verified before it ships.

## What the chat knows.

Not a general-purpose assistant with your repo pasted in. A reviewer that already holds the whole map.

| # | Capability | What it does |
| --- | --- | --- |
| 1 | Product memory | Code, APIs, database schema, frontend routes, tests, docs, owners, and hotspots, kept current on every merge. |
| 2 | Review context | Every past finding, fix, and incident is in reach, so answers carry the history of your codebase, not just its current state. |
| 3 | Grounded citations | Answers link to the exact files, tests, and PRs they rest on. If it cannot cite it, it says so. |
| 4 | Verified fix drafting | Proposed patches run in the sandbox before you see them, so a suggestion is already a passing change. |
| 5 | Owner and history lookup | Who owns this module, what changed it last, and what broke it before, answered without archaeology. |
| 6 | Works where you do | Available from the review thread on GitHub and from the Autter CLI, so the conversation happens next to the code. |

## In one line

> Answers are only useful with the code to back them.

Chat that guesses is worse than no chat at all. Autter answers from product memory and cites its sources, so you can check every claim against the repo it came from.

## Related

- [Code Review](https://autter.dev/features/code-review.md)
- [Integrations](https://autter.dev/features/integrations.md)
- [Full product overview](https://autter.dev/index.md)


---

---
title: Autter Runtime - Observability Agents That Fix Production Errors
description: Autter Runtime watches production through a lightweight open source SDK, folds raw errors into incidents, traces each one to the deploy and pull request that caused it, investigates against your indexed codebase, and opens the fix as a PR for a human to review.
url: https://autter.dev/features/runtime
site: Autter - Autter is the code security and assurance layer for the AI coding era: it checks every change before it merges, catches security risks, governs releases, and closes the loop from production failure to verified fix.
---

## Runtime Observability at a glance

| Fact | Value |
| --- | --- |
| Role | The production loop: errors detected, grouped, correlated, investigated, and returned as fix PRs |
| Signal source | The open source Autter Runtime SDK (browser, Node, Next.js). Sentry, PostHog, and Grafana connectors are on the roadmap, not live yet |
| Promotion rules | Only error-level issues can become incidents: a spike past the threshold or one fatal occurrence. Warnings never page |
| Fix delivery | A GitHub pull request from the Autter bot on its own branch; humans review and merge |
| When uncertain | Asks the team two to five clarifying questions by email instead of guessing, then resumes with the answers |
| Notifications | Email to opted-in reviewers the moment a fix PR opens or questions are waiting |

## How it works, step by step

Eight stages, run unattended from the first occurrence to the closed case. Your part starts at review and ends at merge.

1. **Detected.** A production error crosses the wire. The SDK captures the occurrence with its stack trace, service, environment, and release, and severity is read at the door: fatal, error, warning, or info.
2. **Grouped.** A stable fingerprint built from the error type, the normalized message, and the top stack frames folds thousands of raw occurrences into one issue. Counts accumulate on the group, not in your inbox.
3. **Correlated.** When an issue is promoted to an incident, Autter walks your deployment history. A deploy that landed just before the first occurrence is matched to the merged pull request that shipped it: the suspected cause, named.
4. **Investigating.** Stack frames are mapped to files in your indexed codebase and the real source is pulled. The root cause analysis is grounded strictly in your code: no invented files, no invented symbols.
5. **Fix ready.** The same agentic runner that powers Autter's reviews writes the fix and opens a pull request on its own branch. The incident carries a problem, impact, and solution summary, and your reviewers get pinged.
6. **Deployed.** You review, approve, and merge. Autter opens pull requests; humans keep the merge button.
7. **Monitoring.** After the fix ships, the incident stays open while occurrence counts are watched. Silence is measured, not assumed.
8. **Resolved.** The incident closes with the whole record attached: every occurrence, the correlation, the investigation, the fix, and who approved it.

## What the loop runs on.

Every stage is mechanical and inspectable, from the fingerprint that folds the noise to the questions it asks when it is not sure.

| # | Capability | What it does |
| --- | --- | --- |
| 1 | Fingerprint grouping | Raw occurrences fold into issues by error type, normalized message, and top stack frames, so a thousand pages become one line with a count. |
| 2 | Incident promotion | Only error-level groups can become incidents: a spike past the threshold or a single fatal occurrence opens one. Warnings never page anyone. |
| 3 | Deploy correlation | New incidents are checked against recent deployments and matched to the merged pull request that shipped the change. |
| 4 | Grounded investigation | Stack frames map to your indexed codebase and the real source is fetched, so the root cause cites code that actually exists. |
| 5 | Fix pull requests | Fixes arrive as ordinary GitHub pull requests on their own branch, opened by the Autter bot for a human to review and merge. |
| 6 | Clarifying questions | When the fixer is not sure, it does not guess. It asks your team two to five pointed questions and resumes with the answers. |

## In one line

> The 3 a.m. page becomes a 9 a.m. pull request.

Autter runs the whole loop while you sleep: detects the error, folds the noise, finds the deploy that caused it, writes the fix, and opens the PR. It stops exactly where judgment starts, because self-driving still needs a driver's seat.

## The incident lifecycle

Every incident moves through the same eight stages, rendered as a stepper in the Autter dashboard. Generated from the same data the page renders.

| # | Stage | What happens |
| --- | --- | --- |
| 1 | Detected | A production error crosses the wire. The SDK captures the occurrence with its stack trace, service, environment, and release, and severity is read at the door: fatal, error, warning, or info. |
| 2 | Grouped | A stable fingerprint built from the error type, the normalized message, and the top stack frames folds thousands of raw occurrences into one issue. Counts accumulate on the group, not in your inbox. |
| 3 | Correlated | When an issue is promoted to an incident, Autter walks your deployment history. A deploy that landed just before the first occurrence is matched to the merged pull request that shipped it: the suspected cause, named. |
| 4 | Investigating | Stack frames are mapped to files in your indexed codebase and the real source is pulled. The root cause analysis is grounded strictly in your code: no invented files, no invented symbols. |
| 5 | Fix ready | The same agentic runner that powers Autter's reviews writes the fix and opens a pull request on its own branch. The incident carries a problem, impact, and solution summary, and your reviewers get pinged. |
| 6 | Deployed | You review, approve, and merge. Autter opens pull requests; humans keep the merge button. |
| 7 | Monitoring | After the fix ships, the incident stays open while occurrence counts are watched. Silence is measured, not assumed. |
| 8 | Resolved | The incident closes with the whole record attached: every occurrence, the correlation, the investigation, the fix, and who approved it. |

## The Runtime SDK

Open source at https://github.com/Autter-dev/autter-runtime. Install with `npm install @autter/runtime-browser` (or the Node/Next.js package). Ingest keys are scoped: server keys stay on the server, publishable client keys are safe to ship in the browser.

| Package | What it does |
| --- | --- |
| `@autter/runtime-browser` | Errors and usage from the browser, a few kilobytes behind a publishable client key. Light enough that nobody argues about adding it. |
| `@autter/runtime-node` | Server-side errors and OpenTelemetry signals, plus a same-origin relay for the browser tracker. |
| `@autter/runtime-next` | Both halves wired into Next.js with one import. |

Connectors for Sentry, PostHog, Grafana are on the roadmap (not live yet); they will feed the same loop from grouping onward.

## How context is assembled before a fix

- **Frames become files**: Each stack frame is matched against the indexed repository, exact path first, unique suffix next, and the real source is fetched from the branch you ship from.
- **Deploys become suspects**: Deployment events in the window before the first occurrence are matched by commit to the merged pull request that shipped them.
- **Code stays the ground truth**: The investigation is grounded strictly in fetched source. If your code cannot support a claim, the claim does not ship.
- **The same map your reviews use**: Runtime shares the code intelligence index Autter already builds for review, so production context and review context are one map, not two.

## Human-in-the-loop guarantees

- **PRs, never merges**: Every fix arrives as an ordinary pull request from the Autter bot on its own branch. Your review process applies, and nothing lands without a human approval.
- **It asks before it guesses**: When the fixer cannot confirm the fix from your code, it stops and asks your team two to five pointed questions, then resumes with the answers.
- **Pinged where you already read**: The moment a fix PR opens, or questions are waiting, the reviewers who opted in get an email with the whole case attached.
- **Tuned to stay quiet**: Only error-level issues can become incidents, and warnings never page. A fatal occurrence escalates an open incident instead of opening a second one.

## Related

- [Code Review](https://autter.dev/features/code-review.md)
- [Analytics](https://autter.dev/features/analytics.md)
- [Integrations](https://autter.dev/features/integrations.md)
- [Full product overview](https://autter.dev/index.md)


---

---
title: Autter Integrations: GitHub, CI/CD & More
description: Autter connects GitHub, CI, issue trackers, docs, Sentry, PostHog, Grafana, and deployments into one shared context, installed through a native GitHub App in minutes.
url: https://autter.dev/features/integrations
site: Autter - Autter is the code security and assurance layer for the AI coding era: it checks every change before it merges, catches security risks, governs releases, and closes the loop from production failure to verified fix.
---

## Integrations at a glance

| Fact | Value |
| --- | --- |
| Role | Signal ingestion: the whole stack in one review context |
| Install | A native GitHub App, connected in minutes |
| Repositories | Unlimited on every plan, including the free one |
| Also runs | Locally, through the Autter CLI |

## How it works, step by step

One install, a few connections, and the context assembles itself.

1. **Install the GitHub App.** Autter integrates with GitHub natively. Connect a repository on the free plan, or your whole org on Cargo.
2. **Connect your signals.** Point Sentry, PostHog, Grafana, logs, telemetry, CI, issue trackers, and docs at Autter. Each one deepens the review context.
3. **Autter builds product memory.** Code, APIs, database schema, frontend routes, tests, docs, owners, hotspots, and blast radius get mapped automatically, so every review knows what a change can reach.
4. **Every PR reviews with full context.** From then on each pull request is reviewed against everything the stack knows, and the Autter CLI brings the same checks to your local branch.

## What plugs in.

Every connection feeds the same review context, so each integration makes all the others sharper.

| # | Capability | What it does |
| --- | --- | --- |
| 1 | GitHub, natively | A native GitHub App, not a webhook bolted on. Reviews, checks, and fix PRs live where your team already works. |
| 2 | CI providers | Existing pipelines stream results into the review, and the sandbox verdict lands beside them as one more required check. |
| 3 | Error trackers | Sentry errors get pinned to the exact code that caused them, with the owner attached. |
| 4 | Analytics and observability | PostHog, Grafana, logs, and telemetry connect production behavior back to the changes that shipped it. |
| 5 | Issue trackers and docs | Tickets and documentation join the review context, and generated docs flow back the other way on every merge. |
| 6 | The Autter CLI | The same gate, runnable from your terminal before the PR even opens. |

## In one line

> Context is what separates a reviewer from a linter.

A diff alone cannot tell you what matters. Autter reviews with your errors, your analytics, your docs, and your history in hand, because that is how a senior engineer reads a change.

## Connectors

Every connection feeds the same review context, so each integration makes the others sharper.

| Signal | What it contributes to the review |
| --- | --- |
| GitHub (native App) | Repos, pull requests, checks, and fix PRs, where the team already works. Repository allowance scales by plan, up to unlimited on Cargo and Fleet. |
| CI providers | Existing pipeline results stream in beside the sandbox verdict as one more required check. |
| Sentry (error tracker) | Production errors pinned to the exact code that caused them, with the owner attached. |
| PostHog (analytics) | Product behavior connected back to the changes that shipped it. |
| Grafana, logs, telemetry (observability) | Runtime signals tied to the code under review. |
| Issue trackers | Tickets join the review context. |
| Docs | Documentation feeds context in; generated docs flow back out on every merge. |
| Deployments | Release state connected to the review record. |
| Autter CLI | The same gate, runnable from the terminal before the PR opens. |

## Related

- [Code Review](https://autter.dev/features/code-review.md)
- [Autter CLI](https://autter.dev/features/cli.md)
- [Pricing and plans](https://autter.dev/pricing.md)
- [Full product overview](https://autter.dev/index.md)


---

---
title: Autter CLI - Open Source AI Code Attribution for Git
description: The Autter CLI is an open source Git extension for line-level AI code attribution. Know which AI wrote each line, straight from Git history, with autter blame and autter stats.
url: https://autter.dev/features/cli
site: Autter - Autter is the code security and assurance layer for the AI coding era: it checks every change before it merges, catches security risks, governs releases, and closes the loop from production failure to verified fix.
---

## Autter CLI at a glance

| Fact | Value |
| --- | --- |
| Role | Open source Git extension for line-level AI attribution |
| License | Apache 2.0 |
| Mode | Local-first: works fully offline, no account, no prompt uploaded |
| Storage | Attribution kept in Git Notes; survives merges, rebases, cherry-picks |
| Git hooks | None — Git commands stay fast |

## How it works, step by step

Start local-only, connect to the platform later. Nothing about the team workflow changes either way.

1. **Install.** macOS, Linux, and Windows (native PowerShell or WSL). One command, no dependencies, no account.
2. **Attribute.** autter blame is a git blame companion that answers with authors, human and AI alike, line by line.
3. **Measure.** autter stats summarizes accepted AI lines, human edits, tools, and models across the repository.
4. **Onboard.** Pick local-only mode, or connect the platform for dashboards, prompt search, and audit history.

## A record agents cannot explain away.

Explicit line-level attribution at write time, carried through standard Git history.

| # | Capability | What it does |
| --- | --- | --- |
| 1 | No workflow change | Keep prompting, editing, committing, pushing. Attribution happens in the background. |
| 2 | Local-first by default | The open source CLI works fully offline. No account needed and no prompt ever uploaded. |
| 3 | No git hooks | Autter does not wrap Git or install per-repo hooks, so Git commands stay fast. |
| 4 | Git-native record | Attribution is stored in Git Notes and survives merges, rebases, and cherry-picks. |
| 5 | Every agent covered | Claude Code, Codex, Cursor, GitHub Copilot, Windsurf, and any agent that adopts the open standard. |
| 6 | Open source | Apache 2.0, developed in the open at github.com/Autter-dev/autter-cli. |

## In one line

> A record agents cannot explain away.

Attribution is captured explicitly at write time, including the agent, the model, and the prompt, and stored in Git Notes where it survives every rebase.

## Command reference

| Command | What it does |
| --- | --- |
| `autter onboard` | Choose local-only mode, or connect the platform for dashboards, prompt search, and audit history. |
| `autter blame <file>` | A `git blame` companion: answers each line with its author, human (the committer) or AI (the model). |
| `autter stats` | Repo-wide summary of accepted AI lines, human edits, tools, and models. Add `--json` for machine-readable output. |

## Install

macOS, Linux, and WSL:

```sh
curl -fsSL https://api.autter.dev/install.sh | bash
```

Windows (native; run it from Command Prompt or PowerShell):

```powershell
powershell -NoProfile -ExecutionPolicy Bypass -Command "iex (irm https://api.autter.dev/install.ps1)"
```

One command, no dependencies, and no account for local-only mode. Use the `api.autter.dev` URLs exactly as shown.

## Facts

| Fact | Value |
| --- | --- |
| Repository | https://github.com/Autter-dev/autter-cli |
| License | Apache 2.0 |
| Mode | Local-first (fully offline; no prompt ever uploaded) |
| Storage | Git Notes; survives merges, rebases, and cherry-picks |
| Git hooks | None; Autter does not wrap Git or install per-repo hooks |
| Documentation | https://autter.dev/docs |

## Supported agents

Claude Code, Codex, Cursor, GitHub Copilot, Windsurf, Gemini CLI, and any agent that adopts the open attribution standard.

## Related

- [Integrations](https://autter.dev/features/integrations.md)
- [Code Review](https://autter.dev/features/code-review.md)
- [Full product overview](https://autter.dev/index.md)


---

---
title: Autter MCP Server - Connect Your Coding Agents
description: The Autter MCP server gives Claude Code, Cursor, OpenCode, and any MCP-compatible coding agent direct access to Autter's review findings, codebase intelligence, security scans, and team conventions, so the agent that writes the code can fix its own review.
url: https://autter.dev/features/mcp
site: Autter - Autter is the code security and assurance layer for the AI coding era: it checks every change before it merges, catches security risks, governs releases, and closes the loop from production failure to verified fix.
---

## MCP Server at a glance

| Fact | Value |
| --- | --- |
| Role | The machine-facing layer: coding agents read Autter's reviews and act on them |
| Endpoint | https://api.autter.dev/mcp (Streamable HTTP, stateless JSON; POST only) |
| Auth | Autter personal access tokens (autter_pat_...), sent as a Bearer header |
| Scopes | mcp:read, mcp:write, mcp:llm; tokens expire and revoke from the dashboard |
| Clients | Claude Code, Cursor, OpenCode, Windsurf, and any MCP-compatible client |
| Guardrails | No arbitrary SQL, no generic GitHub writes; every call audited and rate limited |

## How it works, step by step

The old loop had a human courier: read the finding on GitHub, explain it to the agent, paste the fix back, click resolve. Over MCP the agent runs the whole circuit itself.

1. **Pull the review.** get_pr_review returns the verdict and up to 50 findings, each pinned to file and line with a ready-to-run fix_prompt.
2. **Fix in place.** The agent applies each fix_prompt in the working tree, with the conventions from get_learnings already in context.
3. **Answer the thread.** reply_to_review_comment posts the fix commit; resolve_review_thread closes the thread out on GitHub, which stays the source of truth.
4. **Push.** Commits go up exactly the way they always do. Nothing wraps Git.
5. **Ask for another pass.** trigger_review re-runs the review on the latest revision. Green means merge.

## Sixteen tools, five jobs.

Not an API dump behind an MCP wrapper. Each tool is built around something an agent genuinely needs mid-change, and every call lands in the audit log.

| # | Capability | What it does |
| --- | --- | --- |
| 1 | Identity and repositories | whoami and list_prs anchor the session to the right org, connected repos, and open pull requests. |
| 2 | The review loop | get_pr_review returns findings with ready-to-run fix_prompts; reply, resolve, and trigger_review close the round trip. |
| 3 | Team knowledge | get_learnings reads the conventions Autter has learned from your reviews; add_learning teaches new ones that future reviews enforce. |
| 4 | Codebase intelligence | query_codebase, get_symbol_info, get_impact_analysis, and get_repo_health answer before the first edit. |
| 5 | Security and scans | check_dependency vets packages before they are installed; trigger_scan, get_scan_status, and get_scan_findings run the full sweep. |
| 6 | Controlled access | Scoped personal access tokens, per-token rate limits, structured errors, and an audit entry for every call. |

## In one line

> The code writer can finally talk to the code reviewer.

Agents already write the code. The MCP server hands them the context they were writing blind without: findings, conventions, blast radius, and dependency risk, at the exact moment they need it.

## Tool reference

All 16 tools, generated from the same catalog the page renders. Every tool takes a `context` parameter where the agent states why it is calling; the reason is recorded alongside the call in the organization audit log.

| Tool | Area | What it does |
| --- | --- | --- |
| `whoami` | Identity and repositories | The authenticated user, org, token, and connected repositories. Call it first. |
| `list_prs` | Identity and repositories | Tracked pull requests for a repo, newest first, with per-PR review status. |
| `get_pr_review` | The review loop | The verdict, the chapters, and up to 50 findings, each pinned to file and line with a ready-to-run fix_prompt. |
| `reply_to_review_comment` | The review loop | Answer a review thread as the agent, attributed to your token. |
| `resolve_review_thread` | The review loop | Close a thread once its finding is fixed. GitHub stays the source of truth. |
| `trigger_review` | The review loop | Re-run the review on the pull request's latest revision. |
| `get_learnings` | Team knowledge | Team conventions learned from review feedback, dismissed findings, and repo rules. |
| `add_learning` | Team knowledge | Teach Autter a new repo convention. Future reviews enforce it. |
| `query_codebase` | Codebase intelligence | Natural-language questions answered from generated docs and the code graph, with citations. |
| `get_symbol_info` | Codebase intelligence | Definition, callers, blast radius, and change risk for any symbol. |
| `get_impact_analysis` | Codebase intelligence | What a change to a file can reach: dependents, churn history, test coverage. |
| `get_repo_health` | Codebase intelligence | Architecture concerns, hotspots, and risk insights at repository level. |
| `check_dependency` | Security and scans | Known CVEs, fixed versions, and typosquat flags before the package is installed. |
| `trigger_scan` | Security and scans | Start a full codebase scan across Autter's scanning agents. |
| `get_scan_status` | Security and scans | Poll a running scan with per-agent progress. |
| `get_scan_findings` | Security and scans | Unified findings from the latest scan, filterable by severity and agent. |

## Connecting a client

Create a personal access token in the Autter dashboard under Organization → Access Tokens (scope it to `mcp:read` for a read-only agent), then register the server.

Claude Code:

```sh
claude mcp add --transport http autter https://api.autter.dev/mcp \
  --header "Authorization: Bearer autter_pat_..."
```

Cursor and most other MCP clients:

```json
{
  "mcpServers": {
    "autter": {
      "type": "http",
      "url": "https://api.autter.dev/mcp",
      "headers": { "Authorization": "Bearer autter_pat_..." }
    }
  }
}
```

## Protocol facts

| Fact | Value |
| --- | --- |
| Endpoint | https://api.autter.dev/mcp |
| Transport | Streamable HTTP, stateless JSON responses (POST only; GET returns 405) |
| Auth | `Authorization: Bearer autter_pat_...` |
| Token scopes | `mcp:read`, `mcp:write`, `mcp:llm` |
| Errors | Structured codes such as `repo_not_found`, `insufficient_scope`, `scan_limit_reached`, `github_unavailable` |
| Rate limits | Per token, so runaway agent loops are slowed rather than billed |

## Related

- [Code Review](https://autter.dev/features/code-review.md)
- [Autter CLI](https://autter.dev/features/cli.md)
- [Integrations](https://autter.dev/features/integrations.md)
- [Full product overview](https://autter.dev/index.md)


---

---
title: About Autter - The Team Behind the Code Assurance Layer
description: Autter is the code security and assurance layer your team has been missing. The Friday deploy that started it, the merge gate we built in response, and the small crew behind it.
url: https://autter.dev/about
site: Autter - Autter is the code security and assurance layer for the AI coding era: it checks every change before it merges, catches security risks, governs releases, and closes the loop from production failure to verified fix.
---

## Company facts

| Fact | Value |
| --- | --- |
| Company | Autter |
| Product | The code security and assurance layer for the AI coding era: pre-merge checks, security, product impact, and release governance |
| Founded | 2026 |
| Stage | Pre-launch, with a waitlist and a product almost ready to ship |
| Team | Two co-founders, hiring deliberately (small on purpose) |
| Co-founder, Tech | Sagnik. Writes the scanner, ships the blog, answers every technical support email himself |
| Co-founder, GTM | Tanvi. Positioning, partnerships, and distribution |
| Mascot | Captain Patch, the otter "harbour auditor" who opens every crate instead of trusting the manifest |
| Location | Remote (IST timezone) |
| Website | https://autter.dev · docs at https://autter.dev/docs |

## The evidence behind the mission

- **77%** of developers use AI coding tools (Stack Overflow Developer Survey, 2024).
- **1.7×** more bugs in AI-generated code than human-written code (GitClear, analysis of 211M lines).
- **0** tools ran code before merge when the founders went looking, so they built one.

## Operating principles

1. **Block the merge, don't advise.** A check you can ignore is just advice. Execution is the only pre-production check that catches what static analysis cannot see.
2. **Risk = damage × spread.** A one-line change to a shared helper deserves more scrutiny than a hundred lines in a leaf module.
3. **Five real issues beat fifty uncertain flags.** A tool people learn to ignore is actively harmful.
4. **Every finding ships with an explanation and a fix.** The maintainer is the customer, not the dashboard.
5. **Built from scratch in 2026.** Tools designed for human-written code were not built for the current landscape.

## Origin, in one paragraph

One Friday afternoon a pull request written with an AI assistant passed the linter, the syntax check, and human review, and shipped an import for a library that did not exist. Production broke Monday morning; three engineers lost half a day to land a four-line fix. The founders went looking for a tool that runs code before merge, verifies imports against real registries, and maps what a change can break. There wasn't one, so they built it.


---

---
title: Autter Blog - Code Security & Assurance in the AI Era
description: Notes on code security, code assurance, and shipping safely in the AI coding era, written by the team building Autter.
url: https://autter.dev/blog
site: Autter - Autter is the code security and assurance layer for the AI coding era: it checks every change before it merges, catches security risks, governs releases, and closes the loop from production failure to verified fix.
---

## All posts

The Autter blog: 31 essays on code review, release governance, and shipping with AI, written by the team building Autter. Each post's full text is available as raw markdown at its `.md` link. Sorted newest first.

### [Nobody Reads Config Diffs With Feeling](https://autter.dev/blog/nobody-reads-config-diffs-with-feeling.md)

2026-10-13 · Sagnik · 8 min · tags: Security, AI Safety, Merge Gate

Deleting a leaked secret doesn’t delete the key. Where hardcoded secrets hide, why rotation comes first, and why the pull request is the cheapest place to stop them.

### [The PR Queue Wasn’t Built for This Much Code](https://autter.dev/blog/the-pr-queue-wasnt-built-for-this-much-code.md)

2026-10-10 · Sagnik · 6 min · tags: Code Review, AI, Engineering, Product

AI made code abundant. Human attention did not scale with it. Why we built Autter Triage around the changes that actually deserve deeper review.

### [How to Prioritize Vulnerabilities: CVSS, EPSS, KEV, and Reachability](https://autter.dev/blog/how-to-prioritize-vulnerabilities.md)

2026-10-09 · Tanvi · 8 min · tags: Security, Code Review, Merge Gate

How to prioritize vulnerabilities: use CVSS for severity, EPSS for likelihood, KEV for proof, and reachability for reality. Then stop patching in alphabetical order.

### [Claude Code, Cursor, Codex: Fast Hands, Zero Fear of Consequences](https://autter.dev/blog/ai-coding-assistant-security-risks.md)

2026-10-05 · Tanvi · 9 min · tags: AI Safety, Security, Code Review, Merge Gate, Opinion

The real security risks of Claude Code, Cursor, and Codex: insecure code, leaked secrets, bad packages, and prompt injection. And why a merge gate beats a polite suggestion.

### [GitHub Refusing Merge Is Not an SDLC](https://autter.dev/blog/github-refusing-merge-is-not-an-sdlc.md)

2026-09-12 · Autter Team · 11 min · tags: Code Review, GitHub, Merge Gate, SDLC

Why GitHub's real merge levers still stop at the PR — and how Autter extends enforcement from authorship through runtime and repair.

### [How RelayCore cut AI coding spend by 33% with Autter](https://autter.dev/blog/relaycore-cut-ai-coding-spend-33-percent.md)

2026-09-08 · Team Autter · 7 min · tags: Case Study, AI Cost Governance, Engineering, Agent Efficiency

A 38-person engineering team used Autter to connect AI costs to repositories, agents, and completed work. Six weeks later, RelayCore had cut monthly AI spend from $31,800 to $21,400 while shipping 22% more AI-assisted pull requests.

### [How Northstar cut PR review time by 62% with Autter](https://autter.dev/blog/northstar-cut-pr-review-time-62-percent.md)

2026-09-04 · Team Autter · 6 min · tags: Case Study, Code Review, AI Safety, Engineering

A 24-person team was generating code faster than it could review it. Autter put a merge gate between each PR and main — median review time fell from 4.2 hours to 1.6 hours.

### [Copilot Can Review Copilot. That Is Not a Second Reviewer.](https://autter.dev/blog/copilot-can-review-copilot-that-is-not-a-second-reviewer.md)

2026-08-30 · Sagnik · 10 min · tags: Opinion, Code Review, AI, Merge Gate

GitHub now lets Copilot code review cover Copilot-authored PRs. Covering bot PRs was the right product move. Same-vendor review is still the author certifying the merge.

### [Your PR Is Green. Should You Still Be Nervous?](https://autter.dev/blog/merge-room-episode-1-your-pr-is-green.md)

2026-08-21 · Autter Team · 9 min · tags: The Merge Room, Code Review, Engineering

Tests are green, the code compiles, and the PR looks harmless. Learn what code review must catch beyond CI and why reviewing a diff is only the beginning.

### [Autter vs Claude Code Review: Should the AI That Writes Your Code Also Review It?](https://autter.dev/blog/autter-vs-claude-code-review.md)

2026-07-28 · Sagnik, Tech @ Autter · 15 min · tags: Comparison, Code Review, AI

Autter is the stronger first choice for teams that need risk-based verification, enforceable merge gates and predictable code assurance. See how it compares with Claude Code Review.

### [Introducing the Autter MCP server](https://autter.dev/blog/autter-mcp-server.md)

2026-07-27 · Team Autter · 4 min · tags: Product, MCP, AI

Connect Claude Code, Cursor, OpenCode, and other MCP-compatible coding agents to Autter’s reviews, codebase intelligence, security findings, and team knowledge.

### [Autter vs CodeRabbit: a reviewer is not a merge gate](https://autter.dev/blog/autter-vs-coderabbit.md)

2026-07-16 · Sagnik, Tech @ Autter · 14 min · tags: Comparison, Code Review, AI

Compare Autter and CodeRabbit on AI code review, runtime verification, merge gates, rate limits, and pricing for teams shipping AI-generated code.

### [Autter got promoted: From code reviewer to engineering teammate](https://autter.dev/blog/autter-got-promoted.md)

2026-07-13 · Team Autter · 11 min · tags: Product, Story, Engineering

Autter started as a code reviewer. Now it stays with a change from review and testing through merge, production, and the verified fix.

### [We Open-Sourced the Tool We Use to Track AI-Generated Code](https://autter.dev/blog/we-open-sourced-the-tool-we-use-to-track-ai-generated-code.md)

2026-06-22 · Sagnik · 5 min · tags: Open Source, AI, Developer Tools

Git says who committed a line, not who actually wrote it. We built Autter to track AI-generated code at the line level, and today the CLI is open source.

### [What We Did When Our Email Stack Stopped Sending](https://autter.dev/blog/what-we-did-when-our-email-stack-stopped-sending.md)

2026-05-23 · Sagnik · 13 min · tags: Story, Infrastructure, Email

Our dashboards said delivered. Inboxes said nothing. Two months of quiet outbound later, we built Hedwig and email-checker and open sourced both.

### [Why We Block the Merge Button Instead of Posting a Comment](https://autter.dev/blog/why-we-block-the-merge-button-instead-of-posting-a-comment.md)

2026-05-14 · Sagnik · 9 min · tags: Code Review, Opinion, Product

Every code review tool in the market posts comments. We block the merge. That one design decision changed how the entire product got built, what we sell, who we sell it to, and what the moat looks like.

### [AI Reviewing Its Own Code Is a Conflict of Interest](https://autter.dev/blog/ai-reviewing-its-own-code-is-a-conflict-of-interest.md)

2026-05-05 · Sagnik · 8 min · tags: AI, Code Review, Opinion

Every AI code generation company is shipping a review product. The author and the reviewer are the same engine with a different prompt. That is not a code review.

### [Day 1 of a Startup: A Product, No Users, and Infinite Anxiety](https://autter.dev/blog/day-1-of-a-startup.md)

2026-04-28 · Sagnik · 7 min · tags: Story, Startup, Lessons

Launching a startup feels less like firing a rocket and more like pushing a paper boat into a river and then sprinting alongside the bank hoping it doesn't sink.

### [We scanned 10 startup codebases. Here's what we found.](https://autter.dev/blog/we-scanned-10-startup-codebases.md)

2026-04-10 · Sagnik · 5 min · tags: Security, Startups, Code Review

Over the past few weeks, we ran manual codebase scans for 10 early-stage startups. Nine out of ten had at least one high-severity finding.

### [We Spent 3 Weeks Fighting About Names](https://autter.dev/blog/spent-3-weeks-fighting-names.md)

2026-04-08 · Sagnik · 7 min · tags: Story, Branding, Startup

Naming a startup is probably not the most important thing you'll do. But get it wrong and you'll pay for it quietly, in every intro, every cold email, every 'wait, how do you spell that?' on a call.

### [Catching AI-Generated Code Before It Ships](https://autter.dev/blog/ai-generated-code-review.md)

2026-03-28 · Sagnik · 5 min · tags: Code Quality, AI Safety, Code Review, Automation

How engineering teams use autter to detect subtle issues in AI-authored pull requests that pass CI but fail in production.

### [Scaling Code Review Across Distributed Engineering Teams](https://autter.dev/blog/scaling-code-review-distributed-teams.md)

2026-03-25 · Sagnik · 5 min · tags: Developer Experience, Distributed Teams, Code Review, Velocity

How autter eliminates timezone bottlenecks and ensures consistent review quality across distributed teams working in different time zones.

### [Securing Your CI/CD Pipeline Against AI-Introduced Vulnerabilities](https://autter.dev/blog/automated-pipeline-security.md)

2026-03-20 · Sagnik · 5 min · tags: Security, Pipeline, AI Safety

How autter's merge gate catches security vulnerabilities that AI coding assistants introduce — before they reach your deployment pipeline.

### [We were called Shipgate.](https://autter.dev/blog/we-were-called-shipgate.md)

2026-03-19 · Sagnik · 4 min · tags: Story, Branding, Product

Shipgate made sense on paper, but it never made people feel anything. Then I drew an otter at a harbour gate, and the product (and the name) snapped into focus.

### [Enforcing Architecture Decisions at the Merge Gate](https://autter.dev/blog/enforcing-architecture-decisions.md)

2026-03-18 · Sagnik · 5 min · tags: Code Quality, Architecture, Code Review, Governance

How autter automatically enforces architectural boundaries, dependency rules, and design patterns — so your ADRs don't become wishful thinking.

### [Measuring Code Quality in the Age of AI-Assisted Development](https://autter.dev/blog/team-code-quality-metrics.md)

2026-03-15 · Sagnik · 4 min · tags: Analytics, Code Quality, Team Performance

Use autter's analytics to track how AI-generated code impacts your team's quality metrics, review velocity, and production stability.

### [The Harbour Is Open](https://autter.dev/blog/the-harbour-is-open.md)

2026-03-13 · Sagnik · 3 min · tags: Announcement, Product, AI Safety

AI now writes a meaningful share of your pull requests. The code looks right. The tests pass. And yet something is off in ways that only show up in production. autter is a merge gate built for this new reality.

### [Reducing Code Review Fatigue for Senior Engineers](https://autter.dev/blog/reducing-review-fatigue.md)

2026-03-12 · Sagnik · 5 min · tags: Code Review, Developer Experience, Productivity

How autter automates the repetitive parts of code review so your senior engineers can focus on architecture, mentoring, and the decisions that actually require human judgement.

### [Accelerating New Developer Onboarding with Automated Review](https://autter.dev/blog/onboarding-new-developers.md)

2026-03-10 · Sagnik · 5 min · tags: Onboarding, Developer Experience, Code Review

How autter helps new team members learn your codebase conventions, patterns, and architecture through real-time feedback on every pull request.

### [Building Compliance-Ready Audit Trails for Every Code Change](https://autter.dev/blog/compliance-audit-trails.md)

2026-03-08 · Sagnik · 4 min · tags: Compliance, Enterprise, Security

How autter provides automated, tamper-evident audit trails for every pull request — meeting SOC 2, ISO 27001, and HIPAA requirements for change management.

### [Managing Code Review at Scale in Monorepos](https://autter.dev/blog/monorepo-code-review.md)

2026-03-05 · Sagnik · 5 min · tags: Monorepo, Enterprise, Code Review

How autter handles the unique challenges of monorepo code review — cross-package impact analysis, ownership routing, and consistent standards across hundreds of packages.


---

---
title: Nobody Reads Config Diffs With Feeling - Autter Blog
description: Deleting a leaked secret doesn’t delete the key. Where hardcoded secrets hide, why rotation comes first, and why the pull request is the cheapest place to stop them.
url: https://autter.dev/blog/nobody-reads-config-diffs-with-feeling
date: 2026-10-13
author: Sagnik
tags: Security, AI Safety, Merge Gate
reading_time: 8 min
site: Autter - Autter is the code security and assurance layer for the AI coding era: it checks every change before it merges, catches security risks, governs releases, and closes the loop from production failure to verified fix.
---

[← All posts](https://autter.dev/blog)

Oct 13, 2026

# Nobody Reads Config Diffs With Feeling

Deleting a leaked secret doesn’t delete the key. Where hardcoded secrets hide, why rotation comes first, and why the pull request is the cheapest place to stop them.

Sagnik, Founder, autter.dev 8 min read

- Security
- AI Safety
- Merge Gate

*Hardcoded secrets, leaked API keys, and why the pull request is the cheapest place to stop them. A key you delete is a key you can no longer see.*

Two months.

That’s how long a live AWS access key sat in a config file at one of the startups we scanned this spring.

It was committed during an environment migration. Two months later, it still worked. Our scan flagged it. The team rotated it within the hour, which is the good part of the story.

The two months are the other part.

We weren’t there when it went in. But we’ve seen the pattern enough times to narrate it. Someone needs the deploy to work. The key goes in locally, “just to test.” The file gets staged with everything else, committed in one batch, pushed late. The PR looks fine. CI passes, because CI passes everything it wasn’t asked about.

And nobody reads a config diff with feeling.

The short answer

A hardcoded secret is any credential written into your code instead of loaded at runtime. Once it’s been pushed, treat it as compromised. Rotate it at the provider first, then remove it from the code and, if it was exposed, from Git history. Deleting the line on its own fixes nothing. The cheapest fix sits upstream: check every pull request and block the merge when a live credential shows up, so the key never reaches main.

## What counts as a hardcoded secret?

Any credential that lives in your code instead of being injected when the code runs.

API keys. Database URLs with the password inline. OAuth client secrets. Private keys. Signing tokens. Webhook secrets. The token your newest agent needed to talk to the issue tracker.

It has a formal name: CWE-798, Use of Hard-coded Credentials. It also has an informal one: the cheapest breach an attacker will ever get.

Lesson

If a string would let a stranger act as you, it doesn’t belong in a file Git can see.

## How common is it, really?

More common than anyone’s `.gitignore` would like.

This spring we scanned 10 early-stage startups. All voluntary, all anonymized, each scan run in an isolated sandbox. **Six had a secret that had already touched a production branch.** Not an old feature branch. Main.

Here’s what that looked like:

**1. Sitting in HEAD.** A database URL with the admin password, in the current code, in plain sight.

**2. Buried in history.** Keys inside squash-merged commits nobody had opened since the merge.

**3. Rotated, not removed.** One team had rotated a live Stripe secret key and left it in the repo. Half the job. The important half, at least.

**4. Still alive.** The AWS key from the top of this post. Two months. Live.

A standard linter would have caught none of these. Something had to be looking for them on purpose.

- **6 of 10**: startups we scanned had a secret on a production branch

*Source: [Autter codebase scans, spring 2026](https://autter.dev/blog/we-scanned-10-startup-codebases). A small, voluntary sample, not an industry-wide estimate.*

Lesson

“It’s a private repo” is not a control. Private repos get cloned to laptops, CI runners, and contractor machines.

## Where do hardcoded secrets actually hide?

Everyone checks the crate marked `.env`. Here are the seven nobody opens.

**1. Source files.** A key pasted inline “for a quick test.” The test passed. The key stayed.

**2. Config and infrastructure-as-code.** Database passwords in Terraform variables, Helm values, and Compose files. Config diffs get skimmed. Everyone knows it. Including the key.

**3. Test fixtures and mocks.** The “sandbox” key that, on closer inspection, is production.

**4. Notebooks.** Credentials saved in a cell’s output and committed with the notebook.

**5. MCP and agent configs.** Every agent you wire up wants a token. The tokens end up in `mcp.json` and tool definitions, and those get committed with the project.

**6. CI logs.** A debug step that prints the environment. Helpful once. Then permanent.

**7. Git history.** The key you “deleted” three commits ago.

![Blackboard illustration of exposed keys hidden in source files, configuration, test fixtures, notebooks, agent settings, CI logs, and Git history.](https://autter.dev/blog/hardcoded-secrets-locations-v2.webp)

*The obvious environment file is only one place to look. Check source, infrastructure, fixtures, notebooks, agent configs, logs, and history too.*

## Why doesn’t deleting the line fix it?

Because `git rm` is a very confident way to be wrong.

Once a secret is pushed, it’s compromised. Deleting it only hides the evidence from you. Git remembers everything. So do forks, mirrors, cached CI artifacts, and every teammate’s local clone. Public repositories are watched by automated scrapers looking for exactly this.

Removing the line is hygiene. Rotating the key is the fix.

Teams do the hygiene and skip the fix, for understandable reasons. Rotation means finding who owns the key, touching production, and accepting a few nervous minutes. Deleting a line takes ten seconds and feels like progress.

It isn’t progress. It’s closing the curtains on a house that’s already on fire.

Lesson

Rotate first. Clean up second. In that order, every time.

## Why do coding agents make it worse?

Not because they’re careless. Because they’re fast, and nobody briefed them.

An agent asked to make a webhook work will make the webhook work. If the env var won’t load, the value itself is right there. Then it writes the commit message. `fix: webhook handler`. Accurate. Also entirely silent about the key.

Three things change once agents write a real share of your pull requests:

**More diffs.** Every PR is another place a key can slip in. Human attention didn’t scale with the PR count.

**Bigger diffs.** A secret in file 31 of 40 is a secret nobody reads.

**New kinds of files.** Agent and MCP configs are now part of the repo, and most of them want a token.

> “Agents don’t leak secrets because they’re careless. They leak them because they’re fast, and nobody told them the key was special.”

We covered the wider list of agent risks in [Claude Code, Cursor, Codex: Fast Hands, Zero Fear of Consequences](https://autter.dev/blog/ai-coding-assistant-security-risks). Secrets are the one that’s cheapest to stop.

## Where should you catch a secret?

As early as possible, and somewhere that can’t be waved through with one click.

Detection is mostly a solved problem. Good scanners match known key formats for the major cloud, payment, and AI providers, then flag long, random-looking strings that behave like tokens. The hard part is what happens after the scanner speaks.

| Control | When it fires | Good at | Where it slips |
| --- | --- | --- | --- |
| Pre-commit hook | On the developer’s machine, before the commit | Fastest feedback | Has to be installed everywhere. Skippable with `--no-verify`. New laptops and agent sandboxes often run without it |
| Push protection on your Git host | When the push reaches the host | Stops well-known key formats before they land | Usually bypassable by the person pushing. Strongest on formats it already knows |
| PR scanner that comments | When the PR opens | Visible to reviewers | A comment on a green PR gets resolved with one click |
| Merge gate | Before the PR can merge | Enforcement. The merge stays blocked until the key is gone | Only sees what’s in the repo |
| Scheduled repo sweep | Weekly, monthly, quarterly | Finding what’s already in history | Late. The key has been live the whole time |

Run more than one. Just make sure one of them can actually say no. That’s why we [block the merge button instead of posting a comment](https://autter.dev/blog/why-we-block-the-merge-button-instead-of-posting-a-comment).

Lesson

A check you can ignore is just advice.

## What does a gate actually look like?

*Illustrative example. The team, file paths, and timings are made up.*

A developer is testing a payments webhook. The env var won’t load, so the key goes inline. The agent tidies up and opens a 14-file PR.

**Without a gate.** Two approvals. The key is on line 212, in file 11. Merged. A minute later it’s in main, in history, and in every clone made from here on. Week 6, a scheduled sweep finds it. Someone deletes the line. Ticket closed. The key still works.

**With a gate.** The PR opens. The gate flags a live payments key in `src/webhooks/handler.ts`, line 212. Merge blocked. Ten minutes later, the developer revokes the exposed key at the provider, stores its replacement in the secrets manager, and pushes the fix. Autter re-reviews just the change. Clear. The key never reached main and never shipped. (It did touch a branch, so rotation was still required.) But nobody spent six weeks not knowing.

![Blackboard illustration of a pull-request diff with an exposed key under a magnifying glass, stopped by a merge barrier before the main repository.](https://autter.dev/blog/hardcoded-secrets-merge-gate-v2.webp)

*Illustrative example: a gate keeps the key out of main. Rotation still matters when it has touched a branch.*

Want to see the real thing? The [live demo](https://app.autter.dev/demo-access) workspace has a payments-service change flagged critical for an exposed API key in environment config. Sample data, real product.

## A key already leaked. Now what?

**1. Treat it as compromised.** Private repo, “only up for an hour,” doesn’t matter.

**2. Rotate at the provider. Now.** Revoking the value is what actually stops the risk. This stays a human step. The owner should cycle a production credential, not a bot.

**3. Move it out of the code.** Load it from a secrets manager or inject it at runtime. Not another `.env` waiting to be committed.

**4. Purge history if it was public or widely shared.** Then check the provider’s logs for anything that used the key in the gap.

![Blackboard illustration of a revoked broken key, its replacement stored in a secure vault, and access logs inspected with a magnifying glass.](https://autter.dev/blog/hardcoded-secrets-playbook-v2.webp)

*Rotate first. Clean up second.*

## Where does Autter fit (and where doesn’t it)?

Every PR that ships is a vessel requesting entry. Autter decides what clears the harbour.

It’s the assurance layer between every pull request and main, whoever opened it. Every PR [executes in an isolated sandbox](https://autter.dev/features/code-review) against your base branch. Dependencies are vetted against real registries. **Secrets and CVEs are caught at the gate,** and the merge button stays blocked until the checklist clears. Then it unlocks with the evidence attached.

**Findings land on the exact line,** ranked by severity, with a proposed fix. Push the fix and Autter re-reviews just the change.

**Every change is classified human or AI,** and generated code earns extra scrutiny.

**Your agents can see the findings too.** Through the [Autter MCP server](https://autter.dev/features/mcp), the agent that added the key can be the one that removes it.

**Your standards stay yours.** Point Autter at your team’s rules and exclusions in a config file you own.

**Everything ships with a receipt:** the exact run, the failing case, the trace.

And for what’s already sitting in main, there are Codebase Scans: on demand, on a schedule, or at release time.

The honest part:

**Autter won’t rotate your keys.** Revoking a production credential is a human call, and it should stay one.

**Autter only sees the repo.** A key pasted into Slack, a ticket, or a shared doc is out of reach.

**Autter can’t un-leak history.** If a key already shipped, the playbook above comes first. We stop the next one.

**Autter isn’t a secrets manager.** It makes sure keys end up in one. It doesn’t store them.

**Autter will sometimes be wrong.** If a finding doesn’t hold up, you dismiss it. Nothing blocks your merge on a hunch.

## Frequently asked questions

### Why isn’t deleting the line enough?

Git history, forks, and every clone still hold the value. Rotate the key at the provider, remove it from the code, then purge history if it was exposed.

### Is secret scanning the same as SAST?

No. Secret scanning finds committed credentials. SAST finds insecure code patterns, like injection or a missing auth check. You want both on every pull request.

### How does a scanner tell a secret from a random string?

Two signals. Known formats, which are high-confidence patterns for specific providers. And entropy: long, random-looking strings that behave like tokens even when the format is unfamiliar. Entropy finds more and guesses more, which is why every finding needs context, not just a regex match.

### Is a private repository safe enough?

No. Private code still lands on laptops, CI runners, and contractor machines, and six of the ten startups we scanned had a secret on a production branch. “Private” describes who’s supposed to see it. Not who can.

### Do AI coding agents leak more secrets?

They write more code, faster, in bigger diffs, and they bring new config files that want tokens. More chances for a key to slip in, fewer human eyes per line. The fix isn’t slowing the agent down. It’s putting a gate after it.

## Our read

Back to that config file.

Two months. One live AWS key. A team that did everything right the moment they knew. They just knew two months late.

Hardcoded secrets are the rare security problem that’s cheap to prevent and expensive to ignore. AI didn’t invent it. It multiplied the number of commits where it can happen.

So stop treating a found key as cleanup. It’s an incident. And stop treating the pull request as a place for suggestions. For secrets, it’s a gate.

Calm seas ahead. **Hire Autter for a peaceful weekend.**

[Start Now](https://app.autter.dev/) · [Book a demo](https://autter.dev/contact)

*P.S.*

**Sagnik:** I found a key in the repo. Rotated it. Deleted it. Wrote a postmortem.

**Tanvi:** Good.

**Sagnik:** Then I found the same key in the postmortem.

**Tanvi:** Sagnik.

**Sagnik:** It was a very thorough postmortem.

*(currently: the key is dead, the postmortem is redacted, and Tanvi reads every postmortem now)*

**Sources:** [Autter: We scanned 10 startup codebases](https://autter.dev/blog/we-scanned-10-startup-codebases) · [CWE-798: Use of Hard-coded Credentials](https://cwe.mitre.org/data/definitions/798.html) · [OWASP Secrets Management Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html) · [GitHub Docs: About secret scanning](https://docs.github.com/en/code-security/secret-scanning/introduction/about-secret-scanning)

**Keep reading:** [We scanned 10 startup codebases](https://autter.dev/blog/we-scanned-10-startup-codebases) · [Why We Block the Merge Button Instead of Posting a Comment](https://autter.dev/blog/why-we-block-the-merge-button-instead-of-posting-a-comment) · [How to Prioritize Vulnerabilities: CVSS, EPSS, KEV, and Reachability](https://autter.dev/blog/how-to-prioritize-vulnerabilities)

### See Autter on your own code.

A 30-minute walkthrough with the founders. Bring a repo and watch Autter review a live pull request.

[Book a demo](https://autter.dev/contact)

## Put an assurance layer on every release.

Autter reviews every pull request before it merges, backed by humans. Connect a repo and see your first findings today.

[Get started](https://app.autter.dev/login)

## Keep reading

[Oct 10, 2026 · 6 min read The PR Queue Wasn’t Built for This Much Code AI made code abundant. Human attention did not scale with it. Why we built Autter Triage around the changes that actually deserve deeper review.](https://autter.dev/blog/the-pr-queue-wasnt-built-for-this-much-code)


---

---
title: The PR Queue Wasn’t Built for This Much Code - Autter Blog
description: AI made code abundant. Human attention did not scale with it. Why we built Autter Triage around the changes that actually deserve deeper review.
url: https://autter.dev/blog/the-pr-queue-wasnt-built-for-this-much-code
date: 2026-10-10
author: Sagnik
tags: Code Review, AI, Engineering, Product
reading_time: 6 min
site: Autter - Autter is the code security and assurance layer for the AI coding era: it checks every change before it merges, catches security risks, governs releases, and closes the loop from production failure to verified fix.
---

[← All posts](https://autter.dev/blog)

Oct 10, 2026

# The PR Queue Wasn’t Built for This Much Code

AI made code abundant. Human attention did not scale with it. Why we built Autter Triage around the changes that actually deserve deeper review.

Sagnik, Founder, autter.dev 6 min read

- Code Review
- AI
- Engineering
- Product

AI made writing code dramatically cheaper. Reviewing it did not get cheaper at the same rate.

An agent can open three pull requests while you are still trying to understand the first one. It can refactor a service, upgrade a dependency, add tests and fix a bug before someone on the team has decided whether any of those changes are actually worth shipping.

For years, opening a pull request carried some natural friction. A developer had to understand the problem, write the code, test it and decide it was ready enough to ask someone else to spend time reviewing it. Agents remove a lot of that filter. Trying something is cheap now. Opening a PR for it is cheap. Rewriting it is cheap. The expensive part starts after that, when someone still has to understand what changed, what it touches, whether the tests prove anything useful and whether it should reach production.

That is the problem we built **Autter Triage** around.

## A list of pull requests is not enough anymore

Most PR queues are really just lists. You get an author, reviewers, labels, checks and a timestamp. That works until the amount of code entering the queue starts growing faster than the team can inspect it.

Imagine opening GitHub in the morning to fifteen PRs. One changes copy. One upgrades an internal package. Three are small fixes created overnight by an agent. One changes authentication. Another touches a payment retry path. Two are part of the same stack, and another has been sitting there for three days because the reviewer it actually needs was never assigned.

On the screen, they mostly look like equivalent rows.

But they clearly are not equivalent work.

A seven-line change to authentication may deserve far more scrutiny than a 700-line refactor in an isolated internal package. A dependency bump may look routine until you realise it affects a package sitting in the request path of three services. A PR near the bottom of the list may be the actual blocker for four other changes above it.

The questions engineers care about are not “Which PR is newest?” or “Which one has the most comments?” They are things like: Which change has the largest blast radius? Which one is missing meaningful tests? Which one is blocking other work? Which one needs someone who actually understands this part of the system?

Those are context problems, not sorting problems.

And this is where we think the shape of code review has to change.

Good review is expensive because judgment is expensive. Understanding whether a new abstraction belongs in the architecture takes time. Thinking through what happens when a payment provider times out takes time. Looking at a database migration and tracing what might break downstream takes time.

At the same time, not every PR deserves that level of attention.

If an agent changes a small utility, the affected behaviour is well tested, nothing sensitive is involved and the blast radius is tiny, spending thirty minutes of senior engineering time on it probably does not make sense. But teams often end up in one of two places: they inspect everything deeply and become the bottleneck, or the queue gets large enough that review quality starts collapsing.

The more useful question is not, **“How do we review every PR faster?”**

It is, **“Which PRs actually deserve deep human attention?”**

That became the foundation for Triage.

![A nautical chalkboard contrasts a seven-line authentication change needing deep review with a 700-line internal refactor whose evidence should be checked. Blast radius, test evidence, and ownership inform priority.](https://autter.dev/blog/pr-queue-context-v1.webp)

*The size of a diff tells you little about the attention it deserves.*

## We wanted the queue to understand the change, not just show it

A diff tells you what changed. It does not necessarily tell you what that change means inside the system.

So when Autter looks at a pull request, we try to build a much broader picture around it. That can include dependencies, downstream blast radius, test evidence, security findings, ownership, relevant reviewers, related PRs, stacked dependencies and, where available, runtime and production signals.

The goal is not to attach another AI-generated risk score to the PR.

If Autter says something is risky, the engineer should be able to understand why. Maybe the change touches a payment fallback used by three services and there is no test covering the affected behaviour. Maybe a dependency update introduces a known vulnerability. Maybe the diff looks harmless, but it sits at the bottom of a stack and everything above it is waiting on this one change.

That is useful because it gives someone something to do.

“High risk” is not an action.

“Payment fallback changed, three downstream services affected, no test covers the failure path” is.

The same idea applies to stacked PRs. If PR C depends on PR B, which depends on PR A, and the real problem was introduced in PR A, we do not want someone spending time investigating the same symptom three times. The queue should understand the chain and surface where the problem actually started.

This matters more as agents do more of the implementation work. Engineering work starts looking less like isolated PRs and more like connected changes moving through a system.

## Agents should remove work from the queue too

There is an easy trap with agentic development.

More coding agents create more code. More code creates more PRs. More PRs create more review work. So teams add reviewing agents, which produce more summaries and more comments for humans to process.

You can very quickly end up with more automation and somehow more work.

That is not what we want Triage to do.

If a test is missing, an agent may be able to prepare it. If a review finding has an obvious fix, an agent may be able to create the patch. If several PRs are blocked by one issue lower in a stack, Autter should point to the origin instead of asking a human to rediscover it several times.

Agents should not only add work to the queue. They should help clear it.

The human should appear when judgment is actually required.

There is another part of this we care about a lot: the queue should not forget everything after merge. Production is where a lot of the truth appears. A PR can pass review and still create an incident. A green test suite can still miss the path customers actually use. A supposedly low-risk part of the codebase can turn out to be operationally critical.

That evidence should come back.

If a certain part of the system caused an incident last week, the next PR touching it probably deserves more scrutiny. If a particular type of change repeatedly leads to rollbacks, that should eventually influence how similar changes are treated.

This is why we keep coming back to the idea that review, testing and production observability should not be completely separate systems. You review something, test it, ship it, observe what happens and carry that evidence into the next change.

![A chalkboard connects Review, Test, Ship, and Observe, with a return arrow carrying production evidence back into the next review.](https://autter.dev/blog/pr-queue-feedback-v1.webp)

*Production evidence should inform the next change.*

## The pull request is changing jobs

For a long time, the pull request was mostly a collaboration surface between developers. One person wrote some code, another person reviewed it, they discussed a few things and eventually merged it.

That model is already changing.

The author may now be an agent. The first reviewer may be an agent. Tests may have been generated by an agent. The fix for a failed build may also be generated by an agent. Several systems may have touched the change before a human ever sees it.

At that point, the pull request becomes something more important than a place to leave comments. It becomes a control point between software being generated and software reaching production.

And a flat list of open PRs is not enough for that.

The queue needs to understand which changes are consequential, which ones are blocked, what evidence exists, what is missing and who, or what, needs to act next.

That is what we want **Autter Triage** to become.

Not a prettier inbox. Not another AI summary beside a diff. A layer that helps engineering teams understand where their limited attention actually needs to go.

Because AI is making code abundant.

**Confidence in what should ship is becoming scarce.**

### See Autter on your own code.

A 30-minute walkthrough with the founders. Bring a repo and watch Autter review a live pull request.

[Book a demo](https://autter.dev/contact)

## Put an assurance layer on every release.

Autter reviews every pull request before it merges, backed by humans. Connect a repo and see your first findings today.

[Get started](https://app.autter.dev/login)

## Keep reading

[Oct 9, 2026 · 8 min read How to Prioritize Vulnerabilities: CVSS, EPSS, KEV, and Reachability How to prioritize vulnerabilities: use CVSS for severity, EPSS for likelihood, KEV for proof, and reachability for reality. Then stop patching in alphabetical order.](https://autter.dev/blog/how-to-prioritize-vulnerabilities) [Oct 13, 2026 · 8 min read Nobody Reads Config Diffs With Feeling Deleting a leaked secret doesn’t delete the key. Where hardcoded secrets hide, why rotation comes first, and why the pull request is the cheapest place to stop them.](https://autter.dev/blog/nobody-reads-config-diffs-with-feeling)


---

---
title: How to Prioritize Vulnerabilities: CVSS, EPSS, KEV, and Reachability - Autter Blog
description: How to prioritize vulnerabilities: use CVSS for severity, EPSS for likelihood, KEV for proof, and reachability for reality. Then stop patching in alphabetical order.
url: https://autter.dev/blog/how-to-prioritize-vulnerabilities
date: 2026-10-09
author: Tanvi
tags: Security, Code Review, Merge Gate
reading_time: 8 min
site: Autter - Autter is the code security and assurance layer for the AI coding era: it checks every change before it merges, catches security risks, governs releases, and closes the loop from production failure to verified fix.
---

[← All posts](https://autter.dev/blog)

Oct 9, 2026

# How to Prioritize Vulnerabilities: CVSS, EPSS, KEV, and Reachability

How to prioritize vulnerabilities: use CVSS for severity, EPSS for likelihood, KEV for proof, and reachability for reality. Then stop patching in alphabetical order.

Tanvi, Founder, autter.dev 8 min read

- Security
- Code Review
- Merge Gate

One startup we scanned had a critical remote-code-execution flaw in a serialization library. It had been in their dependency tree for four months. It arrived when they upgraded a completely unrelated package.

CI was green the whole time. CI runs the tests you wrote, and nobody had written one called *please don't let strangers run code on our server.*

They weren't careless. They were busy. And a list of 400 "criticals" is not a plan. It's a to-do list written by someone who has never met your sprint.

The short answer

Combine three signals. CVSS tells you how severe a flaw is in theory. EPSS tells you how likely it is to be exploited. CISA's KEV catalog tells you it already has been. Then add the one signal no public feed can give you: whether the vulnerable code is actually reachable in *your* codebase. Patch anything in KEV first, then high-EPSS criticals, then everything else on a schedule. Stop treating a raw CVSS score as your roadmap.

Tens of thousands of CVEs are published every year. You cannot fix them all. Prioritization isn't a nice-to-have. It's the whole job.

## What's the difference between CVSS, EPSS, and KEV?

Picture every vulnerability as a vessel requesting entry to your harbour. Capt. Patch has four questions before anyone clears the gate.

| Signal | The question it answers | Source | What it can't tell you |
| --- | --- | --- | --- |
| **CVSS** | How big is the cannon? (severity, 0.0 to 10.0) | FIRST / NVD | Whether anyone will fire it, or whether it's pointed at you |
| **EPSS** | How likely is someone to fire it? (probability of exploitation, plus a percentile, updated daily) | FIRST, free | Anything about your environment |
| **CISA KEV** | Has it already been fired at someone? | CISA | What hasn't been caught yet. It's a floor, not a ceiling |
| **Reachability** | Is the cannon pointed at *your* harbour? | Your own codebase | Nothing. It just needs your repo |

![A nautical chalkboard compares CVSS severity, EPSS likelihood, KEV confirmed exploitation, and reachability in your codebase, with exposure and blast radius added as context.](https://autter.dev/blog/vulnerability-prioritization-signals-v1.webp)

*Four signals answer four different questions. Your repository supplies the context.*

Everyone has CVSS. Fewer teams use EPSS. Almost nobody does reachability, because it requires reading your code, which is the one thing a CVE feed can't do.

## How do you actually prioritize vulnerabilities?

Four lanes. Work them top to bottom.

**1. Already in the harbour (it's in KEV).** Drop everything. Exploitation is confirmed, so the score is decoration. A 5.4 in KEV outranks a 9.8 that exists only in theory. KEV entries come with remediation due dates for a reason.

**2. Pirates on the horizon (high EPSS + high CVSS).** You're next. No KEV listing yet doesn't mean no raid. It means nobody's filed the paperwork.

**3. Big cannon, no pirates (high CVSS, low EPSS).** Schedule it. Normal cadence. But EPSS refreshes daily, so a low score today is not a pardon.

**4. Rowboats (low CVSS, low EPSS).** Batch into routine maintenance. Do not convene a war room for a rowboat.

Then apply the part no feed knows: **blast radius.** Is it reachable? Is it internet-facing? Does it touch auth, billing, or user data? Is there a compensating control? A medium on your public API can outrank a critical in an internal script nobody has opened since 2023.

![Four chalkboard priority lanes: fix KEV first, prioritize high EPSS with high CVSS next, schedule high CVSS with low EPSS, and batch low scores into routine maintenance. Adjust each lane for reachability, exposure, and blast radius.](https://autter.dev/blog/vulnerability-prioritization-lanes-v1.webp)

*Work the lanes in order, then apply the reality of your own codebase.*

## What does this look like on a real afternoon?

Three findings. One engineer. Slightly unreasonable expectations.

| Finding | CVSS | EPSS | In KEV? | Reachable? | Where it lives | Verdict |
| --- | --- | --- | --- | --- | --- | --- |
| A | 9.8 | Low | No | No, vulnerable function never called | Transitive dep in a build tool | Schedule it. Keep your weekend. |
| B | 6.5 | Medium | **Yes** | **Yes** | Public API | Fix today. |
| C | 8.1 | High | No | Yes | Internal admin panel | This week. |

Rank by CVSS alone and you fix A, C, B. Rank by evidence and you fix B, C, A. Raw CVSS gets you the exact wrong order, delivered with great confidence, which is the most dangerous kind.

*(Illustrative numbers, not a real incident. The ordering logic is the point.)*

![A chalkboard shows CVSS-only ordering A, C, B beside evidence-based ordering B, C, A. Finding B is exploited and reachable despite its lower 6.5 score. The findings are illustrative.](https://autter.dev/blog/vulnerability-prioritization-order-v1.webp)

*Same findings. Different priorities. Evidence moves the exploited public API ahead of the unreachable build dependency.*

## Why is timing the part everyone ignores?

Because nobody's job description includes **"notice on day one."**

When we scanned 10 startup codebases, 8 had a dependency with a known critical CVE. The average CVE had been public for **94 days**. The average number of PRs merged in that window: **38**. That's 38 chances to notice. Nobody did, because at merge time, noticing wasn't anyone's job.

A ranking refreshed once a quarter is not a ranking. It's a historical document. [Full scan findings here.](https://autter.dev/blog/we-scanned-10-startup-codebases)

## What do CVSS, EPSS, and KEV not catch?

Everything without a CVE number. Which is, inconveniently, a lot of your own code.

In that same scan, a Copilot-generated API handler validated the request body perfectly. It never validated *who was sending it.* Any authenticated user could trigger a job scoped to another user's data. No CVE. No CVSS. No EPSS. No KEV. Invisible to every scoring system in this post.

The same goes for the live Stripe key that was rotated but never removed from the repo (6 of 10 codebases had a secret that had touched a production branch), and the migration that would've failed against 180,000 rows in production but sailed through an empty staging database.

Scores rank known flaws in other people's code. The expensive ones are increasingly in yours, especially when AI is writing a share of it.

## Where does Autter fit?

Honest version: a scoring framework tells you what to fix. It doesn't stop the next bad change from landing.

**Codebase scans** run on demand, on a schedule, after a default-branch push, or at a release tag. They combine focused security agents with established tooling across code, dependencies, containers, infrastructure, APIs, and secrets. The report is deduplicated and ranked by reachability, exploit evidence, severity, and repository context, with a CycloneDX SBOM attached. So you get a queue, not a pile.

**The merge gate** handles the rest. Every PR executes in an isolated sandbox against your base branch. Dependencies are vetted against real registries. Secrets and CVEs get caught at the gate. The merge stays blocked until the checklist clears.

> “A CVSS score is a comment. A merge gate is enforcement.”

That's the whole bet. Comments get scrolled past at 4:47pm on a Friday. [We wrote a whole post about it.](https://autter.dev/blog/why-we-block-the-merge-button-instead-of-posting-a-comment)

What Autter doesn't do: replace your CI (it sits on top of it) or replace your humans (it clears the repetitive stuff so they can argue about architecture instead). You still decide what risk is acceptable.

**Want to see it first?** Run it on one of our demo repos with planted findings, or connect your own. The Harbour plan is free (10 PR reviews a month on one repository), public repos are free, and your code never trains a model. [Start now](https://app.autter.dev/login) or [book a demo](https://autter.dev/contact).

## Frequently asked questions

### Should I patch every critical CVSS first?

No. Patch KEV first regardless of score, then use EPSS and reachability to rank the rest. "Patch all criticals" floods the team and still misses exploited mid-scored bugs.

### Is EPSS free?

Yes. FIRST publishes EPSS scores openly, updated daily, for the full CVE set.

### Does low EPSS mean I can ignore it?

No. It's a probability, not a promise. It tells you where to look later, not that you never have to.

### What if a vulnerability has no CVSS score yet?

Don't wait for NVD. Some actively exploited flaws hit KEV before they're scored. KEV membership is a priority signal on its own.

### What about vulnerabilities in my own code?

They have no CVE, so none of these scores apply. That's what reviewing the change itself is for: running it, testing it, and blocking the merge if it fails.

## Our read

Prioritization is where vulnerability management is won or lost, and the data to do it well is free. Rank by evidence. Then make sure the next bad change can't walk in while you're busy ranking.

The startup with the four-month-old RCE didn't need a smarter list. It needed something standing at the gate the day that dependency arrived.

Capt. Patch has been standing there since. [Hire Autter for a peaceful weekend.](https://app.autter.dev/login)

*Sources: exploitation probability per [FIRST EPSS](https://www.first.org/epss/); confirmed exploitation per [CISA KEV](https://www.cisa.gov/known-exploited-vulnerabilities-catalog); severity per [NVD](https://nvd.nist.gov/vuln-metrics/cvss); scan statistics from [Autter's own codebase scans](https://autter.dev/blog/we-scanned-10-startup-codebases).*

**Keep reading:** [Securing Your CI/CD Pipeline Against AI-Introduced Vulnerabilities](https://autter.dev/blog/automated-pipeline-security) · [Catching AI-Generated Code Before It Ships](https://autter.dev/blog/ai-generated-code-review)

## P.S.

**Sagnik:** What if we build our own EPSS? Autter Probability Scoring System. APSS.

**Tanvi:** FIRST already publishes EPSS. Free. Daily. For every CVE.

**Sagnik:** Ours would have a mascot.

**Tanvi:** Ours would also have a maintenance burden.

**Sagnik:** *(has already drawn the logo)*

*(currently: the logo is ready, the roadmap is not)*

### See Autter on your own code.

A 30-minute walkthrough with the founders. Bring a repo and watch Autter review a live pull request.

[Book a demo](https://autter.dev/contact)

## Put an assurance layer on every release.

Autter reviews every pull request before it merges, backed by humans. Connect a repo and see your first findings today.

[Get started](https://app.autter.dev/login)

## Keep reading

[Oct 5, 2026 · 9 min read Claude Code, Cursor, Codex: Fast Hands, Zero Fear of Consequences The real security risks of Claude Code, Cursor, and Codex: insecure code, leaked secrets, bad packages, and prompt injection. And why a merge gate beats a polite suggestion.](https://autter.dev/blog/ai-coding-assistant-security-risks) [Oct 10, 2026 · 6 min read The PR Queue Wasn’t Built for This Much Code AI made code abundant. Human attention did not scale with it. Why we built Autter Triage around the changes that actually deserve deeper review.](https://autter.dev/blog/the-pr-queue-wasnt-built-for-this-much-code)


---

---
title: Claude Code, Cursor, Codex: Fast Hands, Zero Fear of Consequences - Autter Blog
description: The real security risks of Claude Code, Cursor, and Codex: insecure code, leaked secrets, bad packages, and prompt injection. And why a merge gate beats a polite suggestion.
url: https://autter.dev/blog/ai-coding-assistant-security-risks
date: 2026-10-05
author: Tanvi
tags: AI Safety, Security, Code Review, Merge Gate, Opinion
reading_time: 9 min
site: Autter - Autter is the code security and assurance layer for the AI coding era: it checks every change before it merges, catches security risks, governs releases, and closes the loop from production failure to verified fix.
---

[← All posts](https://autter.dev/blog)

Oct 5, 2026

# Claude Code, Cursor, Codex: Fast Hands, Zero Fear of Consequences

The real security risks of Claude Code, Cursor, and Codex: insecure code, leaked secrets, bad packages, and prompt injection. And why a merge gate beats a polite suggestion.

Tanvi, Founder, autter.dev 9 min read

- AI Safety
- Security
- Code Review
- Merge Gate
- Opinion

## Your AI Coding Assistant Is a Brilliant Intern With Root Access

*Claude Code, Cursor, and Codex ship fast. Nobody ships a cost-free thing. Here's the bill, and who's supposed to check it.*

Picture a Tuesday.

A pull request lands. Title: `fix: small typo`.
Forty files changed. Tests are green. The diff is confident, tidy, and beautifully commented.

Somewhere around file thirty-one, an API key is sitting in a config, wearing a little hat. Nobody wrote it on purpose. The assistant needed the service to work, so it made the service work.
That is the job it was given. Nobody told it that "works" and "safe" are different harbors.

This is the story of AI coding assistant security. It's not a horror story. **It's just a Tuesday.**

## What are the main AI coding assistant security risks?

**AI coding assistant security is the set of risks that appear when tools like Claude Code, Cursor, and Codex write, edit, and refactor your code.** They fall into three buckets:

- The code can be insecure.
- The context can leak.
- The assistant itself can be manipulated.

We're not telling you to stop using them. They're genuinely good. We use them. The point is that speed without a checkpoint is just a faster way to reach the incident channel.

| Risk | What it looks like | Why you should care |
| --- | --- | --- |
| Insecure generated code | Injection-prone queries, weak auth, hand-rolled crypto | Plausible-looking vulnerabilities, shipped with confidence |
| Hardcoded secrets | Keys and tokens written into files, configs, or tests | The assistant doesn't know your `.env` is a feelings-free zone |
| Risky dependencies | Outdated, abandoned, or flat-out invented packages | Supply-chain problems, delivered by autocomplete |
| Prompt injection | Hidden instructions in a repo file, issue, README, or tool | A document starts giving orders to your agent |
| Excessive agency | Broad file, shell, or API access granted "to save time" | The blast radius grows with every permission you hand out |

We don't have a shiny industry-wide percentage to wave at you, and we're not going to invent one. What we do have: when we ran manual scans on [10 early-stage startup codebases](https://autter.dev/blog/we-scanned-10-startup-codebases), nine had at least one high-severity finding. That's before anyone blamed an AI.

## 1. Insecure code that looks great

**The problem isn't that the code is ugly. It's that it's handsome.**

A model trained to produce confident, plausible code is very good at confident, plausible code. That includes the kind with a missing authorization check or a query built by string concatenation. It compiles. It passes the tests it wrote for itself. It reads like a senior engineer on a good day.

> “Green tests mean the code does what the tests expected. They don't mean the tests expected enough.”

That's why diff-only review struggles here. The bug isn't in the lines that changed. It's in how those lines behave next to everything else.

## 2. Secrets and context that wander off

**Assistants read your repo. Then they write into it.**

Keys end up in files. Tokens end up in test fixtures. Internal URLs end up in comments. Nobody is being malicious. The model is doing what it was asked, with the information it was given, in the most direct way available. Directness and secret hygiene have never been friends.

Whatever data-handling settings your vendor offers, the problem remains once a secret lands in a commit. Rotating keys at 2 a.m. isn't a personality you want.

## 3. Dependencies that may or may not exist

**"Just add this package" is a sentence that deserves a background check.**

Assistants will happily suggest a library that's outdated, abandoned, or not quite the name you think it is. A package that sounds right is not the same as a package that is right. If you've ever typo-squatted yourself, you already know the vibe.

## 4. Prompt injection: when a README starts giving orders

**An agent that reads untrusted content can be steered by untrusted content.**

If your assistant reads an issue, a dependency's docs, a file in a repo, or a connected tool, hidden instructions in any of those can become part of what the model acts on. Researchers have repeatedly shown this steering coding agents toward leaking secrets or making changes nobody asked for.

The fix isn't "write a stricter prompt." You cannot politely ask a model to stop listening. The fix is least privilege, plus a layer that checks what actually lands in your code, no matter who talked the agent into writing it.

## 5. Too much agency, too little supervision

**Every permission is a larger blast radius.**

Shell access, API access, write access to everything, all handed over because it makes the demo smoother. This is how an intern with a good attitude becomes an intern with root access. The attitude was never the problem.

## So who checks the assistant?

![Captain Patch inspects a leaking cargo crate under a lantern while a closed harbour barrier holds the shipment.](https://autter.dev/blog/ai-coding-assistant-checkpoint-v1.webp)

*Keep the speed. Inspect what actually reaches the gate.*

Here's the part where everyone gestures at a built-in review feature.

Most assistants now have some version of one. It's useful. It's also the same engine that wrote the code, grading the code it wrote, inside the tool that benefits when you ship more of it. We've [made this argument at length](https://autter.dev/blog/ai-reviewing-its-own-code-is-a-conflict-of-interest), but the short version is: author and reviewer shouldn't share a brain, a metric, or a payroll.

Even a great reviewer has a second problem. A comment is advice. Advice gets scrolled past at 4:47 p.m. on a Friday.

That's the gap Autter sits in. Autter is a merge gate, not a suggestion box. Every pull request, human-written or AI-written, runs through the gate before it reaches main.

| What the assistant gives you | What Autter adds at the gate |
| --- | --- |
| Inline hints from the model that wrote the code | The change is cloned into an isolated sandbox and **executed** against your base branch. The verdict comes from behavior, not vibes |
| "Looks fine" | **Secrets and CVEs** are caught at the gate, before they reach main |
| "Added a package!" | **Dependencies vetted** against real registries |
| Nothing marks who wrote what | Every change is **classified human or AI**, and the [Autter CLI](https://autter.dev/features/cli) tracks AI provenance at the line level |
| A comment you can ignore | A **merge gate** that holds the merge until the checklist clears |
| A finding with no receipt | Every finding ships with its receipt: the sandbox run, the failing case, the trace |

You can also connect your coding agents to Autter directly through the [MCP server](https://autter.dev/features/mcp), so they get reviews, findings, and fixes in the loop where they work. Your code stays yours: it runs in an isolated sandbox, it's never used to train a model, and the source is destroyed when the review ends. The [security page](https://autter.dev/security) has the details.

## The honest part

We like being honest. It's cheaper than being impressive.

- **Autter doesn't write your code.** We don't sell a model or have a generation product to protect. Our incentives point at blocking the right things.
- **Autter doesn't stop an agent from being prompt-injected.** It checks what the agent produced before it merges. Least privilege on the agent is still your job.
- **Autter is not a runtime WAF.** It secures what goes into main. It doesn't stand in front of your production traffic.
- **Autter will sometimes be wrong.** When it is, you dismiss the finding and it learns from the override. Nothing blocks your merge on a hunch.

## Frequently asked questions

**Should we stop using Claude Code, Cursor, or Codex?**

No. They're excellent, and your competitors are using them. Keep the speed and add a checkpoint.

**Which risk is the biggest?**

For most teams it's volume: a lot of generated code, reviewed by a limited number of humans. Leaked secrets come next. Prompt injection grows with every permission you grant an agent.

**Does Autter replace human reviewers?**

No. It clears the repetitive, easy-to-miss stuff so your reviewers spend their time on architecture and design, not on spotting a missing null check.

**Does Autter replace our CI?**

No. CI runs the jobs you wrote. Autter sits on top as the merge gate and decides whether the change is safe to merge.

**How much does it cost?**

You can start free. Pricing follows PR volume, not seats, so adding developers or coding agents doesn't add a per-seat fee. See [pricing](https://autter.dev/pricing).

## Our read

Back to that Tuesday.

The `fix: small typo` PR, forty files, one key wearing a hat. In one version of this story, it gets merged because the tests are green and everyone is busy. In the other, it never clears the gate.

The assistants will keep getting faster. That's fine. Let them. Just make sure that the thing deciding what ships isn't the thing that wrote it.

Build faster. Ship safer. Enjoy your vacation.

**Hire Autter for a peaceful weekend.** [Start Now](https://app.autter.dev/) or [book a demo](https://autter.dev/contact).

*Related:* [*Why we block the merge button instead of posting a comment*](https://autter.dev/blog/why-we-block-the-merge-button-instead-of-posting-a-comment) *·* [*Autter vs Claude Code Review*](https://autter.dev/blog/autter-vs-claude-code-review)

**P.S.**

**Sagnik:** What if we just tell the assistant to "be more secure"?

**Tanvi:** That's the plan?

**Sagnik:** It's a prompt, Tanvi. Prompts are free.

**Tanvi:** They are not and even if they were, so is "please don't get hacked."

*(currently: Sagnik adding "be secure" to the system prompt.)*

### See Autter on your own code.

A 30-minute walkthrough with the founders. Bring a repo and watch Autter review a live pull request.

[Book a demo](https://autter.dev/contact)

## Put an assurance layer on every release.

Autter reviews every pull request before it merges, backed by humans. Connect a repo and see your first findings today.

[Get started](https://app.autter.dev/login)

## Keep reading

[Sep 12, 2026 · 11 min read GitHub Refusing Merge Is Not an SDLC Why GitHub's real merge levers still stop at the PR — and how Autter extends enforcement from authorship through runtime and repair.](https://autter.dev/blog/github-refusing-merge-is-not-an-sdlc) [Oct 9, 2026 · 8 min read How to Prioritize Vulnerabilities: CVSS, EPSS, KEV, and Reachability How to prioritize vulnerabilities: use CVSS for severity, EPSS for likelihood, KEV for proof, and reachability for reality. Then stop patching in alphabetical order.](https://autter.dev/blog/how-to-prioritize-vulnerabilities)


---

---
title: GitHub Refusing Merge Is Not an SDLC - Autter Blog
description: Why GitHub's real merge levers still stop at the PR — and how Autter extends enforcement from authorship through runtime and repair.
url: https://autter.dev/blog/github-refusing-merge-is-not-an-sdlc
date: 2026-09-12
author: Autter Team
tags: Code Review, GitHub, Merge Gate, SDLC
reading_time: 11 min
site: Autter - Autter is the code security and assurance layer for the AI coding era: it checks every change before it merges, catches security risks, governs releases, and closes the loop from production failure to verified fix.
---

[← All posts](https://autter.dev/blog)

Sep 12, 2026

# GitHub Refusing Merge Is Not an SDLC

Why GitHub's real merge levers still stop at the PR — and how Autter extends enforcement from authorship through runtime and repair.

Autter Team, Autter 11 min read

- Code Review
- GitHub
- Merge Gate
- SDLC

A common assumption about AI code review is that turning it on adds a safety interlock: if the reviewer dislikes a change, the change cannot merge. For most of the tools in this category that is not how it works, and the reason is not a missing feature or a pricing tier. It is the GitHub merge mechanics. A reviewer that posts a comment, or completes a check with a neutral result, is structurally incapable of stopping a merge no matter how confident it is.

That fact alone ends most of the category. But even when you *do* wire a real gate — a required status check that is willing to conclude `failure` — you have only secured one stage of the lifecycle. The gate does not know who actually wrote the line. It does not survive into production. It does not turn an incident back into a verified fix under the same policy.

This is a mechanics explainer: what GitHub actually blocks on, why a comment-only or neutral reviewer slips past it, why a merge gate alone is still not an SDLC, and how Autter builds the longer loop — CLI/MCP provenance, an enforceable PR gate, runtime telemetry correlated to the change, and repair that re-enters the same memory. The Autter-specific parts describe shipped surfaces. They do not pretend every customer has already closed the full loop.

![Captain Patch standing at a harbour mouth gate inspecting an outgoing ship while identical ships sail past uninspected in the fog behind, a broken ship returning in the distance](https://autter.dev/blog/github-merge-is-not-sdlc-cover-v1.webp)

*The harbour mouth is one checkpoint. The voyage is the SDLC.*

## Three different things GitHub calls “review”

Branch protection on GitHub has two independent levers that people conflate, plus a third state that quietly defeats both.

**Required pull request reviews.** A protected branch can require *N* approving reviews. A review is an event with one of three states: `APPROVE`, `REQUEST_CHANGES`, or `COMMENT`. Only `APPROVE` counts toward the required count, and only `REQUEST_CHANGES` actively holds a merge open until dismissed. A `COMMENT` review is inert: it neither approves nor blocks.

**Required status checks.** A protected branch can require named checks to be green before merge. Each check run reports a conclusion: `success`, `failure`, `neutral`, `cancelled`, and so on. Branch protection blocks the merge only while a required check is missing or its conclusion is one of the failing values. This is the lever that actually enforces.

**The neutral conclusion.** A check that completes with `neutral` renders as a grey square, not a red X. Crucially, branch protection treats `neutral` as not failing. A required check that always concludes `neutral` will never block anything; it satisfies the “check has reported” requirement and then reports a non-failure.

> “There is exactly one way for an automated reviewer to gate a merge: publish a status check, mark it required, and be willing to conclude failure.”

So there is exactly one way for an automated reviewer to gate a merge on GitHub: it must publish a status check, that check must be marked required in branch protection, and it must be willing to conclude `failure`. A reviewer that only leaves comments has opted out of the enforcement lever entirely. A reviewer that publishes a check but only ever concludes `neutral` has wired up the lever and then disconnected it.

![Diagram of GitHub's two merge levers: required pull request reviews with Approve, Request Changes, Comment states, and required status checks with success, failure, neutral conclusions, with neutral marked as non-blocking](https://autter.dev/blog/github-merge-levers-diagram-v1.webp)

*The two levers and the neutral trap: only failure blocks, comment and neutral never do.*

## Where the surveyed tools land

With that mechanic in hand, the behavior of the common tools is unsurprising.

**GitHub Copilot code review** posts a `Comment`. According to GitHub's own documentation, Copilot's review is left as a Comment and does not count toward required approvals. It is on the first lever (reviews) but in the one state that neither approves nor requests changes. There is no setting that promotes it to a required, blocking check. This is not Copilot being weak; it is Copilot choosing the inert review state by design.

**Claude Code review** concludes `neutral`; other check-based reviewers often default the same way. They publish status checks rather than comments, which *looks* like the enforcement path. But a check that completes `neutral` is a grey square. Branch protection will not treat it as a failure. Wired up, then disconnected.

**Configurable tools** sit in the middle: they can publish a check, and some can be taught to conclude `failure` when you mark that check required. Left at a neutral default, the check exists and the gate does not. Configured to fail, they can block a merge. The difference is a design decision about conclusions and required checks, not a limit of what AI reviewers can technically do on GitHub.

**A real required check** — success and failure conclusions that branch protection can require — is the architecture that actually enforces at PR time. We have written about that distinction before: a reviewer is not a merge gate, and same-vendor review of same-vendor code is still self-certification. The rest of this essay starts where that argument usually stops.

- **COMMENT**: Copilot review state — inert, never blocks
- **neutral**: Default-neutral check — grey square, never fails
- **failure**: Required check willing to fail — the only real gate

![Comparison matrix of Copilot comment review vs neutral check vs configurable check vs required failing gate, showing which signals branch protection enforces](https://autter.dev/blog/github-reviewer-vs-gate-matrix-v1.webp)

*Not all signals are equal. Only the required failing gate stops the merge.*

## The merge gate is necessary. It is still not an SDLC.

A required, failing check answers one question: *may this pull request merge?* That is the right question for the harbour mouth. It is the wrong question for the whole voyage.

The gate only knows what it can see at PR time: the diff, the sandbox run, the policy you configured, the CI signals you already trust. Once the change is on `main` and in production, the gate has done its job. GitHub's branch protection has nothing left to say. If something still breaks under real traffic, you need a different control surface — one that can point from the live failure back to the change, the author, and the policy decision that let it through.

Three incomplete controls get sold as “safety”:

1. **Advisory PR review** — `COMMENT` or `neutral`. Feedback. Not a control.
2. **A merge gate alone** — required check that can fail. Real enforcement at merge. Blind after deploy.
3. **Runtime alerts with no provenance** — dashboards and pages with no durable link to the PR, the commit, or the agent that wrote the line. Symptoms. Not a closed loop.

> “There is no single magic checkbox called AI safety. There are stages: authorship, merge, deploy, observe, diagnose, fix, verify.”

So there is no single magic checkbox called “AI safety.” There are stages. Authorship. Merge. Deploy. Observe. Diagnose. Fix. Verify. A tool that only comments at PR time has opted out of enforcement. A tool that only blocks the merge has opted out of everything after ship. A tool that only pages on error has opted out of knowing *what shipped*.

![SDLC timeline from authorship through merge, deploy, observe, diagnose, fix, verify, showing GitHub branch protection coverage ending at merge and the blind zone after deploy](https://autter.dev/blog/github-sdlc-stages-gap-v1.webp)

*GitHub's enforcement ends at the merge. Everything after is the blind zone.*

## Why this matters more as agents write more code

The gap between advisory and enforcing is the gap between feedback and a control. The gap between a merge gate and a closed loop is the gap between “we blocked bad diffs we could see” and “we can still act when production teaches us something the diff could not.”

Integration guidance has been blunt about the first gap: verification that is recommended but not enforced in CI gets bypassed under pressure. A reviewer that can only comment is a recommendation. When most of the diffs arriving in a repository are machine-generated and the human in the loop is approving at volume, three failure modes show up together:

1. Nobody can say who actually wrote the line — `git blame` names the committer, not the agent, model, or prompt session.
2. The merge is certified by a `COMMENT`, by a check that concludes `neutral`, or by the same product line that opened the PR.
3. When production breaks, the incident is a pile of logs with no durable link back to the change that introduced the behavior.

The control-surface test

“A bot left a comment” is not a control surface. “The check didn't fail” is not the same as “the check passed.” “CI was green” is not a production memory. You need authorship before the PR, a verdict that can hold the merge, and runtime signals that still know which change they belong to.

## How Autter's loop is built

Autter is built as three shipped surfaces that share one memory, not as a comment bot with a dashboard bolted on. The PR gate is deliberate about GitHub's levers. The rest of the loop exists because those levers stop at merge.

### 1. CLI / MCP — authorship before the PR

Git records who committed. It does not record who wrote. The Autter CLI exists for that gap.

Install once (macOS, Linux, WSL, or Windows). Device-code sign-in. Machine-specific credentials you can revoke. Coding agents report what they wrote via checkpoints rather than guessing after the fact. Optional commit hooks can attach authorship notes. `autter blame` is provenance-aware: same shape as `git blame`, but the line can name the agent and session, not only the human who pressed commit.

MCP puts that same assurance surface inside the coding agent: reviews, findings, and codebase context available where the code is being written, not only after the PR opens.

This is the change layer's first fact: intent, code, and authorship, before branch protection ever runs. Without it, even a perfect gate is certifying anonymous agent sludge.

![Side-by-side of git blame showing only human committer versus autter blame showing agent, model, and session per line, Captain Scout pointing at the provenance column](https://autter.dev/blog/autter-authorship-blame-v1.webp)

*Same code. More context: autter blame names the agent, model, and session behind each line.*

### 2. Change / PR — separate the explanation from the verdict

On the pull request, Autter runs as a GitHub App: findings, agentic verification, and a merge gate you can mark required in branch protection.

The architectural rule is the same one that separates real gates from theatre: **the enforcing signal has to publish a status check, that check has to be required, and it has to be willing to conclude `failure`.** A comment thread is not that. A `neutral` check is not that. Grey squares that read as “didn't fail” are the Copilot-class mistake applied to status checks.

Autter keeps the two jobs distinct on purpose. The review carries the summary and the findings — the explanatory feedback, the part you read. The gate carries the merge decision. You mark the gate required; you can leave the advisory surface advisory. The split exists so the enforcement signal is never diluted by the volume of commentary, and so the gate is never tempted into `neutral` as a polite default.

What the assurance engine looks at is multi-dimensional: security, AI-slop patterns, blast radius, regression, migration risk, policy. None of that matters for branch protection unless the conclusion can fail.

Precision on the claim

Autter's merge gate exists in product. Whether it is armed as required for a given repo is a team decision — the same way any required check is. Enforcement is a design you turn on, not a slogan that appears because a bot spoke.

![PR screen split into advisory review thread with findings on the left and a separate red-X failing merge gate check on the right, Captain Patch standing on the gate side](https://autter.dev/blog/autter-review-vs-gate-split-v1.webp)

*Good reviews improve code. Checks keep it safe: advisory feedback separated from the required gate.*

### 3. Runtime — production still knows the change

After merge, GitHub's branch protection has finished speaking. The loop has not.

Autter's runtime path ingests OpenTelemetry-style signals (Node SDK, Next.js instrumentation, browser relay, OTLP). Incidents get a lifecycle — detected, investigating, fixing, resolved — and correlate to deployments, PRs, and commits. External sources can feed the same memory (for example PostHog, Sentry, Grafana, or generic webhooks) with explicit modes: auto-fix, investigate-only, or ingest-only.

Root-cause analysis is useful only if it can point at code. The shipped path ties telemetry back to the change layer, produces an incident fix plan, and — when qualified — can open a fix PR that re-enters review and the *same* gate instead of being a paste into Slack.

This is the part most “AI code review” products never build, because it is not a GitHub Checks UX problem. It is a memory problem: deployments, traces, logs, errors, and user impact have to sit in the same place as intent, ownership, and policy. Otherwise you have a red X at merge and a disconnected pager at 2am.

![Runtime incident timeline correlated backwards to deployment, PR, commit, and authoring agent, then forwards into a fix PR re-entering the same merge gate, circular loop diagram](https://autter.dev/blog/autter-runtime-to-fix-loop-v1.webp)

*The incident-to-fix loop: from alert to improvement, with context that sticks.*

### Assurance Memory is the spine

A shared memory connects review, runtime, and repair. In layers:

- **Change:** intent, code, ownership, dependency graph
- **Assurance engine:** security, execution, regression, migration, policy
- **Runtime signals:** deployments, traces, logs, errors, user impact
- **Repair + verification:** root cause, proposed fix, sandbox proof, controlled rollout
- **Policy + memory:** what can ship, what can auto-fix, what needs a human

Human policy stays in charge. The platform compounds because each decision and outcome can feed the next change. That is the difference between four disconnected tools and one loop — and the reason a green required check is the start of assurance, not the definition of it.

## Adopt the loop without surprises

The honest objection to any required check is that you cannot see what it will block until it blocks something, and a gate that fails your merge queue on day one is its own kind of noise. The honest objection to runtime wiring is that you do not want a new pager with no correlation.

The measured path mirrors how you should arm any GitHub gate:

1. Get authorship in place with the CLI so PRs stop arriving without provenance.
2. Run Autter on PRs with the gate *advisory* first — read findings, tune what should fail. Do not mark it required while it is still noisy.
3. Mark the gate required in branch protection only when failures match what you would actually hold. Until then you have a check that reports; you do not yet have enforcement.
4. Wire runtime ingest and deploy/PR correlation before you trust auto-fix paths.
5. Keep auto-fix qualified and policy-gated; investigate-only is a valid mode while you learn. Never let an errored or empty run look like a clean pass on the merge decision.

Public usage already shows demand for assurance before the broader loop is complete for every customer. The next proof is the one we say out loud: retention — teams repeatedly trusting Autter on production-bound changes. Horizontal company. Narrow wedge proof. Destination is the full loop, not a claim that every team has already closed it.

Lesson

Run advisory first, require when the failures match what you would actually hold, then wire runtime before auto-fix. Enforcement is a design you turn on — not a slogan.

## The short version

GitHub blocks merges on required status checks that conclude `failure`, not on review comments and not on `neutral` checks. A reviewer that posts a `Comment` (Copilot) or concludes `neutral` (any default-neutral check) has chosen, by design, a signal that branch protection will not enforce.

A real PR gate is one check run that is willing to conclude `failure`, marked required, kept separate from advisory chatter. That is necessary. It is still not an SDLC. Production will teach you things the diff could not. If your runtime alerts cannot name the PR, the commit, the authoring agent, and the policy decision that let the change through, you do not have a lifecycle control — you have a pager.

Autter is built as the loop: CLI/MCP provenance into the change, PR review plus a gate you can require, runtime telemetry correlated back to what shipped, and repair that re-enters the same memory under human policy. Feedback is not a gate. A gate is not a closed loop. The harbour only counts if the ship is inspected on the way out *and* still recognized when it comes back broken.

*Building Autter in public. We sit on the merge when policy says so, we keep authorship honest at the line, and we treat production as part of the same memory — not a separate product category. The harbour is only as honest as the last change you can still explain.*

### See Autter on your own code.

A 30-minute walkthrough with the founders. Bring a repo and watch Autter review a live pull request.

[Book a demo](https://autter.dev/contact)

## Put an assurance layer on every release.

Autter reviews every pull request before it merges, backed by humans. Connect a repo and see your first findings today.

[Get started](https://app.autter.dev/login)

## Keep reading

[Sep 8, 2026 · 7 min read How RelayCore cut AI coding spend by 33% with Autter A 38-person engineering team used Autter to connect AI costs to repositories, agents, and completed work. Six weeks later, RelayCore had cut monthly AI spend from $31,800 to $21,400 while shipping 22% more AI-assisted pull requests.](https://autter.dev/blog/relaycore-cut-ai-coding-spend-33-percent) [Oct 5, 2026 · 9 min read Claude Code, Cursor, Codex: Fast Hands, Zero Fear of Consequences The real security risks of Claude Code, Cursor, and Codex: insecure code, leaked secrets, bad packages, and prompt injection. And why a merge gate beats a polite suggestion.](https://autter.dev/blog/ai-coding-assistant-security-risks)


---

---
title: How RelayCore cut AI coding spend by 33% with Autter - Autter Blog
description: A 38-person engineering team used Autter to connect AI costs to repositories, agents, and completed work. Six weeks later, RelayCore had cut monthly AI spend from $31,800 to $21,400 while shipping 22% more AI-assisted pull requests.
url: https://autter.dev/blog/relaycore-cut-ai-coding-spend-33-percent
date: 2026-09-08
author: Team Autter
tags: Case Study, AI Cost Governance, Engineering, Agent Efficiency
reading_time: 7 min
site: Autter - Autter is the code security and assurance layer for the AI coding era: it checks every change before it merges, catches security risks, governs releases, and closes the loop from production failure to verified fix.
---

[← All posts](https://autter.dev/blog)

Sep 8, 2026

# How RelayCore cut AI coding spend by 33% with Autter

A 38-person engineering team used Autter to connect AI costs to repositories, agents, and completed work. Six weeks later, RelayCore had cut monthly AI spend from $31,800 to $21,400 while shipping 22% more AI-assisted pull requests.

Team Autter 7 min read

- Case Study
- AI Cost Governance
- Engineering
- Agent Efficiency

RelayCore builds workflow automation software for logistics companies. Its engineers use Cursor, Claude Code, and GitHub Copilot across nine production repositories.

The tools helped RelayCore increase development output. They also created an expense that engineering leaders struggled to explain.

Provider invoices showed how much the company had spent. They did not show which repositories, agents, or engineering tasks had caused that spending.

RelayCore used Autter to connect AI usage to completed software work. Autter also recommended lower-cost models and flagged agents that consumed excess tokens or tool calls.

![Autter connects provider invoices and model calls to repositories, agents, workflows, completed work, and verified savings](https://autter.dev/blog/relaycore-cost-attribution-workflow.png)

*Autter connected every model call to the engineering work and outcome behind it.*

## AI adoption created a cost attribution problem

RelayCore began with six engineers testing coding agents. Within four months, 31 engineers used them for implementation, test generation, debugging, and pull-request review.

AI spending rose from $8,600 to $31,800 per month.

The increase did not follow headcount. Some teams with similar numbers of developers showed a fourfold difference in AI spend. Two repositories accounted for 46% of the bill, but RelayCore could not explain why.

Each provider reported usage through its own dashboard. Finance could see charges by vendor and model. Engineering could inspect individual agent sessions. No shared view connected those records to a repository, task, or merged pull request.

RelayCore’s VP of Engineering needed to answer:

- Which repositories and teams consumed the budget?
- Which tasks used the most tokens and tool calls?
- Which agents repeated work or entered costly loops?
- Could smaller models complete the same tasks?
- How much had each optimization saved?
- What would the current workflow cost at three times the usage?

The team could not approve a larger AI budget without those answers.

## More model power did not guarantee a better result

RelayCore had no formal model-selection policy. Engineers chose models based on familiarity, reputation, and the defaults inside each coding tool.

Developers often selected high-capability reasoning models for routine work. Test generation, documentation updates, dependency upgrades, and small implementation tasks used the same models as architecture changes and production debugging.

The company also used agents from several vendors. One agent might search the repository five times before editing a file. Another might reopen the same files throughout a run. RelayCore paid for each repeated token and tool call, but the final pull request gave reviewers no sign of that waste.

Two tasks could produce comparable results at different costs. RelayCore had no reliable way to find those cases.

What RelayCore needed

RelayCore needed to connect AI spending to engineering outcomes and give developers evidence they could use when choosing a model.

## RelayCore connected nine repositories to Autter

RelayCore connected its production repositories, AI coding tools, model providers, and GitHub pull requests to Autter.

Autter attributed each model call to its repository, team, agent, workflow, and task. It recorded token usage, tool calls, retries, model choice, and validation results.

Engineering leaders could start with the company’s total bill and inspect the work behind it. A high-cost repository could lead them to one workflow, then to the agent sessions responsible for the increase.

RelayCore organized its dashboard around four questions:

- How much did the completed work cost?
- Did the task pass its tests and review?
- How did its cost compare with similar tasks?
- Could a lower-cost model produce the same accepted result?

Autter grouped comparable tasks by repository, task type, change size, and validation outcome. The comparison prevented RelayCore from treating a complex migration and a documentation update as equivalent work.

## A test-generation agent exposed $4,900 in annual waste

During the second week, Autter flagged a test-generation agent in RelayCore’s shipment-tracking repository.

The agent had consumed 428,000 tokens and made 73 tool calls during one run. The task cost $39.84.

The agent reopened the same four files several times. It reran an unchanged test command six times and used extended thinking for each step. The resulting tests passed, but the task cost more than the implementation it covered.

Autter found 17 comparable test-generation tasks from the same repository. Runs completed with a mid-sized coding model had a median cost of $14.73. They passed the same test suite and received the same review outcome.

![A $39.84 test-generation run used 428,000 tokens and 73 tool calls, while comparable accepted runs had a $14.73 median cost](https://autter.dev/blog/relaycore-agent-waste.png)

*The accepted result looked normal. The work behind it was 63% more expensive than the comparable median.*

Autter’s recommendation

**Use the mid-sized coding model for the first attempt.**

Comparable test-generation tasks passed the same validation checks at a median cost of $14.73, 63% below this run. Disable extended thinking for the first attempt. Escalate to the reasoning model after failed validation.

RelayCore tested the recommendation across 20 tasks.

Eighteen tasks completed without escalation. Two required the larger model after the first attempt failed validation. The change reduced the workflow’s average cost by 54%.

RelayCore then updated the agent instructions to retain file context and stop rerunning unchanged commands. Those changes removed another 18% from the workflow’s token and tool-call cost.

## Autter recommended changes before routing work

RelayCore kept developers in control of model selection.

Autter showed each recommendation beside the evidence behind it. Developers could inspect the comparison group, expected saving, validation criteria, and reason for the recommendation.

The team saw guidance such as:

- “This task does not require extended thinking.”
- “A smaller model completed 14 comparable tasks with the same validation outcome.”
- “This agent used 42% more tool calls than the repository median.”
- “The agent reopened files already present in its context.”
- “Use separate models for implementation and independent review.”

Developers could accept, dismiss, or test each recommendation. Autter recorded the result.

That feedback improved later recommendations. If a smaller model failed a class of migration tasks, Autter excluded those tasks from future savings estimates. If the model completed routine dependency updates without escalation, Autter added that evidence to the comparison set.

RelayCore kept high-capability models for architecture work, complex debugging, and independent review. Routine implementation and test generation moved to smaller models when completed runs supported the choice.

## Results after six weeks

- **$31.8k → $21.4k**: Monthly AI spend (−33%)
- **+22%**: AI-assisted pull requests
- **$18.70 → $12.40**: Median cost per merged PR
- **54 → 38**: Tool calls per completed task

![RelayCore monthly AI spend fell 33 percent from $31,800 to $21,400 while AI-assisted pull requests increased 22 percent](https://autter.dev/blog/relaycore-six-week-results.png)

*RelayCore reduced spend without reducing access to coding agents.*

### Monthly AI spend fell from $31,800 to $21,400

RelayCore cut monthly AI spending by 33%.

The team did not reduce access to coding agents. During the same period, engineers merged 22% more AI-assisted pull requests.

### Cost per AI-assisted pull request fell by 34%

Median AI cost per merged pull request fell from $18.70 to $12.40.

RelayCore measured completed and merged work rather than agent sessions alone. Failed tasks and abandoned runs remained visible as waste, but they did not inflate the count of successful outcomes.

### Tool calls per completed task fell by 30%

The median number of tool calls per successful task fell from 54 to 38.

Engineers revised prompts for agents that repeated searches, reopened files, or reran unchanged checks. Autter flagged new regressions when tool-call counts moved outside the workflow’s normal range.

### 68% of eligible tasks moved to smaller models

RelayCore moved 68% of routine implementation and test-generation tasks to lower-cost models.

Ninety-one percent completed without escalation. The remaining tasks moved to a higher-capability model after a failed check.

## The savings dashboard separated evidence from estimates

Autter reported $10,400 in verified monthly savings.

Accepted model-selection recommendations accounted for $8,960. Reduced tool calls and repeated context accounted for another $1,440.

Each saving included:

- The original model and observed cost
- The replacement model and observed cost
- The completed task type
- The validation and review outcome
- The number of comparable runs
- The model prices used in the calculation

Autter excluded dismissed recommendations and failed replacement runs from verified savings. It also excluded price estimates that lacked a completed comparison task.

The dashboard displayed projections in a separate section.

At three times the current task volume, RelayCore’s old usage pattern would have cost an estimated $95,400 per month. The optimized pattern projected a cost of $64,200.

The $31,200 difference remained a forecast. Autter showed the volume assumption, current cost per task, escalation rate, and model prices beside the estimate.

![Verified monthly savings of $10,400 are separated from a projected $31,200 monthly difference at three times task volume](https://autter.dev/blog/relaycore-savings-evidence.png)

*Observed savings and volume-based projections stayed in separate evidence lanes.*

Finance could inspect the calculation instead of accepting a savings claim without its assumptions.

## Repository-level costs changed planning conversations

Before Autter, RelayCore assigned AI spending to a central engineering budget. Product teams had no view of the costs their work created.

Autter showed cost per repository and workflow.

The shipment-tracking team spent more on test generation. The integrations team spent more on debugging because its agents called external tools. The platform team used expensive models less often, but its architecture tasks had the highest cost per run.

Engineering leaders could judge each expense against the work involved. They stopped comparing teams through total token counts alone.

The repository view also helped RelayCore forecast new projects. A team planning a large integration could use observed costs from comparable work instead of applying a company-wide average.

## Engineers began selecting models by task

RelayCore added model guidance to its engineering playbook.

Developers now start routine implementation with the lowest-cost model that has completed comparable work. Failed validation triggers escalation. Architecture decisions and independent review use separate models when the risk warrants the additional cost.

Autter monitors the results and updates the evidence behind each recommendation.

The policy gives RelayCore a path to control AI spending as usage grows. Engineers retain access to capable models. Finance receives forecasts tied to observed work. Product leaders can see how AI costs change as a feature moves from experiment to production.

## RelayCore’s stack

| Area | Detail |
| --- | --- |
| Engineering team | 38 engineers |
| Production repositories | 9 |
| Source control | GitHub |
| AI coding tools | Cursor, Claude Code, GitHub Copilot |
| Model providers | Anthropic and OpenAI |
| CI/CD | GitHub Actions |
| Autter | Cost attribution, model guidance, agent-efficiency analysis, and production forecasting |

AI coding costs become harder to govern as more developers and agents enter the software lifecycle. Autter connects that spending to the engineering work that produced it and gives teams evidence for reducing it.

**Autter helps enterprises govern and reduce the cost of AI-generated software.**

See what AI-generated software costs your organization

Bring one month of AI usage and a production repository. Autter will map spending to your teams and workflows, identify high-cost tasks, and estimate the savings available from model and agent changes.

[Book a demo with the Autter team.](https://autter.dev/contact)

### See Autter on your own code.

A 30-minute walkthrough with the founders. Bring a repo and watch Autter review a live pull request.

[Book a demo](https://autter.dev/contact)

## Put an assurance layer on every release.

Autter reviews every pull request before it merges, backed by humans. Connect a repo and see your first findings today.

[Get started](https://app.autter.dev/login)

## Keep reading

[Sep 4, 2026 · 6 min read How Northstar cut PR review time by 62% with Autter A 24-person team was generating code faster than it could review it. Autter put a merge gate between each PR and main — median review time fell from 4.2 hours to 1.6 hours.](https://autter.dev/blog/northstar-cut-pr-review-time-62-percent) [Sep 12, 2026 · 11 min read GitHub Refusing Merge Is Not an SDLC Why GitHub's real merge levers still stop at the PR — and how Autter extends enforcement from authorship through runtime and repair.](https://autter.dev/blog/github-refusing-merge-is-not-an-sdlc)


---

---
title: How Northstar cut PR review time by 62% with Autter - Autter Blog
description: A 24-person team was generating code faster than it could review it. Autter put a merge gate between each PR and main — median review time fell from 4.2 hours to 1.6 hours.
url: https://autter.dev/blog/northstar-cut-pr-review-time-62-percent
date: 2026-09-04
author: Team Autter
tags: Case Study, Code Review, AI Safety, Engineering
reading_time: 6 min
site: Autter - Autter is the code security and assurance layer for the AI coding era: it checks every change before it merges, catches security risks, governs releases, and closes the loop from production failure to verified fix.
---

[← All posts](https://autter.dev/blog)

Sep 4, 2026

# How Northstar cut PR review time by 62% with Autter

A 24-person team was generating code faster than it could review it. Autter put a merge gate between each PR and main — median review time fell from 4.2 hours to 1.6 hours.

Team Autter 6 min read

- Case Study
- Code Review
- AI Safety
- Engineering

Northstar is a 24-person engineering team building a B2B SaaS product. Its engineers use Cursor, Claude Code, and GitHub Copilot to produce code at a higher rate. The team could not review incoming work at the same rate.

![From generated code to a merge decision: an AI-written diff is evaluated against the application graph for blast radius, test evidence, and runtime risk before a merge or block verdict](https://autter.dev/blog/northstar-merge-decision-workflow.png)

*Autter turns a diff into codebase-aware evidence before anything reaches main.*

## Faster coding filled the review queue

Northstar's original process looked familiar. An engineer opened a pull request, a teammate who knew the relevant system reviewed it, and CI checked the code before merge.

AI coding tools increased the size and number of pull requests. An agent could produce a substantial implementation in minutes, but a reviewer still had to trace the change through the codebase and judge whether it was safe.

Each review required engineers to identify:

- The behavior changed by the PR
- Other parts of the product that depend on the code
- Test coverage for the paths that carry risk
- Gaps in the evidence required for a merge

A PR could take 20 minutes to produce, then wait hours for a senior engineer to build enough context to review it. After three weeks of measurement, Northstar recorded a median review time of 4.2 hours.

## More comments gave reviewers more work

Northstar had CI, tests, linting, and static analysis. The team tried AI review tools that flagged edge cases, naming choices, possible failure modes, and opportunities to simplify code.

Reviewers used some findings and discarded many others that had no bearing on the merge decision. After seeing repeated low-value findings, the team began to skim the output.

What Northstar needed

Northstar needed a clear merge gate. The team asked Autter to decide whether each PR had enough evidence to proceed.

## Northstar put Autter between each PR and main

The team connected six production repositories to Autter. For each pull request, Autter analyzed the changed lines in the context of the codebase. It traced dependencies, identified affected behavior, checked test evidence, and flagged unresolved risk.

Northstar used the result to route review work. Engineers could move low-risk changes through the queue. Autter blocked changes with unresolved risk before they reached main, which let senior engineers focus on the PRs that needed their judgment.

![Review attention follows unresolved risk: every pull request is evaluated for changed behavior, downstream impact, test evidence, and unresolved risk, then routed to proceed or senior review](https://autter.dev/blog/northstar-review-routing.png)

*Every pull request is evaluated against codebase context before it enters the review queue.*

## A subscription refactor showed the value of codebase context

A few weeks after rollout, an engineer used a coding agent to refactor the subscription upgrade flow. The diff looked routine, and the existing tests passed.

Autter blocked the merge because the refactor bypassed a fallback for customers without a stored payment method. Most customers would miss the bug, but affected customers could no longer complete the upgrade flow. The standard test suite did not cover that path.

No single line exposed the risk. Autter found it by tracing the relationship between the new flow and existing behavior elsewhere in the system.

![The risk was outside the diff: the edited subscription upgrade flow passed its tests but disconnected a no-card fallback elsewhere in the application, which Autter blocked](https://autter.dev/blog/northstar-risk-outside-diff.png)

*The edited upgrade flow passed its tests but disconnected a fallback elsewhere in the application.*

The engineer restored the fallback, reran the checks, and shipped the PR later that day.

## Results after three weeks

- **4.2h → 1.6h**: Median review time (−62%)
- **3.2×**: AI-assisted PR volume
- **−41%**: Review noise

![Median PR review time fell by 62 percent, from 4.2 hours before Autter to 1.6 hours with Autter](https://autter.dev/blog/northstar-review-time-62-percent.png)

*Reviewers spent less time reconstructing context before deciding where to focus.*

### Median review time fell from 4.2 hours to 1.6 hours

Northstar cut median review time by 62%. Reviewers spent less time reconstructing codebase context before deciding where to focus.

### AI-assisted PR volume grew 3.2 times

Before the rollout, engineers kept agent-written work small because large changes took too long to validate. With the merge gate, the team had a consistent check between generated code and main. Engineers began using coding agents for larger pieces of production work.

### Review noise fell by 41%

Autter surfaced fewer findings than the team's previous review tools. Each finding connected to the merge decision, which reduced the number of low-value comments engineers had to process.

![More AI-assisted work with fewer low-value findings: AI-assisted PR volume grew to 3.2 times baseline while review noise fell 41 percent](https://autter.dev/blog/northstar-ai-volume-review-noise.png)

*Both panels use Northstar's pre-Autter period as an indexed baseline of 1.0× or 100%.*

### Senior engineers reviewed the changes that needed them

Northstar had routed most risky-looking pull requests to senior engineers. Autter helped the team separate routine changes from changes with unresolved risk. Senior engineers could spend their review time on architecture, product behavior, and failure modes that required experience.

## Faster implementation shifted the constraint to review

Engineers used AI coding agents to cut the time and effort required to produce code. They still had to decide whether that code was safe to ship.

Northstar used Autter to build its review process around that decision. Autter checked each change against the codebase, surfaced risks that could affect production, and stopped unsupported changes before merge.

## Northstar's stack

| Area | Detail |
| --- | --- |
| Engineering team | 24 engineers |
| Repositories | 6 production repositories |
| Source control | GitHub |
| AI coding tools | Cursor, Claude Code, GitHub Copilot |
| CI/CD | GitHub Actions |
| Autter | Code review, codebase analysis, and merge gates |

AI can produce code in minutes. Autter helps engineering teams decide whether to ship it.

Learn more at [autter.dev](https://autter.dev).

### See Autter on your own code.

A 30-minute walkthrough with the founders. Bring a repo and watch Autter review a live pull request.

[Book a demo](https://autter.dev/contact)

## Put an assurance layer on every release.

Autter reviews every pull request before it merges, backed by humans. Connect a repo and see your first findings today.

[Get started](https://app.autter.dev/login)

## Keep reading

[Aug 30, 2026 · 10 min read Copilot Can Review Copilot. That Is Not a Second Reviewer. GitHub now lets Copilot code review cover Copilot-authored PRs. Covering bot PRs was the right product move. Same-vendor review is still the author certifying the merge.](https://autter.dev/blog/copilot-can-review-copilot-that-is-not-a-second-reviewer) [Sep 8, 2026 · 7 min read How RelayCore cut AI coding spend by 33% with Autter A 38-person engineering team used Autter to connect AI costs to repositories, agents, and completed work. Six weeks later, RelayCore had cut monthly AI spend from $31,800 to $21,400 while shipping 22% more AI-assisted pull requests.](https://autter.dev/blog/relaycore-cut-ai-coding-spend-33-percent)


---

---
title: Copilot Can Review Copilot. That Is Not a Second Reviewer. - Autter Blog
description: GitHub now lets Copilot code review cover Copilot-authored PRs. Covering bot PRs was the right product move. Same-vendor review is still the author certifying the merge.
url: https://autter.dev/blog/copilot-can-review-copilot-that-is-not-a-second-reviewer
date: 2026-08-30
author: Sagnik
tags: Opinion, Code Review, AI, Merge Gate
reading_time: 10 min
site: Autter - Autter is the code security and assurance layer for the AI coding era: it checks every change before it merges, catches security risks, governs releases, and closes the loop from production failure to verified fix.
---

[← All posts](https://autter.dev/blog)

Aug 30, 2026

# Copilot Can Review Copilot. That Is Not a Second Reviewer.

GitHub now lets Copilot code review cover Copilot-authored PRs. Covering bot PRs was the right product move. Same-vendor review is still the author certifying the merge.

Sagnik, Founder, Autter 10 min read

- Opinion
- Code Review
- AI
- Merge Gate

GitHub closed a coverage gap on bot PRs and opened a governance one. Copilot can now review Copilot. That is not a second reviewer.

On 27 August 2026, GitHub shipped a changelog that reads like hygiene and is actually a governance decision.

Copilot code review can now review pull requests authored by bots, including Copilot cloud agent, when the review is auto-requested. Cloud agent PRs used to fall back to a limited experience. They now get a full agentic review. The old size cap (300 files or 20,000 lines) is gone. And when you resolve a Copilot review comment, you can pick a reason: Addressed, Won't fix, or Incorrect.

I read that twice.

The first read is: good. Agents open pull requests now. Those PRs should not skip review because the author is a bot and there is no licensed human to pin the bill to. GitHub even wired org billing, under the “Allow members without a Copilot license to use Copilot code review” policy, so the review can run and the organization pays. That is the correct product instinct.

The second read is the one that matters. Copilot can now open the PR. Copilot can now give it a full review. A human can dismiss the comments with a dropdown. Nothing in that loop has to sit on the merge button.

GitHub closed a coverage gap. They opened a governance one.

> “Bot PRs should get reviewed. Same-vendor review is still the author certifying the merge.”

## What shipped, and why the coverage fix is right

Three product changes, one billing change, one comment UX change. I want to be precise about all of them, because the rest of this essay only works if we do not invent extra sins.

Bot-authored pull requests can now be reviewed by Copilot code review when the review is requested automatically. Previously there was no Copilot-licensed account to attribute that review to, so the auto-request path did not cover the PR. With the unlicensed-member policy on, usage bills to the organization.

Copilot cloud agent pull requests are the sharp version of that. Auto-requested review used to degrade into a limited experience. It now gets the full agentic review.

The size cap is gone. A 400-file agent dump, or a 30,000-line refactor, can be reviewed. That used to be an implicit skip. It is not anymore.

Resolution reasons sit next to “Resolve conversation.” Addressed. Won't fix. Incorrect. GitHub says the selection gives the product team feedback.

I am going to say this without hedging: covering bot PRs was the right move. Unreviewed bot PRs were a hole. Very large PRs skipping review were a hole. GitHub found both and filled them. Credit where it is due. The product team did the coverage work.

The remaining question is not “should this PR be reviewed.” It is who is allowed to certify that it can merge, and what that certification is actually allowed to do.

## Agents opening PRs is now the normal path

A year ago, a bot-authored pull request was a special case. Dependabot. A Renovate bump. A codegen job somebody wired up on a Friday and forgot about. You could argue, badly, that those PRs were small and mechanical, and that a human would look before merge.

That argument is dead.

Copilot cloud agent opens PRs as part of the product. So do Cursor agents, Claude Code, Codex, and the internal bots every reasonably large engineering org has already stood up. The author field on a growing share of diffs is not a person. It is a service account with a mandate to ship.

If your review policy is “auto-request Copilot on every PR” and then bot PRs silently fall out of that policy, you have a hole shaped exactly like your new authoring path. The PRs most in need of a second look—the ones no human sat with while they were written—are the ones that skip the review you thought you turned on.

GitHub is right about that. A review product that cannot see bot PRs is a review product for a 2024 workflow. The limited fallback on cloud agent PRs was worse than a clean skip, because it looked like coverage. A limited review is how a team learns to trust a check that was never doing the job.

The size cap belonged to the same era. Human PRs rarely hit 300 files. Agent PRs do. If the tool stops at the exact volume where an agent is most likely to dump a tree, you have not built a review for agentic work. You have built a review for the PRs that were already easiest to read.

So yes. Cover the bots. Cover the large diffs. Bill the org if that is what it takes to make the auto-request path real. I will not pretend this was a cynical feature. It was a hole, and they closed it.

Lesson

Unreviewed bot PRs were a real gap. Filling that gap with the same vendor that opened the PR is a different decision, and it should be named as one.

## Same-vendor review is still self-certification

This is the part I need to be careful about, because the lazy version of the argument is wrong.

I am not claiming that Copilot generation and Copilot code review use identical models. I do not know that, and GitHub has not said that. The cloud agent and the reviewer may well be different systems, with different prompts, different tools, different loops. “Full agentic review” even implies the reviewer is doing more than a second pass of the same completion engine.

That is not the point.

The point is who owns both sides of the merge, what they are paid to optimize, and what the review is allowed to do when it disagrees with the author.

Copilot cloud agent is a GitHub product. Copilot code review is a GitHub product. They live in the same billing family, the same policy surface, the same changelog, the same staff meeting where someone asks whether review is slowing agent adoption. When the author is Copilot and the reviewer is Copilot, the merge is being certified inside one product line.

I wrote about the incentive version of this in May, in [AI Reviewing Its Own Code Is a Conflict of Interest](https://autter.dev/blog/ai-reviewing-its-own-code-is-a-conflict-of-interest), before Copilot review was allowed to sit on Copilot-authored PRs. What changed this week is not the argument. What changed is that GitHub productized the loop.

A second reviewer is supposed to be able to cost the author something. Time. A change. A blocked merge. A reviewer owned by the same vendor as the author is structurally discouraged from costing that vendor's agent its win. Every blocked Copilot PR is a story that the agent didn't work. Every dismissed comment is a story that the agent just needed a nudge. Guess which story the product org would rather tell at the next launch.

This is not a claim about malice. GitHub is not a cartoon villain. It is a claim about incentives. Generation products live on accepted work. Review products that live inside generation products are graded, quietly, on whether they slow that acceptance down. The gradient runs one way. Toward comments. Toward reasons. Toward a review that can always be resolved.

You can put two different models on either side of that gradient and still not have independence. Independence is not a sampling of weights. Independence is a reviewer who does not lose if the author looks bad.

Watch the merge button, not the comment thread.

A Copilot review comment is a suggestion. Resolving it is a conversation action. The new reasons make that conversation tidier. They do not change the authority of the comment. Addressed, Won't fix, and Incorrect are all a click on a dropdown. One of those clicks even sends GitHub's product team a training signal.

None of those states is “this PR cannot merge.”

If your branch protection does not require a blocking check from someone other than the authoring product, the Copilot review can be thorough, agentic, billed to the org, and still be theatre. The bot opens. The bot's sibling reviews. A person—or another bot—marks the comments Incorrect. Merge. The audit trail says there was a review. The harbour says the ship was cleared by the shipyard that built it.

> “Resolution reasons are comment UX. They are not a gate.”

GitHub is explicit about what the reasons are for. Feedback to the product team. That is a fine thing to want if you are improving a commenter. It is an odd thing to want if you believe the commenter is the review of record. A merge gate does not ask the author to rate the finding so the vendor can tune the product. A merge gate asks whether the change is allowed to ship.

The size cap coming off makes this sharper, not softer. The PRs that most need a real second look are now eligible for a same-vendor full review. Coverage went up. Independence did not.

## What independent has to mean now

“Independent” has gotten sloppy. People use it to mean a different prompt, or a different model, or “we asked the same vendor twice.” After this changelog, that usage should retire.

Independent means three things, and all three have to be true at the same time.

**The reviewer has to run the change, not just read it.** Sandbox execution. Clone the PR, install what it claims to need, run the suite against the base branch, watch what actually happens. A full agentic review that never leaves the diff is still a reading of the manifest. Plenty of bad cargo looks fine on paper. The whole class of bugs that show up only when the code runs will not be caught by a reviewer that does not run the code.

**The reviewer has to resolve dependencies against a real registry.** Agents invent packages with complete confidence. A commenter that pattern-matches import names will bless a hallucinated library because the name looks like a library. A gate that talks to npm, PyPI, crates.io, or Maven Central will not. Phantom cargo is not a style nit. It is a supply-chain hole with a plausible README.

**The reviewer has to return a verdict that can hold the merge.** Pass, warn, or block. Not a comment. Not a reason code. A status check a ruleset can require, with an override path that is explicit, logged, and owned by a human. If the finding cannot stop the merge, it is advice. Advice is what gets scrolled past at 4:47pm on a Friday.

![A three-stage harbour inspection shows Captain Patch running a mechanism in a sandbox, checking cargo against a registry, and operating a pass-warn-block merge gate.](https://autter.dev/blog/independent-merge-gate-v1.webp)

*Independence means execution, real registry checks, and a verdict that can hold the gate.*

Those three are the job. A better comment is not the job. A fuller agentic pass from the same product line as the author is not the job. Org-billed auto-review of bot PRs is coverage of the comment job. It is not the gate.

I want to be honest about the pushback, because it is the one I would make if I worked on Copilot.

“We added a review where there was none. That is strictly better. You are complaining that the reviewer is ours.”

Yes. Adding a review where there was none is strictly better than silence. I already said that. The mistake is treating “strictly better than silence” as the same thing as “sufficient to merge.” A same-vendor commenter on a bot PR is better than an unreviewed bot PR. It is not a second reviewer. It is the authoring product checking its homework in public.

“The reviewer is agentic now. It is not a rubber stamp.”

Agentic means it can use tools. It does not mean it is allowed to cost the parent product a merge. If the output is still a comment you can mark Incorrect, the agency is in service of a suggestion. Suggestions do not govern.

“Teams can wire Copilot review into a required check themselves.”

They can. They could last year. The changelog did not ship that. It shipped broader comments, broader billing, and a dropdown. If enforcement were the point, the heading would have been about branch protection, not resolution reasons.

Lesson

Coverage answers “did anything look at this PR.” Governance answers “could anything have stopped it.” After this week, Copilot can answer the first for its own PRs. It still does not answer the second.

## Audit one PR

Do not take any of this as a slogan. Take it as a procedure.

Pick one pull request from this week. Preferably one opened by a bot or an agent, but a human PR will do if that is what you have.

Look at the author. Is it a person, Copilot cloud agent, Dependabot, an internal bot, something else?

Look at the reviewers. Which of them are the same vendor as the author? Which of them are humans who actually read the diff? Which of them posted comments that were resolved without a corresponding change?

Look at the merge. What was required? A passing CI job you wrote? A Copilot review that can be dismissed with Won't fix? A status check that can block? Anything that would have held the button if the finding was real?

If the author is Copilot and the review is Copilot and the merge is green because someone resolved comments, you do not have two reviewers. You have one product line, talking to itself, with a human as the notary.

That is the whole essay, in one pull request.

Building Autter in public. We do not write your code, we do not sell you a coding agent, and we do not get paid more when more diffs ship. We run the change in a sandbox, we check the cargo against real registries, and we sit on the merge until the verdict is pass. Before you take my word for any of that, go audit the PR. The harbour is only as honest as the last ship you actually inspected.

*P.S. Tanvi read this and said I should lead with “GitHub did the right thing” so nobody thinks we needed Copilot to be wrong in order to be right. She also said if the CTA is “audit one PR” I am not allowed to bury a demo link under it. I cut the demo link. She is, as usual, insufferably correct.*

### See Autter on your own code.

A 30-minute walkthrough with the founders. Bring a repo and watch Autter review a live pull request.

[Book a demo](https://autter.dev/contact)

## Put an assurance layer on every release.

Autter reviews every pull request before it merges, backed by humans. Connect a repo and see your first findings today.

[Get started](https://app.autter.dev/login)

## Keep reading

[Aug 21, 2026 · 9 min read Your PR Is Green. Should You Still Be Nervous? Tests are green, the code compiles, and the PR looks harmless. Learn what code review must catch beyond CI and why reviewing a diff is only the beginning.](https://autter.dev/blog/merge-room-episode-1-your-pr-is-green) [Sep 4, 2026 · 6 min read How Northstar cut PR review time by 62% with Autter A 24-person team was generating code faster than it could review it. Autter put a merge gate between each PR and main — median review time fell from 4.2 hours to 1.6 hours.](https://autter.dev/blog/northstar-cut-pr-review-time-62-percent)


---

---
title: Your PR Is Green. Should You Still Be Nervous? - Autter Blog
description: Tests are green, the code compiles, and the PR looks harmless. Learn what code review must catch beyond CI and why reviewing a diff is only the beginning.
url: https://autter.dev/blog/merge-room-episode-1-your-pr-is-green
date: 2026-08-21
author: Autter Team
tags: The Merge Room, Code Review, Engineering
reading_time: 9 min
site: Autter - Autter is the code security and assurance layer for the AI coding era: it checks every change before it merges, catches security risks, governs releases, and closes the loop from production failure to verified fix.
---

[← All posts](https://autter.dev/blog)

Aug 21, 2026

The Merge Room · Episode 01 / What code review is actually for

# Your PR Is Green. Should You Still Be Nervous?

Tests are green, the code compiles, and the PR looks harmless. Learn what code review must catch beyond CI and why reviewing a diff is only the beginning.

Autter Team 9 min read

- The Merge Room
- Code Review
- Engineering

Key takeaway

A green pull request tells you that the checks you wrote have passed. It does not tell you that the change is correct for every caller, safe under real traffic, consistent with the system’s rules, or harmless downstream. Good code review tests the assumptions around the code, not just the lines in the diff.

## What you’ll learn

- What CI can prove and what it cannot
- The four questions a useful code review should answer
- Why tiny changes can have large consequences
- How codebase context changes a review
- A practical checklist for your next pull request

## The PR that behaved perfectly

Imagine this pull request lands in your queue on a Friday afternoon. It is short enough to scan before your coffee goes cold, and it looks like the author has added a sensible safety check.

```
export async function chargeOrder(orderId: string) {  const order = await getOrder(orderId);  if (order.status !== "paid") {    await paymentProvider.charge(order.total);    await markOrderPaid(order.id);  }}
```

*TypeScript*

The guard stops an order that is already marked as paid from being charged again. Sensible. The code compiles, the unit tests pass, and the linter has no complaints. CI produces the reassuring green tick developers have been trained to love. Would you merge it? Take a moment. This is not a trick question. It is a trap question, which is a close relative with worse incident reports.

Two requests can read the same unpaid order at almost the same time. Both pass the guard. Both charge the customer. Only afterward do they mark the order as paid.

![Captain Patch tracing two concurrent requests that both pass a green gate before colliding at the same payment card](https://autter.dev/blog/merge-room-race-condition-v1.jpg)

*Two requests. Two green checks. One customer charged twice.*

> “Every individual line looks reasonable. The failure lives in the space between two executions.”

That space is where code review begins. The syntax is fine, but the behaviour breaks as soon as the system does two perfectly normal things at once.

## Green means “the checks passed”

Teams often treat a green build as a verdict. It is closer to a receipt. CI can tell you that a known set of commands completed successfully: tests passed, types checked, dependencies scanned, formatting matched, and perhaps an image built. That is valuable. It is also bounded by what those checks know how to ask.

If nobody wrote a concurrent-payment test, the test suite cannot feel a disturbance in the force and invent one. It will pass the test it was given and stay completely silent about the question nobody asked.

That is why a green result has a much narrower meaning than we often give it. It does not automatically prove any of the following:

- the requirement was understood correctly;
- the code behaves safely under concurrency;
- every downstream caller still works;
- authorization is enforced at the right boundary;
- an existing helper was not reimplemented inconsistently;
- logs avoid sensitive data;
- the change follows architectural decisions made elsewhere;
- the feature will behave well in production.

This is not a criticism of CI. A smoke detector is useful even though it does not detect burglary. Problems begin when we ask one control to answer every question.

## What code review is actually for

A useful review answers four questions. They move the conversation away from whether the diff looks tidy and toward whether the change can survive the real system around it.

### 1. Does the change do what we intended?

Start with behaviour, not formatting. What user or system outcome is supposed to change? Which outcome must remain unchanged? What assumptions did the author make about data, ordering, permissions, and failure?

In our payment example, the intent is “charge an unpaid order once.” The implementation currently means “charge an order if this particular request observed it as unpaid.” Those sentences sound similar until two requests arrive together.

> An order may be charged at most once.

Once the invariant is explicit, the missing atomicity becomes much easier to see. You now have something concrete to review instead of a vague sense that the code looks reasonable.

### 2. What can this change affect?

A diff shows what changed. It does not show everything that depends on what changed. Perhaps`chargeOrder` is called by the checkout endpoint, a webhook retry handler, an admin recovery tool, and a nightly reconciliation job. Perhaps one caller already retries automatically. Perhaps another assumes the function is idempotent. That is the difference between reviewing a line and reviewing its blast radius.

- Who calls this?
- What does this call?
- Which routes, jobs, or services can reach it?
- Which tests cover those paths?
- What changed since the surrounding design was introduced?

Without those answers, reviewers guess. Experienced reviewers often guess well. They also take holidays.

![Captain Patch mapping one changed function to routes, retries, jobs, tools, tests, and a database](https://autter.dev/blog/merge-room-blast-radius-v1.jpg)

*The diff is the starting point. The affected system is the review surface.*

### 3. How can it fail in the real system?

Production adds ingredients that unit tests politely leave outside: concurrency, partial failure, retries, stale data, network timeouts, malformed inputs, unexpected permissions, and users with astonishing creativity. For the payment change, that means asking about the whole journey around the function, not only whether the condition reads correctly:

- What if the provider succeeds but `markOrderPaid` fails?
- What retries this function?
- Does the provider support an idempotency key?
- Can two workers process the same order?
- Is the state transition atomic?
- What evidence would let us reconcile an uncertain result?

Notice how little of this is visible in the syntax. The dangerous part is not a malformed`if`. It is the lifecycle around it.

### 4. Will the next developer understand and maintain it?

Correctness today is not the only concern. Review should also protect tomorrow’s changes.

Is the invariant represented clearly? Is the state transition owned by the right layer? Is failure visible? Is the behavior tested at the boundary where it matters? Does this duplicate an existing mechanism?

Maintainability comments are useful when they reduce future risk. “Rename this because I personally prefer another noun” belongs in the Nitpick Bin unless the name creates genuine ambiguity.

## The three review layers

It helps to think of review as three layers rather than one giant activity. Each layer is good at a different kind of question, and the review gets weaker when one tries to do all the work.

| Layer | Best at finding | Typical examples |
| --- | --- | --- |
| Automated checks | Known, repeatable violations | Type errors, formatting, vulnerable dependencies, known security patterns |
| Contextual analysis | Relationships and affected paths | Downstream callers, duplicated logic, missing coverage, architectural drift |
| Human judgment | Intent, tradeoffs, and organizational context | Product behavior, acceptable risk, design clarity, rollout decisions |

The goal is not to replace one layer with another. It is to stop making senior engineers spend attention on work a machine can repeat, while machines surface the context humans need for judgment.

Together, those layers produce a better review conversation. The machine carries the repeatable work and brings the relevant context to the person making the decision.

Low-value comment

Could you rename `result` to `paymentResult`?

Useful comment

This path can be entered by both the checkout request and the webhook retry. Can two workers charge the same order before either writes the new status? We may need a provider idempotency key plus an atomic state transition.

One comment rearranges letters. The other may prevent a very awkward customer email. That is a useful test for whether a review note is protecting the system or only polishing the diff.

## The Autter lens: from changed lines to affected systems

Autter builds an application graph from a repository: files, symbols, imports, call relationships, API routes, data models, tests, and reverse dependencies. When a PR changes a function, the useful question is not merely “is this function valid?” It is “where can this function’s behavior travel?”

For the simplified payment example, a contextual review could surface the five facts below. None of them is obvious from the changed lines alone.

1. `chargeOrder` is reachable from two independently retried entry points.
2. Both paths can operate on the same order.
3. The payment provider call occurs before the local state transition.
4. No concurrency test covers the invariant.
5. A related refund flow already uses provider idempotency keys.

Now the reviewer is not searching the repository from scratch. The relevant map is already on the table. This does not make the merge decision automatically. It makes the decision informed.

## A safer shape for the example

The exact fix depends on the database and payment provider, but the design usually needs two protections that work together. One stops the provider from processing the same payment twice, and the other stops two workers from claiming the same order:

- a stable idempotency key understood by the provider;
- an atomic local transition that prevents two workers from claiming the same charge.

```
export async function chargeOrder(orderId: string) {  const claimed = await claimOrderForPayment(orderId);  if (!claimed) return;  await paymentProvider.charge({    amount: claimed.total,    idempotencyKey: `order:${claimed.id}`,  });  await markOrderPaid(claimed.id);}
```

*TypeScript*

This snippet still does not solve every failure mode. For example, the system needs a recovery plan if the provider succeeds and the final database update fails. That is the point: serious review follows the behavior through the whole lifecycle rather than declaring victory at the closing brace.

## Merge or block?

You are reviewing a PR that changes a shared authorization helper. Its unit tests pass. The diff updates six lines. The helper is used by 47 endpoints, but only two endpoint tests ran because the test selector is based on changed files. The diff looks small, but the reach is not. What do you do?

1. Merge. The helper’s own tests passed.
2. Request a variable rename, then merge. Clean names prevent incidents.
3. Block until the affected authorization paths and test selection are understood.
4. Close the laptop and develop an interest in pottery.

The best answer is **C**, although D remains emotionally available. The six changed lines are not the thing that should decide how deeply you review this PR.

The risk is not proportional to the number of changed lines. A six-line edit to a high-reachability helper can matter more than a 600-line isolated feature. Review depth should follow impact, not diff size.

## What to take into your next PR

1. **Intent:** What invariant or user outcome must this code preserve?
2. **Reach:** Which callers, routes, jobs, services, and data flows can this affect?
3. **Failure:** What happens under retries, concurrency, partial failure, and malformed input?
4. **Evidence:** Which checks prove the important behavior, not merely the happy path?
5. **Clarity:** Will the next developer understand why this design exists?

If the answer to one of these is “I assume…,” you have found the next review question. That small pause is often the difference between approving the code you can see and reviewing the system that will actually run it.

The Merge Room · knowledge check

## Would you approve the merge?

Answer all three. Once you commit your answers, we’ll explain each call and unlock the Autter merch draw. Your score does not affect your chance of being selected.

**What does a green CI result prove?**

The change is safe in production Every downstream caller still works The configured checks completed successfully A senior engineer no longer needs to review the PR

**Why can a tiny diff deserve a deep review?**

Short code is usually suspicious Diff size does not reveal downstream reach Linters are less reliable on small files Review tools charge by the line

**Which comment creates the most review value?**

Please alphabetize these imports. I would have written this with a ternary. Both retrying entry points can call this before the state update. What prevents a duplicate charge? Can we rename data?

0 of 3 answered

Commit answers

Next in The Merge Room

Episode 02

## The diff is not the crime scene

We’ll follow one harmless-looking change through callers, dependencies, and tests to see why code review needs a map of the application. The diff shows us where to start, but it does not show us where the behaviour can travel.

[See what a pull request touches beyond its changed lines →](https://autter.dev/contact)

### Inside The Merge Room

Answer the knowledge check to unlock this episode’s Autter merch draw. Your score is for learning, not eligibility.

Take the knowledge check

## Put an assurance layer on every release.

Autter reviews every pull request before it merges, backed by humans. Connect a repo and see your first findings today.

[Get started](https://app.autter.dev/login)

## Keep reading

[Jul 28, 2026 · 15 min read Autter vs Claude Code Review: Should the AI That Writes Your Code Also Review It? Autter is the stronger first choice for teams that need risk-based verification, enforceable merge gates and predictable code assurance. See how it compares with Claude Code Review.](https://autter.dev/blog/autter-vs-claude-code-review) [Aug 30, 2026 · 10 min read Copilot Can Review Copilot. That Is Not a Second Reviewer. GitHub now lets Copilot code review cover Copilot-authored PRs. Covering bot PRs was the right product move. Same-vendor review is still the author certifying the merge.](https://autter.dev/blog/copilot-can-review-copilot-that-is-not-a-second-reviewer)


---

---
title: Autter vs Claude Code Review: Should the AI That Writes Your Code Also Review It? - Autter Blog
description: Autter is the stronger first choice for teams that need risk-based verification, enforceable merge gates and predictable code assurance. See how it compares with Claude Code Review.
url: https://autter.dev/blog/autter-vs-claude-code-review
date: 2026-07-28
author: Sagnik, Tech @ Autter
tags: Comparison, Code Review, AI
reading_time: 15 min
site: Autter - Autter is the code security and assurance layer for the AI coding era: it checks every change before it merges, catches security risks, governs releases, and closes the loop from production failure to verified fix.
---

[← All posts](https://autter.dev/blog)

Jul 28, 2026

# Autter vs Claude Code Review: Should the AI That Writes Your Code Also Review It?

Autter is the stronger first choice for teams that need risk-based verification, enforceable merge gates and predictable code assurance. See how it compares with Claude Code Review.

Sagnik, Tech @ Autter 15 min read

- Comparison
- Code Review
- AI

AI code review has become table stakes. The more interesting question today is not whether a tool can review code—it is what evidence it can provide before that code reaches production.

That is where Claude Code Review and Autter begin to diverge. The differences become much clearer when the question shifts from **“What is wrong with this PR?”** to **“Is this PR actually ready to merge?”**

> “Review is advice. Assurance is protection.”

Finding issues is useful, but proving that a change is safe to merge is the bigger job. Claude Code Review is a capable AI reviewer that analyzes pull requests and posts findings. Autter goes further by turning code review, runtime verification, security evidence and organizational policy into an enforceable merge decision.

That distinction matters whether your code is written by humans, Claude Code, Cursor, Codex or an internal coding agent. The authoring tool may change from one pull request to the next. Your release standard should not.

Claude Code Review can still be a valuable addition for teams that want another deep, model-driven opinion on selected pull requests. But if you are choosing one product to improve release confidence across the organization, Autter is a good start.

## Autter vs Claude Code Review at a glance

Side-by-side

Same pull request. Different responsibility.

Assurance gate **Autter**

AI reviewer **Claude**

### 01 Primary job

Autter Verify changes and govern merges

Claude Find correctness and security issues

### 02 Product category

Autter Independent assurance layer

Claude AI pull request reviewer

### 03 Review method

Autter Risk-based code, security and execution checks

Claude Multiple specialized Claude agents

### 04 Codebase context

Autter Persistent context across code, APIs, schemas, tests and operational signals

Claude Analyzes changes against the full codebase

### 05 Main output

Autter Findings, execution evidence and a merge verdict

Claude Inline findings with severity and explanations

### 06 Merge blocking

Autter Designed to hold the merge until required checks pass

Claude Neutral by default

### 07 Runtime verification

Autter Part of the pull request assurance process

Claude Available through separately configured Claude workflows

### 08 Customization

Autter Repository rules, custom checks and merge requirements

Claude CLAUDE.md and REVIEW.md

### 09 Pricing model

Autter Monthly pull request volume

Claude Token usage per review

### 10 Best suited for

Autter Teams that need a consistent standard for what is allowed to ship

Claude Teams that want deep automated review without a managed release gate

## How is Autter a smart choice?

Code review is only one part of release confidence.

A pull request can contain no obvious bug and still be unsafe to ship. A payment handler might lack an idempotency test. An authentication change might never exercise token revocation. A database migration might work in isolation but fail against the previous application version.

These are not always problems a reviewer can identify from the diff. They are gaps in evidence.

Autter is designed around those gaps. Instead of asking only what looks wrong, it asks what must be proven before the pull request can merge. It connects review findings with blast radius, test results, runtime behaviour, security evidence, CI status and repository policy, then produces a merge verdict.

That makes Autter more than another review bot. It becomes a consistent assurance layer for every change, regardless of who or what wrote the code.

![Captain Patch investigating a tiny pull request connected by a glowing fault line to a vast system of locks, data stores and service pipes](https://autter.dev/blog/autter-vs-claude-blast-radius.jpg)

*A small change can carry a large blast radius. The verification plan should reflect the systems at risk.*

## What Autter actually does

Autter connects repository data with pull requests, CI, documentation, issue trackers and production signals. It maps code, APIs, database schemas, routes, tests, ownership and blast radius into persistent product context.

![Captain Patch supervising a mechanical assurance line moving a pull request through context, risk, runtime, security, policy and merge checks](https://autter.dev/blog/autter-vs-claude-assurance-pipeline.jpg)

*Pull request → context mapping → risk analysis → runtime verification → security checks → policy evaluation → merge verdict.*

For each pull request, Autter can:

1. Understand the change.
2. Map the systems it can affect.
3. Estimate the risk.
4. Select the required checks.
5. Run the change in an isolated environment.
6. Evaluate security and dependency evidence.
7. Apply repository and organizational rules.
8. Produce a merge verdict.

The goal is not simply to leave an impressive review comment. It is to decide whether the change has earned the right to merge.

Autter sits above the CI systems a team already uses rather than asking the team to replace them. It reads existing checks, adds missing verification where needed and keeps the merge blocked until the required evidence is present.

This is why Autter is the more complete starting point. It provides the control layer that turns separate checks and review signals into a release decision.

## Isn’t Claude Code Review doing a good job already?

Claude Code Review is Anthropic’s managed pull request review service. When a review starts, multiple agents inspect the diff and surrounding code in parallel, with each agent looking for a different class of issue.

![An automated magnifying-lens review station examining a pull request before Captain Patch operates a separate mechanical assurance gate](https://autter.dev/blog/autter-vs-claude-reviewer-vs-gate.jpg)

*A capable reviewer can find issues. The assurance gate still has to decide whether the evidence permits the change to ship.*

A later verification stage checks candidate findings against the code, removes duplicates and ranks what remains. The results appear as inline GitHub comments and in a check-run summary, with findings classified as Important, Nit or Pre-existing.

This is not a basic diff summarizer. It is designed to find logic errors, security vulnerabilities, broken edge cases and regressions using context from the broader codebase.

Teams can also change how the reviewer behaves through two repository files. `CLAUDE.md` provides general project context, while `REVIEW.md` contains review-specific instructions with higher priority.

Those instructions can redefine severity, limit low-value comments, ignore generated files, require integration tests for certain changes or demand stronger evidence before Claude posts a finding. That makes Claude Code Review a capable and configurable review system.

Its limitation in this comparison is scope: it is primarily a reviewer, not a complete assurance gate.

## Review findings are not the same as a merge decision

![Two parallel pull request lanes, one ending after review with an unresolved question and the other passing evidence checks before Captain Patch opens the gate](https://autter.dev/blog/autter-vs-claude-review-vs-evidence.jpg)

*Review can end with a recommendation. Assurance ends with an evidence-backed merge decision.*

Claude Code Review creates a GitHub check, but the managed check is neutral. It does not approve the pull request or block merging through branch-protection rules by default.

Teams can build CI logic that parses Claude’s severity output and turns Important findings into a blocking check. But the team then has to create, test and maintain that enforcement layer.

Autter is designed to provide the gate from the start.

The difference becomes clear when a change has no obvious review finding but still lacks the evidence required to ship. For example:

- A new payment handler has no idempotency test.
- An authentication change never exercises token revocation.
- A migration passes by itself but fails against the previous application version.
- A dependency upgrade affects a reachable production path.
- A sensitive AI-generated change is missing a required human approval.

A reviewer can flag concerns. An assurance system must determine whether the required proof exists and prevent the merge when it does not.

The core distinction

For teams that need both insight and control, the merge decision is the more valuable foundation. That is the role Autter is built to own.

## Independent assurance creates a consistent standard

Using Claude to write code and Claude Code Review to review it does not automatically make the review untrustworthy. Anthropic uses multiple agents, separate instructions and a verification stage rather than simply asking the original coding session to mark its own work.

The stronger case for independence is operational.

A coding agent is optimized to help a developer complete a task. A release-assurance system is responsible for deciding whether that completed task satisfies the organization’s shipping requirements. Those are different jobs, even when the systems performing them use similar underlying models.

The distinction becomes more important when Claude is not the only author. A team might use Claude Code for backend features, Cursor for frontend changes, Codex for migrations, internal agents for infrastructure work and humans for architecture-sensitive changes.

Each authoring environment carries its own prompts, habits and review workflow. If the release standard lives inside the authoring environment, it can move with the author.

Autter gives every change the same independent gate, regardless of which human or coding agent produced it. That makes it the safer default for teams adopting multiple AI development tools.

## Persistent context makes verification more relevant

![Captain Patch maintaining a central code repository vault connected to APIs, databases, tests, documentation, CI, logs and historical risk signals](https://autter.dev/blog/autter-vs-claude-persistent-context.jpg)

*Verification gets smarter when product context persists across pull requests.*

Claude Code Review analyzes a pull request in the context of the full codebase. Its agents can inspect surrounding files, trace relevant behaviour and investigate how the changed code interacts with the rest of the repository.

That is materially better than reviewing the diff alone.

Autter takes context further by maintaining product context across code, APIs, schemas, routes, tests, owners, historical failures and operational signals.

The distinction is between retrieving enough context to perform an individual review and retaining context so future assurance decisions can use what the system has already learned.

That accumulated context can help answer questions such as:

- Which product flow depends on this function?
- Which tests cover the affected route?
- Has this area caused failures before?
- Which team owns the downstream service?
- Does this change touch an especially fragile path?
- What additional evidence does that history justify?

Context is valuable when it changes the verification plan. Autter uses it to decide what must run, what needs approval and what should prevent the merge.

## Runtime verification is the clearest dividing line

Claude Code is an agentic development tool. It can run commands, modify files and execute tests, and teams can use Claude Code GitHub Actions to create custom review or security workflows.

That makes the Claude ecosystem highly configurable. A team can build workflows that run on pull request events, use repository-specific prompts and execute selected checks on GitHub-hosted runners.

But the managed Claude Code Review product and a custom Claude workflow are not the same thing. The managed reviewer primarily finds and explains correctness issues, while the team owns any additional execution and enforcement around it.

Autter makes execution part of the assurance process. Each pull request can be cloned into an isolated environment and evaluated against the base branch.

![Captain Patch monitoring a sealed runtime sandbox containing miniature services, databases, tests and live diagnostic instruments](https://autter.dev/blog/autter-vs-claude-runtime-sandbox.jpg)

*Runtime verification observes the behaviour of the change inside an isolated environment.*

Depending on the change, the checks can include:

- Building the application.
- Running existing tests.
- Generating tests for uncovered behaviour.
- Starting affected services.
- Calling changed API endpoints.
- Checking database migrations.
- Exercising integration paths.
- Validating dependencies against real registries.
- Inspecting logs, traces and runtime failures.

The point is not to run everything on every pull request. That would be slow, expensive and often unnecessary.

The point is to run what the risk justifies. A documentation typo should not receive the same assurance plan as a billing migration. Autter makes that risk-based execution part of the product rather than a custom workflow the team must assemble.

## Enforceable policies are stronger than review instructions

Claude Code Review’s `REVIEW.md` is useful because it lets teams describe what the reviewer should care about. A repository might contain instructions such as:

- Treat PII in logs as Important.
- Ignore generated files.
- Require an integration test for every new API route.
- Report no more than five nits.
- Demand evidence before making a behavioural claim.

These instructions influence what Claude investigates, reports and ignores. An enforceable policy goes further because it changes whether the pull request is allowed to merge.

> Any migration affecting a table used by the billing service must pass backward-compatibility verification and receive approval from the platform owner.

That rule has a condition, codebase context, required evidence, an owner and a merge consequence.

Claude can be instructed to identify a violation. Autter is designed to make the evidence and approval part of the gate itself.

That is the difference between telling a reviewer what to look for and telling the release system what must be true. If governance matters, Autter should be the first choice.

## Pricing: predictable assurance versus per-review usage

Claude Code Review is billed separately based on token usage. Anthropic states that a managed review costs approximately $15 to $25 on average, although the actual amount depends on the pull request, repository complexity and the number of findings that require verification.

The review trigger also matters. Teams can run a review when the pull request is created, after every push or only when someone requests it manually. Running the review after every push can multiply the cost across the life of the pull request. At the stated average, 300 reviews in a month would cost approximately $4,500 to $7,500.

That does not automatically make Claude Code Review expensive. A serious production failure can cost much more than several months of review usage. It does, however, make review cadence a budget decision.

Autter prices by monthly pull request volume rather than tokens or seats. As of August 2026:

- Harbour is free and includes 10 pull requests per month. It covers one repository and basic review.
- Port costs $20 a month and includes 40 pull requests.
- Cargo costs $40 a month and includes 100 pull requests.
- Fleet costs $80 a month and includes 300 pull requests.
- Enterprise is custom pricing for SSO, on-prem deployment, and higher volume.
- Harbour pauses at its included pull requests and is never billed.
- Extra pull requests are $1.20 on Port, $0.90 on Cargo, and $0.60 on Fleet.

The pricing models reflect the products. Claude Code Review charges for the model work performed during each review, while Autter charges according to how much code moves through the assurance gate.

For teams that want every pull request evaluated consistently, Autter’s volume-based model is easier to align with an organization-wide release process. Claude’s usage model can still make sense when deep reviews are reserved for selected pull requests.

![Captain Patch presenting two pricing panels that compare a rising per-review token meter with stable monthly pull request capacity](https://autter.dev/blog/autter-vs-claude-pricing-models.jpg)

*Per-review token usage grows with review frequency. Monthly pull-request volume is designed around a consistent organization-wide gate.*

## AI provenance is becoming a governance requirement

When AI-written code was unusual, identifying it was mostly a curiosity. That changes once several coding agents contribute to the same codebase every day.

Engineering leaders then need to understand where changes came from, how they were verified and what happened after they reached production.

A provenance layer can connect code changes with authorship, model usage, CI evidence, approvals, deployments and production outcomes. That helps organizations answer questions such as:

- Are AI-generated changes failing different checks from human changes?
- Which agents create the most regressions?
- Are sensitive paths receiving the required approvals?
- Did a previous production failure lead to a new test or release rule?
- Can the organization reconstruct why a change was allowed to merge?

This is no longer mainly about whether the code was written by AI. It is about whether the organization can account for how the code was verified.

Autter’s author-independent assurance model is better suited to that governance problem because it applies the same evidence standard across people, tools and agents.

## Choose Autter when

- Human and AI changes must pass through the same release standard.
- Your team uses several coding agents or expects to do so.
- Review comments alone are not enough.
- Merge requirements need to be enforced rather than suggested.
- Verification should change with blast radius and risk.
- Runtime behaviour matters as much as static analysis.
- You want code, CI and production signals connected in one assurance layer.
- You want predictable pricing based on pull request volume.
- Your priority is release confidence, not only review depth.

If these requirements sound familiar, Autter is not merely an alternative to Claude Code Review. It is the more complete product for the job your team needs done.

## Choose Claude Code Review when

- Your organization already uses Claude Team or Enterprise.
- Claude Code is the main development environment.
- You want a deep automated second opinion on selected pull requests.
- Correctness-focused inline findings are the priority.
- You want to tune review behaviour through repository markdown files.
- You are comfortable choosing when reviews run and paying per review.
- You do not need the managed reviewer itself to block merges.
- Your existing CI and governance systems already handle enforcement.

Claude Code Review deserves credit for its multi-agent approach, full-codebase analysis and configurable verification process. It is a strong reviewer. It is simply solving a narrower problem than Autter.

## Can you use Autter and Claude Code together?

Yes. The products are not mutually exclusive.

Claude Code can build the change, and Claude Code Review can provide a deep, model-driven assessment of the pull request. Autter can then apply an independent release standard before the pull request merges.

1. A developer asks Claude Code to implement a feature.
2. Claude modifies the repository and opens a pull request.
3. Claude Code Review identifies correctness and security issues.
4. Claude or the developer addresses those findings.
5. Autter maps the affected systems and selects the required verification.
6. Autter runs the relevant code, security and integration checks.
7. The pull request merges once the required evidence and approvals exist.

In this setup, Claude helps produce and improve the code. Autter remains the final, independent assurance layer that determines whether the release is sufficiently verified.

If you only adopt one of the two, start with Autter. It covers the decision that ultimately matters: whether the change is ready to ship.

## Final verdict: make a thoughtful choice

Claude Code Review is a capable AI reviewer. It uses multiple agents, analyzes the broader codebase and verifies findings before posting them.

But a strong review is still not the same as an enforceable release decision.

Autter combines review, risk analysis, runtime verification, security evidence, organizational policy and merge control in one assurance process. It gives human-written and AI-generated changes the same standard and makes that standard actionable.

![Captain Patch in otter-sized armour guarding a gate that admits verified pull request capsules into a calm production harbour](https://autter.dev/blog/autter-vs-claude-final-verdict.jpg)

*The final responsibility is not to produce another opinion. It is to protect the production gate.*

The verdict

Choose Claude Code Review when you want an additional deep review of selected pull requests and already have enforcement covered elsewhere. Choose Autter when you want a system that determines what must be proven before every change can merge.

Claude can help write and review the change. Autter decides whether it is ready to ship.

### See Autter on your own code.

A 30-minute walkthrough with the founders. Bring a repo and watch Autter review a live pull request.

[Book a demo](https://autter.dev/contact)

## Put an assurance layer on every release.

Autter reviews every pull request before it merges, backed by humans. Connect a repo and see your first findings today.

[Get started](https://app.autter.dev/login)

## Keep reading

[Jul 27, 2026 · 4 min read Introducing the Autter MCP server Connect Claude Code, Cursor, OpenCode, and other MCP-compatible coding agents to Autter’s reviews, codebase intelligence, security findings, and team knowledge.](https://autter.dev/blog/autter-mcp-server) [Aug 21, 2026 · 9 min read Your PR Is Green. Should You Still Be Nervous? Tests are green, the code compiles, and the PR looks harmless. Learn what code review must catch beyond CI and why reviewing a diff is only the beginning.](https://autter.dev/blog/merge-room-episode-1-your-pr-is-green)


---

---
title: Introducing the Autter MCP server - Autter Blog
description: Connect Claude Code, Cursor, OpenCode, and other MCP-compatible coding agents to Autter’s reviews, codebase intelligence, security findings, and team knowledge.
url: https://autter.dev/blog/autter-mcp-server
date: 2026-07-27
author: Team Autter
tags: Product, MCP, AI
reading_time: 4 min
site: Autter - Autter is the code security and assurance layer for the AI coding era: it checks every change before it merges, catches security risks, governs releases, and closes the loop from production failure to verified fix.
---

[← All posts](https://autter.dev/blog)

Jul 27, 2026

# Introducing the Autter MCP server

Connect Claude Code, Cursor, OpenCode, and other MCP-compatible coding agents to Autter’s reviews, codebase intelligence, security findings, and team knowledge.

Team Autter 4 min read

- Product
- MCP
- AI

AI coding agents have become remarkably good at writing code. They can build features, refactor services, trace bugs, generate tests, and occasionally rewrite half the repository because you asked them to rename one variable.

But there is still an awkward gap in the workflow. The agent writing the code often cannot access what the review system already knows about it. It cannot see the architectural context Autter has built, the conventions your team follows, the security issues found during previous reviews, or the potential blast radius of the change it is about to make.

Developers have to carry this information between their editor, GitHub, and the Autter dashboard. We built the [Autter MCP server](https://autter.dev/features/mcp) to close that gap.

Where code is written **Coding agent**

Claude Code Cursor OpenCode Any MCP client

The bridge **Autter MCP Server** 16 purpose-built tools

What Autter knows **Autter intelligence**

Reviews Security Codebase Team knowledge

*The code writer can finally talk to the code reviewer.*

Through the Model Context Protocol, coding agents such as Claude Code, Cursor, OpenCode, and other MCP-compatible clients can now interact directly with Autter. Your coding agent can understand the repository, retrieve review findings, fix issues, check dependencies, and request another review from the same environment where it writes the code.

> “The code writer can finally talk to the code reviewer.”

## What we built

The first version of the Autter MCP server includes 16 tools covering the main stages of working with a repository.

| Area | What the agent can do |
| --- | --- |
| Repository discovery | Confirm its identity and find connected pull requests |
| Pull request review | Retrieve findings, reply to comments, resolve threads, and request another review |
| Team knowledge | Read existing conventions and teach Autter new ones |
| Codebase intelligence | Query the architecture, inspect symbols, calculate impact, and check repository health |
| Security and quality | Run scans, retrieve findings, monitor progress, and check dependencies |

These are not generic API endpoints placed behind an MCP wrapper. Each tool is designed around something a coding agent may genuinely need to do while working on a change.

## Review findings an agent can act on

The central tool is `get_pr_review`. It returns the latest review status, the overall pass, warning, or blocking verdict, review chapters, risk levels, and up to 50 findings ordered by severity.

Each finding includes its file and line location, severity, confidence, verification result, and current GitHub thread state. More importantly, it includes a ready-to-use `fix_prompt`.

Review comments are normally written for humans. They assume the developer will inspect the surrounding code, understand the architecture, and work out the right implementation. A coding agent needs that same feedback expressed as a specific instruction it can execute.

The `fix_prompt` turns an Autter finding into that instruction. The agent can retrieve the issue, understand what went wrong, and begin fixing it immediately.

Once the changes are complete, the agent can reply to the GitHub comment, resolve the review thread, push its changes, and request another review. The complete loop now looks like this:

```
Fetch review → apply fixes → resolve threads → push changes → request another review
```

GitHub remains the source of truth for thread resolution. If GitHub is temporarily unavailable, Autter still returns the rest of the review with a clear indicator that the thread state could not be retrieved.

## Understand the code before changing it

Impact analysis **What could this change affect?**

Elevated risk

08 **Reverse dependencies** Direct consumers

23 **Transitive dependents** Wider blast radius

Changed file **src/auth/session.ts** Core authentication path

61% **Test coverage** 3 affected journeys

High **Churn hotspot** 17 changes this month

*Autter maps the change beyond the diff before the agent starts editing.*

MCP is not limited to fixing problems after a pull request has been opened. Agents can consult Autter before writing the change.

`get_impact_analysis` helps an agent understand what could break if certain files are modified. It reports reverse dependencies, transitive dependants, churn hotspots, test coverage, and the estimated risk of the proposed change.

`get_symbol_info` lets the agent inspect a function, class, or symbol before editing it. It can see where the symbol is defined, who calls it, what it calls, whether it acts as an entry point, and how large its blast radius may be.

For broader questions, the agent can use `query_codebase`. Autter answers natural-language questions using its generated documentation and code graph, then includes citations pointing to the relevant repository context.

Instead of repeatedly searching files and hoping it found the important ones, the agent can ask the system that has already mapped the repository.

## Check dependencies before installing them

Most dependency warnings arrive after the package has already been added. The feature is built, the pull request is open, and a security scanner finally explains why the new dependency was a questionable life choice.

With Autter MCP, the agent can check first. It can look for known CVEs, find fixed versions, retrieve upgrade recommendations, and detect typosquatting or supply-chain warnings.

It can also start a full repository scan, monitor its progress, and retrieve findings across Autter’s scanning agents. Security moves closer to the actual decision, allowing the agent to evaluate a package before introducing it instead of discovering the risk after the implementation is complete.

## Give agents your team’s context

Every engineering team has conventions that are obvious to its members but invisible to an AI agent. Use the shared logger. Keep database writes inside a transaction. Never call this service directly. Do not touch that old utility on a Friday.

Autter learns these patterns through review feedback, dismissed findings, and repository rules. Through `get_learnings`, agents can read those conventions before they begin writing code.

The reverse flow works too. An authorized agent can use `add_learning` to teach Autter a new repository rule, such as:

> Use the shared structured logger instead of calling console.log.

That learning becomes part of the context used by future Autter reviews. Knowledge discovered while implementing one change can improve how later changes are written and reviewed.

## Built with controlled access

The MCP server uses organization-scoped Autter Personal Access Tokens. Tokens can expire, be revoked, and be restricted to read, write, or LLM-backed operations.

There is no arbitrary SQL access and no generic GitHub write tool. Every operation is limited to Autter’s review, security, and code-intelligence workflows.

Tool failures return structured errors such as `repo_not_found`, `insufficient_scope`, `scan_limit_reached`, or `github_unavailable`. This gives the coding agent enough information to correct its request instead of getting stuck on a vague error.

Every tool call is recorded in the organization’s audit log, including the actor, token, duration, result, and error code. Per-token rate limits also protect against runaway agent loops, because even machines occasionally need someone to tell them to slow down.

## What this changes

The Autter MCP server turns code review from a handoff into a continuous feedback loop.

A coding agent can now understand your architecture before touching it, follow team conventions while writing code, check dependencies before installing them, retrieve actionable review findings, fix the issues it introduced, and request another review through one standard protocol.

The goal was never to put the Autter dashboard behind an API. It was to make Autter’s review intelligence available at the exact moment an AI agent needs it.

AI agents are already writing more of the code. Now they can understand what the reviewer knows before that code reaches production.

The full tool catalog, the connection guide, and the access model live on the [MCP server page](https://autter.dev/features/mcp).

**PS:**

Sagnik wanted to add one more tool to this whole thing: a big red button that lets a human yell at the AI mid-task and tell it to slow down. No settings, no options. Just yelling.

Tanvi pointed out that's not a feature, that's just a rate limit with feelings, and we already built one of those.

*(currently: deciding if the AI should have to say "please" before it's allowed to teach us anything)*

### See Autter on your own code.

A 30-minute walkthrough with the founders. Bring a repo and watch Autter review a live pull request.

[Book a demo](https://autter.dev/contact)

## Put an assurance layer on every release.

Autter reviews every pull request before it merges, backed by humans. Connect a repo and see your first findings today.

[Get started](https://app.autter.dev/login)

## Keep reading

[Jul 16, 2026 · 14 min read Autter vs CodeRabbit: a reviewer is not a merge gate Compare Autter and CodeRabbit on AI code review, runtime verification, merge gates, rate limits, and pricing for teams shipping AI-generated code.](https://autter.dev/blog/autter-vs-coderabbit) [Jul 28, 2026 · 15 min read Autter vs Claude Code Review: Should the AI That Writes Your Code Also Review It? Autter is the stronger first choice for teams that need risk-based verification, enforceable merge gates and predictable code assurance. See how it compares with Claude Code Review.](https://autter.dev/blog/autter-vs-claude-code-review)


---

---
title: Autter vs CodeRabbit: a reviewer is not a merge gate - Autter Blog
description: Compare Autter and CodeRabbit on AI code review, runtime verification, merge gates, rate limits, and pricing for teams shipping AI-generated code.
url: https://autter.dev/blog/autter-vs-coderabbit
date: 2026-07-16
author: Sagnik, Tech @ Autter
tags: Comparison, Code Review, AI
reading_time: 14 min
site: Autter - Autter is the code security and assurance layer for the AI coding era: it checks every change before it merges, catches security risks, governs releases, and closes the loop from production failure to verified fix.
---

[← All posts](https://autter.dev/blog)

Jul 16, 2026

# Autter vs CodeRabbit: a reviewer is not a merge gate

Compare Autter and CodeRabbit on AI code review, runtime verification, merge gates, rate limits, and pricing for teams shipping AI-generated code.

Sagnik, Tech @ Autter 14 min read

- Comparison
- Code Review
- AI

Reviewer **Here is what I found.** Walkthroughs Comments and fixes Reviewer-led decision

Merge gate **Here is what the evidence allows.** Runtime behaviour Policy results Merge verdict

*Advice improves a review. Evidence determines whether the gate opens.*

Code review used to have a natural speed limit. Engineers could only write so much code, which meant another engineer could usually read the important parts before they reached production.

Coding agents removed that limit on production, but not on attention. Claude Code, Codex, Cursor, Copilot, and internal agents can open more pull requests than an experienced team can responsibly inspect. The bottleneck has moved from producing code to deciding which of it can be trusted.

CodeRabbit and Autter both sit inside that problem. They overlap in several places, and CodeRabbit deserves more credit than the usual “comment bot” comparison gives it. The real difference is not that one tool reviews code while the other does something completely unrelated.

The difference is where each product stops. CodeRabbit is built to produce a better review, while Autter is built to produce a defensible merge decision.

## Autter vs CodeRabbit at a glance

Side-by-side

Same pull request. Different stopping point.

### 01 Primary job

CodeRabbit Help developers review and improve pull requests

Autter Decide whether a pull request has enough evidence to merge

### 02 Main output

CodeRabbit Walkthroughs, comments, fixes, conversations, and check results

Autter Findings, affected systems, runtime evidence, policy results, and a merge verdict

### 03 Codebase context

CodeRabbit Repository context, code graph, linked repositories, issue context, and team learnings

Autter Application map covering code, APIs, schema, routes, tests, dependencies, owners, and affected journeys

### 04 Runtime verification

CodeRabbit Linters, scanners, sandboxed custom checks, and generated tests on supported plans

Autter Isolated execution of every pull request, dependency verification, targeted tests, and observed behaviour

### 05 Merge enforcement

CodeRabbit Available through configured pre-merge checks and Request Changes

Autter The primary product workflow

### 06 AI governance

CodeRabbit Reviews code produced by coding agents

Autter Records line-level AI authorship, including the agent, model, and prompt

### 07 Pricing model

CodeRabbit Per developer

Autter Per monthly pull-request volume

### 08 Usage model

CodeRabbit Rolling hourly limits, with adaptive fair-usage changes

Autter Flat monthly price for a fixed number of pull requests

### 09 Best fit

CodeRabbit Teams that want faster, broader AI review

Autter Teams that need an assurance layer between coding agents and production

Pull request #184 Merge blocked

✓ Static review **Passed**

✓ Dependency verification **Passed**

! Session invalidation journey **Failed at runtime**

Required evidence has not cleared. Merge pull request

*A representative Autter merge-blocked state, based on evidence rather than comment volume.*

## CodeRabbit is good at the job it was built for

CodeRabbit is a mature AI reviewer. It works in pull requests, the IDE, and the CLI, and it combines AI analysis with repository context, code graph analysis, issue context, suggested fixes, and more than 40 linters and security scanners.

It also has real enforcement features. Teams can define built-in or natural-language pre-merge checks, mark them as warnings or errors, and use the Request Changes workflow to block a pull request when an error-mode check fails. Reviewers can resolve the issue or explicitly override the failure, with restrictions available for who is allowed to do that.

That is useful, and pretending otherwise would weaken the comparison. CodeRabbit is no longer limited to leaving suggestions that everyone is free to ignore.

Its centre of gravity is still the review. The product helps a developer or reviewer understand the change, respond to findings, apply fixes, and move the pull request forward. Enforcement sits around that review workflow.

Autter starts at the other end. It assumes that the merge is the decision that matters, then works backwards to determine what evidence the decision requires.

## The problem is no longer a lack of comments

Most teams do not need another system telling them that authentication changes are risky. They already know. The difficult part is proving that the specific authentication change in front of them did not break session invalidation, weaken a route, bypass a policy, or change behaviour in another service.

A conventional review can raise those questions. An assurance layer has to chase them down.

This distinction becomes obvious when a small diff lands in a shared part of the application. A three-line change to a session helper may affect login, logout, token refresh, mobile clients, background jobs, and service-to-service calls. The diff itself does not explain any of that.

Autter maps the change against the application context it already knows, including code, APIs, schema, routes, tests, dependencies, and owners. It follows the change into the user journeys it can affect, then scales the scrutiny according to how far the change can travel.

That is a different use of context. CodeRabbit uses context to improve the review. Autter uses context to determine what needs to be verified before the merge can proceed.

![Autter Architecture map showing connected IDE integrations, services, authentication, authorship logging, and the organization database](https://autter.dev/blog/autter-architecture-map.png)

*A small diff can travel through a much larger part of the application.*

## Autter runs the pull request

A lot of AI code review is still based on reading. The model reads the diff, searches the repository, runs static tools, and makes a reasoned prediction about what the code will do.

That catches plenty of real issues. It also leaves an awkward gap between “this looks correct” and “this behaved correctly when we ran it.”

Some failures live entirely inside that gap. A migration can pass inspection and still fail on rollback. An endpoint can keep returning 200 while quietly changing the response body. A dependency can resolve locally but point to a package that does not exist in the registry. A test can be green because it never exercises the path the change actually broke.

Autter executes every pull request in an isolated sandbox. It resolves dependencies against real registries, runs the suite against the base branch, generates tests around affected journeys, and records the behaviour it observes. The merge verdict is tied to that evidence.

This does not make static review obsolete. It makes static review the beginning of the investigation rather than the end.

A CodeRabbit finding might correctly say that a session change could leave old tokens valid. Autter’s job is to trace the affected flow, exercise it, capture what happened, and keep the merge blocked when the result does not satisfy the repository’s rules.

That is the line between review and assurance. One identifies a plausible problem, while the other has to resolve whether the problem exists.

![Autter sandbox scene showing a pull request executing in an isolated environment with repository, CI, telemetry, Sentry, Grafana, and PostHog context](https://autter.dev/blog/autter-sandbox-scene.png)

*Static analysis starts the investigation. Runtime evidence closes it.*

## A check you can override is still a policy choice

CodeRabbit can block merges when its Request Changes workflow and error-mode checks are configured. It can also allow specified reviewers to ignore failed checks and unblock the pull request, which is a reasonable design for a reviewer-led workflow.

Autter takes a harder position. Its product page describes the merge block as non-negotiable until the required checks clear, because the gate is meant to represent the team’s release policy rather than another reviewer’s opinion.

That difference matters when standards have consequences. “Payment writes must be idempotent” is not useful as a wiki sentence if the payment change can merge without idempotency being verified. “Authentication changes need security review” is not a policy if the engineer rushing a release can simply decide that this change is probably fine.

In Autter, teams can attach different requirements to different kinds of changes. Authentication work can require security approval and integration coverage. Migrations can require backward-compatibility and rollback checks. Dependency changes can require registry and reachability verification. Infrastructure work can require the service to boot and behave correctly in an isolated environment.

The value is not that these are clever rules. Most experienced teams already know which rules they want. The value is that the rule becomes part of the path to merge instead of a sentence someone has to remember at 6:30 on a Friday.

## AI authorship is useful context, not a scarlet letter

Git tells you who committed the code. That answer becomes less informative when the developer directed an agent that wrote most of the change.

The code may still be excellent. The issue is that the team has lost context about how it was produced, which tool generated it, and how much independent verification should be applied.

The Autter CLI records line-level AI attribution in Git, including the agent, model, and prompt behind generated lines. It can operate locally, and the attribution is stored in Git Notes so it can travel with repository history.

That makes authorship available as a governance signal. A team can inspect whether a risky area was mostly written by a human or an agent, compare the reliability of different agent workflows, and require deeper verification when the source of a change warrants it.

The point is not to make AI-written code guilty until proven innocent. The point is to stop acting as though code provenance tells us nothing.

![Autter showing line-level attribution between human and AI-authored code](https://autter.dev/blog/autter-ai-cli.png)

*AI provenance becomes another piece of context the assurance policy can use.*

## CodeRabbit’s rate limits are clearer now, but they still matter

CodeRabbit charges per developer. Pro is listed at $24 per developer per month on annual billing, while Pro+ is $48. The corresponding month-to-month prices are $30 and $60.

Those plans include rolling hourly review allowances. Pro starts at five PR reviews per developer per hour, while Pro+ starts at ten. Automatic incremental reviews after a push, manual review requests, and manual full reviews each consume an available review. When none remain, the next review waits unless the organisation has enabled the paid usage-based add-on.

The word “starts” matters. CodeRabbit’s fair-usage policy progressively reduces review availability for developers with high recent activity. Pro drops to one review per hour after 60 reviews in the previous seven days, while Pro+ drops to one review per hour after 90.

The policy is documented, so it would be wrong to call the mechanics secret. It can still be difficult for a team to reason about the effective limit during an agent-heavy week.

A coding agent does not produce work in a neat average. It may open several pull requests during a migration, push multiple corrections to the same branch, or trigger full rereviews while an engineer is iterating. The team then has to consider not only the advertised hourly allowance, but also which actions consume it and how the previous seven days of activity affect current availability.

Recent discussions in the CodeRabbit subreddit include users complaining about longer-than-expected waits and review availability that felt inconsistent with the headline allowance. Those comments are anecdotal and should not be treated as representative of every customer, but they show why buyers care about predictability rather than only the number printed beside “reviews per hour.”

Availability under heavier recent activity **Recent usage changes one allowance. The other remains predictable.**

Relative review availability

Full 50% Low

Autter: no adaptive slowdown

Pro+: 10 to 1 per hour

Pro: 5 to 1 per hour

Pro steps down Pro+ steps down 0 60 90 More

Reviews in the previous 7 days

**CodeRabbit:** Pro falls from 5 to 1 review per hour after 60 reviews. Pro+ falls from 10 to 1 after 90.

**Autter:** Recent activity does not reduce availability. Each plan includes a fixed number of pull requests a month, and reviews pause at that cap.

*This illustrates the documented usage rules, not measured customer throughput.*

## Autter prices the thing being reviewed

Autter does not charge by developer seat. It charges by the number of pull requests reviewed each month, so adding engineers or coding agents never changes the bill.

Harbour includes 10 reviews a month for free on one repository. Port costs $20 a month and includes 40 PRs. Cargo costs $40 and includes 100 PRs. Fleet costs $80 and includes 300 PRs. Enterprise is custom pricing for SSO, on-prem deployment, and higher volume.

Every plan is a flat monthly price. Once a plan uses its included reviews, additional PRs wait until the next month. Paid plans keep reviewing and bill the extra pull requests: $1.20 on Port, $0.90 on Cargo, and $0.60 on Fleet. There is no rolling hourly slowdown.

That pricing model matches how agent-heavy teams tend to think. They may have five engineers using several coding agents across twenty repositories. Seat count does not tell you much about the amount of code that needs review, while pull-request volume does.

It also removes a strange operational question from the workflow. An engineer should not have to wonder whether pushing another fix will consume the last review of the hour, whether yesterday’s agent activity has reduced today’s availability, or whether the team should delay a rereview until the allowance refills.

With Autter, the commercial trade-off is visible. The plan includes a known number of pull requests, and the next pull request has a known price.

## Can CodeRabbit and Autter run together?

They can, provided the team gives them different jobs. CodeRabbit can remain the everyday reviewer that helps developers understand a change, catch issues early, apply quick fixes, and get feedback in the IDE or CLI.

Autter can sit later in the path as the release gate. It can run the change, verify the affected journeys, apply repository policy, and decide whether the available evidence is enough to unlock the merge.

Using both products to leave similar comments on the same lines would create noise. Using one to improve the change and the other to verify whether it is safe creates a coherent pipeline.

That setup will not be necessary for every team. It makes sense when review quality and release assurance have become separate problems.

Build **Coding agents**

→

Improve **CodeRabbit review**

→

Verify **Autter assurance gate**

→

Ship **Production**

*Two tools can coexist cleanly when they are assigned different jobs.*

## When CodeRabbit is enough

CodeRabbit is a reasonable choice when human review capacity is the main constraint. It gives developers fast feedback, broad workflow coverage, configurable checks, and a mature review experience across the pull request, IDE, and CLI.

For many teams, that is the problem they need to solve. Their code volume is manageable, their release policies are lightweight, and an experienced reviewer remains involved in every important decision.

Autter is not arguing that every engineering team needs a heavy gate around every change. A low-risk internal application with a small, senior team may get more value from faster review than from deeper verification.

The argument changes when agents produce a meaningful share of the code, small changes can have a wide blast radius, and the cost of a bad merge is high enough that “a reviewer looked at it” is no longer sufficient evidence.

## When the merge needs its own product

At some point, faster review stops solving the actual bottleneck. The team can read the pull request sooner, respond to the findings sooner, and still lack confidence that the change behaves correctly across the application.

That is the point where the merge decision needs its own system.

Autter runs the pull request, traces what it can affect, applies the rules that matter for that kind of change, and keeps the gate closed until the evidence clears. It also records which parts were written by an agent, because the provenance of a change is now part of understanding how much verification it deserves.

CodeRabbit is built to help engineers review more code. Autter is built for the moment when producing more review is no longer the same as producing more trust.

Agents will keep writing more of the code. The uncomfortable question is no longer whether a review tool can comment on all of it, but whether your team has a defensible reason for letting it ship.

That is the job Autter is built to do.

![Autter opening the harbour gate after the required evidence has cleared](https://autter.dev/blog/opening-gate.png)

*The gate opens when the evidence clears.*

### See Autter on your own code.

A 30-minute walkthrough with the founders. Bring a repo and watch Autter review a live pull request.

[Book a demo](https://autter.dev/contact)

## Put an assurance layer on every release.

Autter reviews every pull request before it merges, backed by humans. Connect a repo and see your first findings today.

[Get started](https://app.autter.dev/login)

## Keep reading

[Jul 13, 2026 · 11 min read Autter got promoted: From code reviewer to engineering teammate Autter started as a code reviewer. Now it stays with a change from review and testing through merge, production, and the verified fix.](https://autter.dev/blog/autter-got-promoted) [Jul 27, 2026 · 4 min read Introducing the Autter MCP server Connect Claude Code, Cursor, OpenCode, and other MCP-compatible coding agents to Autter’s reviews, codebase intelligence, security findings, and team knowledge.](https://autter.dev/blog/autter-mcp-server)


---

---
title: Autter got promoted: From code reviewer to engineering teammate - Autter Blog
description: Autter started as a code reviewer. Now it stays with a change from review and testing through merge, production, and the verified fix.
url: https://autter.dev/blog/autter-got-promoted
date: 2026-07-13
author: Team Autter
tags: Product, Story, Engineering
reading_time: 11 min
site: Autter - Autter is the code security and assurance layer for the AI coding era: it checks every change before it merges, catches security risks, governs releases, and closes the loop from production failure to verified fix.
---

[← All posts](https://autter.dev/blog)

Jul 13, 2026

# Autter got promoted: From code reviewer to engineering teammate

Autter started as a code reviewer. Now it stays with a change from review and testing through merge, production, and the verified fix.

Team Autter 11 min read

- Product
- Story
- Engineering

Autter started as a code reviewer. You opened a pull request, Autter reviewed it, and everyone moved on with their lives. That was useful, but over time we realised that reviewing the code was only one part of the job.

Over the last few months, we spoke to more than 40 people who were using, testing, or considering Autter. They were not looking for another tool that left a few comments on a pull request and disappeared. They wanted something that stayed involved after the review was over.

They wanted Autter to test a feature before it shipped, check whether a fix had quietly broken something else, and catch problems before they turned into a 3 am Slack thread where everyone was online but nobody was entirely sure what had happened.

In short: they wanted Autter to babysit the entire software delivery cycle, not just heckle it from the sidelines during review.

That is a much bigger job than code review, so Autter got a promotion.

> “Autter is still a code reviewer. It just does not clock out after leaving a few comments.”

![A diagram showing Autter connecting test execution, regression checks, security, dependency vetting, and merge sign-off to clean releases](https://autter.dev/blog/autter-assurance-layer.png)

*One hire, every task: the entire assurance layer on every pull request.*

## From reviewer to teammate

![Autter and an all-otter engineering crew collaborating around a shared product map](https://autter.dev/blog/autter-promoted-teammates.jpg)

*The review is one checkpoint. The teammate stays for the rest of the journey.*

Code review is important. It is also, structurally, a single checkpoint — a bouncer checking IDs at one door while the rest of the building has no locks at all. A change can look perfectly reasonable inside a pull request and fail the moment it meets the rest of the product. A fix can solve the original bug while creating a new one somewhere nobody thought to check.

The new Autter is built to stay with a change for longer. It reviews the code, understands which parts of the product the change might affect, runs the relevant tests, checks for security and dependency problems, and helps decide whether the pull request is actually ready to merge.

This is what we mean when we call Autter a quality control plane. The phrase sounds slightly serious, but the idea behind it is simple: every important change should be checked before it reaches production, not after users start reporting that something feels broken.

Autter is still a code reviewer. It just does not clock out after leaving a few comments.

## It understands more than the diff

A pull request rarely tells the whole story. The code might affect an API, a database schema, a frontend route, a checkout flow, or a service owned by another team. Looking only at the changed lines can miss the consequences sitting a few steps away.

Autter connects information from repositories, pull requests, documentation, issue trackers, CI, deployments, and tools such as Sentry, PostHog, and Grafana. It uses those signals to build a working map of the product, including its code, APIs, routes, tests, owners, hotspots, and likely blast radius.

For teams, this means less time explaining the same context on every pull request. Autter can review a change with some understanding of where it fits, what it touches, and what should probably be tested before anyone presses merge.

It also helps when a change crosses team boundaries. The person writing the code might not know every service it affects, but the release still has to work when all those services meet.

## It tests what the change actually does

![Autter pushing a heavy crate of code into a running test lift](https://autter.dev/blog/autter-promoted-testing.jpg)

*Comments on code are useful. Running the code is better.*

Comments on code are useful. Running the code is better.

Autter can turn important product flows such as signup, checkout, uploads, and webhooks into end-to-end missions. It can generate unit, API, and integration tests around those flows, look for missing coverage, and identify flaky tests that keep passing and failing depending on the mood of the day.

Each pull request can then run inside an isolated sandbox against the base branch. That gives the team a verdict based on how the change behaves, rather than whether the code merely looks suspicious or unusually confident.

This helps catch the annoying class of bugs that survive a normal review: the new endpoint that breaks an old client, the checkout fix that affects discounts, or the harmless frontend change that somehow makes Safari unhappy again.

It also means developers do not have to manually guess every possible side effect before asking for a review. Autter can help find the gaps and test them while the pull request is still open.

## It checks the things that are easy to miss

![Autter inspecting secrets, dependencies, authentication, vulnerabilities, and code provenance](https://autter.dev/blog/autter-promoted-inspection.jpg)

*The quiet risks still need a checkpoint.*

Not every risky change looks risky. Sometimes the problem is a leaked secret, a vulnerable dependency, a package that does not exist in the real registry, or an authentication check that vanished during a refactor.

Autter vets dependencies against registries and checks pull requests for secrets and known vulnerabilities before the change is allowed through the gate. It also classifies changes as human-written or AI-generated, so teams can apply more scrutiny where generated code needs it.

This matters more now that writing code has become much faster. More code can mean more experiments, more features, and more fixes. It can also mean more changes reaching review before anyone has built a complete mental model of what they do.

The answer is not to stop using AI or slow every developer down. It is to make sure faster code generation is followed by stronger verification.

## It works with CI rather than pretending CI does not exist

We are not trying to replace the pipeline a team has already spent years building. CI still runs the jobs, tests, and checks the team has configured.

Autter sits on top of those signals. It reads what the existing pipeline reports, adds tests where coverage is missing, and acts as a merge gate when something has not cleared the required checks. Human reviewers also stay firmly in the loop. Autter is there to handle repetitive and easy-to-miss issues so people can spend more time thinking about architecture, product behaviour, and whether the change should exist in the first place.

That distinction matters. A useful teammate should fit into the way the team already works. It should not arrive on Monday morning and demand that everyone rebuild the deployment pipeline by Friday.

## It follows production problems back to the fix

![Autter and Captain Scout tracing a production incident across a map to a verified fix](https://autter.dev/blog/autter-promoted-production-fix.jpg)

*A reviewer points out a problem. A teammate stays long enough to see whether it was fixed.*

Even with better checks, production will occasionally find a new and creative way to break. Software is generous like that.

When an error appears in production, Autter can connect telemetry from tools such as Sentry, PostHog, Grafana, and application logs back to the code that caused it. It can identify the relevant section, explain the likely cause, and connect the problem to an owner. Confirmed failures can then become fix pull requests, with the failing case rerun in the sandbox to verify that the patch actually works.

This closes a loop that is usually fragmented across alerts, dashboards, Slack messages, issue trackers, and someone sharing their screen at an unreasonable hour. Instead of only saying that something broke, Autter is designed to help trace why it broke and check whether the proposed fix solves the original problem.

That is the teammate part we care about most. A reviewer points out a problem. A teammate stays long enough to see whether it was fixed.

## It keeps some of the boring work from becoming a crisis

![Autter shielding organized documentation and release work from a storm of incidents](https://autter.dev/blog/autter-promoted-shield.jpg)

*The unglamorous work is often what keeps a routine release routine.*

Documentation is accurate exactly once: the day it's written. After that it slowly drifts into historical fiction. Release notes and changelogs often suffer the same fate, especially when the team is trying to ship quickly.

Autter can generate documentation, changelogs, and release notes from the codebase, pull requests, and the team's existing guidelines. It can also update them as changes are merged, rather than waiting for someone to remember three releases later.

The product also brings quality trends, coverage, flaky tests, hotspots, and cycle time into a release-readiness view. That gives engineering teams a way to see whether quality is improving over time, instead of judging every release by how calm Slack happens to be that afternoon.

None of this is the glamorous part of building software. It is, however, the part people notice immediately when it has been ignored.

## The old website was telling an old story

![Autter standing between an old monochrome code-review website and the wider product story](https://autter.dev/blog/autter-promoted-old-story.jpg)

*The product had moved on. The website had not caught up.*

Our previous website described Autter almost entirely as a code reviewer. That made sense when we first built it, but the product had moved on and the website had not caught up.

Someone could visit the site, understand that Autter reviewed pull requests, and leave without seeing everything that happened before and after that review. They were getting the first chapter and missing most of the book.

So we rebuilt the website around a fairly basic test: could someone understand what Autter does without booking a demo, opening five tabs, or already knowing what a quality control plane is?

That meant simplifying the language, making the product flow easier to follow, and using motion where it genuinely helped explain something. The animations are not there just to make the site feel futuristic. They show how a change moves from code to testing, verification, merge, deployment, and, when necessary, back to a fix.

A developer makes a change. Autter works out what it might affect, runs it, tests it, checks the risky parts, and gives the team a clearer answer about whether it is ready. If something later breaks in production, Autter helps trace the failure back and verify the fix.

That story should be easy to understand. The old website was not making it easy enough.

## This came from conversations, not a rebranding exercise

We did not wake up one morning and decide that "code reviewer" was no longer an exciting enough category. The shift came from listening to how people wanted to use Autter.

Again and again, people described it as something closer to an extension of their engineering team. They did not just want feedback on the code. They wanted more confidence that the feature, fix, or update would still work when it reached the real product.

That changed how we thought about the job Autter was doing. It was no longer enough to identify a possible issue, leave a comment, and move on. The product needed to test the change, show the evidence behind a finding, and stay involved until the team had a verified outcome.

The Autter we are building now is meant to do exactly that. It helps teams move quickly without making production the place where every assumption is finally tested. It also keeps working when the rest of the team is busy, tired, or very reasonably asleep.

Because software has a habit of breaking at inconvenient times. And when something goes wrong at 3 am, nobody wants to hear that the pull request looked fine six hours ago.

## Same Autter, bigger responsibility

![Autter smiling beneath an arc of engineering capability symbols](https://autter.dev/blog/autter-promoted-capabilities.jpg)

*Same Autter. Bigger responsibility.*

Autter is not leaving code review behind. Code review is still part of the product, but it is no longer the boundary of the product.

The new website reflects the wider job Autter is taking on. It shows how the product connects context, tests real behaviour, guards the merge, follows production failures, and helps verify the fix.

Autter started as the teammate who reviewed your code. It's now the teammate who sticks around long enough to make sure the code actually works — and doesn't quietly disappear the moment things get interesting.

**PS —**

**Sagnik:** can we get Autter a little name tag that says "Employee of the Month, Every Month"

**Tanvi:** we are not doing that

**Sagnik:** what if it's a nautical themed name tag

**Tanvi:** *(currently: reviewing Sagnik's name tag mockups so nobody else has to)*

### See Autter on your own code.

A 30-minute walkthrough with the founders. Bring a repo and watch Autter review a live pull request.

[Book a demo](https://autter.dev/contact)

## Put an assurance layer on every release.

Autter reviews every pull request before it merges, backed by humans. Connect a repo and see your first findings today.

[Get started](https://app.autter.dev/login)

## Keep reading

[Jun 22, 2026 · 5 min read We Open-Sourced the Tool We Use to Track AI-Generated Code Git says who committed a line, not who actually wrote it. We built Autter to track AI-generated code at the line level, and today the CLI is open source.](https://autter.dev/blog/we-open-sourced-the-tool-we-use-to-track-ai-generated-code) [Jul 16, 2026 · 14 min read Autter vs CodeRabbit: a reviewer is not a merge gate Compare Autter and CodeRabbit on AI code review, runtime verification, merge gates, rate limits, and pricing for teams shipping AI-generated code.](https://autter.dev/blog/autter-vs-coderabbit)


---

---
title: We Open-Sourced the Tool We Use to Track AI-Generated Code - Autter Blog
description: Git says who committed a line, not who actually wrote it. We built Autter to track AI-generated code at the line level, and today the CLI is open source.
url: https://autter.dev/blog/we-open-sourced-the-tool-we-use-to-track-ai-generated-code
date: 2026-06-22
author: Sagnik
tags: Open Source, AI, Developer Tools
reading_time: 5 min
site: Autter - Autter is the code security and assurance layer for the AI coding era: it checks every change before it merges, catches security risks, governs releases, and closes the loop from production failure to verified fix.
---

[← All posts](https://autter.dev/blog)

Jun 22, 2026

# We Open-Sourced the Tool We Use to Track AI-Generated Code

Git says who committed a line, not who actually wrote it. We built Autter to track AI-generated code at the line level, and today the CLI is open source.

Sagnik, Founder, autter.dev 5 min read

- Open Source
- AI
- Developer Tools

I ran `autter stats` last week and got this back:

```
you  ██░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ ai
     6%                                  94%
```

94% of that commit was AI. I wrote 6%.

The weird part? Before that moment, I had no idea the split was that lopsided. `git blame` showed my name on every line. CI passed. The PR got approved. But most of that code came from Claude, from a prompt I barely remember writing at 11 PM.

I kept thinking about this. Not the percentage itself, but the fact that nothing in my toolchain told me. Git doesn't care who actually wrote the code. It only knows who committed it. And right now, with every team running Cursor, Copilot, Claude Code, or some combination of five different agents, that distinction matters more than it used to.

So we built a thing. Today it's open source.

> “Git doesn't care who actually wrote the code. It only knows who committed it.”

## What it does

Autter is a git extension. You install it once, and from that point on, every line of AI-generated code gets linked to the agent that wrote it, the model it used, and the prompt session it came from. All of this happens automatically when you commit.

```
git commit -m "add auth middleware"

[auth-service 0afe44b2] add auth middleware
3 files changed, 127 insertions(+), 8 deletions(-)

you  ████████░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ ai
     18%                                82%
```

There's also `autter blame`, which works exactly like `git blame` (same flags, same everything) but shows you who actually wrote each line:

```
cb832b7 (Sagnik Ghosh      2025-12-13  133) pub fn execute_diff(
cb832b7 (Sagnik Ghosh      2025-12-13  134)     repo: &Repository,
fe2c4c8 (claude            2025-12-02  138)     // Resolve commits
fe2c4c8 (claude            2025-12-02  139)     let (from_commit, to_commit) = match spec {
fe2c4c8 (claude            2025-12-02  140)         DiffSpec::TwoCommit(start, end) => {
```

Lines 138–140 were Claude. You can trace them back to the exact prompt that generated them.

## How it works under the hood

I keep getting asked about this, so here's the short version:

Coding agents call `autter checkpoint` when they write or modify files. This is already built into 14 agents: Claude Code, Cursor, Copilot, Windsurf, Codex, Gemini, Amp, Junie, Continue, Pi, Droid, OpenCode, Rovo Dev, and Firebender.

On commit, Autter stores line-level attribution in Git Notes. Not in your commit history, not in your source files. Git Notes are metadata that travel alongside commits without touching the diff. This was a deliberate choice; we didn't want attribution data bloating your repo.

The part I'm honestly most proud of is the git operation handling. When you rebase, squash, stash, or cherry-pick, Autter moves and merges attributions automatically. It watches for those operations and reconciles the attribution within 5–100ms. We spent a lot of time making sure you couldn't lose track of who wrote what, no matter how aggressively you rewrite history. Go ahead, give it a try. Try breaking it apart as much as you want.

We don't use git hooks: too slow, too fragile across repos. We don't wrap the git binary: zero overhead on your git commands. And we don't use AI to guess which lines are AI-generated. The agents themselves report what they wrote. Guessing felt wrong for something that's supposed to be a source of truth.

> “The agents themselves report what they wrote. Guessing felt wrong for something that's supposed to be a source of truth.”

## The stats nobody has right now

`autter stats` gives you numbers that, as far as I can tell, most teams are currently guessing at or just not tracking:

```
{
  "human_additions": 28,
  "ai_additions": 76,
  "ai_accepted": 47,
  "git_diff_deleted_lines": 34,
  "git_diff_added_lines": 104,
  "tool_model_breakdown": {
    "claude_code/claude-sonnet-4-5-20250929": {
      "ai_additions": 76,
      "ai_accepted": 47
    }
  }
}
```

Percentage of AI code. Lines generated versus lines committed. Acceptance rates by tool and model. Human overrides.

This isn't survey data or a rough estimate. It's measured at the line level on every commit.

I think the `tool_model_breakdown` is the most interesting part. If you're running three different agents, you can now see which one actually produces code that sticks versus code that gets rewritten a week later.

## Prompt storage

This was one of the harder design decisions. Prompts contain useful context: the requirements, the architecture thinking, the "make it work like X but handle Y differently" kind of instructions. But they also often contain sensitive information: company names, internal systems, sometimes credentials pasted by accident.

We store prompt sessions outside of git entirely. They get scanned and redacted before storage. You get fine-grained access control over who can see them. And if you're running local-only mode, they never leave your machine.

The tradeoff is that prompt history requires a separate lookup rather than living inline with your code. We think that's the right call, but I'm curious what people think once they start using it.

## Install

macOS, Linux, and WSL:

```
curl -fsSL https://api.autter.dev/install.sh | bash
```

Windows (Command Prompt or PowerShell):

```
powershell -NoProfile -ExecutionPolicy Bypass -Command "iex (irm https://api.autter.dev/install.ps1)"
```

No per-repo setup. The installer asks whether you want local-only mode or to connect to the Autter platform. Local-only works without an account. The platform adds cross-repo dashboards, prompt search, and team analytics, with your data going to your org's own database.

[Autter-dev autter-cli Open source Git extension for line-level AI attribution. Track the agent, model, and prompt behind every generated line. install `curl ... | bash` license Apache 2.0 mode local-first View repo on GitHub](https://github.com/Autter-dev/autter-cli)

## For teams

We built a teams version because individual attribution, while useful, only gets you so far. The teams version connects to GitHub, GitLab, Bitbucket, or Azure DevOps and joins in data from across the SDLC:

- Percentage of AI code by PR, repo, team, and contributor
- Token cost tied to individual PRs
- How much rework AI code requires before and after deployment
- Incident tracing back to the AI session that generated the code
- Searchable prompt archive across all repos

Hundreds of teams are using this already. A few of them are bigger companies, though most are smaller engineering orgs that wanted visibility into what their agents were actually doing.

## Why we open-sourced it

Honestly, attribution should be infrastructure. It shouldn't be something you pay for to get the basics. The CLI does accurate line-level tracking locally, for free, and we think that should be the default for every developer using AI tools.

The spec is published too. We want other tools to build on this, not just us.

The business is the teams platform: the dashboards, the cross-repo analytics. The CLI is the foundation. It made more sense to open it than to gatekeep it.

Apache 2.0. Built in Rust.

- [Autter CLI on GitHub](https://github.com/Autter-dev/autter-cli)
- [Autter open attribution standard](https://github.com/autter-dev/autter-cli/blob/main/specs/autter_standard_v3.0.0.md)

If something breaks, tell us.

Sagnik

### See Autter on your own code.

A 30-minute walkthrough with the founders. Bring a repo and watch Autter review a live pull request.

[Book a demo](https://autter.dev/contact)

## Put an assurance layer on every release.

Autter reviews every pull request before it merges, backed by humans. Connect a repo and see your first findings today.

[Get started](https://app.autter.dev/login)

## Keep reading

[May 23, 2026 · 13 min read What We Did When Our Email Stack Stopped Sending Our dashboards said delivered. Inboxes said nothing. Two months of quiet outbound later, we built Hedwig and email-checker and open sourced both.](https://autter.dev/blog/what-we-did-when-our-email-stack-stopped-sending) [Jul 13, 2026 · 11 min read Autter got promoted: From code reviewer to engineering teammate Autter started as a code reviewer. Now it stays with a change from review and testing through merge, production, and the verified fix.](https://autter.dev/blog/autter-got-promoted)


---

---
title: What We Did When Our Email Stack Stopped Sending - Autter Blog
description: Our dashboards said delivered. Inboxes said nothing. Two months of quiet outbound later, we built Hedwig and email-checker and open sourced both.
url: https://autter.dev/blog/what-we-did-when-our-email-stack-stopped-sending
date: 2026-05-23
author: Sagnik
tags: Story, Infrastructure, Email
reading_time: 13 min
site: Autter - Autter is the code security and assurance layer for the AI coding era: it checks every change before it merges, catches security risks, governs releases, and closes the loop from production failure to verified fix.
---

[← All posts](https://autter.dev/blog)

May 23, 2026

# What We Did When Our Email Stack Stopped Sending

Our dashboards said delivered. Inboxes said nothing. Two months of quiet outbound later, we built Hedwig and email-checker and open sourced both.

Sagnik, Founder, autter.dev 13 min read

- Story
- Infrastructure
- Email

A founder asked me last week how our scan reports get delivered. I told him we used to run them through one of the bigger ESPs and now we run them through software we wrote ourselves. He laughed and asked if we built our own database too.

I said no, just the email part, because that was the part that broke.

The actual conversation we had after that is what this post is about, because the question keeps coming up in slightly different forms. Why did you migrate. What was wrong with the old stack. Was it really that bad. The short version is yes. The long version is the rest of this post.

As a team that provides "enforcement infrastructure," the one who blocks bad merges before they hit production, the one whose whole pitch is about catching what breaks before it becomes your problem: we went MIA.

Not intentionally. Not because we went on a team retreat to Shimla (that is a cool idea though). Not because we were too busy shipping features. We went quiet because the thing that was supposed to be carrying our voice out into the world had silently, cheerfully, dashboards-all-green stopped doing exactly that.

Here is the full story. The embarrassing part, the technical part, and the part where we fixed it.

## Going Back in Time to March

![Captain Patch standing next to a small wooden time machine in the harbour, looking puzzled at a calendar with March crossed out twice](https://autter.dev/blog/patch-in-march.webp)

*Captain Patch standing next to a small wooden time machine in the harbour, looking puzzled at a calendar with March crossed out twice.*

It started in March. We did not know it started in March until much later, which is part of the lesson, but if you wind the tape back that is where the trail begins.

The first signal was not a number. It was a feeling. Replies to outreach that should have come back in a day were taking three. New signups felt slower than the activity on the landing page implied. We chalked it up to the usual early-stage noise of bad weeks and good weeks and ignored it the way founders are supposed to ignore most of the funnel ghosts they see.

Then Tanvi noticed the waitlist confirmation open rate had dropped by half in two weeks. Nothing else had changed. That was the thread that actually got pulled. She pulled, I pulled, and by the end of the day the whole sweater was on the floor.

The clearest tell came from a user on Twitter asking where his scan report was. I checked our platform. The send was marked delivered. I checked the inbox on the test account. Nothing. Waited an hour. Still nothing. The report eventually landed three hours later in a folder the recipient does not check on a regular basis, which is the kind of "delivery" that does not count.

This is the worst class of infrastructure failure because it does not look like one. The dashboard reads green, the success rate sits at 99 point something percent, and yet the actual job the system is supposed to do has stopped happening at scale.

> “If the dashboard says delivered and the inbox says nothing, the dashboard is wrong.”

The platform we were on is a well-known ESP, the kind of name you would recognize and that most teams default to at our stage. It was the right choice when we picked it. We had outgrown it without noticing.

## What It Did to Us

![Captain Patch on the harbour deck watching letters pile up at the gate while the lighthouse blinks late and ships drift in the fog](https://autter.dev/blog/patch-letters.webp)

*Captain Patch on the harbour deck watching letters pile up at the gate while the lighthouse blinks late and ships drift in the fog.*

The damage compounded in ways we only mapped in retrospect. Most of it was invisible from inside the dashboard, which is the part that still bothers me.

Cold outreach went dry. Conversations that had been alive in February stopped coming back in March. We assumed for a while that the market had cooled and spent a couple of weeks idly worrying about whether we had said something wrong in a post somewhere. The market was fine. Our messages were just not getting where they needed to go.

Scan report delivery turned into a guessing game. The free codebase scan is the artifact that closes our top of funnel, and the report was arriving late, or in spam, or sometimes not at all. The single highest-value email we send was the least reliable one in the queue. We did not realize this for weeks because every prospect who never got their report just quietly disappeared and we had no good way to tell the difference between "they did not care" and "they never received it."

Sender reputation was eroding underneath all of it. Bounces were not being surfaced in time, so we kept re-sending to dead addresses, so receiving servers started treating us with a little more suspicion every week. None of that registered as a hard fail. It was a slow descent on a graph nobody was watching closely enough.

Open rates went down. Signups slowed. Free scan registrations were getting delayed badly enough that some prospects must have assumed the form had broken and moved on. Onboarding emails trickled out at a third of the volume we had configured them at.

The cumulative effect was that the entire top of our funnel was running through a layer that had stopped working, and the only signal was the absence of activity. Absence is brutal to read. It does not show up on any chart we owned at the time. You only feel it.

## The Internal Conversation

![Captain Patch and Captain Scout at the harbour office table, Patch holding a graph that slopes downward, Scout pointing at it with one paw and at the lighthouse with the other](https://autter.dev/blog/patch-harbour-graphs.webp)

*Captain Patch and Captain Scout at the harbour office table, Patch holding a graph that slopes downward, Scout pointing at it with one paw and at the lighthouse with the other.*

It clicked on a Tuesday. Tanvi walked over with the open rate dashboard and said something close to "This cannot be us. We have not changed anything."

We had not changed anything. That was the point.

The argument we had after that is worth writing down because I suspect some version of it happens in every startup eventually.

She wanted to migrate. There are plenty of decent ESPs. Switch the API keys, repoint the templates, be back in business inside a week, move on. I did not want to do that. Moving from one black box to another black box would buy us a year and then we would be sitting in this same conversation again, except next time we would have wasted a year not learning anything about the layer that had been quietly running our business.

Her counter was fair. The job right now is to get outreach moving again, not to philosophize about infrastructure. Two months of dark outbound is already two months too long. Pick the fastest thing that works.

We landed somewhere between the two positions, which is what cofounders do when both of them are partly right. Pick a path that gets us back to working email inside a week and that we can never get trapped in again. That compromise is what produced Hedwig and email-checker.

## Why This Happened

![Captain Patch with a magnifying glass over a stack of receipts and dashboards, an opaque box labelled ESP sitting in the corner with a small sign reading trust me](https://autter.dev/blog/patch-magnifying-glass.webp)

*Captain Patch with a magnifying glass over a stack of receipts and dashboards, an opaque box labelled ESP sitting in the corner with a small sign reading trust me.*

Once we had ruled out our own domain as the primary cause (which we did first, the way you are supposed to do when something breaks), the only thing left was to test the platform itself against an alternative.

We took 800 transactional sends and split them in half. Same recipients, same content, same time of day, same authenticated sending domain. Half went through the existing ESP. Half went through a direct integration with a transactional provider we had been keeping in the back pocket for exactly this kind of contingency.

The direct path delivered in under thirty seconds. The ESP path took anywhere from forty minutes to four hours with a long tail of sends that simply never confirmed at all. Bounce data on the direct path came back in real time. The ESP took up to four hours to surface the same bounces, which is why we had been hammering dead addresses long after another system already knew they were dead.

We did not have a domain problem. We had a vendor problem.

> “We were paying for a black box that had quietly stopped working at the volume we were paying it for.”

The platform was not technically broken. It was working, somewhere inside there, just much slower than the dashboard claimed and much slower than the price tier we were on implied. Volume had outgrown the layer we were sending through, and the layer had no easy way to tell us that, because telling us would mean admitting that the price we were paying did not match the throughput we were getting.

There is a less polite read on why this happened, and it is the part that stings.

autter is an enforcement infrastructure company. The whole pitch is that advisory layers fail because they have no teeth, that when something matters you do not put it behind a UI that suggests, you put it behind a gate that blocks. And here we were, running the most important outbound channel in our business through an advisory abstraction that suggested it was sending while not actually sending. I have been telling investors and customers a version of this argument for months. Apparently I needed to hear it myself.

Lesson

If your funnel feels off and the dashboards say everything is fine, run a split test the same afternoon. Send identical payloads through your ESP and through a direct provider. The truth is obvious inside an hour.

## How We Fixed It

![Captain Patch at the harbour workshop building two small wooden boxes labelled Hedwig and email-checker, sleeves rolled up, sawdust on the floor](https://autter.dev/blog/patch-building-boxes.webp)

*Captain Patch at the harbour workshop building two small wooden boxes labelled Hedwig and email-checker, sleeves rolled up, sawdust on the floor.*

Two pieces. Built over a few weeks. Ran internally for two weeks. Open sourced this week.

**[Hedwig](https://github.com/Autter-dev/hedwig-mail)** is the sender. It runs on Resend and AWS SES as interchangeable backends. You route by region, by message type, by per-recipient deliverability data, or by whatever logic makes sense for your stack. If Resend has a bad hour, traffic shifts to SES inside a config change. If a particular recipient domain has been giving SES grief, that domain routes through Resend instead. Provider failover is a config concern, not a migration project.

**[email-checker](https://github.com/sagnik11/email-checker)** is the validator that sits in front of Hedwig. Syntax, MX records, SMTP probing where receivers allow it, disposable domain filtering, role account flagging, catch-all detection. It batches. It caches. It is fast enough to run inline on a form submit and cheap enough to run on a million-row import overnight. Bad addresses do not reach the sender, so the sender does not burn reputation on dead inboxes. The validator learns from every domain it sees and the loop closes on itself.

We open sourced both for three reasons and they are all real ones.

First, sending email and knowing who to send to is the most boring critical infrastructure in a startup. Nobody puts it on a roadmap. Nobody gets promoted for owning it. And the day it stops working is the day you find out it had been holding the entire go-to-market motion together. We just lived two months of that. The next early-stage team should not have to lose two months figuring out the same thing.

Second, every founder we talked to was hitting some version of this wall with some version of this kind of platform at the same growth stage. The ESP market is enormous. The layer underneath, which is the part you actually want to control, is fragmented and proprietary. There is no reason for every team to rebuild this from scratch in private.

Third, distribution. We are building autter in public and the tools we ship internally are the ones we want engineering leads to find when they go looking. If Hedwig or email-checker lands in someone's stack, autter is one shorter step away from landing in their merge pipeline. The motive is part useful and part self-interested and I would rather say so than pretend it is purely civic.

Both repos are MIT. Stars are nice. PRs are nicer.

[Hedwig Autter-dev / hedwig-mail Self-hostable broadcast email: contact lists, visual editor, campaigns through Resend or SES, open and click tracking. View on GitHub](https://github.com/Autter-dev/hedwig-mail) [email-checker sagnik11 / email-checker Verify email addresses without sending a single email: syntax, MX DNS, SMTP handshake, disposable/role detection, bulk processing, and CLI. View on GitHub](https://github.com/sagnik11/email-checker)

## Hedwig

Hedwig is the sender we built.

It runs on Resend and AWS SES as interchangeable backends. You can route messages by region, by message type, by per-recipient deliverability data, or by whatever logic you want to write. If Resend has a bad hour, traffic shifts to SES inside a config change. If a specific recipient domain has been giving SES grief, that domain routes through Resend instead. Provider failover is a configuration concern, not a migration project.

Campaigns are data, not buttons. Every campaign in Hedwig is a versioned object that lives in your repo. You diff it. You review it in a PR. You roll it back like any other piece of code. We were tired of building important sends inside vendor dashboards with no audit trail, no way to test changes before they went live, and no way to know who changed what.

Events land in your database within seconds of the provider firing them. Bounces, opens, complaints, deliveries, all of it. No four-hour lag. No mystery about whether a webhook arrived or not. If a send is going to fail, you know before you queue the next batch.

Templates are MJML compiled to HTML and they live in your repo with the rest of the codebase. They get reviewed. They get versioned. They pass through the same merge gate as everything else we ship, which is the same merge gate we sell to other teams, which means we eat our own cooking.

Hedwig does not assume anything about the rest of your stack. We run Node, Drizzle, Postgres. Plug in whatever you already use.

[Hedwig on GitHub Autter-dev / hedwig-mail Self-hostable broadcast email: contact lists, visual editor, campaigns through Resend or SES, open and click tracking. View on GitHub](https://github.com/Autter-dev/hedwig-mail)

## The Email Checker

The other half of the problem was knowing who to send to in the first place.

A list with twenty percent dead addresses will tank your sender reputation no matter how clean the rest of your setup is. Most validation services are either expensive at scale or unreliable at the cheap end. We needed something we could run on every signup, every CSV upload, every imported list, without paying per check forever.

email-checker does syntax validation, MX record lookups, SMTP probing where receivers allow it, disposable domain filtering, role account flagging, and catch-all detection. It batches. It caches. It is fast enough to run inline on a form submit and cheap enough to run on a million-row import overnight.

We use it as a gate in front of Hedwig. Bad addresses never reach the sender. The sender never burns reputation on dead inboxes. The validator gets smarter over time as it sees more domains. The loop closes on itself.

> “A list with twenty percent dead addresses will tank your sender reputation no matter how clean the rest of your setup is.”

[email-checker on GitHub sagnik11 / email-checker Verify email addresses without sending a single email: syntax, MX DNS, SMTP handshake, disposable/role detection, bulk processing, and CLI. View on GitHub](https://github.com/sagnik11/email-checker)

## Lessons Learnt

![Captain Patch and Captain Scout at the end of a long day, two cups of tea on the desk, a notebook open with bullet points half written, the lighthouse blinking clean and on time outside the window](https://autter.dev/blog/tea-on-desk.webp)

*Captain Patch and Captain Scout at the end of a long day, two cups of tea on the desk, a notebook open with bullet points half written, the lighthouse blinking clean and on time outside the window.*

Some of these are technical. Most of them are about how I now think about our own infrastructure. I wrote them down on a Tuesday and have not bothered to make them tidy.

**The split test should have happened in week one.** We spent two months trying to debug our way to a vendor-shaped answer because the test that would have given us the answer felt like overkill. It was not overkill. If you are on a hosted ESP and something feels off, send identical payloads through your ESP and through a direct provider integration on the same afternoon. The truth is obvious inside an hour.

**A vendor abstraction is useful right up to the day it hides the thing breaking**, and the day after that you should already be looking for an exit. We were treating our send pipeline as something we owned and we did not own it. The dashboard was the only thing we owned, and the dashboard turned out to be the wrong thing.

**Tanvi caught this two weeks before any monitoring tool did.** I want to write that down somewhere permanent because it keeps happening. The team noticing the funnel feels off is the signal. The dashboard agreeing with the team is the confirmation. We keep doing it in the other order and it keeps costing us time we could have spent fixing things instead of doubting our own pattern recognition.

**We sell the argument that enforcement beats advisory.** We were running the most important outbound channel in our business on advisory. There is no version of this sentence that makes me feel better about it. The fix is not just the new stack, the fix is the rule that every critical layer in our business has to be inspectable and gateable now, including the layers we used to assume vendors had solved on our behalf.

**Build versus migrate turned out to be a category question, not a tools question.** Migrating to a different ESP would have bought us twelve to eighteen months of relief. Building down a layer bought us indefinite control over the thing the business actually runs on. Short run, building cost more. Long run, the migration treadmill costs more. We are running a business measured in years not quarters and I keep forgetting to do the math that way.

**Absence is the hardest signal to read** and we should have built a measurement for it earlier. When something stops happening it does not show up on any chart we owned. It shows up as a quiet quarter where the founders start blaming the market. The market is rarely the answer.

**Last one.** If you have just lived a particular operational hell and you can see the next ten startups about to walk into the same one, open sourcing the fix is a small cost and a useful gift. Distribution will follow if the work is good. It does not need to be the main reason you ship, but it is allowed to be one of the reasons, and we are getting comfortable saying that out loud.

*Building autter in public. We block bad PRs at the merge gate, and apparently now we send our own email too. If your team is running into the same wall, drop us a line at [hi@autter.dev](mailto:hi@autter.dev) or book [30 minutes](https://cal.com/sagnik-autter/30min).*

*P.S. Tanvi read this draft and pointed out that I described the old ESP as a "black box" four times in eight paragraphs. She asked if I had a thesaurus. I said the thesaurus offered "opaque system," "closed-source platform," and "proprietary layer," none of which feel like what I meant. She said that is a writer problem, not a vendor problem. I am sitting with that.*

### See Autter on your own code.

A 30-minute walkthrough with the founders. Bring a repo and watch Autter review a live pull request.

[Book a demo](https://autter.dev/contact)

## Put an assurance layer on every release.

Autter reviews every pull request before it merges, backed by humans. Connect a repo and see your first findings today.

[Get started](https://app.autter.dev/login)

## Keep reading

[May 14, 2026 · 9 min read Why We Block the Merge Button Instead of Posting a Comment Every code review tool in the market posts comments. We block the merge. That one design decision changed how the entire product got built, what we sell, who we sell it to, and what the moat looks like.](https://autter.dev/blog/why-we-block-the-merge-button-instead-of-posting-a-comment) [Jun 22, 2026 · 5 min read We Open-Sourced the Tool We Use to Track AI-Generated Code Git says who committed a line, not who actually wrote it. We built Autter to track AI-generated code at the line level, and today the CLI is open source.](https://autter.dev/blog/we-open-sourced-the-tool-we-use-to-track-ai-generated-code)


---

---
title: Why We Block the Merge Button Instead of Posting a Comment - Autter Blog
description: Every code review tool in the market posts comments. We block the merge. That one design decision changed how the entire product got built, what we sell, who we sell it to, and what the moat looks like.
url: https://autter.dev/blog/why-we-block-the-merge-button-instead-of-posting-a-comment
date: 2026-05-14
author: Sagnik
tags: Code Review, Opinion, Product
reading_time: 9 min
site: Autter - Autter is the code security and assurance layer for the AI coding era: it checks every change before it merges, catches security risks, governs releases, and closes the loop from production failure to verified fix.
---

[← All posts](https://autter.dev/blog)

May 14, 2026

# Why We Block the Merge Button Instead of Posting a Comment

Every code review tool in the market posts comments. We block the merge. That one design decision changed how the entire product got built, what we sell, who we sell it to, and what the moat looks like.

Sagnik, Founder, autter.dev 9 min read

- Code Review
- Opinion
- Product

A founder I respect told me last month that Autter sounded "too aggressive." He was using a review tool that posted comments on his PRs, and his team had quietly stopped reading them. He was thinking of switching. He wanted to know if we could just leave a comment instead of blocking the merge.

I asked him how many bugs his current tool had caught in the last month.

He couldn't tell me.

That conversation is the entire blog post in three lines, but I'm going to write the rest anyway because the question keeps coming up and the answer matters more than people think.

Every code review tool in the market posts comments. We block the merge. That one design decision changed how the entire product got built, what we sell, who we sell it to, and what the moat looks like.

Comments are advice. Blocks are infrastructure.

This is not a stylistic difference. It is a category difference.

## Comments Are Where Good Intentions Go to Die

![Captain Patch watching a long thread of unread review comments scroll past on a PR while a developer reaches for the merge button anyway](https://autter.dev/blog/autter-confused-merge.webp)

*Captain Patch watching a long thread of unread review comments scroll past on a PR while a developer reaches for the merge button anyway.*

There's a category of software that I have started calling "well-intentioned advisory." Static analyzers that file warnings nobody triages. Linters that became opt-in. Security scanners that stopped failing builds and started filing tickets nobody reads. Code review bots that post forty inline comments on a 200-line diff and get muted in Slack within a week.

All of these tools were built by people who cared. None of them are doing the job they were built to do.

The pattern is always the same. Tool ships. Tool is strict by default. Developers complain. Tool is loosened. Loosened tool catches less. Catches less means fewer flagged issues. Fewer flagged issues means it stops feeling annoying. Stops feeling annoying means nobody complains. Nobody complains means nobody renews, because the tool has gradually optimized itself into the background.

> “A tool that nobody complains about is usually a tool that has stopped doing anything.”

Comments occupy this exact space. The default failure mode of a comment is to be scrolled past at 4:47pm on a Friday by an engineer who just wants to merge their PR before the weekend. The default failure mode of a block is that someone has to deal with it.

These are not the same product. They look like the same product on a marketing page. They are not.

## The Quiet Math of Comment Fatigue

![A vessel sailing into the harbour with small red flags posted along the route and nobody actually standing at the gate to stop it](https://autter.dev/blog/autter-sleeping.webp)

*A vessel sailing into the harbour with small red flags posted along the route and nobody actually standing at the gate to stop it.*

Pull up any large repo and look at PRs from the last 30 days. Count the inline comments left by automated tools. Now count how many of those comments resulted in a code change before merge.

The ratio is brutal. We have done this exercise with several teams as part of pilot conversations. The action rate on automated PR comments, in the codebases we have looked at, sits somewhere between 6 and 15 percent. The rest of the comments get marked resolved without a corresponding diff, get ignored entirely, or get a thumbs-up reaction and then nothing.

This is not a developer problem. This is a UX problem. When you put a comment in a PR thread, you are competing for attention with the actual review, with team chat, with whatever the developer was building before they opened the PR, and with the merge button two scrolls down. Comments lose that fight by default.

> “The action rate on automated PR comments sits between 6 and 15 percent. The rest is theatre.”

The tools know this. The tools have known this for years. The reason they keep posting comments instead of blocking is not because comments work better. It is because comments are a safer product decision. A comment cannot make anyone angry enough to churn. A block can. And so the entire category has converged on a UX pattern that protects the vendor's renewal rate at the expense of the customer's actual security posture.

This is the part nobody wants to say out loud. Advisory tools are designed to be ignorable. That is a feature for the vendor. It is a bug for the user.

Lesson

The default state of a comment is "ignored." The default state of a block is "addressed." Pick the default that matches the job you actually want done.

## What Blocking Actually Does

![Captain Patch standing in front of a glowing green merge button with arms crossed while a developer politely tries to walk around](https://autter.dev/blog/autter-with-dev.webp)

*Captain Patch standing in front of a glowing green merge button with arms crossed while a developer politely tries to walk around.*

Blocking does three things that commenting cannot do, and these three things are why we built the entire product around it.

It forces the conversation to happen now, when the context is still loaded. The window where a developer can quickly understand what their own code does is short. It closes the moment they tab over to something else. A comment that gets read three days later is a comment that gets read by someone who has to re-page in the entire change to make sense of it. A block that fires the second the PR is opened is read while the diff is still warm. The fix takes two minutes. The same fix three days later takes thirty.

It creates an actual decision moment. When you block a merge, somebody has to make a call. Either fix the issue or override the gate. Both of those actions are logged. Both leave a trail. The override path is intentional, traceable, and reviewable. The "I read the comment and decided to merge anyway" path looks identical in the git history to "I never read the comment in the first place." Blocking gives you accountability that commenting cannot, because there is no comparable mechanic to "ignored a comment."

It moves the pain to the right place. Catching a bad change at the merge button costs two minutes. Catching it in production three weeks later, after four other PRs have stacked on top of the bad one, costs a week. Every system has some drag in it somewhere. The question is where you decide to put it. Most teams put it at the worst possible spot, which is wherever the developer no longer remembers what they wrote.

> “The merge button is the cheapest place in the entire pipeline to push back.”

Blocking is the only one of these that meaningfully shifts behavior. The other two follow from it. Without the block, the conversation does not happen at the right time, and the decision does not leave a trail. With the block, both come for free.

## The Objection We Get the Most

The most reasonable pushback against blocking goes like this: "False positives are going to ruin our developer experience. One bad block and the whole team will hate the tool."

This is correct, and it is the entire reason we have spent disproportionate engineering time on suppression. False positive rate is not a metric we manage in a quarterly review. It is the only metric that matters. If a merge gate has a high false positive rate, it is worse than no merge gate at all, because it teaches the team to override blocks reflexively, and once that habit forms, the gate is functionally turned off.

This is also the answer to why a lot of incumbent tools chose comments over blocks in the first place. Comments are the safer product decision precisely because false positives in a comment are forgivable. False positives in a block are not. The bar to ship a blocking tool is significantly higher than the bar to ship a commenting tool, and most of the market quietly took the easier path.

We took the harder path because the easier path is a category that does not work.

False positive suppression in Autter is contributor-aware, repository-aware, and learns from override patterns. If your team has consistently overridden a particular class of finding because it is wrong in your context, that finding gets suppressed for that codebase. Not globally. For you. The tool gets quieter as it gets to know your team, not louder. This is the only way blocking can work as a long-term default.

Lesson

If you are going to block, you have to earn the right to block. False positive suppression is not a feature. It is the foundation under everything else.

## This Is Infrastructure, Not a Feature

![Captain Patch and Captain Scout looking at a wall covered in branch protection rules and contributor history charts that compound over time](https://autter.dev/blog/autter-looking-history.webp)

*Captain Patch and Captain Scout looking at a wall covered in branch protection rules and contributor history charts that compound over time.*

The deeper reason we block instead of comment is that blocking is the only mode that integrates with the existing governance layer of GitHub. Branch protection rules are blocking infrastructure. Required status checks are blocking infrastructure. CODEOWNERS is blocking infrastructure. The entire native vocabulary of "this code cannot ship until X" is built around enforcement, not advice.

A tool that lives in this layer compounds. Contributor patterns get learned. Repository-specific suppression lists grow. Migration risk profiles develop. The longer the tool runs, the better its judgment gets, because every override and every approved block becomes training signal for the next decision. This is the same reason GitHub itself becomes harder to leave the longer you use it. Your governance is captured in the platform, and the platform gets smarter about your team over time.

A tool that lives in the comment layer does not compound. Comments are stateless. The tool posts the same comments next month that it posted last month, because there is nowhere for the learning to live. Every PR is day one again.

> “Comments are stateless. Blocks compound.”

This is also why the merge gate is the right surface area for the next decade of code review, not the comment thread. The comment thread is a feed. Feeds do not have memory. The merge gate is a checkpoint. Checkpoints do.

The companies still shipping comment-based review tools are betting that the AI generation wave will be advisory. They are going to lose that bet. The volume of code generated by AI is going to keep climbing, the average reviewer is going to have less context per PR, and the only way to keep up is to move enforcement to the place where the decision is structurally captured. That place is the merge button.

## The Real Lesson

If you are evaluating code review tools right now, ask one question.

What does the tool actually do when it finds something wrong?

If the answer is "it tells you," that is an advisory tool. It will not change your team's behavior. It will not catch the bug that ships on a Friday afternoon. It will not survive the third quarterly cycle of "we are not seeing enough value."

If the answer is "it stops the merge," that is enforcement. That is infrastructure. That is the thing you actually wanted when you started looking for a code review tool in the first place.

We block the merge button because the merge button is the last point in the pipeline where the cost of being wrong is small. Every other intervention happens too late. Every advisory layer pretends to be that intervention without actually being it.

There is no version of code review that works without somebody, at some point, having the authority to say no. We built that somebody. It happens to be an otter.

*Building Autter in public. We're a merge gate that does not post a comment, does not file a ticket, and does not gently suggest you look at line 247. We block. If that sounds like the kind of layer your team has been quietly missing, drop us a line at [hi@autter.dev](mailto:hi@autter.dev) or book [30 minutes](https://cal.com/sagnik-autter/30min).*

*P.S. Tanvi read this draft and pointed out that I used the word "friction" seven times in one section. I argued that friction is the right word and there is no good synonym. She said drag, pain, resistance, and cost all work and that I was being lazy. I rewrote the section. The version you just read has fewer frictions in it. She is usually right about these things :/*

### See Autter on your own code.

A 30-minute walkthrough with the founders. Bring a repo and watch Autter review a live pull request.

[Book a demo](https://autter.dev/contact)

## Put an assurance layer on every release.

Autter reviews every pull request before it merges, backed by humans. Connect a repo and see your first findings today.

[Get started](https://app.autter.dev/login)

## Keep reading

[May 5, 2026 · 8 min read AI Reviewing Its Own Code Is a Conflict of Interest Every AI code generation company is shipping a review product. The author and the reviewer are the same engine with a different prompt. That is not a code review.](https://autter.dev/blog/ai-reviewing-its-own-code-is-a-conflict-of-interest) [May 23, 2026 · 13 min read What We Did When Our Email Stack Stopped Sending Our dashboards said delivered. Inboxes said nothing. Two months of quiet outbound later, we built Hedwig and email-checker and open sourced both.](https://autter.dev/blog/what-we-did-when-our-email-stack-stopped-sending)


---

---
title: AI Reviewing Its Own Code Is a Conflict of Interest - Autter Blog
description: Every AI code generation company is shipping a review product. The author and the reviewer are the same engine with a different prompt. That is not a code review.
url: https://autter.dev/blog/ai-reviewing-its-own-code-is-a-conflict-of-interest
date: 2026-05-05
author: Sagnik
tags: AI, Code Review, Opinion
reading_time: 8 min
site: Autter - Autter is the code security and assurance layer for the AI coding era: it checks every change before it merges, catches security risks, governs releases, and closes the loop from production failure to verified fix.
---

[← All posts](https://autter.dev/blog)

May 5, 2026

# AI Reviewing Its Own Code Is a Conflict of Interest

Every AI code generation company is shipping a review product. The author and the reviewer are the same engine with a different prompt. That is not a code review.

Sagnik, Founder, autter.dev 8 min read

- AI
- Code Review
- Opinion

Somebody asked me last week if Autter uses AI to review code. Yes. Obviously. Then they asked the next question, which is the better one.

"Isn't that the same thing the generation tools are doing now?"

No. And the difference matters more than anyone is being honest about.

There's a quiet pattern unfolding in developer tooling right now. Every AI code generation company is shipping a review product. Cursor has one. Copilot has one. Claude Code has one. The pitch is roughly the same across all of them: the same model that wrote your code can now check it before it ships.

This sounds reasonable until you say it out loud.

The author and the reviewer are the same engine with a different prompt.

We have a word for this in every other industry. We do not let auditors audit their own firms. We do not let pharma companies run their own clinical trials and publish the results. We do not let credit rating agencies grade the bonds they helped structure, and the one time we did, the global financial system fell over.

But somehow in software, we are watching the same model write the code, ship the code, and grade the code, and calling it a feature.

## The Structural Problem

![Captain Patch standing at the harbour gate looking suspiciously at a vessel that's also wearing the harbour master uniform](https://autter.dev/blog/clone-patch.webp)

*Captain Patch standing at the harbour gate looking suspiciously at a vessel that's also wearing the harbour master uniform.*

A model trained to produce confident, plausible code is the worst possible reviewer for code that is confident and plausible but wrong.

The failure modes of the generator are the blind spots of the reviewer. They were trained on the same data. They share the same priors. They have the same instinct for what "looks right." If a model is going to hallucinate a function call, it will also fail to flag that hallucinated function call when it sees it again, because nothing inside that model is set up to disagree with itself.

This is not a tuning problem. You cannot prompt your way out of a shared epistemology.

The whole point of code review is adversarial. A second pair of eyes that does not share your assumptions, did not write the thing, has no ego attached to the diff, and is willing to push back. When the second reviewer is just the first author wearing a different hat, you have not added a check. You have added a rubber stamp with extra latency.

> “A second pair of eyes that shares your assumptions is not a second pair of eyes.”

There's a deeper version of this. Models are increasingly trained on synthetic data, which often includes outputs from other models. The reviewer model has, in some part, been trained on code that looks exactly like what the generator would produce. Of course it thinks the code looks fine. It thinks the code looks fine because it has seen a million versions of code that looks fine, and most of that code came from somewhere structurally identical to where the new code is coming from.

You are not getting an independent opinion. You are getting the same opinion in a different font.

Lesson

The author and the reviewer cannot be the same intelligence, full stop. If the only thing changing between the two passes is the system prompt, you do not have a review. You have a vibe check.

## The Economic Problem

![Captain Patch holding a clipboard while Captain Scout points at a tilted scale labeled 'ship more' on one side and 'block more' on the other](https://autter.dev/blog/captains-ship-more.webp)

*Captain Patch holding a clipboard while Captain Scout points at a tilted scale labeled 'ship more' on one side and 'block more' on the other.*

The structural problem is the cleaner argument. The economic one is the messier and more important one.

Generation tools live and die on usage. Their pricing depends on tokens generated, lines suggested, completions accepted. Their growth depends on developers feeling like the tool is shipping their work for them. Friction is the enemy of conversion. Friction is the enemy of the metric that justifies the next round.

Now imagine you bolt a review layer onto that same product.

What does that review layer want to do?

In theory, it wants to block bad code. In practice, every block is friction. Every false positive is a developer pausing, getting annoyed, and considering whether they want this tool in their workflow at all. The product team running the review feature reports to the same exec running the generation feature. The generation feature is the revenue. The review feature is, at best, a retention play. At worst, it is a cost center that slows down the feature paying everyone's salaries.

Guess which one wins when those two priorities collide.

This is not theoretical. We have seen it already in adjacent categories. Static analysis tools that started strict and got friendlier over time because nobody was upgrading. Linters that became opt-in. Security scanners that quietly stopped failing builds and started filing tickets nobody read. The market punishes friction. The pressure on a review layer that lives inside a generation product is to slowly, quietly, become a suggestion layer. And then a comment layer. And then a feature on a slide that nobody actually runs.

> “The market punishes friction. A review layer that costs the parent product conversion will be tuned friendlier until it stops costing it conversion.”

The incentive gradient is one direction. Toward leniency. Toward suggestions. Toward not blocking the merge.

That is not a code review. That is a feature designed to look like one for as long as it is politically convenient.

Lesson

If your reviewer and your author are owned by the same business, the reviewer is going to lose every quarterly review meeting. Not because anyone is malicious. Because of how incentives compound when nobody is watching.

## Why Independent Enforcement Wins

![Captain Patch standing at the harbour gate while a row of vessels from different shipyards line up, each waiting for clearance](https://autter.dev/blog/harbour-check-gate.webp)

*Captain Patch standing at the harbour gate while a row of vessels from different shipyards line up, each waiting for clearance.*

The category that scales here is not better in-house review from generation vendors. It is independent enforcement.

Three things have to be true for a review layer to actually work in the AI era.

The reviewer cannot be financially incentivized to ship more code. Its business model has to be independent of the volume of code that gets through. Ideally, it should be incentivized to block code that is wrong, not wave code that is plausible.

The reviewer cannot share the model that wrote the code. Different training data, different priors, different failure modes. You want diversity in the stack the same way you want diversity in a code review panel.

The reviewer has to be able to actually block. Not file a comment. Not open an issue. Not suggest a change in a thread that gets ignored at 4:47pm on a Friday. Block. Sit on the merge button and refuse to move until the issue is resolved.

This is what we mean when we say merge gate, not advisory layer. The whole product category is the difference between a tool that has the authority to say no and a tool that posts a polite suggestion that everyone scrolls past.

> “Block. Sit on the merge button. Refuse to move until the issue is resolved.”

Generation will keep commoditizing. Copilot to Cursor to Claude Code in roughly nine to eighteen month cycles. Whichever one is winning today is not the one winning two years from now. That's fine. That market should commoditize. Generation is becoming a feature of the IDE, then a feature of the OS, then a utility.

Governance does not commoditize the same way.

Branch protection rules, contributor history, blast radius patterns, migration risk profiles, false positive suppression that learned from your team's last six months of reviews. These compound. They compound across vendors. They compound across model generations. The value of a governance layer six months in is significantly higher than the value of the same governance layer on day one, and the value of any individual generation model six months in is roughly half of what it was at launch.

The moat is in the layer above generation, not inside it.

Lesson

Generation is the commodity. Governance is the compounding asset. The companies that confuse those two will be re-platforming every eighteen months.

## The Honest Version

![Captain Patch sitting at a small table with two cups of coffee, having an argument that looks affectionate](https://autter.dev/blog/patch-with-tea.webp)

*Captain Patch sitting at a small table with two cups of coffee, having an argument that looks affectionate.*

I want to be honest about where this argument can be pushed back on.

Yes, Autter uses AI to review code. We are not pretending otherwise. The argument is not "AI cannot review AI." The argument is that the reviewing AI cannot be the same AI, owned by the same company, optimizing for the same metric, as the generating AI.

We are model-agnostic. The model that ran your last review is not the model that wrote your code. We do not sell code generation. We do not have a Cursor competitor sitting in the next office over influencing how strict our defaults should be next quarter. Our entire business depends on us blocking the right things and not blocking the wrong things. If we get loose, we lose. If we get noisy, we lose. The incentive points the right direction.

That is not a feature. That is a structural fact about being an independent layer.

The companies bundling review into their generation products will keep telling you it's the same thing. It is not. Watch which incentives bend over the next eighteen months. You will see it.

## The Real Lesson

The conversation we should be having in the industry is not "is AI good at code review." That question is settled enough. AI can do parts of code review well, and parts of it badly, and the engineering is going to keep getting better.

The conversation we should actually be having is who owns the reviewer.

If your code review layer is owned by the company that wrote the code, you are not running a review process. You are running a marketing channel for the generation product. It will work fine until the moment it doesn't, and the moment it doesn't will be the production incident you cannot explain in the postmortem.

The merge button is the most consequential decision in modern software. Who gets to press it, when, and under what conditions, is governance. It does not belong to a feature flag in someone's IDE plugin.

It belongs at the gate.

*Building Autter in public. We're a merge gate that does not write your code, does not sell you a model, and does not have a quarterly metric that depends on shipping more diffs. We just decide what clears the harbour. If that sounds like the kind of layer your team has been quietly missing, drop us a line at [hi@autter.dev](mailto:hi@autter.dev) or book [30 minutes](https://cal.com/sagnik-autter/30min).*

*P.S. Tanvi read this draft and said the only thing more predictable than an AI reviewing its own code is me writing a 2000 word blog about it. She also said to publish it anyway because being predictable is fine when you're predictably right. I am choosing to take that as the compliment it almost was.*

### See Autter on your own code.

A 30-minute walkthrough with the founders. Bring a repo and watch Autter review a live pull request.

[Book a demo](https://autter.dev/contact)

## Put an assurance layer on every release.

Autter reviews every pull request before it merges, backed by humans. Connect a repo and see your first findings today.

[Get started](https://app.autter.dev/login)

## Keep reading

[Apr 28, 2026 · 7 min read Day 1 of a Startup: A Product, No Users, and Infinite Anxiety Launching a startup feels less like firing a rocket and more like pushing a paper boat into a river and then sprinting alongside the bank hoping it doesn't sink.](https://autter.dev/blog/day-1-of-a-startup) [May 14, 2026 · 9 min read Why We Block the Merge Button Instead of Posting a Comment Every code review tool in the market posts comments. We block the merge. That one design decision changed how the entire product got built, what we sell, who we sell it to, and what the moat looks like.](https://autter.dev/blog/why-we-block-the-merge-button-instead-of-posting-a-comment)


---

---
title: Day 1 of a Startup: A Product, No Users, and Infinite Anxiety - Autter Blog
description: Launching a startup feels less like firing a rocket and more like pushing a paper boat into a river and then sprinting alongside the bank hoping it doesn't sink.
url: https://autter.dev/blog/day-1-of-a-startup
date: 2026-04-28
author: Sagnik
tags: Story, Startup, Lessons
reading_time: 7 min
site: Autter - Autter is the code security and assurance layer for the AI coding era: it checks every change before it merges, catches security risks, governs releases, and closes the loop from production failure to verified fix.
---

[← All posts](https://autter.dev/blog)

Apr 28, 2026

# Day 1 of a Startup: A Product, No Users, and Infinite Anxiety

Launching a startup feels less like firing a rocket and more like pushing a paper boat into a river and then sprinting alongside the bank hoping it doesn't sink.

Sagnik, Founder, autter.dev 7 min read

- Story
- Startup
- Lessons

Launching a startup feels less like firing a rocket and more like pushing a paper boat into a river and then sprinting alongside the bank hoping it doesn't sink.

That sentence is the entire emotional shape of the last month, and I am going to spend the rest of this post unpacking what it actually looked like in practice.

We launched Autter last month. By "launched" I mean we put up a website, told some people we knew, and waited to see what happened. No press. No Product Hunt. No Show HN. Just a URL, a waitlist form, and the particular anxiety that lives somewhere between "what if nobody comes" and "what if somebody does."

This is the second post in the *Learnings from Building Autter* series. The first was about names. This one is about the day the doors opened.

Here is what actually happened.

## What We Did

We did not have a working product on day one. We had a GitHub App skeleton, a landing page, and a lot of conviction that the problem we were solving was real. The first thing Autter could actually produce was a manual codebase scan. Someone connects their repo, we run the scan internally, and send them a findings email with what we caught. No automation. No dashboard magic. Just us, the scanner, and a carefully written email.

Concierge delivery. Embarrassingly manual. We shipped it anyway because we needed something real to put in front of people, and a live product beats a perfect prototype that does not exist yet.

> “A live product, however manual, beats a perfect prototype that does not exist yet.”

On the business side, I wanted to run an OOH campaign. Physical posters. Tanvi had thoughts about this. I ignored her thoughts and did it anyway. The waitlist picked up signups faster than either of us expected, from people we would never have reached through any channel we were already using.

We also started reaching out to people who have supported us over time and given us thoughtful, constructive feedback along the way. Not cold outreach. No spray and pray. Just an honest note: here is what we are building, want to be among the first to run a scan? That list is where our first real conversations came from. Not algorithms. People.

Lesson

Day 1 is not about reach. It is about the first ten conversations being with people who will tell you the truth.

## Three Things That Worked

![Captain Patch giving a thumbs up while sitting in a deck chair, looking relaxed for once](https://autter.dev/blog/lesson-2-thumbsup.webp)

*Three things landed harder than expected.*

**Being specific about what makes Autter different.**

Not "AI code review" as a broad category. Specifically: Autter blocks the merge. It does not post a comment suggesting you look at something. It does not leave a note in the thread. It holds the gate until the conditions are met.

That single framing landed differently in every conversation we had. People stopped nodding politely and started leaning forward. There is a difference between a product that waves a flag and one that actually stands in the doorway, and that difference shows up in the first thirty seconds of a sales call.

**The manual scan delivery.**

We expected people to be put off by the friction. Instead, the findings emails got real replies. People forwarded them internally. Engineering leads were being looped in on the thread. One person replied with three follow-up questions and asked what our pricing looked like.

The manual step turned out to be the best demo we had, because it forced us to write findings in plain English and actually explain what we caught and why it mattered. Automation would have made the output more efficient and significantly less convincing.

> “The manual step turned out to be the best demo we had, because it forced us to explain what we caught and why it mattered.”

**The OOH campaign.**

We still do not fully understand why it worked as well as it did. The instinct when you are building a developer tool is to go where developers are online. Forums, Twitter, Hacker News. The OOH campaign went somewhere physical and completely different and it drove real waitlist signups from people we would never have touched otherwise.

I am not sure we can fully replicate it. It earned its budget. That is enough information for now.

Lesson

The thing that worked is rarely the thing the playbook said would work. Run the experiment, measure the result, do not over-rationalize the outcome.

## Two Embarrassing Wastes of Time

![Captain Patch with one hand on his head, looking at his watch, mildly disappointed in himself](https://autter.dev/blog/lesson-2-stressed.webp)

*Two weeks I would like back.*

**The dashboard nobody asked for.**

We spent almost a full week polishing the dashboard UI before we had a single user to show it to. The reasoning at the time was that we wanted to be ready when people started signing up.

The honest version is that building UI felt like progress and it was easier than talking to people who might say no. Nobody asked for the dashboard. Nobody knew the dashboard existed. We were building for an audience of zero.

> “Building UI felt like progress because it was easier than talking to people who might say no. That is the trap.”

**The generic explainer post that went nowhere.**

We tried to write an "AI-generated code is a growing security risk" explainer and pitch it to a few developer publications. It went nowhere. The piece was too broad, too obviously written by a startup trying to establish credibility before it had earned any, and it had nothing specific in it that only we could say.

Every paragraph could have been written by any company in this space. We killed it before it published, which was the right call. Two weeks too late, but the right call.

Lesson

If a paragraph could have been written by any of your competitors, it should not have been written by you.

## Where We Are Now

The product is live. The scan pipeline is automated. Connect your repo, Autter runs, and you get your findings. No waiting on us. No email threads. No concierge nonsense.

We are looking for ten founding scan users. Teams who are actively nervous about what AI-generated code is doing to their codebase and want a serious look before the next merge.

If that is you, connect at [autter.dev](https://autter.dev).

## The Real Lesson

Day 1 of a startup is not the launch. The launch is a moment. Day 1 is everything you find out about your product, your positioning, and yourself in the four weeks after the launch.

We found out that specificity beats category. We found out that a manual product can land harder than an automated one if the manual version forces you to be honest about what it does. We found out that an OOH campaign can outperform every developer marketing channel we already know how to run, for reasons we still cannot fully explain.

We also found out that polishing a dashboard for an audience of zero is the most comfortable form of procrastination available to a technical founder, and that writing a generic post is the second most comfortable.

The product is the product. The waitlist is real. The first ten users are the next thing. Everything else is content.

## We are opening early beta scans. Free.

We are running free codebase scans for early-stage startups right now. The scan is now fully automated. Connect your repo, the pipeline runs, you get a report. No queue. No batch. No waiting on us to find time in our day.

**Fully blackboxed. We never touch your code.**

The scan runs inside an isolated, ephemeral sandbox. Your code is never transmitted to us, stored on our infrastructure, or accessible to anyone on the autter team. The scanner executes, produces findings, and the environment is destroyed. What you get is a report. Not a relationship where someone at a startup has read your codebase.

This is not a footnote. For most of the teams we spoke to, it was the deciding factor.

No sales call required. No commitment after. If you want to talk through the findings, there is a link below to book 30 minutes. If you just want the report, that works too.

Get your free scan

[autter.dev](https://autter.dev) · [Book 30 minutes](https://autter.dev/contact/sales)

![Autter near that telephone](https://autter.dev/blog/scanned-1.webp)

*Autter near that telephone*

*Building Autter in public. We are an enforcement-first merge gate that does not write your code, does not sell you a model, and does not have a quarterly metric that depends on shipping more diffs. We just decide what clears the harbour. If you want to be a founding scan user, connect at [autter.dev](https://autter.dev) or drop us a line at [hi@autter.dev](mailto:hi@autter.dev).*

*P.S. Tanvi wants me to clarify that she had serious reservations about the OOH campaign and that I ran it anyway. She is correct. It worked. She has not fully forgiven me for being right about this. Tanvi did not approve of this P.S.*

### See Autter on your own code.

A 30-minute walkthrough with the founders. Bring a repo and watch Autter review a live pull request.

[Book a demo](https://autter.dev/contact)

## Put an assurance layer on every release.

Autter reviews every pull request before it merges, backed by humans. Connect a repo and see your first findings today.

[Get started](https://app.autter.dev/login)

## Keep reading

[Apr 10, 2026 · 5 min read We scanned 10 startup codebases. Here's what we found. Over the past few weeks, we ran manual codebase scans for 10 early-stage startups. Nine out of ten had at least one high-severity finding.](https://autter.dev/blog/we-scanned-10-startup-codebases) [May 5, 2026 · 8 min read AI Reviewing Its Own Code Is a Conflict of Interest Every AI code generation company is shipping a review product. The author and the reviewer are the same engine with a different prompt. That is not a code review.](https://autter.dev/blog/ai-reviewing-its-own-code-is-a-conflict-of-interest)


---

---
title: We scanned 10 startup codebases. Here's what we found. - Autter Blog
description: Over the past few weeks, we ran manual codebase scans for 10 early-stage startups. Nine out of ten had at least one high-severity finding.
url: https://autter.dev/blog/we-scanned-10-startup-codebases
date: 2026-04-10
author: Sagnik
tags: Security, Startups, Code Review
reading_time: 5 min
site: Autter - Autter is the code security and assurance layer for the AI coding era: it checks every change before it merges, catches security risks, governs releases, and closes the loop from production failure to verified fix.
---

[← All posts](https://autter.dev/blog)

Apr 10, 2026

# We scanned 10 startup codebases. Here's what we found.

Over the past few weeks, we ran manual codebase scans for 10 early-stage startups. Nine out of ten had at least one high-severity finding.

Sagnik, Founder, autter.dev 5 min read

- Security
- Startups
- Code Review

Over the past few weeks, we ran manual codebase scans for 10 early-stage startups. All voluntarily. All anonymized below. The deal was simple: connect your repo, our scanner runs in an isolated sandbox, you get a findings report. We never see your code. No sales pitch attached.

We were not looking for everything. We were looking for the things that actually blow up in production. The things a fast-moving team with AI-assisted PRs would miss because the reviewer was tired, or because the reviewer was also the author, or because there was no reviewer at all.

Here is what we found.

## By the numbers

- **9/10**: codebases had at least one high-severity finding
- **6/10**: had a secret that had already touched a production branch
- **8/10**: had a dependency with a known critical CVE
- **7/10**: had at least one migration that could not be cleanly rolled back

## Finding 01: Leaked secrets in production branches

Six out of ten. That is the number that surprised us most. These were not secrets buried in an old feature branch. They were in main. A few were in commit history that had been squash-merged and forgotten. One was a live Stripe secret key that had been rotated but not removed from the repo.

Anonymized case / Startup B

An AWS access key was committed directly in a config file during an environment migration two months prior. The key was still active. The finding was surfaced in our report. The team rotated it within the hour.

The pattern we see most often: a developer hardcodes a key locally to test something quickly, then that file gets staged, committed, and pushed in a batch commit at 11pm. The PR looks fine. Nobody checks the diff on config files carefully.

```
# what we actually found, paraphrased
STRIPE_SECRET_KEY=sk_live_4xR9...redacted    # committed 47 days ago
AWS_ACCESS_KEY_ID=AKIA...redacted             # committed 61 days ago
DATABASE_URL=postgres://admin:p4ss...redacted # still in HEAD
```

None of these would have been caught by a standard linter. They were caught by a scan that was specifically looking for them.

## Finding 02: Vulnerable dependencies nobody noticed

Eight out of ten codebases had at least one dependency flagged with a critical CVE. The average time since the vulnerability was published: 94 days. The average number of PRs merged into the codebase in that window: 38.

The dependency that came up most often was a JSON parsing library used as a transitive dependency three layers deep. Nobody installed it directly. It showed up because something else pulled it in. It had a known prototype pollution vulnerability. It was easy to miss and easy to fix once you knew it was there.

Anonymized case / Startup F

A critical RCE vulnerability in a serialization library had been in their dependency tree for 4 months. It was introduced when they upgraded a completely unrelated package. Their CI ran tests. Everything passed. The vulnerability was unrelated to any test they had written.

The problem is not that teams are careless. The problem is that dependency trees are opaque and most review workflows do not have a dedicated step for checking what changed below the surface.

## Finding 03: Schema drift and migration risk

Seven out of ten had at least one migration that we flagged as non-reversible without data loss. Three of those had already been applied to a staging database that shared the same schema as production.

Anonymized case / Startup D

A NOT NULL constraint was added to an existing column via a migration that had no corresponding backfill step. The migration ran fine against an empty staging database. Against a production table with 180,000 rows, it would have failed mid-flight. The rollback would have left the schema in a partially applied state.

Schema drift is the category where we see the clearest gap between what teams think is safe and what actually is. Most teams that write careful application code write fast migrations. The migration is an afterthought. It ships in the same PR as the feature.

> “The migration ran fine in staging. It would have failed against 180,000 rows. The rollback would not have been clean.”

## Finding 04: Unsafe merges from AI-generated code

This one was harder to quantify, so we are being careful with the number. In five out of ten codebases, we found code patterns consistent with AI generation that had been merged without substantive review. Not because the teams were sloppy. Because the code looked fine on the surface and the PR was small.

What we actually flagged in this category: logic that handled the happy path correctly but had no error boundary for an obvious edge case. Input validation that was present in the UI layer but absent in the API route. Auth checks that existed on the route but not on a background job that hit the same data.

Anonymized case / Startup H

A Copilot-generated API handler correctly validated the request body. It did not validate the source of the request. Any authenticated user could trigger a job scoped to another user's data. The code looked correct. The logic was wrong.

This is the blast radius problem. A single unsafe merge is not usually catastrophic on its own. It is catastrophic when it is in a path that touches billing, user data, or access control.

## What this tells us

![Autter blocking merge](https://autter.dev/blog/scanned-3.webp)

*Autter blocking merge*

These are not bad engineering teams. Most of them are moving fast with small crews, using AI tooling to ship faster, which is rational. The problem is that the generation tools and the review layer are not independent. The same model that wrote the code is, at best, being asked to review a diff of the code. That is not a review. That is a spell-check.

What these codebases needed was not more suggestions. They needed something to block the merge until the finding was resolved. That is what we are building.

## We are opening early beta scans. Free.

We are running free codebase scans for early-stage startups right now. The scan is now fully automated. Connect your repo, the pipeline runs, you get a report. No queue. No batch. No waiting on us to find time in our day.

**Fully blackboxed. We never touch your code.**

The scan runs inside an isolated, ephemeral sandbox. Your code is never transmitted to us, stored on our infrastructure, or accessible to anyone on the autter team. The scanner executes, produces findings, and the environment is destroyed. What you get is a report. Not a relationship where someone at a startup has read your codebase.

This is not a footnote. For most of the teams we spoke to, it was the deciding factor.

No sales call required. No commitment after. If you want to talk through the findings, there is a link below to book 30 minutes. If you just want the report, that works too.

Get your free scan

[autter.dev](https://autter.dev) · [Book 30 minutes](https://autter.dev/contact/sales)

![Autter near that telephone](https://autter.dev/blog/scanned-1.webp)

*Autter near that telephone*

*P.S. Tanvi reviewed this post before it went out and said the stat on AI-generated code was "too soft and needs a harder number." She is right. We are working on that. For now, five out of ten is what we can stand behind without overfitting to a pattern. We will publish the harder number when we have it.*

### See Autter on your own code.

A 30-minute walkthrough with the founders. Bring a repo and watch Autter review a live pull request.

[Book a demo](https://autter.dev/contact)

## Put an assurance layer on every release.

Autter reviews every pull request before it merges, backed by humans. Connect a repo and see your first findings today.

[Get started](https://app.autter.dev/login)

## Keep reading

[Apr 8, 2026 · 7 min read We Spent 3 Weeks Fighting About Names Naming a startup is probably not the most important thing you'll do. But get it wrong and you'll pay for it quietly, in every intro, every cold email, every 'wait, how do you spell that?' on a call.](https://autter.dev/blog/spent-3-weeks-fighting-names) [Apr 28, 2026 · 7 min read Day 1 of a Startup: A Product, No Users, and Infinite Anxiety Launching a startup feels less like firing a rocket and more like pushing a paper boat into a river and then sprinting alongside the bank hoping it doesn't sink.](https://autter.dev/blog/day-1-of-a-startup)


---

---
title: We Spent 3 Weeks Fighting About Names - Autter Blog
description: Naming a startup is probably not the most important thing you'll do. But get it wrong and you'll pay for it quietly, in every intro, every cold email, every 'wait, how do you spell that?' on a call.
url: https://autter.dev/blog/spent-3-weeks-fighting-names
date: 2026-04-08
author: Sagnik
tags: Story, Branding, Startup
reading_time: 7 min
site: Autter - Autter is the code security and assurance layer for the AI coding era: it checks every change before it merges, catches security risks, governs releases, and closes the loop from production failure to verified fix.
---

[← All posts](https://autter.dev/blog)

Apr 8, 2026

# We Spent 3 Weeks Fighting About Names

Naming a startup is probably not the most important thing you'll do. But get it wrong and you'll pay for it quietly, in every intro, every cold email, every 'wait, how do you spell that?' on a call.

Sagnik, Founder, autter.dev 7 min read

- Story
- Branding
- Startup

We were Shipgate first.

Then we weren't.

Then we were something else for about four days. Then that domain was taken. Then we almost settled on something that sounded like a SaaS accounting tool. Then Tanvi said no. Then I said no to her suggestion. Then we both sat quietly for a bit.

Three weeks. That's how long naming Autter actually took.

And here's the honest take before I get into any of it: naming is probably not the most important thing you'll do as a founder. The product is. The people are. Whether anyone actually needs what you're building is. A great name with a bad product is just a fast way to build a recognizable failure.

But.

A bad name will cost you. Quietly. Consistently. In every intro, every cold email, every "wait, how do you spell that?" on a call. So while it's not the hill to die on, it's worth getting somewhat right.

Here's what we learned doing it.

## Start With the Category, Not the Brand

The first mistake most founders make is going straight for "what sounds cool." We did this too.

![Captain Patch and Captain Scout discussing an early product name that sounds cool but stays category-adjacent](https://autter.dev/blog/lesson-1-3.webp)

*The trap we fell into first: a name that felt energetic in the workflow diagram but never said what the gate was for.*

Shipgate was the first serious contender. It had energy. It sounded like it belonged in a developer workflow. Ship, gate, it practically described the product. We were building a merge gate for AI-assisted code. Felt clean.

But we kept hitting a wall.

"Shipgate" was category-adjacent, not category-defining. It told you something happened at the gate. It didn't tell you what the gate did or why you'd want one. For a product in a genuinely new space, that's a problem. You're already asking people to believe in a category that doesn't fully exist yet. Your name can't add more cognitive load on top of that.

> “The framing that unlocked everything was the harbour.”

The framing that unlocked everything was the harbour.

Autter is built around the idea of a harbour master. The person who decides what comes in, what goes out, and what's not ready yet. Runtime-aware, security-aware, schema-aware. A judgement layer, not just a check. Once we had that framing locked, we needed a name that lived inside that world without screaming "nautical startup."

Autter. The outer harbour. The boundary before you're inside.

It also came from “Auditing Otter”, which was the dumb internal phrase we kept using while we were building an auditing layer for merges.

The otter part mattered too. Otters are obsessive. They pry things open. They hold onto what they care about and they do not let go. That was the vibe we wanted: a little guard animal that sits on your PRs, checks what changed, and refuses to wave you through.

“Auditing” plus “otter” became Autter. It stuck just enough to become the name.

It fit. Not because it was clever. Because it was accurate.

Lesson

Name the judgment, not the action. If your product enforces something, protects something, or decides something, find a name that carries that weight. Not just what it does, but why it matters.

## Domain Availability Will Humble You

We had a shortlist of eight names at one point. Good names. Names we'd actually use.

Six of them were taken. Two of the remaining had .com parked by domain squatters asking for mid-five figures.

This is normal. This is also annoying.

What changed our shortlist entirely was deciding early that we'd go .dev over .com. Not as a compromise. As a deliberate call.

.dev is a gTLD that Google owns. It's HTTPS-only by default. More importantly, it signals something to the audience we care about: developers. When you see a .dev domain, you're not thinking consumer app. You're thinking tool, API, infrastructure, something built for people who build things. That's exactly where we want to live.

Once we committed to .dev, the shortlist opened up. Names that would've been dead ends on .com were clean on .dev. Autter.dev was available. We registered it the same day.

Lesson

Pick your extension before you pick your name. .dev, .io, .so, .ai, they’re not all equal and they’re not just fallbacks. They carry meaning. Let that filter your options early rather than discovering it late.

![Captain Patch and Captain Scout reacting to a wall of taken domains and parked .com prices](https://autter.dev/blog/lesson-1-1.webp)

*Eight names on the shortlist, most of them dead on arrival. Committing to .dev early rewrote what was even possible.*

## Memorability Is a Function of Friction

We tested names by doing one thing: saying them in a sentence out loud.

"Check out what we're building at ______."

If there was any pause after that blank, any moment where the other person had to process the spelling or the pronunciation, we killed it.

> “A name that needs explaining has already failed its first job.”

A name that needs explaining has already failed its first job.

Autter has one point of confusion: the double-T. People occasionally write "Outer." We've made peace with that. The trade-off is worth it because once someone has it, they have it. Two syllables, phonetic, no ambiguity on how to say it. In a pitch, on a call, in a Slack message, it holds up.

We also ran a basic searchability test. Google the name. Google it with "startup." Google it with the product category. If the results are full of noise or completely unrelated things, that's a discoverability problem you'll be fighting for years.

Lesson

Test names in conversation first, spreadsheets second. Gut feel in a real sentence beats any naming framework.

## What Almost Made the Cut (And Why It Didn't)

A few names that got real consideration before we landed:

**Portgate**: Too on-the-nose. Also sounded like a political scandal.

**Gatekeeper**: Already everywhere. Zero differentiation.

**Mergelock**: Tanvi hated it. She was right.

**Conduit**: We liked it. The .dev was taken. End of story.

**Harbour**: Beautiful word, terrible searchability. Try ranking for that.

**Vessel**: Almost. But it felt more like a data tool than an enforcement layer. Didn't survive the "what does this do?" test.

Every name that made the shortlist was killed by one of three things: domain issues, category mismatch, or the sentence test. If you're naming right now, those are your three filters.

![Captain Patch and Captain Scout debating names (descriptive versus story-driven) at a whiteboard](https://autter.dev/blog/lesson-1-2.webp)

*The fights that sounded like taste were really about whether we were a tool on a diagram or a story that reframed how people think about the merge queue.*

**The debates on the name were actually about something else:** They weren’t really about the name. They were about how we saw the product.

I kept pushing for names that explained the product - that’s what developers like, keeping things simple. Names like Shipgate, Mergelock, anything that felt like it could sit inside a developer’s work flow diagram and immediately make sense.

Whereas, Tanvi kept pushing for names that would change a developer’s pov on these tools. A name with a story, a name with an emotion, a name that would kindle curiosity.

There was a phase where every suggestion from one got an immediate no from the other. Not even a discussion. Just instinct. And that was frustrating.

But looking back, that friction was useful.

Because every time a name got rejected, it gave us answers to the layers of building a product:

- Are we just a tool or a companion-tool?
- Are we descriptive or abstract?
- Do we want to sound serious or slightly playful?

We didn’t have aligned answers to those questions in week one.

By week three, we did. We had a story. We had a mascot. The name came after that.

## The Real Lesson

Three weeks feels long. It also feels like a lot given how much else was happening during that time, early product work, first investor conversations, figuring out how Tanvi and I were dividing the build.

But naming forced us to get precise about what we were building. Not in a deck. In a word.

What is the single thing this product does? What's the one idea someone should walk away with?

For us, the answer was judgment. A harbour master for your merge queue.

The name came from that. Not the other way around.

> “Stop picking names. Go back to the product. Get the one-sentence answer right first.”

So if you're three weeks into a naming spiral and nothing is clicking, stop picking names. Go back to the product. Get the one-sentence answer right first. The name is just a shortcut to that sentence. Once the sentence is clear, the name finds you faster than you'd expect.

We shipped Autter. We like the name. We still think the product matters more.

But we're glad we got the name right enough.

*Building Autter in public. If you're an early-stage team shipping code with AI tools and want a merge gate that actually understands what's happening at runtime, we'd love to talk. Drop us a line at [hi@autter.dev](mailto:hi@autter.dev) or book [30 minutes](https://cal.com/sagnik-autter/30min).*

### See Autter on your own code.

A 30-minute walkthrough with the founders. Bring a repo and watch Autter review a live pull request.

[Book a demo](https://autter.dev/contact)

## Put an assurance layer on every release.

Autter reviews every pull request before it merges, backed by humans. Connect a repo and see your first findings today.

[Get started](https://app.autter.dev/login)

## Keep reading

[Mar 28, 2026 · 5 min read Catching AI-Generated Code Before It Ships How engineering teams use autter to detect subtle issues in AI-authored pull requests that pass CI but fail in production.](https://autter.dev/blog/ai-generated-code-review) [Apr 10, 2026 · 5 min read We scanned 10 startup codebases. Here's what we found. Over the past few weeks, we ran manual codebase scans for 10 early-stage startups. Nine out of ten had at least one high-severity finding.](https://autter.dev/blog/we-scanned-10-startup-codebases)


---

---
title: Catching AI-Generated Code Before It Ships - Autter Blog
description: How engineering teams use autter to detect subtle issues in AI-authored pull requests that pass CI but fail in production.
url: https://autter.dev/blog/ai-generated-code-review
date: 2026-03-28
author: Sagnik
tags: Code Quality, AI Safety, Code Review, Automation
reading_time: 5 min
site: Autter - Autter is the code security and assurance layer for the AI coding era: it checks every change before it merges, catches security risks, governs releases, and closes the loop from production failure to verified fix.
---

[← All posts](https://autter.dev/blog)

Mar 28, 2026

# Catching AI-Generated Code Before It Ships

How engineering teams use autter to detect subtle issues in AI-authored pull requests that pass CI but fail in production.

Sagnik, Founder, autter.dev 5 min read

- Code Quality
- AI Safety
- Code Review
- Automation

AI coding assistants now generate somewhere between 30% and 60% of the code in a typical pull request. The code compiles. The tests pass. The logic reads cleanly. And yet production incidents from AI-authored code are climbing — not because the code is obviously broken, but because it is confidently wrong in ways that only surface under real load, with real data, at the worst possible moment.

This is the gap autter was built to close.

## The shape of the problem

When a human writes a bug, it usually looks like a bug. A missing null check, an off-by-one error, a typo in a variable name. These are the kinds of issues that linters, type checkers, and CI pipelines were designed to catch — and they do catch them, reliably.

AI-generated code fails differently. It produces code that is syntactically perfect, logically coherent, and structurally sound — but semantically wrong in context. The failure modes are subtle:

- **Convention violations** — the AI doesn't know your team deprecated `moment` in favour of `date-fns` last quarter, or that `getUserById` should never be called inside a loop because your ORM doesn't batch
- **Implicit contract breaches** — a function that returns the right type but violates an unwritten invariant, like returning stale cache data where freshness is critical
- **Performance anti-patterns** — N+1 queries hidden inside helper functions that look clean in isolation but collapse under production cardinality
- **Security blind spots** — input validation that covers happy paths but misses edge cases like unicode normalisation attacks or timing-based side channels

Traditional CI catches none of these. Static analysis catches some. Human review catches more — but only when the reviewer has enough context, enough time, and enough suspicion to look closely at code that reads perfectly.

## How autter addresses this

autter operates at the merge layer — after CI passes, before code reaches your main branch. It analyses every pull request with full awareness of your codebase's history, conventions, and architecture.

### Contextual analysis at the codebase level

Unlike generic linters that check files in isolation, autter builds a semantic model of your entire codebase. It understands which patterns your team has established, which APIs are deprecated, and which modules have implicit performance constraints.

When it reviews a PR, it doesn't just check the diff — it evaluates the diff in context:

```
// autter flags this pattern automatically
async function getTeamMembers(teamIds: string[]) {
  // N+1 query — will execute one DB call per team ID
  // autter suggests: use db.teams.findMany({ where: { id: { in: teamIds } } })
  const members = [];
  for (const id of teamIds) {
    const team = await db.teams.findUnique({ where: { id } });
    members.push(...team.members);
  }
  return members;
}
```

autter has seen your codebase use `findMany` with `in` clauses in 47 other places. It knows this loop will generate one query per `teamId`. It flags it — not because loops are bad, but because *this specific pattern in this specific codebase* is a performance regression.

### Convention drift detection

Every codebase has unwritten rules. autter learns them from your merge history:

| What autter detects | Example |
| --- | --- |
| Deprecated API usage | AI used `legacy.createUser()` instead of `auth.register()` |
| Naming convention violations | `camelCase` in a module that uses `snake_case` throughout |
| Import path deviations | Direct import from `@internal/db` instead of the team's `@app/data` facade |
| Error handling pattern breaks | Throwing raw errors where the codebase wraps them in `AppError` |
| Test pattern mismatches | Unit test where integration tests are the established standard |

### Inline review comments

autter surfaces findings directly in your pull request as review comments — the same interface your team already uses. Each comment includes:

1. **What was detected** — a clear description of the issue
2. **Why it matters** — the specific risk or convention being violated
3. **How to fix it** — a concrete suggestion, often with a code snippet
4. **Confidence level** — how certain autter is that this is a genuine issue

### Merge gate enforcement

For critical issues — security vulnerabilities, data integrity risks, breaking API changes — autter can block the merge entirely until the issue is resolved. For lower-severity findings, it adds informational comments and lets the team decide.

```
# autter.config.yml — customise enforcement levels
rules:
  security:
    severity: block          # prevent merge
  performance:
    severity: warn           # comment but allow merge
  conventions:
    severity: info           # informational only
  deprecated_apis:
    severity: block
    exceptions:
      - path: "legacy/**"    # known legacy code, don't block
```

## What teams report after adopting autter

The numbers vary by team size and codebase complexity, but the patterns are consistent:

| Metric | Before autter | After autter | Change |
| --- | --- | --- | --- |
| Production incidents from AI code | ~4.2 / month | ~1.1 / month | -73% |
| Average review cycle time | 2.4 days | 1.1 days | -54% |
| PRs merged per developer / week | 3.8 | 8.7 | +2.3x |
| Time spent on convention enforcement | ~6 hrs / week | ~0.5 hrs / week | -92% |

The biggest shift isn't in the numbers — it's in the team dynamic. Senior engineers stop spending their review time policing conventions and start spending it on architecture and design. Junior engineers get faster, more consistent feedback. And the AI-generated code that makes it through the gate is code the team can actually trust.

## Getting started

Install the autter GitHub App, connect your repository, and your next pull request will be analysed automatically. The default rule set covers the most common AI-generated code issues out of the box.

```
# Or run locally before pushing
npx autter analyse --pr 142

# Preview what autter would flag in your current branch
npx autter check --diff HEAD~1..HEAD
```

autter analyses 10 PRs a month free on one repository. No credit card, no sales call, no configuration — just connect and see what it catches.

### See Autter on your own code.

A 30-minute walkthrough with the founders. Bring a repo and watch Autter review a live pull request.

[Book a demo](https://autter.dev/contact)

## Put an assurance layer on every release.

Autter reviews every pull request before it merges, backed by humans. Connect a repo and see your first findings today.

[Get started](https://app.autter.dev/login)

## Keep reading

[Mar 25, 2026 · 5 min read Scaling Code Review Across Distributed Engineering Teams How autter eliminates timezone bottlenecks and ensures consistent review quality across distributed teams working in different time zones.](https://autter.dev/blog/scaling-code-review-distributed-teams) [Apr 8, 2026 · 7 min read We Spent 3 Weeks Fighting About Names Naming a startup is probably not the most important thing you'll do. But get it wrong and you'll pay for it quietly, in every intro, every cold email, every 'wait, how do you spell that?' on a call.](https://autter.dev/blog/spent-3-weeks-fighting-names)


---

---
title: Scaling Code Review Across Distributed Engineering Teams - Autter Blog
description: How autter eliminates timezone bottlenecks and ensures consistent review quality across distributed teams working in different time zones.
url: https://autter.dev/blog/scaling-code-review-distributed-teams
date: 2026-03-25
author: Sagnik
tags: Developer Experience, Distributed Teams, Code Review, Velocity
reading_time: 5 min
site: Autter - Autter is the code security and assurance layer for the AI coding era: it checks every change before it merges, catches security risks, governs releases, and closes the loop from production failure to verified fix.
---

[← All posts](https://autter.dev/blog)

Mar 25, 2026

# Scaling Code Review Across Distributed Engineering Teams

How autter eliminates timezone bottlenecks and ensures consistent review quality across distributed teams working in different time zones.

Sagnik, Founder, autter.dev 5 min read

- Developer Experience
- Distributed Teams
- Code Review
- Velocity

Your engineering team spans three continents. A developer in Berlin opens a pull request at 4pm CET. The reviewer in San Francisco won't see it for another nine hours. By the time feedback arrives, the original author has context-switched to something else entirely. The review cycle stretches to days. Multiply this by every PR, every day, and you have a team that's technically distributed but operationally sequential.

autter breaks this bottleneck by providing immediate, high-quality review feedback the moment a PR is opened — regardless of what time zone the reviewer is in.

## The timezone tax on code review

Distributed teams pay a hidden tax on every pull request. Research consistently shows that review latency is the single biggest predictor of engineering velocity — more than team size, more than tooling sophistication, more than individual developer skill.

The math is brutal:

| Scenario | Time to first feedback | Typical review cycles | Total cycle time |
| --- | --- | --- | --- |
| Same timezone, same team | 2-4 hours | 1.5 | 0.5-1 day |
| Adjacent timezones (3-5hr gap) | 6-10 hours | 2.0 | 1-2 days |
| Opposite timezones (8-12hr gap) | 12-18 hours | 2.5 | 3-5 days |

Each review cycle that crosses a timezone boundary adds roughly a full business day to the PR lifecycle. And the cognitive cost is even higher — by the time the author sees the feedback, they've lost the mental context around the change.

## How autter collapses the review cycle

autter provides review feedback within 90 seconds of a PR being opened. This doesn't replace human review — it augments it by handling the categories of feedback that don't require human judgement.

### What autter reviews instantly

The moment a PR is pushed, autter analyses:

- **Convention compliance** — naming, import ordering, error handling patterns, file organisation
- **Performance patterns** — N+1 queries, unnecessary re-renders, missing indexes, unbounded loops
- **Security basics** — input validation, auth checks, secret exposure, unsafe dependencies
- **Test coverage** — new code paths that lack test coverage, removed tests without justification
- **API contract changes** — breaking changes to public interfaces, schema migrations

This means when the human reviewer in San Francisco opens the PR nine hours later, the trivial feedback has already been addressed. They can focus on architecture, design, and business logic — the things that actually require human judgement.

### Before and after

**Before autter:**

1. Developer in Berlin opens PR at 4pm CET
2. Reviewer in SF sees it at 9am PST (next day) — 17 hours later
3. Reviewer leaves 8 comments: 3 convention issues, 2 performance suggestions, 1 missing test, 2 design questions
4. Developer sees feedback at 9am CET (next day) — another 15 hours
5. Developer addresses all 8 comments, pushes update
6. Reviewer re-reviews at 9am PST — another 15 hours
7. Total: **~47 hours** across 3 calendar days

**After autter:**

1. Developer in Berlin opens PR at 4pm CET
2. autter reviews in 90 seconds, flags 3 convention issues, 2 performance suggestions, 1 missing test
3. Developer addresses autter's feedback immediately (still has context)
4. Developer pushes updated PR at 4:45pm CET
5. Reviewer in SF sees a clean PR at 9am PST — leaves 2 design questions
6. Developer addresses design feedback at 9am CET
7. Total: **~18 hours** across 2 calendar days — **62% faster**

### Consistent quality across reviewers

Different reviewers catch different things. One senior engineer might focus on performance, another on naming conventions, a third on error handling. In a distributed team where PRs are reviewed by whoever is available in the current timezone, this inconsistency compounds.

autter applies the same rule set to every PR, regardless of who reviews it or when. Your team's conventions are enforced uniformly, and human reviewers are freed to add their unique expertise on top.

## Configuration for distributed teams

autter supports timezone-aware configuration so you can tailor its behaviour to your team's workflow:

```
# autter.config.yml
review:
  # Auto-approve PRs with only low-severity findings
  # when no human reviewer is available in the current timezone
  auto_approve:
    enabled: true
    max_severity: low
    require_ci_pass: true

  # Escalation: if no human review within 8 hours,
  # notify the next-timezone reviewer
  escalation:
    timeout: 8h
    notify: "@team-leads"

  # Label PRs by review status
  labels:
    autter_approved: "autter: approved"
    needs_human_review: "needs: human review"
    blocked: "autter: blocked"
```

## The compounding effect

The benefits of faster review cycles compound over time. When PRs merge faster:

- Developers maintain context on their changes
- Merge conflicts decrease (shorter-lived branches)
- Feature delivery becomes more predictable
- Team morale improves (less waiting, less context-switching)

For distributed teams specifically, autter transforms code review from a sequential, timezone-bound process into a parallel one — where AI handles the repeatable work immediately and humans add judgement when they're available.

## Getting started

```
# Install autter on your repository
npx autter init

# Invite your team — autter will learn from all reviewers
npx autter team add --org your-org
```

No timezone configuration required. autter reviews every PR within 90 seconds, 24/7. Your team just needs to be ready for faster merge cycles.

### See Autter on your own code.

A 30-minute walkthrough with the founders. Bring a repo and watch Autter review a live pull request.

[Book a demo](https://autter.dev/contact)

## Put an assurance layer on every release.

Autter reviews every pull request before it merges, backed by humans. Connect a repo and see your first findings today.

[Get started](https://app.autter.dev/login)

## Keep reading

[Mar 20, 2026 · 5 min read Securing Your CI/CD Pipeline Against AI-Introduced Vulnerabilities How autter's merge gate catches security vulnerabilities that AI coding assistants introduce — before they reach your deployment pipeline.](https://autter.dev/blog/automated-pipeline-security) [Mar 28, 2026 · 5 min read Catching AI-Generated Code Before It Ships How engineering teams use autter to detect subtle issues in AI-authored pull requests that pass CI but fail in production.](https://autter.dev/blog/ai-generated-code-review)


---

---
title: Securing Your CI/CD Pipeline Against AI-Introduced Vulnerabilities - Autter Blog
description: How autter's merge gate catches security vulnerabilities that AI coding assistants introduce — before they reach your deployment pipeline.
url: https://autter.dev/blog/automated-pipeline-security
date: 2026-03-20
author: Sagnik
tags: Security, Pipeline, AI Safety
reading_time: 5 min
site: Autter - Autter is the code security and assurance layer for the AI coding era: it checks every change before it merges, catches security risks, governs releases, and closes the loop from production failure to verified fix.
---

[← All posts](https://autter.dev/blog)

Mar 20, 2026

# Securing Your CI/CD Pipeline Against AI-Introduced Vulnerabilities

How autter's merge gate catches security vulnerabilities that AI coding assistants introduce — before they reach your deployment pipeline.

Sagnik, Founder, autter.dev 5 min read

- Security
- Pipeline
- AI Safety

AI coding assistants are trained on public repositories. This means they have internalised every insecure pattern, every vulnerable snippet, and every deprecated API call that has ever been committed to GitHub. When they generate code for your team, they reproduce these patterns with perfect confidence — and your CI pipeline has no way to tell the difference.

## The new threat model

The traditional security pipeline — dependency scanning, SAST, DAST — was built for a world where developers wrote code intentionally. Every vulnerability had a traceable origin: a developer who misunderstood an API, a library with a known CVE, a configuration that drifted.

AI-generated code breaks this model. The vulnerabilities it introduces don't come from ignorance or negligence — they come from statistical patterns in training data. The AI doesn't know that the auth pattern it just generated was deprecated in 2023. It doesn't know that the SQL query it wrote is safe against the injection vectors in your test suite but vulnerable to a unicode normalisation attack it has never seen.

Common AI-introduced security patterns that bypass traditional scanners:

- **Outdated cryptography** — AI generates `MD5` or `SHA1` hashes for security-sensitive operations because that's what most training data contains
- **Permissive CORS configuration** — `Access-Control-Allow-Origin: *` in API routes because the AI copied from tutorial code
- **Insufficient input sanitisation** — validation that covers the happy path but misses encoding edge cases
- **Hardcoded secrets in examples** — AI interpolates placeholder secrets that look like real values and pass basic regex scanners
- **Timing-safe comparison bypass** — using `===` instead of `crypto.timingSafeEqual` for token comparison

## How autter catches what scanners miss

autter doesn't replace your existing security tooling — it adds a layer of contextual, AI-aware analysis that understands *why* certain patterns are dangerous in *your specific codebase*.

### Pattern-aware vulnerability detection

autter maintains a continuously updated catalogue of AI-generated vulnerability patterns — the specific ways AI assistants tend to produce insecure code. This goes beyond generic SAST rules:

```
// Traditional SAST: no finding (syntactically correct, type-safe)
// autter: SECURITY — timing-unsafe token comparison
// Risk: allows timing attacks to leak token contents byte-by-byte

export async function verifyApiKey(provided: string, stored: string) {
  // AI-generated: looks correct, passes type checks
  return provided === stored;

  // autter suggests:
  // return crypto.timingSafeEqual(
  //   Buffer.from(provided),
  //   Buffer.from(stored)
  // );
}
```

### Dependency chain analysis

When AI suggests adding a dependency, autter evaluates the entire transitive dependency tree — not just for known CVEs, but for behavioural anomalies:

| Check | What autter looks for |
| --- | --- |
| Known vulnerabilities | CVE database + GitHub Security Advisories |
| Behavioural anomalies | New network calls, filesystem access changes, env var reads in recent versions |
| Maintainer reputation | Single-maintainer packages, recent ownership transfers |
| Supply chain signals | Typosquatting, star inflation, sudden publish frequency changes |
| License compatibility | Copyleft contamination in permissive-licensed projects |

### Secrets detection with context

Generic secret scanners use regex patterns and entropy analysis. They catch `AKIA...` and `ghp_...` patterns — but miss secrets that are contextually dangerous:

```
# Generic scanner: no finding (not a standard secret pattern)
# autter: WARNING — database connection string with credentials
#         embedded in source. Use environment variables.

DATABASE_URL = "postgresql://admin:Prod2026$ecure@db.internal:5432/main"
```

autter understands that this string contains credentials not because of its format, but because of its *role in the codebase* — it's being passed to a database connection constructor.

### Enforcement at the merge gate

Security findings in autter are categorised by severity and enforced before merge:

```
# autter.config.yml
security:
  # Block merge on critical/high findings
  block_on:
    - critical
    - high

  # Warn but allow merge on medium
  warn_on:
    - medium

  # Auto-approve known false positives
  allowlist:
    - rule: timing-unsafe-comparison
      path: "tests/**"        # OK in test code
      reason: "Test assertions don't need timing safety"

  # Require security team review for specific paths
  require_review:
    - path: "src/auth/**"
      team: "@security-team"
    - path: "src/payments/**"
      team: "@security-team"
```

## Real-world example

A SaaS team using Copilot for a payments integration noticed autter flagging a series of issues in a single PR:

1. **Critical** — The AI-generated webhook handler didn't verify the signature of incoming Stripe events, allowing anyone to forge payment confirmations
2. **High** — The error handler logged the full request body, which contained credit card tokens, to the application's general log stream
3. **Medium** — The retry logic used exponential backoff but without jitter, creating thundering herd risk under load

All three issues passed the team's existing CI pipeline — TypeScript compiled, tests passed, the Stripe SDK was correctly imported. The issues were semantic: the code did what it said, but what it said wasn't safe.

## Defence in depth

autter works alongside your existing security tools, not instead of them:

| Layer | Tool | What it catches |
| --- | --- | --- |
| Dependencies | Dependabot / Snyk | Known CVEs in direct and transitive deps |
| Static analysis | Semgrep / SonarQube | Generic vulnerability patterns |
| AI-aware merge gate | **autter** | AI-specific vulnerability patterns, contextual analysis, convention enforcement |
| Runtime | WAF / RASP | Exploitation attempts in production |

The merge gate is the last checkpoint before code reaches your deployment pipeline — and the first checkpoint that understands the difference between human-written and AI-generated code.

## Getting started

```
# Enable security analysis on your repo
npx autter init --security

# Run a one-time security audit on your existing codebase
npx autter audit --security --since="30 days ago"
```

autter's security analysis is included in all plans. No additional configuration needed beyond connecting your repository.

### See Autter on your own code.

A 30-minute walkthrough with the founders. Bring a repo and watch Autter review a live pull request.

[Book a demo](https://autter.dev/contact)

## Put an assurance layer on every release.

Autter reviews every pull request before it merges, backed by humans. Connect a repo and see your first findings today.

[Get started](https://app.autter.dev/login)

## Keep reading

[Mar 19, 2026 · 4 min read We were called Shipgate. Shipgate made sense on paper, but it never made people feel anything. Then I drew an otter at a harbour gate, and the product (and the name) snapped into focus.](https://autter.dev/blog/we-were-called-shipgate) [Mar 25, 2026 · 5 min read Scaling Code Review Across Distributed Engineering Teams How autter eliminates timezone bottlenecks and ensures consistent review quality across distributed teams working in different time zones.](https://autter.dev/blog/scaling-code-review-distributed-teams)


---

---
title: We were called Shipgate. - Autter Blog
description: Shipgate made sense on paper, but it never made people feel anything. Then I drew an otter at a harbour gate, and the product (and the name) snapped into focus.
url: https://autter.dev/blog/we-were-called-shipgate
date: 2026-03-19
author: Sagnik
tags: Story, Branding, Product
reading_time: 4 min
site: Autter - Autter is the code security and assurance layer for the AI coding era: it checks every change before it merges, catches security risks, governs releases, and closes the loop from production failure to verified fix.
---

[← All posts](https://autter.dev/blog)

Mar 19, 2026

# We were called Shipgate.

Shipgate made sense on paper, but it never made people feel anything. Then I drew an otter at a harbour gate, and the product (and the name) snapped into focus.

Sagnik, Founder, autter.dev 4 min read

- Story
- Branding
- Product

I registered the domain at 2am, which is how most good decisions get made in early-stage startups. It had "ship" in it. It had "gate" in it. It described the mechanics accurately, and at 2am, accurate feels like enough.

It isn't.

![Twitter announcement of Shipgate](https://autter.dev/blog/shipgate-announce.jpg)

*When we first announced Shipgate to the world.*

For 3 or 4 days I built under that name and talked to people about it. Watched how they responded. And here's the thing: they understood it. Nobody felt it.

There's a meaningful difference between those two things. Understanding means your explanation worked. Feeling means the name did the work on its own, without you standing next to it pointing. Shipgate always needed the explanation. Every single time. That's a problem you want to catch before you've got it embroidered on a hoodie.

Then I drew the otter, mostly because a blank landing page is somehow more anxiety-inducing than a failing CI pipeline.

It started as a mascot sketch, something to fill the page. An otter standing at a harbour gate, arms crossed, not letting anything through without a reason. I named him Captain Patch, gave him a coat, and put him at the entrance looking like he'd seen some things and wasn't impressed by any of them.

I looked at the sketch and thought: that's the product.

![Autter Sketch Drafts](https://autter.dev/blog/autter-sketch.png)

*Autter sketch drafts*

Not a shipping tool. Not a deployment accelerator. A harbour guard. The codebase is the harbour, every pull request is a vessel requesting entry, and Captain Patch audits it before it docks. He doesn't care how confident the developer sounded in the PR description. He checks anyway.

Shipgate described what happened after approval. autter describes what happens before it. Those are different products with different customers and different reasons to exist.

## The name

autter is the auditing otter, and yes, that is the full etymology. No hidden meaning, no recursive acronym, no awkward backstory about a founder who really loved rivers. Just an otter who audits.

Every PR that comes in gets audited at the gate. The verdict is binary: blocked or clear. There's no such thing as "mostly safe to merge." Captain Patch either lets you dock or he doesn't. He's not rude about it. He's just thorough, which in this industry is apparently a rare enough quality to build a company around.

![The Road not taken](https://autter.dev/blog/autter-roads.png)

*The road not taken.*

The name doesn't describe the product literally, and I've made peace with that. The harbour metaphor handles the description. The name just has to hold the identity. Auditing Otter holds it completely, and the moment I said it out loud I stopped second-guessing. That was a welcome change from the 72 hours prior.

## On changing it after 3 days

The GitHub App was registered under Shipgate. A few conversations had already happened under that name. Changing it meant admitting I'd gotten something wrong in the first week, which is a special kind of humbling when you're also trying to convince people you know what you're doing.

I almost kept it anyway, which would have been the wrong call dressed up as pragmatism. Getting attached to a bad name to avoid looking indecisive is its own quiet mistake, the kind that compounds slowly and then suddenly all at once, usually around the time you're explaining it to a journalist and watching their expression.

The early conversations were useful data, as it turned out. People repeated the name back to me with no energy. Nobody said "Shipgate" like it meant anything. That's the signal. It's worth listening to before you've built a brand, a story, and a mascot around the wrong word. I caught it at three days. Some founders catch it at three years. I'll take the early version.

## Who this is for

Here's the other thing the name change clarified: who the product is actually for.

Shipgate, as a name, pulled interest from developers optimizing for velocity. Teams that think of code review as a bottleneck to remove, a tax on shipping speed, something to get through rather than something to take seriously. That is a real market with real money in it. It is also not the customer we're building for.

The customer we're building for is the person responsible for what gets merged. The open source maintainer with hundreds of contributors they've never met, half of whom are now using AI tools to generate pull requests at a pace no human reviewer can match. The engineering lead who's already been burned once by a migration that looked clean in review and silently corrupted production rows at 3am on a Tuesday. The DevSecOps team that keeps finding security issues after the fact and has run out of patient ways to explain to leadership why the process failed again.

These people aren't trying to go faster. They're trying to make sure what ships is actually what they approved, with no quiet surprises hiding in a diff that looked fine at a glance. Tools got faster. Verification didn't. That gap is where autter lives, and it turns out an otter with a clipboard and strong opinions about merge hygiene is exactly the right guardian for it.

> “The harbour metaphor is right. The otter is right. The name is right.”

The harbour metaphor is right. The otter is right. The name is right. It just took a few days of building under the wrong one to see it clearly, which is honestly a faster feedback loop than most things in this job.

Worth every one of those days.

![Captain Patch is waiting at the dock for you.](https://autter.dev/blog/winking-autter.png)

*Captain Patch is waiting at the dock for you.*

**[Join the waitlist at autter.dev](https://autter.dev/#waitlist)**

### See Autter on your own code.

A 30-minute walkthrough with the founders. Bring a repo and watch Autter review a live pull request.

[Book a demo](https://autter.dev/contact)

## Put an assurance layer on every release.

Autter reviews every pull request before it merges, backed by humans. Connect a repo and see your first findings today.

[Get started](https://app.autter.dev/login)

## Keep reading

[Mar 18, 2026 · 5 min read Enforcing Architecture Decisions at the Merge Gate How autter automatically enforces architectural boundaries, dependency rules, and design patterns — so your ADRs don't become wishful thinking.](https://autter.dev/blog/enforcing-architecture-decisions) [Mar 20, 2026 · 5 min read Securing Your CI/CD Pipeline Against AI-Introduced Vulnerabilities How autter's merge gate catches security vulnerabilities that AI coding assistants introduce — before they reach your deployment pipeline.](https://autter.dev/blog/automated-pipeline-security)


---

---
title: Enforcing Architecture Decisions at the Merge Gate - Autter Blog
description: How autter automatically enforces architectural boundaries, dependency rules, and design patterns — so your ADRs don't become wishful thinking.
url: https://autter.dev/blog/enforcing-architecture-decisions
date: 2026-03-18
author: Sagnik
tags: Code Quality, Architecture, Code Review, Governance
reading_time: 5 min
site: Autter - Autter is the code security and assurance layer for the AI coding era: it checks every change before it merges, catches security risks, governs releases, and closes the loop from production failure to verified fix.
---

[← All posts](https://autter.dev/blog)

Mar 18, 2026

# Enforcing Architecture Decisions at the Merge Gate

How autter automatically enforces architectural boundaries, dependency rules, and design patterns — so your ADRs don't become wishful thinking.

Sagnik, Founder, autter.dev 5 min read

- Code Quality
- Architecture
- Code Review
- Governance

Your team spent two weeks designing the new module boundary. You wrote an Architecture Decision Record. You presented it at the engineering all-hands. Everyone nodded. And three sprints later, there are seventeen imports that cross the boundary you defined, four direct database calls from the API layer, and a circular dependency that's going to cost a week to untangle.

Architecture decisions don't fail because people disagree with them. They fail because nobody enforces them at the point where code is actually written.

## The enforcement gap

Most teams document architectural decisions in one of two ways: ADRs (Architecture Decision Records) stored in a docs folder, or tribal knowledge shared in Slack threads and design reviews. Both approaches have the same fundamental problem — they rely on human reviewers remembering the rules and catching violations during review.

This worked when teams were smaller, codebases were simpler, and every PR was written by a human who attended the design review. It breaks down when:

- **AI coding assistants generate code** that has never been exposed to your architectural decisions
- **New team members** haven't internalised the unwritten rules yet
- **Review fatigue** causes experienced reviewers to miss violations in large PRs
- **Cross-team PRs** touch modules whose architectural constraints the reviewer doesn't know

## How autter enforces architecture

autter lets you encode architectural decisions as machine-enforceable rules that are checked on every pull request, automatically.

### Module boundary enforcement

Define which modules can import from which, and autter will block PRs that violate the boundaries:

```
# autter.config.yml
architecture:
  boundaries:
    # API layer can import from services, not directly from database
    - module: "src/api/**"
      can_import:
        - "src/services/**"
        - "src/types/**"
        - "src/utils/**"
      cannot_import:
        - "src/database/**"
        - "src/infrastructure/**"

    # Services can import from database, not from API
    - module: "src/services/**"
      can_import:
        - "src/database/**"
        - "src/types/**"
        - "src/utils/**"
      cannot_import:
        - "src/api/**"

    # Shared types must not import from any layer
    - module: "src/types/**"
      can_import:
        - "src/types/**"
      cannot_import:
        - "src/api/**"
        - "src/services/**"
        - "src/database/**"
```

When an AI assistant generates code that imports the database client directly in an API route, autter catches it immediately:

```
// src/api/routes/users.ts
// autter: ARCHITECTURE — direct database import violates layer boundary
// This module (src/api/**) cannot import from src/database/**
// Suggested: import from src/services/user-service instead
import { db } from "../../database/client";

export async function getUser(id: string) {
  return db.users.findUnique({ where: { id } });
}
```

### Dependency direction rules

Beyond module boundaries, autter enforces dependency direction — ensuring your dependency graph flows in one direction and doesn't develop cycles:

| Rule | What it prevents |
| --- | --- |
| No circular dependencies | Module A imports B, B imports A |
| Layer direction | Presentation → Business → Data, never reversed |
| Package isolation | Feature packages don't cross-import |
| Shared kernel restriction | Only approved types in the shared layer |

### Pattern enforcement

Some architectural decisions aren't about *what* you import but *how* you write code. autter can enforce structural patterns:

```
architecture:
  patterns:
    # All API routes must use the standard error handler
    - name: "api-error-handling"
      match: "src/api/routes/**/*.ts"
      require:
        - pattern: "withErrorHandler"
          message: "All API routes must be wrapped in withErrorHandler()"

    # Database queries must go through the repository pattern
    - name: "repository-pattern"
      match: "src/services/**/*.ts"
      forbid:
        - pattern: "db\.(select|insert|update|delete)"
          message: "Services must use repository methods, not direct DB queries"

    # All new events must include a schema version
    - name: "event-versioning"
      match: "src/events/**/*.ts"
      require:
        - pattern: "schemaVersion"
          message: "All event types must include a schemaVersion field"
```

### ADR-linked rules

autter lets you link rules to the ADR that motivated them. When a violation is flagged, the developer sees not just *what* they did wrong, but *why* the rule exists:

```
architecture:
  boundaries:
    - module: "src/api/**"
      cannot_import:
        - "src/database/**"
      adr: "docs/adr/003-layered-architecture.md"
      rationale: >
        Direct database access from API routes bypasses business logic
        validation. This caused incident INC-2026-041 where an API route
        updated user data without triggering the audit log.
```

The PR comment includes:

> **Architecture violation:** Direct import from `src/database/client` in API layer.
> 
> **Why this rule exists:** Direct database access from API routes bypasses business logic validation. This caused incident INC-2026-041. See [ADR-003](docs/adr/003-layered-architecture.md) for details.
> 
> **Suggested fix:** Import `UserService` from `src/services/user-service` and call `userService.getById(id)`.

## The difference enforcement makes

Teams that enforce architecture at the merge gate report fundamentally different outcomes than teams that rely on documentation alone:

| Metric | Documentation only | autter enforcement |
| --- | --- | --- |
| Boundary violations per sprint | 12-20 | 0-2 |
| Time spent on architecture review | ~8 hrs/week | ~1 hr/week |
| Months before major refactor needed | 6-9 months | 18+ months |
| New developer time to compliance | 4-6 weeks | Immediate |

The most significant impact is on AI-generated code. AI assistants have no awareness of your architectural decisions. Without enforcement at the merge gate, they will violate your boundaries in every PR — not out of malice, but out of ignorance.

## Getting started

```
# Generate an initial architecture config from your codebase
npx autter architecture init

# Scan existing code for boundary violations
npx autter architecture check --report

# Enable enforcement on PRs
npx autter architecture enforce
```

autter can generate an initial boundary configuration by analysing your existing import graph — showing you where boundaries already exist naturally and where they're being violated. Start with what you have, tighten as you go.

### See Autter on your own code.

A 30-minute walkthrough with the founders. Bring a repo and watch Autter review a live pull request.

[Book a demo](https://autter.dev/contact)

## Put an assurance layer on every release.

Autter reviews every pull request before it merges, backed by humans. Connect a repo and see your first findings today.

[Get started](https://app.autter.dev/login)

## Keep reading

[Mar 15, 2026 · 4 min read Measuring Code Quality in the Age of AI-Assisted Development Use autter's analytics to track how AI-generated code impacts your team's quality metrics, review velocity, and production stability.](https://autter.dev/blog/team-code-quality-metrics) [Mar 19, 2026 · 4 min read We were called Shipgate. Shipgate made sense on paper, but it never made people feel anything. Then I drew an otter at a harbour gate, and the product (and the name) snapped into focus.](https://autter.dev/blog/we-were-called-shipgate)


---

---
title: Measuring Code Quality in the Age of AI-Assisted Development - Autter Blog
description: Use autter's analytics to track how AI-generated code impacts your team's quality metrics, review velocity, and production stability.
url: https://autter.dev/blog/team-code-quality-metrics
date: 2026-03-15
author: Sagnik
tags: Analytics, Code Quality, Team Performance
reading_time: 4 min
site: Autter - Autter is the code security and assurance layer for the AI coding era: it checks every change before it merges, catches security risks, governs releases, and closes the loop from production failure to verified fix.
---

[← All posts](https://autter.dev/blog)

Mar 15, 2026

# Measuring Code Quality in the Age of AI-Assisted Development

Use autter's analytics to track how AI-generated code impacts your team's quality metrics, review velocity, and production stability.

Sagnik, Founder, autter.dev 4 min read

- Analytics
- Code Quality
- Team Performance

Your team adopted AI coding assistants six months ago. PRs are shipping faster. Lines of code per developer are up. But is the code actually better — or are you just shipping more of it?

Most teams can't answer this question because their existing metrics don't distinguish between human-written and AI-generated code. autter gives you that visibility.

## The metrics gap

Traditional engineering metrics were designed for a world where every line of code had a human author. They measure throughput (PRs merged, lines changed), velocity (cycle time, lead time), and stability (change failure rate, MTTR). These metrics still matter — but they're incomplete in the AI era.

Consider: your team's PR throughput doubled after adopting Copilot. Great. But your change failure rate also increased by 40%. Is the trade-off worth it? Which PRs are causing the failures? Are they correlated with the percentage of AI-generated code in the diff?

Without instrumentation at the merge layer, you're flying blind.

## What autter tracks

autter captures metrics at the point where code quality and team behaviour intersect — the pull request review.

### PR composition analysis

For every pull request, autter tracks the ratio of AI-generated to human-written code:

```
// Example: autter analytics API
const prAnalysis = await autter.analytics.getPRComposition({
  repo: "acme/backend",
  pr: 1842,
});

// {
//   total_lines_changed: 347,
//   ai_authored_lines: 198,
//   human_authored_lines: 149,
//   ai_ratio: 0.57,
//   issues_found: 4,
//   issues_by_source: { ai: 3, human: 1 },
//   review_cycles: 1,
//   time_to_merge: "4.2h"
// }
```

### Team-level quality dashboard

autter aggregates PR-level data into team and organisation dashboards:

| Metric | What it tells you |
| --- | --- |
| AI-authored ratio | What percentage of merged code is AI-generated? |
| Issue density by source | Do AI-authored lines have more issues per KLOC than human-authored? |
| Review cycle correlation | Do high-AI PRs require more review cycles? |
| Revert rate by source | Are AI-authored changes reverted more often? |
| Time to first flag | How quickly does autter catch issues vs. human reviewers? |
| Convention compliance | Are AI tools following your team's established patterns? |

### Trend analysis

The most valuable metrics aren't snapshots — they're trends. autter tracks how your quality indicators change over time and correlates them with events:

- **New team member onboarding** — does AI-authored issue density spike when new developers join?
- **Tool changes** — did switching from Copilot to Cursor change your AI code quality?
- **Rule updates** — did adding a new autter rule reduce a specific class of issues?
- **Sprint pressure** — does quality degrade near deadlines? By how much?

## Actionable insights, not vanity metrics

Data without action is overhead. autter surfaces specific, actionable recommendations based on your metrics:

### Bottleneck detection

> “Reviews from the platform team are averaging 3.2 days. 67% of their review time is spent on convention enforcement that autter could automate. Consider enabling auto-merge for convention-only findings.”

### Quality regression alerts

> “Test coverage in `src/payments/` dropped 8% over the last two sprints. 12 PRs merged without new tests — 9 of them were >70% AI-authored. Suggested action: enable the `require-test-coverage` rule for this module.”

### AI tool effectiveness

> “PRs using Cursor have 1.4x fewer autter findings than PRs using Copilot for the same codebase. The difference is concentrated in naming conventions and import patterns.”

## Integration with existing tools

autter's analytics complement — not replace — your existing engineering intelligence stack:

| Tool | What it measures | What autter adds |
| --- | --- | --- |
| GitHub Insights | PR throughput, contributor activity | AI vs. human attribution, quality-per-line metrics |
| LinearB / Sleuth | DORA metrics, cycle time | AI-correlated change failure rate |
| SonarQube | Static analysis coverage, code smells | Contextual quality scoring, convention compliance |
| Datadog / Grafana | Production error rates | Correlation between merge-time findings and runtime failures |

### Export and API access

All autter metrics are available via API and can be exported to your BI tools:

```
# Export team metrics as CSV
npx autter metrics export \
  --team backend \
  --period 90d \
  --format csv \
  --output ./reports/q1-quality.csv

# Query via API
curl -H "Authorization: Bearer $AUTTER_TOKEN" \
  "https://api.autter.dev/v1/metrics/team/backend?period=30d"
```

## Getting started

The analytics dashboard is available to all autter users. Connect your repository and data starts flowing from your next pull request — no additional configuration needed.

```
# View a quick summary in your terminal
npx autter metrics --team backend --period 30d
```

You can't improve what you can't measure. And in the AI coding era, what you need to measure has changed.

### See Autter on your own code.

A 30-minute walkthrough with the founders. Bring a repo and watch Autter review a live pull request.

[Book a demo](https://autter.dev/contact)

## Put an assurance layer on every release.

Autter reviews every pull request before it merges, backed by humans. Connect a repo and see your first findings today.

[Get started](https://app.autter.dev/login)

## Keep reading

[Mar 13, 2026 · 3 min read The Harbour Is Open AI now writes a meaningful share of your pull requests. The code looks right. The tests pass. And yet something is off in ways that only show up in production. autter is a merge gate built for this new reality.](https://autter.dev/blog/the-harbour-is-open) [Mar 18, 2026 · 5 min read Enforcing Architecture Decisions at the Merge Gate How autter automatically enforces architectural boundaries, dependency rules, and design patterns — so your ADRs don't become wishful thinking.](https://autter.dev/blog/enforcing-architecture-decisions)


---

---
title: The Harbour Is Open - Autter Blog
description: AI now writes a meaningful share of your pull requests. The code looks right. The tests pass. And yet something is off in ways that only show up in production. autter is a merge gate built for this new reality.
url: https://autter.dev/blog/the-harbour-is-open
date: 2026-03-13
author: Sagnik
tags: Announcement, Product, AI Safety
reading_time: 3 min
site: Autter - Autter is the code security and assurance layer for the AI coding era: it checks every change before it merges, catches security risks, governs releases, and closes the loop from production failure to verified fix.
---

[← All posts](https://autter.dev/blog)

Mar 13, 2026

# The Harbour Is Open

AI now writes a meaningful share of your pull requests. The code looks right. The tests pass. And yet something is off in ways that only show up in production. autter is a merge gate built for this new reality.

Sagnik, Founder, autter.dev 3 min read

- Announcement
- Product
- AI Safety

Sometime in 2024, the nature of code review changed quietly and permanently.

AI coding tools started shipping code that looked right. The imports resolved. The tests passed. The logic read cleanly. And yet something was off in ways no linter could catch, in ways that only became obvious in production, at 2am, when something had already gone very wrong.

I watched it happen to teams I respected. PRs were getting larger, faster, and harder to trust. Not obviously bad. Confidently wrong. And nobody had built anything serious to catch it at the merge layer before it shipped.

The gap was not a missing feature. It was a missing category.

I could not stop thinking about this. My best friend could not stop thinking about this. We looked at the gap. We looked at each other. Reader, we built a company.

> “We built autter to answer one question: what happens to code quality when every developer on your team has an AI writing half their pull requests?”

## The gap in your merge pipeline

Today, most teams run some version of the same pipeline: AI generates a PR, humans review it, CI turns green, someone hits merge, and production finds out what really happened.

Between the moment a human reviewer says "looks good" and the moment that code is merged, there is a big red zone that nobody is really instrumenting. It is where confident, plausible, wrong code quietly slides through.

This is the part of the system we decided to make our problem. The gap between "Code Review" and "Merge" is where autter lives.

## What this actually costs your team

Your senior engineers are drowning in review volume, spending their best hours on things a system could catch, instead of the architecture conversations and mentorship they were actually hired for.

Your junior engineers are clicking accept on AI suggestions without building the judgment to know when the suggestion is wrong. You will feel this in twelve months.

Your incidents are getting harder to explain. Not "someone made a mistake." More like "everything looked correct and then something broke in a way nobody predicted."

This is not a people problem. The system your team is operating in was designed for a world that no longer exists.

## What changes with autter

autter is a merge gate. Installs in under a minute. Touches nothing in your existing workflow. Runs on every pull request automatically.

When something is wrong, it blocks the merge before any human reviewer opens the diff. Not "here is a suggestion." Block. The. Button.

Your senior engineers stop being the last line of defence against bad code and start doing the work they were hired to do. Your junior engineers get real feedback on what went wrong and why. Your production environment gets quieter. Your reviewers arrive at a PR already knowing what to look at.

autter does not replace your reviewers. It makes them dramatically more effective.

> “autter does not replace your reviewers. It makes them dramatically more effective.”

## Why smarter AI makes this more valuable, not less

The more code AI writes, the more valuable a gate at the merge layer becomes. A faster car does not make traffic lights irrelevant. It makes them more necessary.

We are not threatened by the pace of AI development. We are powered by it.

## Why a waitlist

The core is running. Several things are already working. The rest is moving fast.

We want engineering leads, open source maintainers, and teams who already feel this problem and want to help shape the solution. Not passive sign-ups. People who will tell us when something is wrong and exactly how wrong it is.

If you are responsible for what gets merged into your codebase, this is built for you.

Join the waitlist at autter.dev. No credit card. No spam. Just early access and a direct line to two people who have completely lost the plot and are having the time of their lives.

![Captain Patch and Captain Scout Discussing.](https://autter.dev/blog/captains.png)

*Captain Patch and Captain Scout Discussing.*

PS: My best friend says I should explain more about how it works. I told her that is what the waitlist is for. She sighed. This is what building a company with your best friend looks like and I would not change a thing.

### See Autter on your own code.

A 30-minute walkthrough with the founders. Bring a repo and watch Autter review a live pull request.

[Book a demo](https://autter.dev/contact)

## Put an assurance layer on every release.

Autter reviews every pull request before it merges, backed by humans. Connect a repo and see your first findings today.

[Get started](https://app.autter.dev/login)

## Keep reading

[Mar 12, 2026 · 5 min read Reducing Code Review Fatigue for Senior Engineers How autter automates the repetitive parts of code review so your senior engineers can focus on architecture, mentoring, and the decisions that actually require human judgement.](https://autter.dev/blog/reducing-review-fatigue) [Mar 15, 2026 · 4 min read Measuring Code Quality in the Age of AI-Assisted Development Use autter's analytics to track how AI-generated code impacts your team's quality metrics, review velocity, and production stability.](https://autter.dev/blog/team-code-quality-metrics)


---

---
title: Reducing Code Review Fatigue for Senior Engineers - Autter Blog
description: How autter automates the repetitive parts of code review so your senior engineers can focus on architecture, mentoring, and the decisions that actually require human judgement.
url: https://autter.dev/blog/reducing-review-fatigue
date: 2026-03-12
author: Sagnik
tags: Code Review, Developer Experience, Productivity
reading_time: 5 min
site: Autter - Autter is the code security and assurance layer for the AI coding era: it checks every change before it merges, catches security risks, governs releases, and closes the loop from production failure to verified fix.
---

[← All posts](https://autter.dev/blog)

Mar 12, 2026

# Reducing Code Review Fatigue for Senior Engineers

How autter automates the repetitive parts of code review so your senior engineers can focus on architecture, mentoring, and the decisions that actually require human judgement.

Sagnik, Founder, autter.dev 5 min read

- Code Review
- Developer Experience
- Productivity

Your most experienced engineers are spending 30-40% of their time reviewing pull requests. Not on the interesting parts — not on architecture decisions, API design, or subtle race conditions — but on the mechanical parts: naming conventions, import ordering, missing error handlers, test coverage gaps, and the same performance anti-patterns they've flagged a hundred times before.

This is review fatigue. And it's one of the most expensive hidden costs in software engineering.

## The cost of repetitive review

A senior engineer's time is not fungible. An hour spent enforcing naming conventions is an hour not spent on system design, mentoring, incident response, or the kind of deep technical work that only they can do.

The economics are stark:

| Activity | Hours/week (typical) | Value to org |
| --- | --- | --- |
| Architecture & design | 4-6 | Very high |
| Mentoring & pairing | 3-5 | Very high |
| Deep code review (logic, design) | 4-6 | High |
| Convention enforcement | 5-8 | Low (automatable) |
| Boilerplate feedback | 3-5 | Low (automatable) |
| Context-switching between reviews | 2-4 | Negative |

Teams that track reviewer time find that 40-60% of review comments fall into categories that don't require human judgement: style violations, convention drift, missing tests for new branches, deprecated API usage, obvious performance patterns.

These are exactly the categories autter handles.

## How autter eliminates the low-value review work

autter reviews every PR for the mechanical, rule-based issues — before a human reviewer ever sees the code. By the time your senior engineer opens the PR, the trivial issues are already resolved.

### What autter handles automatically

**Convention enforcement:**

- Naming conventions (casing, prefixes, suffixes)
- Import ordering and grouping
- File and directory structure
- Error handling patterns
- Logging format compliance

**Quality gates:**

- Test coverage requirements for new code paths
- Documentation requirements for public APIs
- Changelog entries for user-facing changes
- Migration scripts for schema changes

**Common anti-patterns:**

- N+1 query detection
- Missing null checks on nullable returns
- Unbounded collection operations
- Deprecated API usage
- Hardcoded configuration values

### What your senior engineers focus on

With the mechanical work handled, human reviewers can focus on the decisions that actually require expertise:

- **Is this the right abstraction?** — Does this new service boundary make sense? Will it scale?
- **Are there edge cases the tests don't cover?** — Not "are there tests" (autter checks that) but "do the tests cover the tricky parts"
- **Does this change align with our roadmap?** — Is this feature being built in a way that supports where we're heading?
- **Will this cause operational issues?** — How does this behave under load, during deploys, when downstream services are degraded?

### The reviewer experience

When a senior engineer opens a PR that autter has already reviewed, they see:

1. **autter's review summary** — a concise list of what was found and resolved
2. **A clean diff** — the mechanical issues have been addressed in follow-up commits
3. **Flagged areas of interest** — autter highlights the parts of the diff that are most likely to need human judgement (complex logic, new abstractions, security-sensitive code)

```
// autter review summary for PR #1842
//
// Resolved (4):
//   ✓ Fixed import ordering in 3 files
//   ✓ Added missing error handler in UserController.update()
//   ✓ Replaced deprecated moment.format() with date-fns format()
//   ✓ Added test coverage for new validation branch
//
// For human review (2):
//   → New caching strategy in OrderService — performance implications?
//   → Changed retry logic in PaymentGateway — failure mode analysis needed
```

## Measurable impact on senior engineer time

Teams using autter consistently report a significant shift in how senior engineers spend their time:

| Metric | Before autter | After autter |
| --- | --- | --- |
| Reviews per senior engineer / day | 6-8 | 8-12 |
| Time per review (average) | 25 min | 12 min |
| % of comments on conventions | 45% | 5% |
| % of comments on design / architecture | 20% | 55% |
| Self-reported review satisfaction | 3.2/10 | 7.8/10 |

The last metric matters more than it looks. Review fatigue is a leading cause of senior engineer burnout and attrition. When reviewing code stops feeling like drudgery and starts feeling like meaningful technical contribution, retention improves.

## Gradual adoption

autter doesn't require you to change your review process overnight. Start with a single team, or even a single rule category:

```
# Start conservative — convention enforcement only
rules:
  conventions:
    severity: warn
    auto_suggest_fix: true
  performance:
    severity: off          # enable later
  security:
    severity: off          # enable later
  architecture:
    severity: off          # enable later
```

As your team builds confidence in autter's findings, expand the rule set. Most teams reach full coverage within 2-3 sprints.

## Getting started

```
# Install and let autter learn your conventions
npx autter init --learn

# autter will analyse your last 200 merged PRs to build
# a convention model specific to your codebase
```

Your senior engineers didn't join your team to enforce semicolons. Let autter handle the repeatable work so they can do what only they can do.

### See Autter on your own code.

A 30-minute walkthrough with the founders. Bring a repo and watch Autter review a live pull request.

[Book a demo](https://autter.dev/contact)

## Put an assurance layer on every release.

Autter reviews every pull request before it merges, backed by humans. Connect a repo and see your first findings today.

[Get started](https://app.autter.dev/login)

## Keep reading

[Mar 10, 2026 · 5 min read Accelerating New Developer Onboarding with Automated Review How autter helps new team members learn your codebase conventions, patterns, and architecture through real-time feedback on every pull request.](https://autter.dev/blog/onboarding-new-developers) [Mar 13, 2026 · 3 min read The Harbour Is Open AI now writes a meaningful share of your pull requests. The code looks right. The tests pass. And yet something is off in ways that only show up in production. autter is a merge gate built for this new reality.](https://autter.dev/blog/the-harbour-is-open)


---

---
title: Accelerating New Developer Onboarding with Automated Review - Autter Blog
description: How autter helps new team members learn your codebase conventions, patterns, and architecture through real-time feedback on every pull request.
url: https://autter.dev/blog/onboarding-new-developers
date: 2026-03-10
author: Sagnik
tags: Onboarding, Developer Experience, Code Review
reading_time: 5 min
site: Autter - Autter is the code security and assurance layer for the AI coding era: it checks every change before it merges, catches security risks, governs releases, and closes the loop from production failure to verified fix.
---

[← All posts](https://autter.dev/blog)

Mar 10, 2026

# Accelerating New Developer Onboarding with Automated Review

How autter helps new team members learn your codebase conventions, patterns, and architecture through real-time feedback on every pull request.

Sagnik, Founder, autter.dev 5 min read

- Onboarding
- Developer Experience
- Code Review

A new developer joins your team. They're smart, experienced, and motivated. They've read the docs. They've done the onboarding checklist. They open their first pull request — and it gets twelve review comments, most of them about conventions and patterns they've never seen before.

It's not their fault. Every codebase has hundreds of unwritten rules — patterns that emerged organically, conventions that were agreed on in a meeting two years ago, anti-patterns that caused an incident nobody documented. No onboarding guide captures all of them. And no new developer can learn them without making mistakes first.

autter turns those mistakes into immediate, contextual learning moments — on every PR, from day one.

## The onboarding bottleneck

New developer productivity follows a predictable curve. In the first 2-4 weeks, they're learning the codebase. In weeks 4-8, they're contributing small changes with heavy review guidance. By week 8-12, they're autonomous for most tasks. Full productivity typically takes 3-6 months.

The biggest bottleneck in this curve isn't comprehension — it's feedback latency. When a new developer writes code that violates a convention, the feedback loop is:

1. Developer writes code → opens PR
2. Reviewer notices violation → leaves comment (hours to days later)
3. Developer reads comment → makes change
4. Reviewer re-reviews → possibly finds more issues
5. Repeat until approved

Each cycle costs time and context. Worse, the feedback is inconsistent — different reviewers catch different things, and some conventions only get flagged when a particular senior engineer happens to review the PR.

## How autter accelerates onboarding

autter provides immediate, consistent, contextual feedback on every convention, pattern, and anti-pattern in your codebase. For new developers, this means:

### Instant feedback, zero waiting

A new developer opens a PR and gets autter's review within 90 seconds:

```
// autter feedback on PR #47 (new developer's second PR)
//
// 1. CONVENTION — Import ordering
//    In this codebase, imports follow the pattern:
//    external packages → internal packages → relative imports
//    Each group separated by a blank line.
//    [auto-fixable]
//
// 2. PATTERN — Error handling
//    This codebase wraps all service errors in AppError.
//    Raw throws are reserved for truly unexpected conditions.
//    See: src/services/user-service.ts:42 for an example.
//
// 3. CONVENTION — Test file naming
//    Tests in this module use *.test.ts, not *.spec.ts.
//    [auto-fixable]
```

The developer fixes these immediately — while they still have full context on the change — and pushes an updated PR. When the human reviewer sees it, the PR is clean.

### Learning through examples

autter doesn't just tell developers what's wrong — it shows them examples from the codebase:

> **Pattern:** In this codebase, database queries in services always use the repository pattern.
> 
> **Your code:**
> 
> ```
> const user = await db.users.findUnique({ where: { id } });
> ```
> 
> **Codebase convention** (see `src/services/order-service.ts:28`):
> 
> ```
> const user = await this.userRepository.findById(id);
> ```
> 
> **Why:** Repository methods include audit logging, caching, and soft-delete filtering that raw queries bypass.

This is the kind of context that would take weeks to absorb through documentation alone. With autter, it's delivered in context, at the exact moment the developer needs it.

### Progressive complexity

autter adapts its feedback density based on the developer's history with the codebase. In the first weeks, it explains conventions in detail with examples. As the developer demonstrates mastery of a pattern (by no longer violating it), autter reduces the verbosity:

| Developer experience | autter feedback style |
| --- | --- |
| First 2 weeks | Detailed explanations with codebase examples |
| Weeks 2-6 | Concise flags with links to examples |
| Weeks 6+ | Minimal — only flags, no explanation needed |

This prevents experienced developers from being annoyed by verbose feedback while ensuring new developers get the guidance they need.

### Convention catalogue

autter maintains a living catalogue of your codebase's conventions — derived from your merge history, not from documentation that might be outdated:

```
# New developer can browse conventions at any time
npx autter conventions list

# Output:
# ┌─────────────────────────────────────┬──────────┬─────────────┐
# │ Convention                          │ Category │ Compliance  │
# ├─────────────────────────────────────┼──────────┼─────────────┤
# │ Import ordering (external → inter…) │ Style    │ 97%         │
# │ AppError wrapping in services       │ Pattern  │ 94%         │
# │ Repository pattern for DB access    │ Pattern  │ 91%         │
# │ camelCase for functions/variables   │ Naming   │ 99%         │
# │ Test co-location (*.test.ts)        │ Testing  │ 96%         │
# │ Async error handling with try/catch │ Pattern  │ 88%         │
# └─────────────────────────────────────┴──────────┴─────────────┘
```

## Impact on onboarding metrics

| Metric | Without autter | With autter |
| --- | --- | --- |
| Time to first merged PR | 5-8 days | 2-3 days |
| Review cycles on first 10 PRs | 3.2 avg | 1.4 avg |
| Convention violations at week 4 | 8-12 per PR | 1-2 per PR |
| Time to autonomous contributor | 8-12 weeks | 4-6 weeks |
| Senior engineer time on onboarding reviews | ~10 hrs/week | ~3 hrs/week |

The impact compounds: faster onboarding means new developers contribute value sooner, senior engineers spend less time on repetitive guidance, and the team's conventions are enforced consistently regardless of who reviews the PR.

## Getting started

```
# autter learns conventions from your merge history
npx autter init --learn

# Generate an onboarding guide from detected conventions
npx autter conventions export --format markdown > docs/conventions.md
```

Your codebase has patterns. autter makes sure every new developer learns them from their first PR — not their fiftieth.

### See Autter on your own code.

A 30-minute walkthrough with the founders. Bring a repo and watch Autter review a live pull request.

[Book a demo](https://autter.dev/contact)

## Put an assurance layer on every release.

Autter reviews every pull request before it merges, backed by humans. Connect a repo and see your first findings today.

[Get started](https://app.autter.dev/login)

## Keep reading

[Mar 8, 2026 · 4 min read Building Compliance-Ready Audit Trails for Every Code Change How autter provides automated, tamper-evident audit trails for every pull request — meeting SOC 2, ISO 27001, and HIPAA requirements for change management.](https://autter.dev/blog/compliance-audit-trails) [Mar 12, 2026 · 5 min read Reducing Code Review Fatigue for Senior Engineers How autter automates the repetitive parts of code review so your senior engineers can focus on architecture, mentoring, and the decisions that actually require human judgement.](https://autter.dev/blog/reducing-review-fatigue)


---

---
title: Building Compliance-Ready Audit Trails for Every Code Change - Autter Blog
description: How autter provides automated, tamper-evident audit trails for every pull request — meeting SOC 2, ISO 27001, and HIPAA requirements for change management.
url: https://autter.dev/blog/compliance-audit-trails
date: 2026-03-08
author: Sagnik
tags: Compliance, Enterprise, Security
reading_time: 4 min
site: Autter - Autter is the code security and assurance layer for the AI coding era: it checks every change before it merges, catches security risks, governs releases, and closes the loop from production failure to verified fix.
---

[← All posts](https://autter.dev/blog)

Mar 8, 2026

# Building Compliance-Ready Audit Trails for Every Code Change

How autter provides automated, tamper-evident audit trails for every pull request — meeting SOC 2, ISO 27001, and HIPAA requirements for change management.

Sagnik, Founder, autter.dev 4 min read

- Compliance
- Enterprise
- Security

Your auditor asks: "Can you show me the review history for every code change deployed to production in the last 90 days?" You pull up GitHub. You point to PR comments. The auditor asks follow-up questions: "How do you ensure every change was reviewed? How do you prove the reviewer was qualified? How do you demonstrate that security concerns were addressed before merge?"

If your answers involve "we trust the process" or "our team follows the guidelines," you have a compliance gap. Auditors need evidence, not assurances.

autter generates that evidence automatically, for every pull request, without changing your workflow.

## The compliance burden on engineering teams

Regulated industries — healthcare, finance, government, and increasingly SaaS companies pursuing enterprise customers — require demonstrable controls over code changes. The standards vary (SOC 2, ISO 27001, HIPAA, PCI-DSS, FedRAMP), but the requirements converge:

| Requirement | What auditors look for |
| --- | --- |
| Change authorisation | Every change approved by an authorised reviewer before deployment |
| Separation of duties | The person who wrote the code is not the same person who approved it |
| Risk assessment | Evidence that security and quality risks were evaluated |
| Traceability | A complete chain from requirement → code change → review → deployment |
| Anomaly detection | Controls that flag unusual or high-risk changes for additional review |

Most engineering teams handle these requirements through manual processes: required reviewers on GitHub, branch protection rules, periodic access reviews. These controls work — but they generate sparse evidence that requires manual assembly for audits.

## How autter automates compliance evidence

autter generates a structured, machine-readable audit record for every pull request. This record includes everything an auditor needs to verify your change management controls.

### The audit record

For every PR that passes through the autter merge gate, a tamper-evident record is generated:

```
{
  "pr": {
    "number": 1842,
    "title": "Add payment retry logic",
    "author": "dev@acme.com",
    "opened_at": "2026-03-15T14:23:00Z",
    "merged_at": "2026-03-15T18:45:00Z"
  },
  "review": {
    "autter_analysis": {
      "completed_at": "2026-03-15T14:24:22Z",
      "findings": {
        "security": { "critical": 0, "high": 0, "medium": 1, "low": 2 },
        "quality": { "critical": 0, "high": 1, "medium": 3, "low": 5 },
        "conventions": { "violations": 4, "auto_fixed": 3 }
      },
      "risk_score": 42,
      "risk_category": "medium"
    },
    "human_reviews": [
      {
        "reviewer": "senior-dev@acme.com",
        "role": "code_owner",
        "approved_at": "2026-03-15T17:30:00Z",
        "comments": 2,
        "addressed": true
      }
    ],
    "separation_of_duties": true,
    "required_reviewers_satisfied": true
  },
  "compliance": {
    "standards": ["SOC2-CC8.1", "ISO27001-A.12.1.2"],
    "controls_verified": [
      "change_authorization",
      "separation_of_duties",
      "security_review",
      "quality_assessment"
    ],
    "evidence_hash": "sha256:a3f2b1..."
  }
}
```

### Risk-based review routing

Not all code changes carry the same risk. autter automatically classifies PRs by risk level and routes them accordingly:

```
# autter.config.yml
compliance:
  risk_classification:
    critical:
      # Changes to auth, payments, or data handling require security team review
      paths:
        - "src/auth/**"
        - "src/payments/**"
        - "src/data/**"
      required_reviewers:
        - team: "@security-team"
        - team: "@code-owners"
      min_reviewers: 2

    high:
      # Changes to API contracts or database schemas
      paths:
        - "src/api/routes/**"
        - "migrations/**"
      required_reviewers:
        - team: "@code-owners"
      min_reviewers: 1

    standard:
      # Everything else
      required_reviewers:
        - team: "@code-owners"
      min_reviewers: 1
```

### Continuous compliance monitoring

autter doesn't just generate records — it monitors for compliance drift:

- **Missing reviews** — PRs that bypassed the review process (admin merges, emergency hotfixes)
- **Reviewer qualifications** — reviewers who lack the required role for the risk classification
- **Policy violations** — merges that didn't meet the configured requirements
- **Trend analysis** — increasing risk scores, decreasing review quality over time

When a deviation is detected, autter creates a compliance event that can trigger alerts, workflows, or audit findings.

### Audit-ready reports

When audit time comes, autter generates pre-formatted reports that map directly to compliance framework controls:

```
# Generate SOC 2 change management report
npx autter compliance report \
  --standard soc2 \
  --period "2026-01-01..2026-03-31" \
  --format pdf \
  --output ./audit/q1-change-management.pdf
```

The report includes:

- Total code changes in the period
- Review coverage percentage (target: 100%)
- Separation of duties compliance rate
- Security findings detected and resolved
- High-risk changes with full review chain
- Policy exceptions with justification

## For different compliance frameworks

| Framework | What autter provides |
| --- | --- |
| SOC 2 (CC8.1) | Change authorisation evidence, review logs, risk assessment records |
| ISO 27001 (A.12.1.2) | Change management controls, operational procedure compliance |
| HIPAA (§ 164.312) | Access controls evidence, audit trail for PHI-touching code changes |
| PCI-DSS (6.3, 6.4) | Secure development lifecycle evidence, change control procedures |
| FedRAMP (CM-3) | Configuration change control, security impact analysis |

## Getting started

```
# Enable compliance mode
npx autter init --compliance

# Configure your compliance framework
npx autter compliance configure --standard soc2

# Run a compliance gap analysis on your current process
npx autter compliance audit --period 90d
```

The gap analysis reviews your last 90 days of PRs against your chosen compliance framework and identifies where your current process has gaps. Most teams close the gaps within a single sprint — and from that point on, every PR generates audit-ready evidence automatically.

Compliance doesn't have to mean friction. With autter, it means evidence that generates itself.

### See Autter on your own code.

A 30-minute walkthrough with the founders. Bring a repo and watch Autter review a live pull request.

[Book a demo](https://autter.dev/contact)

## Put an assurance layer on every release.

Autter reviews every pull request before it merges, backed by humans. Connect a repo and see your first findings today.

[Get started](https://app.autter.dev/login)

## Keep reading

[Mar 5, 2026 · 5 min read Managing Code Review at Scale in Monorepos How autter handles the unique challenges of monorepo code review — cross-package impact analysis, ownership routing, and consistent standards across hundreds of packages.](https://autter.dev/blog/monorepo-code-review) [Mar 10, 2026 · 5 min read Accelerating New Developer Onboarding with Automated Review How autter helps new team members learn your codebase conventions, patterns, and architecture through real-time feedback on every pull request.](https://autter.dev/blog/onboarding-new-developers)


---

---
title: Managing Code Review at Scale in Monorepos - Autter Blog
description: How autter handles the unique challenges of monorepo code review — cross-package impact analysis, ownership routing, and consistent standards across hundreds of packages.
url: https://autter.dev/blog/monorepo-code-review
date: 2026-03-05
author: Sagnik
tags: Monorepo, Enterprise, Code Review
reading_time: 5 min
site: Autter - Autter is the code security and assurance layer for the AI coding era: it checks every change before it merges, catches security risks, governs releases, and closes the loop from production failure to verified fix.
---

[← All posts](https://autter.dev/blog)

Mar 5, 2026

# Managing Code Review at Scale in Monorepos

How autter handles the unique challenges of monorepo code review — cross-package impact analysis, ownership routing, and consistent standards across hundreds of packages.

Sagnik, Founder, autter.dev 5 min read

- Monorepo
- Enterprise
- Code Review

Your monorepo has 200 packages, 15 teams, and a shared infrastructure layer that everything depends on. A developer changes a utility function in the shared layer. The PR looks small — 12 lines changed. But that function is imported by 47 packages across 8 teams, and the behavioural change will break three of them in ways that won't show up until their next deployment.

This is the monorepo review problem: small changes can have outsized, invisible impact. And traditional code review tools have no way to surface that impact before merge.

## Why monorepo review is different

In a polyrepo world, the blast radius of a change is contained to the repository it lives in. Change a function, run the tests in that repo, get a review from the team that owns it. Simple.

Monorepos collapse this isolation. A single PR can touch shared code that affects every team in the organisation. The challenges are specific:

- **Cross-package impact** — a change to a shared utility can break consumers that aren't tested in the PR's CI scope
- **Ownership ambiguity** — who reviews a change that touches packages owned by three different teams?
- **Inconsistent standards** — different packages may have evolved different conventions, and a PR that crosses boundaries needs to respect both
- **Review routing** — the right reviewer depends on which packages are affected, not just which files are changed
- **CI cost** — running every package's test suite on every PR is prohibitively expensive; selective testing requires understanding impact

## How autter solves monorepo review

autter is built with monorepo-scale codebases in mind. It understands package boundaries, dependency graphs, and cross-package impact — and uses this understanding to make review faster, safer, and more accurate.

### Cross-package impact analysis

When a PR modifies shared code, autter traces the dependency graph to identify every affected consumer:

```
// autter impact analysis for PR #3847
// Changed: packages/shared/utils/format-currency.ts
//
// Direct consumers (7 packages):
//   packages/checkout/src/components/PriceDisplay.tsx
//   packages/invoicing/src/generators/pdf.ts
//   packages/reporting/src/charts/revenue.ts
//   packages/admin/src/views/billing.tsx
//   packages/api/src/routes/pricing.ts
//   packages/mobile/src/screens/Cart.tsx
//   packages/email/src/templates/receipt.ts
//
// Behavioural change detected:
//   format-currency() now rounds to 2 decimal places (was 0)
//   This changes output for all consumers.
//
// At-risk consumers (3 packages):
//   ⚠ packages/invoicing — tests compare exact string output
//   ⚠ packages/reporting — snapshot tests will break
//   ⚠ packages/api — API response format change (breaking)
```

This analysis happens in seconds — before any CI runs, before any reviewer looks at the PR.

### Intelligent review routing

In a monorepo, the right reviewer isn't always the person who owns the files being changed — it's the person who owns the packages being *affected*. autter handles this automatically:

```
# autter.config.yml
monorepo:
  # Define package ownership
  ownership:
    - path: "packages/checkout/**"
      team: "@checkout-team"
    - path: "packages/invoicing/**"
      team: "@billing-team"
    - path: "packages/shared/**"
      team: "@platform-team"

  # Review routing rules
  routing:
    # Changes to shared code: require platform team + affected teams
    shared_code:
      paths: ["packages/shared/**"]
      require:
        - team: "@platform-team"           # owns the code
        - affected_teams: true             # auto-add affected package owners

    # Cross-package changes: require all affected teams
    cross_package:
      require:
        - affected_teams: true
        - min_reviewers: 1                 # per affected team
```

When the `format-currency` PR is opened, autter automatically requests reviews from `@platform-team` (owns the shared code), `@billing-team` (invoicing affected), `@reporting-team` (reporting affected), and `@api-team` (API affected).

### Per-package standards

Different packages in a monorepo often have different conventions — the React frontend uses different patterns than the Go backend, which uses different patterns than the shared TypeScript utilities. autter supports per-package rule configuration:

```
# packages/checkout/.autter.yml (overrides root config)
rules:
  react:
    enforce_hooks_rules: true
    require_memo_for_list_items: true
  testing:
    require_rtl: true                      # React Testing Library
    min_coverage: 85%

# packages/api/.autter.yml
rules:
  api:
    require_openapi_update: true           # API changes must update the spec
    require_migration: true                # Schema changes need migrations
  testing:
    require_integration_tests: true
    min_coverage: 90%
```

### Selective CI recommendations

Running every package's test suite on every PR is expensive. autter's impact analysis tells your CI exactly which packages need testing:

```
# GitHub Actions example
- name: Determine affected packages
  id: affected
  run: npx autter impact --format json > affected.json

- name: Test affected packages
  run: |
    PACKAGES=$(jq -r '.affected_packages[]' affected.json)
    for pkg in $PACKAGES; do
      npm test --workspace=$pkg
    done
```

This reduces CI time from "run everything" (45+ minutes in a large monorepo) to "run what's affected" (typically 5-15 minutes).

### Change categorisation

autter categorises monorepo changes by their scope and risk:

| Category | Description | Review requirement |
| --- | --- | --- |
| Package-local | Changes contained within one package | Package owner |
| Cross-package | Changes affecting multiple packages | All affected owners |
| Shared infrastructure | Changes to shared code | Platform team + affected owners |
| Build/config | Changes to build tooling or config | Platform team |
| Breaking change | Changes that alter public APIs | All affected owners + architecture review |

## Results at scale

Teams running autter on monorepos with 100+ packages report:

| Metric | Before autter | After autter |
| --- | --- | --- |
| Cross-package incidents per month | 4-7 | 0-1 |
| Avg review routing accuracy | ~60% | ~95% |
| Time to identify impact scope | 30-60 min (manual) | Under 2 min (automatic) |
| CI minutes per PR (avg) | 45 min | 12 min |
| Stale review requests | 30% of PRs | Under 5% of PRs |

The biggest win is the incidents you don't have. A shared utility change that breaks a downstream package in production is expensive — in debugging time, in incident response, in customer trust. autter catches these before merge, every time.

## Getting started

```
# Initialise autter with monorepo mode
npx autter init --monorepo

# autter will detect your package manager (npm/pnpm/yarn workspaces,
# Turborepo, Nx, Lerna) and build the dependency graph automatically

# Preview impact analysis for your current branch
npx autter impact --diff main...HEAD
```

Your monorepo is a force multiplier for your team. autter makes sure it doesn't become a liability.

### See Autter on your own code.

A 30-minute walkthrough with the founders. Bring a repo and watch Autter review a live pull request.

[Book a demo](https://autter.dev/contact)

## Put an assurance layer on every release.

Autter reviews every pull request before it merges, backed by humans. Connect a repo and see your first findings today.

[Get started](https://app.autter.dev/login)

## Keep reading

[Mar 8, 2026 · 4 min read Building Compliance-Ready Audit Trails for Every Code Change How autter provides automated, tamper-evident audit trails for every pull request — meeting SOC 2, ISO 27001, and HIPAA requirements for change management.](https://autter.dev/blog/compliance-audit-trails)


---

---
title: Careers at Autter - Build the Code Security & Assurance Layer
description: Join the team building the code security and assurance layer for the AI coding era. See open roles at Autter.
url: https://autter.dev/careers
site: Autter - Autter is the code security and assurance layer for the AI coding era: it checks every change before it merges, catches security risks, governs releases, and closes the loop from production failure to verified fix.
---

## Open roles at a glance

| Role | Department | Location | Type | Published |
| --- | --- | --- | --- | --- |
| [Frontend Engineer](https://autter.dev/careers/frontend-engineer.md) | Engineering | Remote (PT / IST overlap) | Full-time | 2026-04-04 |
| [Backend Engineer (Agentic AI)](https://autter.dev/careers/backend-engineer.md) | Engineering | Remote (PT / IST overlap) | Full-time | 2026-04-04 |
| [Marketing Intern](https://autter.dev/careers/marketing-intern.md) | Marketing | Remote (IST) | Internship | 2026-04-04 |

Engineering roles are full-time with hours that overlap the team across Pacific (PT) and India (IST). The Marketing Intern is full-time or near full-time in the IST timezone. Everyone works directly with the founding team. Each role's page carries the full description, responsibilities, and requirements, plus the application form.

## How to apply

Apply through the form on the role's page (first name, last name, email, phone, LinkedIn URL, resume upload, optional cover letter, and a few short-answer questions). Applications go straight to the founders.

## Working at Autter

Autter is a two-founder, pre-launch startup that hires slowly and deliberately. The company values:

- **Craftsmanship**: We believe great tools are built by people who care deeply about quality. Every line of code, every interaction, every decision reflects our commitment to excellence.
- **Transparency**: We default to openness. We share context freely, communicate honestly, and trust each other to make good decisions with the full picture.
- **Urgency**: We move fast and ship often. We remove friction, bias toward action, and iterate quickly to help engineers do the same.


---

---
title: Frontend Engineer - Careers at Autter
description: Work directly on the Autter web application, shipping real features alongside the founding team.
url: https://autter.dev/careers/frontend-engineer
department: Engineering
location: Remote (PT / IST overlap)
employment_type: Full-time
published: 2026-04-04
site: Autter - Autter is the code security and assurance layer for the AI coding era: it checks every change before it merges, catches security risks, governs releases, and closes the loop from production failure to verified fix.
---

[← All positions](https://autter.dev/careers)

# Frontend Engineer

Engineering Remote (PT / IST overlap) Full-time

We're looking for a frontend engineer who cares about craft. You'll work directly on the Autter web application, shipping real features alongside the founding team. No make-work tasks. No tutorial-level projects. If you're good, you'll leave with a portfolio that actually says something.

Apply for this role

## What you'll do

- Build UI components for the Autter dashboard and PR review interface
- Translate Figma designs into production-ready React code
- Write clean, accessible HTML and CSS that holds up across screen sizes
- Own frontend performance improvements and bug fixes
- Sit in on design reviews and contribute opinions

## What we're looking for

- Solid understanding of React and JavaScript (TypeScript is a plus)
- Familiarity with Tailwind CSS or similar utility-first frameworks
- Ability to read a Figma file and ask the right questions
- Portfolio or side projects you can point to
- Hours that overlap with the team across Pacific (PT) and India (IST)

## Nice to have

- Experience with Next.js App Router
- Any exposure to animation libraries like GSAP or Framer Motion
- Opinionated about spacing and type hierarchy

Application

## Apply for this role

First name Last name

Email Phone

LinkedIn URL

Resume Click to upload PDF, DOC, or DOCX Up to 5 MB.

Cover letter Click to upload Optional: PDF, DOC, or DOCX

Anything else you'd like us to know? How can we improve what we're building? How would you like to contribute?

I've signed up and seen how the platform works I agree to the [Terms of Use](https://autter.dev/terms-of-service) and [Privacy Policy](https://autter.dev/privacy)

Submit application

## How to apply

Submit the application form at https://autter.dev/careers/frontend-engineer (first name, last name, email, phone, LinkedIn URL, resume upload, optional cover letter, and a few short-answer questions). Applications go straight to the founders. This role is full-time, Remote (PT / IST overlap), in the Engineering department, published 2026-04-04. All open roles: [careers index](https://autter.dev/careers.md).


---

---
title: Backend Engineer (Agentic AI) - Careers at Autter
description: Build and maintain the systems that detect blast radius, security vulnerabilities, and AI-generated code quality issues.
url: https://autter.dev/careers/backend-engineer
department: Engineering
location: Remote (PT / IST overlap)
employment_type: Full-time
published: 2026-04-04
site: Autter - Autter is the code security and assurance layer for the AI coding era: it checks every change before it merges, catches security risks, governs releases, and closes the loop from production failure to verified fix.
---

[← All positions](https://autter.dev/careers)

# Backend Engineer (Agentic AI)

Engineering Remote (PT / IST overlap) Full-time

Autter runs agentic pipelines to analyse every pull request that comes through. We're looking for a backend engineer who wants to work close to that layer. You'll help build and maintain the systems that detect blast radius, security vulnerabilities, behavioral regressions, and AI-generated code quality issues. The work is real and the surface area is large.

Apply for this role

## What you'll do

- Build and maintain backend services in Node.js or Python that power PR analysis
- Work on agentic orchestration pipelines using LLM APIs
- Integrate with the GitHub API and process webhook events
- Write scripts and tooling to support analysis and testing pipelines
- Help improve the accuracy and speed of existing detection engines

## What we're looking for

- Comfortable with Node.js or Python in a backend context
- Solid understanding of REST APIs and webhooks
- Curious about how LLMs work and willing to experiment with prompting and tool use
- Can read a codebase you didn't write and figure out what's happening
- Hours that overlap with the team across Pacific (PT) and India (IST)

## Nice to have

- Any experience with LLM API integrations (OpenAI, Anthropic, etc.)
- Familiarity with GitHub Apps or the GitHub API
- Exposure to Docker or containerised environments
- Prior work on developer tooling or open source projects

Application

## Apply for this role

First name Last name

Email Phone

LinkedIn URL

Resume Click to upload PDF, DOC, or DOCX Up to 5 MB.

Cover letter Click to upload Optional: PDF, DOC, or DOCX

Anything else you'd like us to know? How can we improve what we're building? How would you like to contribute?

I've signed up and seen how the platform works I agree to the [Terms of Use](https://autter.dev/terms-of-service) and [Privacy Policy](https://autter.dev/privacy)

Submit application

## How to apply

Submit the application form at https://autter.dev/careers/backend-engineer (first name, last name, email, phone, LinkedIn URL, resume upload, optional cover letter, and a few short-answer questions). Applications go straight to the founders. This role is full-time, Remote (PT / IST overlap), in the Engineering department, published 2026-04-04. All open roles: [careers index](https://autter.dev/careers.md).


---

---
title: Marketing Intern - Careers at Autter
description: Own growth, GTM, content, campaigns, creative, and community work with the founding team before launch.
url: https://autter.dev/careers/marketing-intern
department: Marketing
location: Remote (IST)
employment_type: Internship
published: 2026-04-04
site: Autter - Autter is the code security and assurance layer for the AI coding era: it checks every change before it merges, catches security risks, governs releases, and closes the loop from production failure to verified fix.
---

[← All positions](https://autter.dev/careers)

# Marketing Intern

Marketing Remote (IST) Internship

Autter is pre-launch with a waitlist and a product that's almost ready to ship. You'll work closely with the founding team across GTM, growth, content, campaigns, brand, and marketing strategy. This isn't a role where you just write captions — you'll own real initiatives end to end, from researching a market to shipping a campaign. Good judgment matters more than prior experience here.

Apply for this role

## What you'll do

- GTM & Growth: Brainstorm and execute go-to-market strategies, growth experiments, acquisition ideas, and campaigns
- Marketing Strategy: Research our target users, competitors, and developer communities to identify opportunities for Autter
- Campaigns: Conceptualise and execute launches, product campaigns, community initiatives, and creative marketing experiments
- Content: Create LinkedIn, X, Instagram, and other content — from ideation and scripting to execution
- Creative & Design: Design posters, social creatives, campaign assets, landing-page visuals, and other marketing collateral
- Video & Motion: Edit short-form videos, product demos, reels, and potentially create simple animations and motion graphics
- Community & Distribution: Identify relevant developer communities, channels, partnerships, and distribution opportunities
- Product Marketing: Translate Autter's technical features into messaging developers, engineering leaders, and founders actually understand
- Market Research: Track competitors, developer tooling trends, communities, and emerging marketing opportunities
- Experiments: Come up with unconventional marketing ideas, test them, measure what works, and iterate
- General Growth: If you see a way to put Autter in front of 1,000 relevant developers, we want you to figure out how to make it happen

## What we're looking for

- Understands the basics of GTM planning and marketing strategy
- Strong creative thinking and the ability to come up with original growth ideas
- Comfortable with content creation, editing, and design
- Knows their way around tools such as Canva, Figma, CapCut, Premiere Pro, After Effects, or similar
- Understands social media and what makes content perform
- Comfortable researching, experimenting, and figuring things out independently
- Strong written and verbal communication skills
- Curious about startups, technology, AI, and developer tools
- Willing to get your hands dirty — whether that's designing a poster, researching a market, writing a campaign, or reaching out to a community
- Available full-time or near full-time (IST)

## Bonus points

- Experience with B2B SaaS, developer tools, or tech startups
- Understanding of developer and engineering audiences
- Experience with GTM, growth experiments, or campaign planning
- Motion graphics or animation skills
- Basic analytics and performance marketing knowledge
- Experience running social media accounts or communities
- A portfolio of creative work, campaigns, or projects

Application

## Apply for this role

First name Last name

Email Phone

LinkedIn URL

Resume Click to upload PDF, DOC, or DOCX Up to 5 MB.

Cover letter Click to upload Optional: PDF, DOC, or DOCX

### Role-specific questions

Introduce yourself in 100–150 words.

Rank these from 1 (most interesting) to 6 (least interesting) — drag to reorder:

1. 1 Growth & GTM
2. 2 Marketing strategy
3. 3 Content & social media
4. 4 Design & creative
5. 5 Community & distribution
6. 6 Product marketing

Position 1 is your top pick, 6 is your least.

Portfolio A link to your portfolio, past campaigns, or projects (Drive, Behance, Figma, your site, etc.)

Anything else you'd like us to know? How can we improve what we're building? How would you like to contribute?

I've signed up and seen how the platform works I agree to the [Terms of Use](https://autter.dev/terms-of-service) and [Privacy Policy](https://autter.dev/privacy)

Submit application

## How to apply

Submit the application form at https://autter.dev/careers/marketing-intern (first name, last name, email, phone, LinkedIn URL, resume upload, optional cover letter, and a few short-answer questions). Applications go straight to the founders. This role is internship, Remote (IST), in the Marketing department, published 2026-04-04. All open roles: [careers index](https://autter.dev/careers.md).


---

---
title: Autter Changelog - What's New in Autter
description: Everything Autter ships, the day it ships: the running record of new features across the Autter platform, CLI, and integrations.
url: https://autter.dev/changelog
site: Autter - Autter is the code security and assurance layer for the AI coding era: it checks every change before it merges, catches security risks, governs releases, and closes the loop from production failure to verified fix.
---

## Release index

129 releases logged to date, newest first. New entries land most weeks, usually Saturdays. Labels: **New Feature** (net-new capability) and **Improvement** (accuracy, speed, or polish on an existing one).

| Date | Label | Release |
| --- | --- | --- |
| 2026-10-10 | New Feature | A Confidence Score comment that updates as the review runs |
| 2026-10-10 | New Feature | PR Triage scores every open pull request P0–P3 |
| 2026-10-10 | New Feature | Runtime 1.5.0: one record per request, coded errors, and evidence-based root causes |
| 2026-10-10 | New Feature | CI/CD failures on your default branch now open incidents |
| 2026-10-10 | New Feature | Memory pages update themselves every night |
| 2026-10-10 | New Feature | Product Walk runs in codebase scans and across multi-service stacks |
| 2026-10-10 | New Feature | One Pipeline settings page, eight new scanners, and a cross-repo contract check |
| 2026-10-10 | Improvement | PR reviews no longer fail during busy periods, and finish faster |
| 2026-10-10 | Improvement | Review memory you can control |
| 2026-10-10 | Improvement | Product Walk, the scan overview, and the dashboard get more honest and easier to read |
| 2026-10-10 | Improvement | The CLI stays logged in on flaky networks and asks before installing |
| 2026-10-10 | Improvement | Security and trust hardening, plus fixes |
| 2026-10-04 | New Feature | Product Walk, rebuilt: an AI agent walks through your app on each PR |
| 2026-10-04 | New Feature | Autter in Slack: slash commands, alerts, and actions |
| 2026-10-04 | New Feature | Issue trackers and support tickets flow into Autter |
| 2026-10-04 | New Feature | Critical root causes open a draft fix PR automatically |
| 2026-10-04 | New Feature | Simulations in PR review test scenarios against your real code |
| 2026-10-04 | New Feature | More data over MCP, and a map of what changed in each PR |
| 2026-10-04 | New Feature | Runtime adds a service topology graph, auto-closing incidents, and drafted postmortems |
| 2026-10-04 | Improvement | Fix PRs make real code changes, and draft PRs stay in sync |
| 2026-10-04 | Improvement | CLI 2.1.0–2.2.0: update prompts, smarter doctor, and verified installs |
| 2026-10-04 | Improvement | Sign in with Google, GitHub or a Passkey |
| 2026-09-21 | New Feature | Repository dashboards bring health, scans, indexing, and activity into one place |
| 2026-09-21 | New Feature | Sync your documentation with Confluence in both directions |
| 2026-09-21 | Improvement | PR reviews gain richer context, verification, and recovery handling |
| 2026-09-21 | New Feature | Detect and respond to incidents faster with lifecycle actions and reconciliation |
| 2026-09-21 | Improvement | Indexing handles incremental updates more efficiently |
| 2026-09-21 | Improvement | Faster and more economical AI processing across runs |
| 2026-09-21 | Improvement | More reliable integrations and platform workflows |
| 2026-08-18 | New Feature | Autter now flags problems in your code before they cause an incident |
| 2026-08-18 | New Feature | Pull request review effort now matches the size of the change |
| 2026-08-18 | New Feature | A new command line tool tells you, in one shot, whether Autter is actually working |
| 2026-08-18 | Improvement | Two ways the review page could say one thing while showing another |
| 2026-08-18 | Improvement | On the free plan, your one repository slot is now permanent |
| 2026-08-18 | Improvement | A dashboard error affecting every account is fixed |
| 2026-08-18 | Improvement | Runtime telemetry now survives a slow or restarting service |
| 2026-08-18 | Improvement | Runtime event counts are accurate again, and every error occurrence is inspectable |
| 2026-08-18 | Improvement | A retained error now keeps the trace that explains it |
| 2026-08-17 | Improvement | Running jobs moved out of a floating toast and into the notification bell |
| 2026-08-17 | Improvement | Indexing narrates itself during setup, and the completion email waits for your whole fleet |
| 2026-08-17 | Improvement | The sample-data indicator now matches what is on screen |
| 2026-08-17 | Improvement | The terms-of-service popup no longer appears twice on first login |
| 2026-08-17 | Improvement | A single crashed query no longer stops your machine's attribution syncing for good |
| 2026-08-16 | New Feature | Autter now reads your TODO comments, not just your code |
| 2026-08-16 | New Feature | See what your AI-assisted development actually costs, by day, team, and person |
| 2026-08-16 | Improvement | Fixed three separate ways your AI-attribution history could quietly go missing |
| 2026-08-16 | Improvement | Every way to install the CLI now works, including two that did not |
| 2026-08-16 | Improvement | Editor integration is more honest about what actually installed |
| 2026-08-15 | New Feature | Connecting your AI models now takes one line of code |
| 2026-08-15 | New Feature | Slow and expensive AI calls now get flagged within minutes, not the next day |
| 2026-08-15 | New Feature | Autter can now open a pull request that fixes an AI performance or cost problem |
| 2026-08-15 | New Feature | A daily summary of your AI spend and health, delivered to your notifications |
| 2026-08-15 | New Feature | See your slowest and most expensive calls at a glance |
| 2026-08-15 | Improvement | The Runtime LLM tab no longer shows an error before your first data arrives |
| 2026-08-15 | Improvement | The pieces behind the one-line install all landed together |
| 2026-08-13 | New Feature | Your first repository gets scanned automatically, with no button to find |
| 2026-08-13 | New Feature | Scans now tell you what needs your attention, not just a number |
| 2026-08-13 | New Feature | Autter names a real finding in your own code, right away |
| 2026-08-13 | New Feature | A scan-complete email that actually tells you something |
| 2026-08-13 | Improvement | Installing the command-line tool on Windows now just works |
| 2026-08-13 | Improvement | The Runtime tab in the public demo no longer crashes |
| 2026-08-13 | Improvement | Severity drives the risk score, not volume |
| 2026-08-12 | New Feature | Setup is four steps instead of nine, and the waiting does something |
| 2026-08-12 | New Feature | Bring your own monitoring: Sentry, PostHog, Grafana, or any webhook |
| 2026-08-12 | New Feature | Autter Runtime now catches slow code, not just broken code |
| 2026-08-12 | New Feature | Environment variables for your repositories, so checks run against real configuration |
| 2026-08-12 | Improvement | Scans that fail now look like it |
| 2026-08-12 | Improvement | One blocking-issue count, and verdicts that update after the deeper pass |
| 2026-08-12 | Improvement | Automated fix runs always report back |
| 2026-08-12 | Improvement | Every CLI install screen now explains why you need it |
| 2026-08-12 | Improvement | Two pieces of hardening behind the scenes |
| 2026-08-09 | New Feature | Search your pull requests by meaning |
| 2026-08-09 | New Feature | Two new review checks: row-level security and UI slop |
| 2026-08-09 | New Feature | See how much of Autter's review you actually act on |
| 2026-08-09 | New Feature | Custom agents: schedules, email, and six new templates |
| 2026-08-09 | Improvement | Review depth follows who wrote the code |
| 2026-08-09 | Improvement | A faster start, and workspaces you can rename |
| 2026-08-09 | Improvement | Failures that hid themselves, fixed |
| 2026-08-05 | New Feature | Stacked pull requests are now first-class in Autter |
| 2026-08-05 | New Feature | Autter can now propose how to split a large pull request into a stack |
| 2026-08-05 | New Feature | Dependency chains now trace back to their origin in pnpm and yarn projects |
| 2026-08-05 | Improvement | Quieter errors, honest demo pricing, and reviews that stop cleanly |
| 2026-07-19 | New Feature | A pull request board, stronger controls, and safer automation |
| 2026-07-19 | New Feature | Regional pricing, subscriptions, and usage metering |
| 2026-07-19 | New Feature | Connected accounts and guided onboarding |
| 2026-07-19 | New Feature | Meet Autter MCP: review context and actions in your AI tools |
| 2026-07-19 | New Feature | Scoped build verification and safer automated testing |
| 2026-07-19 | Improvement | More reliable connected workflows and notifications |
| 2026-07-13 | Improvement | Reviews that learn, verify, and act |
| 2026-07-13 | New Feature | Custom agents and post-merge automation |
| 2026-07-13 | Improvement | Clearer diffs, repository learnings, and live issue boards |
| 2026-07-13 | New Feature | Engineering health analytics and safer sign-in |
| 2026-07-01 | New Feature | Stronger review gates and better conversations |
| 2026-07-01 | Improvement | Broader review coverage with fewer false positives |
| 2026-07-01 | New Feature | Automation, dependency alerts, and team digests |
| 2026-07-01 | Improvement | Smoother connections and production reliability |
| 2026-06-21 | New Feature | Secure sign-in, developer tokens, and the identity layer that stays out of your way |
| 2026-06-21 | Improvement | Sharper reviews, quieter noise, and analytics that actually tell you something |
| 2026-06-21 | New Feature | Interactive demos and the faster front door |
| 2026-06-21 | Improvement | The quiet stuff that keeps everything running |
| 2026-06-14 | New Feature | The review that sees everything |
| 2026-06-14 | Improvement | Scan results that explain themselves |
| 2026-06-14 | New Feature | The billing that runs itself |
| 2026-06-07 | New Feature | The gate gets teeth |
| 2026-06-07 | Improvement | A review surface built for humans |
| 2026-06-07 | Improvement | Richer webhooks and Slack routing |
| 2026-05-31 | New Feature | The merge gate goes live |
| 2026-05-31 | New Feature | Public reports you can hand to anyone |
| 2026-05-31 | New Feature | The first knowledge graph |
| 2026-05-23 | New Feature | The full scan surface |
| 2026-05-23 | New Feature | Issue sync: Linear, Jira, and GitHub |
| 2026-05-23 | New Feature | Exploit enrichment and chain tracing |
| 2026-05-17 | Improvement | The docs engine, upgraded |
| 2026-05-17 | New Feature | The first auditor agent |
| 2026-05-10 | New Feature | Custom agents and guided config |
| 2026-05-10 | New Feature | The documentation generation pipeline |
| 2026-05-04 | New Feature | CVE watch: scheduled monitoring |
| 2026-05-04 | Improvement | Repository overview and smarter search |
| 2026-04-27 | New Feature | The repository wiki |
| 2026-04-27 | Improvement | Pull request review, rebuilt |
| 2026-04-27 | New Feature | The graph: architectural insights |
| 2026-04-20 | Improvement | The indexing pipeline levels up |
| 2026-04-20 | Improvement | Onboarding and a lot of plumbing |
| 2026-04-16 | Improvement | Onboarding that gets out of the way |
| 2026-04-12 | New Feature | Self-service scan initiation |
| 2026-04-05 | Improvement | Streaming progress and auto-open setup |
| 2026-03-29 | New Feature | The multi-agent scan engine |
| 2026-03-29 | New Feature | GitHub PR automation and the first dashboard |
| 2026-03-22 | New Feature | Week one: we built the product |

## Releases in full

Every logged release, newest first, with what shipped and why it matters.

### October 10, 2026 — A Confidence Score comment that updates as the review runs (New Feature)

Autter now posts a single Confidence Score comment on each PR and keeps it current while the review runs. It refreshes when threads are resolved, and you can turn it off on the Pipeline settings page.

- **Score and verdict**: A score out of 5 and a one-line verdict at the top of the comment.
- **Ranked findings**: Findings ranked P0–P3, each linking to its review thread.
- **Summary and change diagram**: A short summary of the PR and a diagram of what changed.
- **🔄 Re-run review**: A checkbox that re-runs the review. Only users with write access can use it.

### October 10, 2026 — PR Triage scores every open pull request P0–P3 (New Feature)

Open PRs are now scored P0–P3 automatically, so you can see what needs attention first. You can filter by priority and by handler.

- **Evidence and scope**: Each PR shows the evidence behind its priority and the scope of the change.
- **Review effort**: An estimate of how much review the PR needs.
- **Agent or person**: A suggestion of whether an agent or a person should handle it, plus the next step.

### October 10, 2026 — Runtime 1.5.0: one record per request, coded errors, and evidence-based root causes (New Feature)

Runtime 1.5.0 gives every request and job one summary record with a request ID, lets your app tell Autter what an error means, and rebuilds root-cause analysis around cited evidence.

- **Requests & logs**: A new view with Requests, Routes, Jobs and Logs tabs, plus a request page with a Find request box.
- **Coded errors**: Your app can attach an error code, plus the cause and fix it already knows. The same code from any source counts as one issue, including Sentry, PostHog, Datadog and Grafana/Loki.
- **Expected errors stay quiet**: Errors marked as expected never open incidents. You get an alert when one spikes.
- **A new issue page**: A step-by-step view of the failing request, a comparison against healthy requests, browser events, a timeline with deploy markers, and links from the analysis to its evidence.
- **Evidence-based root-cause analysis**: Autter works out root causes from cited evidence: the failing requests and their logs, a comparison against healthy requests, browser events, deploys, and the PR changes linked to the failure. Each analysis shows a classification, a confidence level and reproduction steps, and links every claim to its evidence.
- **Safer automatic fixes**: Fixes are attempted automatically only when confidence is medium or higher, and each fix starts by writing a test that reproduces the failure.
- **@autter/runtime-edge**: A new SDK for Cloudflare Workers, Vercel Edge, Deno and Bun.

Runtime 1.4.0 added diagnostic logs and operation outcomes, which are linked to issues and used in root-cause analysis.

### October 10, 2026 — CI/CD failures on your default branch now open incidents (New Feature)

When a workflow or deployment fails on the default branch, Autter opens an incident in a new CI/CD failures tab. Each one gets a root-cause analysis and, when the failure is in code, a draft fix PR. The next green run closes it.

### October 10, 2026 — Memory pages update themselves every night (New Feature)

Every night, each member's Memory pages are updated from their recent activity. Edits people make themselves are never overwritten.

Patterns Autter has learned are also grouped by topic each night and used in reviews.

### October 10, 2026 — Product Walk runs in codebase scans and across multi-service stacks (New Feature)

Codebase scans now boot your app and walk through its routes in a browser. You can watch the walk live from the scan page.

- **Multi-service stacks**: A stack can have any number of services, and you can import one from docker-compose.yml.
- **Laravel/PHP**: Laravel and PHP apps are supported too.

### October 10, 2026 — One Pipeline settings page, eight new scanners, and a cross-repo contract check (New Feature)

Each repo now has one Pipeline settings page with every check, AI layer, scanner, lens and walk toggle in one place.

- **New scanners**: ruff, bandit, actionlint, hadolint, semgrep, golangci-lint, gosec and rubocop, plus React, accessibility and Next.js rules for oxlint. Autter also flags comments or config edits that silence a scanner.
- **Frontend lens on by default**: Turned on for PRs that change React, Vue or Svelte code.
- **Cross-repo contract check**: Checks contracts between connected repos.

### October 10, 2026 — PR reviews no longer fail during busy periods, and finish faster (Improvement)

Reviews, scans and docs jobs now run in whichever region has free capacity at that moment, so busy periods no longer fail PR reviews.

**More reliable**

- Review gates no longer get stuck
- Long reviews run to completion, and a stopped review resumes where it left off
- Pushing a new commit skips the outdated review instead of finishing it
- Build and test failures that were already there before the PR no longer block it

**Fewer false merge blocks**

Only confirmed findings block a merge, and Product Walk never blocks one.

**Faster**

- The PR description, chapters and diagrams are generated while the checks run instead of before them
- Fast-forward pushes are re-reviewed incrementally
- Only the affected builds and tests run

### October 10, 2026 — Review memory you can control (Improvement)

You can now see which learnings shaped a finding and reject the ones that don't fit.

- **Applied learnings**: Findings show which learnings were applied, and you can reject a learning in one click.
- **Mutes expire**: Mutes expire after 90 days.
- **👍 reactions count**: 👍 reactions improve later verification.

### October 10, 2026 — Product Walk, the scan overview, and the dashboard get more honest and easier to read (Improvement)

Product Walk now really clicks through the app, and its statuses are honest about login walls and failed boots. When it hits a login wall it waits for help for at most 10 minutes, then continues.

**Codebase scan overview**

- Tabs are grouped into 6 categories
- "What to fix first" is now the first card
- Every score has a legend. "Legacy debt" was previously shown in reversed colors and is now correct
- The scan assistant returns clickable deep links

**Elsewhere in the dashboard**

- **autter.yaml**: Changes saved in the dashboard show as pending, with a link to the draft PR. Comments in the file are kept.
- **Archify diagrams**: Diagrams render reliably. About half used to come back as "unavailable".
- **Animations**: Modals, side sheets and bottom drawers animate, and side sheets can be dragged to dismiss.
- **Runtime version compatibility**: A new card in Repository → Settings → Runtime.

### October 10, 2026 — The CLI stays logged in on flaky networks and asks before installing (Improvement)

A round of CLI fixes focused on staying out of your way.

- You no longer get logged out when a token refresh is lost on a flaky network
- Local mode never uploads anything
- Choosing a mode during onboarding no longer installs integrations without asking (--yes to skip the prompt)
- doctor and bg status share one health check
- Fixes for Windows install and for capture from Antigravity

### October 10, 2026 — Security and trust hardening, plus fixes (Improvement)

Secrets are scrubbed in every Runtime SDK and in the ingester, and again before any runtime data reaches an AI model.

**Security and trust**

- Unverified CVE findings from web search are labelled "Unverified" and capped at medium severity
- Agents' read-only database access is limited to code-index tables
- PR comments and the dashboard no longer show raw internal errors

**Fixes**

- The "Indexing complete" email described other repos' stacks. It now covers only the repo it announces
- The Windows and Linux install commands from app.autter.dev work again
- Fixed crashes on the demo's Memory, Runtime and board pages

### October 4, 2026 — Product Walk, rebuilt: an AI agent walks through your app on each PR (New Feature)

An AI agent now walks through your app in a real browser on each PR. It plans what to test, fills forms with safe test values, and checks the result.

- **Checks that catch real bugs**: Duplicate submits, dead clicks, and whether changes survive a reload.
- **UI and API together**: It can walk a UI and its API together, even when they live in different repos.
- **Credentials stay private**: Credentials you configure are never shown to the model.

### October 4, 2026 — Autter in Slack: slash commands, alerts, and actions (New Feature)

Install the Autter Slack app and link your workspace to bring Autter into the channels your team already uses.

- **Slash commands**: Run Autter commands straight from Slack.
- **Incident and PR alerts**: Sent to the channels you pick in notification settings.
- **Actions from the assistant**: Take incident and PR actions from the assistant.

### October 4, 2026 — Issue trackers and support tickets flow into Autter (New Feature)

Connect Linear and Jira from the Issues page and choose which team or project feeds each repo.

- **Support triage**: Tickets from Intercom, Zendesk or a signed webhook become Autter issues, with the customer's evidence attached, a root-cause analysis and a verified draft fix.

### October 4, 2026 — Critical root causes open a draft fix PR automatically (New Feature)

Critical root-cause results from Runtime and Issues now open a draft fix PR automatically.

- **Reviewers per repo**: Each repo chooses who reviews these: an on-call reviewer, team leads, or automatic review for low-risk changes.
- **Review state and audit history**: Incident pages show review state and audit history, and you can export the audit log.
- **Email notifications**: Opted-in recipients get an email with the PR link.

### October 4, 2026 — Simulations in PR review test scenarios against your real code (New Feature)

Autter writes up to six scenarios based on the diff and runs them against your real code. Results appear in the test comment and the Tests tab.

- **Base-commit comparison**: When a scenario fails, Autter re-runs it on the base commit to tell whether the PR caused the failure.

### October 4, 2026 — More data over MCP, and a map of what changed in each PR (New Feature)

The new get_repo_index MCP tool reads 26 index datasets: structure, dependencies, APIs, tests, architecture, decisions and review outcomes. get_learnings can now filter and page.

- **PR change map**: The PR page shows a map of what changed.
- **Repository board**: The repository board shows how repos relate to each other.

### October 4, 2026 — Runtime adds a service topology graph, auto-closing incidents, and drafted postmortems (New Feature)

Runtime now shows how your services connect and closes the loop on incidents once their fix merges.

- A service topology graph with error rates, latency and deploy context
- Incidents close automatically when their fix PR merges, and Autter drafts an editable postmortem
- Memory-pressure incident tracking
- CSP violation detection
- Continuous profiling in SDK 1.3.x

### October 4, 2026 — Fix PRs make real code changes, and draft PRs stay in sync (Improvement)

If the first model only returns a plan, a second model makes a full attempt. Each fix PR describes the regression scenarios it tested and the commands it ran. If no PR can be opened, Autter tells you why.

- **Draft PRs**: Draft state stays in sync between the board and the PR detail view, and the merge dialog explains that a draft must be marked ready on GitHub first.

### October 4, 2026 — CLI 2.1.0–2.2.0: update prompts, smarter doctor, and verified installs (Improvement)

Two CLI releases focused on setup, diagnostics and safer installs.

- Interactive update prompt
- autter doctor suggests the next command to run
- doctor and bg status report upload failures consistently
- New system investigation commands
- Fixes for stalled uploads
- The npm installer only installs checksum-verified binaries

### October 4, 2026 — Sign in with Google, GitHub or a Passkey (Improvement)

Sign-in by email code is gone. You can sign in with Google, GitHub or a Passkey.

### September 21, 2026 — Repository dashboards bring health, scans, indexing, and activity into one place (New Feature)

Repository dashboards now bring key information into one place, including repository health and runtime metrics, codebase scan history and progress, indexing status with estimated completion time and per-card states, provenance and repository-specific activity, and open pull request counts.

- **Repository-level settings with autter.yaml support**: Teams can now manage organization and repository configuration together in a single file.

### September 21, 2026 — Sync your documentation with Confluence in both directions (New Feature)

You can now connect Confluence to Autter and sync content in both directions. The new connector also supports automatic wiki publishing when generation completes.

- **Bidirectional sync**: Content flows both ways between Autter and Confluence, keeping documentation current.
- **Auto-publish on generation complete**: Wiki pages are automatically published when Autter finishes generating documentation.

Notion connection handling and context-source management have also been improved.

### September 21, 2026 — PR reviews gain richer context, verification, and recovery handling (Improvement)

PR reviews now include richer semantic context, improved finding verification, auto-rebase support, retry and recovery handling, and better handling of stale reviews and review-thread events.

- **Live GitHub file fallback**: Autter falls back to live GitHub files when repository data is unavailable.
- **Review status hidden until gate finishes**: Review status now stays hidden until the review gate finishes, so Safe to merge appears only when the review is ready.

### September 21, 2026 — Detect and respond to incidents faster with lifecycle actions and reconciliation (New Feature)

Incident management now includes lifecycle actions, notifications, runtime monitoring, investigation endpoints, and reconciliation workflows.

- **Fix PR notifications**: When Autter creates a fix PR from an incident, you'll receive an in-app notification.
- **Proactive recommendations trigger investigation**: Proactive recommendations can trigger AI investigation, manual refreshes, resweeps, and on-demand fix PRs.

### September 21, 2026 — Indexing handles incremental updates more efficiently (Improvement)

Indexing now handles incremental updates more efficiently by reusing repository snapshots, skipping unchanged files, and cleaning up verified data.

- **LLM analysis focuses on code changes**: This helps control AI usage while keeping reviews relevant.
- **Expanded API endpoint detection**: Now covers more frameworks including Node.js, Cloudflare, Rust, and Spring.

### September 21, 2026 — Faster and more economical AI processing across runs (Improvement)

We upgraded the AI routing layer to use faster, more cost-efficient models across runs. Improved fallback handling also helps keep reviews, scans, and agent workflows moving when a model reaches a temporary limit or becomes unavailable.

- **Faster, more cost-efficient models**: AI routing now uses faster, more economical models across reviews, scans, and agent workflows.
- **Improved fallback handling**: Runs keep moving when a model reaches a temporary limit or becomes unavailable.

### September 21, 2026 — More reliable integrations and platform workflows (Improvement)

This release also includes improvements across GitHub OAuth, onboarding, CLI handling, webhook processing, Slack notifications, browser storage, accessibility, and scheduled jobs.

- Improved GitHub OAuth and onboarding flows
- Organization-less workspace creation during authorization
- Better CLI version handling and setup
- Faster webhook processing
- Slack notifications for configuration sync events
- Safer browser storage handling
- Keyboard shortcuts and accessibility improvements across the dashboard
- More reliable scheduled scans, agents, and runtime jobs

### August 18, 2026 — Autter now flags problems in your code before they cause an incident (New Feature)

Runtime Incidents gains a fourth, forward-looking category. Where the existing monitors react once something breaks or slows down, this one looks at your codebase and your traffic patterns together and calls out what is likely to go wrong next: churn hotspots, files only one person understands, dependencies with known vulnerabilities, and routes whose traffic or latency is quietly trending toward trouble.

- **The same investigate-and-fix loop as everything else in Runtime**: Each recommendation opens as an incident with its reasoning and evidence, and if a safe, behaviour-preserving fix exists, Autter opens a pull request for it.
- **Honest when it cannot help**: If nothing safe can be done automatically, the recommendation stays as guidance with its reasoning on the timeline, the same posture as a performance incident with no available optimisation.
- **Checked weekly, per repository**: Runs on a slow, deliberate cadence, and never repeats a recommendation the reactive error, performance, or AI-cost monitors already raised.

### August 18, 2026 — Pull request review effort now matches the size of the change (New Feature)

A one-line documentation edit used to come back with findings, a task checklist, and a blocked merge, each individually defensible but absurd together, and exactly the kind of thing that teaches people to stop reading the review. Autter now decides how deep a review needs to be before it spends a single AI call on it.

- **Four depths**: Documentation-only changes get a light skim, still checked for an accidentally pasted secret. Small, ordinary code changes get a lighter pass. Everything else gets the full review it always got.
- **Never lighter where it matters**: Database migrations, CI configuration, dependency files, and anything touching authentication or billing always get the full review, however small the diff. A small change to a file used across dozens of others is escalated the same way.
- **Shown, not hidden**: The review depth and the reason for it are printed on the check run and the gate summary, so it is never a mystery why a review came back quickly.

### August 18, 2026 — A new command line tool tells you, in one shot, whether Autter is actually working (New Feature)

`autter doctor` checks everything that has to be true for Autter to capture and attribute your work correctly: your git setup, the background service, editor hook installation, and your account connection, and finishes with an end-to-end test that makes a real checkpoint and confirms it was attributed correctly.

Every failed check comes with a specific fix line rather than a bare red mark, and a broken install now points you straight at this command instead of a general troubleshooting dump.

### August 18, 2026 — Two ways the review page could say one thing while showing another (Improvement)

Both fixes are about the pull request review page contradicting itself: the written verdict saying one thing while the findings table underneath it said another.

**A reverted change no longer shows the old findings as current**

Push a change that undoes every edit in a pull request, and the dashboard would briefly say there was nothing to review, then quietly bring back the previous version's findings as if they still applied. The dashboard now marks a summary as belonging to an older revision whenever that is the case, and a genuinely emptied diff is recognised and closed out immediately instead of running a full review against nothing.

**The written summary now agrees with the findings table**

The pass/fail wording could say no findings remain while the table right below it still listed one, because the two counted findings differently: the summary quietly excluded ones a later, more careful pass had already ruled out as false positives. Both now count the same way, and the summary explicitly says when a finding was dismissed rather than acting as though it was never raised.

### August 18, 2026 — On the free plan, your one repository slot is now permanent (Improvement)

The free plan includes one connected repository. Disconnecting it no longer frees that slot for a different repository, it only removes the repository you disconnected. This closes a gap where the single-repository limit could be worked around by disconnecting and reconnecting a different project.

Reconnecting the same repository is always fine, and nothing changes on paid plans, where swapping which repositories are connected was always intended to work. If you are genuinely stuck, upgrading remains the way through, and every screen that could previously read as an invitation to swap repositories now says plainly that it is not.

### August 18, 2026 — A dashboard error affecting every account is fixed (Improvement)

The main organisation dashboard could fail to load entirely. The cause was a database query bug in how a list of email addresses was passed to the database, and it affected every account, not only new ones, which is where it was first noticed.

A few quieter side effects sharing the same root cause are fixed with it: empty language breakdowns, empty AI-authorship figures when a repository filter was applied, and commit summaries regenerating on every load instead of loading from cache.

### August 18, 2026 — Runtime telemetry now survives a slow or restarting service (Improvement)

Error and performance data travelled from your service to Autter as a single best-effort delivery: a deploy, a network blip, or a slow moment on our end could silently drop the batch, and with it the specific errors it carried.

Delivery is now at-least-once end to end. Your service's monitoring library retries with backoff when a send fails, and duplicate retries are recognised and only counted once on our side. A background reconciler also runs every fifteen minutes comparing what should have arrived against what actually landed, and quietly backfills anything that slipped through.

### August 18, 2026 — Runtime event counts are accurate again, and every error occurrence is inspectable (Improvement)

Some services were showing issues detected correctly while every event counter next to them read zero, because error events were never being counted into the numbers that back those counters. That is fixed: request and error paths now feed the same totals.

Alongside it, expanding an error group now loads its actual recent occurrences, time, route, status code, release, and trace, instead of only the frozen summary captured when the issue was first seen.

### August 18, 2026 — A retained error now keeps the trace that explains it (Improvement)

Errors are always captured in full, but the request trace around them was sampled at a low rate, so opening a retained error usually surfaced the error itself and nothing that led to it.

Autter's runtime library now recognises when a trace contains an error partway through and keeps the whole trace, not just the error span, so you land on the full story instead of one isolated data point. This closes the same gap already fixed for AI call traces.

### August 17, 2026 — Running jobs moved out of a floating toast and into the notification bell (Improvement)

A fixed toast in the corner of the screen tracked scans, indexing, and documentation generation as they ran, but it covered page content, did not reposition itself, and vanished without a trace once the job finished.

That tracking now lives in the header's notification bell: a small badge while anything is running, a list of in-progress jobs you can click through to, and a permanent record left behind once each one completes.

### August 17, 2026 — Indexing narrates itself during setup, and the completion email waits for your whole fleet (Improvement)

Two fixes to how indexing communicates itself during setup: what you see while it runs, and when the completion email actually arrives.

**What you see while it runs**

The setup screen used to show an indeterminate progress bar while your first repository was indexed. It now shows the same plain-language stages the dashboard already had, fetching your code, reading every file, mapping how it connects, writing up what was learned, expanded from six stages to seven for more granularity, plus a live file count as it works.

**One email instead of several**

Connecting more than one repository at once used to send a separate indexing-complete email per repository, sometimes before the others were even done. The email now waits until every repository in the batch has finished and names the ones it is reporting on together.

### August 17, 2026 — The sample-data indicator now matches what is on screen (Improvement)

Exploring Runtime with sample data filled every tab with fictional telemetry, but the status pill next to the page title still pulsed "waiting for your first event." The header now shows an amber "Sample data" pill for as long as sample data is on screen, so it is never ambiguous whether what you are looking at is real.

### August 17, 2026 — The terms-of-service popup no longer appears twice on first login (Improvement)

A timing race between the terms-acceptance step and the welcome animation could show the terms card, replace it mid-entrance with the welcome film, then show the terms card again once the film finished. Both steps now share one sequencing, so each part of first login shows exactly once.

### August 17, 2026 — A single crashed query no longer stops your machine's attribution syncing for good (Improvement)

A database hiccup during a background sync could leave the CLI's background service unable to sync anything else, attribution, metrics, notes, until it was restarted by hand, with only a generic panic line to explain why.

That failure now recovers automatically: the connection is dropped and re-established instead of staying wedged, and the underlying cause is now logged clearly if it happens again.

### August 16, 2026 — Autter now reads your TODO comments, not just your code (New Feature)

A new review check family reads the to-do-style comments already in your codebase and flags the ones that carry real risk, in both pull request review and codebase scans.

- **"Do not ship this" comments**: Phrasing like "do not merge", "remove before release", or a lingering WIP marker is flagged directly on the pull request.
- **Markers that admit a known problem**: FIXME, HACK, XXX and similar, with no linked issue behind them, are called out as risk with no paper trail.
- **Disabled tests**: Skipped or pending tests are flagged wherever a test suite has quietly stopped running part of itself.
- **A repository-wide view**: Codebase scans get a new TODOs tab inventorying every marker with its age, so a note from eight months ago reads differently to one from yesterday.

A marker linked to an issue number or a ticket is treated as tracked debt, not a problem. The point is encouraging a paper trail, not banning TODOs outright.

### August 16, 2026 — See what your AI-assisted development actually costs, by day, team, and person (New Feature)

The AI Provenance tab now estimates spend from the token usage your CLI was already recording, with nothing new to set up. Costs show as a daily trend, split by team and by model, with a per-person table underneath.

Figures are estimates from public list pricing, so a flat-fee subscription seat will not map exactly to what you are billed, and models Autter cannot yet price are called out explicitly rather than silently left out of the total.

### August 16, 2026 — Fixed three separate ways your AI-attribution history could quietly go missing (Improvement)

This batch of CLI fixes centres on one theme: attribution that disappears without a trace is worse than attribution that was never captured, because nothing tells you to go looking for it.

**A normal git outcome was read as a failure**

Two commits sharing no common history is an entirely ordinary answer for git to give, but the CLI treated it as an error and used that as a reason to skip attribution processing for the whole surrounding pull. It no longer does.

**Local-only mode stopped writing attribution after a settings change**

Switching from connected mode to local-only should move attribution storage to git notes on your own machine. Instead, the background service kept using its previous setting until restarted, so local-only installs were silently degrading to plain git blame with no attribution at all. Changing modes now takes effect immediately.

**One bad rebase could poison every rebase after it**

Rebasing onto history with no common ancestor, the same case as the first fix, left behind a marker that could never be resolved, and that marker was retried ahead of everything else on every later rebase, permanently blocking attribution from being restored. That marker is now recognised and skipped instead of retried forever, and repositories already affected repair themselves on their next rebase.

**Server-side squash merges are now recovered automatically**

When a pull request is squash-merged through GitHub or GitLab's own merge button, the resulting commit is created server-side with no attribution note attached. Autter now recognises this after your next pull and reconstructs the note from your local branch automatically, the same recovery a manual command already offered, without needing to run it by hand.

### August 16, 2026 — Every way to install the CLI now works, including two that did not (Improvement)

Three separate install-path problems, found close together, are fixed together.

**Windows installs are no longer broken**

Windows binaries were missing from recent releases entirely, so the advertised download 404'd, and the PowerShell installer's architecture detection could crash outright on some machines. Windows binaries now ship with every release, and installer failures explain specifically what was tried and why it failed instead of a bare HTTP error.

**npm install now works**

npm i -g autter previously failed outright. The CLI now also publishes as @autter/cli, so npm i -g @autter/cli works too, still giving you the autter command.

**PATH activation is reliable on first install**

Following the installer's own advice to reload your shell configuration did not always put autter on your PATH, depending on which shell file you had open. The installer now writes a small activation file and prints one command, guaranteed to work, as the very last thing it does.

### August 16, 2026 — Editor integration is more honest about what actually installed (Improvement)

The VS Code extension install step now verifies the extension actually appears installed before reporting success, rather than trusting an exit code alone, with a specific reason shown on failure.

Separately, VS Code's built-in Copilot agent had silently stopped producing checkpoints after an editor update changed how it exposes agent hooks. `autter install-hooks` and `autter debug` now speak the current version of that integration, with a new section in `autter debug` showing exactly which link in that chain, if any, is broken. Commits authored by cloud AI agents are also now attributed consistently between `autter blame` and `autter stats`, instead of counting as untracked in one but not the other.

### August 15, 2026 — Connecting your AI models now takes one line of code (New Feature)

Setting up AI monitoring used to mean a multi-step configuration walkthrough. Now the LLM tab shows you a single line to add, plus a prove-it-works button that sends a harmless test call, no tokens spent, no real request made, so you can confirm everything is wired up before you go anywhere near production traffic.

- **The page updates live**: The moment that test call lands the tab reflects it, so there is no guessing whether it worked.
- **Or let the setup agent do it**: The agent instructions now handle the wiring and run the verification for you automatically.

### August 15, 2026 — Slow and expensive AI calls now get flagged within minutes, not the next day (New Feature)

Autter now checks your AI traffic every ten minutes instead of every half hour, and it is watching for two new problems. In practice this means you find out about a slowdown or a runaway bill while it is happening, rather than discovering it in the next day's numbers.

- **It learns what normal looks like**: For each individual model you use, Autter learns the typical response time and raises a flag when responses start dragging well past it.
- **Runaway single requests get named**: Any one request that costs an unusually large amount on its own gets called out, the classic sign that a prompt has quietly ballooned or an output ran away with itself.

### August 15, 2026 — Autter can now open a pull request that fixes an AI performance or cost problem (New Feature)

When a slow-response or expensive-call flag fires, Autter does not just tell you, it investigates. It gathers the worst offending calls, then traces backwards to find which part of your application actually triggered them, so it understands the real context rather than just the symptom.

- **Safe fixes arrive as pull requests**: If there is a safe, behaviour-preserving improvement available, caching, trimming a prompt, capping tokens, adding a timeout or a retry, batching requests, it opens a pull request with the change for you to review.
- **Honest when there is no safe fix**: If it decides a safe fix does not exist, it says so on the incident timeline and explains its reasoning, so you are never left wondering whether it looked.

### August 15, 2026 — A daily summary of your AI spend and health, delivered to your notifications (New Feature)

Every organisation with AI traffic now gets one report per day: what you spent and how that compares to yesterday, how many calls and tokens went through, your error rate, typical and worst-case response times, how many slow or expensive calls got flagged, your busiest model, and where you stand against your budget.

It arrives in the same place as your budget alerts and links straight through to the full view. If your error rate climbs or new flags appear, the summary is marked as needing attention so it does not blend into the background.

### August 15, 2026 — See your slowest and most expensive calls at a glance (New Feature)

The LLM tab has two new cards listing your worst-performing requests side by side, one ranked by response time, one by cost. It is the fastest way to go from our AI bill went up to this is the exact request that did it.

Each entry shows the tokens used, what it cost, how long it took, whether it errored, and a reference you can use to dig into that specific call.

### August 15, 2026 — The Runtime LLM tab no longer shows an error before your first data arrives (Improvement)

Some organisations were seeing the LLM tab fail to load entirely. The cause was a timing gap: the dashboard was ready to read AI usage data slightly before the system that stores it had finished preparing.

Now, when that data store is not ready yet, the tab simply shows its normal setup and getting-started view instead of an error page, and the same protection applies automatically to any future data we add, so this class of problem cannot resurface. The background monitor that was quietly failing on the same issue every sweep is fixed too. The original outage was already resolved on our side before this change shipped; this closes the door on it happening again.

### August 15, 2026 — The pieces behind the one-line install all landed together (Improvement)

This dashboard work landed alongside matching updates to our runtime library and setup skills, so the one-line install, the automatic tracing, and the built-in verification step all arrived together rather than in pieces. We also cleaned up an internal data-formatting issue that had been making one of our source files hard to review, invisible to you, but it makes our own changes easier to check going forward.

### August 13, 2026 — Your first repository gets scanned automatically, with no button to find (New Feature)

Connect your first repository and Autter queues a fast scan for you, starting it the moment indexing finishes. It runs a focused set of checks, secrets, dependencies, configuration, licence and inventory, access rules, and AI-specific risks, so you get real results in minutes instead of waiting to work out where to click.

- **Labelled for what it is**: The header marks it as a Quick scan, and a tooltip explains what the deeper full sweep adds when you are ready for it.
- **It does not cost you a scan**: The automatic first scan never uses up your monthly allowance, paid or free.

### August 13, 2026 — Scans now tell you what needs your attention, not just a number (New Feature)

Every scan surface now leads with a Needs attention count covering only the critical, high, and medium findings: the results header, the overview tiles, the findings list, the shareable PDF, and the Slack notification. The findings list opens filtered to those by default, with all severities still one click away.

Previously a repository with a long tail of low-severity informational notes could look alarming at a glance. The headline number is now the short list you would actually work through.

### August 13, 2026 — Autter names a real finding in your own code, right away (New Feature)

Instead of telling you it surfaced 199 findings, your dashboard scan cards now show the single most important thing found.

- **In the repository summary**: After indexing, the top finding sits front and centre with its description and location.
- **A one-time spotlight**: After your organisation's first completed scan, a spotlight card names the finding directly, with the exact file and line.

### August 13, 2026 — A scan-complete email that actually tells you something (New Feature)

When a scan you triggered finishes, the email now narrates the most important finding rather than just saying done. It also explains the difference between the quick scan and the full deep sweep, so you know what your next step is. This closes the loop the scan started email had been promising.

### August 13, 2026 — Installing the command-line tool on Windows now just works (Improvement)

The install command we show you now runs correctly whether you paste it into Command Prompt, Windows PowerShell, or PowerShell 7. Previously it only worked in PowerShell and failed with a confusing syntax error anywhere else.

The setup guide also gained a quick step to confirm the install succeeded, plus a reminder to restart your terminal so the command is found. An entire category of it did not work and I do not know why has been removed rather than documented around.

### August 13, 2026 — The Runtime tab in the public demo no longer crashes (Improvement)

Opening Runtime in the try-it-yourself demo workspace previously failed every single time, showing a blank error page instead of the product. The demo now serves proper sample data for the overview, incidents, errors, services, and deployments views, and every one of those pages plus the demo home renders cleanly.

**Filters behave like the real thing**

As part of the same fix, filtering in the demo actually filters: choosing an environment like staging narrows the KPIs and incident list to that environment, and the Errors tab's Resolved filter returns only resolved issues. Before, every filter returned the full sample set, which made the demo feel broken even once it loaded.

**Missing data no longer breaks a page**

The pages handle incomplete data gracefully now, showing an empty or could not load state instead of breaking.

### August 13, 2026 — Severity drives the risk score, not volume (Improvement)

The scoring behind the risk number was rebalanced so severity, rather than the sheer volume of minor notes, drives it. Alongside it, the scan pipeline learned to run a lighter, safely reduced set of checks for the new automatic first scan without ever counting against your usage, and our notification infrastructure was extended so scan results can be emailed straight from the scanning engine.

### August 12, 2026 — Setup is four steps instead of nine, and the waiting does something (New Feature)

The standard signup path collapses into a single setup hub that runs while your repository is being indexed, rather than making you click through informational screens first. A live status card shows exactly which repositories are being processed, and underneath it there are tabs to install the CLI, connect your observability tools, invite teammates, and link your GitHub account. The flow ends by offering to run your first codebase scan, so you leave onboarding having seen Autter actually do something.

**What changed in the flow**

- **Setup runs during indexing**: The hub is usable while the index builds in the background, not after it.
- **A real Windows install command**: The install guide now offers PowerShell. Previously it only ever showed the Mac and Linux command, even though Windows was supported.
- **Onboarding finishes itself**: When indexing completes you land on your dashboard a couple of seconds later, instead of the screen sitting on a green checkmark waiting for two more clicks. If indexing ran into problems Autter deliberately does not auto-advance, so the warning stays on screen where you can read it.
- **One GitHub step instead of two**: Installing the app links your personal profile at the same time, on the same screen. Signing up used to ask you to connect to GitHub twice.

**Your remaining steps became a live checklist**

The finish setting up section on the dashboard is now a proper checklist with a progress bar, and each step ticks itself off automatically based on what you have actually done: a scan that has been run, the CLI detected on your machine, observability data arriving, a teammate invited, your GitHub account linked. Hints are personalised with the repository name to scan, how many teammates you have, and which GitHub account you are connected as, and the header flips to a done state when you finish. It replaces a section that previously looked half-finished, with content floating in empty space.

**Two things to know**

- Teammates who never install anything themselves get a new Your GitHub account card in Settings, Source Control, which is also the first place in the product where you can disconnect a personal GitHub link.
- Linking your profile during app installation needs a small configuration change on our side to switch on, and behaves exactly as before until then.

### August 12, 2026 — Bring your own monitoring: Sentry, PostHog, Grafana, or any webhook (New Feature)

You no longer need to be using Autter's own runtime SDK to get incident investigation and automated fixes. Alerts from Sentry, PostHog, Grafana, or any tool that can send a JSON webhook now flow into the same incident pipeline: Autter correlates them with recent deployments and pull requests, investigates the root cause, and can open a fix pull request.

- **You choose how far it goes**: Per source: just collect the data, investigate it, or investigate and auto-fix.
- **External alerts open an incident immediately**: Your monitoring tool already decided the alert was worth firing, so these skip Autter's usual volume threshold. When your tool marks it resolved, Autter closes it too.
- **Data Sources settings is fully working**: Previously a set of preview cards, now setup instructions per tool and a copyable webhook address.

### August 12, 2026 — Autter Runtime now catches slow code, not just broken code (New Feature)

A new monitor sweeps your runtime data every half hour looking for operations that are both slow and frequent, web routes and background jobs alike. When it finds one it opens a performance incident, marked with a violet PERF badge in Runtime, Incidents, correlates it with recent deployments, and runs an automated analysis using real trace evidence to work out where the time is actually going.

- **The same loop, extended to latency**: Detect, investigate, fix. If there is a safe optimisation, Autter opens a pull request with the change and a test proving it.
- **It tells you when it cannot help**: If it decides the code cannot safely be optimised, it says so on the incident timeline rather than staying silent.
- **No nagging**: An unresolved slow process will not re-alert for a week.

### August 12, 2026 — Environment variables for your repositories, so checks run against real configuration (New Feature)

The repository Environment variables tab is no longer a placeholder. You can paste in a .env file as a named bundle and choose which parts of Autter's testing it feeds, builds, tests, or app startup, so checks that previously stalled on missing configuration now run properly.

- **Import from a secret manager**: AWS Secrets Manager, Doppler, and Infisical, with a Sync now button to re-pull.
- **Missing variables get named**: Autter shows which variables your repository declares that you have not configured yet, and a failing build check names the missing variable and points you at the tab.
- **Write-only by design**: Nothing in the product or its APIs ever gives a value back. Only variable names are ever displayed.

### August 12, 2026 — Scans that fail now look like it (Improvement)

Two fixes on the same screen: first scans that failed with a raw internal error, and failed scans that still rendered a clean bill of health.

**First scans no longer fail with a raw technical error**

New users running their first codebase scan could hit a failure with an unfriendly internal error message printed directly on the dashboard. The underlying configuration gap in our processing infrastructure has been corrected and affected scans have been repaired. Beyond that, we changed the behaviour so this class of problem cannot fail a scan at all: a scan that cannot be dispatched right away now stays safely queued, and a new background sweep picks up anything waiting more than a few minutes and runs it. Internal error details go to our logs only, and you see plain-language status instead.

**Failed scans stopped pretending they succeeded**

A scan that failed partway through could still render a green shield, risk scores, and a No findings summary, reading as a clean bill of health when it was nothing of the sort. Failed scans now show a red indicator and a clear panel saying the scan did not finish, with the scores suppressed.

**In the same pass**

- The CLI install prompt no longer stacks up in three places at once.
- The Settings CLI screen recognises when you have already connected, instead of pitching a feature you are using.
- An architecture map message that implied your repository was not indexed when it was.
- Two pieces of misleading copy, one about how prompt data is stored, one about how CLI credentials work.

### August 12, 2026 — One blocking-issue count, and verdicts that update after the deeper pass (Improvement)

The pull request page is the one screen meant to tell you whether a merge is safe. Two ways it could mislead you are now fixed.

**Every count on the page agrees**

On a demo trial the page header said 7 hard blocks while the summary right below it said 10. The mismatch came from different parts of the page counting findings differently: some included findings the verification pass had already refuted, some did not. Every count now uses the same rule as the merge gate itself. Refuted findings still appear in the list, counted separately and labelled, so the arithmetic on screen adds up.

**The verdict is recomputed after the deeper analysis**

A test pull request with a deliberately broken import and a hardcoded API key still read 0 findings, 157 checks passed, approved and merge-ready, even though the deeper analysis pass had caught the broken import by actually running the code. The verdict had been posted earlier and nothing ever revisited it. It is now recomputed when the deeper pass completes: new problems supersede the approval with a change request and turn the check red, and if the deeper pass instead refuted the findings that were blocking, the gate re-opens. Check counts, the pill grid, and the dashboard cards all update to match.

**Keys labelled fake are no longer discarded silently**

API keys labelled fake or dummy were being silently discarded before detection ran, which is indistinguishable from not noticing them. They now surface as a clearly labelled low-risk note, so you can see the detection worked, and they never block a merge on their own.

### August 12, 2026 — Automated fix runs always report back (Improvement)

An automated fix run could announce that it was processing fixes and then go completely silent, with no branch, no follow-up, and no explanation, when its internal safety checks decided not to ship a patch. Every one of those quiet exits now posts a closing comment explaining what happened.

**Effort spent where a patch can help**

The fixer no longer works on findings that no patch can resolve, things like a missing linked issue or a pull request that mixes a refactor with a behaviour change. Those now get their own checklist comment addressed to you, so you can work through your half while the agent handles the automatable half, and they no longer crowd out real fixes.

**Closed pull requests are handled honestly**

Ticking the fix option on a pull request that was already closed used to start a job that could never run, leaving a processing message hanging forever. You now get an immediate reply explaining that fix runs only target open pull requests, and a run that is mid-flight when a pull request closes is cancelled with a comment instead of vanishing.

**The patch-safety check always uses the best model**

The final safety check that decides whether a generated patch is good enough to ship was being served by the economy model on lower plans, and was withholding perfectly sound fixes. That one check is now exempt from plan-based model selection for everyone. It is a tiny call, and the wrong place to economise.

### August 12, 2026 — Every CLI install screen now explains why you need it (Improvement)

People kept asking a fair question: "I just connected my repository to GitHub, why am I also installing something on my machine?" Each install screen now leads with a one-minute setup badge and a short side-by-side explanation, and it shows up everywhere the install guide appears, not just during signup.

- The GitHub connection reviews pull requests and indexes your code in the cloud, but only ever sees finished commits.
- The CLI runs where the code is actually written and records who wrote each line as it happens, which cannot be reconstructed after the fact.

### August 12, 2026 — Two pieces of hardening behind the scenes (Improvement)

The processes Autter runs against your code, builds, tests, and app boots, no longer inherit our internal credentials: they get a deliberately scrubbed environment containing only your own configuration. Separately, the infrastructure that hands scans off for processing was audited and corrected after the first-scan failures above, with a backstop sweep added so a similar gap cannot strand your work again.

### August 9, 2026 — Search your pull requests by meaning (New Feature)

The Pull requests tab now has real search. Ask for what you mean rather than guessing at keywords: searching "is this safe from attackers" finds a pull request titled "fix: SQL injection in search endpoint", with no words in common.

- **Meaning, not keywords**: Describe the change you are looking for and matching pull requests surface even when the words differ.
- **Exact lookups stay instant**: Pull request numbers, branch names, and author names still resolve instantly.
- **List and Board agree**: Both views always show the same matches for the same query.

### August 9, 2026 — Two new review checks: row-level security and UI slop (New Feature)

The review engine gained two checks aimed at the failure modes of AI-built products: database rows anyone can read, and interfaces nobody edited. Both skip themselves entirely when a change does not touch the relevant area, so they add no cost to unrelated reviews. Test, fixture, and demo files are excluded.

**Row-level security**

Autter now checks Postgres row-level security posture on any RLS-reliant stack, including Supabase, Neon, RDS, Hasura, raw SQL, Drizzle, and Prisma. Available in pull request review and as a new RLS Security tab on codebase scans.

- Tables shipped without RLS enabled.
- Policies that let everyone through.
- Views and functions that bypass policies.
- Privileged keys exposed to the browser.
- Privileged queries that trust a client-supplied id.

**UI design slop**

Catches the tells of unedited generated interfaces before they reach production: the stock gradient hero, filler copy, leftover Lorem ipsum and Acme Corp placeholders, emoji standing in for real icons, and buttons that look clickable but do nothing.

### August 9, 2026 — See how much of Autter's review you actually act on (New Feature)

A new Review signal section on a repository's Health tab shows the acted-on rate: of the findings Autter surfaced, how many were fixed before the pull request merged, versus dismissed or ignored. You can finally see which checks earn their place and which are noise.

**The measurement**

- **Overall acted-on rate**: One headline number for the repository.
- **Week-by-week trend**: Whether the review is getting more or less useful over time.
- **Worst-first breakdown by check**: The checks costing attention without earning it sit at the top.
- **In your digest**: The headline number and the worst-performing check are included in the weekly digest email and Slack message.

**Reviews that tune themselves**

This measurement now feeds back into the reviews. A check with a persistently low acted-on rate in your repository is automatically moved out of inline comments: first into the summary, then out of the pull request entirely. Checks recover on their own if they start being useful again, and you can reverse a demotion.

### August 9, 2026 — Custom agents: schedules, email, and six new templates (New Feature)

Custom agents are no longer tied to pull request events. They can now run on a schedule, send email, and start from six new templates, and the agent builder's trigger step is reorganised into Pre-merge, Post-merge, and Scheduled.

- **Run agents on a schedule**: Daily, on weekdays, or weekly at a time you choose. Scheduled agents get a digest of recent activity, open and recently merged pull requests, as context.
- **Agents can send email**: A new Email tool is available to every custom agent. Agents can only email members of your organisation, never an outside address.
- **Six new starter templates**: Standup Summary, Weekly Review, PR Review Digest, Changelog Drafter, Dependency Update Check, and Release Notes Drafter.

### August 9, 2026 — Review depth follows who wrote the code (Improvement)

For repositories using the Autter CLI, the deepest parts of the review, the verification pass and the agentic follow-up, now prioritise code written by an AI agent that no human has since edited. Nothing gets less scrutiny than before, and nothing new is flagged: Autter just spends its most careful passes on the code least likely to have been read. Repositories not using the CLI are unaffected.

### August 9, 2026 — A faster start, and workspaces you can rename (Improvement)

New accounts get a workspace created for them at signup instead of having to fill in a form first, and you can rename a workspace and its URL from settings at any time.

One thing to know: renaming changes the workspace URL, so older links in already-sent emails and pull request descriptions will stop resolving.

### August 9, 2026 — Failures that hid themselves, fixed (Improvement)

Two fixes this week share a theme: failure should never be invisible. A review job that died partway through now reports itself, and a secret scan that never ran no longer looks like a clean one.

**Reviews were silently not posting for some organisations**

Accounts created before a settings change in mid-July stopped receiving pull request reviews around 4 August: the review job was failing partway through without reporting an error. This is fixed, and Autter now repairs this class of problem automatically. Pull requests missed during the outage need a new push or an @autter comment to be reviewed.

**A secret scan could report a clean result when it never ran**

If the AI provider was unavailable, the secret scanner returned an empty result that looked identical to a clean scan. Scans affected by a provider outage are now clearly marked as incomplete.

### August 5, 2026 — Stacked pull requests are now first-class in Autter (New Feature)

GitHub recently introduced native stacked pull requests, and Autter now speaks that language fluently. A stack shows up as a single entry on your dashboard instead of flooding the list with rows that only make sense read together, with a map of the layers and each one's position, and you can land the whole stack from the dashboard. The old merge button simply could not do that.

**Reading a stack**

Stacks built with other tools like Graphite or Sapling are detected and displayed too, clearly labelled so you always know which ones GitHub can merge for you and which it cannot.

- **One entry per stack**: Layers group together instead of scattering across your list.
- **Layer map with positions**: See the shape of the stack and where each pull request sits in it.
- **Third-party stacks detected**: Graphite and Sapling stacks are labelled for what they are.

**Merging a stack**

Three things come with it that we think you will feel immediately.

- The merge gate now agrees with GitHub. Instead of a vague warning that a pull request below is not ready, Autter names the layer and the finding holding the stack up.
- An issue found low in a stack is no longer re-reported on every layer above it, so review comments stay readable.
- The merge confirmation names every pull request that will land with it. No surprises.

**Cost**

Reviews across a stack are cost-aware by default, giving full attention to the layers that need it instead of re-reviewing overlapping work several times over.

### August 5, 2026 — Autter can now propose how to split a large pull request into a stack (New Feature)

Open a big pull request and Autter can suggest a way to break it into reviewable layers, worked out from how the code in your change actually depends on itself. Each proposed layer stands on its own rather than being chopped up by folder or file count.

- **Dependency-aware layers**: Splits follow the real structure of the change, not the directory tree.
- **Deterministic and free**: The same answer every time, at no extra cost.
- **Quiet when it should be**: No split suggested for small or self-contained pull requests.
- **Nothing happens behind your back**: Accepting a proposal records your intent and shows the commands to create the branches. Autter never rewrites your pull request for you.

### August 5, 2026 — Dependency chains now trace back to their origin in pnpm and yarn projects (New Feature)

If your repository uses pnpm or yarn, the Dependency Chain panel in your dependency inventory used to say origin unknown for every indirect dependency. That left the question that matters most during a security scare unanswered: what did we install that pulled this in?

- **Full paths reconstructed**: Works for pnpm and yarn across every common lockfile version.
- **Dev and production separated**: Development-only dependencies no longer get mistaken for ones that ship to users.
- **Inventories that were empty now fill in**: Some older pnpm projects listed no indirect dependencies at all and will now show a complete inventory for the first time.

### August 5, 2026 — Quieter errors, honest demo pricing, and reviews that stop cleanly (Improvement)

Three fixes that all remove work nobody asked for: phantom issues, wrong numbers, and reviews that kept running after their pull request had already shipped.

**Demo billing pages show the right prices again**

Plan pricing in demo workspaces had drifted and was displaying figures a hundred times higher than the real thing, along with out-of-date usage limits and overage rates. Everything is realigned to the actual published pricing in both US dollars and Indian rupees, and the sample usage figures now sit sensibly within plan limits so the progress bars tell an honest story.

**Error tracking is quieter and more useful**

A noisy class of errors caused by browser extensions, not by Autter or your code, was being captured and mixed in with real problems, where it buried genuine regressions. We now filter that category out at the source while being careful not to hide real failures that happen to look similar. The practical effect: fewer phantom issues competing for your attention.

**Reviews stop cleanly when you merge mid-flight**

If you merged a pull request while its review was still generating, Autter used to keep going: finishing a review nobody would read, then kicking off its heaviest follow-up work against code that had already shipped, sometimes opening a fix pull request for a pull request that no longer existed. Autter now recognises the merge, stops in-flight work where it is safe to do so, and never queues follow-up work for a closed or merged pull request. Questions you ask Autter directly on a merged pull request still get answered, because those are intentional, not waste.

### July 19, 2026 — A pull request board, stronger controls, and safer automation (New Feature)

Pull requests now have a dedicated board for managing review work, backed by stronger safeguards and more dependable automated fix runs.

**Review board**

- Added a pull request board view with clear columns for review status and requested changes.
- Added drag-and-drop pull request status updates for easier review management.

**Review controls**

- Strengthened review blocking for high-risk issues that could cause billing or financial impact.
- Added stricter free-tier limits for pull request reviews.
- Improved feedback handling with mute controls and cleaner display behavior.

**Security hardening**

- Fixed security gaps around file uploads, rendered content, external page fetching, and billing edge cases.

**Fix execution**

- Improved fix-run notifications and failure handling.
- Fixed review environment installation issues for more reliable automated runs.

### July 19, 2026 — Regional pricing, subscriptions, and usage metering (New Feature)

Pricing and subscription management now adapt more clearly across regions, with dependable invoicing and more complete usage tracking behind the scenes.

**Pricing and billing**

- Added dual-currency pricing with clearer subscription and cancellation flows.
- Migrated subscriptions to a new regional payment flow with support for coupons.
- Improved invoice generation so payments are reflected more reliably.

**Usage tracking**

- Routed coding-agent sessions through metering for better usage tracking.

### July 19, 2026 — Connected accounts and guided onboarding (New Feature)

A dedicated account-linking path and a more dependable guided setup now carry users from code hosting connection to a working demo with less friction.

- Added a dedicated account-linking flow for code hosting accounts.
- Improved onboarding reliability after account connection and app installation.
- Added copy-friendly demo setup details and a smoother guided onboarding flow.

### July 19, 2026 — Meet Autter MCP: review context and actions in your AI tools (New Feature)

The new Autter MCP server gives AI tools secure access to pull requests, review intelligence, repository health, and the actions needed to move review work forward.

- Added secure personal access tokens for MCP and other external tool access.
- Added the Autter MCP server with tools for reading pull requests, review results, learnings, repository health, dependency checks, and codebase insights.
- Added MCP actions for replying to review comments, resolving review threads, triggering reviews, and saving team learnings.
- Added analytics for MCP tool usage and intent capture.

### July 19, 2026 — Scoped build verification and safer automated testing (New Feature)

Build verification now scales to larger repositories, explains failures more clearly, and can exercise uncovered test areas against disposable databases.

**Build verification**

- Improved production build reliability across frontend and backend.
- Added scoped build verification for large repositories.
- Added clearer explanations when builds fail.

**Automated testing**

- Added automated test-plan grading and execution for uncovered test areas.
- Added disposable test databases for safer automated test runs.

### July 19, 2026 — More reliable connected workflows and notifications (Improvement)

Planning tool updates, scheduled checks, and weekly digests now stay in step more reliably and give teams better control over recurring notifications.

**Connected planning**

- Improved issue syncing reliability from connected planning tools.

**Schedules and notifications**

- Improved timestamp handling in alerts and suggestions so scheduled checks behave more reliably.
- Improved weekly digest notification settings.

### July 13, 2026 — Reviews that learn, verify, and act (Improvement)

Automated reviews now cover more of what makes software safe to ship, learn from the way each repository responds to findings, and turn confirmed issues into action with less friction.

- Added richer automated pull request reviews with more checks for security, reliability, performance, testing, documentation, and production readiness.
- Improved review accuracy by learning from user replies, reactions, and repository-specific feedback.
- Added stronger secret, dependency, and vulnerability detection across review workflows.
- Added configurable security alerts and weekly team digest notifications.
- Improved automated fix flows so selected fixes can be run directly from review options.
- Made high-risk money-loss findings block merges when confirmed by AI review.
- Improved nightly vulnerability scans with clearer repository summaries and better alert delivery.

### July 13, 2026 — Custom agents and post-merge automation (New Feature)

Teams can now bring installed and custom agents into the review pipeline, control what they are allowed to do, and continue automating work after a change lands.

- Added support for installed and custom review agents inside the review pipeline.
- Added sample agent templates and permission controls for custom automation.
- Added post-merge automation triggers so teams can run workflows after changes land.
- Improved review session routing, isolation, and diagnostics for more dependable automation.
- Fixed build, install, and environment issues that were blocking reliable review execution.

### July 13, 2026 — Clearer diffs, repository learnings, and live issue boards (Improvement)

The product now does a better job of showing where findings came from, carrying repository knowledge forward, and keeping issue activity current without a manual refresh.

- Improved pull request diff views with clearer findings, better navigation, and per-line authorship indicators.
- Added repository-level learnings and surfaced them in the repository overview.
- Improved onboarding with a guided demo path, interactive checklist, animations, and analytics.
- Added live issue-board updates so new issue activity appears without manual refresh.
- Connected inbound issue updates to the relevant repository board.
- Improved pull request provenance by fetching full commit history instead of partial results.
- Reduced noisy client-side errors in tracking so real issues are easier to see.
- Updated documentation and project guidance to better reflect the current product experience.

### July 13, 2026 — Engineering health analytics and safer sign-in (New Feature)

New dashboards connect day-to-day engineering activity with delivery trends, while authentication and other sensitive product surfaces received another round of hardening.

- Added engineering analytics dashboards for usage, performance, deployment activity, and team delivery metrics.
- Improved executive reporting for engineering health and delivery trends.
- Hardened sign-in and authentication flows, including safer error handling and reduced sensitive logging.
- Fixed multiple security gaps around uploaded files, rendered markdown, external fetches, and billing race conditions.

### July 1, 2026 — Stronger review gates and better conversations (New Feature)

Pull request reviews now combine enforceable merge controls with line-level conversations, assistant chat, and better context about every commit and its authorship.

- Added stronger pull request review gates to help teams catch issues before changes are merged.
- Improved the pull request review experience with clearer loading states, better error handling, and richer review status details.
- Added line-level review comments, comment threads, and reaction support for smoother review conversations.
- Introduced an AI-powered pull request assistant chat to help users understand and act on review feedback.
- Added per-commit insights so users can more easily see what changed inside a pull request.
- Added authorship insights to show how work was created and reviewed across pull requests.
- Added required status checks so review policies can be enforced directly in the development workflow.

### July 1, 2026 — Broader review coverage with fewer false positives (Improvement)

The review engine now checks more dimensions of production readiness, verifies uncertain findings after a review, and learns from the feedback teams leave behind.

- Expanded automated review coverage for correctness, performance, testing, documentation, internationalization, security, and production readiness.
- Added post-review verification so low-confidence or outdated findings can be checked and cleaned up.
- Added stronger secret-detection coverage.
- Added support for external quality and security scanners in the review pipeline.
- Added a feedback loop so review findings can improve based on replies and reactions.
- Improved model selection, caching, and diagnostics for automated review sessions.
- Fixed several scanner installation, parsing, and version-detection issues.

### July 1, 2026 — Automation, dependency alerts, and team digests (New Feature)

Merged work now refreshes project context automatically, dependency risks reach the right teams with configurable severity, and weekly digests keep quality signals visible.

- Added automatic re-indexing after merged pull requests so project context stays up to date.
- Added automatic handling for assistant mentions in comments.
- Improved automated fix workflows to avoid repeated or recursive runs.
- Added dependency risk alerts with configurable severity filters and team notifications.
- Added weekly KPI digest notifications for review and quality metrics.
- Improved indexing reliability and support for incremental updates.

### July 1, 2026 — Smoother connections and production reliability (Improvement)

Account connections are easier to complete, indexing is more dependable, and the production foundation received cleaner configuration, routing, and networking support.

- Improved onboarding and account connection flows for the code hosting integration.
- Improved infrastructure and deployment configuration for the production app.
- Added custom domain routing and updated deployment compatibility settings.
- Cleaned up unused analytics and deployment configuration files.
- Improved backend networking permissions and deployment options.
- Fixed documentation and connection support for the internal search and analysis service.

### June 21, 2026 — Secure sign-in, developer tokens, and the identity layer that stays out of your way (New Feature)

Three things shipped this week that all share a thread: getting into autter should be fast, safe, and never the reason work stalls. CLI sign-in is now secure by default. Account setup lost its friction. And personal access tokens give developers a proper way to connect their tools without sharing credentials.

**CLI sign-in and account setup**

The old flow had too many steps and not enough guardrails. The new one uses secure authentication by default, cuts the setup path in half, and gets you into a working environment faster.

- **Secure CLI sign-in**: No more plaintext credentials or manual config files.
- **Streamlined account setup**: Fewer steps from signup to first scan.
- **Personal access tokens**: Connect developer tools without sharing org-wide secrets.

**AI authorship insights**

autter now tracks how code was created. Every pull request shows whether a change was human-written, AI-assisted, or AI-generated. This is not a judgement. It is context. Reviewers see provenance. Leads see patterns. Nobody has to guess.

### June 21, 2026 — Sharper reviews, quieter noise, and analytics that actually tell you something (Improvement)

The review engine got better in the way that matters most: more accurate findings, clearer comments, and fewer false positives. When autter speaks up on a PR, it is because something real needs attention, not because a heuristic fired on a pattern it half-understood.

**Code review**

- **More accurate findings**: Fewer false positives reaching reviewers.
- **Clearer comments**: Suggested fixes are easier to understand and apply.
- **Faster fix suggestions**: Less time between finding and resolution.
- **Infra and config security checks**: Catches misconfigurations before they ship.
- **Improved dependency reporting**: Vulnerability notifications with actionable detail.

**Analytics**

Pull request and repository activity metrics are now clearer and more complete. You can see what is actually happening across your codebase without building your own dashboards.

**GitHub integration**

- Reviewer assignment works correctly across team configurations.
- Error messaging tells you what went wrong and what to do about it.
- Code indexing is more reliable for large projects: no more silent failures on big repos.

### June 21, 2026 — Interactive demos and the faster front door (New Feature)

Two changes to how people first experience autter. Demo workspaces are now interactive. You can click through a real environment instead of watching a video. And the demo signup flow lost its rough edges, so the path from curiosity to hands-on is shorter.

- **Interactive demo workspaces**: Explore a real environment without creating an account.
- **Smoother demo signup**: Fewer steps, fewer dropoffs, faster time-to-value.
- **Faster org creation**: New organizations spin up quicker and more reliably.

### June 21, 2026 — The quiet stuff that keeps everything running (Improvement)

Not everything that ships is visible from the outside. This week: progress notifications now include direct links to completed work, important account and billing actions are fully tracked, and deployment reliability improved across the board.

- **Progress notifications with direct links**: Go straight to the result instead of searching for it.
- **Complete audit trail**: Every important account and billing change is logged and traceable.
- **Improved deployment reliability**: Fewer incidents, faster recovery.

> Ship the gates, ship the guardrails, then get out of the way.

### June 14, 2026 — The review that sees everything (New Feature)

The PR review engine went from “good coverage” to “nothing gets past it.” It now checks for things most teams only catch after something goes wrong: static security, secrets, dependency and license compliance, CI/CD misconfigurations, auth and permissions, database migrations, frontend health, code hygiene.

**PR review: broader, sharper, quieter**

- **Dependency impact analysis**: Reviews understand what a dependency change actually touches downstream.
- **Typosquatting detection**: Packages that look like popular libraries but aren't get flagged before they land.
- **Cross-file consumer checks**: Changing an API? autter checks who's calling it before approving the change.
- **False positive reduction**: Fewer findings that waste your time. The ones that remain are the ones that matter.

**Infrastructure-as-code scanning**

IaC scanning is live. Terraform plans, CloudFormation templates, and Kubernetes manifests are now checked for misconfigurations before they ship. Three engines run independently, so coverage gaps from any single scanner get caught by the others. If you have ever deployed a security group that was wider than you intended, this is for that.

> A review engine earns trust by catching real problems and staying quiet about everything else.

### June 14, 2026 — Scan results that explain themselves (Improvement)

Scan results are no longer a list you have to interpret. They are a surface you can act from: every finding explains itself, and the ones that don't can be handed straight to autter for a fix.

- **Finding detail modals**: Every finding opens into a full explanation, not a one-line summary.
- **AI fix suggestions**: Ask autter for a recommended fix directly from any finding.
- **Business logic invariant views**: The specific rule, the specific violation, and the specific evidence.
- **Content-shaped loading states**: Scan results load progressively instead of appearing all at once.

### June 14, 2026 — The billing that runs itself (New Feature)

autter now has a full billing system with native subscription management. Teams can sign up, pick a plan, and start paying without a single manual step on our end.

- **Plan tiers and subscriptions**: Pick a plan, upgrade or downgrade, and usage adjusts automatically.
- **Hosted checkout**: Pay without leaving autter, with UPI and B2B invoicing included.
- **Invoice generation and backfill**: Current and historical invoices available on demand.
- **Usage visibility**: Your current usage is always visible in the sidebar and billing settings.

> A billing system earns trust by disappearing entirely. Billing should be something you set up once and never think about unless you want to.

### June 7, 2026 — The gate gets teeth (New Feature)

The merge gate shipped weeks ago. This week it became the kind of gate you actually trust: a full PR review engine and fifteen categories of automated checks. The previous version could block a merge. This one explains why it blocked it.

**PR review engine**

- **Chapter generation**: PRs are broken into reviewable chapters, not treated as a single diff.
- **Inline comments**: Review findings appear exactly where the code changed.
- **Summary utilities**: Every PR gets a structured overview before a reviewer opens a file.
- **Gate panels and overview UI**: Merge-blocking status is visible, not buried in a check run.
- **Local and Fargate runners**: Review runs wherever your infrastructure already lives.

**Fifteen review checks**

Static security. CI/CD security. API contract validation. Dependency and license compliance. Typosquatting detection. Secret scanning. Infrastructure-as-code misconfiguration. Race condition analysis. Logging hygiene. Privacy surface detection. Rate limiting coverage. Architectural conformance. Policy engine evaluation. AI slop detection. Each check writes to its own findings surface, and policy violations get deterministic hashes so repeated findings are tracked, not duplicated.

> A gate that checks fifteen things and tells you which one failed is not a gate. It is a review team that never takes a day off.

### June 7, 2026 — A review surface built for humans (Improvement)

All that machinery is only useful if the humans doing the reviewing can read it. The PR review UI got the treatment: scannable activity, a proper diff engine, and comments that feel like conversation.

**PR review UI**

- **Monaco-based diff viewer**: Diffs render with the same engine your editor uses.
- **Conversation timeline**: Comments, suggestions, and gate decisions in chronological order.
- **Keyboard shortcuts**: Navigate reviews without reaching for a mouse.
- **Activity feed styling**: Review events are scannable instead of a raw log.

**Comments, mentions, and GIFs**

Inline comments now support full Markdown. Mentions are wired in. The GIF picker is live. This is the kind of feature that makes review conversations feel like conversations instead of form submissions.

### June 7, 2026 — Richer webhooks and Slack routing (Improvement)

Webhook ingestion got sharper, and PR review and scan events now route to Slack with per-event webhook support. Teams configure which events fire, where they land, and whether a gate decision triggers a notification or stays silent.

- **Delivery logging**: PR events are logged with enough detail to debug routing.
- **Writeback detection**: autter's own comments no longer trigger recursive review processing.
- **Gate-skip tracking**: See what bypassed enforcement and when.
- **Automatic schema bootstrapping**: New repos need no manual setup before gates start working.

### May 31, 2026 — The merge gate goes live (New Feature)

The merge gate is no longer a concept. This week autter shipped merge-blocking PR review gates, a full review pipeline with diff parsing and summary generation, and the webhook infrastructure to drive it all natively through GitHub.

**PR review pipeline**

- **Diff parsing and summaries**: Every PR gets a structured breakdown before review agents run.
- **Merge-blocking review gates**: Review output is evaluated before a pull request is allowed to merge.
- **Durable PR tracking**: Revisions, metadata, and migration safeguards for org databases.
- **GitHub-native webhooks**: PR, review, and comment events route through rebuilt handlers.

**Secret scanning, rebuilt on TruffleHog**

Detection runs across full git history, not just the current state. The previous version found secrets. This one tells you which ones are live, which ones rotated, and where in history they first appeared. Semgrep rule coverage also expanded across auth bypass, injection, cryptographic misuse, SSRF, XSS, and more.

> A comment on a PR is advice. A blocked merge is enforcement. This week autter started enforcing.

### May 31, 2026 — Public reports you can hand to anyone (New Feature)

Scan results can now leave the building. Share a scan with a public link, export a branded PDF, and let the report guide readers toward next steps instead of ending with a findings list.

**Scan sharing and reports**

- **Public share tokens**: Generate a link anyone can view without an autter account.
- **Branded report pages**: Shared reports look like they came from your security team, not a raw tool.
- **PDF export**: Structured sections with branded cover and closing pages.

**Supply chain and dependency risk**

- **Deterministic risk scoring**: Severity and risk factors are reproducible, not model-dependent.
- **Lockfile-aware resolution**: autter resolves what you actually installed, not what your manifest says.
- **Exploit chain tracking**: Critical CVEs with no published fix get chain cards, detail views, and narratives.

### May 31, 2026 — The first knowledge graph (New Feature)

The first version of a knowledge graph that maps how your codebase actually connects. Graphify-backed indexing is live: graph tables, indexer orchestration, and deployment wiring all shipped, and repository dependency views now include connectivity data from the graph.

**Also in this release**

- The codebase-scan chat experience is now powered by AI SDK.
- Documentation generation uses task-specific model routing: each writer gets the model best suited to its job.
- Fullscreen viewing and copy support across architecture-map surfaces.

### May 23, 2026 — The full scan surface (New Feature)

Everything we have been building the scan engine toward shipped this week. Secret scanning, SAST, container scanning, SBOM, supply chain analysis, API surface analysis, policy compliance, AI slop detection, database findings, code quality, and business logic analysis all landed with findings, enrichment, Captain Patch suggestions, and issue linkage.

**Scan infrastructure**

- **Agent pipeline tables**: Every agent's output is tracked, counted, and attributed.
- **Runtime preflight checks**: Agents verify the environment before executing, not midway through.
- **strace runtime tracking**: Runtime behavior is observed and stored alongside static findings.

**The scanners**

- Secret scanning with live validation, allowlists, rotation mapping, and direct issue creation.
- CodeQL is live as a fourth scanning engine; SAST findings include enrichment and suggestions.
- Trivy container scanning, unified dependency audits, and richer license findings.
- AI slop detection: hallucinated imports, placeholder logic, and low-confidence outputs.
- Per-organization SBOM artifacts with CycloneDX support and file risk history through commits.

> A merge gate is only as strong as what it checks. This week we finished building the checklist.

### May 23, 2026 — Issue sync: Linear, Jira, and GitHub (New Feature)

Findings are only useful if they end up where your team plans work. Issues now flow both ways between autter and your tracker, with logs, backfill, and persistent action items.

- **Bidirectional sync**: Issues created in autter stay in sync with your issue tracker.
- **External issue creation**: Push a finding to your tracker directly from autter.
- **Sync logs**: Every sync event is recorded and auditable.
- **Backfill support**: Historical findings can be synced, not just new ones.

### May 23, 2026 — Exploit enrichment and chain tracing (New Feature)

A CVE number tells you almost nothing. Findings are now enriched with exploit probability, standardized severity, external intelligence, and, where paths connect, full exploit chains.

- **EPSS + CVSS scoring**: Exploit probability and standardized severity attached to each CVE.
- **OSV and Exa enrichment**: Vulnerability databases and external intelligence feed into findings.
- **Complexity scoring**: Findings are ranked by how hard they are to exploit.
- **Exploit chain tracing**: Connected vulnerability paths are tracked as chains, not isolated findings.

### May 17, 2026 — The docs engine, upgraded (Improvement)

The documentation engine got faster and more complete: the kind of upgrade that makes generated docs something you actually trust instead of something you politely ignore.

**Documentation engine**

- **Manual generation trigger**: Teams can regenerate docs on demand, not just on scan.
- **Job status tracking**: Generation progress is visible, not a black box.
- **Type-safe modular internals**: A pipeline we can extend without breaking things.

**Wiki and architecture**

- Wiki search powered by proper full-text indexing, with better navigation, zoom, and typography.
- Architecture visualization inside generated documentation.
- File content surfaced directly in search results.

> A wiki you trust beats documentation you maintain. This week we made it trustworthy.

### May 17, 2026 — The first auditor agent (New Feature)

autter shipped its first domain-specific agent: a Payment Gateway Auditor that targets the risk surface specific to payment flows. Under the hood, agent execution got meaningfully faster and smarter about context.

**Agent execution improvements**

- **Batch inserts + parallelism**: Findings write in bulk and agents run concurrently without contention.
- **Team context**: Agents know which team owns a scope before they score it.
- **Calibrated risk scoring**: Scoring is tuned against actual severity signals.

**Also in this release**

- Custom teams and member assignment, managed directly from settings.
- A dedicated repository issues tab.

### May 10, 2026 — Custom agents and guided config (New Feature)

Custom agents are no longer a flat list. They have categories, trigger configuration, and richer API support. Configuring one is now a step-by-step flow with streaming updates and visible progress, and teams can take a prebuilt agent, adjust its schema and behavior, and edit it through the same UI.

### May 10, 2026 — The documentation generation pipeline (New Feature)

autter shipped its first documentation generation pipeline, turning indexed codebase knowledge into something readable. Wiki routes, documentation query APIs, markdown rendering, sidebar navigation, and full-text searchable generated docs are all in.

- **Codebase graph construction**: autter maps the structure of your repo before generating any docs.
- **Dependency edge tracking**: Relationships between modules are first-class inputs to generation.
- **Module clustering**: Related code is grouped before documentation is written.
- **Risk flag integration**: High-risk areas surface in the docs, not just in findings.

> The agents know your codebase. The docs make it legible. This week connected both.

### May 4, 2026 — CVE watch: scheduled monitoring (New Feature)

We started watching for vulnerabilities on a schedule instead of waiting for someone to ask. Recurring background checks run against your dependencies, and what they find is data, not log lines.

- **Recurring background checks**: Your dependencies are checked on a schedule, not on request.
- **Concurrency controls**: Multiple repos can be scanned without stepping on each other.
- **Graceful shutdown handling**: Long-running checks no longer leave findings half-written.
- **First-class findings schema**: Vulnerabilities and upgrade suggestions are data, not log lines.

### May 4, 2026 — Repository overview and smarter search (Improvement)

The repository workspace got a real face this week. Health views matured, and search got smarter in ways you can feel.

- The repository page rebuilt around dedicated tabs: activity, dependencies, API data, health, onboarding.
- Org-wide search with suggestions, page-visit awareness, and an animated header trigger with rotating prompts.
- Deeper dependency intelligence with automatic registry and version enrichment.
- AI response caching, Vercel AI Gateway migration, and loading skeletons across the repo experience.

### April 27, 2026 — The repository wiki (New Feature)

Searchable repository discovery, structured documentation pages, table-of-contents navigation, breadcrumbs, keyboard shortcuts, and an AI-assisted “ask” flow for exploring codebase knowledge directly.

**Also in this release**

- Richer treatment for third-party packages: classification, docs resolution, usage insights.
- Endpoint indexing across multiple frameworks, connected to test coverage.

### April 27, 2026 — Pull request review, rebuilt (Improvement)

The PR review experience got rebuilt from the ground up: dedicated tabs for AI review, checks, and commits. Inline comments. File tree navigation. Unified and split diff viewing.

**Also in this release**

- Configurable event-based notifications, weekly digests, and Slack/webhook test flows.
- Shipped agentic-sales, a small open-source AI sales toolkit, as a side project.

### April 27, 2026 — The graph: architectural insights (New Feature)

A substantial expansion of the indexing engine. This is the week autter started reasoning about your codebase the way a senior engineer does: end-to-end indexing across scope detection, file hotspots, dependency resolution, and scope health metrics.

- **Reverse dependency analysis**: autter knows what depends on what, in both directions.
- **Call graph analysis**: Function-level relationships are tracked across the codebase.
- **Scope dependency graphs**: Coupling and layering between scopes are visible, not implied.
- **AI-augmented health and risk**: Structural issues, hotspots, and tech-debt signals surface per scope.

> A scanner finds problems. A graph explains them. This week was about the graph.

### April 20, 2026 — The indexing pipeline levels up (Improvement)

Not every week produces a headline feature. This one produced the thing that makes headline features work reliably: a significantly smarter indexer.

- **Repository context detection**: autter identifies what kind of codebase it is looking at before scanning.
- **Scope profiling**: The indexer understands which parts of the repo relate to which others.
- **Full dependency resolution**: The whole graph gets traced, not just top-level packages.
- **Scope health metrics**: A health signal per scope, not just per file.

> The indexer is what makes autter's findings trustworthy instead of just plentiful. This week it got meaningfully better.

### April 20, 2026 — Onboarding and a lot of plumbing (Improvement)

The first-run experience for new organizations is more guided now, and infrastructure that was held together with assumptions is now held together with actual logic.

- Guided onboarding: autter asks about your setup upfront and walks you through the first scan.
- Webhook testing directly from organization settings.
- More resilient database provisioning with better retry logic.
- Stronger backend logging, health check visibility, and AI pipeline instrumentation.

### April 16, 2026 — Onboarding that gets out of the way (Improvement)

Getting set up with autter should not feel like configuring a server. This week we focused on making the first few minutes feel less like work.

**What changed**

- Guided organization setup: each step comes with actual context, not just a progress bar and a prayer.
- Cleaner motion and transitions across the dashboard and login experience.
- Meaningful hardening for secrets management, host configuration, and deployment setup.
- Dynamic database migrations: provisioning handles schema changes gracefully during setup.
- Better observability: improved route logging, health checks, and Slack integration.

**Why it matters**

First impressions compound. If setup is confusing, people assume the product is confusing. The goal is for setup to feel so unremarkable that you forget it happened. We are getting there.

### April 12, 2026 — Self-service scan initiation (New Feature)

The codebase scan is now something you can start yourself.

**What you can do now**

- Start a scan from the dashboard or onboarding flow. No manual handoff required.
- Get notified when it is done, via email and Slack.
- See full dependency coverage: every package tracked, cross-referenced, and auditable over time.
- Branch-aware scanning: scans run against the right branch, not whatever was last pushed.

**What gets scanned**

- **Security vulnerabilities**: Known CVEs, exposed secrets, injection patterns.
- **Dependencies**: Every package, version, and license in your repo.
- **AI-generated code quality**: Hallucinated imports, placeholder logic, low-signal patterns.
- **Blast radius**: Which parts of the codebase a change touches and how far it reaches.

> Seven out of ten users in our concierge cohort said they would pay for this. That is why we shipped it.

### April 5, 2026 — Streaming progress and auto-open setup (Improvement)

Small week. Useful change.

- Streaming progress during setup: watch organization creation happen step by step instead of waiting on a static loading state and hoping it finishes.
- The organization creation dialog now opens from the right place in the dashboard flow automatically.

Not every changelog is dramatic. Sometimes you just fix the thing that was quietly annoying everyone.

### March 29, 2026 — The multi-agent scan engine (New Feature)

This is where the engine got built. We shipped the multi-agent scanning foundation: a set of specialized agents that each look at a different risk surface in your codebase. Each agent has one job. They run independently and their findings roll up into a single, prioritized report.

**What the scan engine covers**

- Security vulnerabilities in your code and dependencies.
- Open source licenses across every package you are using.
- Supply chain risk from third-party dependencies.
- Configuration problems in infrastructure definitions.
- Container security across your Docker setup.
- Policy compliance against your org's own rules.
- Business logic issues that static analysis typically misses.
- Runtime behavior signals that show how code behaves under real conditions.

> A comment on a PR is advice. A blocked merge is enforcement. Everything we built this week is in service of the second one.

### March 29, 2026 — GitHub PR automation and the first dashboard (New Feature)

autter can now comment on pull requests, post check runs, and flag issues directly in GitHub without you leaving your workflow, and the first version of the analytics dashboard is live alongside it.

- GitHub PR automation: comments, check runs, and flagged issues without leaving your workflow.
- The first analytics dashboard, with date-range filters and multiple tabs.
- Expanded codebase intelligence: hotspot detection, dependency mapping, legacy code signals.

### March 22, 2026 — Week one: we built the product (New Feature)

Week one. We built the product. Not a prototype. Not a proof of concept. The actual product, with the foundations required to sign up a real user, connect a real repository, and enforce a real merge gate.

**What shipped**

- **Authentication**: Email login with one-time codes and passkeys. Trusted devices. Welcome flows.
- **Organization management**: Teams, billing, source control, review preferences, custom agents, AI config.
- **GitHub integration**: App installation, pull request views, and the first repository insights.
- **Codebase intelligence**: Architecture graphs, hotspot metrics, and learning signals over time.
- **Dashboard and navigation**: Loaders, toasts, responsive layouts, sidebars, search, and the branding system.

Captain Patch is officially on duty.


---

---
title: Autter Customers - Teams Shipping Secure, Verified Code
description: Autter is built for the people who own what ships: engineering leads, open source maintainers, security engineers, and startup CTOs who answer for what happens when code reaches production.
url: https://autter.dev/customers
site: Autter - Autter is the code security and assurance layer for the AI coding era: it checks every change before it merges, catches security risks, governs releases, and closes the loop from production failure to verified fix.
---

## Persona dossiers, in full



### Case file 01: The engineering lead

- **Role**: Engineering Lead / CTO
- **Verdict in the demo report** (PR #247 · api/users/search.ts): Merge blocked

**Situation**: You own everything the team ships. Half of it was generated by a tool you did not choose, reviewed under deadline pressure, and approved before anyone measured the blast radius.

### Case file 02: The open source maintainer

- **Role**: Open Source Maintainer
- **Verdict in the demo report** (PR #1,203 · lib/auth/session.ts): Merge blocked

**Situation**: Hundreds of contributors you have never met, many pointing AI tools at your repository. More PRs arrive each week than you can review. No dedicated reviewers, no budget to hire them.

### Case file 03: The security engineer

- **Role**: Security / DevSecOps
- **Verdict in the demo report** (PR #89 · app/controllers/payments.rb): Merge blocked

**Situation**: You answer for the security posture of everything engineering ships, and you keep finding the vulnerabilities after deploy, in code that is already live in production.

### Case file 04: The startup CTO shipping at speed

- **Role**: Startup CTO
- **Verdict in the demo report** (PR #34 · src/api/checkout.ts): Merge approved

**Situation**: Small team, every AI tool available, features shipping at maximum speed. You know risk is accumulating, but you cannot afford to slow down for a thorough manual review on every change.

## Early users, on the record



Verbatim statements from early users who ran Autter on their own code. Attribution is a name only; Autter does not attach titles it cannot verify.

> "Autter caught the exact line and exact bug in plain English, not generic boilerplate. The auto-generated task checklist felt like a real senior engineer's comment, not an AI hedge."
>
> Pengpeng

> "Autter earned my trust when it correctly identified an unsafe pickle load in my own project. That kind of real, direct feedback was far more memorable than a polished walkthrough."
>
> Saumya Patel

> "The Team Patterns insight correctly read my actual naming conventions, PR style, and testing habits straight from commit history. I haven't seen anything like it in another app."
>
> Aksh Malik

> "A real hardcoded-secret issue showed up with an 85/100 risk score, a clear explanation, and an AI-fix prompt. Genuinely impressive."
>
> Phuc Nguyen

> "After I proposed a faulty merge request, Autter was able to catch the vulnerability."
>
> Edison

> "The install command generated in the dashboard worked flawlessly: single command, automatic login, all editor and agent hooks configured."
>
> Salil

> "Autter did a good job flagging exploits in an AI-generated fix."
>
> Jaden Ray

> "I was genuinely impressed by the depth of the analysis, how clearly the information was presented, and the overall UI and animations."
>
> Arwa

> "The onboarding sells the infrastructure well: isolated databases, air-gapped sandboxes, ephemeral everything."
>
> Akshat Jain

> "Autter does not position itself as 'another AI code reviewer', which is interesting. It leans into an independent assurance and merge layer for the AI coding era."
>
> Anne Marie Soldatelli Appel


---

---
title: Autter Security - How Your Code Is Protected
description: How Autter protects the code it reviews: ephemeral sandboxes destroyed after every run, no training on your code, least-privilege access, scoped expiring tokens, a full audit trail, and on-prem deployment for enterprises that need the review plane inside their own network.
url: https://autter.dev/security
site: Autter - Autter is the code security and assurance layer for the AI coding era: it checks every change before it merges, catches security risks, governs releases, and closes the loop from production failure to verified fix.
---

## The data path

The life of a pull request inside Autter, end to end. The only artifacts that outlive a run are the verdict, the findings, and the audit entry.

1. **Scoped read**: a native GitHub App with least-privilege scopes clones the pull request. Autter reads what it reviews and nothing more.
2. **Encrypted transit**: code moves over TLS and lands encrypted at rest, inside a sandbox built fresh for this one run.
3. **Isolated execution**: the suite runs against the base branch in full isolation. No shared state, no neighbors.
4. **Verdict posted**: findings land on the pull request pinned to file and line.
5. **Teardown**: the sandbox is destroyed the moment the verdict lands. Source does not outlive the run.

## Security posture, clause by clause

| Clause | Commitment |
| --- | --- |
| §1 Ephemeral execution | Every pull request runs in a sandbox built fresh for that run and destroyed the moment the verdict lands. Nothing lingers between runs, and no two customers ever share one. |
| §2 No training, ever | Your source is never used to train models. It exists inside the run, and then it is gone. |
| §3 Encrypted throughout | In transit and at rest, from the moment the sandbox clones to the moment the verdict posts. |
| §4 Least privilege | The GitHub App asks for the minimum scopes a review needs. Autter reads what it reviews and nothing more, through access you can revoke at any time. |
| §5 Tokens that expire | Personal access tokens carry narrow scopes (mcp:read, mcp:write, mcp:llm), expire on schedule, and revoke instantly from the dashboard. |
| §6 Everything audited | Every machine-facing call records actor, token, duration, result, and error code in the organization audit log. |
| §7 Rate limited per token | Runaway agent loops get slowed down instead of taking the org down. |
| §8 Isolation and SSO | Organizations are isolated from each other, and the Enterprise plan adds SSO / SAML for centralized access control. |

## Data retention: what Autter keeps

| Data | Notes |
| --- | --- |
| Findings and verdicts | Pinned to file and line, they are the review record your team works from. |
| The map, not the territory | Product memory stores structure: APIs, routes, schema, owners, hotspots. A graph about your code, not a copy of it. |
| The audit log | Actor, token, duration, result, and error code for every machine-facing call. |
| Account and billing data | Covered end to end by the privacy policy. |

## Data retention: what Autter never keeps

| Data | Notes |
| --- | --- |
| Your source after the run | Code exists inside the ephemeral sandbox for exactly one review, then the sandbox is destroyed with it. |
| Training data | Your code never trains a model, ours or anyone else's. |
| Prompts from the CLI | Local-only mode never uploads a prompt. Attribution lives in your Git history, on your machine. |
| Standing credentials | Tokens are scoped and expire on schedule. There is no forever-key to steal. |

## Deployment models

| Model | Where the review plane runs | Notes |
| --- | --- | --- |
| Autter Cloud (default) | Autter-managed infrastructure | Live in minutes through the native GitHub App; ephemeral compute per pull request, destroyed after the run; SSO / SAML and audit logs on the Enterprise plan |
| On-prem / self-hosted (Enterprise plan) | Your cloud account or data center | Source never crosses your network boundary; your keys, your logs; updates ship as versioned releases you approve; scoped with your infrastructure team |

## Reporting a vulnerability

- Email support@autter.dev, or use the [contact form](https://autter.dev/contact.md) with the `Security` question type.
- Reports are read by the founders directly, and fixes ship through the same verified pipeline as every other change.

## Vendor security reviews

- Security questionnaires, data-handling walkthroughs, and detail behind every posture clause are available on request via [contact](https://autter.dev/contact.md) or by booking the founders at https://cal.com/sagnik-autter/30min.

## Related

- [Privacy Policy](https://autter.dev/privacy.md)
- [Terms of Service](https://autter.dev/terms-of-service.md)
- [MCP server: token scopes, audit log, rate limits](https://autter.dev/features/mcp.md)
- [Pricing: SSO / SAML, audit logs, and on-prem live on the Enterprise plan](https://autter.dev/pricing.md)
- [Full product overview](https://autter.dev/index.md)


---

---
title: Autter Pricing - Plans for Every Team
description: Autter pricing is a monthly price for a set number of pull requests. Harbour is free for 10 pull requests a month on value models. Paid plans start at $20, then bill per extra pull request. Premium models start on Port.
url: https://autter.dev/pricing
site: Autter - Autter is the code security and assurance layer for the AI coding era: it checks every change before it merges, catches security risks, governs releases, and closes the loop from production failure to verified fix.
---

## How pricing works, in plain language

Autter pricing is a monthly price for a set number of reviewed pull requests, not per seat. Past the included amount, Port bills $1.20 per extra PR, Cargo bills $0.90, and Fleet bills $0.60. Harbour never bills: reviews pause at 10 PRs. Harbour includes value models only. Premium models start on Port with the core catalog, and Cargo, Fleet, and Enterprise include the full premium catalog. Harbour is deliberately narrow: one repository, value models, and no custom rules or team integrations.

## Plans at a glance

| Plan | Monthly price | Included PRs | What you get |
| --- | --- | --- | --- |
| Harbour | $0 | 10 PRs/month | Reviews pause. Value models only. 1 repository |
| Port | $20/month | 40 PRs/month, then $1.20/PR | Core premium catalog, up to 3 repositories, Slack / Jira / Linear |
| Cargo | $40/month | 100 PRs/month, then $0.90/PR | Full premium catalog, unlimited repositories, priority queue |
| Fleet | $80/month | 300 PRs/month, then $0.60/PR | Full premium catalog, higher scan and wiki limits, priority support |
| Enterprise | Custom | Custom | Full premium catalog, SSO / SAML, audit logs, on-prem |

Notes:

- Repositories: 1 on Harbour, up to 3 on Port, unlimited on Cargo, Fleet, and Enterprise.
- Codebase scans and wiki generations per month: none on Harbour, 1 each on Port, 5 each on Cargo, 20 each on Fleet, unlimited on Enterprise.
- Value models are on every plan. Premium models are off on Harbour, the core catalog on Port, and the full catalog on Cargo, Fleet, and Enterprise.
- Past the included pull requests, Port bills $1.20 each, Cargo $0.90, and Fleet $0.60. Harbour pauses and is never billed.
- Harbour's included volume is 10 PRs a month.
- All self-serve plans bill monthly at a flat price.
- Sign up for Harbour, Port, Cargo, or Fleet at https://app.autter.dev/login. For Enterprise (custom volume, SSO, on-prem), [talk to sales](https://autter.dev/contact.md).

## Pricing questions, answered

**How much does Autter cost?**

There are five plans. Harbour is free: $0 per month with 10 reviewed PRs, value models only, and reviews pause at the cap. Port is $20 per month for 40 PRs, then $1.20 per extra PR, with the core premium catalog. Cargo is $40 per month for 100 PRs, then $0.90 per extra PR, with the full premium catalog. Fleet is $80 per month for 300 PRs, then $0.60 per extra PR, also on the full catalog. Enterprise is custom pricing for SSO, audit logs, on-prem deployment, and a negotiated volume, with the full premium catalog.

**Is there a free plan?**

Yes. Harbour is free and includes 10 reviewed pull requests a month on one connected repository, using value models only. It is a narrow plan: no premium models, no custom rules, no Slack, Jira, or Linear, and no codebase scans. At 10 PRs in a month, reviews pause and resume the next month. You are never billed on the free plan.

**What happens when we go over the included PRs?**

On Harbour, reviews pause at 10 pull requests and you are not billed. On Port, extra pull requests are $1.20 each. On Cargo, they are $0.90 each. On Fleet, they are $0.60 each. Enterprise overage is negotiated.

**How do we estimate our monthly cost?**

The monthly price covers the included pull requests. Extra reviews on a paid plan add the overage: Port is $20 plus $1.20 for each PR past 40, Cargo is $40 plus $0.90 past 100, and Fleet is $80 plus $0.60 past 300. Harbour stays $0 and pauses at 10.

**Do we pay per seat or per repository?**

Pricing follows the number of pull requests included in the plan, never seats. Adding teammates does not change the bill. Repository allowance is 1 on Harbour, up to 3 on Port, and unlimited on Cargo, Fleet, and Enterprise.

**Which plan should we pick?**

- Trying Autter on one repository: Harbour (free, 10 PRs a month, basic review only).
- A small team with a few repositories: Port ($20 per month, 40 PRs, custom rules, Slack, Jira, and Linear).
- A team shipping most days: Cargo ($40 per month, 100 PRs, unlimited repositories, priority review, exportable reports).
- High monthly volume without enterprise controls: Fleet ($80 per month, 300 PRs, priority support).
- SSO, audit logs, on-prem deployment, or a custom volume: Enterprise.

**How do we sign up or talk to sales?**

Sign up for Harbour, Port, Cargo, or Fleet at https://app.autter.dev/login and connect the GitHub App; reviews start on the next pull request. For Enterprise pricing, SSO, or on-prem deployment, [talk to sales](https://autter.dev/contact.md) or book the founders directly at https://cal.com/sagnik-autter/30min.

## Full comparison

### Plans

| Feature | Harbour | Port | Cargo | Fleet | Enterprise |
| --- | --- | --- | --- | --- | --- |
| Monthly price | $0 | $20 | $40 | $80 | Custom |
| Pull requests included | 10 PRs | 40 PRs | 100 PRs | 300 PRs | Custom |
| Overage per extra PR | Reviews pause | $1.20 | $0.90 | $0.60 | Negotiated |
| Repositories | 1 repo | 3 repos | Unlimited | Unlimited | Unlimited |
| Codebase scans | None | 1 / mo | 5 / mo | 20 / mo | Unlimited |
| Wiki generations | None | 1 / mo | 5 / mo | 20 / mo | Unlimited |

### Models

| Feature | Harbour | Port | Cargo | Fleet | Enterprise |
| --- | --- | --- | --- | --- | --- |
| Value models | Yes | Yes | Yes | Yes | Yes |
| Premium models | No | Core catalog | Full catalog | Full catalog | Full catalog |

### Review

| Feature | Harbour | Port | Cargo | Fleet | Enterprise |
| --- | --- | --- | --- | --- | --- |
| AI code review | Yes | Yes | Yes | Yes | Yes |
| Edge case and bug detection | No | Yes | Yes | Yes | Yes |
| PR summary and diagrams | No | Yes | Yes | Yes | Yes |
| Codebase intelligence | No | Yes | Yes | Yes | Yes |
| 40+ linters and security scans | No | Yes | Yes | Yes | Yes |
| Auto-fix suggestions | No | Yes | Yes | Yes | Yes |
| Custom rules | None | Unlimited | Unlimited | Unlimited | Unlimited |
| Learns from past PRs | No | Yes | Yes | Yes | Yes |
| Priority review queue | No | No | Yes | Yes | Yes |

### Integrations

| Feature | Harbour | Port | Cargo | Fleet | Enterprise |
| --- | --- | --- | --- | --- | --- |
| GitHub / GitLab | Yes | Yes | Yes | Yes | Yes |
| Jira / Linear | No | Yes | Yes | Yes | Yes |
| Slack notifications | No | Yes | Yes | Yes | Yes |
| VS Code extension | Yes | Yes | Yes | Yes | Yes |
| Multiple organizations | No | No | Yes | Yes | Yes |

### Reports

| Feature | Harbour | Port | Cargo | Fleet | Enterprise |
| --- | --- | --- | --- | --- | --- |
| Code quality analytics | None | Basic | Full | Full + export | Full + export |
| Standup and sprint reports | No | Yes | Yes | Yes | Yes |
| PR velocity and team benchmarks | No | No | Yes | Yes | Yes |
| Audit logs | No | No | No | No | Yes |

### Admin and support

| Feature | Harbour | Port | Cargo | Fleet | Enterprise |
| --- | --- | --- | --- | --- | --- |
| Support | Community | Email | Email + chat | Priority | Dedicated contact |
| Response time | No | No | 48 hours | 24 hours | 4 hours |
| SSO / SAML | No | No | No | No | Yes |
| On-prem / self-hosted | No | No | No | No | Yes |


---

---
title: Contact Autter - Talk to the Team
description: Get in touch with the Autter sales and support teams for product demos, onboarding support, or product questions, or book a call directly with the founders.
url: https://autter.dev/contact
site: Autter - Autter is the code security and assurance layer for the AI coding era: it checks every change before it merges, catches security risks, governs releases, and closes the loop from production failure to verified fix.
---

## Contact channels

| Channel | Use for | How |
| --- | --- | --- |
| Sales form | Plans, pricing, enterprise contracts, demos, free trials | Form on this page (responds within 24 hours) |
| Support form | Product questions, bug reports, security issues, billing, feedback | Form on this page |
| Book the founders | 30-minute call: demos, product ideas, partnerships | https://cal.com/sagnik-autter/30min |
| Support email | General support queries | support@autter.dev |
| Press email | Media requests and press opportunities | pr@autter.dev |
| General email | Anything else | hello@autter.dev |
| Slack community | Questions and best practices with other Autter users | [Join Slack](https://join.slack.com/t/autter-workspace/shared_invite/zt-3uaf8yyur-A6ZMod7HkJ83epVG_id6kw) |
| Documentation | Features, integrations, and how to use them | https://autter.dev/docs |
| FAQ | Quick answers | https://autter.dev/faq |

## Submitting the contact form programmatically

The forms on this page POST JSON to `https://autter.dev/api/contact`. Consent to the [Terms of Use](https://autter.dev/terms-of-service.md) and [Privacy Policy](https://autter.dev/privacy.md) is required.

Common fields (all forms):

- `formType`: `"sales"` or `"support"`
- `firstName`, `lastName`, `email`, `message`: required strings
- `termsAcceptedAt`: required ISO 8601 timestamp recording when the sender accepted the terms

Sales-only fields: `company` (required), `jobTitle` (required), `developers` (required; one of `1-5`, `6-20`, `21-50`, `51-200`, `200+`).

Support-only fields: `questionType` (required; one of `General Question`, `Bug/Problem`, `Security`, `Feature Request`, `Billing Question`, `Sales Inquiry`) and `supportCode` (optional, e.g. `AR-12AC34`, found in Settings → Account).

The endpoint responds with `{ "success": true }` on acceptance or `{ "success": false, "error": "…" }` otherwise.


---

---
title: Terms of Service - Autter
description: Autter Terms of Service: the rules and guidelines governing your use of the Autter platform, CLI, and related services.
url: https://autter.dev/terms-of-service
site: Autter - Autter is the code security and assurance layer for the AI coding era: it checks every change before it merges, catches security risks, governs releases, and closes the loop from production failure to verified fix.
---

Legal

# Terms of Service

The rules and guidelines governing your use of the Autter platform, CLI, and related services.

Last modified: April 2, 2026

On this page

- 1. Definitions
- 2. Interpretation
- 3. Accounts & Subscriptions
- 4. Access and Use
- 5. Service Plans & Beta
- 6. Customer Responsibilities
- 7. Fees and Payment
- 8. Confidential Information
- 9. Privacy
- 10. IP, Feedback & AI
- 11. Modifications
- 12. Disclaimer of Warranties
- 13. Indemnification
- 14. Limitation of Liability
- 15. Term and Termination
- 16. Dispute Resolution
- 17. General Provisions

Welcome to Autter! These Terms of Service ("Terms") form a binding agreement between Autter ("Company," "we," "us," or "our") and you ("Customer," "you," or "your"). By accessing or using our Services, you agree to be bound by these Terms. If you do not agree, do not use our Services.

The complete agreement between you and Autter (the "Agreement") includes these Terms, our Data Processing Addendum ("DPA"), and any applicable Orders or exhibits. In the event of a conflict, the DPA takes precedence over these Terms, and these Terms take precedence over any Orders.

## 1. Definitions

- **"Authorized User"** means any employee, consultant, contractor, or agent you authorize to access the Services on your behalf.
- **"Customer Content"** means all data, code, materials, and information you or your Authorized Users submit to the Services, excluding Usage Data.
- **"Documentation"** means user guides, manuals, and help materials made available at autter.dev/docs.
- **"Autter CLI"** means our proprietary command-line interface tool for AI-powered code review.
- **"Autter Platform"** means the website located at autter.dev and all related web applications.
- **"Usage Data"** means technical logs, telemetry, API call metadata, feature usage statistics, and interaction metrics generated through your use of the Services.
- **"Services"** means the Autter Platform, CLI, and all related products and services provided by us.

## 2. Interpretation

In these Terms, unless the context requires otherwise: "including" means "including without limitation"; "or" is not exclusive; references to the singular include the plural and vice versa; and headings are for convenience only and do not affect interpretation.

## 3. Accounts, Subscriptions, and Free Trials

### Account Registration

To use the Services, you must create an account with accurate and complete information. Your account is personal and non-transferable. You are solely responsible for maintaining the confidentiality of your login credentials and for all activities under your account.

### Subscriptions and Payment

Paid subscriptions renew automatically at the then-current rate on a monthly or annual basis, as selected at checkout. We will provide reasonable advance notice of any price changes. You may cancel your subscription before the next renewal date to avoid further charges.

### Renewal

Subscriptions auto-renew at the end of each billing period unless you cancel before the renewal date. You may cancel through your account settings or by contacting [hello@autter.dev](mailto:hello@autter.dev).

### Refund Policy

All payments are non-refundable except in exceptional circumstances such as extended service outages. Refund requests may be directed to [hello@autter.dev](mailto:hello@autter.dev).

### Free Trials

We may offer free trial periods at our discretion. If you do not cancel before the trial ends, your account will automatically convert to a paid subscription and your payment method will be charged.

## 4. Access and Use

### Platform Access

Subject to your compliance with these Terms and payment of applicable fees, we grant you a revocable, non-exclusive, non-transferable, non-sublicensable, limited right to access and use the Services solely for your internal business operations.

### GitHub Integration

Certain features require a GitHub account. By connecting your GitHub account, you authorize Autter to access your profile information and repositories within the scope permitted by GitHub. We are not responsible for GitHub's products, services, or availability.

### Documentation

We grant you a limited, non-exclusive right to use the Documentation for internal reference purposes in connection with your use of the Services.

### CLI Installation

You may download and install the Autter CLI on your local systems in accordance with the Documentation.

### Use Restrictions

You agree not to:

- Copy, modify, distribute, or create derivative works of the Services
- Reverse engineer, decompile, or disassemble any part of the Services
- Remove or alter any proprietary notices or labels
- Upload or transmit malicious code, viruses, or harmful content
- Interfere with, disable, or damage the operation of the Services
- Circumvent any access controls, rate limits, or security measures
- Use the Services for any purpose that violates applicable law

### Service Suspension

We may suspend your access to the Services if we reasonably believe you have breached these Terms, pose a security risk, are engaged in fraudulent activity, or if required by law. We will provide commercially reasonable notice before any suspension when practicable.

## 5. Service Plans, Beta Services, and Add-On Features

### Service Plans

We offer different subscription tiers with varying features and capabilities. Your specific plan is identified in your Order or account settings.

### Beta Services

We may offer beta or pre-release features from time to time. Beta Services are provided "as is" without any warranties of any kind. We may modify or discontinue Beta Services at any time without notice. Your use of Beta Services is at your sole risk, and you agree not to disclose information about Beta Services without our prior written consent.

### Add-On Features

Optional add-on features may be available at additional cost as described on our pricing page. We may adjust add-on pricing at any time. If we increase the price of an add-on you are using, you may discontinue it without penalty and receive a pro-rata refund for the unused portion.

## 6. Customer Responsibilities

### Acceptable Use

You must use the Services in compliance with all applicable laws and regulations. You may not use the Services for any unlawful, fraudulent, harassing, or abusive purpose.

### Customer Content

You represent and warrant that you have all necessary rights to the Customer Content you submit. You grant us a non-exclusive, worldwide, royalty-free license to use Customer Content solely as necessary to provide, maintain, and improve the Services.

### Authorized User Conduct

You are responsible for the actions of all Authorized Users on your account. Any breach of these Terms by an Authorized User constitutes a breach by you.

### Third-Party Integrations

The Services may integrate with third-party platforms such as GitHub, Slack, and other developer tools. We are not responsible for the content, availability, or practices of any third-party services.

## 7. Fees and Payment

### Fees

Fees are based on the total number of Authorized Users during each billing period, as specified in your Order or subscription plan.

### Payment Terms

All fees are billed in advance in U.S. dollars. Fees are non-cancelable and non-refundable except as expressly stated in these Terms.

### Automatic Billing

By providing a payment method, you authorize us to charge it automatically for all recurring subscription fees.

### Late Payments

Overdue amounts accrue interest at 1.5% per month (or the maximum rate permitted by law, whichever is lower). We may recover reasonable collection costs, including attorney fees. We reserve the right to suspend access after 15 days of non-payment.

### Taxes

You are responsible for all applicable taxes and duties, excluding taxes based on our net income.

## 8. Confidential Information

### Definition

"Confidential Information" means any information disclosed by either party that is marked as confidential or that a reasonable person would understand to be proprietary. The Autter Platform, CLI, pricing, and these Terms are deemed Autter Confidential Information.

### Obligations

The receiving party will maintain the confidentiality of the disclosing party's Confidential Information and will only disclose it to employees and contractors who have a need to know and are bound by confidentiality obligations at least as protective as those herein.

### Exclusions

Confidential Information does not include information that: (a) is or becomes publicly available through no fault of the receiving party; (b) was known to the receiving party prior to disclosure; (c) is received from a third party without restriction; or (d) is independently developed without reference to the Confidential Information.

### Required Disclosures

Disclosure is permitted if required by law or court order, provided the receiving party gives the disclosing party written notice where legally permissible.

### Duration

Confidentiality obligations survive for five years after termination of the Agreement. Trade secrets are protected for as long as they qualify as such under applicable law.

## 9. Privacy

Our collection and use of personal data is governed by our [Privacy Policy](https://autter.dev/privacy) and, where applicable, our Data Processing Addendum.

## 10. Intellectual Property, Feedback, and AI Features

### Customer Content Ownership

You retain all ownership rights in your Customer Content. You grant us a non-exclusive license to use Customer Content as necessary to provide and improve the Services.

### Autter IP

We own all rights, title, and interest in and to the Services, CLI, Platform, Usage Data, Documentation, and all related intellectual property. All rights not expressly granted herein are reserved by us.

### Feedback

If you provide suggestions, ideas, or other feedback about the Services ("Feedback"), we may freely use such Feedback without any obligation to you, including without attribution or compensation. You assign all rights in Feedback to us.

### AI Features

The Services may provide access to AI and large language model ("LLM") capabilities. Inputs you provide to and outputs generated by AI features are treated as Customer Content.

### AI Accuracy Disclaimer

**Autter makes no representations or warranties with respect to the accuracy, completeness, or reliability of any AI-generated outputs.** You are solely responsible for reviewing and validating all AI outputs before relying on them.

### AI Usage Restrictions

You agree not to use AI outputs to:

- Infringe upon the rights of any third party
- Train or fine-tune other AI or machine learning models
- Misrepresent AI-generated content as human-authored
- Make automated decisions that discriminate against or harm individuals

### AI Output Ownership

To the extent permitted by applicable law, you own the outputs generated through your use of AI features. We assign any rights we may have in such outputs to you. You grant us a license to use outputs as necessary to provide and improve the Services.

## 11. Modifications to the Services

We may modify, update, or discontinue any part of the Services at any time. For material changes, we will provide at least 30 days' prior notice. Your continued use of the Services after such notice constitutes acceptance of the changes.

## 12. Disclaimer of Warranties

**The Services (including any Beta Services) are provided on an "as is" and "as available" basis. To the fullest extent permitted by law, Autter disclaims all warranties, express or implied, including warranties of merchantability, fitness for a particular purpose, title, and non-infringement. We do not warrant that the Services will be uninterrupted, error-free, secure, or free of harmful components.**

## 13. Indemnification

You agree to indemnify, defend, and hold harmless Autter and its officers, directors, employees, and agents from and against any third-party claims, damages, losses, costs, and expenses (including reasonable attorney fees) arising from: (a) your breach of these Terms; (b) your misuse of the Services; (c) your negligence or willful misconduct; or (d) your Customer Content. You may not settle any claim without our prior written consent.

## 14. Limitation of Liability

**Except for cases of gross negligence or willful misconduct, our aggregate liability under these Terms shall not exceed the total amounts you paid to Autter during the twelve (12) month period preceding the event giving rise to the claim.**

**In no event shall Autter be liable for any indirect, incidental, special, consequential, or punitive damages, including loss of profits, data, or business opportunities, regardless of the theory of liability, even if advised of the possibility of such damages.**

## 15. Term and Termination

### Term

These Terms take effect when you first access or use the Services and continue until terminated. Paid subscriptions auto-renew on a monthly or annual basis (as specified in your Order) unless cancelled before the renewal date.

### Renewal Pricing

Renewal pricing will be at or below our then-current list pricing at the time of renewal.

### Termination

We may suspend or terminate your account at any time if you breach these Terms, or for any other reason with reasonable notice. Sections 7 through 10, 12 through 14, and 16 through 17 survive termination.

### Effect of Termination

Upon termination, all rights granted to you cease immediately. You must destroy all copies of Documentation in your possession. No refunds will be issued for unused portions of your subscription. Outstanding payment obligations survive termination.

## 16. Dispute Resolution

### Informal Resolution

Before filing a formal claim, you agree to contact us at [hello@autter.dev](mailto:hello@autter.dev) to attempt to resolve the dispute informally. We will have 15 days to address the matter before you may pursue formal proceedings.

### Binding Arbitration

Any dispute that cannot be resolved informally shall be settled by binding arbitration administered by the American Arbitration Association ("AAA") under its Commercial Arbitration Rules, to be held in New York, New York. Either party may seek relief in small claims court as an alternative. You may opt out of this arbitration provision within 30 days of first accepting these Terms by emailing [hello@autter.dev](mailto:hello@autter.dev).

### Class Action Waiver

**You and Autter agree that each may bring claims against the other only in your or its individual capacity, and not as a plaintiff or class member in any purported class or representative proceeding.**

### Time Limitation

Any claim arising under these Terms must be filed within one (1) year of the date the claim first accrued, or the claim is permanently barred.

## 17. General Provisions

### Equitable Remedies

We are entitled to seek specific performance and injunctive relief for any breach or threatened breach of these Terms, without the need to post a bond.

### Marketing

You grant us the right to identify you as a customer and use your name and logo in accordance with your brand guidelines for marketing purposes.

### Modifications to Terms

We may update these Terms from time to time. For material changes, we will provide notice via email or through the Services. Your continued use after such notice constitutes acceptance of the revised Terms.

### Contact Information

**Legal and General Inquiries:**
Email: [hello@autter.dev](mailto:hello@autter.dev)

**Support:**
Email: [hello@autter.dev](mailto:hello@autter.dev)

### Notices

Notices to you may be sent via email to the address associated with your account or through the Services.

### Governing Law and Jurisdiction

These Terms are governed by the laws of the State of New York without regard to conflict of laws principles. You consent to the exclusive jurisdiction of the courts located in New York, New York for any disputes not subject to arbitration.

### Assignment

Neither party may assign these Terms without the prior written consent of the other party, except that we may assign to an affiliate or in connection with a merger, acquisition, or sale of all or substantially all of our assets.

### Subcontractors

We may engage subcontractors (including hosting, infrastructure, and CDN providers) to perform obligations under these Terms. We remain responsible for their performance.

### Relationship of the Parties

The parties are independent contractors. Nothing in these Terms creates a partnership, joint venture, employment, or agency relationship.

### Export Compliance

The Services are subject to U.S. export control laws and regulations. You agree to comply with all applicable export restrictions.

### U.S. Government Rights

The Services are "commercial items" as defined in the Federal Acquisition Regulation. Government use is subject to the terms of these Terms.

### Waiver

No waiver of any right or provision of these Terms is effective unless in writing. Failure to enforce any provision does not constitute a waiver of future enforcement.

### Severability

If any provision of these Terms is held invalid or unenforceable, it shall be reformed to the minimum extent necessary, and the remaining provisions shall continue in full force and effect.

### Force Majeure

Neither party is liable for delays or failures caused by circumstances beyond its reasonable control, including natural disasters, wars, pandemics, government actions, or infrastructure failures, except that payment obligations are not excused.

### Entire Agreement

These Terms, together with any Orders and the DPA, constitute the entire agreement between you and Autter regarding the Services and supersede all prior or contemporaneous agreements, understandings, and communications.

### Counterparts

The Agreement may be executed in counterparts, each of which shall be deemed an original with the same legal effect.

### California Residents

If you are a California resident, you may report complaints to the Complaint Assistance Unit of the Division of Consumer Services of the California Department of Consumer Affairs at 1625 North Market Blvd., Suite N 112, Sacramento, California 95834, or by phone at (800) 952-5210.


---

---
title: Privacy Policy - Autter
description: Autter Privacy Policy: how we collect, use, and protect your information when you use the Autter platform, CLI, and related services.
url: https://autter.dev/privacy
site: Autter - Autter is the code security and assurance layer for the AI coding era: it checks every change before it merges, catches security risks, governs releases, and closes the loop from production failure to verified fix.
---

Legal

# Privacy Policy

How we collect, use, and protect your information when you use the Autter platform, CLI, and related services.

Last modified: April 2, 2026

Built with security in mind

## We keep your reviews safe and your code safer.

Everything we do to keep your code secure can't fit on a page, but here's the short version.

- **Best practices** We follow industry standard practices around employee training, background checks, MDMs, and on-call coverage.
- **Access control** Role-based access controls and GitHub-synced permissions ensure only authorized team members reach your repositories and data.
- **Encryption** In transit, at rest, and in our database, using industry standard HTTPS and AES-256. API tokens are encrypted with hardware-protected secrets.
- **Pen-tested** Continuously by a suite of tools and annually by independent third parties. Contact us to request a report.

On this page

- Updating this Privacy Policy
- Collection and Use of Information
- How We Share Information
- Cookies and Tracking Technologies
- Third-Party Websites and Links
- Data Security & Retention
- Access to Your Information
- United States
- Contact Us

This Privacy Policy ("Privacy Policy") for Autter ("Company," "we," "us," "our") describes how we collect, use, and disclose information about visitors of the Company's website autter.dev (the "Website"), and any content, tools, features, and functionality offered on or through our Website are collectively referred to herein as the "Services." For the purposes of this Privacy Policy, "you" and "your" means you as the user of the Services.

Please read this Privacy Policy carefully. If you do not want information about you used as described in this Privacy Policy, please do not access or use the Services.

## Updating this Privacy Policy

We may modify this Privacy Policy from time to time in which case we will update the "Last Modified" date at the top of this Privacy Policy. The updated Privacy Policy will be effective as of the time of posting, or such later date as may be specified in the updated Privacy Policy. If we make material changes we will notify you and/or take other steps as required by applicable law. If you do not agree to any updates to this Privacy Policy, please do not access or continue to use the Services.

## Company's Collection and Use of Information

In order to provide you with the Services, we may ask you to provide us with certain details or information about you. Information that you submit through the Services includes:

**Contact information:** Name and email address. We collect basic contact details to communicate with you, provide you with the Services, respond to your queries, personalize the Services for you, improve and enhance our Services, market to you, and conduct research and analytics.

**Professional information:** Company name, division, job title, and other professional information. We collect such information to explore business opportunities and provide the Services to you and existing or prospective businesses.

**Information about your use of the Services:** Interaction and feedback regarding the Services, including features, search queries within the Services, and certain interactions you make via the Services, such as code reviews and CLI usage. We collect this interaction and feedback to provide you with the Services, improve and enhance our Services, conduct research and analytics, and for security purposes.

**Any other information you choose to provide:** This includes code reviews, feedback, and any information you provide to us, for example, when communicating with us.

Our Services may require you to enter certain information about yourself. You may elect not to provide this information, but doing so may prevent you from using or accessing the Services.

We may obtain information about you from the following third-party sources:

**Service providers and other similar entities:** They collect information, such as your contact information, profile picture, and your affiliated company information, as applicable, on our behalf to provide our Services.

**Your employer:** Your contact information in order to provide you with access to the Services, market to you and your organization, and for security purposes.

**Social networking platforms:** Your contact information and information you post on social networking platforms (e.g., LinkedIn) when you have a publicly-available profile containing information about yourself. We use this information to network with you, advertise to you, and seek business opportunities. In addition, if you interact with us on social media, we will collect information about those interactions.

**Other third parties:** You may choose to elect that certain third parties share information with us, for example, when you choose to access the Services through another service, such as through Single Sign-on (e.g., GitHub, GitLab, Bitbucket) or link any social media platforms to your account.

Any information we receive from outside sources will be treated in accordance with this Privacy Policy. We are not responsible or liable for the accuracy of the information provided to us by third parties and are not responsible for any third party's policies or practices. See the "Third-Party Websites and Links" section below for more information.

We also automatically collect certain information about your interaction with the Services ("Usage Data"). To do this, we may use cookies, web beacons/clear gifs, and other tracking technologies ("Tracking Technologies"), including PostHog and similar analytics tools, to provide and enhance the performance of our Services, facilitate and enhance user experience, monitor and analyze trends, usage and activities in connection with the Services, and conduct internal research and development.

We collect the following kinds of Usage Data:

- Unique device identifier
- Device type, such as your phone, computer, or tablet
- IP address
- Browser type
- Date and time stamps, such as the date and time you first accessed the Services
- Operating system
- Log data
- Number of visits
- Language of device
- Geolocation
- Other information regarding your interaction with the Services

We use the Usage Data we collect automatically to:

- Improve and provide the Services
- Run analytics
- Better understand user interaction with the Services

In addition to the foregoing, we may use all of the above information to:

- Create anonymized and aggregated data sets that we may use for a variety of functions, including research, internal analysis, analytics, and other functions
- Comply with any applicable legal obligations
- Detect, investigate, and prevent activities that may violate our policies or be illegal
- Enforce any applicable terms of use
- Protect or defend the Services, our rights, the rights of our users, or others

## How the Company Shares Information About You

In certain circumstances, we may share information about you with third parties. Such circumstances may include:

- **With vendors or other service providers,** such as data analytics vendors, data storage providers, email vendors, and security vendors
- When you request us to share certain information with third parties, such as through your use of social media widgets or login integrations
- With our affiliates or otherwise within our corporate group
- To comply with applicable law or any obligations thereunder, including cooperation with law enforcement, judicial orders, and regulatory inquiries
- In connection with an asset sale, merger, bankruptcy, or other business transaction
- To enforce any applicable terms of service
- To ensure the safety and security of the Company and/or its users
- With professional advisors, such as auditors, law firms, or accounting firms

You acknowledge that such sharing of information may occur in all of the aforementioned circumstances and is permitted by and subject to this Privacy Policy and applicable law.

## Cookies and Other Tracking Technologies

### Do Not Track Signals

Your browser settings may also allow you to transmit a "Do Not Track" signal when you visit various websites. Like many websites, our Services are not designed to respond to "Do Not Track" signals received from browsers.

### Cookies and Other Tracking Technologies

We use cookies and other Tracking Technologies to collect information about your browsing activities over time and across different websites following your use of our Website and Services. Cookies allow us to recognize, associate certain analytical information, and count the number of users and to see how our Services are used. This helps us to improve our Services and the way it works. You can find more information about cookies and how to manage them through your browser settings.

You may control the way in which your devices permit the use of Tracking Technologies. If you so choose, you may block or delete our cookies from your browser; however, blocking or deleting cookies may cause some of the Services, including general functionality, to work incorrectly. Most browsers accept cookies automatically.

## Third-Party Websites and Links

Our Services may contain links and/or features (e.g., "like" or "share" buttons) to other websites and/or online platforms operated by third parties. We do not control such other online platforms and are not responsible for their content, their privacy policies, or their use of your information. Information you provide on public or semi-public venues, including information you share on third-party social networking platforms (such as GitHub or Twitter) may also be viewable by other users of the Website and/or users of those third-party online platforms without limitation as to its use by us or by a third party. Our inclusion of such links does not, by itself, imply any endorsement of the content on such platforms or of their owners or operators except as disclosed in the Services. We expressly disclaim any and all liability for the actions of third parties, including but not limited to actions relating to the use and/or disclosure of personal information by third parties. Any information submitted by you directly to these third parties is subject to that third party's privacy policy.

## Data Security & Retention

Please note that any information you send to us electronically, while using the Services or otherwise interacting with us, may not be secure when it is transmitted to us. We recommend that you do not use unsecure channels to communicate sensitive or confidential information to us. Please be aware though that, despite our best efforts, no security measures are perfect or impenetrable, and we cannot guarantee "perfect security." Any information you send us through any means is transmitted at your own risk. We retain your information for as long as is reasonably necessary for the purposes specified in this Privacy Policy. When determining the length of time to retain your information, we consider various criteria, including whether we need the information to continue to provide you the Services, resolve a dispute, enforce our contractual agreements, prevent harm, promote safety, security and integrity, or protect ourselves, including our rights, property or products.

## Access to Your Information

You may request to access, transfer, or delete any personal information we hold about you by contacting us at the email set forth below.

## United States

The Services are provided from and in the United States. When you access the Services, information about you will be subject to U.S. data privacy laws.

## Contact Us

If you would like to reach out to ask questions regarding information about you that we collect or other questions about this Privacy Policy or your rights, you can email us at [hello@autter.dev](mailto:hello@autter.dev).