Четыре года разработки, потом всё отдали ИИ — и код пропал из мастер-репозитория
Ситуация
Продукт с историей в четыре года, приличным объёмом кода и микросервисной архитектурой. В какой-то момент рук на команде перестало хватать, а нанять вовремя не получилось — рынок, бюджет, обычная история. Руководство приняло логичное на первый взгляд решение: закрыть нехватку людей инструментами. И закрывали по-настоящему широко — VS Code с Copilot и ChatGPT для повседневной разработки, Claude Code для более сложных задач, Figma Make, Lovable и v0.dev для экранов и интерфейсов. Каждый занимался своим куском через свой инструмент, координации между ними почти не было.
Со скрипом собрали релиз и выпустили. Почти сразу сломалась авторизация. Выяснилось, что код, написанный за это время, ушёл в прод без автотестов — а CI, рассчитанный на прежний ритм ручной разработки, это пропустил, потому что формально проверять было нечего.
Реакция была тоже вполне логичной: раз тестов нет — поручить написать их ИИ. Но тут вскрылась более глубокая проблема: ИИ физически не мог разобраться, как система должна работать правильно, потому что нигде не было описано, как она должна работать вообще.
Диагноз
Следующим шагом команда попробовала решить проблему её же средствами: скормить ИИ весь исходный код целиком, чтобы он сам собрал документацию. Сожгли огромное количество токенов. На выходе получили один гигантский markdown-файл — действительно впечатляющего размера. Размер и создал ложное чувство полноты: раз файл такой большой, значит, в нём есть всё.
На деле из-за ограничения контекста модель просто молча выбросила примерно половину SQL-таблиц и сущностей — без единого предупреждения, что чего-то не хватает. Бизнес-процессы с несколькими ролями и разными правами доступа, сущности с несколькими стадиями (статусами), операции, привязанные ко времени, — всё это осталось за кадром. Как это оркестрируется между сервисами в микросервисной архитектуре, модель не поняла и ни разу не переспросила, а просто написала то, что смогла собрать из видимого куска контекста, как будто это и есть полная картина.
Именно на эту обрезанную и местами кривую модель предметной области дальше опирались, генерируя автотесты и внося исправления через ИИ. Кульминация случилась несколько недель спустя: в мастер-репозитории на GitLab обнаружилось, что код за последние четыре месяца работы просто пропал. Что реально лежит в мастере и соответствует ли это продакшену — стало совершенно непонятно. Для проекта с четырёхлетней историей это не техническая накладка, а архитектурная катастрофа и, по сути, организационная смерть в моменте: никто не мог с уверенностью сказать, что именно работает в проде прямо сейчас.
Что сделали
Выход нашёлся, хотя и не быстро.
- Начал не с кода, а с людей: устроил опрос команды в формате «кто что помнит» — какие фичи точно доделаны, какие в процессе, какие решения принимались и почему.
- Поднял историю переписки с разными ИИ-инструментами (Copilot, ChatGPT, Claude Code и остальные) — там, вперемешку с обычным диалогом, обнаружились фрагменты кода и решений, которых не было ни в репозитории, ни в той самой «полной» документации.
- Восстановил модель предметной области заново и на этот раз честно: BPMN — для бизнес-процессов с ролями, правами и переходами между статусами; UML, включая Sequence-диаграммы и Use Case — для взаимодействий между микросервисами и сценариев пользователей.
- По каждой фиче и этапу явно зафиксировал степень реализованности — работает полностью, работает частично, является заглушкой, отсутствует. То же самое, что в других подобных случаях оказывается критичным: без этой карты невозможно ни планировать, ни оценивать риски.
- Написал недостающие юнит- и интеграционные тесты — уже не вслепую поверх обрезанной документации, а по восстановленной и проверенной модели.
- Отдельным треком — обучил команду работать с ИИ-инструментами системно: как формулировать промпты, как контролировать объём контекста, чтобы модель не «забывала» половину системы, и, главное, как проверять результат, а не доверять ему по умолчанию только потому, что он выглядит уверенно и подробно.
Результат
Проект вернулся в управляемое состояние: у команды снова есть достоверная карта того, что реализовано, а что нет, восстановленная история кода и документация, которой действительно можно доверять, а не только измерять в мегабайтах. ИИ-инструменты в работе остались — отказываться от них никто не планировал, — но теперь встроены в процесс с проверками, а не заменяют собой архитектурное мышление и код-ревью.
Главный урок этого кейса шире, чем один проект: объём документации и уверенный тон модели — это не то же самое, что полнота и корректность. Чем сложнее система — роли, статусы, время, оркестрация между сервисами, — тем выше цена того, что ИИ молча не уместил в свой контекст и не переспросил.
У вас такая же ситуация?
Давай решим...