Coding assistants in a senior team: rules that protect quality

What breaks when rules stay vague

When a team says "use the assistant when it helps" and leaves it there, review gets slower. Senior engineers stop skimming and start checking every line because they don't know what the tool touched, what it guessed, or what it quietly rewrote. That isn't speed.

Vague rules create noisy diffs. A prompt meant to rename a field or clean up a test can drift into service code, schema logic, or auth checks. Nobody asked for those extra edits, but now somebody has to trace them.

Reviewers feel that first. One commit is a harmless refactor. The next changes error handling on a path that fails once a month in production. Because the risk is uneven, people read more, not less.

The real disagreement often shows up too late. One engineer assumes the assistant may touch only tests and docs. Another assumes it may refactor production code as long as tests stay green. That argument belongs before the prompt, not after the pull request opens.

Vague limits also turn small edits into behavior changes. A developer asks for comment cleanup and gets a rewritten condition, a new helper, and a changed default value. Each edit looks minor. Together, they change the product.

That uncertainty changes behavior. Some authors hide assistant use because they expect pushback. Others paste in large diffs and hope the test suite will catch the risk. Both habits make review worse because the team loses a shared idea of what normal looks like.

Trust drops quietly. Reviewers stop trusting commit size. Authors stop trusting feedback. Managers stop trusting the promised time savings. The tool isn't the main issue. The missing boundary is.

Clear limits fix that. When a team defines scope, proof, and off-limits changes early, people spend less time arguing about intent and more time checking results. Standards stay visible, ordinary, and much harder to lower by accident.

Set file scope before anyone writes a prompt

Teams lose control when a prompt says "update onboarding" and nobody names the files first. The assistant fills gaps with guesses, and guesses spread fast across a repo. File scope should come before the first prompt, not after the diff turns messy.

Start where mistakes are cheap. Docs, tests, and small modules with few dependencies are good places to begin. They usually affect less of the system, and they're easier to review and undo.

Then draw a hard line around code that always needs human judgment. Auth, billing, data deletion, and database migrations should stay blocked unless an engineer approves a very narrow task. One bad assumption there can lock users out, charge the wrong account, or remove data you can't get back.

Don't keep these rules in someone's head. Put them in the repo with plain folder names and short comments. If a folder contains login logic, payment code, deletion jobs, or schema changes, mark it as protected even when an edit looks small.

The policy can stay simple: allow early use in docs, tests, and low dependency modules; protect auth, billing, deletion flows, and migrations; require engineers to name the exact files before every prompt; reject vague requests like "fix the whole flow" or "update anything related."

That last rule does more than it seems. "Change price_rules.go and pricing_test.go" gives the model a fence. "Update the pricing system" tells it to wander.

One product team used this on a checkout bug. The engineer limited the assistant to one validator file and one test file, fixed the issue, and left the payment flow alone. It felt strict for a small bug, but it cut review time and avoided a bigger cleanup later.

Require proof for behavior changes

When a change affects behavior, the pull request needs evidence from tests, not a note that says "it should work now."

Ask for two things: proof that failed before the fix, and proof that passes after it. That can be a failing test, clear failing output, or a short reproduction. The point is to give reviewers something concrete to check.

The proof has to match the claim. If the assistant says it fixed a timezone bug in scheduling, reviewers should see a test for that timezone case. A green build from unrelated tests proves almost nothing. If the assistant claims it improved retry logic, show retry tests, not just a screenshot of the app loading.

Good proof is usually simple. Show the test name or command, a short piece of failing output, the passing result after the edit, and one sentence connecting that test to the behavior that changed.

This rule should stay strict. Reject pull requests that rely on comments like "fixed," "works on my machine," or "the model checked the logic." Those save a minute now and cost hours later.

Take a small checkout example. If the assistant changes price rounding, the pull request should show a failing test for the old rounding case and the same test passing after the fix. A full suite passing still doesn't tell the reviewer whether that bug changed at all.

Test output makes review calmer. Reviewers can approve when the evidence fits the claim, ask for better proof when it doesn't, or stop the change when the tests show wider damage. Teams that skip this usually end up arguing about guesses.

Label risky change types in plain words

A senior team shouldn't argue about risk after the code is already written. Put a simple label on each task or pull request that uses an assistant before work starts.

Use plain categories a reviewer can understand at a glance. Low risk means copy edits, comments, formatting, renames, and text cleanup with no behavior change. Medium risk means small logic fixes inside one area, limited UI behavior updates, or test-only work that doesn't alter production code. High risk means schema changes, security rules, payment logic, concurrency, infrastructure edits, or changes spread across many files.

Schema changes belong in the highest-risk group every time. A new column or index can look minor in a diff, but it can break old code, slow queries, or leave a deploy half finished. If an assistant changes the database shape, the team should ask for a migration plan, a rollback plan, and proof that old and new code can run together during release.

Security, money flow, and concurrency need the same caution. One small access rule can expose the wrong data. One payment update can double-charge or skip a refund. One missed lock, retry rule, or queue check can create bugs that appear only under load, which makes them slow to find and expensive to fix.

Teams also need a clean line between cleanup and behavior changes. Renaming variables, rewriting comments, and reformatting files belong in one bucket. If the assistant changes what the code does, even a little, move it into a different one and review it more closely.

File count matters too. A safe-looking change in one file is easy to reason about. The same pattern copied across 15 files is a different risk level, even when each edit looks harmless on its own. Shared types, common helpers, and cross-service edits deserve stricter review because one bad assumption can travel far.

When two labels seem to fit, pick the higher one. That keeps review clear, and it stops "small" AI changes from slipping into production with big consequences.

Roll it out in small steps

A slow rollout beats a broad launch. Start with one team and one part of the repo where mistakes are easy to spot and easy to undo. Internal tools, test helpers, or simple UI work make better starting points than auth, billing, data migrations, or anything that can break production fast.

Write the first rules on one page. Keep them short enough that everyone can remember them. Say which folders the assistant may touch, what proof each behavior change needs, and which kinds of work always need a senior human to lead.

You don't need a long policy. Limit assistant edits to a named folder or service. Require tests and lint for any nontrivial change. Block large diffs in CI unless a reviewer approves them. Flag schema changes, auth code, payment logic, and delete flows as risky work. Ask reviewers to confirm that the change stayed inside scope.

Add CI checks right away. Spoken rules disappear when the team gets busy. A test gate, lint gate, and diff-size check catch the easy failures before review starts. That leaves reviewers with the part that still needs judgment: whether the change is clear, correct, and worth keeping.

Review the pilot every week, but keep that review short and factual. Look at rework, failed tests, rollbacks, and review comments. If the same issue shows up twice, change the rule. Usually the weak spot is obvious: the file scope was too wide, the proof was too thin, or the assistant touched code it shouldn't have touched yet.

This matches how Oleg Sotnikov describes AI first operations: keep the possible damage narrow, measure the result, then expand. The order matters.

Only widen the scope after several clean review cycles in a row. If senior engineers still rewrite most of the output, the rollout is still a trial. Keep it small until the team can predict the failure patterns before they ship.

A simple example from a product team

A product team needs a small signup change. Marketing wants clearer error messages, and support wants one extra rule for password length. This is a reasonable place to use an assistant because the work is narrow and easy to check.

The engineer sets file scope first. The assistant can update validation tests, test fixtures, and the small helper that only affects this form. It can't touch payment code, database tables, schema files, or anything tied to account billing.

That limit matters more than the prompt. The team keeps risky areas off the table, so nobody has to guess whether a quick AI edit crossed into a part of the product that can break billing or stored data.

The pull request stays simple: the exact prompt, the assistant's diff, and the test run that proves the change works.

Review stays strict. One senior engineer reads the prompt to see what the assistant was asked to do. Another checks the diff and test output. If the tests cover only the easy path, they ask for more.

During review, they spot one risky function. The assistant changed a shared validator in a way that could affect other forms. A human rewrites that function by hand before merge and keeps the AI-generated test updates.

That's the whole point of the policy. The team uses the assistant for routine work, then brings human judgment back in as soon as the change starts to spread.

The result is modest, and that's usually a good sign. The engineer saves about 30 minutes on repetitive test edits. Review quality doesn't drop. Nobody relaxes the proof standard, and nobody treats code written with AI as special.

Over a month, those small wins add up. The team clears boring work faster, while payment logic, schema changes, and shared business rules still get the same careful attention they always needed.

Mistakes that lower standards fast

Standards rarely collapse in one dramatic failure. A team makes a few small exceptions, ships a few easy wins, and starts calling that normal. Then the habits spread.

One common mistake is giving the assistant a broad area to edit with a single prompt. If it can touch a whole service, or several folders, reviewers stop seeing the real risk. A change that started as "fix a validation bug" can quietly alter logging, caching, config, and error handling at the same time.

The main danger is false confidence. Assistant output often looks tidy, which makes people trust it before they check what actually changed.

A few patterns come up again and again. One prompt edits files that should have stayed out of scope. Tests pass, but they only cover the easy path and miss the real failure mode. A big diff gets merged because most of it looks like harmless cleanup. Reviewers relax because the code looks routine and the assistant wrote it fast. Then the team blames the tool instead of fixing the rule that let the mistake through.

Green tests can still hide a bad change. Say the assistant updates an API handler and all unit tests pass. If nobody checked auth rules, retry behavior, or a strange input case from production, those tests proved very little. Passing checks are not proof when they skip the part that can hurt users.

Large diffs are another trap. Cleanup is where renamed fields, changed defaults, and moved conditions can hide in plain sight. If a reviewer needs ten minutes just to understand what changed, the diff is too big.

Skipping review is worse. Senior teams should inspect assistant output more closely, not less. The code can compile, match local style, and still carry a bad assumption.

When this happens, fix the process instead of arguing about the tool. Shrink file scope. Ask for proof tied to the risk. Split big diffs. If the same mistake happens twice, the rule was too loose.

Quick checks before merge

A merge review needs five blunt questions. They take about a minute and catch most of the damage hidden inside tidy-looking diffs.

Check the file list first. The author should name the expected files before review starts. If the diff touches extra files, ask why. Surprise edits are where bad assumptions hide.

Ask for proof, not intent. A comment that says "this should work" is not enough. The branch should include tests, logs, screenshots, or a short repro that shows the claimed behavior.

Scan risky areas early. If the change touches auth, billing, permissions, data deletion, imports, exports, or anything users can't undo, slow down and review it by hand.

Read the diff like a new teammate would. If the reason for the change is fuzzy, the code is not ready. A short note in the pull request should explain what changed, why it changed, and what did not change.

Make rollback easy. One small commit is better than a mixed bundle of refactors, prompt output, and config edits. If the release goes wrong, you want one clean revert.

This is where proof gets real. A passing unit test can still miss the point if it checks only a mocked path. If a user can lose access, get charged twice, or delete data, ask for one test or demo that shows the full behavior end to end.

A small example shows why size can mislead. An assistant updates a checkout flow and the diff is only 40 lines. That sounds safe. But if those 40 lines change retry logic around payment capture, the review is no longer about size. It's about the cost of failure.

When one answer is weak, don't start a ten-comment debate. Send the change back with a narrow ask: trim the scope, add proof, or split the commit. Good teams keep standards high because they make the next step obvious.

What to do next

Start with one safe use case in the next sprint. Pick work that is easy to review and easy to undo, such as test updates, small refactors inside one module, or repetitive type fixes. Don't start with auth, billing, permissions, migrations, or anything that can break data.

That first choice shapes how the team feels about the experiment. A narrow trial gives reviewers a fair chance to check the code properly. If the assistant makes a bad call, the damage stays small.

Write down three no-go areas and put them where the team already looks during daily work, not in a forgotten doc: no schema changes or data migrations, no auth, payment, or permission logic, and no AI-written behavior change without test proof.

Then add a short review template to every pull request that used AI. Three questions are enough: what files were in scope, what risk label applies, and what proof backs the change. It takes about a minute, and it cuts off vague approvals like "looks good."

Standards usually slip for a boring reason: nobody made the rules visible at review time. A small template fixes more than another policy memo.

If you want an outside check, Oleg Sotnikov at oleg.is works as a Fractional CTO and helps startups and small teams put practical guardrails around development that uses AI, infrastructure, and automation. If your team is still figuring out the limits, a short review of your workflow can save a lot of back-and-forth later.

By the next sprint planning meeting, do three things: choose the safe use case, publish the no-go areas, and add the review template. That's enough to start learning without lowering the bar.