Код, который написали без тебя: как агенты пишут прод, а ты сидишь и смотришь отчеты

Привет! Меня зовут Михаил Дукин, и я получаю деньги за код с 2009-го, а писать начал еще раньше. Тогда это был PHP, FTP-загрузка файлов прямо на прод и ощущение, что ты бог, потому что форма отправки письма наконец-то не падает с 500-й ошибкой. Тесты я полюбил немного позже — после того, как в три часа ночи упала интеграция с платежным шлюзом, а я понятия не имел, в каком месте.

Потом я управлял командами. Потом уже тимлидами. Потом внедрял ИИ и, собственно, дошел до состояния, когда код руками уже почти не пишу и даже не смотрю: я пишу спецификацию и отдаю ее агенту. Агент присылает мне отчет с доказательствами качества: тесты, покрытие, отчет о прохождении ревью. Если все корректно, то сливаю.

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

Я долго не мог перестать читать код. Даже если пайплайн зеленый, тесты прошли, мутанты убиты, я все равно раз за разом открывал дифф по привычке. Она очень долго была сильнее логики. Цифры говорили мне, что все хорошо, но я все равно раз за разом лез в код. Прошло это далеко не сразу.

Но штука в том, что иногда самый ценный код — это тот, который ты не написал и даже не прочитал. Его написал агент, проверила автоматика, он просто работает так, как ты и задумывал. А ты уже думаешь про следующую фичу. Это другая точка приложения мозгов.

Сейчас я в Слетать.ру — это туристический агрегатор. Ошибаться дорого. Мы не на нуле: несколько сервисов уже дошли до мутационного тестирования, агенты пишут код. Собираю систему по кускам, уже зная, где разбросаны грабли. Для меня ИИ в разработке travel-сервисов — это ежедневная инженерная практика, где цена ошибки измеряется не только багами, но и деньгами, данными и доверием пользователей

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

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

Выход из этого есть: отменить доверие как класс. Не «мы вам не доверяем», а мы никому не доверяем просто на слово, без доказательств. Доверие теперь — это свежий результат проверки. Срок годности — всего один коммит. Дальше уже перепроверка.

Правила одни для всех: человек, агент, джун, сеньор с пятнадцатилетним стажем. Каждое изменение — это прогон через все гейты качества; доступ ровно под задачу, никаких «на всякий случай»; staging — это не production и не dev, среды должны быть разделены; а логи должны писаться и просматриваться.

Человек и агент в этой системе проходят через одно и то же. В этом основной смысл политики. Правила настроены против привычки верить на слово.

Я когда-то работал в кризисных группах, и первое, чему там учишься: не верить ни одному источнику, пока три независимых не сказали одно и то же. В разработке ровно так же. Особенно когда искусственный интеллект в разработке перестает быть игрушкой для генерации сниппетов и начинает реально менять инженерный процесс.

Помните холивары «GPT лучше Claude»? Они уже кончились. Топовые модели выровнялись и работают плюс-минус на одном уровне.

Теперь разрыв дает не модель, а харнесс — обвязка: контекст, права, инструменты с блокировками, обратная связь от тестов.

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

Вообще, харнесс — это не про модель. Это скорее про нас самих. Модель обновится раз в квартал самостоятельно, а обвязку для агентов строим мы сами. На новом проекте я начал именно с этого.

И вот тут хорошо видно, что нейросети для разработчиков — это не «кнопка сделать красиво». Это инструмент, который начинает приносить пользу только тогда, когда вокруг него есть процесс, ограничения, проверки и понятная ответственность.

На прошлом проекте, когда мы только начинали с агентами, наступали на одни и те же грабли. Дашь агенту «сделай форму регистрации» — он сделает, но не факт, что то, что ты имел в виду. Начинается бесконечный цикл правок: вроде код и пишет агент, а скорость не растет. Бывает, что и падает. Может возникнуть мысль о том, что все это просто хайп. Это лечится спецификацией до кода. Spec-First. Звучит, конечно, как очередная бюрократия, но работает ровно наоборот.

У нас даже появился отдельный агент, который превращает обычные описания задач в нормальные спеки. Берет бриф, который написал менеджер, и выдает пользовательскую историю, use cases, Gherkin-сценарии и чеклист с основными проверками. Разница принципиальная: в первом случае агент точно начнет додумывать. Во втором — у него есть основной контракт с правильно выбранной персоной, понятная боль бизнеса и ценность, которую получает конкретная роль от конкретного действия. Это уже половина качественного решения.

Причем контракт этот проверяет не только автоматика. Бизнес-заказчик смотрит на результат и говорит, так мы его поняли или нет. Если не так, то можно поправить описание, а не код, а до разработчика на этой стадии задача даже не дошла. Но когда дойдет — ему, как и агенту, тоже будет проще работать с задачей, когда в ней понятна реальная проблема и есть внятные критерии готовности.

А дальше техническая часть: что менять, где, как проверять. Разработчик отдает спеку агенту в Plan Mode, агент читает репозиторий и выдает конкретный план изменений. С этим планом агент в Code Mode уже не фантазирует, а следует контракту.

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

И спека — это тоже навык. Чем больше ее пишешь или валидируешь, тем точнее она будет и тем проще будет агенту сделать именно то, что ты хотел.

Спека есть. А что дальше?

Дальше — Quality Gates. Шлагбаумы. Если покрытие упало ниже 70%, то PR дальше не едет. Линтер красный — не едет. Сканер поймал токен в коде — не едет. E2E сломались — не едет.

Я видел, как выглядят проекты, где этого нет: агент плодит код быстрее, чем люди успевают его читать. Через месяц там гора из костылей и мусора, и никто не понимает, что из этого вообще работает. С гейтами все становится иначе и гораздо комфортнее.

Раньше покрасневшие CI означали, что разработчик встает и идет чинить. Теперь агент дорабатывает код сам. Человек не видит код, пока джобы, проверяющие качество, упавшие, кроме случаев, когда агент сам не сможет выбраться. Агент крутится: генератор → ревьюер → проверки → красные джобы → новый план → новая генерация. Без человека.К человеку он попадет только когда пайплайн позеленеет.

Проверок у меня набирается семь слоев, и я не скажу, что заранее планировал ровно столько. Просто каждый раз, когда что-то ломалось, добавлял еще один. Сначала линтер, чтобы не спорить про отступы на ревью. Потом статанализ, когда поймали баг из-за того, что кто-то не учел приведение типов. Сканер секретов — после того, как чуть не утекли ключи в репозиторий. Юнит-тесты с coverage gate появились, когда мы перестали понимать, какой процент кода вообще проверяется.

Интеграционные — когда несколько раз ломались связки между модулями, а юниты этого не видели. E2E на Playwright добавили последними: гоняются они довольно долго, даже несмотря на то, что проверяется только то, что не покрыто слоями ниже. Но тут главное — уметь их параллелить и не дублировать проверки.

Седьмой слой — мутационное тестирование. Вот в него я влюбился по-настоящему. В коде if (a > b) подменяется на if (a >= b). Если тест остался зеленым — он пустышка.

Если тест покраснел, значит мутант убит. Еженощный прогон убивает сотни мутантов, и это самое приятное уведомление в CI. Уровень качества тестов на всех новых сервисах — около 90%. Сотню на реальных сервисах нам выбить не удалось: есть эквивалентные мутанты, в которых формально код меняется, но поведение — нет. Закрывать их бессмысленно, это бы просто сделало нашу систему более хрупкой.

Есть еще LLM-ревью. Просто еще одна пара глаз на PR смотрит diff и сравнивает со спекой. Если он раз за разом находит то, что должны были поймать проверки, — проверки надо чинить.

По сути, это и есть автоматизация разработки: и это далеко не «пускай робот пишет что хочет», а конвейер, где каждое действие подтверждается проверками, а результат можно воспроизвести и объяснить.

Я помню момент, когда перестал читать код. Сижу, смотрю на зеленые галки в пайплайне. Думаю: ну все, допрыгался, даже дифф не открыл. А потом смотрю на отчет: тесты прошли, мутанты убиты, секретов нет, спеке соответствует. И понимаю: ну а зачем мне это читать? Чтобы что? Найти то, что семь выстраданных слоев автоматики пропустили? Ну-ну.

Да, до этого нужно долго вылизывать гейты. Сначала они были красными чаще, чем зелеными. Тесты врали, мутанты плодились, CodeRabbit душнил по мелочам и пропускал важное. А потом практически незаметно перестали. Зеленое стало нормой. Ложных срабатываний не было. Пассрейт стабилен.

Постепенно у нас сложилось простое правило. Спрашиваешь себя: «Что будет, если этот код сломается?» Если ответ: «Да ничего, починим», то можно сливать, даже не просматривая дифф. Если «потеряем деньги» или «утекут данные» — дифф, конечно же пока, нужно открыть.

Со временем это вылилось в то, что мы теперь называем риск-ориентированным ревью. Хотя на деле никакой магии: просто перестали дергаться там, где не о чем дергаться, и стали действительно плотно проверять там, где это реально необходимо.

Для меня внедрение ИИ в разработку как раз об этом. Не про замену инженеров, а про перенос инженерного внимания туда, где оно действительно нужно: риски, архитектура, границы системы, качество процессов.

Система не статична: красный гейт, отказ ревьюера, инцидент, все это данные. И все они должны идти в петлю: сбор, анализ, дообучение, контроль.

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

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

Это уже не похоже на написание кода. Но мне это нравится больше.

Самое ценное, что я теперь делаю, — говорю «нет». Нет, спека кривая. Нет, гейт дырявый. Нет, так не строим.

Раньше я мерил день сделанными задачами. Теперь — предотвращенными проблемами. Агент пишет код, а я не даю ему навредить. Да, это совершенно другая работа. И без нее теперь никуда.

Разработка travel-сервисов особенно быстро показывает, где ИИ ускоряет команду, а где просто быстрее разносит старые проблемы по системе. Поэтому для меня главный вывод простой: ИИ хорош не там, где ему дали больше свободы, а там, где инженеры лучше построили рамки.

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

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

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

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

Агент добавляет к этому списку еще один источник ошибок. И еще несколько слоев защиты. Но при этом автоматика не устает. LLM-ревью не отвлекается. И вместе мы ошибаемся реже, чем поодиночке. Так что когда агент косячит — это не новая проблема. Это та же самая, только с другим источником.

Я много раз видел одно и то же. Команда хочет построить весь пайплайн разом и застревает на полгода. А соседняя команда просто ставит pre-commit, потом начинает выстраивать CI, потом пробует отдавать агенту то, что ее разгрузит.

Не надо строить на века. Поставь линтер на pre-commit. Замерь, стало ли лучше. Улучши CI. Замерь. Напиши одну спеку и отдай агенту, посмотри, что выйдет. Маленькие шаги. Эксперименты. «Пробуем и смотрим на метрики». Мир вокруг несется, и если стоять на месте, то точно не успеешь. А если двигаться, пусть и маленькими шагами, есть все шансы оказаться впереди.

Каждый день раньше открывал дифф, искал глазами то, что пропустила автоматика. Даже если ничего не находил, но все равно искал. А потом перестал и отчетливо понял: автоматика не умнее меня, но она не устает, не отвлекается, не пропускает по невнимательности. Зеленая галка — это семь проверок, которые сошлись на «да» и приложили к этому целую пачку доказательств.

Постепенно это превратилось в конвейер: задача → спека → агент → гейты → отчет.