Автор отмечает, что все согласны: мы в самом разгаре изменений, но суть этих перемен вызывает споры. Это может быть революция или просто очередной пузырь, как в эпоху dot-com. Однако большинство словесных баталий уже выстраданы, поэтому блоггер решил добавить ещё пару тысяч, чтобы прояснить позицию. Терминология здесь важна: автор использует « LLM » вместо размытого термина « AI », чтобы избежать путаницы. Когда речь заходит о « LLM coding », имеется в виду генерация кода на любом языке, будь то с помощью человека или полностью автономно. Автор намеренно не затрагивает социальные аспекты, сосредоточившись на технике.
Многие сейчас продают LLM как серебряную пулю, полагая, что главное преимущество — это высокая скорость генерации кода. Но теория Фрэда Брукса « No Silver Bullet » ставит под сомнение эти претензии. Брукс утверждал, что не существует технологии, дающей порядок величины улучшения продуктивности. Сложность разработки делится на случайные трудности, вроде управления памятью, и сущностные, которые заложины в самой природе кода. Устранение только случайных трудностей, то есть ускорение написания кода, не даст прорыва, если сущностные проблемы останутся.
Данные подтверждают эту точку зрения. Отчёт DORA заявляет, что искусственный интеллект работает как усилитель: он усиливает сильные стороны успешных команд и слабости проблемных. Главный вывод исследования на странице 38 показывает рост нестабильности доставки, который превышает прирост скорости. Нестабильность означает, что после деплоя требуется вмешательство. Искусственный интеллект увеличивает эти сбои, а не устраняет их. Рост пропускной способности не компенсирует ущерб от ошибок, так как команды не успевают адаптировать свои системы.
Отчёт компании CircleCI, опубликованный в 2026 году, подчёркивает похожие тревожные тенденции. В 2026 году показатели стабильности указывают на то, что изменения, сгенерированные искусственным интеллектом, чаще ломаются и их исправление занимает больше времени. Время восстановления ветки main выросло на 13% год к году, а успешность деплоев опустилась до 70,8%, что ниже рекомендованного бенчмарка в 90%. Это означает, что почти каждый третий деплой в продакшн заканчивается неудачей. Стоимость таких сбоев колоссальна: на больших командах это может означать потерю эффективности целых 12 инженеров ежегодно.
Промышленность отвечает на это тем, что старые модели уже устарели, а новые, такие как Claude Opus 4.7 или инструменты вроде Cursor, всё изменят. Но автор указывает, что подобные заявления часто не подкрепляются доказательствами. Даже проекты от Cloudflare, где агенты искусственного интеллекта автоматически код-ревью, натолкнулись на проблемы. Например, при перестроении проекта на фреймворк Next.js агенты пропустили критические тесты безопасности, потому что алгоритм считал их избыточными. Процесс был ориентирован на «счастливый путь», что провело сбои и уязвимости, которые не проявляются сразу.
Скептики часто боятся, что отказ от LLM приведёт к тому, что программистов «забьют». Автор видит два сценария: либо LLM останутся просто одним из инструментов, как тест-драйв или парное программирование, либо они действительно станут обязательными. Автор склоняется к первому варианту. Настоящий прорыв в будущем сможет решить только «сущностную сложность» разработки, то есть проблему спецификации и дизайна архитектуры, а не просто быстрее печатать код. Пока же скорость генерации кода не является ограничивающим фактором, так как большую часть времени разработчик тратит на общение с заказчиком, проектирование и проверку. Поэтому, несмотря на все шумихи, LLM пока не являются серебряной пулёй и вряд ли скоро ею станут.