У розмові на Lenny’s Podcast засновник Zynga Марк Пінкус — людина, що стояла за FarmVille, Words with Friends і ще низкою масових хітів, — розбирає, чому класичний consumer social зайшов у глухий кут і де саме в епоху агентного AI ховається наступна велика можливість. Його погляд особливо цікавий тим, що Zynga свого часу побудувала одну з найефективніших у світі машин утримання користувачів і придумала власні глибинні метрики на кшталт ASN.

Пінкус описує нинішній стан соцмереж як втрату «адреналіну», пропонує дивитися на social як на «cocktail party», а на AI‑чат як на тиху, але перспективну кімнату, де цю вечірку ще тільки належить влаштувати. Паралельно він показує, як Zynga мислила не віральністю, а роковою утримуваністю користувача — і чому така оптика може стати ключем до нової хвилі consumer‑продуктів на базі агентів.

Соціальні мережі без адреналіну: коли «я не в Instagram» звучить як перемога

Пінкус починає з твердження, яке суперечить поверхневій картині: попит на «social» нікуди не зник. Навпаки, його, за його словами, «більше, ніж латентний». Люди продовжують користуватися Snapchat, Instagram, TikTok. Але сам досвід втратив відчуття драйву.

Він описує це через метафору калорій. Instagram‑скролл усе більше нагадує пачку чипсів: ти продовжуєш «їсти», але глибоко всередині це відчувається як порожні, а іноді й негативні калорії. Люди, які видаляють Instagram, часто говорять про це не як про жертву, а як про досягнення — «наче кинули палити». Пінкус наводить спостереження з вимірювань NPS: ті, хто відмовляються від Facebook чи Instagram, за його словами, зміщуються з позитивних оцінок у глибоко негативні, при цьому відчуваючи полегшення.

Звідси його висновок: не існує «загибелі соціальних мереж» як категорії. Існує виснажена, непродуктивна форма нинішнього social‑досвіду, яка забирає час значно більше, ніж віддає корисності чи емоційного заряду. Саме тому простір для перезапуску фундаментально нової соціальної моделі, на його думку, сьогодні величезний.

Social як cocktail party: що зробили правильно Facebook і LinkedIn

Щоб зрозуміти, куди рухатися далі, Пінкус пропонує повернутися до того, що зробили найперші успішні соцплатформи. Його улюблена метафора — cocktail party.

Він називає social‑досвід «соціальним явищем cocktail party»: ми інтуїтивно впізнаємо хорошу вечірку. Спочатку це може бути «обов’язковий» івент, але в якийсь момент ти ловиш себе на думці: «Я так радий, що я тут». На справді хорошій коктейльній вечірці ти не просто проводиш час — ти отримуєш «ліди»: нові знайомства, можливості, ідеї, корисні контакти.

Саме через цю призму він дивиться на ранні соцмережі:

• Friendster став першим місцем, де «лідом» міг бути реальний дейт.
• Facebook і LinkedIn дали вибухову «соціальну продуктивність»: можливість бути в курсі сотень і тисяч людей і водночас отримувати кращі «ліди» — від особистих знайомств до робочих контактів.

Це і є ключ: соцмережі росли не тому, що вони були «залипальними», а тому, що давали кращу віддачу на витрачені хвилини — більше цінних контактів, кращі результати пошуку роботи чи партнерів, менше «шуму» порівняно з тим самим Google чи Craigslist.

Проблема, як вважає Пінкус, у тому, що багато платформ згодом зрушили фокус із продуктивності на чисту залученість і рекламу. Instagram захворів на «TikTok‑заздрість» і став більше схожим на нескінченну стрічку для прокрастинації, ніж на інструмент для підтримки відносин. Це як коктейльна вечірка, де музика стала гучнішою, але цікаві розмови кудись зникли.

Тихий AI‑коктейль: чому Claude і GPT поки що самотні

Далі Пінкус переносить цю ж метафору на епоху AI. Сьогодні, каже він, «ми всі тусимо в Claude чи GPT, але там немає cocktail party». Це величезна нова кімната — але в ній тихо.

Люди проводять усе більше часу в AI‑чатах, проте цей час — радше індивідуальний, аніж соціальний. Немає відчуття вечірки, немає гулу розмов, немає відчуття «я радий, що я тут із цими людьми». Є потужний інструмент, який відповідає на запитання, пише код, допомагає думати, але не вбудований соціальний досвід.

Сам Пінкус формулює виклик так: «Сьогодні ми всі тусимо в Claude чи GPT, але там немає cocktail party… мій челендж — зробити цю вечірку галасливою». Йдеться про завдання для засновників і продактів: перетворити чат‑інтерфейс із тихої кімнати самотньої роботи на соціальний простір, де:

• відбувається обмін «лідами» — не лише інформацією, а й людьми, можливостями, контактами;
• з’являється відчуття присутності інших;
• користувач отримує не тільки корисну відповідь від моделі, а й соціальну віддачу — нові зв’язки, посилену репутацію, спільні дії.

Пінкус прямо говорить, що «вірить, що хтось перевинайде social‑досвід для agentic AI‑ери». На його думку, наші агенти мають навчитися давати нам «ще більше бути в курсі», але при цьому не красти час, а навпаки — повертати продуктивність, яку колись давали ранні Facebook і LinkedIn.

Уроки Zynga: чому вирішальне не віральність, а день 365

Коли Пінкус говорить про майбутній social, він спирається не лише на інтуїцію. У Zynga команда вибудувала одну з найрадикальніших систем вимірювання утримання.

Перше, що він підкреслює: Zynga перемагала конкурентів не «спамністю» чи віральними трюками. У компанії, за його словами, були «масові конкуренти і копіювальники», але саме Zynga знову і знову брала верх. Причина — фокус на довгостроковій ретеншн‑механіці.

Пінкус стверджує, що Zynga, можливо, була єдиною consumer‑компанією у світі, яка системно трекала day‑365 retention. Для більшості продуктів усе закінчується на day‑30: якщо D30 високий, це сприймається як успіх. Але Пінкус звертає увагу на небезпечний патерн: «у більшості продуктів D30 може бути високим, а D365 — нуль».

Це змінює постановку задачі:

• Якщо не думати, «чому людина буде тут через рік», продукт інстинктивно будується навколо миттєвої залученості.
• Користувачі самі, за його спостереженнями, внутрішньо оцінюють, чи варто «інвестуватися» в новий сервіс: чи будуть вони користуватися ним через рік, чи варто віддавати йому дані, запрошувати друзів.

Так народжується принцип: справді цінні компанії — це ті, у кого найвища day‑365 retention. Це не означає, що можна чекати рік, щоб щось зрозуміти. Потрібні ранні предиктори, але мислення має бути саме «річним», а не «30‑денним».

ASN: як Zynga рахувала справжні соціальні зв’язки

Другий ключовий інструмент Zynga — метрика ASN (Active Social Network), яку Пінкус називає своєрідним «пасхальним яйцем» для фаундерів.

Суть проста, але радикальна. Замість просто рахувати DAU чи кількість друзів, Zynga вимірювала, скільки у гравця реальних взаємних соціальних зв’язків у грі. Для цього команда дивилася на «кругові маршрути» з іншими людьми:

• ти зробив хід — інший гравець відповів;
• ти надіслав подарунок — тобі надіслали подарунок у відповідь.

Кожен такий взаємний цикл збільшував ASN. Далі виявилися жорсткі кореляції:

• Якщо користувач переходив із 0 ASN до 1, існувала «80% ймовірність побачити його знову наступного місяця».
• Якщо він доходив до ASN=4, була «80% ймовірність бачити його 22 з наступних 30 днів».

Тобто не «віральність» як така, а саме глибина взаємних соціальних зв’язків була найсильнішим індикатором того, що людина залишиться надовго.

Цю логіку можна безпосередньо перенести на agentic‑соціальні продукти:

• важливо не лише, скільки сесій із агентом або чат‑ботом має користувач,
• а й скільки взаємних циклів він отримує з іншими людьми через цього агента: спільні задачі, відповіді, референси, передані один одному «ліди».

Пінкус описує це як створення «позитивних зворотних зв’язків», коли ти відчуваєш: те, що ти робиш у продукті, хтось бачить, хтось оцінює, хтось відповідає.

Агентний соціум: коли AI стає вашим соціальним брокером

Далі Пінкус переходить до бачення того, як agentic AI може перезапустити social‑досвід. Його інтуїція: у центрі наступного великого споживчого продукту стоятиме агент, який одночасно:

• знає ваш контекст,
• знає контекст інших людей,
• виступає «інтелектуальною мембраною довіри» між вами.

Він називає це «соціальною мембраною»: розумний шар між двома людьми, який знає більше, ніж показує кожній стороні, і динамічно регулює:

• скільки інформації передати,
• скільки уваги запросити,
• як організувати взаємодію так, щоб вона не шкодила, а допомагала.

Приклад із буденності: ви хочете зустрітися з другом на вихідних. Але в кожного свій реальний рівень бажання, навантаження, сімейні плани. Агент може:

• знати ці контексти,
• не розкривати їх повністю одне одному,
• знайти формат зустрічі, який буде комфортним обом,
• не створювати відчуття провини чи соціального тиску.

Пінкус прямо говорить, що бачить у цьому «нову соціальну продуктивність»: агенти можуть зменшити тертя у взаємодіях, допомогти нам частіше бачитися з людьми, із якими ми справді хочемо підтримувати зв’язок, при цьому не перетворюючи це на нескінченні нотифікації й календарні конфлікти.

Усе це, на його думку, і є та сама нова версія cocktail party для AI‑ери: галаслива, але керована; соціальна, але продуктивна.

Агентний тревел‑агент: перший масовий кейс agentic‑social?

Своє бачення того, де може народитися перший великий agentic‑сервіс, Пінкус ілюструє через конкретний сценарій: travel‑агента.

Він упевнений, що попит на подібну послугу завжди був величезним. «Я думаю, має з’явитися agentic‑travel‑агент… 24/7 безкоштовний travel‑агент для кожного, який знає контекст і перебронює ваші перельоти в реальному часі», — каже він.

Ключові елементи цього бачення:

• Агент знає ваші звички, переваги, історію подорожей.
• Він не просто бронює, а супроводжує поїздку в режимі реального часу:
• стежить за затримками рейсів,
• переброньовує альтернативи,
• розрулює логістику, коли щось ламається.
• Послуга — практично безкоштовна для користувача, але економічно можлива завдяки тому, що «токени дешевшають» і AI‑потужності стають все більш доступними.

Пінкус переконаний, що такий сервіс «цінний для всіх, але недоступний для всіх» у старій економіці: живі тревел‑агенти не могли заробити достатньо комісій, а люди не готові були платити за них стільки, скільки це коштує. AI знімає це обмеження.

Однак сьогодні, каже він, якщо хтось «зробить найкращого travel‑агента, можливо, ми про нього дізнаємося, але це важка дорога». Дистрибуція в мобільних сторах давно «зламана» для consumer‑софтверу: інсталяції практично не ростуть, нові хіти пробитися не можуть.

Тому Пінкус робить ще один крок у своєму аргументі: якби подібний travel‑агент був «глибоко вшитий в OpenAI чи Claude», він міг би:

• стати реальним драйвером цінності для широкого кола користувачів конкретної моделі;
• водночас служити новим «поверхом» платформи — місцем, де вже хтось інший може будувати додатковий досвід.

Фактично він пропонує LLM‑платформам задуматися над власними «killer apps» рівня consumer‑сервісу, які були б немислимі без тісної інтеграції з їхнім стеком. Тревел‑агент — лише один із можливих прикладів; Пінкус говорить, що бачить «багато consumer‑орієнтованих agentic‑сервісів», які «мають сенс», але не злетять, якщо залишаться просто ще однією іконкою в App Store.

Чому наступний великий social виросте на перетині агентів і дистрибуції

Пінкус досить тверезо оцінює сьогоднішню ситуацію з платформами. Він не вважає, що AI‑чати вже стали повноцінним «новим платформним шаром» на кшталт мобайлу чи Windows:

• немає усталеного способу дистриб’ювати сторонні програми поверх LLM;
• немає очевидного каналу «відкриття» нових агентів, сервісів чи «міні‑додатків» усередині цього середовища.

Попри це, він упевнений, що гонка між великими LLM‑гравцями неминуче виведе їх до потреби в consumer‑цінності, яка буде зрозумілою нефахівцям. Зараз вони диференціюються переважно за якістю кодування, але на горизонті, який окреслює Пінкус, вирішальним стане:

• наскільки глибоко вбудовані в платформу конкретні агентні сервіси;
• як добре вони перетворюють AI‑чат на «galaslyvu вечірку» — з лід‑геном, зв’язками, соціальною продуктивністю.

Саме на цьому перетині — agentic‑досвіду, що реально економить час і нерви, і нових каналів дистрибуції поверх LLM — Пінкус бачить простір для наступних «інтернет‑скайскрейперів», які «важко буде уявити життя без».

Висновок: cocktail party ще не почалася

Якщо звести його міркування до одного твердження, воно звучатиме так: social не помер, він просто потребує нової сцени. Ера Instagram як центрального місця «вечірки» добігає кінця — але сама метафора cocktail party нікуди не зникає.

AI‑чати сьогодні — це величезні, ще порожні кімнати. У них уже є мільйони людей, але немає гулу голосів, немає соціальної енергії, немає чіткого відчуття корисності контактів. Марк Пінкус пропонує дивитися на цей простір як на шанс:

• використати уроки Zynga — day‑365 retention і ASN, глибину взаємних зв’язків;
• побудувати агентів, які стануть нашими особистими брокерами у світі людей, а не лише інформації;
• зробити так, щоб час онлайн знову відчувався як «позитивні калорії».

«Зробіть цю вечірку галасливою», — кидає він виклик засновникам. У світі, де дедалі більше людей гордо говорять «я не в Instagram», це завдання звучить не як ще одна модна ідея — а як реальна порожня ніша, яку хтось неминуче заповнить.

Джерело

The hidden pattern behind successful products | Mark Pincus (FarmVille, Words with Friends, & more)

На конференції Craft у Будапешті автор блогу The Pragmatic Engineer Герґей Орош розбирав, як великі компанії перебудовують розробку під AI. В одній з найцікавіших частин виступу він спирався на спостереження Лари Тачо, колишньої CPO в DX і нині керівниці напрямку developer experience в AWS, а також на приклад Spotify. Їхній досвід показує: ставка лише на «прискорення окремих девів» дає враження прогресу, але майже не змінює командний результат. Реальні зрушення приходять тоді, коли AI вбудовують у командні процеси як «агентні системи» з чіткою бізнес-метою.

Коли все виглядає швидшим, а команда — ні

Лара Тачо спостерігає однакову картину в багатьох компаніях: окремі розробники демонструють вражаючу продуктивність, але загальний вихід команди не росте. Організації «застрягають» у стані, де люди індивідуально користуються AI, але системний ефект майже не з’являється.

Причину вона формулює доволі жорстко: більшість думає про AI як про індивідуальний інструмент продуктивності для інженера, а не як про частину командної системи. Вона навіть дає цьому назву — «individual speed‑up juice». До цього класу вона відносить:

– автоматичні підсумки email
– дрібні автоматизації у Slack
– генерацію коду для конкретних задач

На папері все виглядає чудово: кожен дев швидше відповідає на листи, менше клацає в месенджері, за хвилини отримує скелет для нового модуля. Але на рівні команди зникають вузькі місця? Прискорюються релізи? Меншає переробок? Часто – ні.

Фактично виникає ілюзія прогресу: індивідуальні дії стають помітно швидшими, та без змін у потоці роботи команди це лише підсилює локальні оптимізації. Ланцюжок розробки й деплою, повний «хенд-офів», блокерів і пошуку інформації у хаотичних системах, від цього не стає кращим.

Компанії, які рухаються швидше, починають з бізнес-мети

Ті, хто дійсно бачить зміни на рівні команд, працюють інакше. Орош переповідає логіку, яку Тачо бачить у таких організаціях: вони починають не з «які AI‑фічі дати девам», а з конкретного бізнес-результату.

Типові формулювання виглядають так:

– «Ми хочемо швидше деплоїти в продакшен»
– «Ми хочемо виштовхувати більше фіч за той самий час, не втрачаючи якість»
– «Ми хочемо підняти якість продукту»

Саме від цього потім відмотують назад: які частини процесу гальмують ці результати, де найбільше ручних передач між людьми, де існує найбільше тертя у пошуку інформації, як саме AI може змінити саму систему, а не лише окремі кроки.

У цій моделі AI — не «тул для девів», а будівельний матеріал для нового процесу розробки. Він має скорочувати кількість хенд-офів, прибирати повторювані дії, робити знання в організації доступнішими в потрібний момент. І все це — під задану бізнес-мету, а не під абстрактну «продуктивність».

Spotify: «якість не має падати» як політика використання AI

На противагу агресивним підходам, Орош наводить Spotify як приклад компанії, що свідомо обрала консервативну стратегію впровадження AI. Під час неформальної розмови CTO Spotify сформулював їхній внутрішній бар’єр досить просто: якість має залишатися на тому ж рівні.

Це означає кілька речей.

По-перше, Spotify не женеться за миттєвим «стрибком продуктивності». За словами Ороша, там не бачать «величезного приросту аутпуту» від AI. Натомість вкладаються у внутрішні інструменти, які перевіряють якість результатів AI, і свідомо сповільнюють розгортання нових AI‑рішень.

По-друге, для Spotify прийнятність AI‑інтеграцій прямо прив’язана до контролю якості. Якщо неможливо гарантувати, що рівень якості не просяде, — AI‑ініціативу притримують, незалежно від обіцянок про економію часу чи коштів.

На фоні прикладів, де AI‑код, перевірений AI‑рев’ю, уже приводив до інцидентів, така позиція виглядає принциповим вибором. Це не історія про «максимізацію використання AI», а радше про те, що AI вбудовують у систему з чітко заданим обмеженням: не гірше, ніж зараз.

Цікаво, що Spotify при цьому все одно будує власні внутрішні інструменти навколо AI. Але ціль цих інструментів — не просто пришвидшити написання коду, а гарантувати, що кінцевий продукт не просідає за якістю. Виходить повільніше, але без «AI‑похмілля» у вигляді великої кількості латентних багів.

Що таке «агентна система» у розумінні Лари Тачо

Ключова відмінність підходу, який описує Тачо, – у тому, що AI розглядається як частина цілісної «агентної системи», а не як сукупність маленьких скриптів і автозавдань.

У її формулюванні бажана система:

– зменшує кількість хенд-офів між людьми
– робить пошук інформації простішим і швидшим
– прибирає тертя у повсякденних процесах
– при цьому зберігає існуючий рівень якості або піднімає його

«Підтримання якості» вона окремо виділяє як рідкісну рису: небагато компаній на практиці ставлять це як обов’язкову умову для AI‑ініціатив, навіть якщо декларують у стратегіях.

Агентна система в такому розумінні — це не просто «розумний бот», а низка узгоджених агентів і сервісів, вшитих у внутрішню інфраструктуру: від трекера задач до CI/CD, тестів, документації й репозиторіїв. Саме вони беруть на себе значну частину «сервісної» роботи, що раніше вимагала ручних передач між ролями.

Наприклад, замість того щоб дев вручну передавав контекст від QA до продакт-менеджера, система може автоматично збирати релевантні логи, документацію, тестові результати й формувати зрозумілу картину проблеми. Умовно той самий дев усе ще пише код, але набагато менше часу витрачає на «логістику» інформації.

Це не те саме, що «корисний чатбот у Slack» — останній зазвичай живе окремим шаром, до якого звертаються епізодично. Агентна система змінює самі потоки роботи.

Ментальна модель: від «автоматизацій для людей» до «агентів для команд»

Тачо пропонує ментальну карту, яку Орош переказує так: вона розділяє використання AI за двома осями. Перша — де відбувається застосування: на рівні індивідуального інженера чи на рівні команди. Друга — тип рішення: проста автоматизація чи повноцінна агентна система.

У цій координатній площині більшість компаній сьогодні опиняється в «нижньому лівому куті»: індивідуальне використання AI для простих автоматизацій. Тобто, умовно:

– кожен дев має свій автодописувач коду
– хтось налаштував собі автосамарі для листів
– хтось додав невеликий бот у Slack для дрібних задач

Це корисно й часто справді підвищує комфорт роботи. Але до квадранта, де є командні агентні системи, ще дуже далеко.

Саме туди «хочуть потрапити» більшість організацій: побудувати системи, в яких AI‑агенти взаємодіють із внутрішніми сервісами, керують частинами потоку задач, агрегують інформацію для всієї команди, автоматично зменшуючи кількість зайвих дій і затримок.

Однак дійти до цієї точки, за словами Ороша, вимагає того, що вже роблять гравці рівня Uber: значного інвестиційного циклу в інфраструктуру, інтеграцій та ітерацій. Неможливо просто «купити готовий продукт», навіть якщо це потужний AI‑редактор коду чи хмарний агент. Їх доводиться вбудовувати в унікальні процеси компанії.

Це означає:

– виділені платформи‑команди, які будують шлюзи й рантайми для агентів
– поступове підключення внутрішніх сервісів і систем до єдиної AI‑шини
– розробку власних критеріїв прийняття AI‑функцій у продакшен з огляду на якість

Тобто перехід від «джусу швидкості» для окремих людей до командних агентних систем — це не питання ще одного підписаного контракту з постачальником AI, а питання багаторічної еволюції внутрішньої платформи розробки.

Чому фокус на системі, а не на індивіді, стає критичним

На фоні історій про інциденти, пов’язані з AI‑кодом, і загального падіння якості софту, теза «застосовувати AI до системи, а не до індивіда» звучить не як теоретична порада, а як умова виживання.

Орош підкреслює: сьогодні більшість гравців застрягла саме на рівні індивідуальних автоматизацій. Саме тому не спостерігається драматичного приросту командної продуктивності, попри те, що окремі деви часто можуть показувати вражаючу швидкість. Без переосмислення процесів та чітко визначених бізнес-цілей AI залишається «турбо‑надбудовою» над старою системою, але не створює нову.

Водночас приклади на кшталт Spotify демонструють: можлива й інша траєкторія. Замість гонитви за максимальним використанням AI — жорсткий бар’єр якості й повільне будівництво внутрішніх інструментів, які не розвалюють існуючий рівень надійності. А досвід, описаний Ларою Тачо, показує ще один важливий зсув: від «ми дамо девам більше інструментів» до «ми змінимо спосіб, яким команда досягає бізнес-результату».

У підсумку «індивідуальний джус швидкості» — це швидкий, але обмежений виграш. Справжній, системний профіт від AI з’являється там, де компанії готові вкладатися в агентні системи на рівні команд, виходячи з чітких бізнес-мет і зберігаючи (або навіть піднімаючи) якість, а не жертвуючи нею заради короткострокового прискорення.

Джерело

Slow down to speed up: AI and software engineering — The Pragmatic Engineer

Американський підприємець і консультант з AI‑систем Остін Марчезе, який будував продукти на базі Claude Code в реальному бізнесі, пропонує нетиповий погляд на те, як варто створювати Claude Skills. Замість того, щоб вигадувати абстрактні «універсальні» навички наперед, він вибудовує філософію, де кожен skill народжується з живої розмови і конкретного виконаного завдання, а потім еволюціонує завдяки спеціальній секції gotchas.

Ця логіка змінює підхід до Skills із «бібліотеки шаблонів» на систему живих, самовдосконалюваних процесів.

Що таке Claude Skill насправді

Марчезе пропонує максимально приземлене визначення: Claude‑skill — це не «магічний модуль» і не складна інтеграція, а по суті структурована папка з інструкціями.

За його формулюванням, це «папка з інструкціями, яку Claude може викликати автоматично». Найзручніша метафора — набір чітких покрокових вказівок, які дозволяють Claude щоразу виконувати одну й ту саму роботу однаково, без додаткових пояснень.

Фокус тут не стільки на технічній реалізації, скільки на стандартизації поведінки моделі. Skill фіксує один спосіб роботи так, щоб Claude не витрачав кожен новий запуск на «вигадування» стратегії з нуля. В результаті одна і та сама задача перестає бути «креативною сесією» і перетворюється на відтворюваний процес.

Помилка за замовчуванням: будувати skills «зі стелі»

Попри очевидну корисність Skills, більшість користувачів, за спостереженням Марчезе, заходять у них із хибної точки. Вони спершу «сідають подумати», якими мали б бути їхні ідеальні навички.

Типовий внутрішній діалог виглядає так: «Який skill мені варто створити?» Далі зазвичай один із двох сценаріїв. Або людина нічого так і не робить, бо не може виокремити справді вартий уваги кейс. Або створює навичку, яку потім майже не використовує.

Саме тому, підкреслює Марчезе, «ніколи не варто будувати skills абстрактно». У такому підході занадто багато припущень і замало перевірених кейсів. Навичка виходить відірваною від реального процесу: немає підтвердження, що саме так ви насправді працюєте, що такий формат результату вам потрібен, і що ця послідовність дій взагалі приносить цінність.

Це створює ілюзію організованості — ніби система налаштована, — але фактично Skills перетворюються на «мертвий капітал»: щось одного разу збудоване, але не інтегроване в живу роботу.

Фраза, яка змушує Skill народитися з реальної роботи

Альтернатива, яку пропонує Марчезе, звучить у вигляді конкретної power‑phrase: «Based on this conversation, build me a skill.»

Ця фраза, на його думку, радикально змінює місце, з якого стартує створення навички. Замість абстрактного «що варто зробити?» точкою відліку стає вже виконаний процес. Ви щойно з Claude пройшли певну задачу: розібрали вимоги, відполірували текст, зібрали spec, прогнали перевірки. Коли після цього лунає «Based on this conversation, build me a skill», Claude просто пакує вже відпрацьований сценарій у повторюваний формат.

Звідси ключова перевага: «use case уже валідований, бо ви буквально щойно зробили цю роботу вручну». Немає ризику вигадати штучний сценарій, який так і не приживеться. Skill з’являється лише там, де факт повторюваності й корисності підтверджений самою практикою: ви це вже робили, це вже спрацювало, і є сенс зробити це відтворюваним.

У такій моделі Claude виступає не стільки архітектором системи, скільки пакувальником: він бере ланцюжок кроків, який уже виявився працездатним для вас, і фіксує його так, щоб наступного разу це не вимагало стільки ручної участі.

Як «gotchas» перетворюють Skills на систему, що накопичує досвід

На цьому етапі, за словами Марчезе, виникає наступний рівень. Навіть якщо перша версія skill створена з реального діалогу, «вона не буде ідеальною». У процесі використання спливатимуть дрібні проблеми — те, що він називає gotchas.

До цього підходу його підштовхнула внутрішня практика Anthropic. Компанія, яка створює Claude, нещодавно оприлюднила матеріал про те, як використовує skills у себе. Головний висновок, який Марчезе виділяє з цієї публікації: «найкраще, що ви можете зробити зі skills, — додати до них секцію gotchas.»

Gotchas — це не загальні зауваження й не ще один список інструкцій. Це саме ті дрібні моменти, які реально заважають у щоденній роботі: крайові випадки, стилістичні особливості, будь‑які деталі, через які вам доводилося кілька разів уточнювати завдання, щоб отримати правильний результат.

Ці речі поверхнево здаються незначними. Але саме вони створюють відчуття «цей AI мене не чує» — коли начебто все правильно, але «не зовсім так», і кожен запуск вимагає ручного втручання.

Марчезе пропонує перетворити ці проблеми на паливо для поліпшення навички. Кожного разу, коли щось пішло не так або знадобились додаткові пояснення, це не просто разова помилка, а новий пункт у gotchas. Claude можна прямо попросити: «Based on this conversation, enhance any skill I use to include a gotchas section so we don’t make this mistake again.»

У такій конфігурації Skill стає динамічним: кожен збій, кожен «не той тон», кожен неправильний кут аналізу додається до колективної пам’яті процесу. Чим швидше ви ідентифікуєте ці gotchas і вбудуєте їх до навички, тим швидше зростає її якість. Марчезе називає це стисканням feedback‑loop’а — саме воно змушує skills «компаундувати», тобто накопичувати ефект від використання.

Замість «який skill створити?» — «чи варто цей процес робити skill’ом?»

У фіналі Марчезе формулює, ймовірно, головний зсув мислення, який випливає з цього підходу. Базове питання, яке звикли ставити собі користувачі Claude, звучить: «Який skill мені створити?» Він пропонує повністю від нього відмовитися.

Натомість питання має бути іншим: «Чи варто перетворити цей процес на skill?» Тобто не шукати навички в теорії, а знаходити їх у реальних повторюваних задачах.

Це повертає нас до його головного принципу: «Concrete beats abstract every time.» Конкретний процес, який ви щойно пройшли від початку до кінця й залишилися ним задоволені, — набагато краща сировина для skill, ніж будь‑яка стратегічна «мапа ідей», складена наперед.

У такій моделі життєвий цикл навички виглядає спрощено, але показово. Спочатку ви виконуєте роботу вручну разом із Claude. Потім запускаєте фразу «Based on this conversation, build me a skill» і отримуєте першу версію процесу, пакованого в інструкції. Далі щоразу, коли щось іде не так, фіксуєте це в gotchas, посилюючи навичку. Чим частіше процес повторюється, тим стабільнішим і точнішим стає skill — без абстрактного планування й без потреби проектувати всю систему наперед.

Висновок: Skills як «жива документація» ваших процесів

Підхід, який описує Остін Марчезе, розвертає роботу зі Skills у Claude у бік практичного, процесного мислення. Skills більше не виглядають як окремий рівень «просунутості», доступний лише тим, хто любить проєктувати складні системи.

У цій логіці skill — це просто спосіб зберегти вдалу розмову з Claude у вигляді відтворюваного процесу, а gotchas — механізм, який змушує цей процес розумнішати від кожної помилки. Коли центральним питанням стає не «що б ще автоматизувати», а «чи цей конкретний процес достатньо стабільний і повторюваний, щоб його зафіксувати», Claude Skills перетворюються на своєрідну живу документацію вашої роботи.

І саме в такому вигляді вони мають шанс стати системним активом, а не черговою колекцією «фіч, які ми одного разу налаштували й забули».

Джерело

YouTube: Type This Into Claude, It’ll Make You Build 10x Faster.

У своїх останніх розбірках про Claude Code підприємець та консультант з AI‑систем Остін Марчезе показує один простий, але нетиповий прийом: замість вигадувати «ідеальний промпт», варто попросити Claude… проінтерв’ювати вас. Ця зміна ролей перетворює сесію з AI з чергової спроби «вгадати правильну формулювання» на структуроване спільне мислення над продуктом чи автоматизацією.

Йдеться не про ще один шаблон промпта, а про спосіб витягнути з засновника або розробника бізнес‑контекст, цілі та ключові рішення, які зазвичай так і лишаються в голові — і через це ламають проєкти вже на етапі реалізації.

Проблема «я знаю, що хочу, але не знаю як»

Марчезе описує типову ситуацію: людина «знає, що хоче побудувати на високому рівні», але не розуміє деталей, які насправді роблять або ламають проєкт. Claude може написати красивий документ, створити план чи навіть одразу перейти до коду, але якщо початкова картина нечітка, результат буде таким самим.

Він підкреслює, що слабкі результати Claude майже завжди впираються не в якість моделі, а в «thinking problem» — проблему мислення. Модель чесно намагається будувати з того, що їй дали, але якщо вихідні рішення про продукт, аудиторію, обмеження чи критерії якості не були сформульовані, жоден «чарівний промпт» цього не виправить.

Класичний сценарій: користувач просить Claude «написати спека» чи «спроєктувати систему», отримує складний документ і раптом розуміє, що сам не може сказати, це добре чи погано. Спек виглядає розумно, але не прив’язаний до реальних бізнес‑цілей, користувача або контексту. Саме на цій тріщині зазвичай починають сипатися дедлайни, бюджети й очікування.

Як працює «Interview me»: Claude змінює ролі

Третя з ключових фраз, на якій зупиняється Марчезе, звучить просто: «Interview me». Її сенс — радикально поміняти напрямок інформаційного потоку.

Замість того, щоб людина намагалася запхнути в один промпт «достатньо контексту», щоб Claude написав «ідеальний спека з нуля», модель «перевертає тумблер» і сама починає ставити запитання. Вона уточнює те, що користувач навіть не підозрював, що варто уточнити.

У цьому режимі Claude:

• не приймає туманне формулювання як даність, а розкручує його питаннями;
• витягує деталі про продукт, процес чи автоматизацію, які користувач знає інтуїтивно, але ніколи не формулював;
• допомагає виявити точки, де людина взагалі не думала, що потрібно ухвалювати якесь рішення.

Марчезе зауважує, що вже через кілька хвилин такого «інтерв’ю» люди часто ловлять себе на думці: «Я ніколи про це не задумувався». Саме в ці моменти й виявляються критичні параметри майбутньої системи — від того, для кого вона створюється, до того, які сценарії потрібно явно відсікти.

Цей режим, за його словами, здатен заощадити години, які зазвичай витрачаються на побудову «не того» продукту, а потім — на переробку.

Фокус на проблемі й аудиторії: чому це не дрібниця

Один з ключових елементів промпта для «Interview me» Марчезе формулює так: «працюй зі мною, щоб визначити основну проблему, яку ми вирішуємо, і хто є і не є нашою аудиторією. Я не можу переоцінити, наскільки це важливо».

Йдеться не лише про поверхневий опис цільової групи, а саме про подвійне визначення: для кого будується рішення — і для кого воно свідомо не будується. Саме це, на його думку, радикально впливає на кінцевий продукт.

Як приклад він наводить Anthropic, творця Claude. Однією з причин швидкого зростання компанії Марчезе називає те, що на початкових етапах у неї був дуже чіткий фокус на тому, для кого вони будують, а для кого — ні. В їхньому випадку стартовою аудиторією стали розробники.

Ця рамка, стверджує він, визначає все: і які сценарії AI оптимізує, і які функції вважаються базовими, і які компроміси приймаються. Якщо спроєктувати продукт «для всіх», він неминуче розмивається. Якщо ж разом із Claude у режимі «Interview me» ретельно пройтися тим, хто точно не є цільовим користувачем, це допомагає відрізати цілі класи фіч і вимог, що лише ускладнюють систему.

Claude в такій сесії не просто запитує «хто ваша аудиторія», а повертає цю тему знову й знову через призму ключових рішень: як це впливає на формат інтерфейсу, мову, рівень технічної складності, припустимий ризик, необхідний рівень підтримки тощо. Так через діалог формується ясна рамка, в якій уже має сенс будувати технічний спека.

Від інтерв’ю до спека за п’ять хвилин

Ключовий фінальний крок у цій схемі Марчезе формулює як третій елемент промпта: «підсумуй це як implementation spec». Після того, як Claude за допомогою запитань «витягнув» з користувача контекст, цілі, аудиторію і низку ключових рішень, модель переходить у режим структурування.

На виході з’являється документ, який уже не виглядає як «генерація з повітря». Це спека, зібрана з відповідей людини, але оформлена в технічну форму:

• з чітким формулюванням проблеми;
• із зазначенням, для кого будується рішення і для кого ні;
• з окресленими рішеннями по ключових кроках;
• із зрозумілими для подальшої реалізації деталями.

Марчезе підкреслює, що саме зв’язка «Interview me → summarize as implementation spec» дозволяє «перейти від порожньої сторінки до повного спека менш ніж за п’ять хвилин». Порожня сторінка в цьому підході не лякає, тому що її заповнення відбувається не через спробу одноразово «вигадати ідеальний опис», а через низку питань, на які простіше відповідати по одному.

Так утворюється міст між інтуїтивним розумінням засновника чи продакт‑менеджера і формальним документом, з яким Claude (або команда) вже може працювати в режимі побудови.

Пастка «Interview me»: чому просто клацати «так/ні» марно

Попри очевидну привабливість режиму, Марчезе попереджає: «Interview me» працює тільки в тому випадку, якщо людина справді думає, перш ніж відповісти. Якщо користувач просто «проклікує» запитання, відповідаючи «так» чи «ні», цінність процесу втрачається — у такому разі, як він зауважує, можна взагалі дозволити Claude самому вигадувати відповіді.

Це не той сценарій, де модель «сама все зробить краще». Суть прийому саме в тому, щоб сповільнити мислення людини щодо ключових рішень:

• зупинитися на кожному запитанні;
• додати контекст, чому рішення саме таке;
• визнати, де відповіді немає, і свідомо делегувати Claude «use your best judgment».

Цікава деталь: Марчезе радить використовувати голосові інструменти, щоб відповідати на питання в «Interview me» як у живому інтерв’ю. На його думку, це змушує давати більш розгорнуті, осмислені відповіді і робить процес менш схожим на заповнення форми.

У результаті замість сухого чекліста виходить розмова, в якій прояснюються мотивації, обмеження, побоювання та припущення — те, що рідко потрапляє в перший варіант технічного документа, але потім боляче відгукується на етапі реалізації.

Чому це про мислення, а не про промпти

Червоною ниткою через увесь розбір у Марчезе проходить одна теза: коли вивід Claude «не дуже», проблема зазвичай не в моделі, а в мисленні. «Interview me» — спроба обійти спокусу ставитися до AI як до «чорної скриньки, яка все вирішить сама», і натомість використати його як інструмент для структурованого мислення.

У такому режимі Claude не підміняє продакт‑роботу, а підсилює її. Він не «вгадує за вас», що ви хочете побудувати, а методично змушує це назвати. Саме тому цей підхід добре стикується з подальшими етапами — розробкою implementation spec і вже потім побудовою — але не замінює їх.

У підсумку «Interview me» можна розглядати як спосіб поставити правильні запитання тоді, коли їх ще не сформульовано. І якщо вірити практиці Марчезе, це часто виявляється важливішим, ніж будь‑який новий режим, плагін чи чергова «просунута техніка промптингу».

Джерело

YouTube — Type This Into Claude, It’ll Make You Build 10x Faster.

Американський підприємeць і розробник Остін Марчезе, колишній COO технологічного стартапу з виручкою понад $25 млн і нині засновник BuildPartner.ai, системно розбирає, як працювати з Claude Code не на рівні «крутих промптів», а як із реальною продакшн‑системою. Один із найпрактичніших фокусів його підходу — перевірка результатів роботи моделі до того, як щось потрапляє в продакшн або впливає на бізнес.

Марчезе пропонує конкретну «силову фразу» — verify before you build — і вибудовує навколо неї трирівневу архітектуру валідації: від файлу Claude.md і MCP‑інструментів до зон, де людина обов’язково має лишатися в контурі рішень.

Чому «verify before you build» стало обов’язковим правилом

Ключова відправна точка — тверезе визнання обмежень моделей. Claude, як і будь‑яка інша сучасна LLM, може впевнено написати, що завдання виконано, тоді як система не працює, функція не покрита краями кейсів або результат просто не відповідає очікуванням користувача. Марчезе прямо формулює проблему: Claude галюцинує, повідомляє про завершення роботи, коли вона де-факто не завершена або не відповідає бажаному результату.

На цьому фоні з’являється «power phrase number four, verify before you build». Це не ритуальна фраза для промпта, а спосіб змінити режим взаємодії з моделлю: перш ніж дозволити Claude щось «будувати» — від коду до аналітичних звітів — система має продумати, як вона перевірить власний результат.

Тут Марчезе апелює до Бориса Черні, творця Claude Code. Той наполягає: якщо «дати Claude спосіб перевірити свою роботу» і вбудувати для моделі зворотний зв’язок, це здатне «у два‑три рази підняти якість фінального результату». І далі йде ще один крок: «справжній хід — дати Claude інструмент, який дозволяє бачити власний аутпут, а потім явно розповісти моделі про цей інструмент».

Це зміщує фокус із простого «перечитай код» до більш конкретного підходу: агенту потрібен не лише список правил, а й механічний спосіб подивитися на те, що він створив, і на основі цього коригуватися.

Як навчити Claude перевіряти себе: правило «інструмент + правило»

У цій логіці верифікація розпадається на дві частини. Перша — що саме слід перевірити. Друга — як це перевірити технічно або процесно. Марчезе формулює це просто: правило верифікації каже Claude, що перевіряти, а інструмент — як здійснювати перевірку.

Звідси виникають дуже конкретні сценарії. Якщо модель будує сайт, їй слід дати можливість відкрити його в браузері та оцінити фактичний фронтенд, а не лише «довіритися» генерованому коду. Якщо йдеться про підготовку звіту, Claude має отримати спосіб звірити цей документ із бренд‑гайдом, а не покладатися на абстрактне уявлення про «тон голосу» чи формат.

Критичний момент: інструмент сам по собі не спрацьовує, якщо Claude не знає про його призначення. Саме тому Черні й підкреслює — треба не просто увімкнути MCP‑інструменти, а й явно описати для моделі, що саме вони роблять і як допомагають оцінити результат. Лише тоді агент може «бачити» свій аутпут і свідомо запускати петлю самокорекції.

Марчезе пропонує формалізувати цю логіку в трьох рівнях: від системного файлу конфігурації до набору інструментів і, нарешті, до зон, де без людини взагалі не обійтися.

Рівень 1: Claude.md як місце, де починається перевірка

Перший рівень — оновлення Claude.md, того самого файлу, який Claude автоматично підтягує на початок кожного запиту. Саме він визначає базову поведінку агента в сесії. На думку Марчезе, тут має з’явитися одна ключова лінія: «Перш ніж виконувати будь‑яку роботу, поясни, як ти можеш її верифікувати».

Це невелика, але структурна зміна. Якщо раніше модель одразу стрибала в генерацію коду, тексту чи сценаріїв автоматизації, то після цього правки вона спершу схиляється до формування плану верифікації. Тобто замість «ось код» користувач спочатку побачить: «Ось як я планую перевірити, що цей код працює».

За рахунок того, що Claude.md завжди інжектиться на початок промпта, цю звичку не потрібно нагадувати вручну. Вона стає частиною «характеру» агента. Фактично, цей рівень змушує Claude думати про тестування, перш ніж мова взагалі зайде про реалізацію.

Рівень 2: MCP‑інструменти як місток до реальності

Другий рівень — вмикання потрібних інструментів під конкретні завдання. Марчезе пропонує починати з простого запиту до моделі: «Виходячи з того, що я будую, які інструменти можуть допомогти з верифікацією?». Далі Claude само пропонує варіанти — як зовнішні, так і внутрішні, технічні чи нетехнічні.

У прикладах, які він наводить, це виглядає так. Якщо розробник деплоїть застосунок на хостинг і хоче впевнитися, що реліз справді дістався продакшну, можна підключити відповідний MCP‑інструмент, який пінгуватиме ресурс або запитуватиме дані про стан деплою. Це технічний зовнішній кейс.

З іншого боку, є внутрішні нетехнічні сценарії — наприклад, написання постів для соцмереж. Тут доцільно створити «валідатор бренд‑голосу», умовний skill, який автоматично порівнюватиме свіжозгенерований текст із зафіксованим стилем компанії. І Claude знатиме, що перед відправкою пост має пройти через цей фільтр.

У результаті перевірка перестає бути ручною звичкою користувача і перетворюється на конкретні виклики інструментів. Модель отримує змогу не тільки придумати, як варто тестувати роботу, а й фізично виконати цю перевірку — від хитрих MCP до внутрішніх валідаторів.

Рівень 3: «human validation zones» там, де помилка надто дорога

Третій рівень — визнання того, що навіть із найкращими інструментами й найакуратнішим Claude.md людина все одно має лишатися в контурах рішень. Йдеться про концепцію «human validation zones» — зон, де без людського схвалення нічого не має змінюватися.

Марчезе опирається на відоме формулювання: «Що може піти не так, те й піде не так». В епоху, коли агенти беруть на себе левову частку операційної роботи, люди дедалі частіше випадають із потоку виконання. Це означає, що якісь небажані зміни рано чи пізно таки стануться.

Щоб мінімізувати ризики, він пропонує просту рамку: подивитися на всі вузли системи й відповісти на питання, де «вартість помилки» справді висока. Саме ці області й мають стати human validation zones.

У прикладі з застосунком фронтенд і сайт, із якими взаємодіють користувачі, Марчезе відносить до низьковартісної зони — там допустима стратегія «швидко будувати й ламати». Натомість платіжна система, що стоїть за цим інтерфейсом, — це вже зона високого ризику, де будь‑яка помилка може мати серйозні фінансові наслідки. Її він однозначно зараховує до human validation zone, де людина має особисто затверджувати зміни, а агенти не повинні мати повних прав.

Далі, за його словами, можна «копати глибше» — розбудовувати процеси навколо цих зон, налаштовувати права доступу й маршрутинг завдань. Проте навіть базовий рівень — просто вимагати людського підпису і в ряді випадків повністю прибрати автоматичні дозволи агентів — уже суттєво знижує ризики. Це теж варто зафіксувати в Claude.md, щоб агент знав: у низці ситуацій він не має права діяти автономно й повинен просити review.

Як три рівні валідації працюють разом

У підсумку Марчезе пропонує розглядати цю систему як єдине ціле. На першому рівні Claude навчений ще до початку роботи продумати валідацію. На другому рівні в нього є реальні інструменти — від MCP‑конекторів до внутрішніх скілів — якими можна здійснити цю перевірку. На третьому рівні визначені точки, де жоден інструмент не замінює людського рішення, і агент знає про ці обмеження наперед.

Щоб швидко інтегрувати все це у власний робочий процес, він пропонує готовий промпт, який можна «просто вкинути в Claude Code», щоб зібрати всі три шари верифікації воєдино. Та головна ідея не в конкретному тексті промпта, а в зміні парадигми: замість того щоб просити модель «будувати швидше», варто спершу змусити її думати, як вона дізнається, що взагалі побудувала правильну річ.

У світі, де LLM‑агенти дедалі частіше працюють як автономні системи, цей підхід перетворює їх із «креативних генераторів» на більш відповідальних виконавців, які вміють не лише видавати результат, а й ставити його під сумнів — до того, як за нього доведеться платити.

Джерело

YouTube: Type This Into Claude, It’ll Make You Build 10x Faster.

Угорський інженер і автор блогу The Pragmatic Engineer Ґерґей Орош на конференції Craft у Будапешті показав внутрішню «кухню» компаній на кшталт Uber, Stripe, Shopify й Airbnb. За останні місяці вони зібрали навколо AI не просто пару плагінів до IDE, а повноцінні внутрішні платформи: MCP‑шлюзи, агент‑студії, власні CLI та системи фонового запуску агентів. На цьому тлі стандартний «підключили Copilot і пішли далі» раптом виглядає як вчорашній день.

Uber як зразок нового AI‑дев‑стеку

Uber, де працює близько 3 тисяч інженерів і ще близько 20 тисяч співробітників по бізнесу, за кілька років перетворив звичайну платформу розробки на AI‑центричну інфраструктуру. Окремий департамент developer experience фактично став AI‑experience‑командою приблизно з двох десятків людей, яка будувала інструменти вже не для окремих девів, а для всієї організації.

Ключовою деталлю тут є внутрішній MCP‑шлюз. Uber побудував власний gateway поверх протоколу Model Context Protocol: через нього реєструються й виявляються інструменти, з якими можуть працювати агенти. Це не «ще одна інтеграція з LLM», а шар, через який уніфіковано підключаються сервіси компанії до агентів.

Поверх цього з’явився Uber Agent Builder — внутрішній конструктор агентів без коду, орієнтований на бізнес‑користувачів. Для інженерів, які будують ці можливості, це спосіб масштабувати себе на десятки тисяч колег: агенти створюють не тільки деви, а й, наприклад, операційні чи аналітичні команди.

Наступний рівень — Uber Agent Studio. Це вже середовище, де агенти можна «збирати» drag‑and‑drop‑режимом, комбінуючи кроки та інструменти, не заглиблюючись у код. У компанії діє реєстр таких агентів, і саме він виводить цю систему за межі інженерного департаменту: близько 20 тисяч співробітників Uber користуються цими конструкторами та студією, створюючи власні сценарії для бізнесу.

Тобто внутрішній AI‑стек виглядає як повноцінна платформа: MCP‑шлюз, но‑код‑builder, студія, реєстр, інтеграція з усіма внутрішніми системами. Це вже не «інструмент для девів», а компанійний рантайм для агентів.

CLI як «хмарний код» Uber

Окремий елемент цього стека — Uber AI FX CLI. Це інтерфейс командного рядка, який Орош порівнює з «cloud code для Uber». Від звичайного CLI його відрізняє те, що він одразу «зашитий» у внутрішню інфраструктуру: інтегрований із монорепозиторієм, сервісами, модельними endpoint’ами, експериментальними платформами.

Через цей CLI інженери працюють із різними моделями, не думаючи про деталі кожного провайдера: вибір, маршрутизація, налаштування вже інкапсульовані всередині. Замість того, щоб кидати запити напряму у зовнішні API, деви використовують одну консольну оболонку, з якою узгоджені всі внутрішні процеси й політики.

Таким чином, CLI стає не просто інструментом, а єдиною «воротами» до AI‑функцій у кодовій базі Uber — ще одним шаром, який стандартизує роботу з агентами по всій компанії.

Uber Minion: фонова армія агентів

Показовий елемент цієї архітектури — Uber Minion. Це система для запуску фонового виконання агентів у масштабі всієї компанії. На відміну від класичного «запустив агента в IDE», Minion вбудований в основні інфраструктурні системи Uber: монорепозиторій і платформу експериментів Morphus.

Завдяки такій інтеграції Minion може робити те, чого не дають загальні інструменти: працювати з реальними сервісами, розуміти структуру репозиторію, підлаштовуватись під експерименти й фічфлаги. Devs можуть користуватися сторонніми агентами на кшталт хмарних код‑асистентів, але на практиці часто обирають Minion саме тому, що він краще «вписаний» у середовище Uber і працює швидше й дешевше.

Система не обмежується простим запуском задач. Вона аналізує промпти й підказує, як їх переписати так, щоб агент відпрацював ефективніше: швидше, з меншим споживанням ресурсів і кращою якістю результату. Ці «мета‑підказки» — ще один шар інтелекту, який персональні інструменти зазвичай не дають.

У підсумку Minion виглядає як еталон того, якими можуть стати корпоративні рантайми агентів: тісно зв’язані з кодовою базою, експериментальними системами, політиками, спостережуваністю.

Коли AI‑код‑рев’ю стає шумом: Uber Code Inbox

Ще один симптом масштабного впровадження агентів — перевантаження розробників AI‑код‑рев’ю. У Uber автоматичні рев’ю стали настільки масовими, що компанії довелося будувати Uber Code Inbox — власну «вхідну скриньку» для AI‑коментарів до змін у коді.

Ідея проста: якщо більшість рев’ю роблять агенти, девелопери ризикують потонути в нотифікаціях і втратити критичні сигнали серед десятків «звичайних» рекомендацій. Code Inbox пріоритизує ці повідомлення: показує, що справді потребує людської уваги, а що можна відкласти.

Поверх цього Uber накручує додаткові механіки. З’являються «розумні призначення» рев’ю із SLA: якщо розробник не відреагував за певний час, запит перекидається на іншого. Формуються risk‑profile змін — коли система оцінює, наскільки небезпечним може бути патч і чи варто залучити більш досвідченого інженера. Є й UReview — внутрішній аналог сервісів на кшталт CodeRabbit чи Sonar, який працює з урахуванням контексту саме Uber.

Усе це робить код‑рев’ю знову керованим процесом, а не просто потоком автоматичних коментарів. На фоні вибухового росту кількості pull‑request’ів та AI‑змін — це вже не «приємний бонус», а необхідна частина дев‑стеку.

Stripe, Shopify, Airbnb: усі будують свій інфраструктурний шар

Uber у цьому сенсі не поодинокий випадок, а радше передній край загальної тенденції серед великих технологічних компаній. Орош описує, як «інші великі так само роблять своє»: кожен збирає аналогічні стеки навколо власних сутностей і назв.

Stripe має власні «minions», Tool Shed, Blueprints, Z Boxes — усе це елементи внутрішньої екосистеми інструментів і агентів, які прив’язані до платіжної доменної моделі, безпеки й процесів Stripe. У Ramp фігурують інструменти з назвами Inspect, Glass, Dojo, Sensei — це теж набір сервісів та оркестраторів, які координують роботу агентів у фінансовій інфраструктурі.

Shopify розгорнув набір із Sidekick, LM Proxy, dev MCP Server — знову ж таки, це внутрішні інструменти, а не просто підключений зовнішній асистент. Airbnb будує власні системи на кшталт One Everything і Catalyst.

Спільна риса: у всіх цих компаній є окремі інфраструктурні організації, які будують AI‑платформи для внутрішніх розробників і бізнес‑команд. Вони не покладаються на один‑єдиний готовий продукт на кшталт GitHub Copilot. Замість цього великі гравці збирають «шари» — MCP‑шлюз, агентний реєстр, внутрішні CLI, фонового рантайму, системи рев’ю й маршрутизації задач — і вже на них вішають конкретних моделей і вендорів.

Важливий наслідок: саме цей інфраструктурний шар стає тим, що важко скопіювати. Підключити ту саму модель теоретично може будь‑хто, а от побудувати Uber‑рівень інтеграції з монорепою, експериментальною платформою та тисячами внутрішніх сервісів — роки роботи.

Чому «просто купити Copilot» вже недостатньо

На фоні таких прикладів традиційний підхід — оплачений Copilot чи ще один AI‑плагін до IDE — виглядає як лише перший щабель. Великі компанії демонструють кілька принципово інших акцентів.

По‑перше, фокус зміщується з окремого розробника на системи. Агенти — це не особисті асистенти у редакторі коду, а частина корпоративної платформи, до якої підключені реєстри, політики, контроль ризиків, власні CLІ й фонові рантайми. Справжній виграш від AI з’являється тоді, коли агенти вбудовані в життєвий цикл продукту, а не просто генерують шматки коду.

По‑друге, компаніям доводиться вирішувати проблему «надлишкового AI‑шуму». Uber Code Inbox і подібні механізми — це визнання того, що автоматизація без правильної фільтрації швидко перетворюється на нове джерело перевантаження.

По‑третє, виникає новий клас внутрішніх команд — платформних і AI‑experience‑груп, які відповідають не тільки за продуктивність інженерів, а й за те, щоб агенти реально працювали в контексті конкретного бізнесу: від маршрутизації запитів до оптимізації промптів під вартість та якість.

Усе разом формує ескіз того, як може виглядати «стандартний» AI‑стек через кілька років: власний MCP‑шар, agent builder для бізнес‑користувачів, agent studio для комбінування сценаріїв, внутрішній CLI як єдиний інтерфейс до моделей, фоновий рантайм на кшталт Minion, спеціалізовані інструменти для пріоритизації рев’ю й моніторингу ризиків.

Іншим компаніям це ставить досить чіткий виклик. Підключити зовнішній AI‑сервіс сьогодні просто. Побудувати навколо нього внутрішню екосистему, яка дійсно змінює спосіб роботи розробників і бізнес‑команд, — зовсім інший рівень інвестицій. Саме на ньому вже зараз працюють Uber, Stripe, Shopify, Airbnb та інші, задаючи планку для того, що незабаром називатимуть просто «нормальним дев‑стеком».

Джерело

Slow down to speed up: AI and software engineering — The Pragmatic Engineer

На конференції Craft 2026 у Будапешті автор блогу The Pragmatic Engineer Ґерґей Орош поділився рідкісним зрізом того, як великі AI‑лаби й продуктові компанії уже перебудували щоденну розробку навколо кодових агентів. На відміну від теоретичних прогнозів, це історії з перших рук: внутрішні метрики, робочі практики OpenAI, Anthropic, Cursor, Google, Uber й інших гравців — і дуже конкретні цифри, що показують, наскільки більше коду сьогодні реально пише AI.

Вибух продуктивності: коли кодові агенти множать обсяг коду

Одне з найяскравіших спостережень стосується команд, які інтегрували AI‑агентів у свій щоденний процес розробки. За внутрішніми даними Linear, які компанія поділилася вперше, команди, що користуються агентами, зараз «шиплять» приблизно у п’ять разів більше коду, ніж ті, що працюють без них. Це не віддалений прогноз, а вже наявний ефект: «by now the teams that are using agents are shipping five times as more code… this is massive 5x increase».

Орош окремо наголошує: це зміна масштабу, яку галузь не бачила десятиліттями. Подібне зростання продуктивності зазвичай розтягується на 10–20 років еволюції інструментів і практик. Тепер же, за його словами, п’ятикратний приріст обсягу коду стався менш ніж за два роки.

Що це означає на рівні окремого розробника, добре видно на прикладі Cursor — одного з найбільш «агентно-орієнтованих» IDE на ринку.

Cursor: вдвічі більше рядків і втричі більші PR за рік

Команда Cursor поділилася з Орошем статистикою щодо того, як змінився випускний «темп» розробників, які активно працюють у цьому середовищі. За рік середня кількість рядків коду, які деви генерують за допомогою Cursor, «майже у два з половиною рази» зросла: «from 3 up 4,000 lines of code to more than 8,000 lines of code just on cursor».

Змінився не лише обсяг, а й структура змін. «The size of PRs also from cursor is up by 3x… if you combine those two that’s six times as much code», — каже Орош. Тобто окремі pull request стають у три рази більшими, а сумарний обсяг коду, який проходить через них, зростає приблизно вшестеро.

Cursor також бачить ще одну помітну тенденцію: різко зростає частка розробників, які приймають зміни від AI без ручного редагування. Після виходу нових моделей на кшталт Opus 4.7 та GPT 5.5 «the percentage of devs using cursor who are accepting changes from the AI without any manual review is massively up». Це означає, що для значної кількості користувачів AI уже не просто інструмент підказок, а фактичне джерело фінального коду.

Орош одразу застерігає: така експоненціальна крива обсягу коду тягне за собою й очевидний наслідок — зростання кількості багів. Він прямо артикулює те, про що посміхаючись думає зал: «we know that there’s six times as many bugs… we’ll again, we’re going to get there». Питання якості він розкриває окремо, але саме на прикладі Cursor добре видно базову динаміку: AI швидко перетворюється на основний «двигун» потоку змін, а не допоміжний інструмент.

Anthropic: 5 агентів на ноутбуці й 70–90% коду, написаного AI

Як виглядає «життя з агентами» всередині AI‑лабу, Орош демонструє на прикладі Anthropic та його продукту Claude Code. Він розповідає про розмову з Борисом Черні, який очолює команду Claude Code й одночасно залишається дуже hands‑on‑інженером.

«Boris specifically runs five parallel agents on his laptop all the time. He ships 20 to 30 pull requests a day», — описує Орош. П’ять паралельних агентів постійно працюють поруч із людиною, яка водночас керує великим продуктом і щодня відправляє десятки PR. Це наочна демонстрація того, наскільки щільно агентні воркфлови можуть бути вплетені в роботу навіть топових техлідів.

Всередині Anthropic Claude Code вже давно став не просто продуктом для клієнтів, а базовим інструментом розробки самої компанії. Орош наводить їхні внутрішні оцінки: «Today 100% of cloud code is generated by cloud code… inside Entrophic is not 100% but it’s closer to 70 to 90%». Тобто:

• весь код самого Claude Code повністю згенерований Claude Code
• у ширшому кодовому базисі Anthropic AI‑генерація становить приблизно 70–90% залежно від команд та контексту

Принципово важливо, що таке проникнення AI в їхній дев‑процес не є формальною ціллю: «there’s no target. This is just people using it again». Люди просто віддають перевагу інструменту, який працює швидше й звичніше за ручний ввід.

Окремий акцент — на тому, що класичні артефакти на кшталт PRD‑документів для планування фіч у Anthropic фактично «мертві». Черні, за словами Ороша, вважає їх застарілими, а компанія масово переходить на прототипування, де агенти допомагають швидко збирати робочі прототипи замість довго писати специфікації.

OpenAI: кнопка «fix it» і компанія, де «більшість людей більше не пише код»

Якщо в Anthropic Claude Code став внутрішнім «двигуном коду», то в OpenAI роль грає Codex і внутрішня версія ChatGPT. Орош описує те, як виглядає їхня розробка сьогодні.

Всередині компанії існує модифікований застосунок ChatGPT із вбудованою функцією «fix it». «Inside of OpenAI… they have fix it button. You can literally just take a screenshot and say fix this bug and it goes to codeex. It generates a pull request and an engineer can merge it», — пояснює Орош.

Алгоритм роботи простий і показовий:

1. Інженер або навіть неінженер робить скріншот проблеми в інтерфейсі чи системі.
2. В інтерфейсі ChatGPT він натискає кнопку «fix this bug».
3. Запит іде у Codex, який генерує код‑фікс та створює pull request.
4. Людина переглядає PR і за потреби зливає його.

Для некритичних змін у OpenAI запроваджені багаторівневі safety‑механізми: частина коду може йти в продакшен після лише AI‑рев’ю, для критичних шляхів обов’язковий людський перегляд. Але те, що навіть неінженери можуть фактично запускати повний цикл «знайшов баг — отримав PR», показує, наскільки глибоко Codex обгортає рутини розробки.

Орош описує й повсякденну «агентну» культуру компанії. Більшість девів, за його словами, запускають «several agents» одночасно. Він наводить історію, як під час відеоінтерв’ю запитав одного з інженерів, чи той тримав агента увімкненим під час розмови. Відповідь була показовою: «I didn’t have an agent running. I had five».

Далі — ще більш радикальний зсув: «most people don’t really write code inside of OpenAI… this has changed in October… it’s just slowly going away». Якщо раніше було типовим співвідношенням, коли деви писали приблизно 30% коду руками й 70% — через AI, то нині навіть ця «людська третина» поступово зникає. Команда Codex, за його словами, «obviously writes it all with Codex».

Фокус зміщується до іншої компетенції: «taste, knowing what to build is becoming pretty important». Вартість не стільки в тому, щоб написати код, скільки в тому, щоб правильно сформулювати, що саме має бути побудовано, як це інтегрується в систему й яку проблему вирішує.

Цю логіку OpenAI застосовує навіть до власних інструментів. Codex, за словами Ороша, «improves itself» — вночі він проганяє тести, шукає можливі покращення, а зранку команда отримує пропозиції змін і вже вирішує, що приймати. Під час дебаг-сесій інженери надсилають голосові нотатки в Codex, який паралельно аналізує їх і повертає результати вже до кінця зустрічі.

Google і обмеження власної моделі

Всередині Google картина менш однозначна. Компанія історично побудувала величезний стек внутрішніх інструментів: власний IDE Cider, монорепозиторій Piper, Borg замість Kubernetes, Monarch як внутрішній аналог Datadog, Code Search, Critique для code review тощо. За словами Ороша, «AI is integrated into all of these things and it’s all integrated together really really nicely so inside it’s a really good experience».

Втім, ключова проблема — якість самої моделі Gemini. Орош формулює це дуже прямо: «Gemini is just not as good as Opus or GPT 5.5». У результаті там, де інженери мають можливість користуватися Claude Code, вони це роблять, але «only inside the Gemini org», де є офіційний дозвіл. Обмеження на використання зовнішніх моделей означає, що загальне впровадження AI у Google, попри вражаючий внутрішній стек, відстає від компаній, які можуть безперешкодно брати кращі моделі ззовні.

Uber та «новий стандарт» внутрішніх AI‑платформ

Uber з’являється в розповіді Ороша як показовий приклад того, як навіть відносно «традиційна» продуктова компанія з кількома тисячами інженерів відбудовує свій дев‑стек навколо агентів. Він підкреслює, що в Uber близько 3 000 розробників, а окрема команда developer experience фактично перетворилася на «AI experience‑команду» з приблизно 20 людей.

Ця невелика група побудувала цілу екосистему внутрішнього AI‑інструментарію:

• внутрішній MCP‑gateway для реєстрації й відкриття сервісів
• конструктор агентів Uber Agent Builder і візуальну Agent Studio для нетехнічних співробітників
• реєстр агентів, яким користуються близько 20 000 людей поза інженерним штатом
• AI‑CLI, яке Орош описує як «the cloud code for Uber»
• Uber Minion — фонова система агентів, інтегрована в монорепозиторій і платформу експериментів Morpheus
• Code Inbox, що фільтрує AI‑рев’ю коду й підсвічує, де потрібна увага людини
• Smart Assignments і UReview для пріоритизації та маршрутизації рев’ю

Орош порівнює Uber Minion із режимом фонового виконання агентів у Cursor, але підкреслює, що внутрішнє рішення працює «краще і швидше» завдяки глибокій інтеграції з їхньою інфраструктурою. Наприклад, Minion сам аналізує промпт, пропонує варіанти, як отримати «results faster cheaper», і тому деви воліють користуватися ним, навіть маючи доступ до Claude Code.

Ця частина розповіді у виступі Ороша тісно пов’язана з іншим його спостереженням: великі компанії на кшталт Stripe, Shopify, Airbnb так само інвестують у власні MCP‑шлюзи, агентні студії, CLI та внутрішні рантайми — але це детальніше він виносить в окремий блок, який уже виходить за межі теми чисто «кодового вибуху».

Де закінчується хайп і починається практика

Усі ці приклади разом малюють чіткий тренд: агенти перестають бути додатковою опцією в IDE і стають базовим шаром розробки — від AI‑лабораторій до великих продуктових компаній.

Ключові практичні маркери цього переходу, які фіксує Орош у своїх розмовах і даних:

По-перше, різке зростання обсягу коду. П’ятиразовий приріст у командах з агентами за даними Linear, дво‑з‑половиною кратне зростання рядків на девелопера в Cursor, триразове збільшення розміру PR і до шестиразового сукупного приросту коду — це вже не експерименти окремих ентузіастів.

По-друге, глибина інтеграції у внутрішні процеси. В Anthropic 70–90% коду компанії створюється Claude Code, а сам Claude Code на 100% написаний собою. В OpenAI існує кнопка «fix it», яка перетворює скріншот у pull request, і «most people don’t really write code» у класичному сенсі. Uber будує цілий ланцюжок платформ для агентів, покликаний зробити AI доступним не лише девам, а й десяткам тисяч бізнес‑користувачів.

По-третє, зміна ролі розробника. Там, де агенти беруть на себе більшу частину «рутинного» набору коду, зростає цінність смаку й продуктового мислення — «knowing what to build». У кодових лабах AI не скільки замінює інженера, скільки вимагає від нього іншого профілю — архітектора, куратора агентів, людини, що формулює задачу правильно й контролює результат.

По-четверте, розмивання межі між інженерами й «неінженерами» у частині взаємодії з кодом. Функції на кшталт OpenAI‑шної «fix it» дозволяють людям без сильного дев‑бекграунду ініціювати кодові зміни, покладаючись на автоматизований пайплайн генерації та рев’ю.

Орош не ідеалізує ці процеси: далі у виступі він детально розбирає проблеми якості, перевантаження кодової бази, вигоряння рев’юерів і бюджетний шок від AI‑інференсу. Але саме в частині агентів і обсягу коду картинка вже досить чітка: хайп навколо «AI, що пише код», перетворився на стрімко мінливий, але дуже конкретний робочий стандарт у значній частині індустрії.

Висновки

Історії Anthropic, OpenAI, Cursor, Google й Uber у викладі Ґерґея Ороша показують, що дискусія про «AI‑агентів у деві» змістилася з площини «чи це спрацює» у площину «які наслідки матиме такий темп для якості, культури й ролі розробника». Команди, які вже живуть у цій реальності, бачать п’ятикратні й більші прирости обсягу коду, масову генерацію PR‑ів агентами й дедалі менший обсяг коду, написаного людиною «від руки».

Попереду — робота з відновлення балансу між швидкістю й довірою до коду, але факт залишається фактом: агентні системи вже сьогодні радикально переписують те, як створюється програмне забезпечення у провідних технологічних компаніях.

Джерело

Slow down to speed up: AI and software engineering — The Pragmatic Engineer

Anthropic, компанія за штучним інтелектом Claude, оприлюднила внутрішній підхід до того, як її команди — від інженерів до маркетингу й юридичного відділу — будують та використовують Claude Skills. Підприємець і розробник Остін Марчезе розібрав цю «плейбук-логіку» у великому відеоогляді. Окрема лінія в цій історії — верифікаційні skills: саме їх в Anthropic вважають головним важелем для підвищення якості результатів Claude.

Чому верифікація стала головною ставкою Anthropic

У внутрішніх матеріалах Anthropic прямо сказано: верифікаційні skills мали «найбільш вимірюваний вплив» на якість вихідних результатів Claude. Настільки значний, що, за формулюванням компанії, «може бути виправданим, щоб інженер витратив тиждень лише на те, щоб зробити ваші верифікаційні skills відмінними».

Це не декоративна надбудова над основною роботою моделі, а системне рішення: Anthropic фактично виділяє верифікацію в окремий шар, через який проходить кожен важливий результат. У цьому ж контексті згадується й автор Claude Code: якщо дати Claude спосіб перевіряти власну роботу, це «у 2–3 рази підвищить якість виходу».

Цей акцент помітно відрізняється від типового сприйняття генеративних моделей. Більшість користувачів, як описує Марчезе, дивляться на AI як на «множник» — більше контенту за той самий час, при незмінній якості. Anthropic же вбудовує у свої процеси іншу логіку: використовувати Skills як «якісний фільтр», щоб при тій самій кількості результатів суттєво підняти їхню планку.

Два рівні перевірки: коректність проти якості

У структурі Anthropic верифікація — не однорідний процес. Окремо виділяються два різні типи перевірок, які працюють з різною природою помилок і різними критеріями успіху.

Перший тип — верифікація коректності. Це відповідь на запитання: чи все «правильно» в фактичному сенсі. Чи збігаються цифри, чи працює застосунок, чи виконав код те, що мав зробити. Це зона, де результат можна виміряти однозначно: пройти тести, запустити програму, звірити значення.

Другий тип — верифікація якості. Тут йдеться не про те, чи «працює» результат, а чи відповідає він тій планці, яку ставить собі команда або конкретний користувач. Чи достатньо це добре для публічної презентації? Чи відповідає це стилю бренду? Чи виглядає це як робота сеньйорного спеціаліста, а не швидка чернетка?

Марчезе акцентує: більшість людей думає про AI як про інструмент, що дає «вищу кількість при тій самій якості». Натомість підхід із верифікаційними skills дозволяє використовувати Claude як «підсилювач якості»: можна зберегти обсяг роботи, але зробити її суттєво кращою за рахунок того, що кожен вихідний результат проходить через виразно описаний якісний фільтр.

/verify та /run: вбудовані технічні приклади

У Claude Code частина цієї логіки зашита прямо «з коробки». У середовищі вже існують два стандартні skills, які в Anthropic відносять до технічної верифікації.

Перший — /verify. Він запускає застосунок і підтверджує, що зміна в коді справді робить те, що повинна робити. Це фронтальна перевірка коректності: не тільки синтаксису чи стилю, а реальної поведінки системи після змін.

Другий — /run. Цей skill просто запускає застосунок так, щоб Claude міг «побачити» власну роботу. У такому режимі модель не тільки генерує код або конфігурацію, а й спостерігає за тим, як усе працює в дії. Це створює контур зворотного зв’язку, у якому Claude може виявляти помилки вже на рівні виконання, а не лише логіки.

Усі ці приклади показують, що для Anthropic верифікація — це не окремий «чек-лист» для людини, а така сама автоматизована частина пайплайну, як і генерація. Claude не просто видає результат, а й бере участь у його перевірці.

Об’єктивний вихід як серце будь-якого верифікатора

Ключовий принцип, який повторюється у всій цій системі: «будь-який хороший верифікатор потребує об’єктивного виходу». Мається на увазі вихід, щодо якого можна однозначно сказати, пройшов тест чи ні — як самій моделі, так і користувачу.

Як приклад Марчезе наводить умовний /code reviewer: якщо це саме верифікаційний skill, він повинен не просто давати розгорнутий відгук, а видавати чіткий результат — «pass» або «fail». Тоді цей вихід можна використовувати як сигнал у ширшому пайплайні: пропускати зміни далі або блокувати їх до виправлення.

Подібна логіка — і для інших сценаріїв. Уявна «перевірка звіту» не просто пише коментарі, а виставляє оцінку за шкалою, наприклад «від 1 до 10». Наявність такої кількісної або бінарної оцінки дозволяє робити з результатами подальші автоматизовані дії і, головне, дозволяє Claude самому орієнтуватися в тому, чи достатньо добра його відповідь.

Цей акцент на «об’єктивному виході» суттєво відрізняє верифікаційні skills від звичайних допоміжних prompts. Йдеться не про ще один текстовий відгук, а про чітко структуроване рішення, придатне для подальшої автоматизації.

Skill-driven verification: вбудована перевірка в уже наявні навички

Попри те, що верифікатори можна будувати з нуля, Марчезе віддає перевагу іншому підходу, який він називає skill-driven verification. Ідея проста: замість окремих великих «рев’ю-скилів» варто модифікувати вже наявні skills так, щоб у них з’явився виразний верифікаційний компонент.

Наприклад, якщо існує skill для роботи з голосом бренду, його можна доповнити перевіркою: той самий /brandVoice не лише генерує текст у потрібному стилі, а й здатен сказати, чи проходить результат валідацію за критеріями бренду. Вихід у такому випадку може включати, знову ж таки, pass/fail або оцінку за шкалою.

Цей підхід зміщує фокус із «окремого етапу рев’ю» до «рев’ю як властивості кожної навички». Фактично, кожен ключовий skill перетворюється на міні-систему, де всередині вже вбудовано свій власний верифікатор. Це робить систему більш модульною: навичка одночасно генерує результат і вміє пояснити, чи відповідає він заданим критеріям.

У своєму розборі Марчезе демонструє промпти, які використовує для аудиту наявних skills — щоб виявити, які з них можна «підкрутити» у бік верифікації, а які варто будувати з нуля як спеціалізовані верифікатори. Але базовий принцип залишається тим самим: чим більше навичок мають вбудований об’єктивний тест, тим менше доводиться сподіватися на інтуїцію користувача.

Коли менеджер — це skill: верифікація як симуляція чужого судження

Окремий пласт у підході Anthropic — верифікація як симуляція експертного або менеджерського відгуку. Тут йдеться не лише про «правильно/неправильно», а про те, якою була б реакція конкретної людини зі своїм стилем мислення та очікуваннями.

Марчезе наводить приклад Амула Асара, керівника зростання в Anthropic. Той створив верифікаційний skill, який імітує фідбек його реальної менеджерки. Для цього в систему було подано дані з її публічних текстів і внутрішніх комунікацій — зокрема, Slack-обговорень. Далі щотижня цей skill запускається й «розповідає», який відгук вона дала б на зроблену за тиждень роботу.

За словами Марчезе, так формується «судження, закодоване як рецензент». До моменту, коли працівник показує щось своєму керівнику, результат уже пройшов перевірку через його «AI-двійника» — і, відповідно, наближений до того рівня, який очікується в живій взаємодії.

Сам Марчезе описує схожу практику у власній роботі. У нього є skill під назвою internal focus group, який проганяє роботу через «групу радників» і видає конкретний фідбек із позиції цих віртуальних консультантів. Оскільки формального менеджера в нього немає, така «внутрішня фокус-група» виконує роль ради директорів або борду, що регулярно оцінює його рішення як засновника.

Обидва приклади демонструють, як Anthropic та пов’язані з нею практики інтерпретують верифікацію ширше, ніж технологічний контроль якості. Це спосіб закодувати в системі вподобання, вимоги та стиль мислення конкретних людей, щоб Claude міг не просто перевіряти формальну правильність, а й узгоджувати результати із реальними очікуваннями команди.

Висновки: верифікація як ядро серйозних AI-систем

У внутрішній логіці Anthropic верифікаційні skills перестають бути «додатковою опцією» для параноїдів, які бояться помилок. Вони стають центральним шаром, через який проходить кожен важливий вихід Claude, — шаром, заради якого, на думку компанії, виправдано інвестувати повний робочий тиждень інженера.

Поділ на верифікацію коректності й якості дає можливість працювати одночасно з фактами й планкою очікувань. Вбудовані skills на кшталт /verify і /run показують, як це виглядає в технічних сценаріях, тоді як підхід skill-driven verification демонструє, як ту ж логіку можна застосувати до будь-якої навички — від брендингу до продуктових рішень.

І, нарешті, приклади з симуляцією менеджерського відгуку чи «внутрішньої фокус-групи» розкривають, що верифікація в системі Claude — це не лише про тести, а й про закодуване судження людей, з якими ви реально працюєте або на яких орієнтуєтесь.

Саме цей шар, за рахунок об’єктивних виходів і чітко описаних критеріїв, перетворює Claude з генератора текстів або коду на інструмент, здатний стабільно тримати високу планку якості. А в екосистемі Anthropic саме таку роль відводять верифікаційним skills.

Джерело

YouTube: How Anthropic Employees ACTUALLY Use Claude Skills

Anthropic, компанія, що створила Claude, оприлюднила внутрішній плейбук того, як її команди будують та використовують Claude Skills — від інженерів до маркетологів і юристів. Підприємець і розробник Остін Марчезе проаналізував інтерв’ю, блоги й офіційні документи Anthropic і показав, що базове уявлення про «скіли як markdown-файли» виявляється хибним. Насправді для продакшн-команд Claude Skill — це повноцінна папка з кодом, шаблонами та налаштуваннями, які роблять робочі процеси стабільнішими й дешевшими.

Claude Skill як папка, а не текстовий файл

Одне з ключових непорозумінь навколо Claude Skills пов’язане з тим, як їх уявляють. Багато хто вважає, що це просто один markdown-файл з інструкціями. Anthropic прямо називає це «поширеною хибною думкою».

У внутрішньому підході компанії skills — це не «просто текстові файли». Вони розглядаються як папки, які можуть містити скрипти, асети, дані та інші допоміжні матеріали. Агент Claude здатен ці файли «відкривати, досліджувати та змінювати» в межах цього робочого простору.

У підсумку, за формулюванням з плейбуку Anthropic, skill — це папка з набором компонентів. Саме композиція цих компонентів, а не один описовий промпт, визначає, наскільки потужним та надійним буде інструмент.

Такий підхід від самого початку віддаляє Claude Skills від класичного «довгого системного промпта». Йдеться не про одну гігантську інструкцію, а про структурований, файловий артефакт, який можна розвивати, версіонувати, тестувати і поступово ускладнювати.

Скрипти як «мотор» скіла: менше імпровізації, більше повторюваності

У цій файловій структурі Anthropic виділяє кілька ключових компонентів, без яких навряд чи варто говорити про продуманий skill. Перший і, за оцінкою компанії, один з найпотужніших — це скрипти.

Скрипт у цьому контексті — це просто комп’ютерний код, який виконує конкретне завдання. Anthropic формулює це дуже жорстко: один з найсильніших інструментів, які можна дати Claude, — це саме код. Якщо Claude отримує готові скрипти й бібліотеки, модель витрачає свої «ходи» на композицію, планування та ухвалення рішень, а не на відтворення шаблонного коду з нуля.

За таким підходом повторювані, добре визначені операції виносяться у скрипти, а сам Claude працює як оркестратор: вирішує, що саме запустити, як поєднати окремі частини, де потрібен додатковий аналіз чи креатив.

Критичний момент — поділ детермінованих і недетермінованих робочих процесів. Anthropic пропонує чітко відрізняти:

• детерміновані workflows, де однаковий вхід завжди дає однаковий вихід (як «2 + 2 = 4»). Ці задачі ідеально підходять для скриптів, бо їх поведінка стабільна й передбачувана;

• недетерміновані workflows, де один і той самий запит може породжувати різні коректні відповіді. Це типовий простір для LLM: формулювання тексту, варіанти пояснень, креативні рішення.

Чим більше детермінованої логіки перенесено в код, тим менше модель «імпровізує» там, де імпровізація не потрібна. У плейбуці це зводиться до простої тези: що більше функціоналу винесено у скрипти, то більш повторюваним буде результат і тим менше токенів знадобиться для досягнення того ж ефекту.

Для команд, які рахують гроші й борються за стабільність продакшн-виходів, цей баланс між «те, що повинен робити код» і «те, що повинен вирішувати Claude» стає одним із головних інженерних параметрів при проєктуванні skills.

Шаблони й асети: робити «як минулого разу», але автоматично

Другий «силовий» компонент, на який Anthropic окремо звертає увагу, — це асети й шаблони. Йдеться про файли, які завантажуються всередину skills-папки і служать цільовими формами вихідного результату.

У межах Claude Skill можна додати конкретні файли як шаблони бажаного аутпуту. Якщо очікується, що результатом роботи буде, скажімо, презентація, до папки додається попередній файл-зразок. Він потрапляє до каталогу assets і стає базовою формою, яку Claude заповнює новими даними.

З практичної точки зору це означає, що шаблон стає «каркасом» для нескінченної кількості звітів чи документів. Змінюється шаблон — автоматично змінюється й форма всіх наступних виходів, які генерує skill.

Anthropic підкреслює, що логіка тут така сама, як і зі скриптами: йдеться про поступове відмовляння від імпровізації. Мета — щоб skill припинив щоразу «вигадувати» структуру з нуля і почав послідовно відтворювати один і той самий формат.

Для команд це не лише про бренд-буки чи візуальний стиль. Навіть у суто технічних пайплайнах стабільні шаблони виводу — спосіб уніфікувати формати, спростити подальшу обробку й інтеграцію в інші системи.

Setup-промпти: скіли мають бути зрозумілими не лише для Claude

Третій ключовий елемент всередині папки — так звані setup-промпти та супровідні файли конфігурації, які роблять skills зрозумілими й керованими для людей, а не тільки для моделі.

Anthropic апелює до відомого принципу програмування: будь-хто може написати код, який зрозуміє комп’ютер, але хороші розробники пишуть код, який зрозумілий людям. У світі skills це транслюється у формулу: будь-хто може написати інструкцію, яку зрозуміє Claude; найкращі пишуть skills так, щоб їх легко читали й використовували люди.

Щоб цього досягти, у плейбуку пропонують кілька технічних прийомів.

По-перше, створити файл config.json. Він працює як система первинної ініціалізації: під час першого запуску, якщо бракує критичного параметра, skill не намагається «здогадатися», а явно запитує саме цю інформацію. Введені значення зберігаються, тож надалі їх не потрібно повторювати. Це дозволяє скілу «пам’ятати» налаштування задачі й скорочувати тертя при повторному використанні.

По-друге, активно використовувати вбудований механізм «ask user question». У Anthropic пропонують у skill.md визначати, де Claude має не просто чекати вільного тексту, а показувати структуровані варіанти відповіді — наприклад, у вигляді множинного вибору. Це наближає досвід роботи зі skill до «інтерв’ю-флоу», де користувача крок за кроком проводять через чітку послідовність рішень.

По-третє, на самому початку файлу skill.md рекомендується оголошувати поле arguments. Воно слугує пам’яткою: коли хтось викликає цей skill, arguments прямо показує, які саме вхідні дані потрібні для коректного запуску. Це не стільки інструкція для Claude, скільки підказка для колег чи для самого автора через рік-два, коли деталі забудуться.

Anthropic наголошує: будуючи skills, варто орієнтуватися не на себе «сьогодні», а на себе через один-три роки. Системи, що накопичують цінність з часом, вимагають інвестицій у читабельність, прозорість і самодокументованість.

Як технічна архітектура skills економить токени й нерви

Якщо звести підхід Anthropic до Claude Skills в одну лінію, він впирається в дуже інженерну оптику: skill — це не магічний промпт, а невеликий застосунок у вигляді папки.

Скрипти відділяють детерміновану логіку від креативної, зменшуючи потребу в довгих промптах і повторній генерації «бойлерплейту». Шаблони й асети фіксують формат результатів, знімаючи з Claude тягар проєктування структури кожного разу. Setup-промпти, config.json, arguments і «опитування користувача» роблять skills придатними для тривалої, спільної експлуатації без постійного заглиблення у вихідний код.

Anthropic прямо пов’язує обсяг логіки, винесеної в ці компоненти, із двома ключовими метриками: повторюваністю виходів і кількістю використаних токенів. Чим більше інструкцій та обчислень зашито у файли всередині папки, тим рідше Claude доводиться генерувати зайвий текст, відтворювати однотипні фрагменти чи «вигадувати» механіку процесу.

Для команд, які будують на Claude реальні робочі процеси, це змінює саме мислення про skills. Замість того, щоб сприймати їх як «розумні markdown-и», Anthropic пропонує бачити в них маленькі, еволюційні програмні модулі, де кожен файл — це частина системи: код, форма виходу, конфігурація чи інтерфейс взаємодії з людиною.

Висновок: від промптів до системи папок

Внутрішній плейбук Anthropic показує, що Claude Skills проектуються радше як набір компонентів в одній папці, ніж як один довгий текстовий опис. Папка зі скриптами, шаблонами, конфігураціями та setup-промптами дозволяє відокремити стабільну, детерміновану логіку від змінних і креативних частин, знизити витрати токенів і зробити виходи відтворюваними.

Для продакшн-команд це означає, що робота зі skills наближається до звичної інженерної практики: проєктування структури, інкапсуляція логіки в код, використання шаблонів, документування аргументів і налаштувань. У такій моделі Claude залишається тим, чим найкраще вміє бути, — універсальним композитором і координатором, який працює поверх надійної файлової основи.

Джерело

YouTube: How Anthropic Employees ACTUALLY Use Claude Skills

Канал Tech With Tim протестував нову модель MiniMax M3 у реальних сценаріях розробки й порівняв її з популярною моделлю Composer 2.5. Формально це звичайний огляд інструмента для кодування, але між рядків проглядається інша, важливіша історія: як поєднання гігантського контекстного вікна і дуже дешевого токен-ліміту змінює спосіб, у який розробники можуть мислити про довгі AI-сесії, автономні агенти й роботу з великими репозиторіями.

Де грає роль контекст: 12 годин автономної роботи

Один з ключових аргументів на користь MiniMax M3 — не стільки “розумність” моделі, скільки те, як вона поводиться у довгих безперервних сесіях.

Команда MiniMax, як навели в огляді, запускала модель в автономному режимі протягом 12 годин. За цей час агент “міг продовжувати виконувати, лупитись без людського втручання”, виконуючи послідовності викликів інструментів і тримаючи весь ланцюжок міркувань у пам’яті. Демонстрація виглядає як стрес-тест саме контекстного вікна: чи не “забуде” модель, що робила годину тому, коли дійде до чергового кроку.

Ключовий висновок з цього експерименту прозвучав прямо: “це просто показує, що контекстне вікно працює і модель може робити купу tool calls перед тим, як зрештою здатися”. Іншими словами, фокус не на одному ідеальному виклику, а на десятках і сотнях кроків — аналіз, планування, правки, тести, нові спроби.

У практиці розробника це відкриває простір для сценаріїв, які ще недавно виглядали екзотикою:

• довгі автономні “рани” агента, який годинами рефакторить, тестує або збирає складну фічу;
• інструментальні ланцюжки, де модель постійно ходить у браузер, тести, build-систему;
• поступове наростання контексту замість агресивного “забуття” частини історії через ліміт.

MiniMax M3 не позиціонують як найкращу модель на ринку, але саме її здатність тримати великі діалоги та довго “думати” над задачами стає одним із центральних аргументів.

Мільйон токенів у дії: як виглядає велика сесія в IDE

Практичний тест на розробці вебзастосунку показав, як велике контекстне вікно використовується в реальній IDE. MiniMax M3 отримала завдання створити з нуля веб‑додаток для скорочення URL‑адрес. Модель писала код істотно довше за Composer 2.5 — приблизно у кілька разів — але при цьому поводилася як педантичний інженер.

Вона спершу “накидала” загальний драфт усіх файлів і архітектури, а вже потім переходила до інструментальних викликів: створення файлів, редагування, запуск тестів, відкриття браузера. Кожен крок супроводжувався додатковим аналізом та самокритикою: модель переписувала частини коду, змінювала структуру, додавала валідацію й тести.

У підсумку отриманий проект вийшов великим і добре структурованим: 21 файл, розділені конфігурація, база даних, хендлінг помилок, сервіси, утиліти, повний набір тестів та перевірки в UI. Це був не “мінімально робочий прототип”, а радше невеликий, але повноцінний застосунок.

При цьому, навіть після досить тривалої сесії, виявилося, що “ми лише на приблизно 106 000 із загального вікна в 1 мільйон токенів”. Фактично модель встигла:

• прийняти первинний промпт;
• спланувати структуру застосунку;
• згенерувати значний обсяг коду у кількох файлах;
• зробити багаторазові правки й тести;
• тримати весь цей процес у єдиному діалозі.

І все це — десь на десятій частині доступного контексту. Тобто, простору вистачає не лише на початкову генерацію, а й на подальші великі цикли “аналіз → правки → тести” у рамках тієї ж сесії.

Для робочих сценаріїв це означає, що розробник може не боятися “забити” контекст кількома сотнями кілобайт коду, історією тасок і логами проміжних спроб: місця все одно залишається достатньо, аби модель продовжувала адекватно орієнтуватися в проєкті.

Дешевий довгий контекст: ефект на інженерні звички

Окремий пласт дискусії стосувався вартості. MiniMax M3 інтегрується через токен‑плани, які дають дуже великий обсяг токенів за фіксовану суму. Після трьох повноцінних тестів — з вебдодатком, складним завданням на Rust і додаванням нової фічі у велику існуючу кодову базу — автор звернувся до дашборда й побачив, що “зараз не думаю, що я навіть використав 2% мого 5h hour limit, що просто insane”.

Це не абстрактне враження, а конкретний досвід: кілька важких сесій у IDE з численними інструментальними кроками, рендерами, тестами й тривалим аналізом великого репозиторію забрали лише невелику частину доступного ресурсу.

Звідси головний практичний висновок: “це означає, що я можу реально ганяти це і використовувати по максимуму, не хвилюючись про будь-які constraints, price тощо”. Замість постійного контролю ліміту й вимкнення agent‑режимів, щоб “не спалити бюджет”, модель можна тримати “розкрученою” годинами.

Такий ціновий профіль безпосередньо впливає на інженерні звички:

• вже не потрібно стискати промпти “до кісток”, викидаючи корисний контекст;
• не так страшно запускати довгі автономні агенти, які сотні разів сходять у файлову систему, тести чи браузер;
• можна дозволити собі підтримувати довгі історії в IDE‑чаті, не обнуляючи контекст щоразу, коли задача ускладнюється.

І в підсумку змінюється сама парадигма використання LLM: модель стає не одноразовим “запит-відповідь” сервісом, а постійним фоновим гравцем у розробницькому процесі, який не вимикається після перших 10–20 хвилин роботи.

Довгі dev‑цикли: коли повільніше, але глибше — краще

Порівняння з Composer 2.5, який у тестах стабільно працював значно швидше, додає ще один важливий штрих. MiniMax M3 програє за швидкістю, але компенсує це більш глибоким аналізом і готовністю “копатися” у задачі довше.

На тесті з трасуванням променів на Rust обидві моделі впоралися з завданням технічно: згенерували код, який компілюється й рендерить зображення. Проте детальний розбір виявив, що у виведеній Composer картинці були проблеми з орієнтацією та відображеннями — зображення довелося перевертати, а віддзеркалення об’єктів виглядали некоректно.

Версія MiniMax дала більш послідовний результат: правильну орієнтацію сцени, переконливі відображення й загалом більш “об’ємну” картинку. При цьому обсяг коду був схожим, але MiniMax знову витратила помітно більше часу, проходячи більше інструментальних кроків і проводячи детальніший аналіз.

Схожа картина повторилася на великій існуючій кодовій базі, де моделі мали додати нову фічу — “щоденний стрик” у дашборді студентів. Завдання вимагало попередньо розібратися в численних Python‑модулях бекенду та великому фронтенді на TypeScript, а потім внести зміни в різні файли та шари застосунку.

Composer завершив роботу значно швидше й додав мінімальний UI‑компонент, що відображав стрик. MiniMax витратила набагато більше часу: довше аналізувала репозиторій, робила більше змін і доповнила інтерфейс додатковими деталями, зокрема показником “best of” для серії днів. Знову спрацювала та сама логіка: модель використовує час, щоб ретельніше пропрацювати задачу в ширшому контексті, а не просто “закрити” її мінімальною функціональністю.

У підсумку сформулювали просте, але показове резюме: “для 90+% завдань ви будете в кращому становищі, використовуючи щось таке, бо це просто набагато дешевше і все одно робить роботу”. Не йдеться про абсолютну перевагу у всіх сценаріях — а саме про те, що в більшості повсякденних задач різниця в якості не виправдовує різницю в ціні з дорогими моделями, особливо коли мова про довгі, інструментально насичені dev‑цикли.

Коли обмеження відходять на другий план

Сукупність цих факторів — велетенське контекстне вікно, реальна здатність тримати довгі ланцюжки tool‑calls та наднизька вартість токенів — створює для розробників нову стартову точку.

Якщо надскладну, критичну задачу, де важлива кожна деталь, і надалі може бути сенс віддати дорожчій і потужнішій моделі, то для більшості рутинних або середньої складності робіт MiniMax M3 дозволяє просто не думати про обмеження. А коли розробник перестає постійно озиратися на ліміти, він починає користуватися моделлю інакше: довше тримає її “в курсі” про проєкт, частіше довіряє їй довгі автономні рини, не стискає промпти до рівня телеграми.

MiniMax M3 показує не стільки майбутнє “ідеальних” моделей, скільки майбутнє доступних, довгих AI‑сесій у розробці — коли ціна й контекст більше не диктують архітектуру робочого процесу.

Джерело

https://www.youtube.com/watch?v=da5nLxqbTxE

У подкасті The Pragmatic Engineer головний інженер Octopus Deploy Роберт Ерез, який понад десятиліття будує системи CI/CD і відповідає за розгортання у великомасштабних середовищах, детально розбирає одну з найболючіших тем продакшн‑інцидентів — «магічні ролбеки». Ба більше, він формулює позицію, яка суперечить звичним уявленням: зрілі команди взагалі намагаються не говорити про rollback і будують процеси так, ніби його не існує.

Мрія про кнопку rollback і реальність стану

Ерез визнає: запит на «великий червоний» ролбек‑батон звучить постійно. Клієнти приходять із простим запитом: якщо система вміє задеплоїти версію, чому не може так само просто відкотити її назад?

Це працює у дуже вузькому класі систем — там, де все справді статлес. Якщо немає стану, немає баз даних, немає збережених даних, які живуть довше, ніж процес застосунку, — відкат зводиться до заміни артефакта. У таких сценаріях GitOps чудово демонструє свою силу: є декларативний опис бажаного стану, робимо git revert, агенти знову приводять кластери до попередньої конфігурації, і на цьому історія закінчується.

Але, підкреслює Ерез, «реальність для більшості систем інша». У грі завжди є стан: бази даних, збережені сутності, інформація, яку «не можна просто взяти й відкотити». Саме тут і руйнується ілюзія універсального ролбеку.

Ключова проблема — схема БД. Типовий деплой змінює не тільки код, а й структуру даних. Якщо ми відкачуємо версію застосунку, але не повертаємо назад схему, отримуємо код, який розраховує на стару модель, але працює з новою: інші колонки, таблиці, індекси. Формально «деплой назад» відбувся, фактично — система в непередбачуваному стані.

Теоретично можна супроводжувати кожну міграцію «анти‑міграцією», яка здатна повернути схему назад. Практично це далеко не завжди можливо: складні зміни, втрати даних, конфліктуючі оновлення, дані, що вже живуть у новому форматі. Запит «зробіть кнопку ролбеку» в такій реальності перетворюється на небезпечну ілюзію контролю.

Показовий момент, на який звертає увагу Ерез: багато команд впевнено кажуть, що «регулярно роблять ролбеки», але при першому ж запитанні про відкат версії зі зміною схеми завмирають і раптом розуміють, що їм просто щастило — вони ще не в’їхали в глухий кут.

Від «відкотити» до «просунутися вперед»

Octopus Deploy цілеспрямовано відходить від поняття rollback у розмовах з клієнтами. Формулювання Ереза жорстке й однозначне: «ви маєте уникати розмов про roll back. Це завжди roll forward».

Логіка проста. Якщо в продакшні виявлено баг, найнадійніший шлях — якнайшвидше внести зміну, яка його виправляє, і задеплоїти цю зміну. Не повертати систему в минулий стан, а рухатися до наступного, кращого стану.

У цій парадигмі версії мисляться інакше. Якщо, умовно, версія 2 впала, «ролбеком» вважається не повернення до версії 1, а вихід на версію 3, де проблема вже виправлена. Саме це і є roll‑forward‑підхід: помилилися — виправили — швидко розгорнули нову, безпечнішу версію.

Тут критичну роль відіграє швидкість зворотного зв’язку та готовність процесу до хотфіксів. Команда має мати змогу вийти за рамки звичайного «довгого» циклу dev–staging–prod із погодженнями і формальностями, коли поспіху немає, і увімкнути прискорений шлях для критичного виправлення. У таких ситуаціях вузьким місцем стає вже не організація, а сама збірка: час, за який CI/CD проганяє пайплайн і видає нову версію.

Ерез визнає: якщо інцидент спричинений саме механізмом деплоймента або якимось кроком у процесі розгортання, час відновлення буде коротшим. Але при вадах бізнес‑логіки чи схем даних стратегічно безпечнішим виявляється саме рух уперед, а не спроба повернутися до «учора», коли продакшн уже в іншому стані.

Фічефлаги як справжній «ролбек» без ролбеку

В ідеальному світі, каже Ерез, відкот функціональності відбувається не через версії, а через фічефлаг. У цій моделі ми не змінюємо версію застосунку, не намагаємося повернути кодову базу у минуле — ми змінюємо шлях виконання всередині поточної версії.

Фічефлаг дозволяє тримати в одному релізі дві (або більше) гілки коду: стару, стабільну та нову, експериментальну. Перемикачем стає зовнішня конфігурація, що визначає, якою саме гілкою піде виконання: новим кодом користуються лише певні сегменти трафіку, окремі групи користувачів або взагалі ніхто, поки команда не буде готова.

Саме це вирішує кілька фундаментальних проблем, які роблять версійні ролбеки такими болючими.

По‑перше, узгодженість із схемою даних. Якщо зміни в БД проєктуються разом із новою кодовою гілкою, можна організувати код так, щоб кожна гілка була самодостатньою щодо поточного стану схеми. Умовно кажучи, незалежно від того, вмикаємо ми фічу чи вимикаємо, код, який працює зі схемою, очікує саме ту структуру, яка є в базі тут і зараз. Флаг не відмотує схему, він вибирає логіку, яка з нею коректно працює.

По‑друге, час реакції. Відкат через фічефлаг — це секунди. Не потрібно згортати середовище, перезнімати інстанси, чекати завершення деплоймента. Достатньо змінити значення флага в системі керування фічами — і новий (насправді старий, стабільний) шлях виконання починає застосовуватися миттєво. Це критично, коли інцидент трапляється в «2:00 ночі», а інженер у стресі намагається мінімізувати шкоду.

По‑третє, передбачуваність. Коли реліз фічі прив’язаний до викочування версії, команда змушена підлаштовуватися під час деплоймента: бути в онлайні, моніторити логі, слідкувати за метриками саме в момент, коли новий код фізично потрапляє у продакшн. Фічефлаги відокремлюють ці моменти. Код можна спокійно задеплоїти, скажімо, у понеділок, а фічу увімкнути у вівторок, коли команда в повному складі, все підготовлено, спостереження налаштовані.

І, нарешті, точність таргетингу. Класичні підходи на кшталт канарних деплойментів працюють з одиницею «версія застосунку»: разом виходить все, що було закомічено з попереднього релізу. Фічефлаг ж дозволяє вмикати й вимикати окремі зміни з дуже тонкими правилами — наприклад, лише для конкретної країни чи певного сегмента користувачів.

У цій картині світобудови фічефлаг і є тим «справжнім ролбеком», тільки реалізованим без відкату версій.

Як жити без ролбеку і не зламати собі процеси

Позиція «ролбеків не існує» звучить радикально, але в інтерпретації Ереза вона не про заборону, а про зміну мислення. Кілька ключових наслідків цього підходу вимальовуються прямо з його аргументів.

По‑перше, доводиться серйозніше ставитися до змін схеми даних. Якщо відкат «на версію назад» не розглядається як реалістична опція, команди мусять ретельніше планувати еволюцію БД, розбивати її на етапи, проєктувати міграції так, щоб кожен проміжний стан був життєздатним. Це підвищує вимоги до зрілості команд, але й різко знижує шанси на катастрофічні інциденти через невідкатну схему.

По‑друге, хотфікси перестають бути «винятковою подією» і стають повноцінним сценарієм життєвого циклу. Пайплайн має вміти швидко пропускати критичні виправлення, а команда — розуміти, де межа прийнятного ризику, коли можна скоротити формальні кроки заради швидкості відновлення.

По‑третє, важливо не плутати два різних інструменти: roll‑forward як спосіб руху між версіями й фічефлаги як спосіб оперативно керувати поведінкою системи всередині однієї версії. Вони доповнюють одне одного. Якщо загальний «злам» у версії — потрібен новий реліз. Якщо збій локалізовано у фічі — найшвидший «ролбек» пройде саме через вимкнення флага.

Зрештою, підхід, який описує Ерез, чесно визнає реалії сучасних систем. Там, де немає стану, відкот — це проста операція над артефактом. Там, де є бази даних, довгоживучі дані та складні міграції, сподівання на універсальну кнопку rollback — небезпечна омана. Замість шукати магічний батон, зрілі команди будують процеси довкола roll‑forward, хотфіксів і гнучкого керування функціональністю через фічефлаги — і вчаться завжди рухатися тільки вперед.

Джерело

CI/CD with Robert Erez — The Pragmatic Engineer

У подкасті The Pragmatic Engineer головний герой розмови — Роберт Еріз, principal engineer в Octopus Deploy і фахівець із CI/CD та систем розгортання. Ще на початку 2010‑х він відповідав за великомасштабні деплойменти у Skype, а останні роки проєктує процеси доставки ПЗ для сотень різних команд. На основі цього досвіду він доволі приземлено описує, як працює прогресивна доставка у реальних продуктах: від канарних релізів «на Нову Зеландію» до blue‑green і фічетоглів, які часто виявляються сильнішими за будь‑який сценарій з версіями.

Цей текст — самостійний розбір підходів до прогресивної доставки, без необхідності знати попередні частини розмови.

Від continuous delivery до progressive delivery

У класичній моделі continuous delivery основна мета — завжди мати зміни в стані «готові до деплою». Код регулярно інтегрується, проходить тести, автоматично потрапляє в dev, staging і, за рішенням команди чи за графіком, — у production. Реліз відбувається переважно «одним ударом»: нова версія потрапляє до всіх користувачів, як тільки її розгорнули.

Прогресивна доставка — наступний крок цієї еволюції. Її суть Еріз формулює як випуск змін «у більш контрольований спосіб», зазвичай через такі техніки, як канарні деплойменти. Ідеться не про інший тип CI/CD‑системи, а про усвідомлену стратегію зниження ризику в production: розгортати, спостерігати, поступово збільшувати охоплення, мати простий шлях «загальмувати».

У практиці це виливається у три основні підходи: канарні розгортання, blue‑green і фічетогли. Кожен має свою зону застосування, але в сучасних продуктових командах саме фічефлаги часто стають базовим інструментом.

Канарні деплойменти: чому Нову Зеландію обрали «тестовим» ринком

Один із найживіших прикладів прогресивної доставки з досвіду Еріза — деплойменти в Skype для web. Команда працювала у великій корпорації з усіма типовими атрибутами: дорадчі ради по змінах, формальне погодження релізів раз на тиждень, чіткі вікна деплойментів. Водночас інфраструктура вже тоді дозволяла «штовхати» новий код у production значно частіше.

Щоб розігнути цю бюрократичну пружину, команда фактично влаштувала собі власну continuous delivery‑схему з елементами прогресивної доставки. Зміни потрапляли у staging, проходили кілька рівнів тестів — і після цього розгорталися у production, але не одразу для всього світу.

Роль канарки виконувала Нова Зеландія. Саме ця країна стала «тестовою аудиторією» з кількох причин, які Еріз перераховує майже з посмішкою:

Нова Зеландія — перша країна значного розміру, що входить у новий день за часовим поясом. Це давало зручне вікно: коли в Європі й США ще ніч або глибокий вечір, у Новій Зеландії вже працюють користувачі, і команда може спостерігати за поведінкою системи.

Англомовна аудиторія спрощувала обробку багрепортів і звернень.

Ринок достатньо малий, щоб інциденти не перетворювалися на глобальну кризу, але водночас репрезентативний.

Технічно канарний деплоймент виглядає так: версія 2 сервісу запускається поруч із версією 1; мережевий рівень (traffic manager, load balancer) спрямовує невеликий відсоток трафіку на нову версію; далі частка поступово збільшується. Важлива умова — наявність зрілої спостережності: метрики, логи, алерти мають дозволити вчасно побачити проблеми й знизити частку трафіку або повністю повернутися до попередньої версії.

Мета канарних деплойментів — не в «красивій схемі», а в реальному випробуванні нової версії на живому трафіку в контрольованому сегменті. Новозеландський кейс показав Ерізу, наскільки потужною може бути така тактика, коли команда хоче рухатися швидше за формальні процеси, але не готова ризикувати всією глобальною аудиторією.

Blue‑green: дві версії поряд і миттєве перемикання

Ще одна популярна стратегія прогресивної доставки — blue‑green‑деплойменти. У цій моделі є два повноцінні середовища: одне (blue) обслуговує весь production‑трафік, друге (green) розгорнуте паралельно, але поки що «тіньове».

Нова версія застосунку розгортається у green‑середовищі. Команда має можливість:

перевірити працездатність;

прогнати додаткові тести;

провести ручну валідацію через прямий доступ (наприклад, за окремою IP‑адресою чи доменом).

Коли впевненість достатня, трафік просто перемикають з blue на green. Ззовні це виглядає як миттєве оновлення для всіх користувачів — фактично «канарка на 100%», але з попередньою ізольованою перевіркою.

Blue‑green особливо корисний там, де важливо уникати cold starts і довгого прогріву: нова версія вже «на ногах», прогріта, з ініціалізованими кешами чи іншими ресурсами. Це підхід про контроль і передбачуваність, але все одно його одиниця змін — цілий застосунок, а не окремі фічі.

Чому фічетогли часто сильніші за канарки

Попри симпатію до канарних і blue‑green‑деплойментів, Еріз доволі чітко формулює свою позицію: у більшості випадків «найкорисніша стратегія прогресивної доставки — це фічетогли». Тобто feature flags / feature toggles — незалежно від термінології.

Ключова відмінність — у «одиниці зміни». Для канарного чи будь‑якого версійного деплойменту нею є весь застосунок: якщо з моменту попереднього релізу було 20 комітів, канарний реліз тестує всі 20 одразу, а не тільки ту функцію, яку команда хотіла б контролювати. Це підвищує ризик: валідується пакет змін, а не конкретна можливість.

Фічетогли роблять одиницею зміни окремі гілки логіки — аж до «одиничних рядків коду». Решта системи залишається незмінною, і це радикально знижує площу ризику.

Гранулярність контролю — ще одна сильна сторона. Через фічетогли можна задати складні правила: вмикати фічу для користувачів певного ринку, типу акаунта чи поведінки (на кшталт «клієнти з Німеччини з певним продуктом у кошику»). Досягти подібної точності через мережеве роутинг‑правило значно складніше.

Нарешті, саме фічетогли дають найкращий досвід «ролбеку» у прогресивній доставці. Відкат канарного деплойменту зазвичай означає повний повернення до попередньої версії: це хвилини (або більше) на перекат, повний redeploy, пов’язаний із інфраструктурою та артефактами.

Фічефлаг вимикається за секунди — часто буквально натисканням кнопки в адмінці або API‑викликом. Зміна набирає чинності миттєво, без переінсталяції застосунку. Це повністю змінює психологію чергового та on‑call‑інженера: замість паніки й гарячих патчів достатньо «перекрити фічу», зупинити кровотечу і спокійно шукати причину.

Декуплінг деплою і релізу: головний бонус фічефлагів

Ще один аргумент Еріза на користь фічетоглів — те, як вони змінюють саму модель релізів. У версійній логіці деплой і реліз жорстко пов’язані: щойно нова версія задеплоєна, усі фічі в ній автоматично «в ефірі». Командам доводиться підлаштовуватись під часові вікна розгортання, координуватися з іншими командами, стежити за логами саме в цей момент.

З фічетоглами деплой і реліз розриваються в часі. Застосунок із новим кодом можна вивантажити в production у понеділок, але реальний запуск фічі зробити у вівторок вранці, коли команда онлайн, аналітика відкрита, а лог‑панелі під рукою. Можна навіть дати кільком людям з команди або обмеженому пулу користувачів ранній доступ, перш ніж поширювати зміни на всіх.

Це робить реліз продуктовою подією, а деплоймент — рутинною технічною операцією. Саме так Еріз описує «справжню користь» від фічетоглів: вони дозволяють керувати моментом і масштабом активації змін незалежно від того, коли й як ці зміни потрапили в production.

Де канарки й версійні деплойменти все одно незамінні

Попри прихильність до фічефлагів, Еріз не зводить прогресивну доставку лише до них. Він прямо зазначає: версійні деплойменти через канарки чи blue‑green залишаються дуже корисними, особливо для змін інфраструктури, де немає сенсу або можливості будувати фічетогл на рівні коду.

Це стосується, наприклад:

змін у конфігурації середовища;

оновлень компонентів платформи;

частини складних міграцій баз даних.

Особливо гостро питання постає навколо змін схеми БД. Саме вони, за спостереженнями Еріза, «велика проблема для будь‑якої прогресивної доставки» й місце, де багато команд стикаються з межами своїх підходів.

«Ролбеків не існує»: прогресивна доставка й рух лише вперед

Обговорюючи прогресивну доставку, Еріз неминуче переходить до теми ролбеків. Він помічає парадокс: багато команд говорять про ролбек як про стандартний інструмент безпеки, але варто запитати їх, що вони роблять у випадку зміни схеми бази даних, — і з’ясовується, що фактичного сценарію немає. У кращому разі їм просто «щастило» не натрапляти на критичні кейси.

На практиці для систем із суттєвим стейтом «магічний ролбек» майже ніколи не працює: код можна повернути, а дані — ні. Тому Еріз просуває іншу філософію: «уникати розмов про ролбек, думати лише про roll‑forward».

У цій моделі:

серйозний баг вирішується не поверненням до старої версії, а якомога швидшим хотфіксом — новою, кращою версією;

ланцюжок версій виглядає не як «2 → назад до 1», а як «2 → 3 з виправленням»;

фічетогли слугують «коротким шляхом» для зняття проблемної функції з бою, поки команда готує roll‑forward‑фікс.

Ця філософія напряму пов’язана з прогресивною доставкою: фічетогли дають швидкий важіль миттєво відкотити окрему можливість, а канарні й blue‑green‑схеми — зменшити кількість користувачів, які побачать проблему до того, як вийде виправлення.

Гігієна фічетоглів: сила, яка вимагає прибирання

Є й зворотний бік: фічефлаги легко розмножуються й накопичуються. Еріз прямо визнає, що навіть у команді Octopus Deploy є «застарілі» тогли, які давно мали би бути видалені. У великих продуктах це швидко перетворюється на борг: старі огороджуючі конструкції у коді, складні для розуміння гілки логіки, дублювання сценаріїв.

Щоб тримати цю систему під контролем, у Octopus поверх обраного SDK (вони використовують OpenFeature) побудували власний шар: кожен фічетогл має прив’язку до відповідної команди і «термін придатності». Коли дата минає, ніщо не ламається автоматично, але CI‑процеси можуть сповістити команду: цей тогл давно не мав би існувати, його час переглянути чи видалити.

Ідея не стільки в конкретній реалізації, скільки в принципі: якщо команда всерйоз покладається на фічетогли як фундамент інженерних практик, потрібно впроваджувати й системне «прополювання» — відслідковувати, коли тогл востаннє використовувався, коли був видалений із коду і коли конфігурація безпечно може бути очищена.

З чого почати команді, яка хоче перейти до прогресивної доставки

Еріз радить не чекати «ідеальної архітектури», а зробити перший невеликий крок. Для більшості команд це означає додати один фічетогл для реальної фічі, вивести її в production під контролем, подивитися на поведінку, а потім — вимкнути в разі потреби.

Перший досвід часто змінює ставлення до релізів. Поки немає тоглів, будь‑який баг у production — це набір неприємних питань: чи встигнемо швидко зібрати хотфікс, чи є вікно для деплою, як погодити це з іншими командами. Коли ж є можливість одним кліком забрати фічу з очей користувачів, ситуація з розряду «кризова» переходить у розряд «керована».

Далі питання лише в гігієні та балансі: додавати тогли там, де вони реально дають виграш, і системно їх прибирати після того, як фіча стала «частиною фону».

Висновок

Прогресивна доставка в інтерпретації Роберта Еріза — не про модні терміни чи догму певних інструментів. Це набір практик, які дозволяють командам відправляти зміни в production так само часто, як і раніше, але з меншим ризиком і більшим контролем.

Канарні деплойменти дозволяють вчитися на невеликій частині аудиторії — як це колись робили в Skype з Новою Зеландією. Blue‑green дає змогу перемикати весь трафік на нову версію лише після того, як вона пройшла ізольовану перевірку. А фічетогли забезпечують головне: дрібну одиницю змін, миттєвий відкат окремих фіч і можливість розвести в часі деплой і реліз.

Разом ці три підходи формують практичну відповідь на запитання: як випускати більше змін, не перетворюючи кожен реліз на лотерею. Для інженерів, які щодня живуть у CI/CD‑пайплайнах, це вже не «наступний тренд», а просто нормальна робоча практика, яка дає спати спокійніше вночі.

Джерело

CI/CD with Robert Erez — The Pragmatic Engineer