AI-кодирование требует сильных software engineers: почему опыт важнее «vibe slop»

Откат был неизбежен. Последний год Кремниевая долина уверяла нас, что разработка ПО вот-вот превратится в упражнение «написал промпт — отправил в продакшн». То есть достаточно описать, что нужно, и AI coding agent сам соберет продукт. Конечно, можно было бы оставить пару условных senior engineers, чтобы они одобрили результат… а можно и не оставлять. При этом Sundar Pichai из Google говорит, что 75% нового кода теперь создается с помощью AI и проходит ревью у инженеров, причем этот показатель резко вырос по сравнению с прежним уровнем.

The Wall Street Journal недавно обратил внимание на предупреждения Mario Zechner и Armin Ronacher, двух инженеров, стоящих за ключевыми частями популярного AI agent OpenClaw. По их мнению, AI coding tools наводняют софт тем, что они называют «vibe slop». Их претензия в том, что слишком многие используют AI, чтобы пропустить именно те части разработки, которые действительно важны: проектирование, суждение, тестирование, владение кодом и глубокое понимание системы, которую меняют.

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

Пересмотреть, но не отвергнуть.

Правильный ответ — не «AI coding bad». Это было бы глупо. AI coding мощен примерно так же, как мощны электроинструменты: они помогают опытным людям делать больше и быстрее. И они же помогают неопытным или небрежным людям совершать более крупные ошибки с большей уверенностью. В миниатюре именно так выглядит enterprise AI.

Нечто почти правильное все равно может быть очень неправильным

Я уже высказывал близкий тезис о реальной цене «почти правильного» AI-кода. Проблема никогда не заключалась в том, что large language models выдавали бы явно сломанный мусор. Тогда мы бы это заметили и пошли дальше. Проблема в том, что они очень быстро начинают выдавать правдоподобный результат. Быстрое и правдоподобное — это как раз тот тип ошибки, который незаметно попадает в production.

Важно понимать, что генерация кода никогда не была самой сложной частью софта. Как говорит основательница Honeycomb и CTO Charity Majors, работа сильного software engineer «гораздо больше связана со способностью понимать, поддерживать, объяснять и управлять большим объемом софта в production с течением времени, а также с умением переводить бизнес-потребности в техническую реализацию», чем с простым штампованием большого количества кода. Как я писал ранее, скорость разработки редко бывает правильной метрикой. Разработчики тратят большую часть времени на понимание существующих систем, а не просто на добавление новых строк.

AI не отменил необходимость этой сложной работы. Он лишь сделал ее пропуск куда более соблазнительным.

Это верно не только для разработки. Я постоянно использую AI в своей работе. Например, я могу с его помощью набросать слайды для обучения sales teams или обобщить отзывы клиентов. AI дает мне стартовую точку — как черновик служебной записки, который может быть верен на 80%. Это действительно полезно. Но финальный документ, верный лишь на 80%, — уже риск, поэтому я должен направлять и контролировать агентов. Это настоящая работа, пусть и иная, чем та, что я делал раньше.

Проблема в отказе от ответственности

Самая примитивная версия спора об AI coding сводится к вопросу, заменит ли AI developers. Лучший вопрос другой: какого именно developer вознаграждает AI? Он не вознаграждает человека, который слепо принимает результат. Напротив, он вознаграждает того, кто быстро и точно может определить, подходит ли результат системе, security model, performance envelope, пользовательской потребности и стандартам организации. Иными словами, AI вознаграждает опыт; он вознаграждает людей, которые знают, как выглядит «хорошо».

Именно поэтому армии autonomous coding agents вызывают у меня тревогу. Не потому, что agents бесполезны, а потому, что ответственность не масштабируется так же, как промпты. Разработчик может проверить одно AI-generated изменение. Может пять. Может 20, если изменения небольшие, а тесты сильные. Но когда компания начинает праздновать десятки или сотни agents, которые штампуют pull requests, issues, tests, migrations и fixes, очевидный вопрос звучит так: кто вообще понимает, что происходит?

Если ответ — «другой агент», то, простите, мы снова там же, где и начали. Open source maintainers уже живут с обратной стороной этого процесса. GitHub рассматривает более жесткий контроль pull request’ов после предупреждений мейнтейнеров о том, что всплеск низкокачественных, часто AI-generated вкладов перегружает проекты. InfoWorld сообщал, что GitHub рассматривал более строгие фильтры и инструменты контроля для мейнтейнеров, чтобы сдержать этот поток.

Это и есть уродливая экономика AI slop: дешево генерировать, но дорого проверять.

Трение — это и есть смысл

Ronacher очень ясно формулирует близкую мысль. В своем выступлении «The Friction Is Your Judgment» он и Cristina Poncela утверждают, что code, сгенерированный агентами, имеет тенденцию скатываться к локально удобному решению. Поймать исключение, добавить fallback, замазать странный edge case, сохранить движение демо. Каждое изменение по отдельности может выглядеть разумным, но проблема в том, что происходит после того, как сотня таких правок накапливается по всему codebase, тихо усложняя понимание системы.

Мне это кажется верным. Friction — не враг; это место, где живет ваше суждение.

Вот почему язык «human in the loop», каким бы затертым он ни стал, все еще важен. Но эта фраза что-то значит только тогда, когда человек и внимателен, и способен оценить работу. Junior developer, который принимает сгенерированный код лишь потому, что он проходит первый тест, проблемы не решает. Не решает ее и senior developer, который «ревьюит» поток agent-written pull requests с такой скоростью, что реальное ревью становится невозможным.

Защита — не в том, чтобы рядом с loop стоял кто-то формально. Нет, защита — в deliberate expertise, подкрепленной системами, которые заставляют отвечать за результат, а не просто предполагают ответственность. Для developers AI особенно силен там, где задачи bounded: например, при генерации tests или объяснении незнакомого кода. И он заметно слабее, когда его просят принимать широкие architectural decisions или выводить business rules, которые живут в головах людей, а не в repository.

Для managers худшая метрика — «процент кода, сгенерированного AI». Это все равно что измерять newsroom по проценту предложений, набранных autocomplete. Кому это важно? Настоящие вопросы — снижаются ли defects, быстрее ли delivery, меньше ли incidents и довольнее ли customers.

Отчет DORA 2025 о состоянии AI-assisted software development объясняет это более полезно: AI обычно усиливает уже существующие сильные и слабые стороны организации. Если у вас сильные tests, понятная ownership-модель, дисциплинированный review, хорошая observability и быстрый rollback, AI может сделать вас лучше. Если у вас слабая engineering hygiene, AI может сделать вас хуже и быстрее.

Иными словами, AI не отменяет потребность в engineering discipline. Он повышает цену ее отсутствия.

Границы нельзя задать запиской

Дисциплина необходима, но для enterprise ее недостаточно. Нельзя заставить десятки тысяч engineers, analysts, marketers, lawyers и salespeople надежно «замедляться и проверять работу» одними благими намерениями и запиской. На масштабе human in the loop должен обеспечиваться архитектурой, а не надеждой на благоразумие.

На практике это означает, что guardrails нужно встраивать в системы, с которыми работают agents, — например, в identity, data governance и observability. Здесь я рискну прозвучать так, будто работаю там, где работаю (Oracle). По-настоящему интересный сдвиг, который я вижу по всей отрасли, и да — на который делает ставку Oracle, — это перенос большей части этих controls в сам data layer, чтобы agents работали с governed enterprise data, а не были хитрыми скриптами, держащими ключи к production.

Это не так эффектно, как говорить, что agents будут писать весь ваш code. Но знаете что? Это хорошо. В enterprise AI «скучное» — это хорошо.

Так насколько для enterprises важно, что Google говорит о 75% нового кода, созданного с помощью AI? Возможно, это правда. Но у Google также есть одни из лучших engineers в мире, которые ревьюят этот результат. И именно эту часть истории слишком многие AI-энтузиасты пропускают, хотя не должны. Люди — лучший способ заставить AI работать.

Материал — перевод статьи с английского.

Оригинал: AI coders need good software engineers