Четыре провала за четыре года — и четыре человека с AI, которые переписали всё за два месяца

Четыре года мы пытались переписать нашу платформу для проведения IT-соревнований Codenrock. Четыре раза отступали. На пятый — два разработчика, тестировщик и UI-дизайнер справились за два месяца. У каждого — Claude Code на максимальной подписке.

Это история о том, как технический долг накапливает проценты, как мы выбирали стек для новой платформы и что на самом деле значит «80% кода пишет AI».

Что такое Codenrock и зачем нам вообще платформа

Codenrock — это платформа для хакатонов, ML-соревнований, CTF и соревнований по алгоритмическому программированию. Это полноценный продукт с реальными пользователями и реальной нагрузкой: регистрация, треки, задачи, команды, автоматическая проверка решений, рассылки через Kafka, сертификаты. В текущей версии:

• 77 моделей в базе данных;

• 128 API-эндпоинтов;

• 264 React-компонента.

Но так было не всегда.

Диагноз: зоопарк за стеклом

Первая версия платформы Codenrock родилась в 2018 году. Как и положено стартапу, она строилась из того, что было под рукой: Laravel для бэкенда, Blade для шаблонов, Vue для интерактивных кусков. Выбор был оправдан: быстрый старт, быстрый набор фич, проверка гипотез. Никто не знал, куда продукт вырулит. Он формировался по ходу дела.

А потом прошло шесть лет. Vue 2 перестал получать обновления. Пакеты отваливались, и рынок вынудил добавить в стек Vue 3. Переписать накопленный легаси было невозможно, поэтому в одном проекте стали жить четыре способа рендерить интерфейс в одном монолите: Vue 2, Vue 3, jQuery и Blade одновременно.

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

Деплой занимал 40 минут. Docker-образ распух от двойного набора зависимостей: Composer для PHP и npm для фронтенда. Каждый хотфикс — это минимум час ожидания, пока CI/CD прогонит пайплайн и выкатит образ. Когда перед стартом хакатона находился критический баг, этот процесс казался вечностью.

Четыре попытки, четыре провала

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

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

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

Почему пятая попытка сработала

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

Миграцией занималась команда из четырёх человек: два разработчика, тестировщик и UI-дизайнер. У каждого — максимальная подписка на Claude Code. AI-агент стал полноценным инструментом для всей команды:

• разработчики генерировали и ревьюили код;

• тестировщик валидировал критические маршруты;

• дизайнер реализовывал интерфейсы.

Четыре человека с AI делали то, что раньше требовало команды вдвое-втрое больше.

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

Стек выбирали не для себя, а для AI

Это, пожалуй, самый провокационный тезис этой статьи, но мы готовы его отстаивать.

Нам было безразлично — React или Vue, Next.js или Nuxt. Мы выбирали то, с чем AI-агенты генерируют лучший код. И здесь у Next.js на React было объективное преимущество: больше данных в обучающей выборке, более стандартизированные паттерны (App Router), шире экосистема проверенных пакетов с хорошей документацией.

Звучит непривычно? Ещё год назад мы бы сами усмехнулись. Но когда 80% кода в проекте генерирует AI, качество его работы со стеком становится критичнее, чем личные предпочтения разработчика.

Что ещё было в стеке и почему:

Почему не микросервисы

Осознанный выбор. Next.js с API Routes — это тоже монолит, но с другими свойствами: серверный рендеринг, edge-функции, инкрементальная статическая регенерация. Для нашего масштаба и размера команды монолит — это не ругательство, а самая эффективная архитектура.

Zitadel вместо Keycloak

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

Keycloak мы рассматривали, но он показался избыточным: сложная настройка, тяжеловесные сущности. Zitadel — проще, легче, и для нашего масштаба его хватает с запасом.

Prisma после Eloquent

Когда у тебя 77 моделей в базе, ORM становится критичным выбором. Prisma 6 дала нам:

• schema-first подход (одна правда о структуре данных);

• автогенерацию TypeScript-типов;

• поддержку мультисхем в PostgreSQL.

Последнее оказалось важным: мы разнесли данные по схемам: public, geo, contest_library, user_library, contests, gitlab. Это упростило и навигацию, и разграничение доступа.

Потеряли мы привычный Active Record и магию Eloquent-скоупов. Prisma требует более явного написания запросов. Но для AI-агентов явность — это плюс: меньше неявных зависимостей, проще генерировать корректный код.

Как на самом деле выглядит работа с AI-агентом

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

Что AI делает хорошо

CRUD-эндпоинты, маппинги данных, бойлерплейт компонентов, типы, тесты, документация — всё, что имеет чёткий паттерн и примеры в контексте. Когда у тебя есть CLAUDE.md на 500+ строк с описанием архитектуры, примерами кода, матрицей авторизации и паттернами, агент генерирует рабочий код с первого-второго раза.

Конкретный пример: реализация системы рассылок: 14 эндпоинтов, интеграция с Kafka, JSONB-фильтры, шаблоны, статистика. На старой платформе мы бы оценили это в неделю минимум. С AI-агентом заняло меньше дня. Аналогично генерация сертификатов — неделя превратилась в день.

Что AI делает плохо

Скрипты миграции данных из одной базы в другую. Это та задача, где агент не справился, и код приходилось тяжело валидировать вручную. Миграции требуют глубокого понимания и старой, и новой структуры, и всех edge cases в данных — AI-агент видит только то, что ему показали.

Ещё хуже — со сложной бизнес-логикой, где нет чёткого паттерна. Если задача не укладывается в «посмотри на пример A и сделай аналогично для B», качество генерации падает резко.

Как теперь устроен рабочий процесс

Рабочий день разработчика изменился кардинально.

Раньше:

• Пишу код.

• Снова пишу код.

• Ещё пишу немного кода.

• Делаю ревью чужого кода.

• Пишу код.

Теперь:

• Проектирую архитектуру и пишу спецификацию.

• Формулирую задачу для AI-агента.

• Делаю ревью сгенерированного кода.

• Корректирую и дополняю.

• Интеграционное тестирование.

Главный скилл сместился: не писать код, а читать его и правильно формулировать запрос. По-прежнему критично понимание архитектуры, устройства веба, инфраструктуры, слабых мест. А вот набор кода руками — нет.

CLAUDE.md — онбординг для AI

Одна из самых полезных практик, которую мы выработали: подробный файл контекста для AI-агента. Наш CLAUDE.md содержит:

• Структуру проекта с описанием каждой директории.

• Примеры существующих API-эндпоинтов с паттернами.

• Матрицу авторизации: какой эндпоинт, какой уровень доступа.

• Примеры кода для типовых операций.

• Чек-лист качества — что проверять перед коммитом.

• Список запрещённых практик.

По сути — тот же онбординг-документ, который вы бы написали для нового сотрудника, только адаптированный для AI. Чем подробнее контекст, тем точнее генерация. Рекомендую всем, кто работает с AI-ассистентами.

Про «80% кода пишет AI»

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

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

Миграция данных: 20 минут, 20 часов и один JSON-файл

Миграция базы данных — традиционно самая страшная часть любого переезда. У нас были таблицы и с сотнями тысяч, и с несколькими миллионами записей.

Что оказалось простым

Сама перекачка данных из MySQL в PostgreSQL. Скрипты с двойным подключением одновременно к MySQL и к PostgreSQL, разбитые на несколько десятков этапов. Каждый этап — одна или несколько тесно связанных таблиц. Порядок этапов выстроен так, чтобы не нарушать внешние ключи. Вся база перекачалась за 20 минут.

ID: из инкрементальных int в UUID

В MySQL у нас были автоинкрементальные целочисленные ключи. В PostgreSQL мы перешли на UUID. Для того чтобы скрипты были идемпотентными и их можно безопасно перезапустить в случае сбоя, нам нужен был маппинг старых ID на новые UUID.

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

Что оказалось сложным

Миграция пользователей в Zitadel. Раньше пароли и сессии жили в нашей MySQL. Теперь аутентификация происходит в отдельном сервисе, и перенести пользователей «дампом» нельзя: нужно было создавать каждого через API. Этот этап занял несколько часов из-за скорости API — тысячи пользователей, по одному запросу на каждого.

Скрипты миграции мы запускали не с локальных машин, а прямо в том же Kubernetes-кластере, где живёт всё остальное. Минимальная сетевая задержка до Zitadel и баз данных, плюс независимость от локального интернета.

Даунтайм

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

Результаты: что измерили

Производительность

PageSpeed Insights показал рост показателей в 2–3 раза по сравнению со старой платформой. Серверный рендеринг Next.js и отсутствие зоопарка фронтенд-фреймворков сделали своё дело. Поисковые роботы стали видеть контент — SEO улучшился сразу.

Скорость разработки

Конкретные примеры:

• Система рассылок. API-эндпоинты, Kafka, фильтры в базе, шаблоны сообщений — задача, которую раньше закладывали почти на неделю, фактически была сделана меньше чем за день.

• Генерация сертификатов. Ранее оценивалась в несколько дней, на практике реализована в течение одного дня.

• Типовой CRUD-эндпоинт с проверками доступа и тестами: несколько часов вместо дня.

Деплой

Время сборки и деплоя сократилось в разы. Один пакетный менеджер вместо двух, чистый Docker-образ, отсутствие PHP-зависимостей.

Что стало хуже

Потеряли Laravel «batteries included». Laravel из коробки даёт очереди, рассылки, уведомления, шедулер — всё готовое. В Next.js каждую такую вещь нужно собирать руками или подключать внешний сервис. Kafka вместо Laravel Queues, отдельный сервис для почты вместо встроенного Mail — инфраструктура стала сложнее, хоть и гибче.

Зависимость от AI-инструмента. Мы завязаны на качество Claude Code. Если завтра он деградирует — скорость разработки упадёт. Хотя инструмент можно заменить — рынок растёт быстро, да и по качеству тоже тренд растущий.

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

Инфраструктура

Вся инфраструктура живёт в Яндекс Облаке:

• Managed Kubernetes — оркестрация. Старая и новая версии — в одном кластере, разные namespace'ы.

• Managed PostgreSQL — база данных.

• Kafka — шина данных между сервисами (рассылки, уведомления).

• Redis — кэширование. Только кэширование — очереди ушли в Kafka.

• S3-совместимое хранилище — файлы.

• Горизонтальное масштабирование реализовано через HPA (Horizontal Pod Autoscaler) в Kubernetes и автоскейлер нод на уровне облака.

Важный момент: старая и новая версии платформы жили в одном кластере. Это упростило переходный период — общие шины данных, общие внешние сервисы (компилятор кода, Kafka). Переключение прошло бесшовно.

Что дальше

Мы запустили платформу, но это начало, а не конец.

• AI в продукте. Мы планируем внедрить AI-ассистентов для участников хакатонов — помощь в создании проектов прямо на платформе. Встроенные песочницы с AI, автоматическая проверка решений — не только кода, но и идей.

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

• AI-оценка решений. Субъективная? Да. Зависящая от промптов? Безусловно. Но с точки зрения честности — ничуть не хуже оценки жюри. AI не заменит объективные метрики (время выполнения кода, accuracy ML-модели), но прекрасно заменит человека, которому нужно прочитать 200 проектов за два дня.

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

Вместо заключения: что бы мы посоветовали

Если вы сидите на легаси и думаете о миграции — вот что мы поняли за четыре провала и один успех:

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

• Выбирайте момент. Четыре наших провала случились не потому, что мы плохо старались. Технологии не были готовы, ресурсов не хватало. Пятая попытка сработала, потому что совпали три фактора: AI-агенты созрели, наступил сезон низкой активности, а мы перестали пытаться переписать всё, и сразу подготовили MVP и запустили.

• Документируйте для AI. CLAUDE.md (или аналог для вашего инструмента). Это инвестиция, которая окупается с первого дня. Напишите онбординг для AI так же серьёзно, как написали бы для нового сотрудника.

• Не ждите идеала. Веб-сервисы и мобильные приложения никогда не будут идеальными. Рынок и мир всегда подкинут новые вызовы. Запускайте MVP, итерируйте, не останавливайтесь.