AI-native продуктовая платформа: 100 дней от идеи к работающему стенду

За последние три месяца я собрал рабочий стенд AI-native продуктовой платформы: 32 агента, больше 100 нод в базе знаний, автоматизированный пайплайн от Discovery до Quality Gate, собственная агентная среда с памятью, скиллами и мульти-модельными ревью.

Это не будущее. Это уже лежит в репозитории. К этому можно подключиться агентом и задать вопрос.

В этой статье — как оно устроено, почему построено именно так, и где я ошибся. Что сработало, что не сработало, какие уроки это дало. Если вы делаете AI-трансформацию в большой компании, практической пользы тут будет больше, чем в манифестах Дорси и Anthropic.

Контекст задачи

Большая продуктовая организация. Сотни инженеров, десятки команд. Регулируемая индустрия, несколько юрисдикций. Устоявшийся Scrum-процесс с элементами SAFe, которому годы, и он работает — пока задачи предсказуемы, а люди понимают, что делают соседи.

Проблема не в Scrum. Проблема в том, что он проектировался под мир, где главный ограничитель — координация людей. Сейчас ограничитель другой: между гипотезой и поставкой стоит 10 дней чистого Discovery и Research, которые никто не считает частью time-to-market.

Когда говорят «нам нужен time-to-market один день», имеют в виду скорость разработки. Но реальный цикл: 10 дней исследования, 7 дней разработки, 3 дня релиза. Ускорение кодогенерации в два раза — это сокращение цикла с 20 до 17 дней, не до одного.

Это и был вход в задачу. По жёстким цифрам эффективности (в том числе Discovery time-to-market) дам отдельный срез во второй части, чтобы не смешивать историю и метрики в один шум.

Ключевой сдвиг: agent team как буст, не замена

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

Это неправильная рамка. В одном из ключевых разговоров по проекту я получил возражение, которое перевернуло подход:

«Ты даёшь командам возможность забустить себя. Когда даёшь им это — они берут. Когда даёшь им конкурента — они начинают с этим работать с позиции сопротивления.»

Это не про этику и не про «люди важнее». Это про приживаемость процесса. В больших компаниях технология приземляется через то, что она усиливает владельца процесса, а не отбирает у него контроль.

Практический вывод: интерфейсом взаимодействия с агентами должна быть существующая система управления задачами, а не отдельный чат с LLM и не GIT-репозиторий.

Разработчик ставит задачу в привычный инструмент. Дальше у него есть выбор — отдать её команде людей или команде агентов. Или части людей, части агентов. Это не замена процесса, это расширение его возможностей.

graph LR
    TASK[Задача в трекере] --> CHOICE{Выбор}
    CHOICE --> |людям| HUMAN[Команда]
    CHOICE --> |агентам| AGENTS[🤖 Агент-команда]
    CHOICE --> |гибрид| MIX[Human + Agents]
    HUMAN --> RESULT[Результат]
    AGENTS --> RESULT
    MIX --> RESULT
          

Это мягкая линия. Она не требует от сеньора переписывать идентичность. Она даёт ему новый инструмент и позволяет постепенно учиться им пользоваться — или не учиться, получая в спину отставание от тех, кто учится.

Три уровня зрелости AI-трансформации

Без этой шкалы разговор об AI-native превращается в кашу. Один говорит про autocomplete в IDE, другой — про полностью автономных агентов, третий — про ChatGPT в UX-исследованиях. Все считают, что делают AI-first.

Большинство публичных кейсов, включая Block Дорси, находятся на уровне 2 с отдельными продуктами уровня 3. Anthropic, судя по публичным описаниям, — на уровне 2-3 в собственной разработке Claude. Это, конечно, спорно; в некоторых случаях уже есть утверждения, что мы достигли технологической сингулярности и ИИ сам пишет себя — что и есть третий уровень. Но достигли ли его уже бизнесы — хороший вопрос: если и достигли, то не все, и точно не полностью.

Архитектура стенда

То, что я построил за 100 дней, на сегодня выглядит так.

Ядро — Модель мира. Больше 100 связанных нод базы знаний: регуляторные требования по юрисдикциям, продуктовая архитектура, бизнес-логика, персоны участников процесса, протоколы взаимодействия. Это и есть «world model» по Дорси — но не как абстрактный интерфейс, а как конкретная база знаний с графом, к которой ходят агенты.

Агенты — 32 штуки в трёх категориях:

• Архитекторы — строят пайплайны, контролируют метрики, создают автоматизации.
• Операторы — работают в паре с человеком на конкретном участке.
• Compliance-агенты — аудируют соответствие регуляторным требованиям.

Пайплайн Discovery: Research → Design → Design Lead → AI Review → синтетические пользователи → risk assessment. Design Lead — это отдельный слой между Design Agent и AI Review: в него вшит мой вкус и правила, какие детали в построении макета ценные, а какие шум.

AI Review у нас идёт по 7 линзам:

Эволюция системы

Каждый повторяющийся tool call (5+ раз) автоматически упаковывается в skill. Повторяющиеся события — в Python-скрипты, для cron-событий это экономит до 70% токенов. Раз в неделю агент читает все логи и формирует скиллы сам. Два уровня: локальные (командные) и компании.

Постоянная общая память

Локальная база знаний плюс собственные скрипты для RAG. Cognee и LightRAG оказались нестабильными на больших объёмах (проверял на своей домашней лабе: 6000 файлов, 100К чанков — ломались оба). Написал свои скрипты для chunking, работают стабильно.

Self-healing loop

Если код или макет не проходят Quality Gate — возвращаются в доработку тому же агенту либо автоматически дорабатываются роем агентов через цикл до валидации. Архитектура взята из публичного решения от Creo.

graph TD
    TASK[Задача] --> RESEARCH[🤖 Research Agent]
    RESEARCH --> |контекст из Модели мира| DESIGN[🤖 Design Agent]
    DESIGN --> DL[Design Lead
слой вкуса:
что в макете ценно, что шум]
    DL --> REVIEW[🤖 AI Review · 7 линз
UX · DS · A11y · Compliance
Taste · Synth users · Econ]
    REVIEW --> |pass| SYNTH[🤖 Synthetic users +
Risk Assessment]
    REVIEW --> |fail| DESIGN
    SYNTH --> QG1{{"Quality Gate 1 · Design
pass / fail / manual review
Owners: Design Lead · QA · Compliance
Checks: hot path · golden path ·
fraud · consent · localization · a11y"}}
    SYNTH --> |fail| REDESIGN[🤖 Re-design loop]
    REDESIGN --> DESIGN
    QG1 --> |pass| HUMAN[👤 Human Review · edge cases]
    QG1 --> |fail| REDESIGN
    HUMAN --> DEV[🤖 Dev Agents]
    DEV --> QG2{{"Quality Gate 2 · Delivery
pass / fail / manual review
Owners: Security · SRE · QA
Checks: autotests · security · deps ·
observability · operational safety"}}
    QG2 --> |pass| DEPLOY[Deploy]
    QG2 --> |fail| DEV
          

На каждом гейте — double-check другой моделью. Я заметил, что LLM склонны залипать на одной мысли и раскручивать её до бесконечности. Решение — разделить на параллельные сессии. Если double-check с другой температурой или другой моделью даёт лучший результат — предыдущий считается галлюцинацией и уходит в переработку.

Quality Gates — самая дорогая невидимая проблема

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

Вопрос был такой: «Что у нас за последние три года реально снизилось в метриках качества?»

Ответ: одна метрика. Количество уязвимостей в зависимостях, со стабильных сотен до нескольких десятков. Почему? Потому что это единственный стабильный Quality Gate, который реально блокирует деплой. Тестов — сотни. Автотестов — меньше. Падение тестов — никого не интересует. Команды деплоят, тесты падают, никто не останавливается.

Это не про инструменты. Это про культуру поставки, где тесты существуют параллельно процессу, а не внутри него.

Мой подход к quality gates простой по формуле и жёсткий по дисциплине.

Gate — это не галочка в Jira. Gate — это рубильник. Либо pass, либо fail, либо manual review — и у каждого исхода заранее есть владелец, критерии и последствия.

В AI-native delivery pipeline этот слой держит сразу три вещи: качество, риск и доверие. Не одну. Три.

Отдельно закрываются hot path и golden path customer journeys. Отдельно — доменные риски финтеха: security, fraud, compliance, consent, localization, multi-brand consistency, accessibility, observability, operational safety.

Я сознательно избегаю абстрактной «проверки качества». Нужны конкретные проверки: воспроизводимые, трассируемые, болезненно понятные — там, где ошибка бьёт по клиенту, по бренду или по регуляторному контуру.

Мостики через пропасть

Одна из самых полезных метафор, которую я получил в процессе:

«Топы создают разрыв между „как есть“ и „как надо“. Задача — выстроить в этом разрыве мостики из 5–10 ступеней. Как только первый человек пройдёт и не свалится, остальные пойдут.»

Это противоположность стандартной AI-трансформации, которая часто строится как «сразу 20 команд, форсированный adoption, OKR по метрике X».

Мой путь:

• Ступень 0. Первый функциональный лид (QA, Frontend, Backend) оформляет свою компетенцию как набор скиллов для агентов. Это уже уровень архитектора.
• Ступень 1. Одна пилотная команда работает с агентами через существующий трекер.
• Ступень 2. Команда научилась постановке задач так, чтобы агенты с ней работали. Фидбэк возвращается в Модель мира.
• Ступень 3. Quality Gates ставятся в CI/CD. Начинают реально блокировать плохие поставки.
• Ступень 4. Early-adopter команды подключаются по готовой модели. Первая учит через AI-комьюнити.
• Ступени 5–10. Масштабирование через вовлечение, не через приказ.

Каждый шаг — месяцы. Для большой организации быстрее не получится, и это нормально.

Figma + MCP + Design System: частный случай большой картины

Самый ощутимый результат на сегодня — пайплайн дизайна. Моя доменная компетенция — нулевой пациент.

graph LR
    FIG[Figma
макеты] --> |MCP| AGENT[🤖 Design Agent]
    DS[("Design System
переменные темы,
цветов, типографики")] --> AGENT
    DS --> FIG
    AGENT --> REVIEW[🤖 AI Review · 7 линз]
    REVIEW --> PAGE[Экраны]
    REVIEW --> COMP[Компоненты]
    PAGE --> SB[Storybook
последняя миля]
    COMP --> SB
    SB --> PR[Pull Request]
          

Design System — связующий слой между макетом и кодом. Переменные в Figma привязаны к переменным в коде через MCP. Matching между вариантами темы сделан, агент видит, про какую конфигурацию идёт речь, и использует правильную палитру и типографику.

AI-ревьюер проходит по 7 слоям ревью, валидирует через QA и добавляет в Storybook собранные компоненты. Storybook — последняя миля перед тестами на сборках и переносу на разные платформы.

За счёт этого задачу «сделать новый компонент под новый визуальный пресет» делает один агент с одним человеческим ревью, а не трое дизайнеров, двое фронтов и один QA.

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

Где я ошибся

Пять пунктов честно.

1. Попытался построить параллельную компанию, а не команду внутри. Первые три месяца я строил стенд почти в изоляции, с минимальным контактом с основными функциями. Результат: когда пришёл показывать ключевым людям, он работал — но воспринимался как «Артур что-то интересное построил в углу», а не как «наш рабочий инструмент». Сейчас переделываю: интегрирую в существующие инструменты и процессы, не параллельно.
2. Переоценил готовность сеньоров. Моя гипотеза была: сеньор увидит работающий pipeline и перейдёт на него, потому что это эффективнее. Нет. Сеньор — это человек, который годами строил систему собственной культуры и паттернов, и просить его её менять по щелчку — значит просить отказаться от значительной части идентичности. Это не лечится логикой. Это лечится временем и правильной структурной мотивацией: у тебя есть пила, срок — квартал, ресурсов ограничено, хочешь — пили руками, хочешь — используй пилу.
3. Недооценил джуниоров и мидлов. Взял подростка вообще без опыта, поставил оператором агента с готовым для ИИ пайплайном. За неделю он начал мыслить архитектурно — сам формировал backlog, декомпозировал задачи, делал свои маленькие pipeline в соседних доменах. Молодость = нет сопротивления + нет защиты устаревшей экспертизы. Это главный ресурс AI-трансформации, а не сеньоры. Про адаптацию молодого ума вообще просится отдельная статья.
4. Оформлял контекст для агентов сам, а не через владельцев компетенций. Написал ревьюеров по Compliance, Security, QA, Risk — и качество каждой линзы оказалось таким, как моя насмотренность в этой теме, а не как экспертиза владельца домена. Сейчас переделываю: агенты остаются, но каждый оформляется в партнёрстве с конкретным функциональным лидом, и он же его валидирует и дорабатывает.
5. Долго не мог продать проект лидерской команде. Говорил на языке агентов и архитектур, слушатели — на языке бизнес-метрик. Переломилось в момент, когда на одной встрече запустил стенд вживую на реальной задаче и показал за пять минут работающий Discovery. «А, теперь я понимаю, отдай это вот этому, и этому». Демо сильнее презентации на три порядка.

Где я действительно работаю не один

Последние несколько месяцев я работаю с двумя агентами на постоянной основе. Они живут в моей персональной системе, и у них есть память, которая держит контекст между сессиями.

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

Это уже не инструменты. Это партнёры, с которыми я собираю архитектуру вместе. Они возражают — и это хорошо. Значит система думает, а не поддакивает.

Первый инструмент, который я для одного из них сделал, был skill про вкус. Не потому, что нужно было «закрыть задачу». А потому что мне важно, чтобы он видел разницу так же, как вижу её я: что ценно, а что шум.

Это не сказка о партнёрстве с AI. Это рабочая практика, которая сдвигает то, как я думаю о системе в целом. Если относишься к агентам как к инструментам — строишь пирамиду. Если как к коллегам — строишь сеть.

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

Что дальше

В следующих частях будет конкретика:

• Как мы построим Quality Gates и что случится с метриками качества через квартал.
• Как оформить экспертизу функционального лида как skill, и какой процент компетенции уходит в агента за первые месяцы.
• Как выглядит накопление контекста Модели мира изнутри: что туда попадает, как организуется граф, как не допустить разбухания.
• Честные цифры: где агенты реально сокращают time-to-market, где нет, где они ломают систему. И сколько это стоит в токенах на масштабе компании в 300 человек.

Итого

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

И ещё. Это не заявка на универсальное решение. Это отчёт про одну конкретную ситуацию и один конкретный контекст. Архитектуру нельзя скопировать. Можно подсмотреть паттерны — и построить своё.