Anthropic сьогодні — один із найагресивніших гравців на ринку генеративного AI. Компанія, відома моделлю Claude, за останній рік перетворилася на еталон швидкості розробки: багато фіч виходять не за пів року, а за тиждень чи навіть день. У центрі цієї динаміки — Cat Wu, Head of Product для Claude Code та Cowork, яка відповідає за шлях від ідеї до релізу й за те, щоб маркетинг, продажі, фінанси та інфраструктура встигали за темпом інженерів.
Але висока швидкість неминуче загострює питання безпеки, надійності інфраструктури та меж платформи. Anthropic уже зіткнулася з резонансним витоком вихідного коду Claude Code, змушена обмежувати використання Claude у сторонніх продуктах і паралельно нарощувати обчислювальні потужності, щоб не «задихнутися» від попиту. Попри активне використання власних моделей, включно з Mythos, компанія наполягає: головний драйвер швидкості — не магічні внутрішні інструменти, а процеси, очікування й культура відповідальності інженерів.
Ця стаття розбирає, як Anthropic намагається поєднати екстремальний темп розробки з безпекою, що змінилося після витоку коду, як компанія мислить інфраструктурними обмеженнями та чому свідомо звужує платформу, відмовляючись від частини інтеграцій.
Людська помилка, а не збій AI: що насправді сталося з витоком Claude Code
Витік вихідного коду Claude Code став одним із найгучніших інцидентів навколо Anthropic. На тлі загальної тривоги щодо «неконтрольованих» можливостей моделей було легко припустити, що проблема криється в самій AI‑системі чи в її безпекових механізмах. Внутрішнє розслідування компанії дало іншу картину.
Anthropic дійшла висновку, що витік був наслідком суто людської помилки під час pull request, який змінював логіку релізу пакетів. Це не був злам інфраструктури, не був збій моделі й не був провал системи безпеки. Код, який зрештою призвів до витоку, був:
- написаний з допомогою Claude,
- перевірений двома рівнями людського рев’ю,
- інтегрований у продакшн як частина звичайного процесу оновлення.
Цей ланцюжок особливо показовий. По‑перше, він демонструє, що AI‑асистований код не є автоматично безпечнішим чи небезпечнішим — він підкоряється тим самим операційним ризикам, що й звичайний. По‑друге, навіть подвійний людський контроль не гарантує виявлення тонких операційних помилок, особливо коли команда працює в режимі постійних релізів.
Anthropic фактично отримала «стрес‑тест» власної культури швидкого шипінгу. Компанія вже до цього зменшила типові цикли розробки з приблизно шести місяців до одного місяця, тижня або навіть одного дня для окремих фіч. Витік показав, що за таких темпів класичні практики — рев’ю коду, CI/CD, внутрішнє «догфудинг» — потребують додаткового посилення саме там, де йдеться про чутливу логіку релізів, доступів і розповсюдження.
Ключовий висновок: проблема не в тому, що Claude «написав щось небезпечне», а в тому, що організаційні процеси дозволили цій зміні пройти всі фільтри. Це важливий сигнал для всієї галузі, яка масово переходить на AI‑асистований девелопмент: поєднання моделей і стандартних практик рев’ю не скасовує потреби в спеціальних запобіжниках для операційно критичних змін.
Як Anthropic «загартувала» процеси після інциденту — і не загальмувала релізи
Після витоку коду Anthropic не обмежилася констатацією людської помилки. Компанія посилила внутрішні процеси так, щоб знизити ймовірність подібних інцидентів у майбутньому, але при цьому не зруйнувати головну конкурентну перевагу — швидкість.
Точні технічні деталі змін не розкриваються, але загальний вектор зрозумілий: було «загартовано» саме ті ділянки пайплайну, де невелика помилка може мати непропорційно великі наслідки. Йдеться про:
- те, як рецензуються й тестуються зміни, що стосуються релізної логіки та розповсюдження пакетів;
- те, хто й за яких умов може ініціювати такі зміни;
- те, як відокремлюються експериментальні можливості від чутливих елементів інфраструктури.
Важливий контекст: Claude Code команда загалом побудована так, щоб мінімізувати бар’єри до шипінгу. Більшість фіч виходять у форматі чітко позначеного research preview. Це зменшує зобов’язання перед користувачами, дозволяє швидко відкочувати або радикально змінювати функціональність і дає змогу інженерам виводити ідеї до продакшну за тиждень чи менше.
Щоб така модель не перетворилася на хаос, Anthropic тримає кілька опорних структур:
- щотижневі метрик‑рід‑аути для всієї команди, де розбираються ключові цілі, тренди й драйвери;
- письмовий набір командних принципів, який фіксує, хто є ключовим користувачем, чому саме він, і які компроміси команда готова приймати;
- чіткий, повторюваний процес запуску: інженер, який вважає фічу готовою й «продогфудженою», постить її в «вічну launch‑кімнату», після чого маркетинг, документація та деврел за замовчуванням підхоплюють реліз наступного дня.
Після витоку коду компанія не відмовилася від цієї моделі, а радше уточнила, де саме швидкість є прийнятною, а де потрібні додаткові запобіжники. Фактично Anthropic розділяє світ на дві зони:
- зону швидких експериментів, де research preview, гнучкі очікування користувачів і легкий відкат дозволяють рухатися майже без тертя;
- зону критичної інфраструктури, де зміни проходять посилений контроль, навіть якщо це коштує додаткових годин чи днів.
Це компроміс, з яким рано чи пізно доведеться визначитися кожній AI‑компанії, що намагається одночасно бути і «лабораторією майбутнього», і постачальником стабільного продукту для бізнесу.
Межі платформи: чому Anthropic обмежує сторонні продукти на кшталт OpenClaw
Ще один блок рішень Anthropic, який напряму пов’язаний із безпекою та керованістю, — це політика щодо сторонніх продуктів, які будуються поверх Claude. На тлі вибухового попиту на моделі компанія зіткнулася з тим, що окремі сервіси почали активно використовувати підписки Claude у власних продуктах, фактично перетворюючи їх на «бекенд» для своїх рішень.
Одним із таких прикладів став OpenClaw — інструмент для побудови персональних AI‑агентів. Anthropic ухвалила рішення обмежити використання підписок Claude у подібних сторонніх продуктах. Мотивація була не в тому, щоб «закрити екосистему» як таку, а в тому, щоб чітко розставити пріоритети:
- у першу чергу — власні продукти Anthropic, включно з Claude Code і Cowork;
- у другу — офіційний Claude API як основний канал для розробників;
- і лише в межах цих рамок — інтеграції зі сторонніми сервісами.
Це рішення фактично окреслює межі платформи. Anthropic сигналізує, що не хоче, аби масове споживання через непрямі канали підривало досвід користувачів у першопартійних продуктах або створювало неконтрольовані навантаження на інфраструктуру. У ситуації, коли попит на моделі зростає швидше, ніж встигає масштабуватися обчислювальна база, подібні обмеження стають не стільки бізнес‑вибором, скільки операційною необхідністю.
Для розробників це означає більш чітке розділення: якщо продукт хоче глибоко інтегруватися з Claude, він має робити це через офіційний API, а не через «перепаковані» підписки кінцевих користувачів. Для Anthropic — це спосіб зберегти контроль над тим, як і в яких обсягах використовується модель, і водночас не розмити власну продуктову лінійку.
Інфраструктура як продуктове обмеження: масштабування, токени й ефективність
Швидкість релізів — лише одна сторона медалі. Інша — здатність інфраструктури витримати навантаження й зробити це економічно доцільно. Anthropic прямо трактує ємність і вартість як «першокласні» продуктові обмеження, а не як щось, що можна віддати на відкуп бекенду.
Попит на Claude зростає настільки швидко, що компанія змушена паралельно вирішувати дві задачі:
перша — масштабувати інфраструктуру, щоб обслуговувати дедалі більшу кількість запитів;
друга — підвищувати токен‑ефективність, тобто зменшувати кількість обчислень (і, відповідно, витрат) на одиницю корисної роботи.
Це не лише питання витрат на GPU чи хмарні ресурси. Для продуктової команди Claude Code й Cowork це означає, що кожна нова фіча має оцінюватися не тільки за користю для девелопера чи аналітика, а й за тим, як вона вплине на загальне споживання токенів. Наприклад, зміна, яка робить промпти довшими або збільшує кількість автоматичних викликів моделі, може бути корисною з точки зору UX, але неприйнятною з точки зору інфраструктурної вартості.
Тому Anthropic працює в двох площинах:
- на рівні моделей — над тим, щоб вони виконували більше корисної роботи за меншу кількість токенів;
- на рівні продукту — над тим, щоб інтерфейси й флоу не стимулювали зайвих викликів моделі, а навпаки, заохочували більш «щільні» й осмислені взаємодії.
Це ще один приклад того, як інфраструктурні реалії безпосередньо формують продуктову стратегію. Коли модель стає ядром продукту, питання «скільки це коштує в токенах» стає таким самим важливим, як «наскільки це зручно користувачу».
Міф про «чарівні внутрішні інструменти»: роль Mythos і процесів
На тлі феноменальної швидкості релізів Anthropic природно виникло припущення: компанія, мабуть, просто має настільки потужні внутрішні моделі й тулінг, що це й пояснює її темп. Особливу увагу привернув Mythos — дуже сильна модель, яка поки що перебуває в прев’ю, зокрема через побоювання щодо потенційних можливостей.
Anthropic дійсно використовує власні моделі внутрішньо, включно з Mythos. Це допомагає пришвидшити окремі етапи роботи — від написання коду до аналізу даних. Однак у компанії наголошують: основна частина приросту швидкості пояснюється не Mythos, а процесами й очікуваннями.
Команда Claude Code вже кілька кварталів працює в режимі, коли:
- більшість фіч запускаються як research preview;
- інженери можуть довести ідею до релізу за тиждень або менше;
- кросфункціональні команди (маркетинг, документація, деврел) інтегровані в процес так, що можуть підтримати реліз буквально наступного дня після технічної готовності.
Внутрішні моделі, безумовно, роблять окремі кроки швидшими. Але вони не замінюють базову організаційну роботу: чіткі цілі, прозорі метрики, узгоджені принципи, добре налаштований пайплайн релізів. Саме ці елементи дозволяють Anthropic одночасно:
- швидко експериментувати;
- відносно безболісно переживати помилки (як у випадку з витоком коду, після якого процеси були посилені, але не паралізовані);
- масштабувати успішні патерни на різні продуктові напрями.
Це важливий контраргумент до популярної в індустрії ідеї, що «секретна зброя» AI‑компаній — це насамперед їхні внутрішні моделі. У випадку Anthropic значна частина переваги лежить у площині організації праці, а не лише алгоритмів.
Інженери з продуктовим смаком: чому Anthropic концентрує відповідальність на індивідуальному рівні
Ще один ключовий елемент моделі Anthropic — те, кого саме компанія наймає й як розподіляє ролі між інженерами та продакт‑менеджерами. Cat Wu прямо говорить: компанія свідомо шукає інженерів із сильним продуктовим смаком.
Ідея проста: якщо інженер не лише пише код, а й добре відчуває користувача, розуміє бізнес‑контекст і може самостійно приймати рішення про UX‑компроміси, він здатен доставляти фічу «під ключ» — від ідеї до релізу — з мінімальною участю PM. У такій моделі:
- продакт‑менеджер більше фокусується на загальній траєкторії продукту, узгодженні з іншими функціями (маркетинг, продажі, фінанси, capacity), визначенні ключових користувачів і цілей;
- інженер бере на себе більшу частину відповідальності за конкретну реалізацію, UX‑деталі й швидкість шипінгу.
Це прискорює розробку, але водночас концентрує більше відповідальності на рівні окремого індивіда. Інженер у такій системі не може сховатися за «я просто зробив, як сказали в PRD». Він стає співвласником продуктового рішення, а не лише його технічним виконавцем.
Для Anthropic це логічне продовження загальної філософії: мінімізувати кількість «передач м’яча» між ролями, зменшити бюрократію й дозволити людям із хорошим продуктовим чуттям діяти максимально автономно. Для індустрії загалом це сигнал, що в AI‑компаніях майбутнього межа між «інженером» і «продактом» ставатиме дедалі розмитішою.
Висновок: модель високої швидкості з вбудованими обмеженнями
Історія Anthropic — це не просто історія компанії, яка «шипить швидше за всіх». Це приклад того, як організація намагається поєднати три, на перший погляд, суперечливі цілі:
- підтримувати екстремальний темп розробки й релізів;
- зберігати високу планку безпеки й керованості, особливо після інцидентів на кшталт витоку коду;
- працювати в умовах жорстких інфраструктурних обмежень, де capacity й вартість токенів стають ключовими продуктовими параметрами.
Відповідь Anthropic — у комбінації процесів і принципів: research preview як стандарт для нових фіч, чіткі командні правила, які дозволяють людям приймати рішення без постійного погодження, посилені запобіжники для критичної інфраструктури, свідоме обмеження сторонніх інтеграцій на кшталт OpenClaw, фокус на токен‑ефективності й найм інженерів із сильним продуктовим смаком.
Внутрішні моделі, включно з Mythos, безумовно, додають швидкості. Але, якщо вірити самій Anthropic, справжня перевага — у тому, як організована робота людей навколо цих моделей. Для решти індустрії це, можливо, головний урок: у світі, де код стає дешевим, найдефіцитнішим ресурсом стають не моделі, а процеси, які дозволяють будувати з ними безпечно — навіть на повній швидкості.
Джерело
How Anthropic’s product team moves faster than anyone else | Cat Wu (Head of Product, Claude Code)