Skip to main content
anthropicclaude-codeai-automation

Claude Code стал лениться. И это уже измерили

После 8 марта 2026 у Claude Code заметно просело поведение в coding-задачах: модель стала меньше читать контекст перед правками и чаще делать ленивые, поверхностные изменения. Для бизнеса это тревожный сигнал: полагаться на coding-агента без своих метрик и защитных проверок уже опасно.

Что именно сломалось в Claude Code

Я люблю такие истории не за драму, а за то, что здесь наконец принесли не скриншоты из X, а нормальные цифры. В обсуждении, которое подхватил The Register, команда AMD AI Director Стеллы Лаурензо и независимый анализ истории использования показали деградацию Claude Code после 8 марта 2026.

Масштаб там не игрушечный: 6852 сессии, около 234 тысяч tool calls, почти 18 тысяч thinking blocks. Это уже не «мне показалось», а материал, который можно ковырять всерьёз.

Я отдельно посмотрел на репозиторий lazy-claude-analysis. Самое полезное в этой истории не сама жалоба, а то, что автор выложил скрипт и дашборд для воспроизводимого анализа. Вот это правильный путь: меньше эмоций, больше телеметрии.

По метрикам картина неприятная. Reads before edits упал с 6.6 до 2.0. Read/Edit ratio просел с 0.7 до 0.2. Иными словами, модель стала заметно реже читать код до того, как начинает что-то переписывать.

Ещё один красный флаг, на котором я завис, это stop-hook violations. До 8 марта их почти не было, потом стало в среднем до 10 в день. Обычно это выглядит как классическая лень production-модели: не дочитал контекст, рано остановился, начал просить подтверждения там, где раньше уверенно доводил задачу до конца.

На уровне симптомов всё знакомо любому, кто гонял coding-агентов в бою. Вместо точечного edit модель чаще делает широкие, шумные правки и выдает тот самый AI slop. Снаружи ответ выглядит уверенно, а внутри у него слабая опора на реальный контекст проекта.

В обсуждениях это связывают с rollout thinking redaction в версии 2.1.69. Гипотеза такая: публичная версия стала хуже показывать или даже хуже выполнять глубокий разбор перед действием. Прямого официального разбора причины я пока не видел, так что тут я бы держал голову холодной: корреляция сильная, но это ещё не финальный root cause.

Отдельно всплыл флаг CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING. Сам по себе он ничего не доказывает, но сам факт существования такого переключателя хорошо показывает, где искать проблему: в механике адаптивного рассуждения, а не только в UI или rate limits.

Что это меняет для бизнеса и ИИ-автоматизации

Если коротко, я бы перестал относиться к coding-модели как к стабильному слою инфраструктуры. Сегодня она аккуратно читает шесть файлов перед edit, завтра читает два и начинает фантазировать. С точки зрения бизнеса это уже не «особенность модели», а операционный риск.

Больше всех здесь выигрывают команды, у которых есть своя наблюдаемость поверх LLM. Кто логирует tool calls, считает reads-before-edit, отслеживает full-file rewrites, тот хотя бы видит деградацию в течение дня. Кто просто дал разработчикам Claude Code и сказал «пользуйтесь», тот узнает о проблеме по сломанным PR.

Я это постоянно повторяю в клиентских проектах: внедрение ИИ нельзя строить на доверии к одной модели. Нужны guardrails, тестовые прогоны, fallback-маршруты и метрики качества на уровне конкретного workflow. Иначе любая тихая смена поведения модели бьёт по срокам и качеству сильнее, чем кажется.

Для ИИ автоматизации в разработке вывод тоже жёсткий. Если агент может сам читать, менять и коммитить код, то ему нужен не только доступ к репозиторию, но и система сдержек: policy на объём edit, проверка чтения контекста, sandbox, автооткат и обязательные тесты перед merge.

Мы в Nahornyi AI Lab именно так и собираем архитектуру ИИ-решений для engineering-процессов: не вокруг магии модели, а вокруг контролируемого контура. Модель может быть хоть Claude, хоть GPT, хоть локальная сборка. Если она начинает лениться, система должна это поймать раньше, чем клиент увидит регрессию в проде.

История с Claude Code мне нравится одной вещью: теперь у рынка есть воспроизводимый пример lazy reasoning в production. Не абстрактный страх, а конкретные метрики, дата перелома и открытый инструмент анализа. Для индустрии это полезный щелчок по самоуверенности.

Вадим Нагорный, Nahornyi AI Lab. Я руками собираю ИИ-агентов, coding automation и n8n-сценарии для реальных команд, поэтому на такие сбои смотрю не как наблюдатель, а как человек, которому потом это чинить в бою.

Если хотите обсудить ваш кейс, заказать ИИ автоматизацию, заказать ИИ агента под заказ или собрать n8n-автоматизацию с нормальными guardrails, пишите. Посмотрим, где у вас реальные риски, и соберём схему без слепой веры в одну модель.

Поделиться статьёй