AI-агенты больше не теряются в коде — и это медленно убивает рефакторинг
AI Agents and the Refactoring That Never Happens
Автор, работающий с AI-агентами, замечает тревожную тенденцию: команды, включая опытных инженеров, перестали инициировать рефакторинг сложных участков кода. Раньше сигналом к рефакторингу служило чувство «я потерялся в этом коде» — человеческое ограничение, которое заставляло останавливаться и наводить порядок. AI-агенты не подвержены этому ограничению: они могут работать с запутанным кодом, не испытывая дискомфорта, поэтому сигнал больше не срабатывает. Риск в том, что люди теряют способность понимать и контролировать свои системы, а ревью становятся формальностью. Автор подчеркивает, что чистый код выгоден и агентам: он снижает затраты токенов и вероятность галлюцинаций. Решение — сознательно вернуть практику рефакторинга и научить агентов предлагать его.
Удобство агента, который никогда не теряется, реально, но «агент всё ещё может разобраться в коде» — это не то же самое, что «система здорова».
- bunderbunder
Я не согласен с утверждением, что «ИИ-агенты больше не теряются». Что я наблюдал вместо этого — так это то, что они не испытывают ощущения потери ориентации. А это совсем другое.
Этим летом я довольно долго использовал агента для программирования, чтобы помочь мне распутать глубокий и сложный конвейер обработки данных. Он сам был построен агентами за поразительно короткое время. Но также стало ясно, что он был переполнен ошибками и выдавал много плохих данных.
Что я быстро обнаружил, так это то, что более чем на половину моих вопросов я получал очень уверенные, но неверные ответы. И даже когда я наконец диагностировал текущую проблему, было трудно доверить агенту исправление ошибок. Поскольку ему было еще труднее, чем мне, прослеживать потоки данных (воспользуюсь случаем, чтобы предложить вашему вниманию мысль, что быстрее не обязательно лучше), он оказывался чем-то вроде обезьяньей лапки. Да, он исправлял именно ту ошибку, которую я просил, но обычно вносил новые дефекты в процессе. И да, я сталкивался с этой проблемой со всеми новейшими и лучшими моделями.
В конечном итоге я пришел к выводу, что в этой кодовой базе агент действительно был глубоко и безнадежно потерян. (прим.: И, вероятно, этот код изначально стал таким плохим именно потому, что агенты, использованные для его создания, были потеряны какое-то время, но не могли распознать эту проблему и привлечь к ней внимание своих операторов.)
- joshstrange
А я тем временем рефакторю как можно больше кода, написанного людьми за годы (или десятилетия). Превращение бардака, который я либо унаследовал, либо помог создать, либо строил поверх, во что-то чистое и безупречное — возможно, мое любимое применение LLM. То же самое для личных проектов, кодовых баз, которые развивались много лет, когда у меня было время, и не поддерживались в такой «чистоте», как мне хотелось бы, и которые наконец-то были приведены в порядок.
Я всегда _хотел_, чтобы мой код был чистым и легким для понимания, но жизнь, дедлайны, меняющиеся приоритеты и тому подобное мешали этому. Теперь я наконец могу достичь своей личной нирваны.
Тем не менее, мне приходилось уводить модели от слишком сильной абстракции или подобного, потому что это делало код слишком трудным для понимания.
- simonw
Я обнаружил, что доступ к агентам для программирования помог мне стать гораздо менее терпимым к плохим паттернам кода, которые можно отрефакторить.
Раньше рефакторинг имел вполне реальную цену — это было значительное количество времени, которое приходилось выкраивать из работы над новыми функциями.
Теперь я могу заметить потенциальный рефакторинг, запустить промпт в асинхронном агенте для программирования (или в отдельной ветке), а через 20 минут вернуться и либо принять его, либо подправить, либо отказаться. Мне это почти ничего не стоит.
- joshka
Многое из этого, похоже, сводится к обучению агентов создавать код, удовлетворяющий различным бенчмаркам, в сочетании с реакциями на вещи, которые ранее были дезадаптивными. Т.е. вещи, которые были явно выучены из модели в пост-обучении. Я думаю, что здесь не хватает многих долгосрочных принципов программной инженерии, которые, похоже, не встроены в то, как модели пишут код по умолчанию.
У меня есть предположение, что люди, занимающиеся пост-обучением моделей, как правило, более молодые исследователи, которые не работали над большими сложными программными системами, поэтому их вкус в этом отношении не так развит, чтобы понимать, что здесь важно.
Но эту область можно направлять с помощью соответствующих начальных инструкций («При выборе компромиссов реализации стремись к долгосрочной поддерживаемости и понятности кода, а не к реализации только точного кода, необходимого для решения проблем. и т.д. Цепочка рассуждений часто включает информацию, которую пришлось бы повторять в будущей сессии агента; обязательно сохраняй ее в коде или внешней документации, чтобы будущие сессии и понимание пользователя уважались»).
Это также можно сделать как шаг после изменения с аналогичными эффектами. И вы можете использовать своих агентов, чтобы встроить этот уровень в ваш общий модус операнди для борьбы с преступлениями сгенерированного кода. Но одна из вещей, которую все ИИ-лаборатории должны делать, — это рассматривать AGENTS.md в реальных проектах как жесткие выражения того, какие режимы отказов реальные проекты […]
- moezd
ИИ-агенты теряются постоянно, особенно если кодовая база уже разрастается бесконтрольно.
Ваша дисциплина окупается только если вы уже понимаете свой код и/или установили четкий базовый уровень для своих стандартов до того, как начать манию разработки функций. И ее нужно поддерживать на каждом шагу, иначе поток генерации кода легко выбьет входную дверь.