Человеческое ревью не поспевает за агентами: кода стало больше, чем можно прочитать. Addy Osmani разбирает, как качество переезжает в ограничения — тесты, гейты и среду, где падение стоит дёшево.
✍️ Addy Osmani📅 12 августа 2026⏱ ~11 мин🌐 x.com · X Article👁 405 тыс. просмотров
Главный тезис
Качество кода теперь держится не на том, кто его прочитал, а на ограничениях, которые вы поставили вокруг агента: что система вообще пропустит дальше.
«Software quality now depends on the constraints you set around your agents.»
Агенты выдают сотни тысяч изменений в день. Проверки уезжают в harness, окружение и операционную систему вокруг агента. Османи по-прежнему читает код, но выбирает участки, где готов положиться на ограничения.
🚦Гейты решают, что доедет
Агент предлагает что угодно. Ограничения отвечают за четыре вопроса: изменение достаточно безопасное, корректное, в рамках скоупа и полезное — команде хватит этого, чтобы отгрузить.
⚖️Важна строгость, а не число
Качество распадается на шесть сигналов, от корректности до понятности. Считать надо не количество проверок, а то, дотягивают ли они до вашей планки готовности к продакшену.
Большую часть истории качество кода проверял человек: кто-то читал написанное и решал, чистое ли оно, продуманное, быстрое, понятное, покрытое тестами. С агентами этот способ упирается в объём — читать столько кода некому. Поэтому всё больше проверок переезжает в harness, окружение и операционную систему вокруг агента.
поток широкий, человеческое внимание — узкое
🧭Что меняется на практике
Раньше проверка была событием: пришёл дифф — кто-то прочитал. Теперь это свойство системы, в которой агент работает: среда сама сообщает, что предложение не годится, и делает это до того, как правку кто-то увидит.
Османи не отказывается от чтения кода. Он выбирает, где именно ограничение заменяет чтение, и относится к этому выбору как к инженерному решению.
🏭Масштаб задачи
Цикл должен надёжно выдавать продакшен-код даже тогда, когда агенты создают сотни тысяч или миллионы изменений каждый день. При таком потоке ручная проверка каждого изменения перестаёт быть вариантом.
Ограничения задают, что системе позволено делать: предложения агента встречают тесты и детерминированные проверки. Османи называет их quality gates и перечисляет формы, в которых они встречаются. Смысл не в том, чтобы навалить проверок побольше: набор должен быть широким, но выбранным осознанно, у каждой проверки — своя зона ответственности.
🧪 Тесты
Обычные unit-тесты, property-тесты и acceptance-тесты — база, на которую опираются остальные проверки.
🧬 Мутационное тестирование
Генерируем варианты кода, гоняем на тех же тестах и смотрим, не протаскивают ли мимо баги, которых тесты не видят.
📏 Метрики кода
Цикломатическая сложность, длина строк и прочее, что удерживает код читаемым.
🔤 Типобезопасность
Отдельный сигнал: компилятор отвергает то, что не сходится по типам, ещё до запуска тестов.
🏛 Архитектурные правила
Свои ограничения, которые команда описывает сама — например, правилами линтера вроде ESLint.
🛡 Security-сканирование
Поздняя стадия проверки: политика безопасности блокирует небезопасные практики.
⚡ Производительность
Ещё одно измерение, ради которого стоит держать отдельную проверку, а не надеяться на тесты корректности.
🪝 Хуки
У многих инструментов есть встроенные хуки: когда что-то ломается, они подтягивают агента или человека.
Вывод: не полагайтесь на одни unit-тесты. Разные проверки ловят разные классы ошибок, и широкий набор сигналов даёт больше, чем углубление в один.
Ограничения решают и другую задачу: какие предложения система вообще примет как изменение кода. Пока правка идёт от интерпретатора, где крутится агент, к контроллеру агента и дальше в продакшен, на ней накапливается достаточно проверок, чтобы поверить: отгружать безопасно, а эффект изменения не выходит за рамки полномочий агента.
каждая стрелка вперёд оплачена пройденной проверкой
«An agent can propose anything. Your constraints decide whether a proposal is safe enough, correct, scoped, and useful, for you and your team to ship.»
Агент может предложить что угодно. Ограничения решают, достаточно ли предложение безопасно, корректно, в рамках скоупа и полезно, чтобы вы и команда его отгрузили.
Модель ограничений даёт много, но кое-что оставляет за скобками. Первая дыра — автономия: агент неплохо реализует намерение и спотыкается там, где не хватает информации или задача двусмысленна. Это касается и самой задачи, и того, как её параметризуют harness с окружением. Вторая — доверие: передавать намерение даже умному агенту без проверки корректности нельзя, доверие приходится заслуживать.
почему падают агенты — и люди тоже
🧱Хрупкое окружение
Среда не выдерживает, когда по ней идёт скриптовая нагрузка.
🎲Недетерминированные сборки
Один и тот же вход даёт разный результат — доверять сигналу невозможно.
🔒Нехватка прав
Работа обрывается там, где не выданы нужные доступы.
🕳Слабые тесты
Проверка проходит, но ничего не гарантирует: сигнал есть, ценности в нём нет.
три свойства, ради которых стоит чинить окружение
«The environment we’re after is one where an agent can do real work, get feedback it can trust, and fail without doing much damage.»
Нужна среда, где агент делает настоящую работу, получает обратную связь, которой можно верить, и падает без большого ущерба.
Османи раскладывает проверки по времени: одни задают форму работы до её начала, другие дают обратную связь по ходу, третьи решают, пересечёт ли результат границу продакшена. Разложить свои гейты по этим трём точкам — быстрый способ увидеть, где у вас пусто.
одно и то же правило стоит по-разному в начале и в конце
Противодавление собирается из обычных инструментов: компилятор отвергает невалидный код, тесты падают, политика безопасности блокирует плохие практики, CI отказывается деплоить. Османи настаивает, что оно должно жить по всему циклу, а не сводиться к одной проверке в самом конце. Ждать финального «CI не пустит» — значит узнавать о проблеме позже всех, кто мог бы её поймать.
четыре источника «нет» из статьи
⏱Раньше — дешевле
Сигналы стоит использовать так рано, как только возможно, и всеми доступными путями. Проверка на выходе из пайплайна сообщает то же самое, но после того, как работа уже сделана.
🔁Цикл, а не финальный экзамен
Ограничения и противодавление позволяют агентам ловить плохую работу до того, как она станет проблемой. Это свойство всего цикла доставки, а не одной стадии.
🧰Чем усилить
Противодавление наращивают двумя способами: внедрить новые инструменты или усилить те, что уже стоят. Оба способа помогают отбивать большинство входящих изменений.
Что будет, если изменений больше, чем инструменты способны переварить? Появляется очередь, и скорость всей доставки задаёт система проверки, работающая в человеческом темпе. Османи разбирает три рычага и добавляет четвёртый ход, о котором обычно забывают.
Рычаг
Что делаем
Чем платим
Масштабировать проверку
Наращиваем ёмкость верификации: больше проверок и больше пропускной способности, чтобы отбивать входящие изменения.
качество сохраняется
Притормозить агентов
Снижаем темп генерации изменений, чтобы проверка догнала объём работы.
падает скорость доставки
Опустить планку
Делаем проверку менее требовательной, чтобы она пропускала больше.
качество уходит вниз осознанно
Снять ограничения точечно
Где-то ослабляем — рои агентов-разработчиков, автоматические software factories работают без ревью каждого изменения, — а строгость держим там, где цена ошибки выше.
пропускная способность растёт без потери там, где важно
трейд-офф решается явно, иначе решится сам
📥Очередь — это симптом
Как только проверка перестаёт успевать, у неё вырастает очередь, и темп всей системы сваливается к человеческой скорости. Смысл — переносить как можно больше проверок внутрь цикла, а не копить их к финалу.
🎚Где ужесточать
Сильные ограничения ставят там, где они служат обеим целям сразу: держат качество и не душат поток. Там, где проверка не делает ни того, ни другого, её стоит ослабить или снять. Планку качества нужно быть готовым двигать в обе стороны.
ИИ даёт объём и скорость генерации кода, и та же скорость мешает человеку просматривать каждое изменение. Если поставить человеческую проверку посреди системы, которая движется на машинной скорости, продуктивность просядет — и удивляться нечему. Значит, внимание нужно направлять осознанно: людей подключают там, где сломались автоматические guardrails, и там, где решение требует человеческого суждения.
🎯Куда направить внимание
К самым тонким задачам, где нужна оценка человека: замысел, архитектура, вкус. Всё остальное отдают автоматике.
🚨Когда звать человека
Когда ломаются автоматические ограждения. Пока гейты держат, вызывать людей вниз по потоку незачем.
📡Что шлёт система
Ясную обратную связь от среды агентам и командам, чтобы люди оставались внутри безопасного коридора и не разбирались задним числом, где всё пошло не так.
«Human “code review” in the future is going to look very different»
Человеческое ревью кода в будущем будет выглядеть совсем иначе.
— подпись к мысли о распределении внимания
в статье ↗
«Human attention is scarce and valuable so we should proactively direct it to those most nuanced problems that require our judgment.»
Человеческое внимание дефицитно и ценно, поэтому направлять его стоит заранее — к самым тонким задачам, где нужно наше суждение.
Корректность — только одно измерение. Рядом стоят поддерживаемость, производительность, безопасность, эффективность и понятность. Как корректность распадается на разные типы сигналов, так распадается и всё остальное качество. И важнее не то, сколько у вас ограничений, а то, достаточно ли они требовательны для вашей планки и готовности к продакшену.
важность каждого сигнала команда расставляет сама
🦷Что даёт качеству зубы
Ограничения, расставленные в разных точках системы, — это и есть механизм, которым качество становится обязательным, а не пожеланием.
🧑⚖️Последнее ограничение
Оно самое неудобное: готовность отвечать за то, что вы построили и как это эксплуатируете. Здесь тоже нужен осознанный размен — насколько собственное суждение сдерживает систему и работает финальной проверкой.
📝Что делать с этим
Османи заканчивает прямым предложением: возьмите эту постановку задачи и составьте свой план на ограничениях для собственных приложений.
Статья идёт сплошным текстом без подзаголовков, поэтому вот её маршрут: от провала ручного ревью к личной ответственности за выстроенную систему. Любой пункт открывает оригинал.
Под постом 36 ответов. Два из них добавляют к тезису статьи то, чего в ней нет: где именно проходит инженерная работа и почему одними ограничениями проблему не закрыть.
WWHALER · @Whaler526151 · 3 лайка
Противодавление выпало из большинства разговоров об агентной разработке, а настоящая инженерия — в умении понять, когда остановиться, отклонить или эскалировать.
«knowing when to stop, reject, or escalate is where the real engineering lives»
Приносит в тред тезисы доклада @dexhorthy: расчёт на «модели уже достаточно хороши, код бесплатен, нужно больше токенов, циклов и лучше harness» — неверен. Провалы идут не от нехватки навыка или масштаба, а от того, как обучают кодовые модели: под долгосрочную поддерживаемость кодовой базы их не оптимизируют.
«No amount of harness engineering or adversarial review bots fully solves this.»
Второй ответ спорит с рамкой статьи: если модель не обучена держать поддерживаемость, никакие ограждения вокруг неё этого не починят. Османи в тексте признаёт смежное: разница между полезной работой агента и слопом пока определяется навыком команды.
момента, где работают ограничения: до старта, по ходу, на границе продакшена
3
рычага, когда верификация не успевает: масштабировать, притормозить, опустить планку
405 тыс.
просмотров у поста, 1 026 лайков и 1 996 закладок
✅
Как применить
Османи заканчивает предложением составить собственный план на ограничениях. Вот из чего его собрать — по шагам, которые видно из текста. Отмечайте кликом, что уже сделано.
Инвентаризация гейтов: выпишите все проверки пайплайна и напротив каждой — какой класс ошибок она реально ловит. Пустые строки против «безопасность», «производительность», «архитектура» и есть ваши дыры.
Проверьте тесты на прочность: прогоните мутационное тестирование на одном критичном модуле. Если подсунутые баги проходят мимо, зелёный прогон ничего не значит — ни для человека, ни для агента.
Почините окружение: детерминированная сборка, выданные заранее права, изоляция и быстрый откат. Цель — чтобы падение агента стоило дёшево, а обратной связи можно было верить.
Разложите проверки по трём точкам: что задаёт форму задачи до старта, что подсказывает агенту по ходу, что решает на границе продакшена. Самый частый перекос — всё свалено в конец, в CI.
Опишите архитектурные правила как код: то, что вы обычно проговариваете на ревью, вынесите в правила линтера и хуки, которые зовут агента или человека при срабатывании.
Найдите очередь: посмотрите, где изменения ждут проверки. Дальше выберите рычаг явно — нарастить ёмкость проверок, притормозить генерацию или опустить планку, — вместо того чтобы получить выбор стихийно.
Разнесите строгость по зонам: максимальные требования там, где цена ошибки высока; там, где она мала, ограничения можно ослабить и пустить агентов работать без ревью каждого изменения.
Пропишите правило вызова человека: людей подключают, когда ограждение сломалось или нужно суждение об архитектуре и замысле. Всё остальное — работа автоматики.
Зафиксируйте планку по шести измерениям: что для вашей команды означает «готово к продакшену» по корректности, поддерживаемости, производительности, безопасности, эффективности и понятности.
Назначьте владельца планки: кто-то должен отвечать за то, что построено и как оно эксплуатируется, и иметь право двигать требования вверх или вниз с объяснением причины.
Ответ @Whaler526151 ↗про то, где живёт настоящая инженерия: остановить, отклонить, эскалировать
Ответ @xSamvidx ↗тезисы доклада @dexhorthy: модели не учат держать поддерживаемость
ESLintпример инструмента, которым в статье предлагают описывать архитектурные правила
Sonarспонсор статьи: кросс-файловый анализ на каждый коммит, карта риска и единый quality gate для людей и агентов
Pangram 4оценил текст как «100% human written» — примечание в конце статьи
// понятия из статьи
quality gatesback-pressuremutation testingproperty testsacceptance testscyclomatic complexityharnessagent controllerguardrailssoftware factoriesslopочередь на верификации
harness — обвязка вокруг модели: то, как ставится задача, какие инструменты доступны агенту и как читается результат.
back-pressure — противодавление: любой механизм, который отвечает «нет» на изменение и возвращает его автору.
slop — поток низкокачественного сгенерированного кода, который проходит формальные проверки, но не решает задачу.
Про иллюстрации: в конспекте только обложка статьи, остальные схемы нарисованы для него. Внутренние иллюстрации X Article закрыты для неавторизованного доступа, поэтому подтянуть их не вышло; вместо копирования картинок содержание изложено текстом и собственными диаграммами.
