Що саме зламалося в 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 (stop-hook violations). До 8 березня їх майже не було, а потім стало в середньому до 10 на день. Зазвичай це виглядає як класична лінь production-моделі: не дочитав контекст, рано зупинився, почав просити підтвердження там, де раніше впевнено доводив завдання до кінця.
На рівні симптомів все знайоме кожному, хто використовував coding-агентів у реальних проектах. Замість точкового редагування модель частіше робить широкі, галасливі правки і видає той самий AI slop. Зовні відповідь виглядає впевнено, а всередині вона слабко спирається на реальний контекст проєкту.
В обговореннях це пов'язують із впровадженням «редагування мислення» (thinking redaction) у версії 2.1.69. Гіпотеза така: публічна версія стала гірше показувати або навіть гірше виконувати глибокий аналіз перед дією. Прямого офіційного розбору причини я поки не бачив, тому тут я б зберігав холодну голову: кореляція сильна, але це ще не фінальна першопричина (root cause).
Окремо з'явився прапор CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING. Сам по собі він нічого не доводить, але сам факт існування такого перемикача добре показує, де шукати проблему: в механіці адаптивного міркування, а не тільки в UI чи лімітах запитів.
Що це змінює для бізнесу та ШІ-автоматизації
Якщо коротко, я б перестав ставитися до coding-моделі як до стабільного шару інфраструктури. Сьогодні вона акуратно читає шість файлів перед редагуванням, завтра читає два і починає фантазувати. З погляду бізнесу це вже не «особливість моделі», а операційний ризик.
Найбільше тут виграють команди, у яких є власна спостережливість (observability) поверх LLM. Хто логує tool calls, рахує reads-before-edit, відстежує full-file rewrites, той хоча б бачить деградацію протягом дня. Хто просто дав розробникам Claude Code і сказав «користуйтеся», той дізнається про проблему зі зламаних PR.
Я це постійно повторюю в клієнтських проєктах: впровадження ШІ не можна будувати на довірі до однієї моделі. Потрібні захисні механізми (guardrails), тестові прогони, запасні маршрути та метрики якості на рівні конкретного робочого процесу. Інакше будь-яка тиха зміна поведінки моделі б'є по термінах і якості сильніше, ніж здається.
Для ШІ-автоматизації в розробці висновок теж жорсткий. Якщо агент може сам читати, змінювати й комітити код, йому потрібен не тільки доступ до репозиторію, але й система стримувань: політика щодо обсягу редагувань, перевірка читання контексту, пісочниця, автоскасування та обов'язкові тести перед мержем.
Ми в Nahornyi AI Lab саме так і збираємо архітектуру ШІ-рішень для інженерних процесів: не навколо магії моделі, а навколо контрольованого контуру. Модель може бути хоч Claude, хоч GPT, хоч локальна збірка. Якщо вона починає лінуватися, система повинна це зловити раніше, ніж клієнт побачить регресію в продакшені.
Історія з Claude Code мені подобається однією річчю: тепер у ринку є відтворюваний приклад «лінивих міркувань» (lazy reasoning) у продакшені. Не абстрактний страх, а конкретні метрики, дата перелому і відкритий інструмент аналізу. Для індустрії це корисний ляпас по самовпевненості.
Вадим Нагорний, Nahornyi AI Lab. Я власноруч збираю ШІ-агентів, coding automation та n8n-сценарії для реальних команд, тому на такі збої дивлюся не як спостерігач, а як людина, якій потім це лагодити в бою.
Якщо хочете обговорити ваш кейс, замовити ШІ-автоматизацію, замовити ШІ-агента на замовлення або зібрати n8n-автоматизацію з нормальними guardrails, пишіть. Подивимося, де у вас реальні ризики, і зберемо схему без сліпої віри в одну модель.