ИИ уже пишет 80% кода Anthropic. Самое тревожное спрятано в цифре, которую подают как успех

Самое тревожное в истории «ИИ пишет код» — не скорость и даже не ошибки ^[1]. А то, что всё чаще один и тот же ИИ и пишет изменения, и сам же их проверяет.

Anthropic с гордостью приводит цифру: их автоматический проверяющий задним числом поймал бы примерно треть ошибок из прошлых сбоёв рабочего кода. Переверните её: треть поймал — две трети пропустил.

А теперь главное. Если код пишет Claude и проверяет тоже Claude — у автора и проверяющего общие слепые места. Хитрую ошибку, которую сделает один, второй, скорее всего, не заметит. Оба слепнут в одной точке.

Ниже — спокойный инженерный разбор: почему «проверка ИИ» не равна независимой проверке, как измерить слепое пятно и как перенести сюда двухконтурную схему из мира промышленной безопасности.

Коротко — о чём текст

• Три цифры, которые нельзя смотреть по отдельности. Claude пишет больше 80% кода, строк кода на инженера стало в 8 раз больше. Но независимый замер (группа METR) показал обратное: ИИ замедлял опытных разработчиков примерно на 19%. «Кажется быстрее» и «на деле быстрее» — разные вещи.

• «У нас есть проверка» — это начало разговора, а не конец. Безопасность — это не наличие проверки, а измеренный размер её слепого пятна.

• Самая дорогая иллюзия — «независимая» проверка, когда и автор кода, и проверяющий — один и тот же ИИ. Лечится не вторым таким же ИИ, а набором проверок разной природы и замером того, насколько их промахи совпадают.

• Перенос в промышленность: та же двухконтурная схема, что в защитной автоматике (стандарт IEC 61508), плюс два коротких примера и место формальной проверки кода контроллеров.

1. Сначала три цифры — и почему их нельзя смотреть по отдельности

В начале июня 2026 Anthropic опубликовала отчёт «When AI builds itself» ^[2] о том, что её код всё больше пишет сам ИИ. Проверенные по первоисточнику факты:

• В мае 2026 больше 80% кода в рабочих системах Anthropic пишет Claude. Годом раньше — единицы процентов.

• Кода на одного инженера за квартал стало в 8 раз больше, чем когда-либо в 2021–2025.

• За апрель 2026 Claude выкатил больше 800 исправлений и снизил один класс ошибок примерно в тысячу раз — это оценили как работу четырёх человек за год.

• На задачах без готового решения успех вырос до 76% (плюс 50 пунктов за полгода).

И сразу — то, что делает картину честной. Anthropic сама оговаривает: строки кода — это объём, а не качество; «в 8 раз» почти наверняка завышено; самооценка инженеров (в 4 раза) — тоже скорее оптимизм.

А вот отрезвляющий внешний замер. В строгом эксперименте независимая группа METR получила обратное: ИИ замедлял опытных разработчиков примерно на 19% — хотя самим разработчикам казалось, что они ускорились.

Три цифры — 80%, в 8 раз, минус 19% — нужно держать вместе. Поодиночке каждая обманывает: первая впечатляет, вторая льстит, третья отрезвляет. Вместе вывод один: что-то реально сдвинулось, но измеряем мы это хуже, чем чувствуем.

Доля рабочего кода, написанного Claude.

Строк кода на инженера (2024 = 1).

METR: как долго ИИ работает сам без сбоев (логарифмическая шкала).

Успех на задачах без готового решения.

Все четыре графика — схематичные реконструкции по опубликованным числам. Точные ряды Anthropic не приводит; это иллюстрации тенденции, не данные.

Ещё штрих. Призыв Anthropic «иметь возможность притормозить» — условный: только если затормозят и другие лаборатории, в США и Китае. И прозвучал он примерно через неделю после закрытой заявки на биржевое размещение с оценкой около 965 млрд долларов. То есть даже ответ на риск упирается в проверку — а у проверки, как видно дальше, есть измеримые границы.

2. Три уровня самогенерации — чтобы не путать подсказку кода со взрывом интеллекта

Разведём три уровня, иначе всё смешается в кучу.

Почти все пугающие цифры — это первые два уровня. Anthropic описывает переход от первого ко второму и предупреждает о сползании к третьему. Важное: граница между вторым и третьим уровнем сегодня и есть наше окно времени.

Пока самообучение упирается в потолок (без свежих данных модель, обученная на собственных ответах, начинает накапливать ошибки и вырождаться), а эксперименты не переносятся в реальную работу один к одному, у нас есть время выстроить проверки — до того, как цикл станет слишком быстрым для человека. Вывод не «расслабьтесь», а «успейте».

3. Как это устроено: тот же конвейер, что в обычной разработке

Есть текущее состояние системы: версии моделей, код, настройки, права. ИИ-генератор (обозначу его F) предлагает изменение — заплатку, новую настройку, переобученную модель. Пока это только предложение. Проверка (обозначу её V) решает: пропустить — и изменение становится реальностью; не пропустить — откат к старому.

Рис. 1. Генератор F предлагает кандидата; проверка V сверяет его с правилами-инвариантами; пропустил — новое состояние, не пропустил — откат к старому.

Зачем отдельно правила-инварианты (обозначу I)? Тесты проверяют «вроде работает». Инварианты — то, что должно быть верно всегда: допустимые диапазоны, неприкосновенность логики безопасности, запрет на целые классы действий. Тонкость в том, что сам генератор не обязан их соблюдать — он гонится за метрикой, а не за безопасностью. Поэтому между ИИ и реальным миром обязательно должна стоять проверка. Иначе даже один процент вредных предложений со временем закрепится и расползётся по новым версиям.

Такие проверки у Anthropic уже есть: автоматический проверяющий читает каждое изменение перед вливанием в общий код; ускорять обучающий сценарий разрешено только без потери заранее зафиксированных проверок; отдельно идут тесты возможностей и безопасности. Казалось бы — добавь контур проверок, и порядок. Нет. И доказательство — в их же цифре.

4. Проверка хороша ровно настолько, насколько мало она пропускает

Вернёмся к «трети ошибок». Контур проверок не делает «ИИ улучшает ИИ» безопасным сам по себе. Он лишь переносит вопрос: с «есть ли проверка» на «насколько ей можно доверять». У любой проверки есть слепое пятно, и его размер — и есть мера доверия.

«Поймал треть» — значит, две трети ошибок остались незамеченными.

На своём материале (код для промышленных контроллеров, где всё можно довести до конца) я вижу два разных способа промахнуться, и второй опаснее.

Тихий пропуск. Дешёвая проверка говорит «всё хорошо», а дорогая (полный разбор всех состояний) находит реальное нарушение и показывает его по шагам. Это прямой аналог «двух третей, что пропустил проверяющий».

Невыразимость. Есть ошибки, которые дорогая проверка не умеет описать в принципе (у меня так вышло с 16-битной арифметикой и порядком вычислений в цикле контроллера). Про такой класс проверка не говорит ни «поймал», ни «пропустил» — он просто выпадает из отчёта. И это легко принять за «чисто».

Отсюда правило: общая оценка проверки честна только вместе со списком того, что она в принципе не умеет проверять. Иначе она завышает доверие — ровно так же, как «поймал треть» звучит как успех.

Безопасность — это не наличие проверки, а измеренный размер её слепого пятна.

5. Самая дорогая иллюзия — «независимая» проверка

Я требую, чтобы проверяющий был независим от автора кода. Но если код пишет Claude и проверяет Claude — у них общая архитектура и общие данные обучения ^[3], а значит, и общие слепые места. Хитрую ошибку (например, редкое совпадение двух событий) ИИ-автор сделает, а ИИ-проверяющий, скорее всего, пропустит. Это совпадающие промахи — и для двухконтурной схемы это главная угроза, а не мелочь.

Если проверки разной природы — промахи почти не совпадают, и набор закрывает дыры. Если оба проверяющих — ИИ одной природы, они слепнут вместе.

Что делать:

• Набор проверок разной природы. Не «ещё один такой же ИИ», а смесь: обычные анализаторы кода, формальные методы и ИИ другого производителя. Цель — чтобы промахи не совпадали.

• Измерять совпадение промахов, а не верить в него. Для каждой пары проверок берём отметки «пропустил / поймал» по набору дефектов и считаем, насколько их пропуски совпадают (эту величину обозначу φ; в литературе — мера совместного пропуска по Кунчевой–Уитакеру). Если совпадают — добавлять однотипную проверку бесполезно. Если не совпадают — что упустил один, поймает другой.

Это и есть линия моих работ: измерять, где проверки слепнут вместе. Как это сделать на практике — в следующем разделе.

Когда генератор и проверяющий видят мир одинаково, второй контур даёт не защиту, а общую слепую зону.

6. Как замерить слепое пятно у себя

Слепое пятно проверки не обязательно угадывать — его можно измерить. Идея простая: берём рабочий код, подсаживаем в него искусственные ошибки известных видов и смотрим, сколько из них проверка ловит.

Какие ошибки подсаживать:

• Логическая ошибка на единицу — перепутаны «меньше» и «меньше либо равно», сдвинут индекс.

• Снятая блокировка — убрано условие, которое не должно сниматься никогда.

• Гонка — два события приходят одновременно, и порядок обработки меняет результат.

• Неверная обработка отказа — при сбое датчика система идёт не по безопасной ветке.

• Переполнение — значение выходит за границы 16-битной арифметики.

Как считать:

1. Собрать набор подсаженных ошибок по каждому виду.

2. Прогнать его через каждую проверку и отметить по каждой ошибке: поймал или пропустил.

3. Доля пойманных по виду — оценка того, насколько проверка надёжна на этом классе.

4. Для пары проверок посчитать, насколько совпадают их промахи (та самая φ). Высокое совпадение — второй контур почти не добавляет защиты.

И сразу — как не обмануть себя этим числом. Оно зависит от того, насколько подсаженные ошибки похожи на реальные, и это не сертификат безопасности. А невыразимые классы (см. раздел 4) так измерить нельзя в принципе: их выносят отдельной строкой «не проверяется», а не записывают в «поймал ноль».

7. Где даже эта схема не справляется — честно о границах

• Обман метрики и вырождение модели. Для кода проверка работает. Но при обучении на собственных ответах все тесты могут формально проходить, а модель — вырождаться или находить способ обмануть саму метрику, не решая задачу. Тут проверка кода бессильна — нужны проверки поведения ^[4] и данных.

• Атака на саму проверку. Если генератор — самостоятельный агент, он может научиться обходить проверку, формально ничего не нарушая (например, растянув вредное действие во времени). Проверку надо испытывать и на устойчивость к обходу.

• Стоимость. Полностью перебрать все состояния большой нейросети невозможно. Ответ — не «проверить всё», а разбить систему на модули с проверяемыми стыками и проверять модули и стыки, а не всё целиком.

• Невыразимость лечится разбиением, а не смирением. Что нельзя проверить целиком — выносим на уровень, где это выразимо. Иногда дешевле гарантировать свойство по построению (сделать недопустимое состояние просто невозможным), чем ловить нарушение потом.

8. Перенос в промышленность: двухконтурная схема и стандарт IEC 61508

Сразу оговорка: проверка кода контроллеров — это не цикл обучения большой модели. Переносится только структура (петля «предложил → проверил → принял»), а не данные. Аналогия — не доказательство.

С этой оговоркой схема узнаваема: ИИ-контур предлагает изменения, контур безопасности решает, что попадёт в производство.

Рис. 2. ИИ-контур предлагает; в производство проходит только то, что пропустил контур безопасности (проверки плюс правила-инварианты).

Пример 1 (для иллюстрации). ИИ-оптимизатор предложил снизить энергопотребление узла, чуть изменив задержку срабатывания защиты. По метрике — улучшение; по правилу «время реакции ^[5] защиты не больше X» — нарушение. Независимый контур безопасности отклонил изменение: генератор «обошёл» защиту, не понимая, что трогает функцию безопасности.

Пример 2 (для иллюстрации). Изменение логики контроллера прошло обычные тесты, но формальная проверка свойства («никогда не открывать клапан при двух одновременных условиях») поймала сценарий, которого в тестах не было. Без неё это дошло бы до пусконаладки. Тесты «на удачу» — не то же, что инвариант.

Виды проверок:

9. Короткий список вопросов

Если хотя бы на половину пунктов ответ «нет / не уверен» — о безопасной самогенерации говорить рано.

1. Разделены ли тот, кто генерирует изменения, и тот, кто решает о выкатке, в зонах, критичных для безопасности?

2. Записаны ли явно правила, которые ИИ не вправе нарушать даже ради эффективности?

3. Есть ли независимый проверяющий — вне набора агентов и не переписываемый ими?

4. Проверки разной природы (анализаторы, формальные методы, ИИ другого производителя), и замерено ли, насколько их промахи совпадают?

5. Замерено ли слепое пятно проверки (например, подсадкой ошибок) — какой класс она пропускает?

6. Ведётся ли журнал всех шагов: кто предложил, какие проверки прошли, кто утвердил?

Мой вклад — сделать измеримыми пункты 4 и 5: превратить «у нас есть проверка» в «мы знаем и замерили, где она слепнет».

10. Что здесь факт, а что — моя рамка

• Факт (по первоисточнику Anthropic): больше 80% кода, в 8 раз за квартал с их же оговоркой «объём, не качество», самооценка в 4 раза, 800+ исправлений за апрель, 76% на задачах без готового решения, автоматический проверяющий и «треть ошибок». Внешнее — замедление около 19% в эксперименте METR.

• Разбор случая, не истина: Anthropic — один источник; для полноты нужны независимые работы о пределах самообучения.

• Моя рамка (не теорема): обозначения «генератор / проверка / инварианты» и три уровня самогенерации.

• Аналогия, не перенос: проверка контроллеров и цикл самогенерации совпадают по структуре, не по данным.

Заключение

Самогенерация ИИ — вопрос не «случится ли», а «в какой форме и под чьим контролем». Без проверки сохранить правила безопасности нельзя. Сами проверки — не новость: в промышленности так работают давно (защитные контроллеры, уровни безопасности, управление изменениями). Новое — что то же самое теперь нужно и для ИИ.

Но добавить проверку — это половина дела. Вторая, более трудная: замерить, где она слепнет, и не дать автору и проверяющему ослепнуть вместе. Пока мы не умеем честно мерить это слепое пятно — включая случаи, когда свойство нельзя проверить вовсе, — «у нас есть проверка» это начало разговора, а не его конец.

---

А как у вас: если завтра ИИ-агент начнёт сам предлагать изменения в вашу систему безопасности — кто и чем будет это проверять? Замерено ли, насколько совпадают промахи ваших проверок, и знаете ли вы заранее, какой класс ошибок они не ловят? Расскажите в комментариях о ваших примерах «независимой проверки» — особенно где промахи совпали там, где вы этого не ждали.