После полугода интенсивных экспериментов с LLM-агентами для написания кода Джордж Хотц вынес приговор: быстрые прототипы — да, реальная разработка — катастрофа. По его оценке, баги, которые генерируют агенты, становятся всё сложнее отлавливать по мере роста кодовой базы. Это не ворчание скептика — это наблюдение человека, который сам строит AI-инфраструктуру.
Контекст
Джордж Хотц — основатель comma.ai (open-source автопилот) и tinygrad (минималистичный фреймворк для нейросетей), а также один из немногих людей, которые одновременно строят AI-продукты и готовы публично говорить о его ограничениях. Его репутация в индустрии держится не на медиа-выступлениях, а на конкретных проектах — именно поэтому его критика весит больше, чем очередное академическое предупреждение.
Рынок AI-агентов для разработки сейчас на пике хайпа. GitHub Copilot, Cursor, Devin, Claude Code, Gemini Code Assist — инструменты активно продвигаются как способ кратно ускорить разработку. Венчурные деньги идут в этот сегмент волнами. Корпорации закупают лицензии пачками. Весь нарратив звучит как «следующий уровень продуктивности инженера».
Но за пределами демо-роликов существует другая реальность. В сообществах разработчиков давно зреет скептицизм: AI хорошо пишет первый черновик, но плохо держит контекст, плохо рефакторит, плохо работает с большими кодовыми базами и генерирует ошибки, которые выглядят правдоподобно — а значит, их сложно заметить на ревью.
Аналитика
Хотц формулирует то, что многие чувствуют, но не говорят вслух: скрытый баг дороже медленного кода. Когда разработчик пишет баг сам — у него есть ментальная модель, почему он это написал. Когда баг генерирует агент, а человек его апрувит не глядя — ментальной модели нет ни у кого. Технический долг накапливается тихо. Стоимость отладки растёт нелинейно.
Это принципиальная проблема доверия, а не производительности. Coding agents действительно повышают скорость на стандартных задачах — бойлерплейт, CRUD, написание тестов по шаблону. Но там, где нужна архитектурная осознанность и понимание системных инвариантов, LLM работает статистически, а не каузально. Он предсказывает следующий токен, а не понимает, что должна делать система. Разница критична, когда цена ошибки высока.
Раскол в AI-сообществе реален. С одной стороны — Андрей Карпатий и другие, которые верят, что агенты переосмыслят профессию разработчика уже к концу десятилетия. С другой — практики вроде Хотца, которые видят системный риск в том, что индустрия строит зависимость от инструментов, которые не умеют объяснять собственные решения. Обе позиции имеют под собой основания.
Кейсы применения в бизнесе
B2B-SaaS стартап: агенты реально ускоряют ранние стадии — MVP, интеграции, API-обёртки. Правило одно: весь AI-генерированный код проходит через ревью человека с контекстом, а не просто «смотрит, нет ли синтаксических ошибок». Если команда меньше 5 инженеров и нет культуры ревью — coding agent создаст больше проблем, чем решит. Стоит ввести правило: любой PR с >40% AI-кода требует отдельного архитектурного ревью.
Корпорация с legacy: здесь риск максимальный. LLM плохо работает с кодом, написанным в другую эпоху, с неочевидными зависимостями и бизнес-правилами в комментариях десятилетней давности. Если вы внедряете агентов в легаси — начните с изолированных модулей, новых микросервисов, строго ограниченных контекстов. Не давайте агенту трогать критические пути без хирургической точности задания.
SMB и локальный бизнес в КР/СНГ: для небольших компаний, которые заказывают сайты и простые автоматизации, AI-агенты — уже реальный инструмент снижения стоимости. Но нужен подрядчик, который умеет проверять то, что генерирует AI. Слепая вера в то, что «агент написал — значит работает» — рецепт проблем через 3-6 месяцев, когда начнутся странные баги в production.
Кейсы в личной жизни
Разработчик: позиция Хотца — не «не используй агентов», а «не отключай голову». Продуктивная схема: агент пишет черновик, ты архитектурно ревьюишь и берёшь ответственность за каждую строку. Если ты не понимаешь, что написал агент — это твоя проблема, не агента. Используй инструмент как ускоритель набора, а не как замену мышлению.
Контент-мейкер и продакт без глубокого бэкграунда в коде: coding agents дают вам доступ к прототипам и скриптам, которые раньше требовали найма разработчика. Это ценно. Но для production-систем нужен технический ревьюер. No-code инструменты + AI-агент — сильная связка для быстрого прототипа; не надо делать из этого продукт без инженерного сопровождения.
Студент и начинающий разработчик: опасность здесь самая высокая. Если учишься — не давай агенту писать код, который ты ещё не понимаешь. Используй его как объясняющий инструмент («почему этот код работает?», «что здесь не так?»), а не как автора. Иначе пропускаешь этап формирования ментальных моделей, без которых senior-уровень недостижим.
Как применить сегодня
- Введи правило в команде: AI-генерированный код — это черновик, а не финальная версия. Каждый merge требует понимания, а не просто отсутствия ошибок линтера.
- Используй агенты на изолированных, новых модулях — не трогай ими критические или легаси-пути без опытного ревьюера.
- Добавь в процесс явный вопрос перед мержем: «Я понимаю, почему этот код работает именно так?» Если нет — разберись или перепиши.
- Для оценки реального качества AI-кода: попроси агента объяснить граничные случаи и возможные точки отказа в только что написанном коде. Качество объяснения — хороший индикатор глубины генерации.
- Следи за дискуссией: позиции Хотца, Карпатия, команд Anthropic и OpenAI по теме агентной разработки расходятся — читать все стороны полезнее, чем следовать одному нарративу.