От вайб-кодинга к AI-инжинирингу: методология разработки агентов

От вайб-кодинга к 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 или демки навыброс я по-прежнему буду вайбкодить 😮‍💨