Спойлер: архитектура AIналитика полностью переписана, теперь Платформу можно запускать практически под любым харнесом (OpenCode, Kodik, Codex, Claude Code), а также подключать любые LLM, включая локальные. Добавлено/в разработке много новых фич: многоагентная система, доска навигации и дашборд для тимлидов.

Пару месяцев назад я опубликовал на Хабре статью «Как я научил Claude Code работать бизнес-аналитиком по руководству BABOK. Вот что получилось». Коротко, я разработал AI Платформу AIналитик - ai-ассистента, который работает рядом с бизнес-аналитиком, как опытный коллега. Он знает методологию BABOK v3 и ведёт BA по проекту, может: спланировать, подготовить интервью, собрать требования, провести трассировку, приоритизировать, оценить риски и изменения. Покрыты все задачи пяти областей знаний, главы с 3 по 7, за исключением 8-ой.

Исходный код AIналитика v1 на Github. Канал с новостями проекта AI Платформа AIналитик.

Идея первой версии AIналитика умещалась в одно слово: рельсы. Бизнес-аналитик перемещается по проекту, как трамвай по рельсам. Платформа не даёт свернуть в сторону и начать творить отсебятину, пропустить шаг или забыть про дедлайны. Бизнес аналитик с Платформой выполняет задачи так, как это рекомендует методология BABOK. Пользователь общается с AIналитиком человеческими словами, никаких специальных команд знать не надо. Платформа подсказывает следующий ход и берет на себя всю рутину.

Что это даёт бизнесу, кратко в трёх пунктах:

AIналитик искусственно бустит грейд бизнес-аналитика. Джуниор с платформой работает по методологии как мидл. Повышается эффективность. Та же команда бизнес-аналитиков может выполнять больше задач за то же время, при этом качество не проседает. Вы управляетесь со всеми своими задачами теми человеческими ресурсами, которые у вас в наличии.
Знания о проекте не утекают вместе с человеком. Каждый шаг BA на проекте падает в структурированные артефакты. BA уволился, заболел, ушёл в отпуск? Контекст остался в проекте. Онбординг нового BA в действующий проект сокращается с недель до часов. Снижается вероятность косяков, связанных с тем, что новый бизнес-аналитик что-то упустит, не заметит или не обратит внимания. Снимаются трения, которые возникают из-за того, что новому бизнес-аналитику приходиться лишний раз дергать коллег, и что еще хуже - внешних стейкхолдеров, чтобы что-то там уточнить.
Значительно уменьшаются трудозатраты на change request. Прилетело от стейкхолдера «давай по-быстрому добавим вот это…»: платформа за секунды покажет, какие требования, тесты и решения новое требование стейкхолдера затронет. То, что обычно вылезает только в разработке, с AIналитиком видно сразу. Бизнес-аналитик без временных затрат получает на руки конкретные аргументы для обоснования, например, того, что “по-быстрому” это не получится, которые он может использовать в переговорах со стейкхолдерами.

Если это все редуцировать до одного короткого поинта, то AIналитик повышает эффективность и уменьшает количество конфликтных ситуаций.

Это была первая версия. Работала, но по объективным причинам быстро упёрлась в потолок. За пару месяцев я переписал AIналитика полностью: изменил архитектуру, применил агентский подход, добавил новые важные фичи.

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

Узкое место: 21 MCP-сервер

Первая версия жила внутри Claude Code, терминального AI-агента от Anthropic. Аналитические операции выполняли инструменты, оформленные в виде MCP-серверов. Их было 21 (плюс один для конфлюенса), и все загружались в контекстное окно модели одновременно, на всю сессию.

Контекстное окно конечно. Чем плотнее оно забито, тем выше риск, что LLM начнёт ошибаться и галлюцинировать. На длинной сессии с большими транскриптами этот риск более чем вероятен.

Решал я это фазами. Делил инструменты на пять наборов по областям BABOK и загружал только один набор за раз. Память разгрузилась, но появился неприятный побочный эффект. За фазой нужно следить, а после переключения давать команду /restart, иначе инструменты не перезагрузятся. Подробно это всё описано в первой статье.

И тут вот в чём загвоздка. Я хотел построить платформу, чтобы бизнес-аналитик вообще не загружал свою голову техническими моментами. Но ему всё равно приходилось держать в голове: какая сейчас фаза, не забыл ли дать команду/restart. Это была мелочь, которая ломала саму идею. И не давала мне покоя.

Обратная связь, которая всё развернула

После публикации пошла обратная связь. И она сложилась в три повторяющихся сигнала.

Первый, Claude в России это боль. Первая версия завязана на модель Claude от Anthropic. Для российской аудитории это необходимость в VPN, сложная оплата подписки с использованием серых схем и рисков блокировки аккаунтов на ровном месте. Говорили прямо, что идея отличная, но пользоваться неудобно из-за самой модели.

Второй, это требования к безопасности. Регламенты работы крупных компаний требуют, чтобы никакие документы не отправлялись на обработку стороннему облаку. Данные не должны выходить за пределы контура компании в принципе. Точка. Таким компаниям для запуска AIналитика нужна локальная модель, чтобы ни одна строка не ушла на сторону.

Третий, страшно переходить на AIналитика в середине действующего проекта. Идея нравится, но переход пугает. Проект идёт уже давно, артефакты частично собраны, и как в рабочий процесс встроить AIналитика, непонятно. Говорили примерно так, на новом проекте попробуем с радостью, а середину текущего ломать тревожно.

Опасения разные, но корень у них один. Первая версия была жёстко привязана к одной модели Claude и к одному харнесу (Claude Code). Но бизнесы и компании разные. И контекст и ограничения у всех свои. Вывод напросился сам: платформа должна подстраиваться под компании, а не наоборот.

Какие решения я принял

Уйти от MCP к обычным CLI-скриптам. Вместо 21 MCP сервера я использовал CLI скрипты. Агент вызывает нужный скрипт ровно тогда, когда тот нужен. Отработал, вернул результат, освободил память. Как приятный побочный эффект исчезает необходимость в фазах и их переключении, и команде /restart.

Отвязаться от Claude Code. Раз Claude отпугивает часть людей, нельзя оставаться к нему привязанным. CLI-скрипты тем и хороши, что их может запускать почти любая AI-обвязка. Такие обвязки называют харнесами, их на рынке десятки. Я взял несколько ориентиров, у каждого из них своя роль:

OpenCode: открытый харнес, работает с любой моделью, включая локальные. Ответ на первый и второй сигналы разом.
Kodik: российская разработка, большой выбор моделей, и что самое приятное это оплата подписок рублями, без VPN и возни с зарубежными картами. Кроме того, к нему также можно подключать локальные модели.
Codex: консольный агент от OpenAI. Технически он лишний (модели OpenAI есть и в первых двух), это больше реверанс в сторону фанатов экосистемы OpenAI.

Я специально спроектировал архитектуру AIналитика так, чтобы было можно подключать любые харнесы и работать с любыми моделями, и при необходимости в будущем спокойно расширяться без изнурительного рефакторинга, как это у меня произошло при переходе от MCP серверов к CLI скриптам. Так что архитектура у AIналитик сейчас продвинутая - такая, что по запросу могу быстро подключить почти любую обвязку с рынка: Cline, Roo Code, Kilo Code, Qwen Code, Aider, Antigravity CLI. Не знаю, зачем они вам, так как все боли закрываются основными тремя, но мало ли. Пишите, сделаю! 😉

Возможность перейти на AIналитика в любой момент проекта. Чтобы снять опасения, что «коней на переправе не меняют», Платформа в новой версии должна уметь подхватить проект на любой стадии. Это реализовано с помощью Доски (отдельный разговор ниже). AIналитик с помощью этой фичи читает уже готовые ваши артефакты и сам вычисляет, на какой стадии по BABOK вы находитесь.

Доска: рельсы, которые наконец видно

Моя любимая часть второй версии.

BABOK большой. Шесть областей (у нас реализовано пять, кроме последней), в каждой по несколько задач, и они сцеплены: выход одной идёт на вход другой. Удержать эту карту в голове на длинном проекте очень трудно. Раньше рельсы были, но невидимые. Бизнес-аналитик, общаясь в чате, чувствовал направление, но всей дороги не видел.

Доска делает рельсы видимыми. Внешне она напоминает канбан: этапы BABOK по колонкам. Видно три вещи: где вы сейчас, какой шаг следующий, какие артефакты готовить.

Переход на AIналитика в любой точке проекта

Вы можете загрузить все артефакты, которые у вас накопились в проекте. Доска все подхватит и быстро определит ваше положение на оси BABOK. Вы наглядно увидите, где находитесь: какой путь пройден, какие задачи пропущены, какие артефакты нужно сделать. Получите рекомендации по следующим шагам.

Обратные петли BABOK

Место, где Доска по-настоящему выручает. Граф переходов в BABOK запутанный. Иногда выход поздней задачи оказывается входом для ранней. Пример: выход задачи 6.1 «Анализ текущего состояния» идёт в том числе на вход ранним задачам 3.2 и 3.3. То есть поработали над стратегией, будьте добры вернуться и поправить артефакты планирования, которые считали закрытыми ещё месяц назад. На память такие обратные петли отслеживать очень затратно, и они становятся пробелами в проекте. На Доске же все переходы зашиты и подсвечены: она сама мягко напомнит, что пора вернуться и подправить ранние артефакты.

Два режима и кнопки-подсказки

У Доски реализовано два режима: ведомый и экспертный. В экспертном доска деликатна, подсказывает, но не давит. Предполагается, что эксперт отдает отчет своим действиям. В ведомом режиме рельсы жёстче, подсказок больше. На каждой карточке (в обоих режимах) есть две кнопки. «Что дальше?» - отвечает, куда вести проект по графу. «Как лучше?» - даёт методический совет по текущей задаче. Спросить можно на любом шаге.

Запустить Доску можно в виде вебприложения. Кроме того Доска может жить прямо в редакторе кода VS Code и любого его форка, а их сейчас много, например, Cursor. Панель только навигирует, работу делает субагент-аналитик.

Сводки и дашборды: картина без статус-отчётов

Доска это вид бизнес аналитика: один проект, его рельсы, его следующий шаг. Но у работы есть и другой угол: не «где я иду», а «здоров ли проект в целом» и «что происходит сразу во всех». Обычно ради этой картины бизнес-аналитиков сажают писать статус-отчёты. Работа ради работы, которую все тихо ненавидят.

Здесь она не нужна. Каждый шаг аналитика и так падает в структурированные артефакты, а сводку платформа собирает из них сама, по запросу. Отдельный отчёт никто не пишет. Картина складывается из уже сделанной работы. И ещё важная мелочь: сводки только читают, ничего не меняют, поэтому запросить их можно в любой момент, ничего не боясь сломать.

Сводки по проекту

Это готовые срезы, каждый отвечает на свой управленческий вопрос:

Покрытие. Какие бизнес-цели уже закрыты требованиями, а где дыры. Какие требования висят без источника или без проверки. То, что обычно всплывает только на демо, видно заранее.
Здоровье реестра требований. Где копится мусор: что меняли слишком часто (признак нестабильности), что давно не трогали, что застряло в черновике.
Готовность к согласованию. Можно ли уже фиксировать требования: кто из стейкхолдеров одобрил, кто условно, кто молчит, какие условия просрочены. Вместо «вроде уже можно» чёткий вердикт.
Матрица рисков. Профиль риска по зонам, основа для разговора со спонсором: двигаться ли дальше и на каких условиях.
Сравнение вариантов. Варианты решения и их оценки бок о бок, чтобы выбор защищался данными, а не мнением.

Бизнес-аналитик не верстает эти отчёты руками. Он просит сводку, платформа считает её по текущему состоянию и отдаёт готовый документ, который можно тут же показать стейкхолдеру или спонсору. А если команда использует Confluence, артефакт можно одной командой опубликовать прямо туда, в корпоративную вики.

Дашборд руководителя (в работе)

Всё выше это срезы по одному проекту. Другое направление, пока еще в разработке, это портфельный дашборд руководителя: взгляд сразу на все проекты команды.

Что увидит руководитель:

Все проекты на одной карте: какой на каком этапе BABOK, какой стоит, какой движется.
Узкое место: на каком шаге проект застрял и почему.
Очередь решений: требования и изменения, висящие на согласовании.
Риски: где накопились открытые вопросы и непокрытые угрозы.

Для ЛПР это та самая прозрачность, которой обычно нет: виден не отдельный аналитик, а весь поток работы команды, без ручного сведения отчётов по вечерам. Архитектура это уже позволяет, дашборд выводится из тех же артефактов, что и доска со сводками, отдельной базы под него заводить не нужно. Это часть SaaS-направления платформы. Фундамент готов, витрину достраиваю.

Архитектура: один движок, много кузовов

А теперь поговорим о том, за счет чего возможны все эти фичи у AIналитика. Как спроектирована архитектура. Детали вынесу в спойлеры, тут только суть.

Вся новая архитектура держится на одной метафоре: один движок, много кузовов.

Движок и кузова

Разложу по слоям.

Движок (от среды запуска не зависит):

core: общая служебная основа. Хранилище артефактов, разбор ответов модели, расчётные матрицы. Самой методологии тут нет, это переиспользуемые кирпичики для всех глав.
lib: сама методология BABOK, по функции на каждую задачу. Строит реестры, считает приоритеты, обходит граф требований. Опирается на core.

Вот эти core и lib и есть движок в узком смысле.

Кузова (через них движок попадает в конкретную среду):

CLI-скрипты: кузов для терминальных агентов (Claude Code, OpenCode, Kodik, Codex). Тонкие, на пару десятков строк: приняли команду, вызвали lib, вернули результат.
Веб-приложение: другой кузов - для браузера. Зовёт тот же lib напрямую.
Панель в IDE: третий кузов, живёт внутри VS Code.

Главное, что CLI, веб и панель это не три копии логики, а три двери в одну комнату. Поправил методологию в lib, и поправилось сразу везде.

Чтобы такая система не рассыпалась от каждой правки, держу её под почти двумя тысячами автотестов.

В чем польза для бизнеса

Если кратко, то в скорости и масштабируемости.

Новую среду подключаю быстро. Появился новый харнес или редактор? Пишу тонкий кузов, движок не трогаю. Занимает буквально дни, а может и часы, но никак не месяцы.

Кастомизация под компанию это вырезать блок и добавить новый, а не переписать всё. У каждой компании свой набор потребностей и требований: одной нужны интеграции с Jira и Confluence, другой нет, третья хочет работать только на локальной модели, для четвертой важно, чтобы без VPN и оплатой рублями. Я с самого начала строил архитектуру так, чтобы лишнее удалялось как отдельный блок, начисто, без многонедельных переделок, а нужное добавлялось. Быстро, никаких рефакторингов кода.

Даже если выйдет новая редакция BABOK, обновлюсь без боли. Стандарт не вечен, рано или поздно выйдет новая версия. Вся методология находится в движке: основная логика в lib, переходы между задачами в графе навигации. Правки уходят туда. Кузова (CLI, веб, панель в IDE), агенты, слой работы с моделью и хранилище не трогаются вообще. Им безразлично, какая версия стандарта действует.

Четыре Агента вместо одного

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

Orchestrator — «менеджер проекта»

Главный координатор. Получает от BA задачу («обработай 7 транскриптов с воркшопов и сведи в кросс-анализ») и расписывает её на подзадачи. Решает, кому что отдать, в каком порядке, что параллельно, что последовательно. Сам не работает с содержанием, только организует процесс.

Analyst — «бизнес-аналитик» по BABOK

Главный мыслитель. Знает всю методологию BABOK наизусть. Общается с BA в диалоге, задаёт уточняющие вопросы, предлагает варианты, помогает принять методологическое решение. Здесь живёт «как правильно по BABOK». Когда вы вместе обсуждаете, какую технику выявления выбрать для CFO, — это Analyst.

Worker_LLM — «технический писатель»

Текстовый ремесленник. Берёт готовый кусок информации (транскрипт интервью) и превращает его в нужный артефакт: структурированное саммари, переформулированное требование, чек-лист противоречий. Методология ему не нужна, есть чёткий шаблон, исходник и результат. Быстро и точно.

Worker_File — «оператор данных»

Файловый ремесленник. Читает .txt / .pdf / .docx / .md. Парсит регламенты, выгружает данные из таблиц, сохраняет артефакты в нужную папку. Не думает про содержание, просто работает со структурой. Зато умеет это делать очень быстро.

Главное - параллельность

Зачем такое деление? Ради скорости. Если нужно разобрать не одно интервью, а пачку, Дирижёр запускает думающих работников параллельно. Пачка разбирается заметно быстрее.

Как устроен слой работы с моделью (для технарей)

Вся платформа обращается к языковой модели через одну функцию, invoke(). Код, который выполняет работу по BABOK, не знает, какая именно модель используется. Он просто вызывает invoke(): «вот задача, дай ответ».

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

anthropic: облачные модели Claude через Anthropic SDK.
openai_compat: всё, что понимает «диалект» OpenAI API. Сюда попадает целый набор инструментов: vLLM, Ollama в OpenAI-режиме, LM Studio, OpenRouter, LocalAI.
ollama: локальные модели через собственный API Ollama.

Зачем это нужно? Чтобы перейти с облачного Claude на локальную модель, я просто меняю настройку, а не код. Логика BABOK, которая вызывает invoke(), не меняется ни на строку. Отсюда и берётся «AIналитик работает на любой модели».

Сюда же зашита экономия на токенах. У каждой задачи есть «вес». Рутину (извлечение, классификация) invoke() отправляет на дешёвую быструю модель, а тяжёлый синтез на более сильную. Это снова вопрос настройки, не кода, и на длинном проекте заметно режет косты.

Ещё одно решение. Автоматического переключения между бэкендами при сбое нет. Звучит удобно (упала локальная модель, тихо ушли в облако), но это прячет ошибку и незаметно меняет стоимость и качество ответа. Если что-то упало, система сообщает об этом явно, дальше решает человек.

Стек: на чём всё это стоит (для технарей)

Python это мозги: движок BABOK, CLI-скрипты, навигация доски, слой работы с моделями. Вся детерминированная математика (матрицы, приоритеты, обход графа), все артефакты-файлы и вся работа с моделями живут на нём.

React и TypeScript это лицо: веб-приложение и сам визуальный интерфейс Доски. React за гигантскую экосистему, TypeScript за строгую типизацию, чтобы интерфейс большого продукта не рассыпался от каждой правки.

FastAPI это мост между лицом и мозгами.

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

Под каждую боль своя сборка

Вернёмся к трём сигналам. Один из них, страх входа в середину проекта, уже закрыт Доской выше. Остаются два, про модель и про деньги: под каждое такое ограничение есть своя сборка. Плюс ещё одна для тех, кого в Claude всё устраивает.

Нужна приватность, данные не выпускаем за периметр. Сборка: OpenCode плюс локальная модель через Ollama. AIналитик работает целиком внутри вашего контура, наружу не уходит ничего. Уже реализована.

Нужна простая оплата рублями и без VPN. Сборка: Kodik, российская IDE с оплатой токенов рублями. Та же платформа, та же методология, без зарубежных подписок. Уже реализована.

В Claude всё устраивает, хочется отдельный красивый продукт. Сборка: полноценное веб-приложение на Anthropic SDK. Пока в разработке.

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

Основные поинты новой версии AIналитика

Нет фаз и /restart. Этот момент исчез.
Не привязаны к одной модели и вендору. Хотите Claude, хотите локальную модель, хотите российскую IDE с оплатой рублями.
Появился параллелизм: пачка интервью разбирается быстрее.
Запускается где угодно, новый харнес подключается быстро.
Кастомизация под клиента это вырезать блок и добавить другой без рефакторинга.
Можно перейти на AIналитика в любой момент времени, не обязательно начинать проект с самого начала.
Появилась визуальная Доска.
Сводки по проекту: покрытие целей, здоровье требований, риски, готовность к согласованию.
Дашборд руководителя для тимлидов и PM (в работе).

Что дальше

Веб целиком. Для тех кейсов, где работа Claude приемлема всё просто: сAnthropic SDK веб-чат можно собрать быстро. Но реализовать в браузере возможность переключения между провайдерами (Claude, локальная модель, OpenAI, китайские облачные модели), видеть их потоковый ответ это уже отдельная большая инженерная задача. Универсальный переключатель провайдеров именно для вебприложения, к сожалению, быстро не сделать. С этим придется повозиться.

Бот-интервьюер, он же «анкетирование 2.0». Идея, с которой AIналитик когда-то начинался. Бот сам проводит интервью со стейкхолдером, держа в уме весь собранный контекст, и работает в двух каналах: веб-чат и Telegram. Проводить интервью через бота или лично решает живой бизнес-аналитик, платформа лишь подскажет, уместно ли это для конкретного человека. Со спонсором лучше лично, а для довыявления и уточнений бот подойдёт.

Команда. Общие пространства на нескольких бизнес аналитиков, те самые дашборды для тимлида и PM, интеграции с Jira и различными сервисами Гугла.

И главное это ниши. За пару месяцев я в одиночку собрал швейцарский нож. Дальше хочу сужаться и допиливать (кастомизировать) Платформу под потребности конкретных компаний. Тут мне нужен важен контекст. Жду ваши требования!

Backstage

Как происходила разработка проекта

В конце хотелось бы поделиться впечатлениями от процесса разработки. Идею проекта я вынашивал несколько месяцев, она появилась у меня в конце прошлого 2025 года. Приступил к реализации в десятых числах марта 2026 года, сразу после 8-мартовского праздника.

Вайбкодинг

Я не знаю почему процесс кодинга с AI так назвали. Извини, Андрей, но в этом я с тобой совсем не согласен! 😉

Никакого вайба в процессе работы я не заметил. Наоборот, приходилось предельно концентрироваться и фокусироваться, постоянно быть собранным. Полностью расслабиться никогда не получалось. Во время процесса нужно было держать ухо востро, потому что LLM-ку необходимо постоянно контролировать. Она вроде невероятно умная, но порой способна выкинуть какой-нибудь фортель. И потом так по-детски начать лепить отмазки и извиняться. Даже мой любимый Claude не исключение. Особенно тяжело вайбкодить, когда сам процессом разработки никогда раньше не занимался. Лично мне сильно не хватало опыта разработчика, код я никогда сам не писал. Так что я тру вайбкодер :)

Меня выручал лишь мой опыт бизнес-аналитика и навык написания спецификаций, который позволил мне быстро освоить контекст инжиниринг.

Spec-Driven Development (SDD)

Когда начинал проект, я ничего не знал про SDD. Но практически сразу мне пришлось его переоткрыть. У меня сложился определенный пул dev файлов, куда LLM-ка (Клод) в процессе работы складывала разную служебную информацию: принятые в процессе работы решения, структуры сессий, правила открытия и закрытия сессий. Например, по регламенту закрытия сессии в конце каждой сессии LLM-ка сама писала мне стартовый промпт для следующей сессии. Я его просто копировал и вставлял в новой сессии.

Самые первые сессии проекта были посвящены не только постановке целей и описания задач, но так же выработке регламента работы: мы договаривались о процедуре работы, о том, КАК мы делаем проект (какие dev файлы мы заводим и как мы их ведем). Этот этап занял очень много времени. Порой Клод убегал в самоволку, откуда его приходилось возвращать.

В середине работы над проектом процесс приобрел уже рутинный характер. В конце каждой сессии Клод совершал ритуал закрытия сессии: обновлял dev файлы (claude_dev.md, devlog.md, decisions.md и др), выдавал мне в чат сводку и новый промпт для следующей сессии, который он готовил исходя из общей спеки и плана. Я его просто копировал, открывал новую сессию и вставлял.

На этом этапе я был похож на котейку, который мирно дремлет, но при этом очень внимательно отслеживает ситуацию вокруг - ну знаете, вроде он спит, но ушки инстинктивно поворачиваются на источник звука :) Так и я вставлял приготовленный промпт в новую сессию, смотрел в медитативном состоянии на поток мыслей и сообщений Клода. Но любая мелочь быстро встряхивала меня, я писал в чат и устраивал допрос, а иногда и разнос Клоду.

Если вдруг мне в голову приходили какие-то идеи, то я в конце сессии озвучивал их Клоду. Мы их обсуждали, Клод запускал скилл брейншторминга из пакета superpowers, писал спеку и составлял план реализации для новой фичи.

У меня был принят следующий форкфлоу. Первая сессия это имплементация - Клод кодил. И обязательно писал тесты, на которые он потом постоянно опирался. Следующая сессия - внешнее ревью сделанного на предыдущем шаге кода. Клод запускал субагента ревьюера из плагина суперпауэрс, который найденные ошибки классифицировал: Critical, Important и Minor. Если были первые две (критические или важные), то клод их сразу фиксил - либо в этой же сессии, либо в специальной новой. Если ошибки были минорными, то как правило он их записывал и фиксил в каких-то следующих сессиях, где это было ему удобно.

Критические ошибки у меня вылезали за все время не больше трех раз. Важные чуть почаще. В основном были минорные.

Когда заканчивался блок имплементации фичи, это как правило занимало около пяти-десяти сессий, то стартовало “ревью ревью”, задача которого было проверить, что все найденные минорные баги были в итоге пофиксены. Клод же оставлял их на будущие сессии, и я всегда боялся, что он протупит и забудет. Но таких косяков за ним замечено не было.

Вот такой вот SDD у меня получился. Возможно, он далеко не идеальный. Знаю, что существует несколько методологий SDD: Spec Kit, Open Spec, AI-Factory. Дойдут руки - изучу, но пока своих наработок хватает.

Косяки Клода

В процессе работы за Клодом было замечено несколько разных косяков. Маленькие и средние я уже не помню.

Но был один серьезный косяк, к счастью, не приведший к последствиям. В начале работы мы договорились, что он результаты каждой сессии должен пушить на гитхаб в репозиторий. Он несколько первых сессий это честно делал, а потом забил и перешел просто на локальные коммиты. Я сразу не заметил и обнаружил это только в самом конце проекта - на последней сессии, когда проект был готов. Если бы в процессе работы над проектом что-то случилось с жестким диском, то я бы все потерял :(.

Но это моя вина, что не уследил из-за недостатка опыта разработчика.

Спасибо, что дочитали. Первая статья была про то, что я построил. Эта про то, как и зачем перестроил. Задавайте вопросы! Если у вас есть вопросы персональные, касающиеся конкретно вашей ситуации, то пишите мне в тг: https://t.me/achaussky

Канал с новостями проекта AI Платформа AIналитик.

Анатолий Чаусский | Бизнес-аналитик | AI разработчик | AI Амбассадор Яндекс.Практикума

AIналитик v2 по BABOK: как я переписал AI-платформу для бизнес-анализа, чтобы она работала c любыми LLM