How to Kill the Code Review

How to Kill the Code Review

Как убить код-ревью

Human-written code died in 2025. Code reviews will die in 2026.

Код, написанный людьми, умер в 2025 году. Код-ревью умрёт в 2026-м.

Second wave speakers for AIE Europe and CFP for AIE World’s Fair are announced today, and OpenCode is confirmed for Miami! We’ll also be in Melbourne & Singapore.

Сегодня объявлена вторая волна спикеров AIE Europe и CFP для AIE World's Fair, а также подтверждено участие OpenCode в Майами! Мы также будем в Мельбурне и Сингапуре.

Editor: This is the latest in our guest post program, where we will publish AI Engineering essays worth considering, even if we don’t personally agree with them — having just shipped an AI review tool, this is one of those cases where I am not there yet, but is clearly on the horizon, and am happy for Ankit to argue the case!

От редакции: Это новый выпуск в рамках нашей программы гостевых публикаций, где мы публикуем эссе об AI-инженерии, заслуживающие внимания, даже если лично мы не со всем согласны. Только что выпустив инструмент для AI-ревью, я признаю, что сам ещё не дошёл до этой точки, но она явно на горизонте, и рад, что Ankit берётся отстаивать эту позицию!

Humans already couldn’t keep up with code review when humans wrote code at human speed. Every engineering org I’ve talked to has the same dirty secret: PRs sitting for days, rubber-stamp approvals, and reviewers skimming 500-line diffs because they have their own work to do.

Люди и так не справлялись с код-ревью, когда люди писали код с человеческой скоростью. У каждой инженерной организации, с которой я общался, один и тот же грязный секрет: PR висят днями, одобрения ставятся формально, а ревьюеры бегло просматривают диффы на 500 строк, потому что у них своя работа.

We tell ourselves it is a quality gate, but teams have shipped without line-by-line review for decades. Code review wasn’t even ubiquitous until around 2012-2014, one veteran engineer told me, there just aren’t enough of us around to remember.

Мы убеждаем себя, что это контроль качества, но команды десятилетиями выпускали код без построчного ревью. Как сказал мне один опытный инженер, код-ревью не было повсеместным примерно до 2012–2014 годов — просто мало кто из нас помнит те времена.

And even with reviews, things break. We have learned to build systems that handle failure because we accepted that review alone wasn’t enough. This shows in terms of feature flags, rollouts, and instant rollbacks.

И даже с ревью всё ломается. Мы научились строить системы, которые справляются с отказами, потому что признали: одного ревью недостаточно. Это проявляется в feature flags, поэтапных раскатках и мгновенных откатах.

We have to give up on reading all the code

Нам пора перестать пытаться прочитать весь код

Teams with high AI adoption complete 21% more tasks and merge 98% more pull requests, but PR review time increases 91%, based on data from over 10,000 developers across 1,255 teams.

Команды с высоким уровнем AI-adoption выполняют на 21% больше задач и мёрджат на 98% больше pull request'ов, однако время ревью PR увеличивается на 91% — по данным более 10 000 разработчиков из 1 255 команд.

Two things are scaling exponentially: the number of changes and the size of changes. We cannot consume this much code. Period. On top of that, developers keep saying that reviewing AI-generated code requires more effort than reviewing code written by their colleagues. Teams produce more code, then spend more time reviewing it.

Экспоненциально растут две вещи: количество изменений и размер изменений. Мы не можем потреблять столько кода. Точка. Вдобавок разработчики постоянно говорят, что ревьюить код, сгенерированный ИИ, труднее, чем код коллег. Команды производят больше кода — и тратят больше времени на его проверку.

There is no way we win this fight with manual code reviews. Code review is a historical approval gate that no longer matches the shape of the work.

Ручным код-ревью эту битву не выиграть. Код-ревью — исторический шлюз одобрения, который больше не соответствует характеру работы.

AI code review is still review

AI-ревью кода — это всё ещё ревью

AI code review tools are just buying us time. If AI writes the code and AI reviews it, why do we need a pretty review UI to display that? As much as AI code reviews can be valuable, these will shift left in the dev cycle. There’s no reason to waste CI resources and manage versioning in between the review cycles.

Инструменты AI-ревью лишь покупают нам время. Если ИИ пишет код и ИИ его ревьюит, зачем нам красивый интерфейс ревью, чтобы это отображать? Как бы ни были полезны AI-ревью, они сместятся левее в цикле разработки. Нет смысла тратить ресурсы CI и управлять версиями между циклами ревью.

Post-PR review made sense when humans wrote code and needed fresh eyes. When agents write code, “fresh eyes” is just another agent with the same blind spots. The value is in the iteration loop here, not as an approval gate.

Пост-PR ревью имело смысл, когда люди писали код и нуждались в свежем взгляде. Когда код пишут агенты, «свежий взгляд» — это просто другой агент с теми же слепыми зонами. Ценность здесь — в итерационном цикле, а не в шлюзе одобрения.

We know from experience agents are not always reliable, and it’s very human to think, I caught the AI doing something dumb once; therefore, I must always check it. That instinct made sense when manual verification was feasible. At the current scale, it’s not anymore. And it’s just going to get worse.

Мы знаем из опыта, что агенты не всегда надёжны, и вполне по-человечески думать: «Я однажды поймал ИИ на глупости, значит, надо всегда проверять». Этот инстинкт имел смысл, когда ручная проверка была осуществима. При нынешних масштабах это уже не так. И дальше будет только хуже.

From reviewing Code to reviewing Intent

От ревью кода — к ревью намерения

The answer is to move the human checkpoint upstream. If the thought of not reviewing code seems scary, let me remind you that checkpoints have moved before in software development. We moved from waterfall sign-offs to continuous integration. We can move them again.

Ответ — переместить человеческий контрольный пункт вверх по потоку. Если мысль о том, чтобы не ревьюить код, кажется пугающей, напомню: контрольные точки в разработке уже перемещались. Мы перешли от водопадных приёмок к непрерывной интеграции. Можем сдвинуть их снова.

Spec-driven development is becoming the main way of working with AI. Humans should review specs, plans, constraints, and acceptance criteria—not 500-line diffs.

Разработка на основе спецификаций становится основным способом работы с ИИ. Люди должны ревьюить спецификации, планы, ограничения и критерии приёмки — а не диффы на 500 строк.

In this new paradigm, Specs become the source of truth. Code becomes an artifact of the spec. You don’t need to review the code. You review the steps. You review the verification rules. You review the contract the code must fulfill.

В этой новой парадигме спецификации становятся источником истины. Код превращается в артефакт спецификации. Вам не нужно ревьюить код. Вы ревьюите шаги. Вы ревьюите правила верификации. Вы ревьюите контракт, которому код должен соответствовать.

Human-in-the-loop approval moves from “Did you write this correctly?” to “Are we solving the right problem with the right constraints?” The most valuable human judgment is exercised before the first line of code is generated, not after.

Одобрение с участием человека смещается от «Ты правильно это написал?» к «Мы решаем правильную задачу с правильными ограничениями?». Самое ценное человеческое суждение применяется до того, как будет сгенерирована первая строка кода, а не после.

Building trust through layers

Выстраивание доверия через слои

How comfortable do we need to get before we stop reading the code?

Насколько комфортно нам нужно себя чувствовать, прежде чем мы перестанем читать код?

In rule form:

Code must not be written by humans

Code must not be reviewed by humans

В форме правил:Код не должен писаться людьмиКод не должен ревьюиться людьми

LLMs are not great at following commands. They deviate. Frequently. And they’re unreliable at self-verification—they’ll confidently tell you the code works while it’s on fire. The fix isn’t to ask the LLM to verify. It’s to ask it to write a script that verifies. Shift from judgment to artifact.

LLM плохо следуют инструкциям. Они отклоняются. Часто. И ненадёжны в самопроверке — уверенно скажут, что код работает, пока он горит. Решение не в том, чтобы просить LLM проверить. А в том, чтобы попросить её написать скрипт, который проверит. Переход от суждения к артефакту.

Trust is layered. This is the Swiss-cheese model: no single gate catches everything. You stack imperfect filters until the holes don’t align. So, where else can we put approval gates?

Доверие строится слоями. Это модель швейцарского сыра: ни один барьер не ловит всё. Вы ставите несовершенные фильтры друг за другом, пока дыры не перестанут совпадать. Так где ещё можно поставить шлюзы одобрения?

Layer 1: Compare Multiple Options

Слой 1: Сравнение нескольких вариантов

Instead of asking one agent to get it right, ask three agents to try differently and pick the best outcome. Let them compete. The cost of optionality is the lowest in the history of software engineering.

Вместо того чтобы просить одного агента сделать правильно, попросите трёх агентов попробовать по-разному и выберите лучший результат. Пусть соревнуются. Стоимость вариативности — самая низкая в истории программной инженерии.

The selection doesn’t have to be manual either. You can rank outputs by which one passes the most verification steps, which one produces the smallest diff, which one doesn’t introduce new dependencies. Competition creates a signal you wouldn’t get from a single attempt.

Отбор не обязан быть ручным. Можно ранжировать варианты по тому, какой проходит больше верификационных шагов, какой даёт минимальный дифф, какой не добавляет новых зависимостей. Конкуренция создаёт сигнал, который не получить от единственной попытки.

Layer 2: Deterministic Guardrails

Слой 2: Детерминированные ограждения

There should be a deterministic way to verify the work. Tests, type checks, contract verification - things that don’t have opinions, just facts.

Должен быть детерминированный способ верифицировать работу. Тесты, проверка типов, верификация контрактов — вещи, у которых нет мнений, только факты.

Instead of asking an LLM “Did this work?” you define verification steps that produce a series of pass/fail artifacts. The agent can’t negotiate with a failing test. It either meets the specification or it doesn’t.

Вместо того чтобы спрашивать LLM «Это сработало?», вы определяете шаги верификации, которые выдают серию артефактов «пройдено/не пройдено». Агент не может договориться с падающим тестом. Он либо соответствует спецификации, либо нет.

These guardrails can be defined as layers themselves:

Эти ограждения можно определять как отдельные слои:

Стандарты кодирования — это могут быть кастомные линтерыИнварианты на уровне организации — безусловные требования, например: никаких захардкоженных учётных данных, API-ключей или токеновДоменные контракты — специфичны для фреймворка, сервиса или части кодовой базы, например: домен платежей — все суммы используют тип MoneyКритерии приёмки — специфичны для конкретной задачи

Verification steps should be defined before the code is written, not invented after to confirm what’s already there. If the agent writes both the code and the tests, you’ve just moved the problem—now you’re trusting the agent to test the right things. Verification criteria need to come from the spec, not from the implementation.

Шаги верификации должны определяться до написания кода, а не придумываться задним числом для подтверждения того, что уже есть. Если агент пишет и код, и тесты, вы просто переместили проблему — теперь вы доверяете агенту тестировать правильные вещи. Критерии верификации должны исходить из спецификации, а не из реализации.

Layer 3: Humans define acceptance criteria

Слой 3: Люди определяют критерии приёмки

So where do humans add value? Upstream, defining what success looks like.

Так где же люди приносят пользу? Выше по потоку — определяя, как выглядит успех.

This is where Behavior-Driven Development becomes newly relevant. BDD was always a good idea—write specifications in natural language that describe expected behavior, then automate those specs as tests. But it never fully caught on because writing specs felt like extra work when you were also going to write the code.

Именно здесь Behavior-Driven Development обретает новую актуальность. BDD всегда была хорошей идеей — писать спецификации на естественном языке, описывающие ожидаемое поведение, а затем автоматизировать эти спецификации как тесты. Но подход так и не прижился полностью, потому что написание спецификаций казалось лишней работой, когда ты и так собираешься писать код.

With agents, the equation flips. The spec isn’t extra work; it’s the primary artifact. You write:

С агентами уравнение переворачивается. Спецификация — не дополнительная работа, а главный артефакт. Вы пишете:

The agent implements. The BDD framework verifies. You never have to read the implementation unless something fails.

Агент реализует. BDD-фреймворк верифицирует. Вам не нужно читать реализацию, пока что-то не сломается.

This is humans doing what humans are good at: defining what “correct” means, encoding business logic and edge cases, thinking about what could go wrong. The agent handles the translation from intent to code. The BDD specs become your verification layer—deterministic, automated, and defined before the first line is written.

Это люди, делающие то, в чём люди хороши: определяют, что значит «правильно», кодируют бизнес-логику и крайние случаи, думают о том, что может пойти не так. Агент берёт на себя перевод намерения в код. BDD-спецификации становятся вашим слоем верификации — детерминированным, автоматизированным и определённым до написания первой строки.

Acceptance criteria authored by humans, verified by machines. That’s the gate that actually matters.

Критерии приёмки, написанные людьми и проверенные машинами. Вот шлюз, который действительно имеет значение.

Layer 4: Permission Systems as Architecture

Слой 4: Системы разрешений как архитектура

What can this agent touch? What requires escalation? These become architectural decisions, not afterthoughts.

Что может трогать этот агент? Что требует эскалации? Это становится архитектурным решением, а не запоздалой мыслью.

Most agent frameworks treat permissions as an all-or-nothing setting. The agent either has shell access or it doesn’t. But granularity matters. An agent fixing a bug in a utility function doesn’t need access to your infrastructure configs. An agent writing tests doesn’t need to modify CI pipelines.

Большинство агентных фреймворков трактуют разрешения как «всё или ничего». У агента либо есть доступ к шеллу, либо нет. Но гранулярность важна. Агенту, исправляющему баг в утилитной функции, не нужен доступ к конфигам инфраструктуры. Агенту, пишущему тесты, не нужна возможность менять CI-пайплайны.

Scope should be as narrow as possible while still letting the agent do useful work. If the task is “fix the date parsing bug in utils/dates.py,” the agent’s filesystem access should be limited to that file and its test file. Not the whole codebase. Not “src/ and tests/”. Just the files that matter for this task.

Область доступа должна быть как можно уже, но достаточной для полезной работы. Если задача — «исправить баг парсинга дат в utils/dates.py», доступ агента к файловой системе должен быть ограничен этим файлом и его тестовым файлом. Не всей кодовой базой. Не «src/ и tests/». Только файлами, относящимися к задаче.

Escalation triggers are equally important. Certain patterns—touching auth logic, modifying database schemas, adding new dependencies—should automatically flag for human review regardless of how confident the agent is.

Триггеры эскалации не менее важны. Определённые паттерны — затрагивание логики авторизации, изменение схемы базы данных, добавление новых зависимостей — должны автоматически отправляться на ревью человеку, вне зависимости от уверенности агента.

Layer 5: Adversarial Verification

Слой 5: Состязательная верификация

Separation of responsibilities: One agent does the work, another verifies. They don’t trust each other, and that’s the point.

Разделение обязанностей: один агент выполняет работу, другой верифицирует. Они не доверяют друг другу, и в этом суть.

This is an old pattern—it’s why your QA team shouldn’t report to your engineering manager, and why the person who writes the code shouldn’t be the only one who reviews it.

Это старый паттерн — именно поэтому ваша команда QA не должна подчиняться вашему инженерному менеджеру, а человек, написавший код, не должен быть единственным, кто его ревьюит.

With agents, you can enforce this architecturally. The coding agent has no knowledge of what the verification agent will check. The verification agent has no ability to modify the code to make its own job easier. They’re adversarial by design.

С агентами это можно обеспечить архитектурно. Кодирующий агент не знает, что будет проверять верифицирующий агент. Верифицирующий агент не может изменить код, чтобы облегчить себе работу. Они состязательны по замыслу.

You can take this further: a third agent attempts to break what the first agent built, specifically targeting edge cases and failure modes. Red team, blue team—but automated and running on every change.

Можно пойти дальше: третий агент пытается сломать то, что построил первый, целенаправленно атакуя краевые случаи и режимы отказа. Red team, blue team — но автоматизированные и запускаемые при каждом изменении.

Conclusions: What “good code” looks like is changing

Выводы: Понятие «хороший код» меняется

The incentive of an agentic system is simple: given a task, can I complete it? Can I please the person who gave it to me? The agent’s success is never inherently driven by long-term accuracy or business requirements.

Стимул агентной системы прост: дали задачу — могу ли я её выполнить? Могу ли угодить тому, кто её поставил? Успех агента по своей природе никогда не обусловлен долгосрочной точностью или бизнес-требованиями.

It’s our job to encode in the constraints.

Наша задача — закодировать это в ограничениях.

For code generated by agents and read by agents, what “good code” looks like will become more standardized. For a new codebase, you’ll have to provide less direction because the defaults will be more consistent.

Для кода, сгенерированного агентами и читаемого агентами, понятие «хороший код» станет более стандартизированным. Для новой кодовой базы придётся давать меньше указаний, потому что значения по умолчанию будут более единообразными.

The future is ship fast, observe everything, revert faster.

Будущее — быстро поставлять, наблюдать за всем, откатывать ещё быстрее.

Not: review slowly, miss bugs anyway, debug in production.

А не: медленно ревьюить, всё равно пропускать баги, дебажить в проде.

We’re not going to outread the machines. We need to outthink them—upstream, where the decisions actually matter.

Ultimately, if agents can handle the code just fine, what does it matter if we can read it or not?

Мы не сможем перечитать машины. Нам нужно передумать их — выше по потоку, там, где решения действительно имеют значение. В конечном счёте, если агенты справляются с кодом, какая разница, можем мы его прочитать или нет?

Ankit Jain is the founder and CEO of Aviator, where he’s building the infrastructure for AI-native engineering teams. Aviator’s platform helps modern organizations improve AI adoption while maintaining high engineering standards.

Ankit Jain — основатель и CEO Aviator, где он строит инфраструктуру для AI-нативных инженерных команд. Платформа Aviator помогает современным организациям повышать уровень AI-adoption, сохраняя высокие инженерные стандарты.