Агентное программирование стало новой волной в автоматизации рабочих процессов разработки программного обеспечения. Многие специалисты с энтузиазмом принимают такие инструменты, которые обещают значительно упростить выполнение рутинных задач и повысить продуктивность. Однако, несмотря на похвалу и множество загрузок, не всегда получается добиться ожидаемых результатов. Армин Ронахер — известный разработчик и эксперт в области ИИ и программирования — откровенно рассказал о том, что именно у него не сработало при использовании концепций агентного кодирования и связанных с ними инструментов. Популярность агентного программирования связана с возможностью делегировать часть рутинных или повторяющихся задач интеллектуальным помощникам.
Такие агенты, как Claude Code и аналогичные системы, могут воспринимать ваши команды, анализировать контекст и самостоятельно выполнять операции, экономя время и снижая вероятность ошибок. Но как показывает практика, даже самые многообещающие технологии требуют тщательной настройки и понимания ограничений, иначе они превращаются в источник разочарований и отнимают дополнительное время. Одна из главных проблем, с которой столкнулся Ронахер, связана с правилом автоматизации. Он ориентируется на автоматизацию только тех процессов, которые выполняет регулярно. Если такая автоматизация оказывается неиспользуемой или не приносит ощутимой пользы, он считает её провальной и удаляет.
Это позволяет избежать захламления рабочей среды неактуальными командами, а также избежать путаницы при совместной работе и снижает когнитивную нагрузку. Это правило иллюстрирует важную деталь: автоматизация без регулярного применения бесполезна. Часто бывает так, что создаваемый агент или команда вызывают интерес на старте, но вскоре забываются или вызывают необходимость постоянной доработки. Результат — пустая трата ресурсов. Поэтому важно всегда критически оценивать выгоду от внедрения таких инструментов внутри своего рабочего процесса.
Ронахер подробно рассказал о своем опыте с использованием slash-команд — функциональности, позволяющей заранее загружать шаблоны команд и быстрее действовать в пределах сессии. Хотя изначально он возлагал на них большие надежды, их полезность оказалась далеко не очевидной. В частности, ограниченный и неструктурированный способ передачи аргументов к slash-командам значительно усложняет работу с ними, особенно в ситуациях, когда нужна точная подстановка названий файлов или других переменных. Проблему усугубляет невозможность использования файлового автозаполнения для аргументов. Например, если приходится писать имя файла вручную для обработки грамматических ошибок, процесс становится неудобным и требует лишних действий.
В качестве решения Ронахер часто заставляет Claude ориентироваться на текущее состояние Git-репозитория. Это позволяет автоматически выявлять изменённые или новые файлы, избегая необходимости явного указания их в командах. Несмотря на то, что он создал и тестировал множество slash-команд, таких как фиксация багов с учетом контекста из GitHub, автоматическая генерация сообщений коммитов, добавление тестов и исправление мелких ошибок, большинство из них не прижились. Например, идеи автонаписания коммитов полностью не оправдали себя, поскольку создаваемые сообщения не соответствовали стилю автора. Подход с генерацией тестов был вдохновляющим, но в итоге результаты оказались не лучше существующих автоматических средств.
Хороший пример неэффективности — команда для выбора следующей задачи в списке дел, которая оказалась менее полезной, чем прямое взаимодействие с файлами. Таким образом, несмотря на присутствие технологий для автоматизации, Ронахер всё чаще возвращается к более простым и интуитивным методам работы, таким как голосовой ввод и традиционное копирование-вставка. Голосовое управление по его признанию — наиболее эффективная и удобная форма взаимодействия, которая позволяет более полно выражать мысли и уточнять запросы, делая коммуникацию с агентом живой и гибкой. Попытки использовать хуки для интеграции в процессы сборки или запуска также не принесли существенных улучшений. Основной барьер — режим работы «yolo», в котором запрещающие правила не работают, из-за чего сложно программировать последовательность выполнения или выбор инструментов.
В итоге Ронахер использовал обходные пути, такие как предзагрузка специальных скриптов и изменение системного пути, чтобы заставить агента использовать нужные утилиты. Тем не менее, ожидания по автоматической работе с форматированием и запуском проверок, разделяя сессии и обработку, не оправдались, и эти функции остались малоиспользуемыми. Еще одной перспективной, но пока недоработанной функцией для него стала «Print Mode» — режим, позволяющий создавать детерминированные скрипты с минимальным компонентом генерации данных при помощи ИИ. Идея состоит в том, чтобы отделить автогенерацию сообщений коммитов от исполняемых скриптов и добиться максимальной предсказуемости и контроль над результатами. Но медленная работа, сложность отладки и нестабильность работы заставляют пока ограниченно использовать этот режим.
Что касается параллельности и изоляции контекста, то использование подзадач и подагентов оказалось не так эффективно, как хотелось бы. Подзадачи хорошо справляются с независимыми вычислениями, но при необходимости смешанного доступа к данным они создают сложную и непредсказуемую ситуацию. В результате Ронахер предпочитает создавать новые сессии и фиксировать мысли в отдельных Markdown-файлах, а также переключаться на разные режимы диалогов для улучшения результатов. Все эти наблюдения показывают, что автоматизация рабочих задач с использованием ИИ и агентных инструментов не является панацеей. Важным моментом остается человеческий фактор — регулярное использование и тщательная оценка результативности внедрённых автоматизаций.
Без последовательного подхода от таких инструментов появляется больше вреда, чем пользы. Легко потерять контроль и перестать осознавать процесс, что приводит к ошибкам и снижению качества. Армин Ронахер подчеркивает, что главная польза от автоматизации в том, чтобы улучшить, а не заменить мышление инженера. Он не использует излишнюю формализацию, не вводит шаблонов для коммитов или PR, предпочитая дать ИИ больше контекста и свободы реагировать на задачи с учётом естественной речи и текущей ситуации. Это позволяет избегать чрезмерного усложнения и поддерживать гибкость работы с агентом.
Однако даже при всех усилиях работу с контекстом, то есть правильной подстановкой данных и поддержанием актуальной информации, назвать полностью надёжной нельзя. Слишком длинные сессии приводят к утере начальной информации, несмотря на возможные техники управления контекстом или статические подсказки. Немаловажным фактором становится и то, что сам ИИ нередко проявляет непредсказуемое поведение в зависимости от объёма и качества введённых данных. В итоге Ронахер придерживается жесткой методики: если он собирается автоматизировать задачу, то сначала выполняет её вручную несколько раз, после чего сравнивает результаты с тем, что выдал ИИ. Только после трёх проверок он решает, стоит ли полагаться на созданный агент.
При этом в его голове постоянно присутствует осознание необходимости сохранять внимание и контроль, чтобы не упустить потенциальные ошибки и не снизить собственное мастерство. Заключение, которое следует из опыта Армина Ронахера, состоит в том, что агентное программирование — это мощный инструмент, требующий аккуратного и осознанного применения. Оно не заменяет инженера и не должно превращать разработчика в пассивного наблюдателя. Вместо этого следует использовать ИИ как помощника, который помогает, но при этом не снимает с пользователя ответственность и необходимость думать. Для тех, кто только начинает внедрять агентные инструменты в свои процессы, полезно помнить о важности настройки под собственные регулярные задачи, отслеживании эффективности автоматизаций и не боязни отказываться от неработающих подходов.
Только так можно построить действительно продуктивный, адаптивный и сбалансированный рабочий процесс, где технологии служат человеку, а не наоборот.
![JavaScript Haikus: My Adventures in Tiny Coding (2023) [video]](/images/F9FFB127-35EC-4C87-8076-07E40297966A)
