Skip to main content
AnthropicClaudeAI reliability

Чому Anthropic «впустила» Claude Code

Anthropic опублікувала постмортем щодо збоїв Claude Code: проблема була не в ядрі моделі, а в трьох продуктових змінах, які разом призвели до провалу. Для бізнесу це прямий урок з інтеграції ШІ: ламається не тільки модель, але й уся система, що її оточує.

Технічний контекст

Я уважно пройшовся по постмортему Anthropic від 23 квітня, і тут найцікавіше не в самому базі, а в тому, як акуратна на вигляд AI integration розвалилася через кілька дрібних рішень одразу. Якщо ви будуєте AI automation поверх LLM, це дуже знайомий сценарій: модель начебто та сама, а продукт раптово став дурнішим, забудькуватішим і сухішим.

Anthropic описала три незалежні зміни. Першу внесли 4 березня: у Claude Code знизили default reasoning effort з high до medium, щоб прискорити відповіді. На внутрішніх тестах падіння якості виглядало помірним, а в реальній роботі users отримали помітно слабший кодовий асистент. Відкотили це лише 7 квітня.

Друга зміна прилетіла 26 березня. Команда хотіла очищати кеш reasoning після години простою, але через баг очищення починало спрацьовувати на кожному наступному ході сесії. Звідси й відчуття, що Claude забуває контекст, повторюється і поводиться наче після удару по голові. Цей баг дожив до 10 квітня.

Третя зміна з'явилася 16 квітня, вже після релізу Opus 4.7. Щоб прибрати зайву багатослівність і скоротити витрату токенів, Anthropic додала обмеження в system prompt. І ось тут все склалося особливо неприємно: нова інструкція разом з іншими prompt-правками просадила якість кодингу відразу в кількох версій, включно з Sonnet 4.6, Opus 4.6 та Opus 4.7. Відкат зробили 20 квітня.

Ключовий момент: базова модель і core API, за словами Anthropic, не були зламані. Зламалася продуктова надбудова. Це, чесно, мій улюблений і найнеприємніший тип інцидентів, тому що винен не один великий реліз, а сума «безпечних» змін у параметрах, prompt-шарі та управлінні сесією.

Що це змінює для бізнесу та автоматизації

Для команд це дуже тверезий сигнал: деградація LLM-системи часто приходить не з моделі, а з обв'язки. Якщо у вас AI solution development зав'язаний на system prompts, кеш, роутинг і latency tuning, отже тестувати треба не тільки модель, а й увесь оркестр цілком.

Хто виграє? Ті, у кого є staged rollout, нормальні cohort-метрики та швидкий rollback. Хто програє? Команди, які вважають prompt «не кодом» і викочують такі зміни майже без інженерної дисципліни.

Я у себе давно ставлюся до prompt-шару як до частини архітектури, а не як до текстового файлика на коліні. У Nahornyi AI Lab ми якраз вирішуємо такі штуки для клієнтів: розкладаємо AI architecture по шарах, ставимо спостережуваність і прибираємо крихкі місця, які потім раптово з'їдають якість.

Якщо ви вже бачите, що ваш асистент то розумнішає, то тупіє без очевидної причини, це зазвичай не магія і не «модель втомилася». Можна спокійно розібрати ваш контур і build AI automation так, щоб він тримався не на удачі, а на інженерних гарантіях. Якщо хочете, в Nahornyi AI Lab я допоможу швидко знайти, де саме у вас тече прод.

Пов'язане дослідження вразливостей ШІ показало, як збій саморефлексії Claude може бути використаний через prompt injection, що потенційно веде до DoS-атак. Такі інциденти підкреслюють гостру необхідність у детальних постмортемах і надійних заходах безпеки при розгортанні ШІ.

Поділитися статтею