Оригинальный заголовок: Thoughts on slowing the fuck down
Оригинальный автор: Mario Zechner
Перевод: Peggy, BlockBeats

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

Эта статья основана на практическом опыте на передовой и представляет собой спокойное переосмысление волны «agentic coding». Автор отмечает, что агент не учится на ошибках так, как это делает человек; в отсутствие узких мест и механизмов обратной связи небольшие проблемы раздуваются очень быстро. А в сложных кодовых базах его локальный взгляд и ограниченная способность к восстановлению контекста (recall) дополнительно усиливают хаос в структуре системы. Суть этих проблем — не в самой технологии. Она в том, что человек, действуя из тревоги, слишком рано отдаёт на аутсорс решения и контроль.

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

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

Ниже приводится текст оригинала:

Лицо черепахи — это именно то выражение, которое я вижу, глядя на эту индустрию

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

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

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

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

Всё сломалось

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

Я признаю: до появления агентов такая ситуация уже существовала. Но теперь проблемы явно ускоряются.

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

Satya Nadella (CEO Microsoft) тоже в последнее время всё время подчёркивает, что в компании всё больше кода пишут с помощью ИИ. Прямых доказательств нет, но ощущение такое есть: качество Windows идёт вниз. Даже по некоторым блогам, которые публикует сама Microsoft, кажется, что они, похоже, тоже это молча признают.

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

Разговоры по секрету становятся всё громче: независимо от того, крупная ли это компания или небольшая команда, все говорят об одном и том же — они уже загнаны в тупик тем, что «кодовые агенты пишут код». Без код-ревью, передача решений по дизайну агенту, а потом ещё и наваливание кучи функций, которые никому не нужны — естественно, финал не может быть хорошим.

Почему нам не стоит использовать агент так

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

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

Вы всё больше истощаете себя в бесконечных «матрешечных» циклах.

Посмотрите — Anthropic использовала целую группу агентов, чтобы сделать C-компилятор; сейчас там ещё есть проблемы, но следующее поколение моделей наверняка всё исправит, верно?

Смотрите дальше — Cursor с помощью целой кучи агентов сделала браузер; пусть сейчас он по сути неработоспособен и требует время от времени ручного вмешательства, но следующее поколение моделей точно справится, верно?

«Распределённое», «разделяй и властвуй», «автономные системы», «фабрики при “чёрном свете”», «за шесть месяцев решим проблему с ПО», «SaaS умер, а моя бабушка только что собрала Shopify с помощью Claw»»…

Эти нарративы звучат чертовски приятно.

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

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

Ошибки накапливаются из-за отсутствия обучения, узких мест и задержки “вспышки”

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

Но «машина» не человек. Человек обычно перестаёт повторять одни и те же ошибки после нескольких попыток — либо его «пинают» и он просыпается, либо он сам меняется в процессе реального обучения.

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

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

Ключевое отличие в другом: люди — это узкое место, а агент — нет.

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

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

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

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

Хуже того, те тысячи юнит-тестов, снапшот-тестов и сквозных тестов, которые сгенерировал агент, тоже перестают быть надёжными. Единственный способ понять, нормально ли работает система, остаётся — вручную тестировать.

Поздравляю: вы выкопали себе (и своей компании) большую яму.

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

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

В итоге вы получаете: целый набор крайне сложных систем, в которых перемешаны посредственные имитации «отраслевых best practices», и при этом никто не поставил ограничители до того, как всё вышло из-под контроля.

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

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

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

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

У agentic search низкая “отзываемость” (recall)

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

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

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

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

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

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

Так как же избежать всего этого?

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

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

Передавать задачи агенту само по себе не проблема. Хорошие агентные задачи обычно обладают несколькими признаками: область можно хорошо ограничить, вам не нужно понимать всю систему; задача замкнута (closed loop), то есть агент может самостоятельно оценить результат; результат не проходит по критическому пути — это временные инструменты или ПО для внутреннего использования, которое не влияет на реальных пользователей или доход; либо вам просто нужен «резиновый утёнок» (橡皮鸭), чтобы помочь подумать — по сути, вы отдаёте свои идеи на одну итерацию столкновения с сжатым знанием Интернета и синтетическими данными.

Если эти условия выполняются, то это подходящие задачи для агентов — при условии, что вы, человек, всё ещё являетесь финальным арбитром качества.

Например, использовать auto-research, который предложил Andrej Karpathy, чтобы оптимизировать время старта приложения? Отлично. Но условие в том, что вы понимаете: код, который он выдает, абсолютно не годится для продакшена. auto-research работает потому, что вы задаёте ему функцию оценки — и он оптимизирует вокруг конкретного показателя (например, время старта или loss). Но эта функция оценки покрывает только очень узкое измерение. Агент будет самоуверенно игнорировать все метрики, которые не входят в функцию оценки: качество кода, сложность системы, а иногда даже корректность — если сама функция оценки изначально ошибочна.

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

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

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

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

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

Ваш функционал будет меньше, но правильнее. Научиться говорить «нет» — это само по себе навык. Вы также сможете спокойно спать: вы хотя бы знаете, что происходит в системе, и по-прежнему сохраняете инициативу. Именно это понимание позволяет вам компенсировать проблемы recall в agentic search и сделать вывод агента более надёжным, а количество правок — меньшим.

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

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

[Ссылка на оригинал]

Нажмите, чтобы узнать о найме в BlockBeats

Добро пожаловать в официальное сообщество BlockBeats:

Telegram канал: https://t.me/theblockbeats

Telegram чат: https://t.me/BlockBeats_App

Twitter официальный аккаунт: https://twitter.com/BlockBeatsAsia