Создатель libGDX: ИИ-агенты копят ошибки быстрее, чем вы их замечаете
Марио Зехнер, создатель libGDX, написал пост о том, как автономные ИИ-агенты накапливают ошибки, создают неуправляемую сложность и теряют код при поиске. Его рецепт — замедлиться.
25 марта 2026 года Марио Зехнер, австрийский разработчик, создатель фреймворка libGDX и агентного фреймворка Pi для OpenClaw, опубликовал пост «Thoughts on Slowing the Fuck Down». За двое суток текст вышел в топ Hacker News, его процитировал Саймон Уиллисон, а Кэмерон Уэстланд написал ответное эссе «The Alignment Illusion».
Зехнер занимается инструментами для разработчиков больше 15 лет. Его libGDX используют тысячи программистов по всему миру. Когда такой человек пишет, что с ИИ-агентами что-то пошло не так, к этому стоит прислушаться.
Главный тезис поста: мы подсели на скорость генерации кода и потеряли контроль над результатом.
Софт ломается чаще, и агенты тут причём
Зехнер начинает с наблюдения, знакомого многим: софт стал хрупким. Аптайм 98% превращается из аномалии в норму, а в пользовательских интерфейсах живут баги, которые должны были отловить ещё на этапе тестирования.
Он приводит конкретные случаи. AWS столкнулся с инцидентом, предположительно связанным с ИИ-сгенерированным кодом. Amazon быстро опровергла связь, но внутри компании последовал 90-дневный «ресет». Сатья Наделла хвалится долей ИИ-кода в Microsoft, а пользователи Windows массово жалуются на деградацию качества. Компании, которые рекламируют «100% кода написано ИИ», выпускают продукты с утечками памяти в гигабайтах, падениями и сломанными функциями.
«По сарафанному радио я всё чаще слышу, как люди из компаний, и маленьких, и больших, говорят: мы загнали себя в угол агентным кодом», пишет Зехнер.
Три проблемы автономных ИИ-агентов
Ошибки копятся без обучения
Агенты ошибаются, как и люди. Но между ними есть две принципиальных разницы.
Человек учится на ошибках. Допустил баг, получил фидбек, через какое-то время перестал его допускать. У агента такой способности нет. Он будет делать одну и ту же ошибку раз за разом, пока вы явно не пропишете запрет в AGENTS.md или аналогичном файле правил. А для этого нужно ошибку заметить, что при потоке в тысячи строк кода в час непросто.
Кроме того, человек является узким местом в хорошем смысле слова. Разработчик физически не может выдать 20 000 строк кода за пару часов. Поэтому мелкие промахи накапливаются медленно, боль от деградации качества наступает постепенно, и есть время исправить курс. С армией агентов такого ограничения нет. Маленькие ошибки накапливаются с высокой скоростью. А вы, убрав себя из цикла, даже не знаете об этом, пока не станет поздно.
«Однажды вы оборачиваетесь, чтобы добавить новую фичу. Но архитектура, которая на этом этапе в основном состоит из ошибок, не позволяет агентам внести изменения так, чтобы ничего не сломалось», описывает Зехнер типичный момент осознания.
Агенты как продавцы сложности
Когда вы делегируете агенту не только написание кода, но и архитектурные решения, результат предсказуем: монструозная сложность.
Агенты обучены на данных, где полно «лучших практик» уровня Enterprise Java из 2015 года: абстракции ради абстракций, паттерны проектирования как самоцель, слои обёрток поверх обёрток. При этом каждый агент видит только свой кусок кода. Он не знает, какие решения принимали другие агенты или вы сами. Все решения локальны, и отсюда дублирование кода, несогласованность стилей, нагромождение абстракций.
В больших командах людей аналогичная деградация занимает годы. Организация успевает адаптироваться к нарастающей сложности. С командой из двух человек и армией агентов, по наблюдениям Зехнера, тот же уровень хаоса достигается за недели.
Агентный поиск по коду работает плохо
Прежде чем агент сможет что-то исправить или написать, ему нужно найти весь релевантный код в проекте. Зехнер называет это «agentic search» и указывает: чем больше кодовая база, тем ниже recall (полнота поиска).
Какие инструменты вы ни дайте агенту (ripgrep, LSP-сервер, индекс кодовой базы, векторную БД), с ростом проекта он всё чаще пропускает нужные куски кода. Именно поэтому появляется дублирование, несогласованность и те самые «маленькие ошибки», которые потом превращаются в неподъёмный ком.
Рецепт Зехнера: замедлиться и остаться в коде
Зехнер не предлагает отказаться от агентов. Его рецепт в том, чтобы ограничить зону их применения.
Хорошие задачи для агента: ограниченные по объёму, с замкнутым циклом обратной связи, не критичные для бизнеса. Автоматическое исследование по ускорению запуска приложения (как auto-research Карпати) подходит отлично. Генерация одноразовых утилит тоже. Но в каждом случае финальным фильтром качества остаётся человек.
Конкретные рекомендации из поста:
- Установите дневной лимит на объём кода, который генерирует агент, в рамках вашей реальной способности его ревьюить.
- Всё, что определяет «гештальт» системы (архитектуру, API, ключевые абстракции), пишите руками. Можно с tab-completion, можно в режиме парного программирования с агентом. Главное, будьте в коде.
- Давайте себе время думать. Возможность сказать «нет, нам это не нужно» сама по себе ценна.
- Используйте агентов для рутины и экспериментов, которые не успели бы попробовать сами. Потом берите хорошие идеи и доводите их до ума вручную.
По мысли Зехнера, замедление не убивает продуктивность. Вы вкладываетесь в понимание собственной системы. А понимание позволяет компенсировать низкий recall агентного поиска (вы знаете, где что лежит), быстро реагировать на инциденты и осознанно рефакторить.
Почему это важно сейчас
Пост появился в момент пика «агентного хайпа». Курсы по оркестрации агентов множатся, стартапы обещают полную автоматизацию разработки, компании соревнуются в процентах ИИ-сгенерированного кода.
Между тем практики, те, кто реально строит продукты, всё чаще фиксируют обратную сторону. Мы недавно писали о регрессиям при работе с ИИ-агентами: разработчики выгорают, потому что ревью агентного кода требует не меньше концентрации, чем написание с нуля. Зехнер описывает ту же проблему с другого ракурса: если ревью не делать, кодовая база деградирует до состояния, когда даже агенты не могут с ней работать.
ИИ-агенты не плохой инструмент. Но инструмент без дисциплины работает против вас. И пока LLM не научились учиться на своих ошибках в рамках одного проекта, эта дисциплина остаётся задачей человека.
