AI coding review tiers for regulated teams that still ship

Why one review path slows regulated teams

A single review path sounds fair, but it wastes time.

When every change goes through the same checks, a comment update sits in the same queue as an auth change, a migration, or code that touches patient or payment data. Reviewers spend their day sorting harmless edits from risky ones by hand. Small fixes wait behind work that actually needs close attention.

That also misses the real point of compliance. Auditors and internal control teams usually want proof that the team reviewed the right things, ran the right checks, and kept a clear record. They do not get extra safety because a spelling fix waited two days for the same approval path as a secrets change.

AI makes the weakness obvious because it raises the number of changes. Teams now produce more tests, more docs, more refactors, and more small cleanup pull requests. That is often useful, but weak triage breaks fast under the added volume.

Without review tiers, the queue grows in two bad ways at once. Low-risk changes pile up and frustrate engineers. Reviewers lose focus because every pull request looks equally urgent on paper.

The cost shows up in simple cases. One developer updates error text and adds a missing test. Another changes a database migration and touches token handling. If your merge approval workflow treats both pull requests the same, the safe edit waits too long, and the risky change does not get the extra scrutiny it needs.

Regulated software delivery needs discipline, but discipline is not delay. Strong teams separate proof from friction. They keep strict review where risk is real, and they let minor edits move with lighter checks that still leave an audit trail.

Sort changes by risk, not by author

Teams get stuck when they start with the wrong question. "Did a person write this or did AI write it?" sounds careful, but it rarely reduces risk.

A typo fix from an AI assistant should not wait in the same queue as a database change. A risky edit to access rules does not become safe because a senior engineer wrote every line by hand.

Review rules work better when they follow impact. Start with what the change can affect: user behavior, stored data, access rights, audit records, billing logic, or production stability. If the answer is "almost nothing," use a light path. If the answer is "this could change records or permissions," use a stricter path.

Keep the model short enough to remember. Four levels are usually enough. Once a team creates seven or eight, people stop using them well and too many changes fall into the slowest lane.

A quick screen for each pull request helps. Ask whether the change affects what users see or do, touches stored data or a migration, changes permissions or secrets, or could alter audit trails or regulated records. One "yes" does not always mean the highest tier, but it should move the change out of the fast lane.

Reviewers also need permission to raise a tier when the context feels off. A diff may look tiny but sit in a fragile part of the codebase. A test edit may remove coverage for a rule the company must keep. Good review tiers judge the change in front of the team, not opinions about AI, seniority, or who opened the pull request.

Four tiers people can use quickly

A tier system works only if people can apply it in under a minute. The goal is simple: match review depth to risk.

Tier 1 covers comments, labels, copy edits, and other text-only changes that do not affect code paths, data, or runtime behavior. Tier 2 covers tests, small refactors, and cleanup work where behavior stays the same and no schema, config, or stored data changes. Tier 3 covers behavior changes, permission rules, feature logic updates, API contract changes, and database migration review work. Tier 4 covers secrets, authentication, encryption, credentials, tokens, and any code path that touches sensitive data.

If one pull request touches more than one area, use the highest tier it reaches. That rule matters more than most teams expect. A pull request might look harmless because most files are test updates, but one added permission check moves it to Tier 3. A docs change bundled with a secret scanning policy update becomes Tier 4. Mixed changes should never pass on the lightest path.

Keep the label visible in the pull request template. Ask the author to choose one tier and add one short reason. Reviewers should challenge the label if they spot a higher-risk file, but they should not spend half an hour debating edge cases. If a change feels hard to classify, move it up.

The system works because it reduces hesitation. Engineers know what evidence to attach. Reviewers know how deep to go. Compliance teams get a repeatable rule instead of gut feel.

A few examples make it concrete. Renaming test fixtures is Tier 2. Changing how user roles unlock a billing page is Tier 3. Rotating token handling or editing login flow is Tier 4. The rule stays the same even when AI wrote half the diff.

How low-risk text changes should move

Comment-only edits should take a light path, even in regulated software delivery. If a pull request changes code comments, README notes, spelling, or other non-executable text, one reviewer is usually enough.

That review still needs boundaries. The reviewer should confirm that the diff does not change behavior, does not alter instructions tied to safety or compliance, and does not smuggle in code or config changes.

Automation still runs on every pull request. Lint checks, file policy checks, and secret scanning should not disappear just because the change looks harmless. A copied token in a comment is still a leak. A broken markup file can still fail a docs build.

The reviewer does not need to debate every sentence. The real questions are simple: did the pull request touch only comments or non-executable text, do any changed words affect regulated statements or audit records, did the diff hide generated files or config changes, and did automated checks pass.

If the pull request includes hidden code, config, or generated files, stop and split it. Mixed diffs are where teams lose time and miss risk. A "comment cleanup" branch that also changes a feature flag, test fixture, or dependency file does not belong in the light tier.

One practical rule helps a lot: judge boundaries, not prose taste. If a comment now matches the code, the ticket, and the approved terms, merge it. If the wording changes meaning, sends users down a different path, or alters an audit note, raise the tier.

Tests, refactors, and migrations need different checks

These three change types should not go through the same review.

For test changes, start with one direct question: does the new test match real product behavior? If the product changed, the pull request should say what changed and show a small before-and-after example. If the product did not change, the author should explain why the old test was wrong. A loose assertion that replaces a strict one deserves a closer look.

Refactors are easier to review when they stand alone. If a pull request mixes cleanup, file moves, naming changes, and new behavior, reviewers waste time separating noise from risk. Bugs slip in that way. When possible, keep refactors separate from feature work and label them clearly as "no behavior change." Then prove it with the same inputs, the same outputs, and passing tests on the touched area.

Migrations need a higher bar. Every migration should include a rollback note before anyone approves it. The note does not need to be long. It can say whether the team can reverse the schema, restore a backup, or run a repair script. If the migration fails in production, the team needs a plan they can use right away.

Run migration checks before merge, not after. Test the migration on a realistic dataset, estimate how long it runs, and check for table locks, null issues, default values, and data loss. After the merge is too late to discover that a table lock stalls production.

A healthcare team gives a good example. If one pull request renames service methods, updates tests, and adds a patient table migration, review slows down for the wrong reason. Split that into smaller changes, and the team can inspect each risk with care without blocking every merge.

Secrets, auth, and sensitive data stay in the top tier

In regulated software delivery, a tiny auth edit can carry more risk than a large feature. Any pull request that touches secrets, permissions, or sensitive data belongs in the highest tier, even if the change looks small.

If a developer changes an API key, token, certificate, secret name, vault path, or environment variable, do not wave it through. The same rule applies when AI generates the change. One renamed env var can break rotation, expose a fallback value, or point production traffic at the wrong service.

Auth changes also need a second person every time. That includes login flows, role checks, session logic, password reset code, SSO settings, permission matrices, and middleware that decides who can see what. The second reviewer should check one thing first: who gets access before the change, and who gets access after it.

Generated code needs the same scrutiny. AI tools often copy patterns into config files, test data, and scaffolding. Reviewers should scan generated files for hardcoded tokens or passwords, real email addresses or account IDs, copied production hosts, and debug settings that expose headers, cookies, or request bodies.

Quiet leaks often show up outside application code. Teams focus on the main logic and miss sample payloads, seed data, support scripts, saved screenshots, and example curl commands. If a real customer value appears anywhere, remove it and replace it with fake data.

A simple rule keeps things clear: if the pull request touches secrets or access control, require both human review and automated scanning before merge. When in doubt, raise the tier. Five extra minutes of review costs less than a leaked token, a broken audit trail, or a user seeing data they should never see.

Put the tier in the pull request template

Most teams lose time because they argue about review depth after the code is already open. Put that decision in the pull request template so the author picks a tier before reviewers start.

Make the tier field required. A dropdown works better than free text because people cannot invent labels like "small change" or "safe update." The template should also ask one plain question: what is the highest-risk file, config, or workflow touched in this pull request?

That question matters more than size. If a change updates comments in ten files and also edits one auth rule, the auth rule decides the tier. If a pull request changes tests and includes one migration, the migration decides the tier.

Most teams need only a few fields: the selected tier, the highest-risk file or config changed, the reason for that tier, the proof attached for that tier, and the reviewer group requested.

The proof should match the tier. For a low-tier text or comment edit, that may be a short note and a clean diff. For tests or refactors, attach test results. For migrations, include the plan, rollback steps, and the result from a safe environment. For secrets, auth, or sensitive data, attach scan output and route the pull request to the reviewer named in policy.

Route reviewers by tier, not by habit. Many teams still send every pull request to the same senior engineer, even when the change only fixes wording. That creates a queue and teaches people to wait instead of decide. A low-tier pull request can go to one code owner. A higher tier can require a domain reviewer, security, or both.

Your merge rules should also check whether the selected tier matches the files and proof attached. If the pull request says Tier 1 but changes migration files, the bot should block it. If it says Tier 2 but no test evidence is attached, block it. Reviewers should not have to police paperwork by hand.

A simple healthcare example

A small healthcare product team ships a patient intake form every week. They use an AI coding assistant for routine changes, but they do not send every AI edit through the same path.

One morning, the tool rewrites help text under a consent checkbox. It changes "We may contact you" to clearer wording and fixes two spelling mistakes in the intake flow. Nothing in the logic changes, no fields move, and no data handling changes. The team marks that pull request as low tier. One person checks the wording, confirms that the copy still matches product rules, and merges it quickly.

Later that day, the team adjusts a small validation rule. The form now rejects phone numbers with letters, and the AI tool updates a few tests to match the new behavior. That change still stays fairly low, but it gets more attention than the text fix. A reviewer checks that the tests reflect the rule change and that the new validation does not block valid patient entries.

The next change looks similar at first, but it is different. The AI tool adds a new database column for consent status so the product can store whether a patient agreed to follow-up contact. That is no longer a light review. The team moves the pull request to a higher tier because schema changes can affect reporting, audit trails, backfills, and rollback plans. Now they want a second reviewer, migration checks, and a clear deployment plan.

Then the team spots one more detail: the same pull request also touched an API token in a config file. That one line changes the whole decision. Even if the rest of the work looks clean, the pull request jumps to the top tier. The team stops the merge, rotates the token, checks logs, and splits the safe database work from the secret issue.

That is the whole point of review tiers. The text edit stays light. The migration moves up. A secret change puts the whole change set under the strictest review.

Mistakes that slow delivery or miss risk

Teams freeze delivery when they treat every AI-made change like a production incident. That feels safe, but it creates a long queue, tired reviewers, and rushed approvals late in the day. Delay becomes its own risk because people stop reading carefully and start rubber-stamping.

The opposite mistake is common too. A team lets the author mark a pull request as "low risk" and move on. That works only when someone else checks the label. Authors know the context, but they also miss their own blind spots.

Database work often slips through because it hides inside broad cleanup. A pull request may say "refactor services" while also changing a migration, index, or column type. That is how real risk gets buried in harmless-looking code. If a migration exists, the review path should say so in plain words and move it into the stricter lane.

Short diffs can still need rollback notes. A one-line config edit, a dependency bump, or a changed timeout can break a release just as fast as a larger feature. Before merge, someone should be able to answer two simple questions: what changes in production, and how do we undo it quickly?

Urgent fixes create another bad habit. A secret scan gets waived because the patch is "hot" and the team wants to restore service. That shortcut is hard to defend later. Urgent work needs the scan more, not less. Pressure is when people paste tokens into code, logs, or test files.

A few rules prevent most of this. Another reviewer should confirm the risk tier. Migrations should be called out in the pull request title or template. Every production change should include a rollback note. Secret scans should run on every merge, including emergency fixes.

Start small and adjust fast

Start with one repository that already touches a regulated path. Pick something real, like a customer onboarding flow, a billing update, or a form that stores sensitive data. One pilot gives better feedback than rolling new rules across every team at once.

Keep each tier short enough that a busy engineer can read it in two minutes. Put every tier on one page in plain language. For each one, explain what kind of change fits, which CI checks must pass, when a human reviewer must approve, what needs extra review such as migrations or auth changes, and what blocks the merge.

That short document matters more than a fancy policy file. If people cannot assign a tier quickly, they will guess, and that is where review systems drift.

For the first couple of weeks, track a few numbers by hand if needed. Measure review time, reopen rate, and escaped defects. Review time tells you whether the process is too heavy. Reopen rate shows whether people choose the wrong tier. Escaped defects show where the rules are too loose.

Expect to adjust the model after that first stretch. Most teams find one tier that catches too many low-risk edits and one tier that lets risky database or secret-related changes move too easily. Fix those edges before you copy the model to other repositories.

The best review tiers are boring and clear. A simple rule people follow beats a smart rule nobody remembers.

If a startup or small business needs help setting this up, Oleg Sotnikov shares a lot of this kind of practical AI-first engineering and review thinking through oleg.is. His Fractional CTO work is especially relevant for teams that need stricter controls without turning every merge into a week-long process.