AI Coding Assistants Are Untrusted Contributors at Colleague Speed

Nobody sat in a planning meeting and decided to hire a contributor who commits at three in the morning, never reads the style guide, and cannot be paged. It happened the week product shipped an assistant into the IDE, someone switched on the review bot, and a test generator started filling in the gaps. By the end of the sprint one pull request had touched north of forty files, passed CI clean, and collected three approving comments from a bot that had read the whole diff in under a minute.

That looked like a productivity win. It was a staffing decision nobody made. You did not add a tool to your editor — you onboarded a contributor who works at colleague speed and answers to no one, and you routed its first week straight past the gates you would never let a new hire skip.

Here is the reframe that survives every model swap: an AI coding assistant is not a smarter autocomplete, it is an untrusted contributor working at colleague speed, and your delivery pipeline, not your trust, is what absorbs its output. The classical instinct that review keeps pace with code because both are bounded by how fast people type is the assumption that breaks first. This is a guide to those gates, not to picking tools.

You Already Own the Right Controls

You do not need a new process for code the AI writes. You already have one, and you built it for exactly this situation: the untrusted external contributor.

Think about how a change from someone outside your trust boundary enters your tree. It arrives as a pull request, never a direct push to main. It gets read by someone who can block it. It cannot merge until CI is green. Those three controls — mandatory review, small PRs, required status checks — were never really about the person. They were about the code: a change whose author’s judgment you cannot personally vouch for. That description fits an AI Code Completion suggestion and an agentic refactor just as cleanly as it fits a first-week hire’s first PR.

Mental Model Map: AI Coding Assistants in Your Delivery Pipeline From: An AI assistant is a faster autocomplete — a tool you point at your code. Shift: It commits, reviews, and tests at colleague speed, from a source you cannot vouch for. To: It is an untrusted contributor, and your PR, review, and CI gates are what absorb it. Key insight: You already know how to onboard code you do not trust — you just have to admit that is what this is.

So the controls transfer. What breaks is the reflex around them. The assistant does not feel like a contributor — it feels like an extension of your own hands, an editor feature, a faster keyboard. And you do not gate your own keyboard. That is the misconception that does the damage: a team that would never let a new hire push straight to main will happily wave the same class of unreviewed change through, because it arrived wearing the costume of autocomplete.

The fix is unglamorous and it is the whole game. Route every AI-authored change down the path you already trust for code you did not write — AI Code Review bots included, because the bot is one more untrusted contributor, not a reviewer with authority. In practice, this means the assistant’s output earns a PR, the PR earns a human read, and nothing merges on the model’s say-so alone.

Why Your Review Capacity Breaks First

The bottleneck is not your keyboard anymore. It is your review queue, and most teams do not notice the move until it has already happened.

In a classical workflow, code inflow is bounded by how fast people type. Review roughly keeps pace because both sides run at human speed — one person writes for a day, another reads for an hour, and the ratio holds. The assistant breaks that coupling. Generation speed decouples from the review and CI capacity that has to absorb it. Your team can ship the same features it shipped last quarter, with the same headcount, and still watch the delivery math change — because every engineer now produces review load faster than the reviewers can retire it. By 2026, more than one in five lines of merged code is AI-authored, per ALAN’s licensing analysis, which means your review queue is already absorbing a share of the codebase no human typed.

The tests do not save you here — they often make it worse. An AI Test Generation pass will happily add a suite that compiles, runs, and reports high line coverage while detecting almost no faults. A generated suite can sit above ninety-percent line coverage and score close to nothing under mutation testing, which is the measurement that actually asks whether a test would notice a bug. MONA lays out that gap in the coverage-versus-mutation breakdown. So the assistant’s tests do not lighten the review load — they add more code a human has to check, and they arrive pre-stamped with a coverage number that looks like assurance.

Diagnosis: the constraint moved from writing to reviewing, and nobody re-sized the reviewing. The fix has two parts. First, hold the line on small PRs — the assistant has no instinct to keep a diff readable, so scope discipline has to come from your side, in the spec you hand it and the size you agree to accept. Second, size review capacity against generation speed, not typing speed. MAX’s review-integration guide walks the four decisions — surface, spec, sequence, validation — that decide whether the bot cuts reviewer load or piles onto it, and the test-generation guide makes the same point about suites: validate by what the tests catch, not by what they cover. In practice, an assistant you adopt without expanding review throughput does not speed up delivery — it moves the traffic jam one stage downstream, from the branch to the merge queue.

What the Green Checkmark Certifies Now

A green CI run used to carry a hidden second signal. It told you the tests passed, and it told you a human had reasoned about the change well enough to write those tests. Those two facts traveled together for so long that the industry started treating the green checkmark as the merge contract itself.

Now the same model can write the code and the tests that gate it. When that happens, green certifies something much smaller than you think: that the model’s output is consistent with the model’s own assumptions. If those assumptions are wrong in the same direction on both sides — a misread requirement, a plausible-but-nonexistent API — the code and its tests agree, the build goes green, and the checkmark certifies a closed loop. This is the same class of confident, self-consistent error MONA traces through the hard limits of LLM bug detection: the model is fluent, and fluency is exactly what makes a wrong answer look reviewed.

The fix is to add one gate the model cannot author its way around. Mutation testing is the cleanest example: it grades the tests instead of trusting them, so a suite the model wrote to hit a coverage target cannot also grade itself as sufficient. An independent reviewer configuration, or a required human sign-off on any PR labeled AI-authored, does the same job at the process layer. AI in CI/CD Pipelines still answers to human merge authority by design, as MONA notes in the CI/CD explainer — the danger is quietly signing that authority over to the same system that produced the change. In practice: never let the thing that wrote the code be the last thing that certifies it.

Who Owns the Merge Nobody Signed

Your merge-authority model has an assumption baked so deep you probably never wrote it down: every change has a named human author who is answerable for it. That assumption is what makes a postmortem possible.

Agentic workflows dissolve it one step at a time. A self-healing pipeline — AI-Assisted Debugging wired into the merge loop — can open a fix, review it, run its own generated tests, and merge, with no human in the path. It works most of the time, which is exactly why it is dangerous. The failure looks like this: a refactor moves a signal handler that registered at module load into a lazily imported module the scheduler never touches, everything stays green, and by Wednesday afternoon the on-call channel is on fire. AI-Assisted Refactoring did the edit, the agent approved the edit, and the changelog records a success with no author on the line. DAN traces where these self-healing loops are heading in the agentic-pipeline race; ALAN sits with the harder question in who owns the broken auto-merge.

Shift Diagram: Who Touches a Change Before It Merges Classic: Human writes → Human reviews → CI gates → Human merges AI: Agent writes → Agent reviews → Agent-authored tests gate → Auto-merge

Diagnosis: the pipeline learned to heal itself; the accountability did not heal with it. The fix is not to ban auto-merge — it is to keep a named human on the merge-authority line for anything the agent can merge on its own, and to log provenance so you can tell, after the fact, which merges the machine authored and approved. In practice, self-healing is a fine property for a staging environment and a deliberate decision for production, never a default you discover during an incident.

Before You Let the Assistant Open PRs

Run these questions against your own stack before the next assistant rolls out. They are not about the tool. They are about whether the gates you already trust are still in the path.

For the full prerequisite map and the questions a first rollout tends to raise, see the AI coding assistants topic hub.

The assistant is not a tool you switched on. It is a contributor you onboarded without meaning to, and the only safe move is to treat its output the way you already treat code from anyone whose judgment you cannot personally vouch for — through the gates, never around them. Monday, take one path where AI-authored changes can reach main, and put a human back on its merge-authority line.