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 and Create a custom rule.
Handle findings
Read the review summary
Understand the intent and affected systems before inspecting individual comments.
Prioritize behavior and risk
Address security, correctness, and data integrity findings before style or maintainability feedback.
Review suggested fixes
Treat every generated fix as proposed code. Check it against tests, requirements, and repository conventions.
Autter supports human review; it does not replace it. Reviewers still own architecture, product intent, operational tradeoffs, and approval.