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

Меня зовут Саша Раковский. Работаю техлидом в расчётном центре одного из крупнейших банков РФ, где ежедневно проводятся миллионы платежей, а ошибка может стоить сотни миллионов рублей. Законченный фанат экстремального программирования — значит, DDD, TDD и всего, что с ним связано. Эти подходы редкие и сложные, поэтому делюсь опытом. Если интересно — добро пожаловать.

В прошлой статье я разобрал основы ИИ-разработки и сформулировал три ключевых тезиса:

• На голых промптах далеко не уедешь. Нужен системный подход: управление контекстом, исправление повторяющихся ошибок, шаблоны. Без ИИ-фреймворка — никак.
• Автотесты — центральный элемент ИИ-разработки. Софт — это совокупность поведения. Зелёный тест — единица поведения, фундаментальная частица кода.
• Автономная ИИ-разработка — пока фантастика. Даже лучшие модели ошибаются непредсказуемо. Человеческое ревью обязательно.

Итог: нужен фреймворк, построенный вокруг автотестов и частого ревью. Чем меньше кода на каждом этапе — тем выше шанс заметить ошибку.

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

У меня же в процессе работы родилось собственное решение — заточенное под «книжный подход», принятый в нашей команде. Оно показало хорошие результаты, поэтому делюсь им по просьбам подписчиков.

Фреймворк проверен за 3,5 месяца, 4000 коммитов, 1500 тестов (из них ~350 e2e), 25 тыс. строк продакшн-кода (12k Java, 12k TS/TSX) и столько же тестового кода.

Концепция

Любой софт — это совокупность поведения. Каждое поведение должно быть покрыто тест-кейсом. Хороший софт — это совокупность зелёных тест-кейсов. Эта идея легла в основу фреймворка.

Верхнеуровнево процесс выглядит так:

• Описание продукта + список пользовательских историй
• Для каждой истории:
  • Этап спецификации: интервью, проектирование требований, генерация тест-кейсов
  • Этап реализации: TDD-цикл по каждому кейсу — красный тест → зелёный тест

Истории — это минимально независимые фичи, каждая из которых приносит отдельную ценность. Как говорил Кент Бек: «Tell me your story». Например: «Однажды я забыл пароль» → фича «Сброс пароля».

Разработка начинается с постановки требований: описание, критерии приёмки, API, макеты. На их основе формируется тест-план — главный артефакт для каждой истории.

Когда тест-план готов, фреймворк проходит по кейсам в TDD-стиле, реализуя их один за другим, с остановками на ревью. Когда все кейсы зелёные — история завершена.

Центральный скилл: /continue

Ключевой элемент — скилл /continue. Он анализирует текущее состояние проекта (список историй и их progress.md) и определяет следующий шаг.

Для демонстрации я подготовил пример — Kanban-доску с тремя историями в stories.md:

1. Создать таску
2. Передвинуть таску в другую колонку
3. Изменить/удалить таску

Рассмотрим, как /continue работает с каждой:

• История #3: не начата. /continue 3 стартует с интервью, проектирует API, создаёт макеты, генерирует тест-кейсы.
• История #2: спека есть, разработка не начата. /continue 2 начнёт с написания acceptance-теста и пойдёт по TDD-циклу, останавливаясь на каждом шаге для ревью.
• История #1: бэкенд готов, фронт частично сделан. /continue 1 продолжит с последнего незавершённого фронтового кейса.

Ограничение: фреймворк изначально заточен под серверные приложения. Для мобильных, десктопных, embedded-систем или игр может потребоваться адаптация через скилл /prompt-update.

progress.md

Каждая история имеет свой progress.md — чек-лист, фиксирующий прогресс. Он разбит на фазы:

• Спецификация
• Реализация:
  • Бэкенд
  • Интеграции
  • Фронтенд
  • Безопасность
  • Нагрузка
  • Инфраструктура

Спецификация включает: интервью, описание, макеты, API, тест-план.

После каждого шага /continue отмечает его в progress.md, делает коммит и ожидает ревью. После подтверждения — переходит к следующему.

Фаза реализации состоит из кейсов, сгенерированных на этапе спецификации. Каждый кейс разбивается на TDD-шаги. Фреймворк навязывает ATDD: большой TDD-цикл охватывает несколько маленьких.

Например, для бэкенда:

• Красный acceptance-тест
• Красный usecase-тест → зелёный usecase-тест
• Красный адаптер-тест (например, контроллер) → зелёный
• ... аналогично для других адаптеров
• Зелёный acceptance-тест

После каждого шага — коммит. Это позволяет изолированно смотреть изменения.

Архитектурные правила

Фреймворк построен на Clean Architecture и гексагональной архитектуре с ATDD. Такой подход описан в книгах «Get Your Hands Dirty on Clean Architecture» (Tom Hombergs) и «Hexagonal Architecture Explained» (Alistair Cockburn).

Если вы используете другую архитектуру или стиль тестирования — потребуется адаптация через /prompt-update.

Quality gates

LLM учатся на разном по качеству коде. Чтобы сгладить типовые ошибки, я добавил контрольные точки — quality gates:

• На красном шаге: ревью строгости тестов, архитектуры + рефакторинг
• На зелёном шаге: рефакторинг + проверка покрытия тестами

Каждый gate включает чек-лист, по которому LLM обязана отчитаться: есть ли нарушение.

После gates — коммит. Человек смотрит diff, оставляет замечания. Если всё ок — сбрасывает контекст и запускает /continue. Фреймворк идёт дальше, а мы переходим к другому потоку.

Контекст-менеджмент

Каждый шаг разбит на два этапа: написание кода/теста и последующие gates. Чтобы активности не мешали друг другу, они запускаются в отдельных агентах.

Ещё один приём — progress.md. Он позволяет сбрасывать контекст после каждого шага и загружать только необходимое, повышая надёжность вывода.

Самоулучшение

Если сталкиваюсь с повторяющейся ошибкой — вызываю /prompt-update с описанием проблемы. После исправления проверяю, что фреймворк больше не делает эту ошибку.

Так, день за днём, фреймворк обрастает правилами, становится эффективнее — и порой менее послушным. Чем больше правил, тем выше шанс, что LLM что-то забудет.

Как попробовать

Я теперь пишу код только с этим фреймворком. Если хотите попробовать «взрослый» ИИ-процесс вместо хаотичного вайб-кодинга — у меня есть два репозитория:

• Пример Kanban-доски на Java + React
• Голый фреймворк без примеров

Рекомендую начать с первого.

Рекомендуемый сценарий

1. У вас должна быть подписка на Claude или совместимую LLM (например, GLM5 от Z.ai).
2. Склонируйте репозиторий с Kanban-доской. Лучше три копии — в трёх IDE (или через worktrees).
3. В каждой IDE запустите /continue 1, /continue 2, /continue 3.
4. В первой IDE: продолжится фронтенд-разработка (Selenium-тест).
5. Во второй: начнётся бэкенд с acceptance-теста.
6. В третьей: стартует с интервью — история ещё не начата.

Про параллелизацию

Один цикл /continue занимает от 5 до 20 минут. Иногда — до часа, если LLM перезапускает долгие тесты.

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

Сейчас модели становятся быстрее — через полгода этот недостаток, вероятно, исчезнет.

Почему отдельные репозитории, а не worktree? Можно и worktree, но отдельные репы удобнее.

У меня — 6 параллельных IDE: 4–5 из них крутят /continue, остальные — техдолг, рефакторинги, оптимизация пайпов.

Чтобы избежать конфликтов портов, в репозиториях с суффиксами вроде continue-example1 фреймворк автоматически выставляет уникальные порты.

Как стартовать с нуля

Альтернатива — пустой фреймворк. Я потратил много времени, чтобы он мог из пустой репы доехать до MVP только через /continue и небольшие корректировки.

Как начать:

1. Склонируйте пустой фреймворк.
2. Заполните:
   • BriefProductDescription.md — описание продукта
   • ExpectedLoad.md — нагрузка
   • technology.md — стек
3. Сгенерируйте список историй с помощью Claude и запишите в stories.md.
4. Запускайте /continue — и идите пить чай.

Я отвязал фреймворк от Java и сделал шаблоны под 90% популярных технологий. Он работает, но может выдавать «культурный шок» — результат может не соответствовать стилю вашего языка. В этом случае — /prompt-update в помощь.

Полезные фишки

/prompt-update

Самый часто используемый скилл. Исправляет поведение фреймворка — от мелких багов до глобальных переделок. Я вызываю его несколько раз в день.

Рядом — /prompt-refactor. Ищет слабые места во фреймворке. Но может предлагать ерунду, поэтому требует глубокого понимания контекста. Например: /prompt-refactor last commit.

Не все задачи подходят под TDD-цикл по progress.md. Поэтому у меня есть скилл для багфиксов, рефакторинга, инфраструктуры — назовём это таской. Она похожа на историю, но с меньшей церемонией: только описание и прогресс-файл с шагами.

/continue умеет работать и с тасками. Они хранятся в отдельной папке и после завершения мигрируют в /done. Использую не реже раза в день.

Ещё одно применение агентов — аналитика. Claude отлично ищет в документации, исследует API, проверяет через curl, делает локальные копии данных, даже скрейпит сайты, обходя антиботы.

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

Но результаты теряются после сессии, а контекст засоряется. Чтобы фиксировать находки — есть скилл /doc.

Портирование и ограничения

Фреймворк имеет ограничения:

• Разработан под конкретный стек
• Заточен под Clean Architecture, DDD, OOP, подходы из книги Martin Fowler
• Ориентирован на ATDD и гексагональную архитектуру (adapter + application tests)
• Поддерживает веб-приложения (бэк + фронт)
• Использует английский для экономии токенов

От технологии я его частично отвязал, но от Clean Architecture и ATDD — нет и не планирую. Если они вам чужды — лучше попробовать SuperPowers.

Если решение понравилось — адаптируйте его через /prompt-update. Настройка займёт час-два.

Техника безопасности

• ИИ не заменяет разработчика. Если баг пролезет на ревью — он уедет в прод.
• Принцип «железо дешевле людей». Фреймворк экономит время, тратя токены. У меня $200 на Claude иногда не хватает при работе в 5 потоков.
• LLM нарушают правила. Фреймворк может сойти с рельсов. Нужно подправлять — чаще всего повторным вызовом /refactor или /test-review на чистом контексте.
• Разработан под один проект. На другом стеке, архитектуре или подходе может работать хуже.
• Под вкус автора. Если у вас другие предпочтения — используйте /prompt-update или SuperPowers.
• Молодой и неполный. Требует постоянной доработки через /prompt-update.

Приятной эксплуатации.

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

Меня зовутСаша Раковский. Работаю техлидом в расчётном центре одного из крупнейших банков РФ, где ежедневно проводятся миллионы платежей, а ошибка может стоить банку сотни миллионов рублей. Законченный фанатэкстремального программирования, а значит иDDD,TDD, и вот этого всего. Штуки редкие, крутые, так мало кто умеет — для этого я здесь, делюсь опытом. Если стало интересно, добро пожаловать в мойблог.

В прошлой части я разобрал базу по ИИ-разработке для начинающих и накинул несколько тезисов от себя:

1. На голых промптах далеко не уедешь. В ИИ-разработке необходим системный подход к решению повторяющихся задач, исправлении повторяющихся ошибок, в управлении контекстом. Без ИИ-фреймворка - никак.
2. Без автотестов хоть сколько-то адекватная ИИ-разработка невозможна. Именно автотесты должны быть центральным элементом ИИ-разработки. Если софт - это совокупность поведения системы, то зелёный автотест - это единица поведения, фундаментальная частица, из которой построен этот софт.
3. Автономная ИИ-разработка - это пока фантастика. Даже самые лучшие модели чудят так, что никакими тестами не предугадаешь все их возможные косяки. Человеческое ревью необходимо обязательно.

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

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

Однако, именно поэтому мне, например, superpowers не очень подходит - слишком уж легковесный. Он практически противоречит ATDD и плохо встраивается в более структурированные процессы разработки. В то же время, в процессе разработки у меня как-то само по себе родилось своё решение, заточенное под принятый в нашей команде "книжный подход".

И раз получилось неплохо, то почему бы, по просьбам подписчиков своего канала, и не поделиться прогрессом на текущий момент. Фреймворк проверен на 3,5 месяцах работы, 4к коммитов, 1500 тестов, ~350 — e2e, 25к строк продакшн-кода (12k java back, 12k ts/tsx front). И столько же тест-кода.

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

Верхнеуровнево фреймворк проходит следующую последовательность шагов:

• краткое описание продукта + перечисление историй
• история 1этап спецификацииинтервью...(проектирование требований на основе интервью и описания продукта)генерация кейсов на основе требованийэтап реализации сгенерированных кейсов:кейс 1красный тест...(реализация)зелёный тесткейс 2... (остальные кейсы)
• история 2этап спецификации...этап реализации

Вся работа разбита на истории - минимально зависимые друг от друга фичи, каждая из которых поставляет свою рбособленную ценность. Как говорил Кент Бек пользакам: "Tell me your story". История должна покрывать какой-то один аспект пользовательского опыта. Например, "однажды я забыл пароль" - вполне себе подобная история, которая превращается в фичу "Сброс пароля".

Разработка истории начинается с постановки требований: описания истории, критериев приёмки, проектирования апи, макетов. Эти требования необходимы для составления списка тест-кейсов - главного артефакта для каждой истории.

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

Центральным элементом фреймворка является скилл/continue, который, опираясь на текущее состояние проекта - список историй и их прогресс-файлы, определяет, какой дальнейший шаг необходимо сделать.

Поссылке, я специально сделал демо-пример классического бэк+фронт приложения - Kanban-доски с 3 запланированными к разработке историями вstories.md:

1. Создать таску.
2. Передвинуть таску в другую колонку.
3. Изменить/удалить таску.

Пройдёмся по ним в обратном порядке:

1. Кистории #3я намеренно не приступал, поэтому/continue 3начнет проектирование с самого первого шага - написания спецификации:проведёт и запротоколирует интервью;составит описание истории;построит макеты интерфейса;определит используемое апи и спроектирует новое, если надо;сгенерирует тест-кейсы, необходимые для реализации.
2. Вистории #2спека уже есть, но разработка еще не начата, поэтому "/continue 2" начнет уже с разработки бэка: найдет первый кейс, прочитает спеку, напишет красный приёмочный тест и побежит шаг за шагом его зеленить в коротких red-green-refactor TDD-циклах, прерываясь на ревью после каждого шага.
3. Вистории #1уже сделаны все кейсы на бэке и даже начат фронт, поэтому вызов скилла "/continue 1" приведёт к тому, что разработка продолжится с фронтового кейса - с последнего шага, который отмечен вprogress.mdистории, как выполненный.

Но, как видите, тут мы встречаем первое ограничение: фреймворк был разработан мной для своих задач - разработки серверного приложения. Чтобы использовать фреймворк для мобильного, десктопного приложения, embedded, игр или для еще какого-то софта, может понадобиться доработка фреймворка через специально придуманный для этого скилл/prompt-update.

progress.md

В каждой истории есть свойprogress.md, который фиксирует, на чем остановилась работа над историей в прошлый раз. Это длинный чек-лист, разбитый на несколько фаз:

• спецификация
• реализация:бэкендвнешние интеграциифронтендбезопасностьнагрузкаинфраструктура.

Спецификация состоит, как я уже говорил, из нескольких шагов: интервью, описания, макетов, апи и тест-плана.

После каждого шага/continue, отмечает шаг сделанным в чеклисте, делает коммит и встает на паузу, ожидая ревью от человека. После запуска/continueпереходит к следующему шагу.

Все остальные фазы состоят из кейсов, сгенерированных, в первой фазе.

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

Например, для бэка это выглядит так:

• красныйприёмочный (e2e, acceptance) тест;красныйusecase-тест;зелёныйusecase-тест;красныйадаптер-тест (например, контроллер);зелёныйадаптер-тест;... такие же мини-циклы для других адаптеров
• зелёныйприёмочный тест;

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

Архитектурные правила

Как видим, тут навязана Clean Architecture с общепринятым в гексагональной архитектуре ATDD. Этот подход к тестированию описан, например, в "Get Your Hands Dirty on Clean Architecture", Tom Hombergs и "Hexagonal Architecture Explained" от самого автора гексагоналки, Alistair Cockburn. Если вы предпочитаете иную архитектуру или иной тестовый подход, то тут потребуется доработать фреймворк под себя с помощью/prompt-update, о котором я уже упоминал, но подробнее расскажу чуть позже.

Quality gates

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

• на красном шаге это ревью строгости тестов и соблюдения тестовой архитектуры + рефакторинг;
• на зелёном шаге это рефакторинг + проверка покрытия тестами.

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

После всех гейтов следует коммит, и в дело вступаем мы, отсматривая diff коммита и высказывая замечания. Если замечаний нет или они устранены, мы сбрасываем контекст и делаем/continue. Фреймворк молотит дальше, а мы идем в другое окно IDE разруливать другой добежавший до конца/continue.

Контекст-менеджмент

Каждый шаг реализации разбит на 2 этапа: написание теста/кода и последующие гейты (ревью, рефакторинг, coverage). Чтобы эти активности друг на друга не влияли, все подшаги запускаются в отдельныхагентах.

Другой приём управления контекстом - этот тот самыйprogress.md, позволяющий сбрасывать контекст после каждого шага, и начинать с пустого контекста, загружая туда только самое необходимое, повышая надежность вывода.

Самоулучшение

Если я сталкиваюсь с каким-то косяком не в первый раз, я вызываю/prompt-updateс описанием проблемы. После исправления фреймворка, я отсматриваю изменения, откатываю последний коммит, сбрасываю контекст, и проверяю, что в этот раз проблема решена.

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

Как попробовать

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

• репас примером Канбан-доски на Java+React стеке,
• репас голым фреймворком.

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

Рекомендуемый сценарий:

1. Я предполагаю, что у вас есть подписка на клод или на клод-совместимую LLM (например, GLM5 от Z.ai или вы умеете запускать Claude-конфигурацию в Codex).
2. Склонируйте репу с Канбан доской. Рекомендую склонировать 3 раза и открыть каждую репу в отдельной IDE. Ну или используйте worktrees, если так привычнее.
3. В каждой из IDE откройте терминал, зайдите в клод, и введите/continue 1,/continue 2,/continue 3соответственно.
4. В первой ide клод приступит к написанию selenium-теста для фронтового кейса, на котором остановилась разработка.
5. Во второй ide начнёт разработку с того места, где остановилась вторая история - с acceptance-теста для первого бэкенд-кейса.
6. В третьей ide клод увидит, что третья история ещё не начата и приступит к разработке с самого первого шага - интервью.

Про параллелизацию

Почему 3 ide?

Пока/continueделает все свои необходимые шаги, легко может пройти от 5 до 20 минут. Иногда, если клод столкнулся с какой-то непростой для него проблемой и по много раз перезапускает долго исполняющиеся тесты, чтобы проверить ту или иную гипотезу, время одного запуска может затянуться на сорок минут и даже час.

Это один из недостатков получившегося фреймворка - цикл, на который Claude уходит в работу, очень долгий. Впрочем, если дефицита задач нет, то параллелизация работы позволяет все равно двигаться именно с той скоростью, с которой вы способны ревьюить изменения. Каждая фича будет ехать примерно, как если бы она была написана руками, но одновременно с ней будут ехать еще 3-4 минимум.

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

Почему не worktree?

Можно и worktree, конечно. Но я использую отдельные репозитории, потому они чуточку удобнее и позволяют чуточку больше.

Как у меня

Мой типовой поток состоит из 6 параллельно запущенных IDE, в которых 4-5 молотят /continue или обрабатывают замечания по результатам работы этого скилла, а в оставшихся я занимаюсь какими-то техдолгами: планирую рефакторинги, ищу проблемы в коде, оптимизирую пайп.

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

Если папка будет иметь на конце индекс: "continue-example1", "continue-example2", "continue-example3", то это позволит фреймворку забить для каждого репозитория порты так, чтобы при запуске приложений и инфраструктуры разные потоки друг другу не мешали.

Как стартануть с нуля

Альтернативный вариант -пустая репас голым фреймворком. Я запарился и потратил кучу времени на отладку и тестирование фреймворка, чтобы он, независимо от выбранных технологий, мог доехать от пустой репы, до простенького mvp на одних лишь только вызовах/continueи небольших корректирующих усилиях по причесыванию каких-то заскоков.

Что делать?

1. Клонируетепустой фреймворк.
2. Прописываете:описание продукта вBriefProductDescription.mdожидаемую нагрузку/производительность вExpectedLoad.mdтехнологии вtechnology.mdгенерите вместе с клодом список историй и просите его записать их вstories.md
3. И дальше/continueбез остановки.

У меня отняло несколько вечеров, чтобы отвязать фреймворк от этой своей джавы и сделать его более-менее рабочим на других языках. Я сделал несколько шаблонов под 90% основных технологий и языков. И оно даже работает на всех из них плюс-минус так, как я ожидаю. Но если вы с другого языка, то вы, вероятно, можете испытать некую форму культурного шока от того, как результат не похож на то, что принято в вашем языке. Так что/prompt-updateвам в помощь.

Полезные фишки

Помимо/continueи саб-скиллов, которые он оркестрирует, есть еще парочка полезных скиллов, которые вызываются вне основного потока/continue.

/prompt-update

Этот скилл используется для любого исправления поведения фреймворка. В том числе, для самых серьезных переделок фреймворка. Этот скилл один из самых вызываемых - я его использую по несколько раз в день.

Рядом с ним еще живёт/prompt-refactor, который предназначен для поиска проблемных мест во фреймворке. Но этот скилл я вызываю нечасто: порой он предлагает ерунду всякую, поэтому может использоваться только в условиях глубокого понимания работы фреймворка и контекста. Например, чтобы оценить последние изменения:/prompt-refactor last commit.

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

Скилл/continueумеет итерироваться по задачам так же, как и по историям. Таски хранятся в своей папочке и после реализации мигрируют в папочку /done. Я в своей разработке использую его не реже раза в день.

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

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

Всё это очень сильно упрощает и ускоряет аналитику. Но вот проблема: результаты этой аналитики потеряются вместе с сессией, а контекст сессии с каждым запросом к ней будет засоряться. Поэтому для фиксации всех своих находок может быть полезен скилл /doc.

Портирование и ограничения

У фреймворка есть много ограничений:

• он был разработан под конкретный технологический стек;
• под определенные подходы к разработке - Clean Architecture + DDD + OOP + Martin Fowler's Refactoring Book;
• под определенный подход к тестированию, ATDD - Acceptance Tests (Continuous Delivery book) + hexagonal architecture testing (adapter tests + application tests);
• под бэк + фронт веб-приложение;
• для экономии токенов используется английский язык.

В целом, если от технологии я его как-то отвязать смог, то ни от Clean Architecture, ни от ATDD даже пока не планировал. Поэтому, если Clean Architecture и ATDD для вас чужды, то, возможно, проще будет попытаться под себя адаптировать SuperPowers.

Но, если уж вам понравилось решение, то для редактирования фреймворка под свои задачи, вам потребуется часик-другой доработать егонапильникомскиллом/prompt-update.

Техника безопасности

Ну и, как обычно, в завершении техника безопасности:

• ни ИИ, ни фреймворк не заменит разработчика: если на ревью не будет замечен баг, то он уедет в прод и все сломает;
• фреймворк работает по принципу "железо дешевле людей" и предпочитает сэкономить человеческое время, потратив токены, поэтому мне не всегда даже $200 подписки Claude хватает для 5 часового окна при работе в несколько потоков;
• фреймворк исполняется ллмкой, ллмки нарушают правила, поэтому иногда фреймворк будет сходить с рельс, и надо его подправлять (самое частое - иногда требуется повторно дёрнуть скилл /refactor или /test-review на чистом контексте);
• фреймворк был разработан под один конкретный проект; он может показать себя заметно хуже на другом языке, на другой архитектуре, для других задач и в другом подходе к тестированию;
• фреймворк разработан под вкусовые предпочтения автора, если у вас другие -/prompt-updateили superpowers;
• фреймворк молодой, не учитывает и не может учитывать всего, поэтому он нуждается в постоянной доработке с помощью /prompt-update.

В общем, приятной эксплуатации. За обновлениями - в мой канал.