Как мы заставили ИИ верстать по спецификациям и сократили время разработки на 45%

Как мы заставили ИИ верстать по спецификациям и сократили время разработки на 45%

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

В финтех-группе «СВОЙ» мы превратили нейросети в реального производственного помощника: научили их работать с легаси-кодом и сложной бизнес-логикой и встроили в повседневные процессы команды.

В результате сократили время выполнения задач до 45%.

Содержание:

Почему мы ушли от «просто чатов» к Spec Driven Development

Классическое использование ИИ через чат быстро упирается в ограничения. Мы для себя выделили четыре основных:

  • лимиты контекста
  • «слепота» к архитектуре и техдолгу
  • отсутствие понимания API-контрактов
  • избыточная автономия (когда агент меняет десятки файлов и оставляет «тихие» ошибки)

Чтобы это решить, мы внедрили Spec Driven Development (SDD).

Суть подхода простая: сначала спецификация, а потом код.

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

По сути, спецификация становится контрактом между человеком и моделью.

Что в нее входит:

  • детерминированный план
  • API Agreement (четкие типы и форматы данных)
  • описание поведения и бизнес-логики
  • контекст: стайлгайды, готовые решения, комментарии
  • ссылки на макеты

Критически важный этап валидация. Исправить спецификацию дешевле, чем потом разбирать 500 строк кода.

Наш стек: «руки» и «мозг» ИИ

Мы используем несколько моделей (Claude, GPT и др.), но важно не это, а то, как мы разделили роли:

  • IDE (например, Cursor) — это «руки»: генерация и работа с кодом
  • LLM в чатах — «мозг»: анализ, архитектура, сложные промпты

Дополнительно используем CLI-инструменты для быстрых итераций.

Такой подход убирает хаос и делает работу с ИИ предсказуемой.

Как мы связали дизайн и код через MCP

Фронтенд без верстки невозможен, поэтому мы внедрили Model Context Protocol (MCP) и подключили его к Figma.

Теперь ИИ «видит» макеты напрямую и может брать параметры без участия разработчика.

Это сильно сокращает количество правок, но не убирает их полностью. Например:

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

Чтобы это контролировать, мы используем:

  • Rules: общий контекст и ограничения
  • Skills: переиспользуемые инструкции

Это делает процесс воспроизводимым.

Безопасность: как мы работаем с данными

В финтехе нельзя просто «скормить» данные модели.

Поэтому у нас жесткое правило: никаких реальных персональных данных во внешних ИИ.

Мы работаем через «слепки»:

  • реальные данные заменяются на моки
  • используются плейсхолдеры вроде {{USER_ACCOUNT_ID}}
  • модель видит структуру, но не содержимое

Все процессы регламентированы и детерминированы.

Как мы проверяем код

После генерации начинается верификация.

Мы используем:

  • Qodo — как независимого ревьюера
  • self-review разработчика
  • автотесты и QA-чеклисты
  • интеграцию с GitLab через MCP

Дополнительно ИИ помогает анализировать логи и искать причины падения метрик — часто быстрее, чем вручную.

Кейс: рефакторинг бонусного счета в CRM

Изначальная оценка задачи - 28 часов:

  • верстка: 10 часов
  • API: 6 часов
  • бизнес-логика: 8 часов
  • тестирование: 4 часа

Что получилось на практике:

MCP + Figma (–50%)

Верстка заняла 5 часов вместо 10. Количество багов по дизайну снизилось на 80%.

SDD и API Agreement (–33%)

API перенесли за 4 часа вместо 6. Ошибки интеграции снизились на 86%.

AI self-review (–37%)

Бизнес-логика: 5 часов вместо 8.

Qodo и автоматизация ревью (–62%)

Тестирование и документация: 1,5 часа вместо 4.

Итог: 15,5 часов вместо 28. Экономия: 12,5 часов (≈45%).

Как мы считаем эффективность

По внутренним метрикам, общий прирост производительности достиг 10–15%.

Чтобы считать это не «на глаз», мы добавили два поля в Jira:

  • Estimated AI Savings — ожидаемая экономия
  • Actual AI Savings — фактическая

Дальше считаем отношение экономии ко времени разработки по разным типам задач.

Что изменилось для разработчиков

ИИ не заменил разработчиков. Он сделал их «пилотами»: теперь нужно управлять системой, а не просто писать код. Требования к экспертизе выросли, но и эффективность тоже.

3 совета командам

  1. Не используйте «голые промпты». Всегда начинайте со спецификации
  2. Дайте ИИ контекст MCP-интеграции (Figma, GitLab и т.д.) — критичны
  3. Сначала стандарты — потом автоматизация. Иначе вы просто ускорите генерацию плохого кода
5
Начать дискуссию