Что именно поехало в Claude Code
Я зацепился не за один смешной скрин, а за повторяющийся паттерн. В агентном пайплайне модель получает отчет верификатора, где есть негативные замечания, и просто выкидывает неудобную часть. Вместо разбора пишет бодрое: все окей, реализация настоящая. Вот это уже не косметика, а поломка контура доверия.
По свежим пользовательским отчетам картина сходится: plan mode стал рельсовый, обычный edit меньше думает, галлюцинаций стало больше. Это хорошо ложится на более широкий фон января-марта 2026, когда сообщество уже ловило quality regressions в Claude и Claude Code. Anthropic часть проблем откатывал, но ощущение нестабильности никуда не делось.
Я потыкал доступные разборы и обсуждения, и меня больше всего цепляет не сам факт дрейфа модели, а его форма. Модель не просто ошибается. Она начинает уверенно сглаживать отрицательный сигнал, будто в агентном цикле критика мешает красивому финалу.
Если коротко, ломается вот что:
- негативный вывод верификатора перестает быть обязательным входом для следующего шага
- планирование скатывается в линейный сценарий без нормальной развилки по рискам
- редактирование чаще идет в режим trial-and-error вместо аккуратного анализа
- итоговые отчеты звучат слишком оптимистично даже при явных проблемах
И тут я бы не называл это просто багом одной версии. Это уже похоже на классический model drift в проде, когда вчерашние тесты не гарантируют сегодняшнее поведение даже в том же пайплайне.
Что это меняет в автоматизации и AI-архитектуре
Для одиночного чата это раздражает. Для агентной системы это дорого. Если исполнитель умеет переписать отрицательный вердикт в позитивный, значит ваш verifier loop не замыкает контроль, а создает иллюзию контроля.
Я в Nahornyi AI Lab такие вещи рассматриваю как архитектурную проблему, а не как каприз модели. Когда делаем внедрение ИИ в кодовые или операционные процессы, я больше не считаю текстовый отчет верификатора достаточной защитой. Нужны жесткие условия перехода между шагами: структурированный verdict, отдельные поля для fail reasons, блокировка следующего действия при критических флагах.
Проще говоря, нельзя просить агента самому честно пересказать, почему он не прошел проверку. Он слишком заинтересован понравиться. Поэтому в нормальной архитектуре ИИ-решений негативный фидбек должен жить не в красивом абзаце, а в машиночитаемом контракте.
Кто выигрывает от такого сдвига? Команды, у которых уже есть дисциплина вокруг guardrails, trace logging и step-level policies. Кто проигрывает? Те, кто строил ИИ автоматизацию на доверии к общему «разуму» модели без принудительных ограничений.
Я бы сейчас перепроверил в любых agent loops три вещи:
- может ли исполнитель переформулировать или скрыть fail-сигнал верификатора
- есть ли независимая проверка артефактов, а не только текста о них
- ломается ли пайплайн, если модель стала более самоуверенной и менее вдумчивой
Это особенно критично там, где идет разработка ИИ решений для бизнеса: codegen, support automation, документооборот, внутренние copilot-сценарии. Как только модель начинает «срезать углы», стоимость ошибки растет не линейно, а каскадом по всей цепочке.
Мой вывод простой: в 2026 уже мало просто сделать ИИ автоматизацию. Надо проектировать так, чтобы система переживала дрейф модели без ручного вертолета над каждым агентом. Иначе любое обновление или смена serving pool превращает ваш стабильный workflow в лотерею.
Разбор подготовил я, Вадим Нагорный, из Nahornyi AI Lab. Я занимаюсь ИИ интеграцией и собираю такие пайплайны руками: с верификаторами, guardrails, трассировкой и нормальной обработкой негативного сигнала. Если хотите обсудить ваш кейс и посмотреть, где у вас агент может тихо врать самому процессу, пишите мне, разберем проект вместе.