Замедлитесь, это ответ на эпоху агента

Оригинальный заголовок: Размышления о том, как замедлиться как следует
Оригинальный автор: Марио Зехнер
Перевод: Пегги, BlockBeats

Примечание редактора: По мере того, как генеративный ИИ ускоряется в области программной инженерии, настроения в отрасли меняются с "потрясения от возможностей" на "тревогу по поводу эффективности". Недостаточно быстрый темп написания кода, недостаточное использование, недостаточная автоматизация — все это, похоже, создает ощущение устаревания. Однако, когда агенты-программисты действительно входят в производственную среду, начинают возникать более практические проблемы: ошибки увеличиваются, сложность выходит из-под контроля, системы становятся все более непрозрачными, а повышение эффективности не пропорционально переходит в повышение качества.

На основе практики работы на передовой, в этой статье представлен трезвый взгляд на текущую тенденцию "агентного программирования". Автор отмечает, что агенты не учатся на ошибках так, как это делают люди; при отсутствии узких мест и механизмов обратной связи небольшие проблемы быстро усугубляются. В сложных базах кода их локальная перспектива и ограниченная способность к запоминанию еще больше усугубляют беспорядок в структуре системы. Суть этих проблем заключается не в самой технологии, а в том, что люди преждевременно отказываются от суждения и контроля под влиянием тревоги.

Поэтому, вместо того чтобы погружаться в тревогу о том, "должны ли мы полностью принять ИИ", лучше пересмотреть отношения между людьми и инструментами: пусть агенты берут на себя локальные, контролируемые задачи, в то время как проектирование системы, обеспечение качества и ключевые решения остаются в наших руках. В этом процессе "замедление" становится способностью; это означает, что вы все еще понимаете систему, можете идти на компромиссы и сохранять чувство контроля над своей работой.

В эпоху развития инструментов, действительно дефицитным может оказаться не более быстрые генеративные возможности, а суждение о сложности и твердость в выборе между эффективностью и качеством.

Ниже приведен исходный текст:

Выражение на лице черепахи - это то, как я смотрю на эту индустрию

Примерно год назад начал появляться настоящий программистский агент, который мог бы помочь вам «завершить весь проект от начала до конца». Ранее существовали такие инструменты, как Aider и ранний Cursor, но они были скорее помощниками, чем «агентами». Новое поколение инструментов очень привлекательно, и многие люди потратили много своего свободного времени на реализацию всех проектов, которые они всегда хотели реализовать, но никогда не находили на это времени.

Я не думаю, что это проблема сама по себе. Делать что-то в свободное время по своей природе радостно, и большую часть времени вам действительно не нужно заботиться о качестве кода и его поддерживаемости. Это также дает вам возможность изучить новый стек технологий.

В рождественский праздничный сезон Anthropic и OpenAI также выпустили некоторые "бесплатные кредиты", привлекая людей, как игровой автомат. Для многих это был первый настоящий опыт магии "кодирования агентов". Участие растет.

В настоящее время кодирование с помощью агента также начинает проникать в производственные базы кода. Прошло двенадцать месяцев, и мы начинаем видеть последствия этого "прогресса". Вот мои текущие мысли.

Все разваливается

Хотя большая часть этого является анекдотичной, текущее программное обеспечение действительно дает ощущение, что оно "вот-вот сломается" в любой момент. Доступность в 98% переходит из разряда исключения в норму, даже для крупных сервисов. Пользовательский интерфейс наполнен всевозможными абсурдными ошибками, которые команда QA должна была заметить с первого взгляда.

Я признаю, что эта ситуация существовала до появления Агента. Но теперь проблема явно ускоряется.

Мы не можем видеть истинное состояние внутри компаний, но иногда происходят утечки информации, например, слухи о "отключении AWS, вызванном ИИ". Amazon Web Services оперативно "исправили" заявление, но затем немедленно начали 90-дневный план реорганизации внутри компании.

Сатья Наделла (генеральный директор Microsoft) также недавно подчеркнул, что все больше и больше кода в компании пишется ИИ. Хотя нет прямых доказательств, действительно есть ощущение: качество Windows снижается. Даже из некоторых блогов, опубликованных самой Microsoft, кажется, что они молчаливо признали это.

Компании, которые заявляют, что «100% продукта генерируется ИИ», почти всегда в итоге выпускают худшие продукты, которые только можно себе представить. Не для того, чтобы указывать пальцем, но такие вещи, как утечки памяти гигабайтами, хаос в пользовательском интерфейсе, отсутствие функций, частые сбои... ничто из этого не то, что они считали «подтверждением качества», не говоря уже о положительной демонстрации «давайте Агент сделает все за вас».

Частным образом, вы будете слышать все чаще и чаще как от крупных компаний, так и от небольших команд, говорящих одно: они были загнаны в угол "агентским кодированием". Без обзора кода, передачи решений по дизайну Агенту, а затем добавления кучи ненужных функций — очевидно, что это не может закончиться хорошо.

Почему мы не должны использовать Агента таким образом

Мы почти полностью отказались от всей инженерной дисциплины и субъективного суждения, вместо этого попав в "зависимый" способ работы: есть только одна цель — генерировать как можно больше кода за кратчайшее время, абсолютно не заботясь о последствиях.

Вы строите вспомогательный слой для управления армией автоматизированных Агентов. Вы установили Beads, но совершенно не подозреваете, что это по сути "вредоносное ПО", которое нельзя удалить. Вы делаете это только потому, что в онлайн-источниках написано, что "все так делают". Если вы не делаете этого, вы "ngmi" (не добьетесь успеха).

Вы постоянно самопоглощаетесь в "петле в стиле матрешки".

Послушайте — Anthropic создала компилятор C с использованием группы агентов, хотя сейчас у него все еще есть проблемы, модель следующего поколения наверняка сможет это исправить, верно?

А теперь представьте: Курсор создал браузер с использованием большой группы агентов, хотя сейчас он практически не пригоден для использования и все еще требует периодического ручного вмешательства, но модель следующего поколения наверняка сможет справиться с этим, верно?

"Распределенный", "Разделяй и властвуй", "Автономные системы", "Фабрика черного света", "Шесть месяцев на решение проблемы с программным обеспечением", "SaaS мертв, моя бабушка только что создала магазин Shopify с помощью Claw"...

Эти нарративы звучат захватывающе.

Конечно, такой подход действительно может "по-прежнему работать" для вашего почти неиспользуемого (включая вас самих) второстепенного проекта. Возможно, действительно существует гений, который может использовать этот метод для создания действительно полезного программного продукта, а не мусора. Если вы такая личность, то я искренне восхищаюсь вами.

Однако, по крайней мере в моих разработческих кругах, я еще не видел действительно эффективного случая использования этого метода. Конечно, возможно, мы все просто слишком неопытны.

Накопление ошибок в отсутствие обучения, отсутствие узких мест и отложенные взрывы

Проблема с агентами заключается в том, что они совершают ошибки. Это само по себе не так уж и важно; люди тоже совершают ошибки. Это могут быть просто ошибки в корректности, которые легко выявить и исправить, и добавление регрессионного теста делает его еще более стабильным. Это также могут быть некоторые проблемы с кодом, которые линтеры не могут обнаружить: здесь неиспользуемый метод, там необоснованный тип, дублированный код и так далее. В отдельности это не так уж и важно, и человеческие разработчики тоже совершают такие мелкие ошибки.

Но "машины" - это не люди. После того как человек несколько раз совершает одну и ту же ошибку, он обычно учится не повторять ее — либо его ругают, либо он меняется в процессе обучения.

Агенты не обладают способностью к обучению, по крайней мере, не по умолчанию. Они будут повторять одну и ту же ошибку снова и снова и могут даже «создавать» удивительные комбинации различных ошибок на основе данных обучения.

Конечно, вы можете попытаться их «обучить»: написать правила в AGENTS.md, чтобы они не повторяли такие ошибки; разработать сложную систему памяти, чтобы они могли обращаться к историческим ошибкам и лучшим практикам. Это действительно эффективно при решении определенных типов задач. Но предпосылка такова: вы должны сначала заметить, что он допустил эту ошибку.

Ключевое различие заключается в следующем: Человек — это узкое место; Агенты — нет.

Человек не может выплюнуть двадцать тысяч строк кода за несколько часов. Даже при не очень низком уровне ошибок за день можно ввести только конечное количество ошибок, и их накопление происходит медленно. Обычно, когда "боль от ошибок" достигает определенного уровня, люди (из-за инстинктивного неприятия боли) делают паузу, чтобы исправить ошибки. Или их заменяют, и кто-то другой их исправляет. В любом случае, проблема решается.

Однако, когда вы развертываете целую армию хорошо организованных агентов, нет узкого места и нет "ощущения боли". Эти изначально незначительные ошибки накапливаются с неустойчивой скоростью. Вы были исключены из процесса, не подозревая, что эти кажущиеся безобидными сбои превратились в гиганта. К тому времени, когда вы действительно почувствуете боль, обычно уже слишком поздно.

Это происходит только тогда, когда однажды вы пытаетесь добавить новую функцию и обнаруживаете, что текущая архитектура системы (по сути, стопка ошибок) не может вместить изменения, или пользователи начинают яростно жаловаться, потому что в последнем выпуске есть проблемы, или, что еще хуже, потеряны данные.

Именно в этот момент вы понимаете: Вы больше не можете доверять этой базе кода.

Хуже того, тысячи и тысячи модульных тестов, тестов снимков, комплексных тестов, сгенерированных Агентами, также ненадежны. Единственный способ оценить, "корректно ли функционирует система", - это ручное тестирование.

Поздравляем, вы загнали себя (и свою компанию) в тупик.

Торговец сложностью

Вы полностью потеряли представление о том, что происходит в системе, потому что передали контроль Агентам. И в принципе, агенты занимаются «продажей сложности». Они видели множество ужасных архитектурных решений в своих обучающих данных и постоянно укрепляли эти шаблоны в процессе обучения с подкреплением. Вы позволили им спроектировать систему, и результат оказался таким, как и ожидалось.

В итоге получается крайне запутанная система, сочетающая в себе различные слабые подражания «передовому опыту в отрасли», и вы не накладывали никаких ограничений, пока проблемы не вышли из-под контроля.

Но проблемы на этом не заканчиваются. Ваши Агенты не делятся процессами выполнения друг с другом, не могут видеть полный код и не имеют представления о решениях, которые вы или другие Агенты приняли ранее. Следовательно, их решения всегда "локальны".

Это напрямую приводит к вышеупомянутым проблемам: обилию дублирующегося кода, чрезмерно абстрактным структурам ради абстракции, всевозможным несоответствиям. Эти проблемы усугубляются, в конечном итоге приводя к неизлечимо сложной системе.

Это на самом деле довольно похоже на код базы уровня предприятия, написанный человеком. Единственное отличие заключается в том, что этот вид сложности обычно является результатом многолетнего накопления: боль распределяется между большим количеством людей, каждый из которых не достиг порогового значения "необходимо исправить", сама организация обладает высокой устойчивостью, поэтому сложность и организация "развиваются совместно".

Однако в случае сочетания человека и Агента этот процесс будет значительно ускорен. Двое людей плюс множество Агентов могут достичь этого уровня сложности за считанные недели.

Коэффициент восстановления поиска Агента низкий

Вы можете надеяться, что Агенты "уберут за вами беспорядок", помогут вам изменить структуру, оптимизировать и сделать систему чище. Но проблема в том, что они больше не могут этого сделать.

Потому что база кода слишком велика, а сложность слишком высока, и они могут видеть только часть из нее. Это не просто вопрос того, что контекстное окно недостаточно большое или что механизм долгого контекста не справляется с миллионами строк кода. Проблема более коварна.

Прежде чем Агент попытается исправить систему, он должен сначала найти весь код, который нужно изменить, а также существующие реализации, которые можно использовать повторно. Этот шаг мы называем агентурным поиском.

То, как Агент это делает, зависит от инструментов, которые вы ему даете: это может быть Bash + ripgrep, это может быть индексируемый код, служба LSP, векторная база данных...

Но независимо от используемых инструментов, суть одна и та же: чем больше кодовой базы, тем ниже коэффициент обнаружения. А низкий коэффициент обнаружения означает: Агент не может найти весь соответствующий код и, естественно, не может внести правильные изменения.

Именно поэтому изначально появляются эти незначительные ошибки "запаха кода", он не нашел существующую реализацию, поэтому он изобретает велосипед заново, вводит несоответствие. В конечном итоге эти проблемы будут продолжать распространяться, перекрываться и расти в крайне сложное "гнилое растение".

Как нам этого избежать?

Как нам сотрудничать с агентами (по крайней мере, на данный момент)

Работа с агентами похожа на взаимодействие с морским чудовищем, с его невероятно быстрой скоростью генерации кода и таким "перемежающимся, но иногда поразительным" интеллектом, который затягивает вас. Они часто могут выполнять простые задачи с поразительной скоростью и высоким качеством. Настоящая проблема начинается, когда у вас возникает идея: «Это слишком мощная штука, компьютер, сделай работу за меня!»

Передача задач самому Агенту, конечно, не проблема. Хорошие задачи для Агента обычно обладают рядом характеристик: область применения может быть четко определена, нет необходимости понимать всю систему; задача замкнута, то есть Агент может самостоятельно оценить результаты; выход не находится на критическом пути, это просто временные инструменты или программное обеспечение для внутреннего использования, это не повлияет на реальных пользователей или доход; или вам просто нужна «резиновая утка», чтобы помочь вам думать — по сути, это взятие ваших идей и столкновение их со сжатыми знаниями из интернета и синтетическими данными.

Если эти условия выполнены, то это задача, подходящая для передачи Агенту, при условии, что вы, как человек, по-прежнему остаетесь конечным контролером качества.

Например, использование метода автоматического исследования Андрея Карпати для оптимизации времени запуска приложения? Отлично. Но важно понимать, что генерируемый им код ни в коем случае не готов к производству. Автоисследование эффективно, потому что вы предоставили ему функцию приспособленности для оптимизации по определенному метрику (например, времени запуска или потере). Однако эта функция приспособленности охватывает только очень узкий аспект. Агент смело игнорирует все метрики, не включенные в функцию приспособленности, такие как качество кода, сложность системы и в некоторых случаях даже корректность, если ваша функция приспособленности сама по себе имеет недостатки.

Основная идея на самом деле довольно проста: позвольте Агенту выполнять скучные, не связанные с обучением задачи или исследовательскую работу, которую у вас никогда не было времени попробовать. Затем оцените результаты, выберите действительно разумные и правильные части и завершите окончательную реализацию. Конечно, вы также можете использовать Агента, чтобы помочь с этим последним шагом.

Но то, что я действительно хочу подчеркнуть, это: действительно, немного замедляйтесь.

Уделите себе время, чтобы подумать о том, что вы делаете и почему вы это делаете. Дайте себе возможность сказать «нет, нам это не нужно». Установите четкий лимит для Агента: сколько кода он может генерировать в день, количество, которое должно соответствовать вашим реальным возможностям по его проверке. Все части, определяющие «общую форму» системы, такие как архитектура, API, должны быть написаны вами. Вы можете использовать автозаполнение, чтобы почувствовать «написание кода вручную», или заниматься совместной программированием с Агентом, но главное: вы должны быть в коде.

Потому что написание кода самостоятельно или наблюдение за его созданием шаг за шагом создает своего рода «трение». Именно это трение помогает вам четче понимать, что вы хотите сделать, как работает система и каково общее «ощущение». Здесь на помощь приходят опыт и «чувство», и именно это самые передовые модели пока заменить не могут. Замедлите темп, потерпите некоторое трение – именно так вы учитесь и развиваетесь.

В итоге у вас все равно будет поддерживаемая система, - по крайней мере, не хуже, чем до появления Агента. Да, и прошлые системы тоже были неидеальны. Но ваши пользователи поблагодарят вас, потому что ваш продукт «используем», а не куча кое-как собранной ерунды.

У вас будет меньше функций, но они будут более корректными. Научиться говорить «нет» — это уже само по себе навык. Вы также можете спать спокойно, потому что вы все еще знаете, что происходит в системе, вы все еще контролируете ситуацию. Именно это понимание позволяет вам решить проблему вызова агента поиска, делая вывод Агента более надежным и требующим меньше исправлений.

Когда система выходит из строя, вы можете испачкать руки, чтобы ее починить; когда дизайн был ошибочным с самого начала, вы можете понять проблему и изменить ее к лучшему. На самом деле, важно ли наличие агента или нет, не так уж важно.

Все это требует дисциплины. Все это неотделимо от людей.

[Оригинальная статья]