---
slug: trust-doesnt-live-in-the-code-review
assetPath: /resources/blog/trust-doesnt-live-in-the-code-review
title: Доверие живёт не в код-ревью
description: Почему эпоха агентов забирает у вас код-ревью и что вы держите в руках взамен.
metaDescription: Можно ли доверять коду, который вы больше не читаете построчно? Почему в эпоху агентов доверие уходит из код-ревью и что остаётся у вас.
categoryKey: engineering
tagKeys: engineering
publishedLabel: 30 июня 2026 г.
author: Tenny
editors: Alice, Megan & Cindy
heroImage: /resources/blog/trust-doesnt-live-in-the-code-review/trust-code-review-entropy-cover-5x2.png
heroEmbed: /resources/blog/trust-doesnt-live-in-the-code-review/trust-code-review-entropy-cover-animated.html
socialImage: /resources/blog/trust-doesnt-live-in-the-code-review/trust-code-review-social-1200x630.png
heroAlt: Цикл метода не поспевает за скоростью, и сигналы системы оборачиваются архитектурным сбоем
canonicalUrl: https://raft.build/ru/resources/blog/trust-doesnt-live-in-the-code-review/
datePublished: 2026-06-30
dateModified: 2026-06-30
---

> Источник: официальный блог Raft · https://raft.build/ru/resources/blog/trust-doesnt-live-in-the-code-review/

## Вы стали шлагбаумом

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

И выбор у вас из двух плохих вариантов. Держать оборону и читать каждую строку — и вы становитесь узким местом, перед которым в очередь выстраивается вся команда. Пропускать не глядя — и ревью превращается в печать. Большинство команд тихо выбрало печать. Хуже всего не пропущенные баги: пропущенный баг можно исправить. Ложную уверенность исправить нельзя, а её штампуют строго по графику. Печать по-прежнему даёт ощущение доверия, и вы выпускаете релизы, опираясь на это ощущение. Дело не в том, что у вас не получается построить доверие. Вы строите подделку.

Но отступите на шаг: дело никогда не было в шлагбауме. Вам нужно не чтение. Вам нужны контроль над проектом и обоснованное доверие к нему — та устойчивая уверенность, при которой вы знаете, что выпускаете. Чтение диффа всегда было лишь заменителем, который приняли за саму суть. **На аутсорс нельзя отдать контроль и доверие. Они остаются за вами.** А чтение можно поручить тому, кто справится с ним лучше всех, — человеку или нет.

## Не можете писать — не сможете и читать

Начнём с того, почему ваше чтение вообще чего-то стоило. И дело было не во внимательности. Ревью бывает ровно настолько хорошим, насколько хорош разработчик, который его проводит, а хорошим разработчика делает одно: он достаточно часто сам копается в коде, чтобы держать его детали в живой памяти. Это живое понимание — двигатель ревью; чтение лишь то место, где оно проявляется. Уберите его, и чтение превращается в пустое движение: глаза скользят по строкам.

Эпоха агентов выдёргивает вас из роли такого разработчика. Причина одна, но проявляется она двояко: вы и агент платите за код по-разному. **Модель затрат другая, и из этого следует всё остальное.**

Здесь и сейчас этот разрыв выглядит как скорость. Агент итерирует почти с нулевыми предельными издержками; человек, который пишет руками среди агентов, становится медленной полосой, в которой застревает работа. Честнее всего остановиться и дать агентам работать. Но как только вы это делаете, ваше живое понимание начинает выцветать: вы его больше не строите.

На уровне кодовой базы тот же разрыв выглядит как согласованность, и это верно даже для человека, достаточно быстрого, чтобы не отставать. Кодовая база — кристаллизация тысячи мелких решений, принятых в рамках одной модели затрат: стоит ли дублирование рефакторинга, какой объём логов оправдывает шум, где на самом деле проходит граница. Агенты выдерживают эту строгость ровно, без усталости и скуки, из-за которых утомлённый человек урезает логи или откладывает рефакторинг. Человек, который лезет в код руками, пишет не хуже — просто его код оптимизирован под другую модель затрат. Добавьте такой код в систему, настроенную под иную модель, и он разорвёт ту согласованность, благодаря которой система оставалась понятной. Верхний уровень остаётся за вами: для чего система, куда она может двигаться, какие риски стоит предвидеть, на какие компромиссы стоит идти. А почерк реализации под этим уровнем определяет тот, кто платит за код.

Скажем прямо — с оговоркой, что речь о конкретном режиме, к которому мы движемся, а не о том, что уже действует везде. Как только проект стал agent-native — агенты в этой области как минимум не слабее вас, а кодовая база уже написана их почерком, — человек больше не может по-настоящему писать этот код: ни по темпу, ни по почерку. А человек, который не может писать код, не может и держать его в живой памяти настолько, чтобы делать ревью. Это не закон природы, но внутри этого режима вывод твёрдый: если продолжать ревью, вы просто водите глазами по строкам, судить о которых у вас больше нет права. Поэтому же, когда агенты не ускорили ваш проект, узким местом почти всегда оказывается тот единственный человек, который всё ещё сам пишет и читает код. Не доверие и не чувство направления — они остаются. **Узкое место — рука, которая всё ещё лежит на клавиатуре.**

Ничего нового тут нет; эпоха агентов лишь сделала так, что от этого больше не отмахнёшься. Доверие никогда не жило в код-ревью — ни сейчас, ни раньше. Тот, кто ведёт большой проект, код не читает: когда самый опытный инженер из ваших знакомых в последний раз построчно читал систему, за которую отвечает? Он ведёт её, опираясь на доверие к людям уровнем ниже и на понимание архитектуры в общих чертах, и никто не называет это безответственностью. Построчное чтение могли себе позволить нижние уровни, и то, что это было им по карману, приняли за доверие. Эпоха агентов просто выдвигает каждый уровень туда, где всегда находился верхний.

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

## Быстрее код — быстрее гниль

Пока система стареет под потоком изменений, растёт число программ, которые могли бы сойти за вашу. В молодой, компактной системе все выжившие — почти одна и та же программа. Дайте ей стареть без присмотра, и семейство расползается: та же спецификация, те же зелёные проверки — и огромное пространство взаимно противоречивых реализаций, каждая из которых их проходит. Это расползание — разновидность энтропии, и слово здесь точное именно из-за направления: если ничего не делать, она только растёт. Каждая чёткая граница и каждый честный тест её урезают; каждый срезанный угол и каждый продублированный источник истины дают ей отрасти снова.

И это тоже не ново. Леман сформулировал это ещё в 1970-х: программа, которой пользуются, от релиза к релизу набирает сложность, если только кто-то не вкладывает реальный труд в то, чтобы её сдерживать. Гниение софта, деградация кода — у отрасли есть для этого слова с тех самых пор, как она поставляет программы. Новое — не само явление. **Новое — температура.** Работающий продукт можно поднять за час — и за день довести до состояния, когда его уже не поддержать: скорость в обе стороны одна и та же. Агенты не изобрели энтропию; они просто подняли температуру, убрав то, что раньше сдерживало темп: то, насколько быстро человек может писать и читать код.

![Method keeping pace until agent speed compresses the system lifecycle](/resources/blog/trust-doesnt-live-in-the-code-review/trust-code-review-entropy-cover-5x2.png)

*Когда скорость обгоняет метод, за зелёными сигналами может скрываться система, чьи формы множатся.*

Растущую энтропию вы ощущаете как одну потерю: вы больше не можете предсказать собственную систему. Не можете сказать, прежде чем поменять что-то здесь, что из этого выйдет вон там. **Доверие к системе всегда было только этим — способностью её предсказывать.** Не чувство и не зелёная галочка, а заработанная уверенность в том, что вы знаете, как эта штука себя поведёт. Дифф эту уверенность не вернёт: дифф показывает одно изменение, а предсказание — свойство целого. Поэтому вопрос не в том, корректен ли конкретный дифф. Вопрос в том, растёт энтропия целого или удерживается. Это можно прочитать, и для этого вообще не нужны диффы.

## Перестаньте читать диффы

Так как же читать энтропию, не открывая каждый дифф? **Дифф показывает вам изменение; систему он не покажет никогда.** Вы перестаёте читать дифф и начинаете читать систему. Наборы тестов и дашборды были источником доверия, а сигналы ниже — то, как вы читаете систему теперь: вживую, пока она работает.

Ревью читает артефакт: изменение перед вами, строку за строкой. Но то, что вы хотите знать, не принадлежит ни одному отдельному изменению. Это свойство всей системы, а вся система и так постоянно рассказывает о себе, без того чтобы кто-то открывал файл. Она испускает сигналы; вместо кода вы читаете их. Вот почему этот способ работает там, где ревью не справлялось: ревью целилось в артефакт, а того, что вам нужно было знать, в артефакте не было никогда.

Самый прямой сигнал — список багов, потому что это не прогноз, а запись того, где система уже ошиблась. Баги скапливаются, и эти скопления — карта. Один и тот же модуль всплывает неделю за неделей, один и тот же контракт каждый месяц обрастает новым пограничным случаем — потому что именно там система протекает. Сбои агентов читаются особенно хорошо: ошибка агента обычно указывает на нечистые входные данные — размытый контракт, спецификацию, в которой какой-то случай остался непроговорённым. Человек по привычке компенсирует и тем самым прячет дыру; агент в неё наступает и отмечает место.

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

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

Но зелёный тест — ещё не бесплатное качество, и именно здесь большинство наборов тестов вам лжёт. Тест честно зарабатывает свой зелёный, только если его проверка жёсткая. Он должен проверять реальное поведение на реальных данных, чтобы настоящая регрессия окрашивала его в красный. И он должен покрывать все пути, которыми идёт это поведение: проверка, которая проходит на одном пути, пока другой вообще не исполняется, — это непротестированный случай, переодетый в пройденный тест. Тест, который проверяет форму кода, а не то, что код делает, — зелёная лампочка, ни к чему не подключённая. То же подозрение распространяется на каждый сигнал. Тихий список багов может означать, что модуль здоров, — а может, что им никто не пользуется или что у него погасла телеметрия. Отсутствие сигнала что-то значит, только если вы убедились, что он бы сработал. Поэтому к каждому инструменту вы применяете ту же планку, от которой чуть не отказались вместе с диффом: доверяете ему, только когда доказали, что он способен упасть. **Качество живёт в том, насколько жёсткие у вас проверки, и никогда — в том, что кто-то прочитал строки.**

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

## Ревью — событие, доверие — состояние

Всё это пришлось увести от диффа по причине более глубокой, чем скорость: у ревью неподходящая форма для того, что вы пытаетесь удержать. **Ревью — это событие. Доверие — это состояние.** Событие происходит один раз, выносит вердикт и исчезает; в системе, которой вы пытаетесь доверять, ничего не накапливается. Состояние — вот что вам на самом деле нужно: та самая устойчивая уверенность, что вы можете предсказать собственную систему. А из событий, после которых ничего не остаётся, состояние не построить. Вот фраза, на которую указывал заголовок: доверие живёт не в код-ревью, потому что событию не вместить состояние. Проведите событие хоть тысячу раз — того, что нужно, у вас всё равно не будет. Сигналы непрерывны, поэтому доверие из них накапливается; печати это не удавалось никогда.

Так что ревью как ваш инструмент доверия уходит. Чтение кода не исчезает: оно переезжает туда, где живёт понимание, а в эпоху агентов это агенты, которые пишут код, а не вы. Это они по локоть в деталях, круг за кругом. Уходите вы — в роли шлагбаума. А случаи с высокими ставками, о которых вспоминают первыми, — граница безопасности, необратимый релиз — как раз те, с которыми усталый человеческий взгляд всегда справлялся хуже всего. Теперь они держатся на вещах понадёжнее: на свойстве, которое система типов не даёт нарушить; на проверке с жёстким ассертом; на поэтапной раскатке под присмотром мониторинга, способного поймать регрессию, которую пропустило бы чтение.

Здесь чтение сигналов перестаёт быть просто наблюдением. Каждый сигнал указывает назад, на причину. Выживший мутант указывает на поведение, которое никто не зафиксировал. Уплывшая граница — на контракт, который перестал означать что-то одно. Скопление в списке багов указывает глубже: этот код написала способная модель, поэтому, если модуль раз за разом порождает баги, вероятнее всего, дело не в том, что модель здесь слаба. Дело в том, что интерфейсы модуля сбивают с толку всё, что с ними работает. Баг — это сигнал от системы: граница проведена неправильно. Поэтому вы рефакторите модуль под защитой только что построенного тестового фреймворка: он удерживает поведение неизменным, так что каждое изменение либо доказуемо сохраняет поведение, либо вытаскивает на свет настоящий баг.

Правильный ход почти никогда не «посмотреть следующий дифф внимательнее». Он в том, чтобы отнестись к сбою как к тому, чем он и является: к диагностическим данным, которые идут на вход цикла. **Сбой — не приговор модели; это карта входных данных, которые вы оставили нечистыми.** Он точно указывает, какое из заданных вами условий ещё не чистое. И стоит так на это посмотреть, как ошибки агента становятся самым ценным, что он производит: каждая — подписанный указатель на дыру, которую иначе вы бы не увидели.

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

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

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

Остаётся один вопрос — тот, к которому шла вся эта статья. Если вы больше не шлагбаум и даже не тот, кто читает код, если ваш день — это чтение системы и подтягивание того, чем она питается, — то в чём, собственно, теперь состоит работа человека? Об этом — следующая статья.

---
## Читайте также
- [DAU никогда не учитывал вторую половину вашей команды: знакомьтесь, DAA](/ru/resources/blog/dau-was-never-counting-half-your-team/post.md): DAU придумали для софта, которым люди управляют клик за кликом. Теперь в рабочих пространствах Raft есть и агенты, которые делают реальную работу, поэтому мы считаем обе стороны команды.
- [Вам не нужен корпоративный мозг](/ru/resources/blog/you-dont-need-a-company-brain/post.md): Компании не нужен один общий мозг. Ей нужно много умов со своими границами, которые видят одну и ту же комнату.

Индекс сайта для агентов (каждая статья — одна строка): /llms.txt