{"slug": "write-your-engineering-standards-once-check-every-ai-generated-pr-against-them", "title": "Write Your Engineering Standards Once. Check Every AI-Generated PR Against Them.", "summary": "Aviator launched Aviator Verify, a product that lets engineering teams write rules called Invariants once and have a separate AI agent check every pull request — including those opened by coding agents — against them, returning pass or fail with evidence before human review. Verify drafts candidate Invariants from a team's PR history and docs, but they remain drafts until a team member approves them, and any invariant can be waived with a logged reason such as false positive, not applicable, accepted risk, or fix in a follow-up. The tool targets convention blindness, deprecated APIs, module boundaries and security baselines that linters cannot express, and a free Aviator account generates Invariants the team keeps even without continuing with Verify.", "body_md": "# Write Your Engineering Standards Once. Check Every AI-Generated PR Against Them.\n\nYour team’s engineering standards can be checked automatically on every PR, including every PR a coding agent opens. You write each rule once. From then on, a separate agent checks every change against it and reports pass or fail, before a human ever opens the diff.\n\nThat means code that ignores how your team builds things doesn’t reach production just because it compiled, passed tests, and looked fine. And your senior engineers stop spending review time catching the same agent mistakes over and over.\n\nIn [Aviator Verify](https://www.aviator.co/verify), these rules are called [Invariants](https://docs.aviator.co/verify/concepts/invariants).\n\n## **What an Invariant is, and why you need one**\n\nAn invariant is a rule every change must respect. Invariants address the most common category of AI slop: convention blindness, deprecated APIs, module boundaries the model doesn’t know about, and security baselines that should apply everywhere.\n\nNone of these are in the model’s training data for your specific codebase. They live in the heads of your senior engineers and show up as recurring review comments. Invariants say what *every* PR should respect, for example:\n\n- Writes to the users table go through UserRepository.\n- HTTP handlers call auth middleware before any business logic.\n- Migrations declare a down block.\n\nThese are the rules your linter can’t express, because they’re about what the code does, not how it’s written. Today they live in senior engineers’ heads and in Skills or files like CLAUDE.md. They tell an agent your rules, but nothing checks whether the agent followed them.\n\nWith Invariants, the rule is written once, stored in your Aviator account for the whole team, and checked on every matching change.\n\n## **Where Invariants Come From**\n\nMost good invariants start as a review comment someone has typed more than twice. You don’t have to write them from scratch. Verify drafts them from what your team already knows:\n\nAI-drafted rules start as drafts. They don’t affect any PR until someone on your team approves them.\n\n**See what your team’s invariants would look like.** With a [free Aviator account,](https://app.aviator.co/auth/register) Verify generates them from your PR history and docs. You keep them even if you don’t continue with Verify.\n\n## **How it works**\n\n1. **Verify picks the rules that fit.** When a PR comes in, a selector reads the change and its intent and picks the invariants that apply. Nobody tags rules by hand, and a CSS change doesn’t get checked against database rules. You can also scope a rule to certain paths or languages with[conditions](https://docs.aviator.co/verify/reference/invariant-conditions) .\n2. **A separate agent checks them.** Each selected invariant gets a pass or fail, with evidence pointing at the code that broke it. The verdict says what’s wrong; the author decides how to fix it. See[how verification works](https://docs.aviator.co/verify/concepts/how-verification-works) .\n3. **Exceptions are allowed, Invariants evolve.** Any invariant can be waived with a reason: false positive, doesn’t apply, accepted risk, or fix in a follow-up. Every waiver is logged. If one rule keeps getting waived, that’s your signal to reword it.\n\nThe full reference is in the [invariants docs](https://docs.aviator.co/verify/concepts/invariants), and [setting up org invariants](https://docs.aviator.co/verify/setting-up-org-invariants). \n\n**See what your team’s invariants would look like.** With a [free Aviator account,](https://app.aviator.co/auth/register) Verify generates them from your PR history and docs. You keep them even if you don’t continue with Verify.", "url": "https://wpnews.pro/news/write-your-engineering-standards-once-check-every-ai-generated-pr-against-them", "canonical_source": "https://www.aviator.co/blog/ai-code-review-invariants/", "published_at": "2026-10-29 17:59:50+00:00", "updated_at": "2026-10-29 18:19:38.685335+00:00", "lang": "en", "topics": ["ai-agents", "developer-tools", "ai-tools", "artificial-intelligence"], "entities": ["Aviator", "Aviator Verify", "Invariants"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/write-your-engineering-standards-once-check-every-ai-generated-pr-against-them", "markdown": "https://wpnews.pro/news/write-your-engineering-standards-once-check-every-ai-generated-pr-against-them.md", "text": "https://wpnews.pro/news/write-your-engineering-standards-once-check-every-ai-generated-pr-against-them.txt", "jsonld": "https://wpnews.pro/news/write-your-engineering-standards-once-check-every-ai-generated-pr-against-them.jsonld"}}