Примечание редактора: В то время, как генеративный ИИ стремительно проникает в разработку ПО, настроения в отрасли смещаются от «изумления возможностями» к «тревоге эффективности». Кажется, что писать недостаточно быстро, использовать недостаточно много или автоматизировать недостаточно полно — всё это вызывает давление и страх оказаться ненужным. Но когда кодирующие агенты действительно начинают использоваться в рабочей среде, возникают более практические проблемы: ошибки усиливаются, сложность выходит из-под контроля, системы постепенно становятся непонятными, а рост эффективности не преобразуется в пропорциональное повышение качества.
Эта статья, основанная на практическом опыте, предлагает трезвое осмысление бума «агентного кодирования». Автор указывает, что агенты не учатся на ошибках, как люди; при отсутствии ограничений и механизмов обратной связи мелкие проблемы быстро усугубляются. А в сложных кодобазах их локальная перспектива и ограниченная способность к поиску лишь усиливают хаос в структуре системы. Суть этих проблем заключается не в самой технологии, а в том, что люди, движимые тревогой, слишком рано отдают своё суждение и контроль.
Поэтому вместо того, чтобы поддаваться тревоге «необходимости полностью принять ИИ», лучше заново определить отношения между человеком и инструментом: пусть агенты берут на себя локальные, контролируемые задачи, а проектирование системы, контроль качества и ключевые решения остаются firmly в руках человека. В этом процессе «замедление» само по себе становится способностью — оно означает, что вы по-прежнему понимаете систему, можете делать выбор и сохраняете чувство контроля над своей работой.
В эпоху постоянной эволюции инструментов по-настоящему дефицитными, возможно, являются не способность генерировать быстрее, а способность судить о сложности и твёрдость в выборе между эффективностью и качеством.
Далее следует оригинальный текст:
Примерно год назад начали появляться кодирующие агенты, которые действительно могли помочь «сделать полноценный проект с нуля до конца». Ранее уже были такие инструменты, как Aider, ранний Cursor, но они были больше похожи на помощников, а не на «агентов». Новое поколение инструментов невероятно привлекательно, и многие потратили массу свободного времени, чтобы реализовать все те проекты, которые давно хотели сделать, но не хватало времени.
Я считаю, что в этом нет ничего плохого. Делать что-то в свободное время само по себе приносит удовольствие, и в большинстве случаев вам не нужно заботиться о качестве кода и сопровождаемости. Это также даёт путь к изучению новых технологических стеков.
Во время рождественских каникул Anthropic и OpenAI раздавали немного «бесплатных кредитов», которые, как игровые автоматы, затягивали людей. Для многих это был первый реальный опыт «магии написания кода агентом». Участвовало всё больше людей.
Теперь кодирующие агенты也开始 проникать в рабочие кодобазы. Прошло 12 месяцев, и мы начинаем видеть последствия этого «прогресса». Вот моё текущее мнение.
Всё сломалось
Хотя это в основном эмпирические наблюдения, но современное ПО действительно создаёт ощущение, что оно «вот-вот развалится». Доступность на уровне 98% из исключения становится нормой, даже для крупных сервисов. Пользовательские интерфейсы полны нелепичных багов, тех, которые команда QA должна была бы заметить с первого взгляда.
Признаю, такая ситуация существовала и до появления агентов. Но сейчас проблема явно ускоряется.
Мы не видим реальной ситуации внутри компаний, но иногда просачивается информация, как, например, тот слух о «сбое в AWS, вызванном ИИ». Amazon Web Services затем оперативно «поправили» формулировку, но сразу же запустили внутренний 90-дневный план по наведению порядка.
Сатья Наделла (CEO Microsoft) в последнее время также постоянно подчёркивает, что в компании всё больше кода пишется с помощью ИИ. Прямых доказательств нет, но есть ощущение: качество Windows падает. Даже по некоторым блогам самой Microsoft видно, что они, кажется, молчаливо признают это.
Компании, которые заявляют, что «100% кода продукта сгенерировано ИИ», почти всегда выпускают худшие продукты, которые только можно представить. Ни к кому лично, но гигабайтные утечки памяти, хаотичный UI, неполноценный функционал, частые крахи... Это никак не является «гарантией качества», как они, видимо, думают, и уж точно не положительным примером «поручи агенту делать всё».
В частных разговорах вы всё чаще слышите, как и крупные компании, и маленькие команды говорят об одном: они загнали себя в тупик «кодом, написанным агентом». Никакого код-ревью, передача проектных решений агенту, нагромождение кучи ненужных функций — конец, естественно, нехороший.
Почему нам не стоит так использовать агентов
Мы почти полностью отказались от всей инженерной дисциплины и субъективного суждения, погрузившись в «зависимый» способ работы: цель одна — сгенерировать как можно больше кода за最短шее время, а последствия вообще не учитываются.
Вы строите оркестровочный слой, чтобы управлять армией автоматических агентов. Вы ставите Beads, даже не зная, что это по сути почти что несъёмное «вредоносное ПО». Просто потому что в интернете говорят «все так делают». Не делаешь так — «пропал» (ngmi).
Вы истощаете себя в бесконечных «циклах-матрёшках».
Смотрите — Anthropic использовали кучу агентов, чтобы сделать C-компилятор, правда, пока с проблемами, но следующее поколение моделей точно всё починит, да?
Смотрите ещё — Cursor использовали толпу агентов, чтобы сделать браузер, правда, пока基本 нерабочий и требует периодического ручного вмешательства, но следующее поколение моделей точно справится, да?
«Распределённость», «разделяй и властвуй», «автономные системы», «заводы без света», «решим проблемы ПО за шесть месяцев», «SaaS мёртв, моя бабушка только что собрала Shopify на Claw»...
Эти нарративы звучат круто.
Конечно, для вашего сайд-проекта, которым почти никто не пользуется (включая вас самих), этот способ, возможно, «ещё работает». Может, и существует какой-то гений, способный таким методом сделать нетривиальный, действительно используемый программный продукт. Если вы тот самый — я искренне восхищаюсь.
Но по крайней мере в кругу разработчиков вокруг меня я ещё не видел случаев, когда этот метод действительно работал. Конечно, возможно, мы все просто недотёпы.
Ошибки накладываются без обучения, без ограничений, с отсроченным взрывом
Проблема агентов в том, что они ошибаются. Само по себе это ничего, люди тоже ошибаются. Возможно, это просто ошибки корректности, их легко выявить и исправить, добавив regression-тест для надёжности. Или это могут быть code smells, которые не ловят линтеры: тут ненужный метод, там нелогичный тип, ещё дублирующийся код и тому подобное. По отдельности всё это не страшно, человеческие разработчики тоже допускают такие мелкие ошибки.
Но «машина» — не человек. Человек, повторив несколько раз одну и ту же ошибку, обычно научается её не делать — либо его отругали, либо он в процессе настоящего обучения исправился.
А у агента такой способности к обучению нет, по крайней мере по умолчанию. Он будет раз за разом повторять те же ошибки, а может, на основе тренировочных данных ещё и «создавать» удивительные комбинации разных ошибок.
Конечно, можно попытаться его «натренировать»: прописать правила в AGENTS.md, чтобы он больше так не ошибался; разработать сложную систему памяти, чтобы он запрашивал историю ошибок и лучшие практики. Для определённых типов проблем это действительно работает. Но前提 — вы必须先 заметить, что он совершил эту ошибку.
Более ключевое отличие: человек — это ограничение, а агент — нет.
Человек не может выдать двадцать тысяч строк кода за несколько часов. Даже при не低кой частоте ошибок, за день можно внести лишь ограниченное их количество, их накопление происходит медленно. Обычно, когда «боль от ошибок» накапливается до определенного уровня, человек (из instinctтивного отвращения к боли) останавливается и чинит. Или человека меняют, и чинит другой. В общем, проблемы решаются.
Но когда вы используете целую оркестрированную армию агентов, нет ни ограничения, ни «болевого ощущения». Эти原本 незначительные мелкие ошибки накладываются с неустойчивой скоростью. Вас уже вывели из цикла, вы даже не знаете, что эти, казалось бы, безобидные мелочи уже выросли в нечто огромное. Когда вы真正 почувствуете боль,往往 уже слишком поздно.
До того дня, когда вы захотите добавить новую функцию и обнаружите, что текущая архитектура системы (по сути, уже нагромождение ошибок) вообще не поддерживает изменения; или пользователи начнут яростно жаловаться, потому что последний релиз сломался или даже потерял данные.
Только тогда вы осознаете: вы больше не можете доверять этому коду.
Хуже того, тысячи unit-тестов, snapshot-тестов, end-to-end тестов, которые вы заставили агента сгенерировать, тоже стали ненадёжными. Единственный способ判断, «работает ли система нормально», остаётся только ручное тестирование.
Поздравляю, вы себя (и компанию) здорово подставили.
Продавцы сложности
Вы уже совершенно не понимаете, что происходит в системе, потому что отдали контроль агенту. А агент, по своей сути, «продаёт сложность». В тренировочных данных они видели массу плохих архитектурных решений, и в процессе reinforcement learning эти паттерны постоянно усиливались. Позволить ему проектировать систему — результат предсказуем.
В итоге вы получаете: чрезвычайно сложную систему, перемешанную с неумелыми имитациями «лучших практик индустрии», которую вы до выхода проблем из-под контроля не ограничивали.
Но проблема не только в этом. Ваши агенты не делятся между собой процессом выполнения, не видят полную кодобазу, не понимают решений, принятых вами или другими агентами ранее. Следовательно, их решения всегда «локальны».
Это напрямую leads к упомянутым выше проблемам: масса повторяющегося кода, структуры ради абстракции,各种 несогласованности. Эти проблемы накладываются и в конечном итоге формируют неисправимо сложную систему.
Это очень похоже на enterprise-кодобазы, написанные людьми. Просто та сложность обычно является результатом многолетнего накопления: боль распределена между множеством людей, каждый не доходит до критической точки «надо чинить», толерантность самой организации высока, и сложность «коэволюционирует» с организацией.
Но в комбинации человек + агент этот процесс резко ускоряется. Два человека плюс куча агентов за несколько недель достигают такой сложности.
У agentic search низкий recall
Вы можете надеяться, что агенты «приведут всё в порядок», помогут рефакторить, оптимизировать, сделать систему чистой. Но проблема в том, что они уже не смогут.
Потому что кодобаза слишком велика, сложность слишком высока, а они всегда видят только локальную часть. Это не просто вопрос недостаточного контекстного окна или отказа механизмов длинного контекста перед лицом миллиона строк кода. Проблема более скрытная.
Прежде чем агент попытается починить систему, он必须先 найти весь код, который нужно修改ить, и уже существующие реализации, которые можно复用. Этот шаг мы называем agentic search (агентный поиск).
Как агент это делает, зависит от данных вами инструментов: это может быть Bash + ripgrep, это может быть queryable code index, LSP-сервис, векторная база данных...
Но无论用什么工具, суть одинакова: чем больше кодобаза, тем ниже recall (полнота поиска). А низкий recall означает: агент не может найти весь релевантный код, следовательно, не может внести правильные изменения.
Вот почему изначально появляются те мелкие ошибки «code smells» — он не нашёл существующую реализацию, поэтому изобрёл велосипед, внёс несогласованность. В конечном счёте,这些问题 будут распространяться, накладываться, расцветая невероятно сложным «цветком разложения».
Как же нам всего этого избежать?
Как我们应该 сотрудничать с агентами (по крайней мере, сейчас)
Кодирующие агенты like сирены, привлекают вас сверхбыстрой скоростью генерации кода и этой «прерывистой, но временами впечатляющей» intelligence. Они часто могут с惊人的 скоростью и высоким качеством выполнять некоторые простые задачи. Настоящие проблемы начинаются, когда у вас возникает мысль — «Эта штука слишком крута, компьютер, работай за меня!»
Передавать задачи агенту само по себе не проблема. Хорошие агентные задачи обычно имеют несколько характеристик: их scope можно хорошо ограничить, не требуется понимание всей системы; задача является замкнутой, то есть агент может самостоятельно оценить результат; вывод не находится на критическом пути, это只是一些 временные инструменты или内部使用的 ПО, не влияющее на реальных пользователей или доход; или же вам просто нужен «резиновый утёнок» для辅助 мышления — по сути, это столкновение вашей идеи со сжатыми знаниями интернета и синтетическими данными.
Если эти условия соблюдены, то это задача, подходящая для передачи агенту, при условии, что вы, как человек, остаётесь финальным контролёром качества.
Например, использовать метод auto-research, предложенный Андреем Карпати, для оптимизации времени запуска приложения? Отлично. Но при условии, что вы понимаете: выдаваемый им код абсолютно не готов для production. Auto-research работает, потому что вы дали ему функцию оценки, позволяющую оптимизировать вокруг某个指标 (например, время запуска или loss). Но эта функция оценки покрывает лишь очень узкое измерение. Агент будет уверенно игнорировать все показатели, не входящие в функцию оценки, такие как качество кода, сложность системы, а в некоторых случаях даже корректность — если ваша функция оценки сама flawed.
Основная мысль очень проста: пусть агент делает скучные вещи, которые не учат вас новому, или те исследовательские работы, на которые у вас никогда не было времени попробовать. А вы оцениваете результат, выбираете真正 разумные, правильные части и завершаете финальную реализацию. Конечно, и этот последний шаг можно сделать с помощью агента.
Но я хочу подчеркнуть большее:真的, стоит немного замедлиться.
Дайте себе время подумать, что вы actually делаете и зачем. Дайте себе возможность сказать «нет»: «Нет, это нам не нужно». Установите для агента чёткий лимит: сколько кода в день ему разрешено генерировать, этот объём должен соответствовать вашей реальной способности его проверять. Все части, определяющие «общую форму» системы, такие как архитектура, API и т.д., должны быть написаны лично. Вы можете использовать автодополнение для «ощущения handwritten кода»,也可以 pair programming с агентом, но ключ в том: вы должны быть in the code.
Потому что сам процесс написания кода самостоятельно или наблюдения за его пошаговым построением создаёт «трение». Именно это трение позволяет вам лучше понять, что вы хотите сделать, как система работает, каково общее «ощущение». Именно здесь проявляются опыт и «вкус», и это как раз то, что самые передовые модели пока не могут заменить. Замедлиться,承受一点 трения, — это именно тот способ, которым вы учитесь и растёте.
В итоге вы получите систему, которую依然 можно сопровождать — по крайней мере, не хуже, чем до появления агентов. Да,过去的 системы тоже были неидеальны. Но ваши пользователи скажут вам спасибо, потому что ваш продукт «удобен в использовании», а не куча hastily собранного мусора.
Вы будете делать меньше функций, но более правильных. Научиться говорить «нет» — это already способность. Вы также сможете спать спокойно, потому что вы хотя бы still знаете, что происходит в системе, вы still держите инициативу в своих руках. Именно это понимание позволяет вам компенсировать проблемы recall agentic search, делать вывод агента более надёжным и требующим меньше исправлений.
Когда система ломается, вы можете personally починить; когда изначальный дизайн был плох, вы也能 понять, в чём проблема, и перепроектировать её в лучшую форму. А есть агент или нет — не так уж и важно.
Всё это требует дисциплины. Всё это невозможно без человека.
