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

Недавно была задача взять одну систему за основу и усовершенствовать её – кое-что выпилить, кое-что допилить, что-то оставить

Был выбор:
1. Использовать сложный пайплайн (публичный вариант) с трехчасовым планированием, 20+ часами исполнением плана, декомпозицией задач в YouTrack и ветками в системе контроля версий. Жесть, в общем
2. Использовать обычный чатик с ручными итерациями "перепиши и проверь"
3. Взять что-то между п.1 и п.2: адаптивный полуавтономный пайплайн под среднебытовую задачу с приоритизацией общения в чатике

По сложному названию и ссылке на гит можно догадаться, что я выбрал третий вариант. Мои два промпта кодексу звучали так:
1. "$bx-dev"
2. "/goal возьми из репы Х все python исходники. Перепиши весь проект на go в более сопровождаемый вид. В каждой итерации используй нужные скиллы из skill-library. Следуй протоколу $bx-dev. Критерий завершения – система полностью перенесена на go и проверена на отсутствие потерь бизнес-логики при миграции"

Отличный промпт? Да! Сейчас разберём
Написав $bx-dev, мы задали рабочий контур: исследование перед изменениями, реализация, проверки, ревью и DDD классификация там, где она действительно нужна
А написав "/goal ..." – мы зафиксировали задачу, критерий завершения и требования к процессу. Агенту сложнее закончить раньше времени: при попытке остановиться его возвращает к цели, проверкам и требованиям из $bx-dev и напоминанию использовать skill-library (буст +16 п.п. к эффективности)

Получается, что у нейронки нет нормального выхода из цикла, пока она не сверится с критерием завершения: полностью перенести систему и не потерять бизнес-логику. При каждой попытке останова её пинают и говорят следовать промпту из /goal, который отлично напоминает про задачу и требования к её исполнению

Отправили всё в кодекс и ушли заниматься своими делами, – спустя 8 часов имеем ваншотом полностью перенесенный проект на другой яп. Запустили, проверили – есть пара мелких недочетов, но фиксятся они за 5-10 минут

Суть в том, что $bx-dev сам по себе вполне автономен и хорошо справляется с большинством задач. А в связке с /goal мы это дополнительно усилили, исключив потерю контекста с течением времени


Теперь самое интересное... Я решил в паблик выложить свой bx-dev skill и встроенную skill-library с механизмом ленивой загрузки 105 скиллов, которые использую в повседневных задачах

В репе описал, как устроен скилл и как с ним работать в разных сценариях
Скилл самодостаточен и готов к работе из коробки, нужны лишь утилиты gh (для git репы проекта) и jq (для записи состояний)

☁️ Исходный код: GitHub

#opensource