Швидкість, із якою Anthropic виводить на ринок нові можливості Claude Code, стала предметом обговорення всієї індустрії. На тлі компаній, які досі планують релізи на горизонті пів року, команда Claude Code навчається жити в режимі тижнів, днів і навіть годин. На передньому краї цього зсуву — Cat Wu, Head of Product для Claude Code та Cowork, яка разом із техлідом і продуктовим візіонером Борисом Черні будує одну з найдинамічніших AI‑продуктових організацій сьогодні.
Їхній підхід до швидкості не зводиться до «маємо кращу модель, тому все летить». Anthropic дійсно активно використовує власні моделі всередині компанії, але самі там наголошують: основний приріст швидкості дає не стільки AI, скільки радикально переосмислені процеси, очікування та культура. Це історія про те, як саме побудовано цю «машину релізів» — і що з цього можуть запозичити інші AI‑команди.
Від піврічних релізів до одноденних: як змінилися горизонти планування
Ще кілька років тому типовий цикл розробки складних технологічних продуктів вимірювався місяцями. У класичній моделі PM‑и працювали з 6–12‑місячними дорожніми картами, ретельно узгоджували залежності з іншими командами, а код вважався «дорогим» ресурсом, який потрібно максимально захищати від переробок.
У світі AI ця логіка почала ламатися. Моделі швидко еволюціонують, інструменти розробки стають значно продуктивнішими, а очікування користувачів зростають у геометричній прогресії. В Anthropic це відчули настільки гостро, що довелося буквально перезібрати часову шкалу продукту.
За словами Cat Wu, для багатьох функцій Claude Code часові рамки скоротилися з приблизно шести місяців до одного місяця, одного тижня, а іноді — до одного дня. Це не поодинокі «геройські» історії, а нова норма, під яку перебудовано все: від ролі PM до способу, яким команда працює з маркетингом і документацією.
Ключова зміна — у фокусі. Замість того, щоб витрачати левову частку часу на узгодження багатоквартальних роадмапів із партнерами, продуктова функція концентрується на одному запитанні: який найшвидший шлях вивести ідею до реальних користувачів? У Claude Code це означає, що інженер або PM може запропонувати ідею, а вже до кінця тижня вона опиняється в руках розробників, які користуються продуктом.
Такий темп вимагає не лише технічної готовності, а й іншої ментальної моделі. Швидкість перестає бути винятком і стає очікуванням за замовчуванням. Відповідно, всі процеси, які не допомагають рухатися швидко, або спрощуються, або видаляються.
Дослідницький прев’ю як інструмент швидкості: чому Claude Code не чекає «ідеалу»
Один із головних механізмів, який дозволяє Anthropic рухатися так швидко, — системне використання формату research preview для нових можливостей Claude Code. Майже всі нові фічі спочатку виходять саме як дослідницький прев’ю, чітко промаркований у продукті.
Це не просто косметична етикетка. Research preview виконує одразу кілька стратегічних функцій.
По‑перше, він знижує рівень зобов’язань. Команда відкрито сигналізує: це рання версія, ідея, над якою ми експериментуємо, вона може змінитися або зникнути. Це дозволяє не чекати повного полірування, складних інтеграцій чи масштабних кампаній запуску. Функцію можна вивести за тиждень або два, подивитися на реальне використання, зібрати фідбек і вже потім вирішувати, у що інвестувати глибше.
По‑друге, research preview створює правильні очікування в користувачів. Замість того, щоб обіцяти «готовий до продакшену» інструмент, Anthropic запрошує до спільної роботи над продуктом. Користувачі розуміють, що їхній досвід і відгуки впливають на еволюцію функції, і це підвищує толерантність до недоліків на ранніх етапах.
По‑третє, такий формат дисциплінує команду. Якщо щось позначено як прев’ю, у нього має бути чітка гіпотеза: для кого це, яку проблему має вирішити, які сценарії «мають працювати з коробки». Це не хаотичні експерименти, а швидкі, але цілеспрямовані ітерації.
У результаті Claude Code отримує можливість постійно «дихати» новими ідеями, не перетворюючи кожен реліз на багатомісячний марафон узгоджень і полірування.
Evergreen launch room: як релізи стають майже автоматичними
Ще один ключовий елемент «машини релізів» Anthropic — це так звана evergreen launch room. Це не метафора, а реальний постійно діючий канал, у якому замикається ланцюжок «фіча готова → завтра про неї знає світ».
Процес виглядає так. Коли інженери вважають, що функція готова і пройшла внутрішнє «догфудинг»‑тестування, вони просто публікують її в цьому launch room. Далі запускається майже автоматичний механізм: команда документації, маркетингу продукту та деврелу підхоплює реліз і готує все необхідне — від описів до анонсів — буквально за один день.
Цей ритуал працює з кількох причин.
По‑перше, він радикально знижує тертя. Інженеру не потрібно окремо домовлятися з маркетингом, чекати слот у контент‑плані чи писати довгі пояснення. Достатньо одного посту в правильному місці. Усе інше — справа налагодженого процесу.
По‑друге, він робить кросфункціональну взаємодію передбачуваною. Маркетинг, документація, деврел знають, що від них очікується, які стандарти якості потрібні для прев’ю‑релізу, які формати матеріалів готувати. Це не разові «геройські зусилля», а повторюваний конвеєр.
По‑третє, він підсилює культуру особистої відповідальності. Якщо інженер вважає фічу готовою для evergreen launch room, це означає, що вона пройшла внутрішню перевірку і відповідає базовим принципам продукту. Немає окремого «комітету релізів», який би гальмував процес; є довіра до людей, які будують продукт.
У сукупності це перетворює запуск нових можливостей із великої події на щоденну рутину — але саме така рутина і створює враження «неймовірної швидкості», яке сьогодні приписують Anthropic.
Метричні ритуали й принципи замість мікроменеджменту
Швидкість без орієнтирів легко перетворюється на хаос. В Anthropic намагаються уникнути цього за рахунок двох взаємодоповнюючих інструментів: щотижневих метрик‑сесій і чітко сформульованих командних принципів.
Щотижневі readout‑зустрічі з усією командою Claude Code — це не просто перегляд дашбордів. Їхня мета — зробити так, щоб кожен член команди глибоко розумів, як працює бізнес: які ключові цілі, як вони змінюються з часом, що саме на них впливає. Це протиотрута від «марнославних релізів», коли фічі запускаються заради галочки або красивого списку оновлень.
Коли інженери, дизайнери, PM‑и й інші учасники процесу бачать повну картину, вони краще розуміють, які саме зміни в продукті мають сенс, а які — лише створюють шум. Це особливо важливо в AI‑середовищі, де моделі здатні робити дуже багато різних речей, і спокуса «запустити ще одну можливість» завжди велика.
Другий опорний елемент — письмовий список командних принципів. У ньому зафіксовано, хто є ключовими користувачами продукту, чому саме вони, які компроміси команда готова приймати заради їхнього досвіду. Це не абстрактні цінності, а практичний фреймворк для прийняття рішень під тиском часу.
Наявність таких принципів дозволяє людям діяти автономно. Інженер чи дизайнер може самостійно вирішити, чи варто запускати певну зміну, не чекаючи схвалення PM або інших стейкхолдерів. Вони знають, на що орієнтуватися: на конкретні типи користувачів, конкретні задачі, конкретні метрики.
У результаті швидкість не досягається за рахунок централізованого «форсування», а навпаки — завдяки децентралізації рішень, підкріпленій спільним розумінням цілей і правил гри.
Коли «важка» документація все ще потрібна: роль PRD у новій реальності
На тлі розмов про одноденні релізи може здатися, що класичні інструменти продуктового менеджменту — на кшталт PRD (product requirements document) — остаточно відійшли в минуле. В Anthropic це не так. Команда Claude Code свідомо зберігає PRD там, де вони справді додають цінність.
Йдеться насамперед про дві категорії робіт. Перша — особливо неоднозначні функції, де багато невідомих і потенційних сценаріїв використання. У таких випадках короткий, але структурований документ, який описує цілі, «делайтні» кейси, поточні режими відмови, допомагає уникнути розпорошення зусиль і непорозумінь.
Друга категорія — довготривалі інфраструктурні проєкти, які тривають місяцями й вимагають серйозних інвестицій. Тут легковажний підхід «запустимо за тиждень, а там подивимося» може обернутися великими втратами. Для таких ініціатив Anthropic продовжує використовувати повноцінні PRD, щоб зафіксувати очікування, залежності та критерії успіху.
Ключовий момент у тому, що «важка» документація застосовується вибірково. Вона не є обов’язковим бар’єром для кожної ідеї, а радше інструментом для ситуацій, де без додаткової ясності не обійтися. Усе інше намагаються проводити через легші формати — чіткі цілі, командні принципи, research preview та evergreen launch room.
Це ще один прояв загальної філософії Anthropic: процеси мають служити швидкості й якості, а не навпаки. Якщо певний артефакт не додає ясності або безпеки, він не повинен стояти на шляху до релізу.
Культура «прибрати всі бар’єри»: чому швидкість стає очікуванням за замовчуванням
У підсумку вся продуктова культура Anthropic зводиться до однієї простої, але вимогливої ідеї: прибрати кожен бар’єр на шляху від ідеї до користувача. Для Claude Code це означає, що окрема людина — інженер чи PM — може провести фічу від концепції до запуску менш ніж за тиждень.
Це не означає відсутності стандартів чи нехтування безпекою. Навпаки, саме завдяки чітким принципам, регулярним метрик‑сесіям і продуманим ритуалам на кшталт research preview та evergreen launch room команда може дозволити собі такий темп, не втрачаючи контроль.
Важливу роль тут відіграє і розподіл ролей у керівництві продукту. Борис Черні, як технічний лід і продуктовий візіонер Claude Code, задає горизонт на 3–6 місяців уперед, формулює «AGI‑пігулку» продукту — яким він має бути, коли моделі стануть ще потужнішими. Cat Wu фокусується на шляху від поточного стану до цієї візії, а також на тому, щоб маркетинг, продажі, фінанси, інфраструктурні команди були вирівняні й готові підтримати швидкі релізи.
У такій системі швидкість — не наслідок «чарівної моделі» чи надзусиль окремих людей, а результат цілеспрямованого дизайну організації. Моделі Anthropic, включно з потужним Mythos, безумовно, допомагають пришвидшити розробку, але всередині компанії визнають: основний драйвер зростання темпу — це процеси й очікування, а не самі по собі моделі.
Для інших AI‑команд у цьому підході є кілька уроків. Швидкість не виникає з нічого: її потрібно закладати в структуру роботи, у способи ухвалення рішень, у те, як організація ставиться до ризику й невизначеності. І, можливо, найважливіше — у готовність запускати продукти, які ще не ідеальні, але вже достатньо корисні, щоб навчити команду й модель чомусь новому.
Висновок: швидкість як дисципліна, а не хаос
Історія Claude Code — це не стільки про «шалену гонку релізів», скільки про дисципліновану побудову середовища, де швидкість стає природним станом. Скорочення циклів із шести місяців до одного дня стало можливим завдяки поєднанню кількох елементів: дослідницьких прев’ю, evergreen launch room, щотижневих метрик‑сесій, чітких командних принципів і вибіркового використання «важких» процесів на кшталт PRD.
Усе це працює лише тому, що в центрі залишається користувач і конкретні задачі, які мають «працювати з коробки». У світі, де код стає дедалі дешевшим, а моделі — дедалі потужнішими, справжньою перевагою стає не здатність написати ще більше коду, а вміння вирішити, що саме варто будувати — і як зробити так, щоб це опинилося в руках користувачів якомога швидше.
Для індустрії це сигнал: епоха піврічних релізних циклів для AI‑продуктів добігає кінця. На зміну їй приходить нова норма, де тиждень — це вже довго, а головним активом стає не процес заради процесу, а процес, підпорядкований швидкому, осмисленому руху вперед.