Программирование меняется, и в последние годы темпы изменений становятся все быстрее. Большие языковые модели (LLMs) становятся удивительно умными, а агенты интегрируются повсюду. Нельзя не пытаться избежать этого. Хотя я продвинутый пользователь современных инструментов LLM, я сильно сомневался в инженерии агентов. Ах, как же я ошибался. Я попробовал подход stdlib, который перевернул мое представление с ног на голову.
Предыстория
Недавно я опубликовал статью о своем подходе к использованию ИИ в повседневной разработке. В двух словах, я обращаюсь к LLM, общаюсь и создаю спецификации. Затем я сохраняю их в файл в папке проекта, предоставляя их LLM в редакторе, чтобы он мог лучше автозаполнять. Я верил в инженерию с поддержкой ИИ, но не верил в агентов.
Я пытался использовать режим агента в Cursor AI, Windsurf и Goose, но был разочарован результатами, потому что они были далеки от идеала. Он допускал ошибки и не мог их исправить, использовал много кредитов API и выдавал непоследовательные результаты. Я не мог представить, как интегрировать эти подходы в свою повседневную рабочую практику.
Недавно я наткнулся на вы используете Cursor AI неправильно… и решил протестировать это, опубликовав немного подзабытую идею библиотеки управления разрывами цепей brama. Я смог разработать полностью работающую библиотеку под моим надзором, что лучше, чем если бы я делал это в одиночку.
Объяснение подхода stdlib
Джеффри Хантли представил серию статей о подходе «stdlib». Он объясняет, как он использует агентов и режим Cursor Agent. Это очевидно, если задуматься. Подумайте о вводе нового коллеги-инженера в ваш проект. Вы предоставляете спецификации и документацию (если она доступна, конечно) проекта, даете (или обучаете) инженерные рекомендации и подходы, а затем даете небольшую и детализированную техническую задачу для выполнения. Почему? Потому что, когда он предоставляет результат, вы можете дать обратную связь, чтобы он мог корректировать и учиться. И постепенно, когда результаты consistently good, вы даете более сложные задачи.
Именно так работает stdlib, но вместо нового человеческого коллеги у вас есть новый синтетический помощник. Вы записываете документацию и спецификации и технические правила, даете ему задание и он сам проверяет и перерабатывает, если это необходимо. По модели любое мыслительное моделирование будет работать, но Sonnet 3.7 – лучший, по моим наблюдениям.
Структура:
1. Запишите правила/рекомендации
- Это включает написание списка всесторонних правил, которые могут быть применены к вашему проекту.
- Подумайте о том, как обучить ребенка собирать велосипед. Вы берете ключ и объясняете, что это такое и как его использовать.
- Например, поворачивайте вправо, чтобы затянуть болт, это педаль, и вы ставите ее сюда и т. д.
- Это похоже на то, что некоторые компании имеют в качестве инженерной книги правил.
2. Обеспечьте богатый контекст через максимально детализированные спецификации
- Запишите полную документацию или спецификации.
- Это следует рассматривать очень тщательно, потому что это должно включать все критические размышления, которые у вас есть.
- Ошибки в проектировании и недочеты могут устранить все достижения, которые делают агенты при выполнении работы.
- Включите критерии приемки, детальные объяснения, контекст, примеры и четкие цели.
- Представьте, что вы передаете задачу другому младшему инженеру и делаете свои ожидания совершенно ясными.
3. Вставьте правила и спецификации в контекст агента и создайте цикл
- Здесь происходит выполнение.
- Загрузите все «как выполнять» и «что выполнять» в контекстное окно.
- Строго типизированные языки выигрывают больше всего, но и другие могут работать.
- Когда вы сталкиваетесь с любым неправильным поведением, редактируйте правила или спецификации, чтобы обучить агента делать лучше.
- В настоящее время Claude 3.7 Sonnet лучше всего подходит для этой работы.
- Повторяйте до тех пор, пока работа не будет выполнена.
Кейс: реализация brama
Чтобы протестировать подход, я решил реализовать библиотеку разрывов цепей, о которой я давно думал, так как реализовал элементарную в своей текущей работе. Здесь на помощь приходит brama.
Разрыв цепей – это относительно простой шаблон, который помогает нашим системам предотвращать каскадные сбои, временно блокируя доступ к неисправным сервисам или ресурсам.
defmodule PaymentService do
use Brama.Decorator
@decorate circuit_breaker(identifier: "payment_api")
def process_payment(payment) do
PaymentAPI.process(payment)
end
end
Результат
Когда я впервые прочитал статью Джеффри, я был очень заинтригован. Итак, я начал с технических спецификаций. Я использовал подход, который применяю каждый день, и мозговой штурм с Claude. Я разработал ясный набор спецификаций, API и примеров. Я правильно его настроил, и через 15 минут у меня были спецификации.
Часть с правилами заняла у меня несколько часов. Это был осторожный процесс, изначально потребовавший некоторое время, потому что мне нужно было изложить свой подход к инженерии. Я использовал довольно упрощенный набор правил. Я взял некоторые из архивированных лучших практик Erlang и собрал их в правила Cursor + свои собственные. В процессе реализации я добавил некоторые правила, такие как полное решение и запрет на использование макросов. Я все еще хочу улучшить их и извлечь в репозиторий, чтобы постоянно улучшать и повторно использовать в других проектах.
Затем я записал команду, подчеркивая, что агент должен изучить правила и спецификации, реализовать недостающие части и проверить результат, компилируя и запуская типовые спецификации и тесты. Я нажал Enter.
Команда:
Изучите @SPECS.md для функциональных спецификаций.
Изучите @rules для технических требований
Реализуйте то, что не реализовано
Создайте тесты
Запустите "mix compile --warnings-as-errors" и проверьте, работает ли приложение
Запустите "mix credo" и устраните ошибки линтинга
Запустите "mix test" и устраните ошибки тестов
Запустите "mix dialyzer" и устраните предупреждения от dialyzer
Было очень интересно видеть, как он выдает результаты. Он реализовал первую версию, включая тесты, за несколько минут. Он пытался скомпилировать, но, очевидно, это не сработало. Затем он минуту думал, что пошло не так, и снова пытался исправить это, и снова, и снова. Компиляция прошла, и он попытался запустить 76 написанных тестов. Все они провалились, но постепенно, один за другим, он исправил код. И вот, у меня есть полностью рабочая библиотека.
Обучение
Несмотря на то что было очень весело видеть, что это работает, мне пришлось время от времени нажимать «продолжить», потому что он автоматически останавливается после 25 действий. После трех попыток исправить типы или тесты подряд он их игнорировал. Очевидно, это было одной из правил, которые я добавил. Никогда не пропускайте тесты и убедитесь, что результат соответствует спецификациям. Первый подход с декораторами был полностью сломан, и все тесты были проигнорированы. Я не упомянул в спецификациях, что я хочу использовать библиотеку декораторов вместо написания своей реализации. Вот так и появилась еще одно правило – никогда не пишите макросы, если это не указано явно. Макросы сложны в Elixir, и, конечно, это означает, что в интернете не так много примеров кода, из которых LLM могли бы научиться делать это правильно. Я снова переработал спецификации с Claude и попросил переимлементировать решение, что сработало. Теперь, когда я на это смотрю, я понимаю, что мне нужно было разбить работу на управляемые задачи. Например, я мог начать сначала с основной функциональности, затем с системы уведомлений, и только потом с декораторами. Мне было бы гораздо легче контролировать это, и агенту было бы легче и быстрее это выполнить.
Пересмотренный подход
В ближайшие недели я хочу отточить этот подход. Структура должна включать набор команд для реализации, спецификаций и правил. Она также должна включать единый способ валидации и, вероятно, включать точно настроенный LLM, который должен будет проверять конечный результат агента. Инженер-агент будет общаться с ревьюером-агентом. Это безумие, если учесть, как быстро и далеко мы продвинулись за последние два года.
Само выполнение должно быть автоматизировано. Рассмотрите интеграцию с системой учета задач, такой как GitHub, где агент берет задачи и пытается их реализовать.
Хотя агент справился с этим всего за час, это можно улучшить еще больше, учитывая, что на самом деле было три задачи вместо одной. Я легко могу представить параллельное выполнение в таких проектах, как Cursor, в ближайшем будущем.
Заключительные мысли
Этот эксперимент сделал меня сторонником разработки с помощью агентов. Наша отрасль собирается радикально измениться за два года или даже быстрее. Экспоненциально быстрее выполнение будет требовать от бизнеса адаптации и генерации новых идей. Наша профессия и способ нашей работы будут выглядеть иначе. Нам нужно найти способы интеграции в существующие команды и проекты. Команды и процессы должны адаптироваться.
Этот сдвиг парадигмы потребует от нас новых навыков: стать лучше в формулировании спецификаций, кодификации инженерных принципов и делении сложных задач на управляемые части. Инженеры, которые овладеют этими мета-навыками, возглавят эту трансформацию.
Должны ли мы бояться этого? Конечно, нет! Это не конец инженерии программного обеспечения – это ренессанс.
