Стоимость сгенерированного кода и почему границы продукта кажутся фальшивыми

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

Границы продукта кажутся реальными, когда каждая функция заставляет принять настоящее решение. Кто может этим пользоваться? Что происходит, если данные неверны? Что увидит клиент, если что-то сломается?

Сгенерированный код может проскочить мимо этого ощущения, потому что результат появляется раньше, чем эти решения. Команда может за день собрать десять экранов, страницу настроек и рабочее демо. Такой темп радует, но он меняет то, что люди считают прогрессом. Они перестают спрашивать: «Мы понимаем правило?» — и начинают спрашивать: «Сколько мы сгенерировали?»

Вот тогда границы и становятся скользкими. Код появляется раньше, чем продукт становится понятным. Демо выглядит завершённым, потому что проходит по основному сценарию. А настоящие продукты живут в крайних случаях, исключениях, правах доступа, странных запросах клиентов и скучных административных задачах, о которых вспоминают слишком поздно.

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

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

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

В стартапах это видно особенно часто. Основатель смотрит на отполированную демку и чувствует, что roadmap сжимается. Потом продажи просят свои правила согласования, поддержка — журналы аудита, а финансы — объяснить, как должны работать возвраты. Продукт никогда не был настолько близок к завершению. У команды просто было больше output, чем ответственности.

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

Чего нет в сгенерированном коде

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

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

Страница выставления счетов делает это особенно заметным. Она может создавать счета, отправлять письма и сохранять суммы. Но при этом всё ещё может не отвечать на вопросы: что делать, если VAT изменится после выставления, если клиент относится сразу к двум billing-группам или если finance нужен ручной override. Именно эти детали и есть продукт. Это не украшение.

Следующий пробел — структура. В сгенерированных файлах часто смешиваются названия, повторяются вспомогательные функции и появляется layout папок, который не совпадает с остальной кодовой базой. В одном месте написано «customer», в другом — «user», а в третьем — «account». Звучит мелко, но это тормозит каждое будущее изменение, потому что людям приходится останавливаться и угадывать, что именно означает каждое слово.

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

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

Ответственность так же важна. У каждой области должен быть один человек, который может ответить на вопросы, утвердить изменения и выбрать компромисс, когда времени мало. Если за billing, auth или notifications никто не отвечает, проблемы лежат в backlog, пока не превратятся в инциденты или переделки.

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

Где проявляются настоящие затраты

Первая версия часто кажется дешёвой. Настоящий счёт открывают вторая, третья и десятая правка. Затраты на сгенерированный код обычно приходят после демо, когда люди начинают редактировать, проверять, тестировать и поддерживать то, что выдала модель.

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

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

Исправление багов становится дорогим, когда запросы всё время меняют структуру. Разработчик просит одно и то же дважды и получает два стиля именования, два layout и два способа обрабатывать крайние случаи. Функция по-прежнему работает в демо, но позже исправления превращаются в поисковую работу. Инженеры тратят время на то, чтобы понять, какая копия логики настоящая.

Такое отсутствие доверия ещё сильнее усложняет on-call работу. Когда прод падает в 2 часа ночи, никто не хочет гадать, как сгенерированная функция обрабатывает повторы, тайм-ауты или частичные сбои. Команды начинают двигаться медленнее, потому что уже нельзя предполагать, что похожий код ведёт себя одинаково.

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

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

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

Кто отвечает за код после генерации

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

Лучше всего ответственность работает на уровне модуля, а не всего приложения. Один человек должен отвечать за auth, другой — за billing, третий — за background jobs и так далее. Это не значит, что он пишет каждую строку. Это значит, что он утверждает структуру, следит за тем, чтобы код не расползался, и решает, когда упрощение становится слишком рискованным.

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

Настройка не обязана быть сложной. Назначьте по одному владельцу на каждый модуль. Определите людей, которые могут утверждать AI-сгенерированные изменения. Храните запрос, результат и ручные правки в одном рабочем элементе. Требуйте очистку перед слиянием, а не «потом».

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

Хранить запросы рядом с правками полезнее, чем думают многие команды. Через шесть недель владелец сможет увидеть, что именно модель угадала, скопировала из старого шаблона или придумала заново. Это ускоряет AI-ревью кода, потому что у проверяющего есть контекст, а не загадочный diff.

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

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

Как проверять сгенерированный код шаг за шагом

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

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

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

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

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

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

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

Простой пример стартапа

Основатель строит небольшой SaaS-продукт и быстро нуждается в админских экранах. За два дня AI-инструмент делает список пользователей, управление ролями, страницы подписок и кнопку возврата денег. Демо выглядит впечатляюще. К концу второго дня функция кажется намного больше, чем есть на самом деле, потому что команда может по ней пройтись и видит много поверхностной работы.

Потом приходят недостающие правила.

Сотрудники поддержки должны видеть счета, но не менять биллинг. Менеджеры должны отменять планы, но только для активных аккаунтов. У trial-пользователей не должно быть тех же действий, что у платных клиентов. Возвраты требуют логов. Изменения тарифов требуют проверок. В первой сгенерированной версии этого ничего не видно, хотя именно эти правила решают, можно ли безопасно выпускать функцию.

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

К десятому дню это ощущение исчезает. Старший инженер открывает проект и видит пять версий одной и той же идеи. Логика billing разбросана по нескольким файлам. Правила доступа противоречат друг другу. Сообщения об ошибках не совпадают. Тестов на рискованные сценарии нет.

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

Хорошее AI-ревью кода заметило бы это гораздо раньше. Один человек мог бы остановить команду после первого демо и задать три простых вопроса: где живут права доступа, где живёт логика billing и кто будет поддерживать это через месяц? Эти вопросы кажутся скучными на второй день. Они решают график на десятый.

Ошибки, которые команды делают в начале

Команды часто путают видимый output с завершённой работой. Репозиторий может за полдня вырасти с 20 файлов до 200, и это кажется прогрессом. Но это всё ещё просто текст, пока кто-то не проверит поведение, не протестирует крайние случаи и не решит, кто будет поддерживать это через месяц.

Одна из частых ранних ошибок — считать сгенерированные файлы завершёнными границами продукта. Если AI-инструмент создал экраны входа, API-маршруты и модели базы данных, команда может сказать, что функция почти готова. На деле это лишь черновик. Скрытая работа начинается после генерации: ревью, очистка, нейминг, тесты, проверки безопасности и все маленькие исправления, которые появляются, когда реальные пользователи начинают кликать.

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

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

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

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

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

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

Быстрые проверки перед тем, как назвать работу готовой

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

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

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

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

Объясните изменения support и ops простыми словами. Им нужно знать, что могут сообщать пользователи, за какими логами следить и какие алерты могут сработать.

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

AI-ревью кода помогает, но не заменяет ответственность. Ревьюер может заметить странные шаблоны, мёртвые ветки или скопированную логику. Но кто-то из команды всё равно должен понимать, зачем существует этот код и как безопасно его менять.

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

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

Начните с уменьшения размера каждого AI-сгенерированного изменения. Если один запрос создаёт 800 строк, разбейте работу до того, как кто-то её сольёт. Маленький pull request проще тестировать, проще проверять и гораздо легче поддерживать через шесть месяцев.

Установите жёсткий лимит на ревью, который команда действительно может проверить. Если два человека не могут прочитать изменение, запустить тесты и объяснить замысел простыми словами, изменение слишком большое. Быстрый output дешёв. Внимание — нет.

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

Эта скрытая работа быстро становится дорогой. Одна дополнительная страница дашборда сегодня может завтра добавить triage багов, проверки ролей, обновления тестов и вопросы поддержки. Если функция выглядит как «два дня с AI», заложите и последующую работу, иначе roadmap уйдёт далеко от реальной мощности команды.

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

Команды обычно застревают там, где output растёт быстрее, чем понимание. Backlog выглядит полным, демо — хорошими, и никто не замечает долг, пока маленькая правка не начинает занимать полдня. AI-ревью кода должно ловить это раньше, а не после релиза.

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

Для стартапов и небольших команд это часто значит подключить частичного CTO до того, как беспорядок станет дорогим. Oleg Sotnikov на oleg.is работает именно с такими задачами: лимиты ревью, зоны ответственности, привычки тестирования и реалистичное планирование границ продукта для AI-first разработки. Цель — не больший output. Цель — кодовая база, которой команда всё ещё может доверять и которую может поддерживать после окончания демо.