Две дорожные карты проекта: почему свежий код сразу становился legacy

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

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

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

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

Пишу по собственному инженерному опыту. Детали проекта обобщены и обезличены, а часть чисел округлена, чтобы из технического разбора не получилась викторина “угадай компанию”.

Код рассказал это раньше команды

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

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

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

Упрощённо процесс выглядел так:

репозиторий + задача + локальный контекст разработчика A -> решение A
репозиторий + задача + локальный контекст разработчика B -> решение B

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

Персональный контекст агента стал скрытой зависимостью проекта. Git был общим. Память нет.

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

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

В проекте работала вторая дорожная карта

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

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

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

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

Что мы изменили

Сначала поправили стимулы

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

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

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

Вернули контекст в репозиторий

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

У каждого типа артефакта появилась своя работа:

• спецификация фиксировала ожидаемое поведение до генерации кода;

• тесты проверяли это поведение;

• ADR сохранял причину значимого архитектурного решения, его последствия и условие пересмотра;

• общий harness задавал агентам одинаковые проектные ограничения;

• отдельная проверка оценивала нагрузку, радиус последствий и стоимость следующего изменения.

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

Разделили генерацию и проверку

Рабочий поток после изменений можно свести к такой схеме:

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

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

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

Добавили короткий архитектурный разбор

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

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

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

• кто станет его владельцем после слияния PR;

• что подорожает при следующем изменении;

• как он будет вести себя под ожидаемой нагрузкой и при отказе;

• при каком условии решение надо пересмотреть.

Агент заранее собирал архитектурную проверку и оценку последствий. Это экономило время встречи, но разрешение на новый сервис выдавал человек. Решение и его основания затем оставались в ADR.

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

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

Что изменилось за четыре недели

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

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

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

Если бы я повторял этот эксперимент, заранее зафиксировал бы хотя бы определение “PR с тестами”, формулу ошибки прогноза, медианное время прохождения изменения и долю ADR, которые потом пересматривались. Ретроспективная оценка помогает вернуть проект под контроль, но для нормального сравнения её мало.

Почему AI ускорил именно то, что уже происходило

Назначать AI главным злодеем было бы слишком удобно. После изменений те же агенты помогли довести долю PR с автоматическими тестами примерно до 100%, готовили архитектурные разборы и снимали рутинную работу с разработчиков.

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

DORA в отчёте 2025 года описывает AI как усилитель: он увеличивает преимущества сильных организаций и одновременно делает заметнее проблемы слабых. Авторы опираются на ответы почти пяти тысяч технических специалистов и более ста часов качественных данных. Это хорошо совпадает с нашим кейсом, хотя само по себе совпадение ничего не доказывает.

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

Откуда берётся короткий горизонт

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

Опросы рынка описывают фон, но объяснить мотивы пятерых разработчиков не могут. В опросе Noam Segal и Lenny Rachitsky о состоянии tech workers в 2026 году 55,7% респондентов сообщили как минимум об умеренном выгорании, 41,2% как минимум умеренно беспокоились об увольнениях, а тревога по поводу увольнения сильнее остальных измеренных факторов коррелировала с карьерным пессимизмом. При этом 49% участников чувствовали, что AI усилил их профессионально. Картина получилась расколотой, а не однозначно мрачной.

Американский Tech Sentiment Report от Dice сообщает, что увольнения прямо или косвенно затронули две трети участников, а доля ожидающих долгосрочного роста технологической отрасли снизилась с 80% до 60% по сравнению с предыдущими опросами. Выборка ограничена 1159 американскими IT-специалистами, опрошенными в ноябре и декабре 2025 года, поэтому переносить результат на всю профессию нельзя.

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

Что проверить в своём проекте

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

• Инструкции, ограничения и критерии проверки для агентов лежат в репозитории или живут на ноутбуках разработчиков?

• Можно ли по истории проекта восстановить, почему появился новый сервис или изменилась граница модуля?

• Спецификация описывает поведение до генерации кода или создаётся задним числом вместе с документацией?

• Реализацию и архитектурную проверку выполняет один и тот же агент в одном контексте?

• У спорного решения есть владелец и условие пересмотра?

• Команда обсуждает стоимость следующего изменения до слияния PR или узнаёт её через две недели переделок?

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

Код хранит реальный горизонт команды

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

YAGNI остался на месте. Он просто перестал означать “после нас хоть rewrite”.

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