Я не очень люблю использовать готовые библиотеки для решения специфичных задач [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