Родион, руководитель отдела по анализу данных в Лаборатории данных компании «Синимекс», опубликовал на Хабре ретроспективу: как в компании больше трёх лет пробовали встроить разработку с помощью ИИ в реальные проекты и почему в итоге пришли к Spec-Driven — подходу, где сначала пишется спецификация, а код генерируется последним шагом. Материал заявлен примерно на десять минут чтения и построен по годам: 2023, 2024, 2025, 2026.
Ценность текста не в описании Spec-Driven — о нём написано много. Ценность в том, что показана дорога к нему: пять-шесть внутренних кейсов, из которых половина не взлетела, и причины, по которым они не взлетели, названы прямо. Там есть и история с хорошими ML-метриками, которые пользователи отказались принимать, и пилот, умерший на попытке масштабирования, и опрос сотрудников, показавший, что ассистенты кода у разработчиков почти не прижились.
Ниже — содержание материала по смысловым блокам: что именно пробовали, какие цифры приводит автор, к каким выводам он приходит и в чём, по его версии, состоит переход от «добавим немного ML» к инженерному контуру вокруг модели.
2023: метрики выросли, а работа людей — нет
Первый подход компания сделала в 2023 году, когда LLM только начали набирать популярность. Автор описывает три кейса этого периода.
CDT (Cinimex Development Tool). Гипотеза строилась на том, что у заказчиков лежат горы технических заданий — объёмных, разношёрстных по структуре и стилю, — а аналитики тратят часы на то, чтобы вытащить оттуда требования и сущности. Задачу решали подходом NER (Named Entity Recognition, распознавание именованных сущностей): модель учили выделять требования и находить ключевые сущности в тексте ТЗ. Собрали выборку заданий разного качества, разметили её, провели несколько десятков экспериментов.
Внутренние тесты дали ROC-AUC 0.7 и F1 0.61. Автор оценивает это как «не вау, но кое-что» и описывает реакцию целевой аудитории — аналитиков и архитекторов. Их возражение он приводит цитатой: если система ошибается хотя бы в двадцати процентах случаев, результат всё равно приходится перепроверять целиком вручную, а значит практической ценности почти нет. Пользователи не разбирались в ML-метриках; их критерий был другим — можно ли принять ответ без полной ручной проверки.
Отсюда первый вывод материала: качество AI-функции измеряется не только качеством ответа модели, но и стоимостью проверки этого ответа человеком.
CTT (Cinimex Test Tool). К следующему продукту зашли уже с генеративной стороны и с опорой на разговор с будущими пользователями — тестировщиками. Провели брейнштормы, отобрали сценарии по бизнес-ценности и реалистичности, собрали прототип на открытых моделях и ChatGPT, подготовили документы на согласование. Прототип работал, тесты генерировались, но затраты на развитие перевесили ценность — проект не получил продолжения.
Ассистент по базе знаний. Третий кейс — цифровой ассистент для первой и второй линий поддержки банка из топ-20, которые тонули во внутренних регламентах. Начали с PoC на нормативной документации из открытых источников, затем перешли к MVP на реальных данных: собрали внутренние инструкции и нормативные акты одного подразделения, дообучили модель и отдали сотрудникам. Автор отмечает, что по сути это была классическая RAG-система ещё до того, как такие решения стали массовыми. Подразделение системой пользовалось, инициатор проекта сказал «работает» — но соседние подразделения ответили «нам оно зачем?», и пилот остановился.
Итог года в формулировке автора: хорошие метрики не равны ценности готового решения, а успешный пилот не доказывает масштабируемость сценария.
2024: первый работающий инструмент и расползание практик
В 2024-м направление поиска сместилось к самой разработке.
Нишевые языки. Компания взялась за инструмент генерации кода на RPGLE и COBOL, встроенный прямо в IDE. Логика проблемы: специалистов по этим языкам становится меньше, а системы на них живут и требуют поддержки. От инструмента хотели автокомплит, генерацию кода, помощь с тестами и возможность дообучать модель под конкретный проект. Проанализировали доступные на тот момент LLM, собрали датасет для дообучения — источниками названы репозитории GitHub с RPGLE, датасет The Stack v2 и внутренние репозитории GitLab «Синимекса», — и отработали методику дообучения.
Это первый кейс в тексте, которым автор доволен: получился полноценный Proof of Concept, модель встроилась в IDE и начала помогать разработчикам.
AI-стратегия. Параллельно вскрылась организационная проблема. Компания большая, команд много, каждая использовала ИИ по-своему: кто-то ChatGPT, кто-то GitHub Copilot, кто-то локальные модели, кто-то ничего. Пока это эксперименты — терпимо, но код проектов принадлежит заказчикам, а в репозиториях лежит коммерческая информация, поэтому вести боевую разработку в публичных сервисах нельзя.
Провели внутренний опрос. Автор приводит срез по своему подразделению — Лаборатории данных: 69% сотрудников видели пользу в LLM, 45% использовали их еженедельно. Основные сценарии — копирайт, брейншторм, ресёрч. Неожиданным оказалось другое: ассистенты кода работали плохо, усреднённый опыт сводился к «попробовал несколько раз». Позицию разработчиков автор передаёт их же словами — пишет код на уровне джуна, проще написать самому, чем разбираться, что сгенерировала модель.
Вывод года: adoption уже начался, но без централизованного управления, и набор инструментов, сценарии и правила у команд различались.
2025: постановка задачи оказалась сложнее архитектуры
ИИ-тренер для поддержки продаж. Задача 2025 года была далека от кода: прокачать коммуникативные навыки торговых представителей. Сделали виртуального клиента, который ведёт диалог от приветствия до финальной договорённости, возражает, проверяет аргументы, а после разговора разбирает ошибки.
Продукт дошёл до MVP с измеримыми KPI: частота офферов у консультантов растёт минимум на 15%, конверсия из оффера в пилот — минимум на 20%. Автор подчёркивает, что здесь впервые заговорили не об ощущении пользы, а о бизнес-метриках.
Гладко не было: архитектуру переписывали несколько раз, потому что модели обновлялись быстрее, чем собиралось решение. Но когда проблемы отранжировали, архитектура оказалась лишь на третьем месте. Второе занял RAG, первое — тюнинг промптов. Качество диалога определяла не столько модель под капотом, сколько точность описания роли тренера, правил возражений и формата разбора ошибок. Поменять модель или пересобрать архитектуру оказалось проще, чем точно сформулировать задачу.
1С. Второй кейс года — агентская разработка в экосистеме, кодовой базы которой нет на GitHub. Автор пишет, что был удивлён наличию у 1С современных инструментов: механизм EDT (Enterprise Development Tools), открывающий агенту структуру проекта, исходный код и инженерный контекст, и интеграция через MCP, превращающая агента из чата в участника процесса разработки. Подробности этого кейса он оставляет отдельной публикации коллеги.
Вывод 2025 года: генерация сама по себе перестала быть дефицитом, ценность сместилась в качество постановки задачи, контекст и правила работы агента.
2026: разработка с помощью ИИ глазами самих инженеров
К 2026 году ИИ в компании стал частью повседневной работы, и автор приводит несколько реплик коллег разных ролей и грейдов:
- LLM сильный обманщик, но для опытного разработчика — хороший помощник.
- У системного аналитика время на подготовку High-level Design одной фичи снизилось в 1.5–2 раза; написание ТЗ, формулирование требований и диаграммы стали занимать заметно меньше времени, а самой сложной частью работы становится сбор правильного контекста у стейкхолдеров.
- На ревью кода LLM выявляет уязвимости, время ревью существенно сократилось, качество замечаний адекватное.
- Небольшие проекты можно делать в соло.
Отдельно автор проговаривает позицию по вайб-кодингу: подход не отрицается, но в чистом виде годится для прототипирования, где цена ошибки — переделка. В боевом проекте издержки на отладку и поддержку несоразмерны выигрышу от быстрой генерации.
Spec-Driven: спецификация вместо одноразового промпта
Три вывода, к которым компания пришла к 2026 году, автор сводит воедино: результат зависит от точности постановки задачи (показал ранжированный список проблем на ИИ-тренере); агенту нужен контекст проекта, а не текстовое поле (подтвердила практика с 1С); массовое использование без общего инженерного контура фрагментарно и плохо масштабируется (показал опрос).
Общая идея: постановка задачи, контекст и правила должны перестать быть одноразовыми промптами и стать артефактами проекта. Код при этом перестаёт быть основным активом разработки — чем дешевле его генерация и переработка, тем выше цена формализованных требований, ограничений и архитектурных решений. Архитектура, спецификация и стратегия реализации остаются за инженером, а генерация кода превращается в последний шаг.
Разницу между подходами автор показывает на примере сервиса загрузки документов. В prompt-driven разработчик пишет агенту задачу текстом. В Spec-Driven сначала фиксируются роли, ограничения, NFR (нефункциональные требования), интерфейсы и acceptance criteria, и уже внутри этого набора артефактов работает агент.
Цепочка, которую применяют в компании, состоит из шести шагов:
| Шаг | Что делают | Артефакты |
|---|---|---|
| 1. Определить миссию | Превращают запрос в ТЗ (PRD): цели, пользователи, ограничения, риски | ТЗ в Markdown, диаграмма целей в PlantUML, spec/mission.md |
| 2. Сформулировать правила | Паспорт проекта: принципы, NFR, бизнес-правила | spec/spec.yaml, таблица требований, список must-have |
| 3. Допущения и ограничения | Исследуют инструменты и архитектуры, собирают контекст | Таблица сравнения, список рисков |
| 4. Пересмотр плана | Архитектурный review: стресс-тест допущений, поиск дыр в дизайне | Диаграмма архитектуры, чек-лист |
| 5. Критика | Ищут недостающие требования, уточняют метрики валидации | Red-team-отчёт, список доработок |
| 6. Генерация кода | Передают собранный контекст агенту или LLM | Код, Docker-образ, .gitlab-ci.yml |
К каждому шагу в оригинале привязаны контрольные вопросы: кто потребляет результат и какие бизнес-риски критичны; какие условия должны выполняться при любом способе реализации; какие технологии укладываются в ограничения вроде on-prem, NDA или 1С; какие сценарии нарушают спецификацию; какие требования скрыты в бизнес-процессе; как убедиться, что код соответствует спецификации.
Автор оговаривает, что цепочка не единственно возможная и зависит от инструмента. В качестве примера он называет открытый фреймворк Spec Kit, где та же логика упакована в команды: /speckit-constitution — определить миссию, /speckit-specify — собрать структурированную спецификацию из словесного описания, /speckit-plan — построить план и провести исследования, /speckit-tasks — разбить план на задачи, /speckit-clarify — проверить документы на непротиворечивость, целостность и недоопределённость. Принцип один: сначала спецификация, потом код.
Финальная рифма материала — к истории 2023 года. Вайб-кодинг без инженерного контура, по мысли автора, превращает каждого разработчика в того самого аналитика, который отказался проверять чужие ошибки: вместо написания кода он делает ревью сгенерированного, и отладка съедает больше времени, чем экономит генерация.
Коротко
- Хорошие ML-метрики не означают пользу: при ROC-AUC 0.7 и F1 0.61 на разборе техзаданий аналитики отказались от инструмента, потому что результат всё равно требовал полной ручной перепроверки.
- Успешный пилот не доказывает масштабируемость: ассистент по базе знаний прижился в одном подразделении банка и остановился на вопросе соседних — «нам оно зачем?».
- Первый результат, которым в компании довольны, — дообученная модель для RPGLE и COBOL, встроенная в IDE: ниша, где дефицит людей очевиден, а помощь измерима.
- На проекте ИИ-тренера главной проблемой оказался не выбор модели и не архитектура, а тюнинг промптов — точность постановки задачи.
- Вывод к 2026 году: требования, ограничения и правила должны стать артефактами проекта, а генерация кода — последним шагом цепочки, а не её началом.
Что из этого следует
Материал полезнее всего тем, кто уже прошёл стадию «попробовали, вроде работает» и упёрся в вопрос, почему при живых пилотах ничего не меняется в процессе. Главная мысль ретроспективы прикладная: оценивать ИИ-функцию нужно не точностью модели, а сокращением общего времени работы человека, включая проверку. Этот критерий легко проверить у себя — достаточно замерить, сколько времени уходит на ревью сгенерированного результата, и сравнить с временем ручной работы без модели.
Ограничение у текста естественное: это опыт одной сервисной компании на энтерпрайз-проектах, где код принадлежит заказчику, данные закрыты, а часть стека приходится на 1С и легаси-языки. Цифры по KPI ИИ-тренера приведены как показатели MVP, и условий их измерения в материале нет — переносить «+15% офферов» на свою задачу нельзя. Опрос — срез по одному подразделению, а не отраслевая статистика.
Spec-Driven в изложении автора — не новая технология, а способ зафиксировать то, что раньше жило в одноразовых промптах и головах. Проверять стоит именно это: существуют ли у вас требования и ограничения в виде файлов, которые можно отдать агенту вместе с задачей, или контекст каждый раз собирается заново в чате. Если второе — описанный путь объясняет, почему результат нестабилен.
Для команды, которая хочет попробовать подход без перестройки процесса, есть недорогой вход: взять одну ближайшую фичу, написать для неё спецификацию с ролями, нефункциональными требованиями и критериями приёмки, и только после этого пустить агента. Сравнение с обычным prompt-driven заходом на соседней фиче покажет, стоит ли разворачивать цепочку целиком.
Источник: Как мы 3+ года пытались подружить AI с разработкой: от провалов к Spec-Driven