Поговорим об LLM (Bennett)

Апрельский пост 2026 года Джеймса Беннетта (James Bennett) на b-list.org объёмом в 6000 слов применяет эссе Фреда Брукса No Silver Bullet к циклу хайпа вокруг написания кода с помощью LLM. Беннетт - давний контрибьютор ядра Django - настроен скептически, но без нигилизма. Его аргументация уже и острее большинства критических заметок об LLM в этой wiki: LLM не способны дать прирост продуктивности разработки на порядок, поскольку узкое место заключается вовсе не в скорости генерации кода, и математические выкладки Брукса 1986 года это доказывают.

Теоретический аргумент

Главный ход Беннетта - отнестись к бруксовскому разделению на сущностную и привходящую сложность как к строгому количественному ограничению, а не как к риторической фигуре. Тезис Брукса состоял в том, что ни одно отдельное новшество не способно увеличить продуктивность в 10 раз за десятилетие. Логика проста: сложность ПО делится на сущностную (essential - концептуальное проектирование: спецификация, архитектура, тестирование абстрактной сущности) и привходящую (accidental - рутина представления: синтаксис, управление памятью, системы сборки). Если на долю привходящей сложности приходится менее 90% общих затрат, то даже её полное сведение к нулю не даст десятикратного роста.

Беннетт считает, что этот потолок ещё значительно ниже, чем предполагал Брукс. В зрелых областях - а сам Беннетт большую часть карьеры занимается веб-приложениями с базами данных - привходящая сложность, по его оценке, уже давно составляет меньше 50%. Механизм scaffolding в Rails генерировал CRUD-приложения по схеме БД ещё двадцать лет назад; современные фреймворки снизили привходящую сложность ещё сильнее, и LLM достался лишь хвост этой работы.

В подтверждение он приводит другую известную оценку Брукса из второй главы Mythical Man-Month: непосредственно на написание кода уходит лишь около 1/6 (17%) времени задачи. Даже если LLM сократят написание кода до нуля, теоретический потолок прироста составит существенно меньше 2x. Приведённая Беннеттом цитата CEO Tailscale формулирует это ещё прямолинейнее: если Claude пишет код за 3 минуты вместо 30, очередь на code review длиной в 5 часов никуда не исчезает.

Беннетт также замечает, что сам Брукс рассматривал "автоматическое программирование" как претендента на роль серебряной пули, цитируя Парнаса: "автоматическое программирование всегда было эвфемизмом для программирования на языке более высокого уровня, чем имелся в распоряжении на тот момент". Генерация кода по спецификациям на естественном языке - ровно то, ради чего сейчас продвигают LLM. Брукс утверждал, что языки более высокого уровня уже прошли точку, в которой могли давать революционный прирост; Беннетт переносит этот аргумент на LLM.

Эмпирический аргумент

Затем Беннетт обращается к свежим данным, намеренно используя отчёты, на которые обычно ссылаются сторонники LLM:

Заголовки отчёта DORA 2025 ("State of AI-assisted Software Development") выглядят позитивно, но разваливаются при внимательном чтении. DORA заявляет о росте пропускной способности, но одновременно фиксирует рост нестабильности доставки (delivery instability) - сочетание доли неудачных изменений (change fail rate, "развёртывания, требующие немедленного вмешательства") и доли доработок (rework rate, "внеплановые развёртывания после инцидентов в проде"). DORA не обнаружила никаких сглаживающих факторов: нестабильность по-прежнему бьёт по показателям продукта и приводит к выгоранию. График на странице 38 показывает, что рост нестабильности перевешивает рост пропускной способности.

DORA также заявляет об улучшении "продуктивности" и "качества кода", однако эти метрики основаны на самооценке участников опроса. Беннетт приводит исследование METR начала 2025 года как убойный контрпример: разработчики ожидали, что LLM ускорят их на 24%, в замеренных задачах фактически замедлились, но даже ощутив это замедление на практике, всё равно посчитали, что ускорились на 20%. Продуктивность по самооценке ничего не стоит: разрыв между восприятием и объективными измерениями стабилен и огромен.

Отчёт CircleCI 2026 ("State of Software Delivery") ещё более категоричен. Доля успешных слияний в основную ветку упала до 70.8% - это пятилетний минимум при рекомендуемом ориентире в 90%. За год время восстановления сломанного main выросло на 13%, а сломанных тематических веток (feature branches) - на 25%. CircleCI считает математику: для команды, отправляющей 5 изменений в день, падение с 90% до 70% означает переход от одной критической поломки раз в два дня к 1.5 поломкам в день. При 60-минутном восстановлении это даёт около 250 дополнительных часов отладки и заблокированных релизов в год, а при 500 изменениях в день - эквивалент 12 штатных инженеров.

Описанные в обоих отчётах "модели компетенций" (capabilities models) для извлечения пользы из LLM - строгий контроль версий, работа малыми партиями, внутренние платформы, ориентация на пользователей - это базовые требования, которые уже должны быть у любой успешной команды. Беннетт проводит аналогию с бригадой хирургов: если новая методика лучше всего работает у тех врачей, которые перед операцией моют руки, то это вывод вовсе не о достоинствах методики. Большая часть рекомендаций DORA восходит к Joel Test, Agile Manifesto и литературе по программной инженерии ещё 1970-х годов.

Пример из практики

Самый наглядный свежий пример - переписывание Next.js силами LLM в Cloudflare. Это идеальные входные условия: компетентная команда, отлично документированный и покрытый тестами целевой фреймворк, состязательный многоагентный рабочий процесс (один агент пишет, другой рецензирует, третий правит замечания). Итог: первый публичный релиз не мог запустить базовое приложение на Next.js по умолчанию и содержал проблемы с безопасностью. В публикации Cloudflare с разбором полётов прозвучала фраза, которую Беннетт выделил как самую точную цитату:

AI is now very good at getting a system to the point where it looks complete.

Специфика поломки весьма показательна: LLM действовала "от возможностей" (feature-first) - выбирала отдельную возможность для переноса и подтягивала тесты Next.js под неё. Такой подход даёт покрытие основного сценария (happy path), но упускает регрессионные тесты для краевых случаев, которые не привязаны строго к одной конкретной функциональности. В Next.js есть отдельная директория с тестами на тему "что происходит, если в файлах middleware отсутствуют обязательные экспорты"; этот тест так и не перенесли, поскольку посчитали, что middleware "уже покрыт" другими тестами. Отказоустойчивое поведение было незаметно утрачено. Это конкретная иллюстрация предупреждения читать сгенерированный код самому: выдача LLM, которая выглядит законченной, может не содержать инвариантов, обеспечивавших надёжность оригинала.

Беннетт вскользь упоминает, что недавняя утечка исходников Claude Code вызвала схожие комментарии: команда, которая, казалось бы, находится в наилучшей позиции для извлечения революционной отдачи от LLM, не демонстрирует прорыва.

Ответ на аргумент "вы останетесь позади"

Беннетт считает тезис "внедряйте сейчас, иначе отстанете" самым слабым доводом сторонников LLM. Его раскладка:

• Если права скептическая позиция, то позднее внедрение стоит ровно ноль. Вы просто освоите полезный инкрементальный инструмент, в который превратятся LLM (наравне с TDD, парным программированием или генерацией шаблонов в IDE), когда в этом появится смысл, или не станете осваивать вовсе.
• Если скептическая позиция окажется неправа, то серебряная пуля по определению должна поражать сущностную сложность - математика исключает получение такого эффекта за счёт одной лишь привходящей сложности. Но любая серебряная пуля, способная устранить сущностную сложность, сделает текущие навыки составления промптов для LLM устаревшими, ведь сегодняшний навык сводится именно к тому, "как сформулировать спецификацию и архитектуру программы в форме, пригодной для скармливания LLM". Таким образом, наработанный сегодня опыт ни от чего не страхует.

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

Ответ на аргумент о "демократизации"

Утверждение "LLM позволят непрограммистам писать программы" наталкивается на внутреннее противоречие. Сторонники LLM одновременно заявляют, что (а) успешное написание кода с помощью LLM требует серьёзных навыков - промпт-инжиниринга, управления контекстом, многоагентной оркестрации, умения понимать, когда выдаче можно доверять, и (б) это демократизирует разработку ПО для людей без опыта программирования. Оба утверждения не могут быть верны одновременно. Если разработка с LLM требует высокой квалификации, она не демократизирует процесс; если же она демократизирует процесс, исчезает аргумент о необходимости специальных навыков.

Беннетт также ссылается на Дейкстру и его статью о "глупости 'программирования на естественном языке'": естественный язык неоднозначен настолько, что структурно непригоден для спецификации программ, поэтому всегда потребуется некий формальный язык описания. Приводится и аналогия с 3D-печатью: её превозносили как инструмент тотальной демократизации производства, а в итоге она осталась нишевым хобби.

Самый опасный сценарий сбоя: пользователи без навыков программирования создают с помощью LLM софт, который кажется работающим, и развёртывают его в сферах с высокими требованиями к конфиденциальности и защите данных (здравоохранение, юриспруденция, финансы), где сбой всплывает спустя месяцы в виде утечки данных или незаметно искажённой финансовой модели.

Рекомендации

Уделять внимание базовым вещам. Контроль версий, исчерпывающие наборы тестов, непрерывная интеграция, внятная документация, быстрые циклы обратной связи, итеративная разработка, ориентация на пользователей, работа малыми партиями. Это ровно те практики, к которым снова и снова возвращаются отчёты DORA и CircleCI. Они известны десятилетиями, но на практике всё ещё встречаются редко. Команды, у которых этого нет, не способны переварить никакой рост объёма выдаваемого кода - хоть от LLM, хоть от кого-либо ещё.

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

Связанные страницы

Этот пост связывает воедино большую часть скептической линии вокруг LLM в нашей wiki:

• cult-of-vibe-coding - параллельный аргумент Брэма Коэна: отказ читать сгенерированный ИИ код - это доведённый до культа dogfooding
• building-syntaqlite-ai - 8 лет разработки, 3 месяца с ИИ, провал вайб-кодинга, дисциплинированное переписывание - практическая иллюстрация тезисов Беннетта
• log-distributed-llms - многоагентная разработка как задача распределённого консенсуса; пример Cloudflare у Беннетта показывает, как ограничения FLP и византийских генералов выглядят на практике
• llm-enshittification - расширенная критика LLM от разработчика Gentoo (кража данных, эксплуатация труда, copywashing)
• ai-great-leap-forward - корпоративное насаждение ИИ как ритуализированное производство
• subprime-ai-crisis - экономическая сторона: если прирост продуктивности сомнительный, финансовая модель рушится
• ai-bubble-pale-horses - чеклист признаков сдувания пузыря; эмпирические данные Беннетта согласуются со многими из них
• no-silver-bullet - концепция Брукса, к которой апеллирует Беннетт
• peril-of-laziness-lost - философское дополнение Кантрилла: человеческая лень (стремление к упрощению) - это тот самый механизм, который преодолевает сущностную сложность, и у LLM его нет
• if-ai-writes-your-code-why-use-python - противоположная позиция Митчема: проекты-артефакты (TS на Go, C-компилятор Карлини на Rust, перенос JS-движка Ladybird от Клинга) относятся к плотной привходящей сложности, где, согласно Бруксу, отдача от LLM должна быть максимальной; вопрос в том, масштабируется ли этот эффект