Сегодня я почти не писал код.

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

Со стороны это может выглядеть как обычный модный «вайб-кодинг»:

Написал нейросети: «Сделай сайт» — и пошёл пить кофе.

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

Шуруповёрт ускоряет одну операцию.

Производственная линия управляет порядком операций, контролирует качество, останавливается при браке и не отправляет недоделанное изделие дальше.

Именно эту разницу многие пока не замечают.

Как обычно выглядит разработка с нейросетью

Типичный сценарий сегодня примерно такой:

1. Человек открывает редактор.

2. Пишет большой запрос.

3. Модель создаёт несколько файлов.

4. Что-то не запускается.

5. Человек копирует ошибку обратно в чат.

6. Модель исправляет одну ошибку и создаёт две новые.

7. Контекст разрастается.

8. Модель забывает, что делала в начале.

9. В какой-то момент она уверенно сообщает: «Всё готово».

10. Человек открывает сайт и обнаруживает, что половина кнопок существует только визуально.

Это не автоматизация разработки.

Это ручное управление очень быстрым, очень разговорчивым и временами самоуверенным программистом.

Человеку всё равно приходится постоянно сидеть рядом:

• подтверждать каждую команду;

• повторять требования;

• напоминать, какие файлы нельзя трогать;

• следить, чтобы агент не переписал рабочий код;

• заново объяснять контекст после сброса сессии;

• проверять, действительно ли тесты запускались;

• выяснять, почему слово «готово» не совпадает с реальностью.

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

Что происходило у меня сегодня

Сегодня работа выглядела иначе.

Агент получал не просьбу «сделай ещё одну функцию», а одну ограниченную задачу из заранее построенной очереди.

У задачи были:

• известные зависимости;

• разрешённый объём изменений;

• критерии приёмки;

• обязательные проверки;

• запреты;

• условия остановки;

• правило фиксации результата.

Агент не решал, что ему делать дальше. Порядок уже существовал вне его контекста.

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

Если следующая задача зависела от человеческого решения, конвейер останавливался.

Не «примерно останавливался».

Не «выбирал наиболее разумный вариант сам».

Не «добавлял временное значение, чтобы потом поменять».

Он действительно прекращал работу и возвращал человеку конкретный вопрос.

Это принципиально.

Большая часть опасных ошибок в AI-разработке появляется не тогда, когда модель не знает синтаксис. Синтаксис она как раз знает неплохо.

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

Какой лимит поставить?

Какой формат хранения выбрать?

Что важнее: скорость, память или совместимость?

Можно ли считать эмуляцию телефона доказательством работы на настоящем устройстве?

Обычный вайб-кодер часто отвечает на такие вопросы одной фразой:

Выбери оптимальный вариант сам.

После этого случайное предположение модели превращается в архитектуру проекта.

У меня такие места являются не продолжением задачи, а стоп-сигналом.

Сегодня система несколько раз доказала, зачем это нужно

В течение дня один исполнитель подготовил большой технический черновик и сообщил, что все проверки проходят.

В обычном AI-процессе на этом месте человек нажал бы «принять всё» и пошёл дальше.

Но черновик не считался готовой работой.

Его передали другому агенту в роли независимого ревьюера. Причём ревьюеру было прямо запрещено доверять отчёту первого исполнителя.

Он должен был:

• прочитать изменения;

• проверить, что тесты действительно проверяют заявленное поведение;

• воспроизвести результаты;

• найти ложноположительные проверки;

• повторно запустить весь набор тестов;

• не принимать архитектурных решений за пользователя.

Ревьюер воспроизвёл результаты и нашёл реальный пограничный дефект.

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

Ошибка была исправлена.

Затем появился отдельный регрессионный тест, который:

• падал на старом поведении;

• проходил после исправления;

• навсегда оставался в проекте как защита от повторения дефекта.

Вот это уже похоже на разработку.

Не потому, что код написал искусственный интеллект.

А потому, что утверждение «работает» было отделено от доказательства «работает».

Потом ошибся уже человек

Самый показательный момент дня произошёл даже не с моделью.

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

При обычном вайб-кодинге агент немедленно продолжил бы работу:

• записал выбранное значение в конфигурацию;

• построил вокруг него реализацию;

• добавил тесты;

• изменил документацию;

• возможно, успел бы сделать коммит.

Через час ошибочный клик уже выглядел бы как осознанное архитектурное решение.

Но система была устроена так, что решение ещё не стало необратимым результатом.

Работа была остановлена. Незакоммиченные изменения проверены. Случайный выбор удалён точечным редактированием. Уже завершённые этапы не пострадали. Репозиторий вернулся в чистое состояние, а открытый вопрос снова стал открытым.

Это важная часть автоматизации, о которой почти никто не говорит.

Хорошая автоматизация — не та, которая быстрее всех бежит вперёд.

Хорошая автоматизация — та, которую можно безопасно остановить в неправильный момент.

Ошибка большинства AI-веб-разработчиков

Многие автоматизируют генерацию кода.

Но генерация кода — далеко не самая дорогая часть разработки.

Дорого стоят:

• правильная последовательность изменений;

• сохранение инвариантов;

• проверка совместимости;

• работа с граничными случаями;

• восстановление после сбоя;

• контроль архитектурных решений;

• доказательство того, что новая функция не сломала старые;

• честная остановка при отсутствии данных.

Если автоматизировать только написание строк, получается очень быстрый генератор технического долга.

Он может за вечер создать красивый интерфейс, десятки API-методов и впечатляющую структуру каталогов.

Но за внешней активностью часто скрывается следующее:

• тесты проверяют mocks вместо реальных сервисов;

• база данных существует только в модели ORM;

• очередь задач никогда не запускалась отдельным процессом;

• offline-режим работает только при включённом интернете;

• мобильная поддержка доказана изменением размера окна браузера;

• безопасность описана в документации, но не проверяется кодом;

• сообщение «успешно» основано на том, что команда завершилась без исключения;

• агент сам придумал продуктовые ограничения и сам же написал под них тесты.

Главная ошибка здесь не в использовании нейросети.

Главная ошибка — позволить одному и тому же исполнителю одновременно:

• придумать требование;

• реализовать его;

• проверить самого себя;

• решить, что проверка достаточна;

• объявить работу завершённой.

Человек тоже ошибается в такой системе. Поэтому в нормальной разработке существуют требования, code review, QA, CI и приёмка.

Если заменить всю команду одним чатом, эти функции никуда не исчезают. Они просто перестают выполняться.

Что автоматизировано у меня

Я автоматизировал не «написание сайта».

Я автоматизировал движение работы через состояния.

В сильно упрощённом виде процесс выглядит так:

требование → ограниченная задача → проверка зависимостей → реализация → локальные тесты → интеграционные проверки → фиксация результата → следующая задача

Но у этой линии есть ответвления:

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

Именно это является моей настоящей автоматизацией.

Не конкретная нейросеть.

Не волшебный промпт.

Не кнопка Auto.

А набор правил, из-за которых система не может незаметно превратить предположение в готовую функцию.

Документы вместо памяти модели

Ещё одна распространённая ошибка — считать контекст чата памятью проекта.

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

Потом контекст становится огромным.

Каждый новый запрос несёт за собой всё больше старой информации. Стоимость растёт. Скорость падает. Внимание модели размазывается по десяткам файлов и обсуждений.

В какой-то момент она начинает путать:

• завершённое с запланированным;

• старое решение с новым;

• временный workaround с постоянной архитектурой;

• отчёт другого агента с проверенным фактом.

У меня состояние проекта хранится не в надежде на память сессии.

Оно вынесено наружу:

• архитектура;

• принятые решения;

• открытые вопросы;

• очередь реализации;

• текущая задача;

• критерии готовности;

• результаты проверок;

• известные риски;

• история коммитов.

Поэтому сессию можно закончить.

Модель можно заменить.

Лимит может сброситься.

Консоль можно случайно закрыть.

Работа от этого не должна потерять смысл.

Новый исполнитель не обязан знать всю историю разговоров. Он сначала читает текущее состояние проекта и только затем получает право что-то менять.

В этом смысле Git и структурированные документы являются памятью системы, а контекст модели — только временной рабочей областью.

Модели у меня не конкурируют за один файл

Некоторые пытаются ускорить разработку, одновременно запуская несколько агентов в одном каталоге.

Один меняет базу данных.

Другой переписывает API.

Третий обновляет тесты.

На экране выглядит впечатляюще: все что-то делают.

Через полчаса начинается настоящее веселье:

• один агент прочитал старую версию файла;

• второй изменил контракт;

• третий написал тест под промежуточное состояние;

• первый сохранил свой результат поверх новых изменений;

• никто не понимает, какой набор файлов является целым.

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

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

В моём процессе исполнители сменяют друг друга.

Один закончил черновик и полностью остановился.

Только после этого начинает работу ревьюер.

Если первый агент не сделал коммит, второй видит точный набор незавершённых изменений и знает их происхождение.

Если этап завершён, следующий начинается от чистой контрольной точки.

Это немного медленнее на красивом видео.

Зато гораздо быстрее, чем потом разбирать тысячу строк взаимоисключающих правок.

Почему дорогая модель не должна делать всё

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

Но дело не только в цене.

Чем больше сырой работы выполняет одна модель в одной длинной сессии, тем сложнее ей сохранить точность.

Поэтому роли разделены.

Один исполнитель может быстро подготовить ограниченный черновик.

Другой проверяет архитектуру, инварианты и тесты.

Человек принимает решения, которые нельзя вывести из кода.

Автоматические проверки подтверждают поведение, которое не должно зависеть от чьей-либо уверенности.

Получается не лестница «глупая модель → умная модель».

Получается разделение ответственности:

исполнитель отвечает за объём ревьюер отвечает за сомнение тесты отвечают за повторяемое доказательство Git отвечает за контрольную точку человек отвечает за смысл

Ни один участник не считается безошибочным.

Именно поэтому вся система работает.

Что в этом процессе делает человек

Можно подумать, что человек здесь вообще не нужен.

На практике его роль просто меняется.

Я не выбираю имена переменных и не печатаю каждый обработчик вручную.

Но я решаю:

• что именно является продуктом;

• какие компромиссы допустимы;

• когда данных недостаточно;

• какой риск можно принять;

• какие заявления нельзя делать без проверки;

• когда пора остановить автоматизацию;

• что считать доказательством готовности.

Обычный вайб-кодер разговаривает с моделью как заказчик с фрилансером:

Сделай красиво.
Теперь исправь.
Нет, не так.
А теперь добавь ещё вот это.

В моём случае человек больше похож на диспетчера производства.

Он не стоит у каждого станка.

Он определяет маршрут, правила контроля и точки, в которых линия обязана остановиться.

Это не устраняет ответственность.

Наоборот, ответственность становится заметнее: нельзя оправдаться тем, что «так написала нейросеть». Решение либо принято человеком, либо остаётся открытым.

Как я теперь измеряю прогресс

Раньше прогресс было легко измерять количеством написанного:

• появились новые файлы;

• добавились тысячи строк;

• интерфейс стал больше;

• агент работал несколько часов.

Теперь эти показатели почти ничего для меня не значат.

Настоящий прогресс выглядит иначе:

• завершён отдельный контракт;

• обязательные тесты прошли;

• реальная интеграция воспроизведена;

• граничная ошибка получила регрессионный тест;

• открытое решение осталось открытым до получения данных;

• незавершённая работа не была выдана за готовую;

• после остановки система продолжилась с той же контрольной точки.

Можно написать десять тысяч строк и не приблизиться к работающему продукту.

А можно удалить двадцать строк, добавить один правильный тест и сделать систему значительно надёжнее.

Самая важная автоматизация — право не продолжать

Сегодня один из агентов упёрся в ограничение сессии.

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

В управляемом процессе это штатное состояние.

Система сохранила checkpoint.

Завершённые этапы уже находились в отдельных коммитах.

Рабочее дерево было проверено.

Открытый вопрос не превратился в случайное решение.

Продолжение можно было передать другой модели или отложить до сброса лимита.

Ничего не требовало героического восстановления по истории терминала.

И в этот момент я понял, в чём главное отличие моей автоматизации от большинства демонстраций AI-кодинга.

Другие показывают, как агент умеет продолжать работу.

Моя система умеет правильно не продолжать её.

Она останавливается:

• перед неподтверждённым решением;

• после падающего теста;

• при отсутствии обязательной инфраструктуры;

• при исчерпанном лимите;

• перед опасным изменением;

• после черновика, который ещё не прошёл независимую проверку.

Скорость без тормозов — это не автоматизация.

Это авария, которой просто ещё не хватило времени произойти.

Экономика здесь вторична, но показательна

За день через систему прошли миллионы токенов.

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

Фактическая стоимость черновой облачной работы оказалась сопоставима с мелкой бытовой покупкой.

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

Но главный выигрыш даже не в прямой цене токенов.

Дешевле стало исправлять ошибку рано.

Дешевле стало остановить неправильное решение до реализации.

Дешевле стало воспроизвести проверку.

Дешевле стало передать задачу между исполнителями.

Дешевле стало восстановиться после окончания сессии.

Токены экономит не короткий промпт.

Токены экономит отсутствие хаоса.

В чём итоговая разница

Обычный вайб-кодер автоматизирует руки:

Пусть модель быстрее пишет код.

Я пытаюсь автоматизировать дисциплину:

Пусть система не принимает непроверенную работу.

Обычный вайб-кодер радуется, когда агент создал двадцать файлов.

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

Обычный вайб-кодер считает завершением сообщение модели.

Я считаю завершением воспроизводимую проверку и чистую контрольную точку.

Обычный вайб-кодер боится сбросить контекст.

Мой процесс предполагает, что любой контекст временный.

Обычный вайб-кодер ищет один идеальный промпт.

Я строю систему, в которой один неидеальный промпт не должен разрушить проект.

Обычный вайб-кодер использует AI как очень быстрый редактор.

Я использую несколько ограниченных ролей как производственный процесс.

Финальная мысль

Сегодня я не наблюдал, как нейросеть «сама сделала сайт».

Я наблюдал, как работа проходила через контролируемый конвейер:

• реализация;

• проверка;

• ошибка;

• регрессионный тест;

• решение человека;

• фиксация;

• безопасная остановка;

• восстановление.

Код в этом процессе действительно пишут модели.

Но продукт создаёт не модель.

Продукт создаёт система, которая знает:

• что сейчас разрешено делать;

• что должно быть доказано;

• кто имеет право принять решение;

• когда результат можно зафиксировать;

• когда необходимо остановиться.

Многие пытаются найти нейросеть, которая никогда не ошибается.

Я пошёл в другую сторону.

Я строю процесс, в котором ошибка одного участника — даже моя собственная — не должна незаметно стать частью продукта.

И, кажется, именно это является настоящей автоматизацией разработки.

Не когда код пишется без человека.

А когда работа не разваливается без его постоянного присутствия.