> ## Documentation Index
> Fetch the complete documentation index at: https://autter.dev/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Code review

> Use codebase-aware feedback, summaries, team rules, and suggested fixes on every pull request.

Autter reviews proposed changes in GitHub and GitLab. It looks beyond syntax to evaluate logic paths, edge cases, codebase conventions, and the wider impact of a change.

<Frame caption="Placeholder: replace with an approved pull request review screenshot.">
  <img src="https://mintcdn.com/autter/ZqVSJE8MeDV-Tn7Q/images/placeholders/review-comment.svg?fit=max&auto=format&n=ZqVSJE8MeDV-Tn7Q&q=85&s=2e8beda19006f0122836004d1fce28b1" alt="Placeholder showing an Autter inline pull request finding with an explanation and suggested fix" width="1200" height="620" data-path="images/placeholders/review-comment.svg" />
</Frame>

## What a review includes

* a concise summary of the change
* a walkthrough of important files and behavior
* inline findings tied to affected code
* architectural context or diagrams when available
* suggested fixes for actionable findings
* results from enabled rules, linters, and scanners

## What Autter looks for

Autter is designed to find issues that can survive a surface-level review:

* incorrect assumptions and unhandled edge cases
* security and authorization mistakes
* code that conflicts with repository architecture
* deviations from team conventions
* missing or weak tests around changed behavior
* dependency and scanner findings relevant to the diff
* behavior that appears correct in isolation but fails in the wider codebase

## How context changes the review

A generic rule might flag every direct database call. A codebase-aware review can distinguish between an approved repository layer and a controller that bypasses it.

Autter can ground feedback in:

* related files and dependencies
* established repository patterns
* natural-language team rules
* prior review comments and team knowledge
* linked issues and documentation
* current linter and scanner results

## Use team rules

Define standards in plain language. For example:

> Payment webhooks must be idempotent and include a test for repeated delivery.

Keep rules specific and testable. See [Review rules](/configuration/rules) and [Create a custom rule](/guides/custom-rules).

## Handle findings

<Steps>
  <Step title="Read the review summary">
    Understand the intent and affected systems before inspecting individual comments.
  </Step>

  <Step title="Prioritize behavior and risk">
    Address security, correctness, and data integrity findings before style or maintainability feedback.
  </Step>

  <Step title="Review suggested fixes">
    Treat every generated fix as proposed code. Check it against tests, requirements, and repository conventions.
  </Step>

  <Step title="Update the pull request">
    Push changes and review the latest Autter result alongside human feedback.
  </Step>

  <Step title="Improve noisy rules">
    Refine a rule or pipeline check when it repeatedly flags valid code.
  </Step>
</Steps>

<Note>
  Autter supports human review; it does not replace it. Reviewers still own architecture, product intent, operational tradeoffs, and approval.
</Note>