Що я бачу за цією цифрою
Мене в цій історії зачепила не сама цифра 74. Мене зачепив ритм. Якщо розбивка правильна, Anthropic за 52 дні випустив 28 релізів для Claude Code, 15 для Cowork, 18 для API та інфраструктури, плюс 13 для моделей і платформи.
Це не схоже на класичну схему з рідкісними великими релізами. Це схоже на конвеєр, де продукт, інфраструктура та агентні інструменти рухаються майже одночасно. І так, за такого темпу пів дня простою в Opus та Cowork — це вже не аномалія, а побічний ефект обраної швидкості.
Я окремо покопався в публічних матеріалах Anthropic. Там немає підтвердження моделі «кожен коміт у master одразу в прод». Зате дуже добре видно інше: вони будують розробку навколо агентних циклів, evaluation harnesses, програмного виклику інструментів (programmatic tool calling) та модульної архітектури інструментів.
Для мене це важлива різниця. Швидка доставка тут не про шалений CI/CD заради галочки. Вона про те, що сама AI-архітектура спроєктована так, щоб фічі можна було швидко збирати, перевіряти та відкочувати без тотального хаосу.
Де тут справжня інженерія, а не магія
Я б не романтизував цю історію. «74 релізи» звучить красиво, але ціна такого темпу завжди впирається в тестування. І ось тут починається найцікавіше.
У звичайному софті регресія й так дорога. В AI-продуктах все веселіше: змінюється модель, промпт, tool calling, контекстне вікно, поведінка агента на довгому завданні. Ти лагодиш одне, а в тебе раптово просідає сценарій, який ніхто руками не проганяв уже тиждень.
Anthropic, судячи з їхніх інженерних текстів, робить ставку не на «ідеальне ручне QA», а на програмні evals та цикли перевірки безпосередньо навколо агентної поведінки. Я цей підхід дуже добре розумію. Ми в Nahornyi AI Lab теж постійно впираємося в те, що для ШІ-автоматизації не можна жити лише чек-листами з класичного тестування.
Якщо агент працює з файлами, браузером, API та пам'яттю, то тестувати потрібно не тільки відповідь моделі, але й траєкторію виконання. Де він взяв інструмент. Чому пішов у цю гілку. Скільки токенів спалив. На якому кроці почав деградувати.
Що це змінює для бізнесу
Якщо дивитися очима бізнесу, виграють не найгучніші команди, а ті, хто вміє робити впровадження штучного інтелекту як інженерну систему. Не «підключили модель і сподіваємось», а вибудували спостережуваність, evals, rollback, feature flags та зрозумілі контури відповідальності.
Програватимуть ті, хто намагається зробити ШІ-автоматизацію «на коліні». Особливо в десктопній автоматизації та агентних workflow, де один дрібний баг може зламати цілий ланцюжок дій користувача.
Я б сформулював так: швидкість релізів сама по собі більше не перевага. Перевага в тому, щоб швидко релізити й швидко лагодити, не перетворюючи користувачів на безкоштовний QA-відділ. Rapid Delivery без Rapid Bug Fixing сьогодні вже не працює.
Звідси практичний висновок для команд, які будують ШІ-рішення для бізнесу. Потрібні не тільки сильні розробники, а й архітектура ШІ-рішень, де тестується поведінка агентів на реальних завданнях, а не лише happy path у демці для інвестора.
Я це бачу на проєктах постійно: щойно починається нормальна ШІ-інтеграція в процеси, спливають межові кейси, брудні дані, нестабільні інтерфейси та довгі сценарії. На слайді все гладко. У проді все відразу чесніше.
Мій висновок без романтики
Я не думаю, що всім потрібно бігти й випускати релізи щодня тільки тому, що це може Anthropic. Але я точно бачу, куди рухається ринок: до коротких циклів, автоматизованих evals та дуже жорсткої дисципліни навколо регресії.
Якщо у вас продукт з агентами, сценаріями на кшталт Claude Code або desktop automation, тягнути з дорослішанням процесів уже пізно. Потім це майже завжди оплачується простоями, ручними милицями та дорогою переробкою.
Цей розбір написав я, Вадим Нагорний, з Nahornyi AI Lab. Я займаюся ШІ-автоматизацією на практиці: проєктую AI-архітектуру, збираю агентні пайплайни й дивлюся, як усе це поводиться не в презентації, а в бою.
Якщо хочете обговорити ваш кейс, впровадження ШІ або розробку AI-системи під ваш процес, напишіть мені. Разом подивимося, де вам реально потрібна швидкість, а де спочатку треба зміцнити фундамент.