Все программисты теперь QA-инженеры для ИИ-генерации кода
Anthropic утверждает, что 80–90% её собственного кода создаёт Claude. Это звучит как маркетинговый ход, но за ним скрывается реальная проблема: инженеры всё больше времени тратят не на написание кода, а на проверку того, что написала нейросеть.
Программирование постепенно превращается из создания кода в ревизию чужих — причём чужой здесь выступает не человек, а языковая модель, у которой нет понимания архитектуры.
80% — это либо пиар, либо инженерный компромисс
В начале июня 2026 года Anthropic* опубликовала статистику, которая вызвала бурную дискуссию: 80% написанного компанией кода генерируется Claude, а для новых фич эта доля доходит до 90%. Цифра громкая, и она заслуживает скептического взгляда.
Во-первых, это заявление исходит от компании, которая сама делает Claude. Использовать свой же продукт для разработки и одновременно продвигать его как прорывный инструмент — конфликт интересов, который стоит иметь в виду. Когда Anthropic говорит, что Claude отлично справляется с кодом, она одновременно рекламирует модель, на которой зарабатывает деньги. Это не значит, что цифра ложная, но контекст важен.
Во-вторых, «80% кода сгенерировано» — это расплывчатая метрика. Что считать «сгенерированным»? Полностью написанная нейросетью функция? Файл, где Claude сгенерировал 60% строк, а человек дописал 40%? Рефакторинг, предложенный инструментом и принятый инженером? Без точных критериев цифра — маркетинговая однозначно, а не инженерная.
Но даже если принять её за чистую монету, за ней стоит любопытный сдвиг.
Что на самом деле происходит с кодом Claude Code
Ранее в 2026 году в открытый доступ попал исходный код Claude Code. Сообщество изучило его с пристрастием — и результаты оказались неоднозначными.
Главный файл, main.tsx, содержал 4 683 строки. Это не просто большой файл — это файл, который практически непригоден для ручного сопровождения. Ни один инженер не станет сознательно писать монолит такой длины, но языковая модель, работающая по принципу предсказания следующего токена, не думает об архитектуре в принципе. Она генерирует код, который решает текущую задачу, не заглядывая вперёд и не задумываясь о том, кто и как будет этот код читать через полгода.
Далее — 460 комментариев eslint-disable. Это отключения правил линтера, то есть намеренное подавление автоматических проверок качества. Смысл линтера в том, чтобы ловить проблемные паттерны на автомате. Если вы отключаете его 460 раз — зачем он вообще включён? Для человека такое количество отключений выглядело бы как признак халатности. Для нейросети это побочный эффект: модель не чувствует ответственности за долгосрочную поддерживаемость кода.
Плюс классические комментарии вроде // TODO: figure out why и // This fails an e2e test. Если 80% кода написал Claude, логично ожидать, что и на поиск причин этих TODO и исправление сломанных тестов уйдёт часть этого же ресурса. Но, видимо, не уходит.
Экономика токенов: роскошь, которую может себе позволить только Anthropic
Здесь есть важный нюанс, который большинство обсуждений упускает. Anthropic — компания, которая производит модель Claude. Она может выделять на свои проекты неограниченный объём токенов для inference. Это как если бы завод машин давал своим сотрудникам бесплатные автомобили: стоимость владения для них искусственно снижена.
Для обычной компании, покупающей API-доступ к Claude, каждая генерация — это реальные деньги. Каждая перегенерация кода, каждая итерация, каждый «а попробуй ещё раз» — это токены, которые списываются с баланса. Когда Anthropic говорит, что генерирует 80% кода, она не говорит, сколько токенов на это уходит и сколько перегенераций требуется, чтобы получить приемлемый результат.
Это создаёт искажённую картину. Снаружи выглядит так: «нейросеть пишет наш код, мы просто проверяем». На деле может оказаться: «нейросеть генерирует десятки вариантов, инженер фильтрует мусор, правит руками, и итоговый файл на 40% состоит из human-written кода, который появился только потому, что сгенерированный вариант был непригоден».
Проблема качества, о которой не говорят
Ключевой тезис статьи, на основе которой мы разбираем эту тему, звучит так: когда инструменты генерации кода берут на себя большую часть написания, инженеры постепенно превращаются в QA для продуктов нейросети. И это не просто стилистическое преувеличение — за ним стоит реальный инженерный конфликт.
Код, написанный человеком, несовершенен, но он несёт в себе контекст: разработчик понимает, почему решение принято именно так, как оно вписывается в архитектуру, какие edge cases могут возникнуть. Нейросеть не имеет этого контекста. Она генерирует правдоподобный код — код, который компилируется, проходит базовые тесты, но может содержать тонкие логические ошибки, которые всплывут только в продакшене.
Утверждение автора о том, что вместо «10x productivity» стоит целиться в «7x productivity и 3x quality», звучит разумно, но его сложно верифицировать. Нет никаких метрик, показывающих, что такое распределение возможно или оптимально. Это эмпирическое наблюдение, а не инженерный расчёт.
Что это значит на практике
Для инженеров и команд, активно использующих Claude Code, Cursor, Copilot и аналогичные инструменты, ситуация сводится к нескольким практическим выводам.
Проверка кода становится основной работой. Если раньше QA проверял ручную реализацию, а разработчик — свои куски, то теперь оба проверяют результат работы нейросети. Роль разработчика смещается от «написал — протестировал — задеплоил» к «направил модель — получил код — проверил — дописал — ещё раз проверил».
Технический долг растёт экспоненциально. Нейросеть не думает о рефакторинге. Каждый сгенерированный файл — это потенциальный новый кусок legacy-кода. При объёме 80–90% генерации долг накапливается с невиданной скоростью, и кто-то всё равно будет его выплачивать. Вопрос — кто и на какие деньги.
Кодовая база становится менее читаемой. Файл в 4 600 строк — это не аномалия, а закономерность при работе с LLM. Модели не имеют стимула дробить код на модули, если текущий контекст позволяет сгенерировать монолит. Инженер, пришедший разбираться в таком коде через год, окажется в заведомо худшем положении, чем если бы читал human-written legacy.
Нужны новые практики тестирования. Стандартные подходы к code review и unit-тестированию, рассчитанные на человеческий код, могут быть недостаточны. Приходится думать о property-based тестировании, fuzzing, более агрессивном static analysis — всего того, что может поймать ошибки, которые человек вряд ли написал бы, но нейросеть — запросто.
Обратная сторона «доверяй, но проверяй»
Автор оригинальной статьи описывает свой подход как «trust but verify» — доверяй, но проверяй. Это разумная позиция, но она содержит скрытый парадокс. Если вы проверяете каждый кусок кода, сгенерированный нейросетью, то вы фактически пишете его дважды: один раз — модель, второй раз — вы, в голове, прогоняя логику. В какой момент проверка стоит столько же, сколько самостоятельное написание?
Нет надёжного способа это измерить, но интуитивно понятно: существует точка, за которой автоматизация перестаёт экономить время и начинает его пожирать на overhead проверки. Где именно эта точка — зависит от сложности задачи, размера контекстного окна модели и опыта инженера.
Итого
Anthropic использует собственную статистику как рекламу, и это стоит воспринимать соответствующе. Но за маркетинговым пузырём скрывается настоящий тренд: роль программиста в эпоху LLM-ассистированной разработки меняется. Не в сторону « writes itself», как обещают на лендингах, а в сторону инженера-ревизора, который тратит всё больше времени на то, чтобы убедиться, что нейросеть не натворила дров.
Кто-то назовёт это прогрессом. Кто-то — регрессом в качества при росте количества. Скорее всего, истина где-то посередине, но она точно не в цифре «80%» без оговорок и контекста.
* Meta* — входит в перечень общественных объединений и религиозных организаций, в отношении которых судом принято вступившее в законную силу решение о ликвидации или запрете деятельности по основаниям, предусмотренным Федеральным законом от 25.07.2002 № 114-ФЗ «О противодействии экстремистской деятельности».