Мои принципы командной AI Native разработки Главная цель тут - самостоятельность агентов при сохранении общего замысла продукта. (1) Люди и агенты могут координировать работу через общий язык и явно сформулированные концепции. Это можно использовать, если нужно держать AI Native команду из них в синхроне, распараллеливая работу между ними. В начале нужно создать небольшое смысловое ядро. Это цель, язык, приоритеты и ограничения, из которых естественно следуют дальнейшие решения. Это маленький файл, который пишется вручную (агент может помогать вычитывать). Он грузится в начало контекста агентов и проговаривается со всеми людьми в команде. На базе него принимаются решения и расписываются требования. (2) Получается пирамида, где нижние слои детализируют верхние: смысловое ядро -> решения и требования -> исполняемые BDD спецификации -> код. Чем выше, тем важнее человеческое суждение и тем шире последствия ошибки. Чем ниже, тем больше работу можно распараллеливать и проверять автоматически. Обратная связь из реального мира идёт вверх и помогает пересматривать исходные представления. (3) Контекст раскрывается по мере необходимости (progressive disclosure для людей и агентов). Краткая точка входа ведёт к подробным документам. Знания сохраняются в репозитории и доступны между сессиями. Имена файлов имеют значение! (4) Соответствие кода оформленным требованиям можно проверить запуском тестов! Продуктовые требования связаны с быстрыми поведенческими спеками (executable BDD specs), которые позволяют перепроверять корректность кода со скоростью 7k спеков в секунда. (5) У агента есть инструменты, чтобы проверять результат и исправлять ошибки. Это исполняемые спеки, служебные интерфейсы для отладки. Плюс доступ к логам и продуктовой телеметрии для получения обратной связи от реального мира. (6) Эта система из людей и агентов должна накапливать опыт. Скажем, ошибки улучшают спеки и документацию; пересмотр базовых принципов происходит осознанно (скажем, если повторяются разногласия или узнаем что-то новое). Общие соглашения и центр управления помогают переносить удачные решения между проектами. Урок усвоен, когда он меняет будущие решения или проверки и уменьшает вероятность повторения ошибки. Это можно проверять перезапуском старой сломавшейся задачи после переконфигурации всей пирамиды. А как вы помогаете своим агентам эффективнее работать в командах с людьми? Что работает хорошо, а что - не очень? Ваш, @llm_under_hood 🤗

Я не очень люблю использовать готовые библиотеки для решения специфичных задач [1], т.к. они обычно представляют из себя комбайны с кучей ненужных фич и странных нюансов. А подстраивать их под себя бывает сложнее, чем написать нужный минимум. То ли дело stack flattening - убираем лишний слой абстракции и прямо в коде проекта реализуем ровно те 5% функциональности, которые нам нужны. Без сторонних зависимостей и уязвимостей. А потом, если что-то нужно поправить - поправляем. Особенно это удобно стало с современными coding агентами. Скажем, мне не нравилось, что у меня BDD спеки проекта запускаются последовательно, используя только одно ядро ноутбука. Это же не эффективно. Но “запускатор” - это всего несколько файлов внутри проекта, поэтому я просто попросил Codex распараллелить выполнение. И он реализовал это в режиме piecemeal growth за счет добавления 55 строчек кода. Скорость сразу подросла до более приятных глазу значений:

specs:  77 passed, 26 failed at 2532.9/sec
checks: 451 at 11090.7/sec

На таком объёме экономия десятков миллисекунд погоды пока не делает. Зато теперь тот же паттерн перенести без изменений в другие проектах, где спеков может быть намного больше. Ваш, @llm_under_hood 🤗 — [1] речь не о том, чтобы заменить все зависимости, а только хвост мелких второстепенных.

В этом месяце мы путешествуем. Поэтому время наедине с лаптопом ограничено. Поэтому я и завел codex демонов на linux сервере. Самое главное, наконец, доделал новую версию full-stack event-driven BDD фреймворка, про который обсуждали на вебинарах по AI Coding. Про подход к BDD спекам в продуктах (еще в эру до LLM) я рассказывал в этой истории. Сейчас получилось сделать их full-stack, привязать к UI компонентам (например, через go templ) и свалить работу по написанию и поддержанию на Codex. Скорость я сильно не оптимизировал, спеки запускаются на одном ядре, поэтому получается прогонять "всего" тысячу спеков в секунду). Когда спеков будет больше тесячи - добавлю параллелизм, ибо дольше секунды гонять все базовые бизнес-тесты - для меня недопустимо. И когда есть такие спеки, давать с мобилики задачи кодексу на "напиши спеки под такую фичу" и "а теперь реализуй эти спеки" - одно удовольствие! Даже когда спеки про такие заунывные вещи, как GDPR-compliant email opt-in. А сам код в проекте на скриншоте - от будущей платформы для AI Coding коммьюнити. Ваш, @llm_under_hood 🤗

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

"Это зачем еще? Сначала напиши алгоритм на бумажечке, а потом уже переноси в компьютер."

Тогда это вполне имело смысл, ведь еще не было IDE с автоподстановками/автопроверками, программы занимали килобайты, не гигабайты, а в НИИ даже встречались перфокарты. Но важен еще один момент: чтобы писать код эффективнее, сначала нужна какая-то канва. Сначала обходились просто детальным ТЗ на работы. Затем придумали разные подходы, которые помогают создавать код не просто с чистого листа, а на какой-то основе. Я имею в виду Test-Driven Development (TDD), когда в основе правильного кода лежат успешные тесты, Behavior-Driven Development (BDD), когда в основе кода - конкретные сценарии. И прочие DD. Появление ИИ-помощников в работе повлияло на эти процессы. Несколько месяцев назад GitHub представил подход Spec-Driven Development (SDD). Суть в том, чтобы сначала создать спецификацию, затем скормить ее ИИ-агенту, на ее основе будет составлен план работ и потом строго по плану реализация.

Spec → Plan → Tasks → Implement

То есть теперь не просто пишем промпт "Нарисуй форму", а описываем цели, поведение, граничные условия, исключения и т.д. Для претворения этого дела в жизнь они опубликовали опенсорсный инструментарий - Spec Kit. Поддерживается 35 кодинговых агентов, имеет 138 расширений, может работать оффлайн. В репозитории есть ссылки на обзоры и сообщества. 123 тысячи звезд на Гитхабе, 257 контрибьюторов. #process