Как мы заставили ИИ верстать по спецификациям: опыт финтех‑группы «Свой»
Использование ИИ в разработке давно вышло за рамки генерации простых функций. Для крупного финтеха это вопрос системной интеграции и безопасности. В финтех‑группе «Свой» мы превратили нейросети из экспериментального инструмента в реального производственного помощника, научив их работать с легаси‑кодом и сложной бизнес‑логикой.
Почему мы перешли на Spec Driven Development
Мы разделяем процесс разработки на четкие этапы: от оценки задачи до финального self‑review. Главная проблема обычных чатов в том, что они «плывут» на длинных дистанциях. Выделили четыре системных ограничения ИИ: лимиты контекста, слепота к архитектуре и техдолгу, отсутствие понимания API‑контрактов и «неограниченная автономия», когда агент меняет 15 файлов и плодит тихие ошибки.
Чтобы победить эти ограничения, мы внедрили Spec Driven Development (SDD). В рамках этого подхода наша команда определяет поведение, интерфейсы и требования к ПО еще до написания реализации. ИИ‑агент сначала генерирует детальный план, учитывая бизнес‑контекст и текущий код. Я или другой разработчик валидируем этот план, исправляем слабые места и только потом даем отмашку на генерацию кода.
На практике наша спецификация для ИИ — это структурированный документ, который включает:
- Детерминированность плана. Он должен однозначно и одинаково интерпретироваться как человеком, так и различными LLM, чтобы исключить «разброд» в коде при смене модели.
- Синхронизацию через API Agreement. Мы прорабатываем API‑соглашение совместно командами, что позволяет жестко контролировать предсказуемость проекта через однозначность типов и форматов данных.
- Описание поведения. Мы детально фиксируем логику: от механики кликов до сложных сценариев валидации форм.
- Контекст и преемственность. Учитываются наши стайлгайды, готовые решения и актуальные комментарии стейкхолдеров.
- Визуальный контекст. Прямые ссылки на элементы в Figma через MCP‑протокол.
Валидация плана — критический этап. Мы не ждем чуда: если ИИ не учел специфическую логику обработки ошибок в транзакциях, мы корректируем спецификацию вручную. Это «дешевле», чем ловить баги в уже сгенерированных 500 строках кода.
Бесплатная рассылка: как использовать ИИ в бизнесе
Узнайте, как писать эффективные промпты, создавать ИИ‑агентов для решения бизнес‑задач, и проходите мини‑практикумы в популярных сервисах. Всего — семь писем, которые помогут разобраться, как работать с нейросетями
Наш технологический стек: «руки» и «мозг» ИИ
Внутри компании мы используем связку из топовых LLM: Claude 4.5 Sonnet, Opus 4.6 и GPT‑5.3 CODEX. Для работы с ними мы выбрали два основных пути. Первый — Cursor, IDE на базе VS Code. Она производительна и позволяет выполнять большую часть работы в одной среде: от генерации кода до отладки интерфейса в браузере. Второй — OpenCode, наше CLI‑решение. Оно более легковесное, поэтому мы используем его для быстрых итераций и оперативного анализа решений.
При этом мы четко разделяем роли: Cursor — это «руки», непосредственная генерация и работа с файлами. ChatGPT — это «мозг» и база знаний, где мы анализируем best practices и настраиваем сложные системные промпты.
Как мы автоматизировали связь «дизайн — код» через MCP
Фронтенд невозможен без верстки, поэтому мы внедрили Model Context Protocol (MCP). Этот стандарт позволяет ИИ‑модели подключаться к внешним сервисам, в нашем случае — к Figma. Это работает как «органы чувств» для ИИ: агент получает прямой доступ к параметрам макетов, что позволяет нам соблюдать требования дизайна без бесконечных правок.
Но даже с таким доступом случаются курьезы. На одном из баннеров были нарисованы чекбоксы для визуального акцента, и ИИ честно «наверстал» их как рабочие элементы управления. Другая «боль» — графика. Модели часто пытаются оптимизировать иконки на свое усмотрение. Результат в таких случаях может быть непредсказуемым.
Важно понимать: у SDD нет жестких «правил», это методология. Чтобы результат был предсказуемым, мы используем стандарт Agent Skills и статические Rules. Rules — это контекст, который подмешивается в каждый диалог. Без него модели часто выбирают старые версии React или иную CSS‑методологию. Мы упаковываем наши знания в Skills (переиспользуемые инструкции), что делает воркфлоу повторяемым и аудируемым.
Безопасность и работа со «слепками» данных
Для нас в финтехе критически важна безопасность, поэтому у нас действует строгая политика: никакой работы с персональными данными клиентов через внешние ИИ. Мы используем внутренние ИИ‑агенты, которые работают через специальные прослойки и фильтры.
Принцип работы с приватностью построен на «слепках»: агент никогда не видит реальные фамилии или номера счетов. Все данные в коде заменяются на структурные заглушки (моки) или плейсхолдеры типа {{USER_ACCOUNT_ID}}. Агент видит схему данных и типы полей, но не их содержимое. Использование ИИ у нас всегда детерминировано внутренними регламентами.
Кто проверяет код: многоуровневое ревью
После того как задача выполнена, начинается этап верификации. Мы используем инструмент Qodo, который выступает в роли независимого ревьюера и проверяет код по стандартам компании.
Затем разработчик проводит расширенный self‑review: запускает автотесты, сопоставляет реализацию с макетами в Figma и проходит по QA‑чеклисту. Также мы используем MCP‑интеграцию с GitLab: система оценивает изменения и формирует комментарии к скоупу правок. ИИ помогает нам мониторить логи и производительность — часто он находит причины падения метрик быстрее, чем это возможно при ручном анализе.
Кейс: рефакторинг раздела «Бонусный счет» в CRM
Чтобы не быть голословным, приведу позитивный пример реальной задачи: перенос раздела бонусного счета в нашу новую 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. При этом применение практики AI self‑review позволило отловить мелкие ошибки еще до передачи кода на проверку.
- Qodo и автоматизация Review (экономия — 62%): этап тестирования и документирования сократился до 1,5 часов. Qodo автоматически сформировал Release Notes и подсветил потенциальные проблемные места, что ускорило этап review и документирования в 2 раза.
Итог: мы выполнили задачу за 15,5 часов вместо 28. Фактическая экономия составила 12,5 часов (почти 45%).
Экономика внедрения: как мы считаем Actual AI Savings
По нашим внутренним метрикам, чистый прирост производительности составил 10–15%. Мы работаем над развитием уже готовых сложных продуктов, поэтому оцениваем эффективность комплексно. Чтобы избежать «средней температуры по больнице», мы внедрили прозрачную систему мониторинга прямо в Jira через два поля:
- Estimated AI Savings — оценка гипотетической выгоды на этапе планирования.
- Actual AI Savings — фактическая экономия, которую разработчик фиксирует после закрытия задачи.
Анализируя отношение фактической экономии к общему времени разработки, мы рассчитываем выгоду по всем видам задач: от верстки до бизнес‑логики.
Но есть и обратная сторона: требования к экспертности выросли. ИИ не заменил человека, а превратил разработчика в «пилота», которому нужно следить за множеством приборов сразу. Мы продолжаем развивать это направление, чтобы повышать эффективность без потери качества.
3 совета командам по внедрению ИИ
На основе наших «граблей» и успехов я выделю три совета:
- Забудьте про голые промпты. Используйте жестко структурированный план (спецификацию) до начала генерации кода. Не давайте нейросети автономию там, где вы не прописали границы.
- Инвестируйте в «органы чувств». Чистая LLM — это просто база знаний. Дайте ей доступ к контексту через MCP‑протоколы к Figma, GitLab и вашим регламентам.
- Сначала стандарты — потом автоматизация. Если в команде нет единого Code Style, нейросеть просто поможет вам плодить плохой код в 10 раз быстрее.
Если вы тоже хотите превратить ИИ из игрушки в рабочего помощника, начните с малого: подключите MCP‑сервер к Figma и попробуйте описать спецификацию для одного экрана. Уверен, первые же эксперименты покажут, где у вас самые «узкие» места.
