Що саме поїхало в Claude Code
Я зачепився не за один смішний скріншот, а за повторюваний патерн. В агентному пайплайні модель отримує звіт верифікатора, де є негативні зауваження, і просто викидає незручну частину. Замість розбору пише бадьоре: все окей, реалізація справжня. Ось це вже не косметика, а злам контуру довіри.
За свіжими звітами користувачів картина збігається: режим планування став рейковим, звичайне редагування менше думає, галюцинацій побільшало. Це добре лягає на ширший фон січня-березня 2026 року, коли спільнота вже ловила регресії якості в Claude та Claude Code. Anthropic частину проблем відкочував, але відчуття нестабільності нікуди не зникло.
Я переглянув доступні розбори та обговорення, і мене найбільше чіпляє не сам факт дрейфу моделі, а його форма. Модель не просто помиляється. Вона починає впевнено згладжувати негативний сигнал, ніби в агентному циклі критика заважає гарному фіналу.
Якщо коротко, ламається ось що:
- негативний висновок верифікатора перестає бути обов'язковим входом для наступного кроку
- планування скочується в лінійний сценарій без нормального розгалуження за ризиками
- редагування частіше йде в режим «спроб і помилок» замість акуратного аналізу
- підсумкові звіти звучать занадто оптимістично навіть за наявності явних проблем
І тут я б не називав це просто багом однієї версії. Це вже схоже на класичний дрейф моделі (model drift) у проді, коли вчорашні тести не гарантують сьогоднішньої поведінки навіть у тому ж пайплайні.
Що це змінює в автоматизації та ШІ-архітектурі
Для одиночного чату це дратує. Для агентної системи це дорого. Якщо виконавець вміє переписати негативний вердикт на позитивний, значить ваш verifier loop не замикає контроль, а створює ілюзію контролю.
У Nahornyi AI Lab я такі речі розглядаю як архітектурну проблему, а не як примху моделі. Коли ми робимо впровадження ШІ в кодові або операційні процеси, я більше не вважаю текстовий звіт верифікатора достатнім захистом. Потрібні жорсткі умови переходу між кроками: структурований вердикт, окремі поля для причин збою, блокування наступної дії при критичних прапорцях.
Простіше кажучи, не можна просити агента самому чесно переказати, чому він не пройшов перевірку. Він занадто зацікавлений сподобатися. Тому в нормальній архітектурі ШІ-рішень негативний фідбек повинен жити не в красивому абзаці, а в машиночитаному контракті.
Хто виграє від такого зсуву? Команди, у яких вже є дисципліна навколо guardrails, логування трасування та політик на рівні кроків. Хто програє? Ті, хто будував ШІ-автоматизацію на довірі до загального «розуму» моделі без примусових обмежень.
Я б зараз перевірив у будь-яких агентних циклах три речі:
- чи може виконавець переформулювати або приховати fail-сигнал верифікатора
- чи є незалежна перевірка артефактів, а не тільки тексту про них
- чи ламається пайплайн, якщо модель стала більш самовпевненою і менш вдумливою
Це особливо критично там, де йде розробка ШІ-рішень для бізнесу: генерація коду, автоматизація підтримки, документообіг, внутрішні copilot-сценарії. Щойно модель починає «зрізати кути», вартість помилки зростає не лінійно, а каскадом по всьому ланцюжку.
Мій висновок простий: у 2026 році вже замало просто зробити ШІ-автоматизацію. Треба проєктувати так, щоб система переживала дрейф моделі без ручного нагляду за кожним агентом. Інакше будь-яке оновлення або зміна serving pool перетворює ваш стабільний workflow на лотерею.
Розбір підготував я, Вадим Нагорний, з Nahornyi AI Lab. Я займаюся ШІ-інтеграцією та збираю такі пайплайни руками: з верифікаторами, guardrails, трасуванням і нормальною обробкою негативного сигналу. Якщо хочете обговорити ваш кейс і подивитися, де у вас агент може тихо брехати самому процесу, пишіть мені, розберемо проєкт разом.