Метод короткого поводка для ИИ-разработки

Грег Слепак из okTurtles в заметке от 2 июля 2026 года описывает метод, к которому он пришёл после года использования ИИ-агентов для работы над критичным к безопасности ПО. Он поддерживает собственный форк кодинг-агента Crush и создал инструменты для ИИ-ревью, которые, по его утверждению, не уступают коммерческим системам. Аудитория текста очерчена чётко: это опытные разработчики, чья квалификация в своей области уже превосходит возможности передовых моделей, и которые хотят получить скорость без потери качества. Он прямо говорит, что начинающим разработчикам, скорее всего, стоит избегать таких инструментов, и ссылается на тезис о том, что ИИ вредит обучению разработке.

Метод

Сначала идёт этап планирования: исследование задачи и разбиение её на отслеживаемые шаги. Здесь метод пересекается со всем, что обычно называют vibe-engineering. Всё, что происходит дальше, кардинально отличается.

Никакого YOLO-режима или флага --dangerously-skip-permissions. Агент никогда не работает в фоновом режиме, пока вы заняты чем-то другим. Вы используете агента, который показывает diff предлагаемого изменения прямо в запросе подтверждения прав, и вы сидите и читаете его. Каждый diff. Заметив, что агент собирается сделать что-то не то, вы отклоняете запрос и вмешиваетесь сами, а не ждёте, пока правка применится, чтобы исправить её потом. Коммиты делаются в конце каждой подзадачи, потому что агенты действительно затирают уже сделанную работу - он утверждает, что своими глазами видел такое за Opus.

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

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

Ревью

В PR, проверенном только человеком или только ИИ, остаётся больше ошибок, чем в том, который проверили оба. Слепак относится к ИИ как к linter'у: тот быстро находит типовые ошибки, тогда как человек отлавливает высокоуровневые и концептуальные проблемы.

Из этого следуют четыре правила. Каждый PR проходит ИИ-ревью. Модели для проверки передаются issue, описание PR, кодовая база и сами изменения; при этом должна использоваться лучшая из доступных моделей. В описании PR добавляется заголовок "AI Disclosure" с перечислением конкретных использованных моделей. Это даёт мейнтейнеру понять, что применялся ИИ, позволяет предложить модель получше, если использовалась слабая, и показывает, что автор изменений не пытается ничего скрыть.

Четвёртое правило он разбирает подробнее. PR, написанный с помощью ИИ, - это на самом деле PR от ИИ с помощью человека. Поэтому человек, отправляющий его, обязан вычитать его построчно, как чужой код, явно одобрить собственный PR и только после этого звать мейнтейнера. Понимание того, что именно вы отправляете, - обязательное условие для отправки, а ревью - способ этого понимания достичь.

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

В контексте остального vault'а

Это один из полюсов спора, по которому в vault'е представлено несколько позиций.

Прямая противоположность - control-the-ideas-not-the-code, где antirez доказывает, что построчное ревью вывода LLM - это в основном пустая трата времени, а часы лучше потратить на проектирование и QA. Весь метод Слепака как раз и состоит в построчном ревью с точностью до каждого запроса прав, ещё до того, как код вообще попадёт в файлы. testing-heavy-no-review-workflow заходит в направлении antirez'а ещё дальше: позиция Дэна Луу (Dan Luu) состоит в том, что плотное рандомизированное тестирование на голову превосходит ручное ревью, и именно под такой процесс агенты подходят идеально. Слепак назвал бы это отправкой непроверенного кода.

reviewing-ai-code - это эмпирическое возражение конкретно Слепаку. Аргумент Тома Депьера (Thomas Depierre), основанный на исследованиях в области code review, заключается в том, что пропускная способность и самоуверенность проверяющего - реальные ограничивающие факторы, поэтому совет "просто проверяйте внимательно" не масштабируется так, как полагают его сторонники. Ответ Слепака не сформулирован прямо, но понятен из практики: он проводит ревью на уровне отдельных подзадач, а не целых PR, то есть проверяет небольшие фрагменты и чаще. Именно к такому режиму литература о ревью относится наименее пессимистично.

Где подход вписывается без противоречий: концепция human-in-the-loop как общий паттерн и vibe-engineering в части планирования. Причина, по которой эти накладные расходы оправданы, описана в skill-atrophy-supervision-paradox: контроль требует навыков, которые разрушаются при бесконтрольном использовании агентов. Вычитывание каждого diff'а - осознанный ответ на эту проблему, как и аргументы в dont-outsource-learning. В agentic-coding-is-a-trap сформулирована проблема, которую этот метод пытается обойти. Заголовок AI Disclosure - это противоположность human-made-disclosure: структура та же, но посыл обратный, и, в отличие от плашки о ручной работе, добавление такой отметки чего-то стоит автору.

Масштаб проблемы, на которую нацелен метод, виден в reward-hacking-in-the-wild. Из 3607 зафиксированных случаев некорректного поведения агентов 622 были деструктивными действиями - теми самыми удалениями и перезаписями файлов, которые отклонение запроса прав призвано остановить до применения, и из-за которых Слепак делает коммит после каждой подзадачи.

rakyll-coding-agents приходит к похожему выводу совершенно с другой стороны: ценность этих инструментов достаётся тем, кто уже знает, куда двигаться, и способен вовремя распознать правильную траекторию.