От вайб-кодинга к AI-инжинирингу на примере простого агента
#diy #ai
Я в целом не особо силен во всяких кастомных обвязках и супер-навороченных практиках AI инжиниринга. Моя роль позволяет в целом
быдлокодить делать прототипы, особо не считать токены и в целом обычно хватало просто спеки
Spec.md и агента в виде чата. Так что я решил поиграться с чем-то более продуманным и заодно тут рассказать.
Для примера взял
скиллы Addy Osmani, чисто из-за предвзятости, это очень крутой чел, его суждениям я доверию (но в целом наверняка можно было взять и
Superpowers либо
скиллы Matt Pocock). Суть в том, что это не просто набор скиллов, а изменение всего подхода к agentic разработке. Что-то вроде Spec -> Plan -> Build -> Test -> Review -> Simplify -> Ship.
Слишком томить не буду, дам наводку, а дальше LLM сама лучше расскажет-покажет. В последнее время я новые прикладные темы изучаю генерацией короткого мини-тьюториала в нашем либимом формате HTML. В данном случае я взял идею простенького агента-консультанта по путешествиям и попросил Gemini создать тьюториал о том, как разработать такого агента в стиле Addy Osmani:
I've got a high-level idea of a travel assistant agent. Create an HTML course illustrating the development of such an agent with
https://github.com/addyosmani/agent-skills and agents-cli, create sub-pages for each meaningful chapter (e.g. Spec -> Plan -> Build -> Test -> Review -> Simplify -> Ship), write code and make it copy-pastable so that I can follow the tutorial and go through the whole development process myself.
Сначала gemini сам реализовал простенького агента, затем использовал это решение как референс для мини-курса.
Далее мини-курс сам тебя ведет через все этапы разработки:
1) Определяем спеку, отвечаем на вопросы агента, что мы вообще хотим от продукта. Спека появляется не одна, а несколько – по одной на каждый компонент будущего решения
/spec Build a travel concierge agent with Google ADK, scaffolded and evaluated with agent-cli. It must... <high-level idea pitch>
После ответов на вопросы появится
Spec.md и spec-*.md для компонентов.
2) Далее запускаем планирование
/plan Use
SPEC.md and the architecture we just agreed
Появляются
plan.md и конкретный
todo.md со списком всех задач, acceptance criteria, плана проверки и файлов на выходе. Все в стиле TDD, то есть начиная с тестов.
3) Далее Build, либо вдумчиво по одной фиче из списка
todo.md, либо сразу
/build auto
и почитывать, как он сам все по очереди реализует, тестирует и обновляет Todo.
4) И в конце финальные проверки и еще пара скиллов для упрощения кода. До Ship в данном случае не дошло 👨🦳
Что понравилось
- так на выходе, конечно, решение куда более продуманное, с кучей тестов, покрытыми корнер-кейсами (например,
а что если ты путешествуешь с мелким ребенком, наверное не надо советовать маршрут с прогулками дольше 10 минут). И документация получается сама собой, попутно с разработкой
- далее улучшать решение тоже понятно как – спека уже лежит, фичи детально описаны, надо просто в том же формате добавлять новые фичи и следовать тому же процессу, что описан выше
Ограничения
- уходит больше времени и токенов, конечно. В моем случае 3 часа вместо 5 минут (хотя да, решение сильно более продуманное на выходе).
- На эвалах может много токенов погореть. Да, агент сам помимает, где какие тесты нужны (юнит/интеграционные, а где LLM-as-a-Judge), но также из-за какой-то банальной мелочи типа несовпадающих сигнатур функций у tools может решить перезапустить весь LLM-as-a-Judge для какой-то фичи, а это и генерация синтетических данных, например, и эвал, то есть лекто минут 20 и 120 тыс токенов на один этап
- Душновато получается, все же спеки, планы и todo – это много текста, который надо проверять. Для большого проекта на всю команду – да, можно даже продакта посадить, вместе отвечать на вопросы LLM. Но для мелких одноразовых вещей типа кастомного UI или демки навыброс я по-прежнему буду вайбкодить 😮💨
