AI coding agents требуют сильных software engineers
Если вы действительно хотите не утонуть в «AI slop», вам нужны опытные инженеры, которые будут контролировать observability, testing и review всего этого AI-generated code.
Ответный откат был неизбежен. Последний год Silicon Valley уверяла нас, что software development вот-вот превратится в упражнение «prompt-and-ship». То есть достаточно описать, что вам нужно, и AI coding agent соберет это за вас. Конечно, можно оставить пару номинальных senior engineers, чтобы они благословляли результат… а можно и не оставлять. Sundar Pichai из Google, в конце концов, говорит, что 75% нового кода компании теперь сгенерировано AI и проверено инженерами, и это заметно больше, чем раньше.
«Ура! Верно? Ну…»
The Wall Street Journal недавно обратил внимание на предупреждения Mario Zechner и Armin Ronacher — двух инженеров, стоящих за ключевыми частями популярного AI agent OpenClaw, — которые утверждают, что AI coding tools затапливают software тем, что они называют «vibe slop». Их претензия в том, что слишком многие используют AI, чтобы пропустить именно те части software development, которые действительно важны: design, judgment, testing, ownership и глубокое понимание системы, которую меняют.
К этому стоит отнестись серьезно. Когда люди, помогавшие строить инструменты, которыми пользуются миллионы, предупреждают, что те же инструменты способны производить buggy, потенциально опасный software в промышленном масштабе, пора пересмотреть некоторые предположения, подпитывающие AI-волну.
Пересмотреть, а не отвергнуть.
Правильный ответ — не «AI coding плох». Это нелепо. AI coding мощен примерно так же, как мощны электроинструменты. Они помогают skilled people делать больше и быстрее. Но они же помогают unskilled или careless people совершать более крупные ошибки с большей уверенностью. В миниатюре это и есть история enterprise AI.
Почти правильно — это все равно очень неправильно
Я уже приводил похожий аргумент о реальной цене «почти правильного» AI code. Проблема никогда не заключалась в том, что large language models не способны выдавать очевидно сломанный мусор. Если бы это было так, мы бы просто ловили его и двигались дальше. Проблема в том, что они очень быстро выдают правдоподобный результат. Быстрое и правдоподобное — это как раз тот вид ошибки, который проскакивает в production.
Важно понимать, что генерация кода никогда не была самой сложной частью software. Как говорит основатель и CTO Honeycomb Charity Majors, быть отличным software engineer «гораздо больше связано со способностью понимать, поддерживать, объяснять и управлять большим массивом software в production с течением времени, а также переводить бизнес-потребности в техническую реализацию», чем просто выдавать много кода. Как я писал раньше, скорость разработки — редко правильная метрика. Разработчики тратят большую часть времени на понимание существующих систем, а не просто на добавление новых строк.
AI не устранил необходимость в этой тяжелой работе. Он лишь сделал проще глупо ее пропускать.
Это справедливо не только для software. Я постоянно использую AI в своей работе. Например, я использую AI, чтобы набросать слайды для обучения sales teams или синтезировать обратную связь от клиентов. AI дает мне стартовую точку, как черновик memo, который может быть на 80% правильным. Это действительно ценный подарок. Но финальный черновик, который верен лишь на 80%, — это уже риск, так что мне приходится коучить и контролировать agents. Это настоящая работа, хотя и другая, чем та, которую я делал раньше.
Проблема в отказе от ответственности
Самая примитивная версия спора об AI coding спрашивает, заменит ли AI developers. Лучший вопрос — какого именно developer вознаграждает AI? Он не вознаграждает того, кто слепо принимает output. Вместо этого он вознаграждает того, кто способен быстро и точно определить, соответствует ли output системе, security model, performance envelope, user need и стандартам организации. Иными словами, AI вознаграждает опыт; он вознаграждает людей, которые знают, как выглядит «good».
Именно поэтому меня беспокоят целые флоты автономных coding agents. Не потому, что agents бесполезны, а потому, что responsibility не масштабируется так же, как prompts. Developer может проверить одно AI-generated изменение. Может быть, пять. Может быть, 20, если изменения малы и tests сильные. Но когда компания начинает праздновать десятки или сотни agents, которые штампуют pull requests, issues, tests, migrations и fixes, очевидный вопрос звучит так: кто вообще понимает, что происходит?
Если ответ — «другой agent», то, извините, мы снова вернулись туда, откуда начали. Open source maintainers уже живут с этой изнанкой. GitHub рассматривал более жесткий контроль pull request после того, как maintainers предупредили: всплеск низкокачественных, часто AI-generated contributions перегружает проекты. InfoWorld сообщал, что GitHub думал о более сильных фильтрах и инструментах контроля для maintainers, чтобы сдержать этот поток.
Это и есть уродливая экономика AI slop. Его дешево генерировать, но дорого проверять.
Смысл в трении
Ronacher с достойной уважения ясностью формулирует похожую мысль. В своем докладе «The Friction Is Your Judgment» он и Cristina Poncela утверждают, что agent-generated code имеет свойство дрейфовать к локально удобному ответу. Поймать exception, добавить fallback, замазать странный edge case, сохранить demo в движении. Каждое изменение по отдельности может выглядеть разумным, но проблема в том, что происходит после того, как сотня таких правок накапливается по всему codebase и тихо делает систему труднее для понимания.
Мне это кажется верным. Friction — не враг; наоборот, именно в нем живет judgment.
Вот почему фраза «human in the loop», какой бы затертой она ни стала, по-прежнему важна. Но она что-то значит только если человек действительно следит за процессом и способен оценить работу. Junior developer, который принимает сгенерированный код лишь потому, что он проходит первый test, проблему не решает. Как и senior developer, «reviewing» поток agent-written pull requests с такой скоростью, при которой настоящий review невозможен.
Защита — это не просто человек где-то рядом с loop. Нет, это expertise, применяемая осознанно, с системами, которые требуют accountability, а не предполагают ее. Для developers AI особенно силен, когда используется для bounded tasks, например для генерации tests или объяснения незнакомого code. И, соответственно, он слабее, когда его просят принимать широкие architectural decisions или выводить business rules, которые живут в головах людей, а не в repository.
Для managers худшая возможная метрика — «percentage of code generated by AI». Это все равно что оценивать newsroom по проценту предложений, набранных autocomplete. Какая разница? Настоящие вопросы — уменьшается ли число defects, быстрее ли delivery, меньше ли incidents и довольнее ли customers.
2025 DORA report о состоянии AI-assisted software development показывает это куда полезнее: AI обычно усиливает уже существующие сильные и слабые стороны организации. Если у вас сильные tests, ясная ownership, дисциплинированный review, хорошая observability и быстрый rollback, AI может сделать вас лучше. Если у вас слабая engineering hygiene, AI может сделать вас хуже, но быстрее.
Иными словами, AI не отменяет необходимость engineering discipline. Он повышает цену ее отсутствия.
Гарда не может быть просто служебной запиской
Discipline необходима, но для enterprise ее недостаточно. Нельзя заставить десятки тысяч engineers, analysts, marketers, lawyers и salespeople надежно «замедлиться и проверить работу» только добрыми намерениями и memo. На масштабе human in the loop должен обеспечиваться архитектурой, а не пожеланиями.
На практике это означает, что guardrails нужно встраивать в системы, с которыми работают agents, — например, в identity, data governance и observability. И здесь я рискну прозвучать как человек, который работает там, где работает (Oracle). По-настоящему интересный сдвиг, который я вижу по всей отрасли, и да, на который делает ставку Oracle, — это перенос большего числа таких controls в сам data layer, чтобы agents работали с governed enterprise data, а не были умными скриптами с ключами от production.
Это не так эффектно, как говорить, что agents напишут весь ваш code, но знаете что? Это хорошо. В enterprise AI «скучное» — это хорошо.
Так насколько важно для enterprise, что Google говорит о 75% нового code, созданного AI? Возможно, это правда, но Google также располагает одними из лучших engineers в мире, которые проверяют этот output. Именно эту часть истории слишком многие AI-энтузиасты пропускают, хотя не должны. Humans — лучший способ заставить AI работать.
Материал — перевод статьи с английского.