В середине августа 2026 года на Reddit появился пост, который быстро разошёлся по Hacker News и профессиональным чатам: пользователь под ником NenadConnor сравнил пять AI-фреймворков на одной и той же задаче — написать Rust-мидлвар с тремя жёсткими ограничениями. Результат оказался неудобным для индустрии: только его собственная кастомная система справилась полностью. Остальные либо генерировали неработающий код, либо игнорировали часть требований, либо не укладывались в разумное время.
Это не просто забавный эксперимент. Это срез текущего состояния AI-агентов для программирования: где они реально помогают, а где всё ещё сбиваются на простых, но строгих спецификациях. Разберём, что именно тестировалось, какие фреймворки участвовали и что из этого следует для инженеров, которые хотят внедрять агентов в свой пайплайн.
Что тестировали и почему это важно
Задача звучала просто: написать Rust-мидлвар, который обрабатывает HTTP-запросы. Три ограничения: использовать только безопасный Rust (no unsafe), строго соблюдать заданную сигнатуру функций и не использовать внешние крейты, кроме стандартной библиотеки и tokio. По сути — типичная задача для бэкенд-разработчика средней руки, но с чёткими рамками.
Участвовали пять фреймворков: Cursor, GitHub Copilot (с режимом агента), Claude Code, Devin и самописная система автора на базе LangGraph с кастомным промптом и циклом верификации. Каждому давался час на выполнение.
Результаты, опубликованные в Gist и на HN, показывают: только кастомное решение прошло все тесты. Copilot и Claude Code сгенерировали рабочий код, но с нарушениями ограничений — например, использовали unsafe внутри крейтов из зависимостей. Devin не завершил задачу за час. Cursor выдал код, который не компилировался.
Где фреймворки сломались
Первая и главная проблема — игнорирование явных ограничений. Ограничение «no unsafe» было прописано в промпте. Тем не менее, Copilot и Claude Code использовали крейты, которые внутри содержат unsafe-блоки. Формально они не нарушили букву требования, но нарушили дух — код не был «безопасным» в том смысле, который подразумевал автор.
Вторая проблема — несоблюдение сигнатур. Claude Code изменил API, добавив лишние параметры. Copilot сгенерировал код, который компилировался, но не проходил модульные тесты. Автор отмечает: «Фреймворки не понимают, что спецификация — это не рекомендация, а контракт».
Третья — время. Devin, который позиционируется как автономный AI-инженер, потратил 45 минут на анализ задачи и ещё 15 на генерацию, но так и не дошёл до стадии компиляции. Для реальной разработки это неприемлемо.
Что сделало кастомное решение успешным
Автор использовал LangGraph с двухэтапным пайплайном: сначала генерация кода с жёстким промптом, затем отдельный агент-верификатор, который проверяет каждое требование. Если проверка не проходит — цикл повторяется с уточнением ошибки. Ключевой элемент: верификатор написан на Python и не использует LLM для оценки — он запускает компилятор Rust и тесты.
Такой подход не нов, но он показывает, что текущие out-of-the-box фреймворки не имеют встроенной верификации контрактов. Они оптимизированы на скорость генерации, а не на точность соблюдения спецификаций. Для продакшн-кода это критично.
Ограничения эксперимента и что осталось за кадром
Эксперимент — не научное исследование, а единичный тест с одним промптом, одной задачей и одним автором. Результаты могут не воспроизводиться на других задачах. Кроме того, автор не раскрыл точные версии фреймворков и модель, которая использовалась в каждом случае. Copilot и Claude Code могли работать на устаревших моделях.
Тем не менее, паттерн ошибок совпадает с тем, что мы видим в более крупных бенчмарках: AI-агенты для кода часто игнорируют точные ограничения, если они не подкреплены автоматической верификацией. GitHub Security Lab в своём недавнем отчёте по оценке LLM для сканирования секретов пришли к похожему выводу: бенчмарки не отражают реальную точность, если не включают проверку на соответствие правилам.
Что можно проверить уже сейчас
Для разработчиков, которые хотят внедрять AI-агентов для кодогенерации, из этого теста можно вынести несколько практических шагов.
| Фреймворк | Результат | Основная проблема |
|---|---|---|
| Cursor | Код не компилировался | Ошибки синтаксиса и типов |
| GitHub Copilot (agent) | Код работал, но нарушал ограничения | Использовал unsafe-крейты |
| Claude Code | Код работал, но изменял API | Игнорировал сигнатуры функций |
| Devin | Не завершил задачу за час | Слишком долгий анализ |
| Кастомное решение (LangGraph + верификатор) | Прошёл все тесты | Двухэтапный пайплайн с компиляцией |
Что можно сделать прямо сейчас
Если используете AI-агента для генерации кода, добавьте отдельный шаг верификации: запуск компилятора, линтера и модульных тестов. Не полагайтесь на то, что агент сам проверит свой код.
2. Прописывайте ограничения не только в промпте, но и в коде верификатора. Если вы запрещаете unsafe, добавьте grep-проверку всех зависимостей.
3. Тестируйте агентов на своей типовой задаче, прежде чем внедрять. Результаты на бенчмарках могут не совпадать с реальной работой.
Эксперимент NenadConnor — не приговор AI-фреймворкам, но чёткий сигнал: индустрия всё ещё в фазе, где агенты хороши для черновиков и прототипов, но не для продакшн-кода с жёсткими контрактами. Пока эта проблема не решена на уровне фреймворков, ответственность за верификацию лежит на разработчике.