Флешбэки адового 2020 года, который в 2026 уже не кажется таким страшным

Спойлер: нет, я не про пандемию

Всем привет! На связи Саша Петрушин, я руковожу группой разработки в центре разработки и машинного обучения компании «Инфосистемы Джет».

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

Дисклеймер: в этой статье – теория, как проект мог измениться в 2026 году. ИИ-агенты — это другие требования к информационной безопасности. Используйте их разумно.

В марте, в разгар локдауна, я пришёл в команду пятым разработчиком: Angular 1.4 с Backbone, переписывание на React, виджеты, 2400+ сценариев подачи заявлений. Потом мы расширили команду до двадцати фронтендеров.

В общем, поностальгировал по команде и ощущению «мы же это реально сделали».

А после задался двумя вопросами.

Как бы я решал ту же задачу сейчас?

И что вообще изменилось в реальной экономике поставки продукта за последние пять с лишним лет?

В 2020 мы, к счастью, знали, куда идти — рабочий личный кабинет со всеми нужными услугами и сценариями. В 2026 более уместные вопросы, сколько стоит проект и кто будет работать.

История из черновика: что было в 2020

По контракту нужно было сделать редизайн личного кабинета, перевести на новую архитектуру 80+ услуг и добавить новые сценарии вроде совместной подачи заявлений — и уложиться в загрузку ≤ 2 сек при 1 Мбит/с. Само собой, не обошлось без унаследованного кода.

Тогда я, полный энтузиазма, клонировал проект из GitLab. Открыл репозиторий — и:

Унаследованный код: два слоя монстра

Слой 1 — оболочка: Angular 1.4, CoffeeScript, Gulp, bower и npm одновременно, karma и protractor. Авторизация, роутинг, часть сервисов вне услуг.

Слой 2 — услуги: ES5, Backbone 0.9.10, без сборщика. Сотни файлов через <script>, порядок подключения критичен — собрать бандл за разумное время не получилось. 80+ услуг описаны JSON в БД: сервер отдаёт модель представления, клиентский движок рисует формы. Документации и тестов нет.

Вся боль в цифрах. На отрисовку одной услуги при обновлении страницы уходило 190+ HTTP-запросов, загрузка занимала около 30 секунд при целевых 2 сек на 1 Мбит/с, а код не был минифицирован.

Но самая большая беда — невозможно оценить объём: при 80+ услугах и 2400+ комбинаций заявителей и предметов стоимость одного виджета в старом коде не выводилась.

Команда владела React. Angular 1.4, и Backbone в прод набирать было некому и незачем. Попытки встроить React в монстра упирались в тот же зоопарк подрядчиков за десять лет.

Что мы сделали в 2020

Сразу поняли: нужна новая архитектура.

Какой стек мы выбрали:

• React + TypeScript — типы, чтобы не ловить баги в проде из‑за опечатки в поле.

• Ant Design + свой UI-kit — не рисовали кнопки с нуля. Одинаковые отступы, ошибки в полях, доступность для длинных форм.

• react-hook-form — одно правило для всех полей: изменил значение -> одно событие onChange с данными, валидностью и именем поля.

• redux-saga — всё «между кликами»: автосохранение черновика, цепочка шагов перед подписью КЭП.

• React Router + ленивая подгрузка — страница и тяжёлые виджеты грузятся по частям.

• Redux «по требованию» — состояние услуги подтягивается только когда пользователь зашёл в сценарий. Иначе тайминг в 2 секунды не удержать.

• REST с заранее согласованным контрактом — до кодинга договорились про поля и эндпоинты.

• Storybook — каждый виджет открывается отдельно: QA без полного сценария, аналитики сверяют вёрстку без деплоя.

• Cypress — на каждый запрос на merge — короткий smoke-тест; полный прогон ~1 ч 40 мин в Jenkins перед релизом.

• Express-мок по OpenAPI — фронт без живого бэкенда; тот же контракт локально и в CI.

• GitLab + Jenkins — без зелёного пайплайна ничего в main не вливали.

Вместо «JSON-движка, который всё рисует сам» сделали три слоя:

1. Виджет — кирпичик формы. Иногда целый блок, иногда одно поле. Сам знает, когда «пикнуть наверх»: данные, валидность, имя в форме. Внутри — поля Ant Design, обёрнутые единообразно.

2. Менеджер виджетов — раскладка: шаги, панели, аккордеоны, галочка «раздел заполнен правильно». Не знает про XML — только отображение.

3. Менеджер сервисов — дирижёр сценария: черновик, сохранение после каждого корректного виджета, предпросмотр, подписание усиленной квалифицированной ЭП (КЭП), упаковка в формат бэкенда, несколько заявителей.

Работа над услугой — комбинация виджетов из каталога, новый виджет при необходимости и конвертер в DTO бэкенда.

Примерно на четыре месяца у команды из пяти человек была задача сделать 2400+ сценариев. Конечно, это не 2400 уникальных экранов, но:

В итоге команду мы расширили до 20 фронтендеров: к пяти стартовым добавилось еще пять из штата и десять подрядчиков на короткий срок (в основном на простые сервисы вокруг личного кабинета).

Тогда мы провели около 40 собеседований, и это было одной из самых тяжёлых и нудных частей всего проекта.

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

Простые сервисы — таблица и один-три эндпоинта — шли отдельным потоком. Спасали те же smoke-тесты на merge: без зелёного CI merge не обсуждали. Ревью свелось к типам против контракта, стилю и наличию теста.

Стек 2026: как бы я решал задачу сейчас

Критерий для крупного проекта с долгой поддержкой: инструмент распространён, у major-версий предсказуемая дорожная карта, людей найти несложно.

Ant Design сознательно не меняю. В 2020 UI-kit снял спор «как выглядит поле в форме». В 2026 Ant Design 5 с токенами даёт редизайн без смены архитектуры виджетов.

Что не беру: экзотические менеджеры состояния, чужой CSS-in-JS поверх дизайн-системы, микрофронты «на каждый виджет» — лишняя сложность поддержки без выигрыша на нашей гранулярности.

Процесс тот же, детали глубже

Спецификация с аналитикой — каталог виджетов в YAML: поля, валидаторы, справочники, матрица обязательности по типам заявителей. Gherkin — на классы поведения (@smoke, @regression), а не на каждую комбинацию из 2400. Связка: id виджета -> story -> тег Playwright.

Контроль на merge — как в 2020: линтер и типы -> unit -> smoke Playwright 3–7 минут -> полный регресс по расписанию (ночью, 15–25 минут с шардированием). Сменился контракт OpenAPI — упали генерация клиента и контрактные тесты (Schemathesis). Один источник правды.

Релизы — еженедельно. Услугу включаем флагом. Если бэкенд не готов — поезд не останавливаем.

Что в экономике проекта меняется кардинально: рой агентов вместо рук

Ну а теперь самое интересное. В 2026 году на всех повторяемых задачах исполнитель — не команда разработчиков, а ИИ-агенты, которые отлично вписываются в конвейер.

Разбор унаследованного кода

Рой агентов с доступом к коду только на чтение; каждый складывает отчёт в свою ветку: граф зависимостей старого <script>, хуки JSON-движка, самые тяжёлые запросы при загрузке, черновик ADR «rewrite / strangler». Те же ripgrep, git и статический анализ — только параллельно. Архитектор подписывает ADR.

Спецификации

Агент делает черновик specs/widgets/*.yaml, опираясь на базу знаний с RAG: нормативные документы, каталог виджетов, ранее согласованные постановки — не на память аналитика и не на поиск по Confluence.

AST-разбор репозитория показывает, какие виджеты и связи уже есть в коде и как старый код мапится на поля. Из этого агент собирает черновик постановки на единицу работ: виджет, UI-kit, валидаторы, граничные случаи.

Аналитик проверяет изменения и подписывает сверку с нормативкой. Агент подсвечивает ломающие правки в типах OpenAPI. 2400 комбинаций — правила в YAML, а не ручной список.

Реализация

Теперь кодом занимаются оркестратор (старший разработчик) и агенты в песочнице. Пример единицы работы:

id: WIDGET-applicant-passport
spec: specs/widgets/applicant-passport.yaml
stack: react-hook-form, zod, ui-kit/PassportFields
DoD:
  - packages/widgets/applicant-passport/*
  - storybook story "default" + "validation-error"
  - vitest: schema + toDto
  - playwright: @smoke applicant-passport.spec.ts
  - bundle: widget chunk < 45kb gzip
autonomy: standard  # MR агента; выборочная проверка человеком
forbidden: crypto, signing, xml-converter-core

autonomy: standard не значит, что код едет в прод без человека. Виджеты из каталога, прошедшие весь CI, человек смотрит выборочно; новый паттерн или красный чек — обязательное ревью. Юридическая ответственность за релиз остаётся на команде.

Агент работает в обвязке с AGENTS.md: структура монорепозитория, импорт только из UI-kit, паттерны Ant Design. В контуре заказчика облачные Cursor/Copilot часто недоступны. В этом случае помогают локальные модели в контуре — они немного дороже и слабее, но схема единиц работы и гейтов та же.

Стандартный виджет — генерация -> тесты -> запрос на merge. Менеджер сервисов, конвертеры, КЭП — проектирует и пишет человек, агент помогает с тестами и шаблоном.

Главный результат: 20-40 параллельных задач в песочнице — как 20 разработчиков на простых задачах, но без 40 душных собеседований.

Качество

Агент генерирует Playwright из Gherkin (@smoke) и Vitest из примеров Zod. Человек дописывает пограничные кейсы: границы дат, пересечение долей, отмена черновика. Шардирование Playwright в GitLab CI: набор, который в 2020 шёл ~1 ч 40 мин в Jenkins, укладывается в 15–25 минут при том же покрытии.

Проверка качества обвязки: 20 репрезентативных услуг + регрессионный diff при смене версии модели — merge блокируется как упавший Jenkins.

Масштабирование простых сервисов

Таблица Ant Design, фильтры, 1–3 эндпоинта — агент по шаблону CRUD в монорепозитории. Раньше это делал подрядчик с нуля; сейчас хватит квоты агентов и одного ревьюера.

Что по-прежнему делает человек

За человеком все равно остаются критичные задачи:

1. Подписание и криптография — браузерные плагины, соответствие требованиям.

2. Конвертеры в XML и доменные правила с юридическими последствиями.

3. Утверждение спецификации в соответствие с нормативными документами.

4. Подписание релиза в прод.

Основной вывод: агент ускоряет набор кода, но не забирает на себя ответственность.

Для наглядности ниже оставил таблицу с отличиями подхода сегодня и 6 лет назад.

Как ИИ меняет структуру затрат

В 2020 профиль бюджета был примерно таким:

• Разработка — главная статья расходов: 5 человек × 4 месяца на виджеты и CI, и не забываем про расширение команды до 20 человек на финальный рывок.

• Аналитика — критичный этап, но разработка часто ждала формализованных постановок.

• QA — сценарии по релизам, автотесты писали разработчики и не всегда успевали до дедлайна.

В 2026 изменились пропорции:

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

  Но самый приятный эффект – ускорение работы. В 2020 на стандартный виджет уходило 2-4 дня разработки. С ИИ срок сокращается до 1-3 часов ревью плюс токены. Это не точные цифры, но порядок уже виден.

• Аналитика / спецификация — узкое место, но теперь единственное. RAG-база и AST снимают рутину поиска и «с нуля в Word», а агенты помогают собрать корректную постановку на единицу работ. Сверку с нормативкой человек не делегирует. Но есть и минусы: теперь ошибка в спецификации касается не одного человека, а умножается на N агентов.

• Обвязка — окупается на N-м виджете, но есть постоянные расходы: токены, поддержка проверок при смене моделей, владелец обвязки. В закрытом контуре — железо под локальные модели.

• QA — дешевле на генерации smoke, но не дешевле на пограничных доменных случаях и приёмке XML/КЭП.

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

Для руководителя разработки KPI смещаются: не «сколько наняли», а «сколько часов аналитики ушло на виджет» и «сколько merge’й прошло без правок по нормативке».

Заключение

С внедрением агентной разработки меняется экономика поставки: разработка перестаёт быть узким горлышком, и на передний план выходят аналитика и качество спецификации. Эффект от искусственного интеллекта приходит, если правильно настроить процесс — спецификации, критерии готовности, песочницу, каталог, UI-kit.

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