§ 1In 1996 I reviewed code written by a junior who could produce more in a day than the rest of the team combined. Half of it was brilliant. The other half opened a remote shell if you knew which port to knock on. We didn’t fire him — we built a review culture around him, and he became the best engineer I’ve worked with. Every AI coding assistant you’ve licensed is that junior, multiplied by your headcount, working nights.
The industry keeps reaching for the wrong metaphor. An assistant is not malware to be blocked, and not an oracle to be trusted. It is staff — prolific, tireless, unaccountable staff — and we have thirty years of practice managing exactly that. What’s new is the volume, and volume is a pipeline problem, not a philosophy problem.
Never let it merge alone
The single control with the best return is embarrassingly simple: generated code never reaches a protected branch without a human approval that is recorded as such — a review event, attributable, with the assistant’s involvement declared in the commit trailer. The CI gate, trimmed to its working core:
# Block assistant-authored merges without human review
on: pull_request
jobs:
provenance:
steps:
- run: |
git log --format=%B origin/main..HEAD \
| grep -q "Assisted-by:" \
&& gh pr view --json reviews \
-q '.reviews[] | select(.state=="APPROVED")' \
|| exit 1Teams push back on the trailer — “developers won’t declare it.” They will, if the declaration buys them something: faster review lanes for declared code, and amnesty when it’s wrong. Make honesty cheaper than concealment. That is policy design, and it is the actual job now.
The optimist’s case
An assistant never tires of being reviewed, never takes feedback personally, and applies a correction to every future suggestion. Your worst junior becomes your best one overnight. No human team ever offered that deal.