Команды, работающие только через промпты, и скрытые издержки, которые они создают

Почему быстрый код всё равно может тормозить команду

Быстрая генерация кода не убирает работу. Она просто переносит узкое место.

Написать код можно за минуты. А ревью, тестирование и исправления всё равно требуют реального времени. Команда может сделать пять pull request'ов до обеда, но кто-то всё равно должен прочитать diff, проверить допущения и решить, безопасно ли выкатывать изменение.

Этот разрыв быстро становится дорогим. AI может создать больше кода, чем команда успевает нормально проверить, и тогда очередь смещается с «сделать это» на «что именно это изменение изменило?». Люди начинают тратить больше времени на разбор последствий, чем на поставку результата.

Мелкие ошибки тоже расходятся дальше, чем ожидает большинство команд. Prompt вроде «добавь доступ по ролям» может затронуть middleware, модели базы данных, API handlers, состояния интерфейса, тесты и настройки деплоя. Если хотя бы одно допущение неверно, баг не остаётся в одном файле. Он проявляется в шести или семи местах, и исправление превращается в поиск по всему стеку.

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

Один неудачный merge может перечеркнуть неделю кажущейся скорости. Спешное обновление billing, auth или permissions может вызвать hotfix'ы, работу поддержки, путаницу у клиентов и ночные проверки базы данных. Код мог сгенерироваться за 20 минут. А исправление — занять два дня.

Команды, которые сохраняют высокий uptime и при этом используют AI, не полагаются только на промпты. Они относятся к сгенерированному коду как к любому другому рискованному изменению. Они держат понятные правила репозитория, выбирают тесты до merge и делают откат простым. Это менее эффектно, чем «выкатывай быстрее», но в итоге экономит намного больше времени, когда появляются реальные пользователи.

Что упускает работа только через промпты

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

Если один разработчик просит billing endpoint, а другой — payment API logic, модель может разложить файлы по разным папкам, выбрать разные названия и по-разному обработать ошибки. Код может работать. Но репозиторий всё равно станет более запутанным.

Многие командные правила вообще не попадают в prompt. Они живут в старых pull request'ах, в чьей-то памяти или в переписке из прошлого месяца. Модели плохо угадывают такие вещи. Если команде нужно, чтобы service-файлы лежали в одном месте, тесты были рядом с фичей, а логирование выглядело единообразно, это нужно записать там, где это увидят и люди, и инструменты.

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

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

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

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

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

Что должны покрывать правила репозитория

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

Начните со структуры. Названия папок должны показывать людям и агентам, где должен лежать код, где находится общая логика и что нельзя трогать без ревью. Ответственность тоже должна быть ясной. Если меняются billing-файлы, их должен проверить нужный инженер и владелец payments. Если меняется auth-код, его должен проверить ответственный за security. Это звучит строго, но экономит часы догадок.

Большинству команд полезно, когда правила репозитория покрывают четыре вещи: что должно лежать в каждой директории, кто владеет чувствительными частями кодовой базы, какой путь согласования нужен для изменений в базе данных, auth, billing и инфраструктуре, и какого размера должны быть коммиты.

Размер коммитов особенно важен, когда код пишет AI. Коммит на 600 строк с названием вроде «cleanup» скрывает реальный риск. Коммит на 40 строк с заметкой вроде «переименовать cache key в checkout flow» даёт ревьюеру честный шанс. И откатывать его намного проще.

Некоторые файлы требуют отдельной осторожности. Правила репозитория должны явно говорить, могут ли агенты менять migrations, настройки окружения, файлы деплоя или что-то связанное с secrets. Во многих командах самый безопасный default прост. Агент может подготовить migration-код, но перед merge его проверяет человек. Агенты никогда не коммитят secrets. Изменения конфига требуют явного согласования, потому что одно неверное значение может сломать рабочий релиз.

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

Относитесь к этим правилам как к живому документу. Когда происходит реальный инцидент, обновляйте их. Если сгенерированный скрипт слишком рано удалил столбец, добавьте правило для staged migrations. Если агент случайно изменил production config, закройте этот путь. Лучшие правила репозитория рождаются из шрамов, а не из теории.

Как выбирать тесты перед merge

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

Если запускать все тесты для каждого мелкого изменения, люди будут ждать слишком долго. Если почти ничего не запускать, баги пройдут в production. Ответ не в том, чтобы «всегда запускать полный набор». Ответ в том, чтобы подбирать тесты под риск.

Начните с diff. Посмотрите, какие файлы изменились, к какому сервису они относятся и какой общий код они затрагивают. Небольшая правка текста в интерфейсе не требует того же тест-плана, что изменение billing-логики или пути записи в базу.

Сначала запускайте самые быстрые тесты, которые покрывают эти пути. Unit-тесты и узкие integration-тесты обычно за несколько минут ловят очевидную поломку. Этот быстрый сигнал важен, потому что команда действительно им пользуется. Набор тестов на 40 минут, который все пропускают, хуже, чем набор на 4 минуты, которому доверяют.

На примере checkout это видно особенно хорошо. Если кто-то меняет формат invoice в одном сервисе, запустите тесты для этого сервиса, парсер invoice и один smoke test для checkout. Если то же изменение задевает payment retries или tax calculation, сразу расширяйте покрытие.

Более широкие тесты нужны, когда изменение касается общих зон риска вроде auth и permissions, billing и refunds, записи данных или schema changes, а также кода, который импортируется многими сервисами.

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

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

Как привычки отката уменьшают ущерб

Быстрая генерация кода сокращает путь от идеи до деплоя. Но она же сокращает путь от маленькой ошибки до проблемы у клиента.

Когда команда может выкатывать десять изменений в день, ей нужен чистый способ отменить одно плохое изменение за минуты. Это работает только тогда, когда деплои остаются маленькими. Если один релиз включает изменение базы данных, исправление billing, три правки интерфейса и новую фоновую задачу, никто не понимает, что откатывать первым. Мелкие деплои делают выбор намного проще: оставить или откатить.

Команды, работающие только через промпты, часто доверяют последнему результату, потому что он выглядит законченным. Именно здесь ущерб и растёт. Понятная привычка к откату ограничивает blast radius ещё до того, как люди начинают гадать, срочно чинить production или делать проблему хуже.

План отката должен отвечать на несколько простых вопросов. Какая была последняя стабильная сборка? Какая версия конфига ей соответствовала? Кто принимает решение об откате? Кто отвечает за шаги в app, базе данных и мониторинге? Сколько обычно занимает откат?

Многие команды спотыкаются именно о конфиг. Вернуть код часто проще, чем восстановить правильные feature flags, secrets, значения окружения и настройки деплоя. Если вы сохранили последнюю стабильную сборку, но забыли соответствующий конфиг, можно откатиться в другое outage.

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

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

Команды, которые держат высокий uptime, не считают откат поражением. Они считают его нормальной операцией. Такой подход ещё важнее, когда AI помогает команде выпускать код быстрее.

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

Простой пример из небольшой продуктовой команды

Небольшая продуктовая команда из четырёх человек попросила модель обновить текст в checkout перед запуском в новом регионе. Prompt выглядел безобидно: поменять несколько label'ов, добавить новую обработку налогов для одного рынка и не трогать существующий checkout flow.

Модель сделала всё за один проход. Она изменила текст кнопки, обновила summary заказа, затронула шаблон чека и скорректировала ветку расчёта налога для digital add ons. Diff выглядел чисто. Названия файлов были логичны. Стиль совпадал с кодовой базой. Поэтому команда быстро провела ревью и выкатала всё в тот же день.

Для большинства покупателей ничего странного не было. Заказы проходили, чеки приходили, а новый текст читался лучше старого. Потом поддержка получила сообщение из одного региона: суммы выглядели немного неверно. Клиент применил скидочный код, купил digital add on и попал в крайний случай в новой tax-логике. В checkout показывалась одна сумма, в чеке — другая, а платёжный сервис списал больше.

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

Три привычки уменьшили бы ущерб. Во-первых, репозиторий должен не позволять выкатывать изменения в pricing или tax в том же pull request, где есть только правки текста. Во-вторых, команде нужно было запустить точечный тест для нужного региона, включая один case со скидкой и одну проверку чека. В-третьих, им нужен был план отката, который позволил бы вернуть изменение checkout за минуты.

С такими ограничителями тот же баг всё равно был бы неприятным, но намного меньшим. Pull request получил бы дополнительное ревью. Тест, скорее всего, поймал бы расхождение до релиза. А если бы оно всё же прошло дальше, команда могла бы сначала откатить tax-изменение, оставить более безопасную правку текста на потом и остановить неверные суммы до того, как выросли тикеты в поддержку.

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

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

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

Одна частая ошибка — мерджить большой diff только потому, что он хорошо читается. AI может за один проход переписать пять файлов, добавить тесты, обновить migration и рефакторить helper. Ревьюеры смотрят бегло вместо проверки поведения, и команда пропускает ту самую строку, которая меняет auth, billing или обработку данных.

Ещё одна ловушка — доверять зелёным unit-тестам, когда никто не проверяет пользовательский путь. Unit-тесты модели писать легко, потому что они близки к коду, который она только что сгенерировала. А реальные поломки часто живут между шагами: пользователь входит в систему, меняет настройку, загружает файл, а потом попадает на страницу, которая падает из-за того, что изменилось одно поле API.

Команды также слишком расслабляются, когда агент редактирует конфиг. App-код получает больше внимания, но именно config-файлы решают, как приложение стартует, деплоится, кэширует, делает повторные попытки и общается с другими сервисами. Небольшая правка environment variable, feature flag, CI-задачи или rate limit может навредить сильнее, чем сломанная кнопка или плохая helper-функция.

Поздние релизы в конце недели только усугубляют ситуацию. Если кто-то мерджит в четверг вечером или в пятницу днём без назначенного владельца отката, команда сама создаёт себе медленный хаос. Когда начинают сыпаться алерты, люди под давлением задают простые вопросы: кто откатывает, какую migration нужно вернуть назад и какой flag выключает функцию?

Более тихая ошибка появляется уже после инцидента. Команда снова и снова решает одну и ту же проблему в чате вместо того, чтобы добавить правила в репозиторий. Если агент продолжает трогать защищённые файлы, писать слишком широкие права доступа или пропускать выбор тестов, ответ не в ещё одном хитром prompt. Ответ в том, чтобы закрепить урок в репозитории через правила ревью, проверки CI, шаблоны и понятные привычки merge.

Так команды сохраняют скорость и не платят за одну и ту же ошибку дважды.

Короткая проверка перед каждым merge

Быстрый код провоцирует на ленивые merge. Именно здесь команды потом платят больше всего.

Перед тем как выкатывать AI-сгенерированный код, нужно ответить на пять простых вопросов. Если хотя бы один ответ расплывчатый, merge, скорее всего, слишком ранний.

• Какой пользовательский поток изменился?
• Какие тесты покрывают именно этот поток?
• Как быстро мы откатим это, если что-то пойдёт не так?
• Достаточно ли мал diff, чтобы его честно проверить?
• Открыло ли это изменение новое правило, которое должно жить в репозитории?

Список простой. Сложность в дисциплине.

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

Выбор тестов важен не меньше. Если изменение влияет на письма при регистрации, запустите тесты вокруг регистрации, отправки писем и job queue, который запускает доставку. Широкие тесты допустимы, но они не заменяют точечные.

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

Ещё одна привычка быстро приносит пользу: ведите короткий список ошибок prompt'ов и правил репозитория, которые их исправили. Через несколько недель команда перестаёт повторять одни и те же ошибки. Это экономит больше времени, чем ещё один хитрый prompt.

Что делать дальше

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

Выберите одну часть репозитория, которая меняется часто, например billing, auth или onboarding. Запишите для неё три простых правила и сделайте так, чтобы их было легко проверять в ревью. Например, запретите прямые запросы к базе в handlers, требуйте migration для каждого изменения схемы и просите один обновлённый тест при каждом изменении API.

Затем соберите небольшую матрицу тестов для тех изменений, которые ваша команда делает чаще всего. Сделайте её достаточно короткой, чтобы ей реально пользовались. Изменение текста или layout в UI может требовать только smoke tests и одной визуальной проверки. Изменение API-логики обычно требует unit-тестов, contract tests и одного end-to-end сценария. Изменение базы данных должно включать проверки migration, seed data и тест отката. Изменения в auth или billing заслуживают полного критического пути, даже если это занимает больше времени.

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

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

Если никто в команде раньше не занимался этим в production, может помочь внешний взгляд. Oleg Sotnikov на oleg.is делает такую работу в формате Fractional CTO для стартапов и небольших команд, включая практики разработки с упором на AI, инфраструктуру и наведение порядка в релизном процессе. Несколько часов ревью часто дешевле, чем один плохой деплой.

Быстрый код полезен. Но ценность ему придаёт только безопасная поставка.