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

Один маркетолог замість 50: як організувати маркетинг як продукт

Протягом майже року в період найшвидшого зростання Anthropic весь маркетинг компанії тримав на собі один нетехнічний growth-спеціаліст: платний пошук, платні соцмережі, email-маркетинг і SEO. У більшості компаній це робота команди з 10–50 людей.

Ключ до такої продуктивності — не «просити ШІ написати текст», а будувати навколо Claude Code цілі робочі системи.

Figma-плагін для креативів: 30 хвилин роботи за 30 секунд

Перший приклад — Figma-плагін для генерації варіацій рекламних креативів. Нетехнічний маркетолог, який до цього навіть не відкривав термінал, за приблизно годину створив плагін, що:

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

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

Автоматизований Google Ads-копірайтинг із вбудованою експертизою

Другий робочий процес — генерація оголошень для Google Ads через кастомний Claude Skill для responsive search ads (RSA). Сценарій виглядає так:

1. Маркетолог вводить у Claude спеціальну команду /RSA.
2. Запускається заздалегідь налаштований workflow:
3. Claude запитує дані кампанії, наявні тексти, ключові слова.
4. Перехресно звіряє їх із низкою попередньо створених «skills»:
   • бренд-тон і голос Anthropic;
   • гайдлайни з точності опису продукту;
   • найкращі практики Google Ads.
5. На виході система генерує:
6. 15 заголовків;
7. 4 описи для кожного оголошення;
8. усе — в межах символів, дозволених Google.
9. Результат експортується у CSV, який можна одразу завантажити в Google Ads.

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

Юридичний відділ як набір мікроінструментів

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

Від «що може ШІ?» до «що ми більше не хочемо робити?»

Вихідна точка — не питання «як використати AI», а «яку роботу ми хотіли б ніколи більше не робити». Пайк описує свій біль так:

• багато дрібної, тактичної, але обов’язкової роботи;
• завдання, які відкладаються «на кінець дня», бо забирають час, але не потребують найкращого рівня експертизи.

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

Інструмент попереднього юридичного рев’ю в Slack

Перший і найпоказовіший інструмент — self-service перевірка маркетингових матеріалів, вбудована прямо в Slack:

1. Маркетолог вставляє текст лендингу, оголошення, email тощо в спеціальний інтерфейс.
2. Claude аналізує контент, звіряючи його з юридичними гайдлайнами Anthropic, які оформлені як окремий skill.
3. Система:
4. перевіряє права на логотипи;
5. звертає увагу на точність статистики;
6. стежить за коректним використанням торгових марок;
7. виявляє потенційно завищені або небезпечні формулювання (наприклад, «найбезпечніший ШІ на ринку»).
8. На основі аналізу інструмент:
9. присвоює рівень ризику (низький, середній, високий);
10. дає конкретні рекомендації, що виправити.

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

Ще три інструменти для юристів — і шість базових skills

Окрім маркетингового рев’ю, Пайк побудував ще три інструменти:

• для редлайнингу контрактів;
• для перевірки зовнішньої бізнес-активності;
• для оцінки впливу на конфіденційність (privacy impact assessments).

Усі вони спираються на шість ключових Claude Skills, які кодують юридичну експертизу в різних доменах:

1. маркетингове право;
2. конфіденційність;
3. трудове право;
4. комерційні питання;
5. корпоративне право;
6. продуктово-правові брифінги.

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

Високий ризик помилки — людський контроль обов’язковий

Юридична робота має високий «ризик помилки», тому Anthropic не віддає її повністю ШІ. Модель:

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

Такий підхід дозволяє:

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

Спільний патерн: спочатку кодифікувати експертизу, потім автоматизувати

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

1. Кодифікація знань

Перед тим як будувати будь-який інструмент, фахівці:

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

У маркетингу це виглядає як:

• чітко описаний тон бренду;
• критерії хорошого рекламного тексту;
• обмеження й вимоги платформи (Google Ads).

У юридичному напрямі — як:

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

2. Побудова мікроінструментів під конкретні болі

Далі створюються невеликі, вузько сфокусовані «мікротули», кожен з яких:

• вирішує одну чітку задачу (наприклад, Slack-повідомлення з юридичними зауваженнями);
• вбудовується в уже існуючий робочий процес (Figma, Google Ads, Slack);
• не намагається «замінити людину», а знімає з неї повторювану частину роботи.

Цей підхід можна застосувати й поза Anthropic. Наприклад, інженерна компанія, з якою працював автор, змогла:

• за дві години спільної роботи з експертом-інженером створити один Claude Skill для звітів за Local Law 97;
• скоротити час підготовки понад 80 звітів із тижнів до кількох годин;
• зняти потребу наймати додаткову людину під цей конкретний тип задач.

3. «AI в циклі», а не «людина в циклі»

Замість класичної моделі «людина допомагає ШІ» фактично формується протилежна:

• людина залишається носієм експертизи й фінальним арбітром;
• ШІ вбудовується в ті 80% процесу, які є повторюваними й формалізованими;
• найцінніші 20% — там, де потрібне судження, креативність, контекст — залишаються за фахівцем.

Як перенести цей підхід у власну роботу

Загальний рецепт, який випливає з кейсів Anthropic:

1. Обрати один повторюваний workflow, який ви робите щотижня й який виснажує, але не вимагає пікової концентрації.
2. Розписати його по кроках:
3. що становить 80% рутинних дій;
4. де саме потрібне ваше судження (критичні 20%).
5. Кодифікувати експертизу:
6. описати критерії якості;
7. зафіксувати правила, обмеження, тон, формат виходу.
8. Побудувати мікроінструмент:
9. максимально простий (навіть якщо це лише генерація чернетки або Slack-повідомлення);
10. вбудований у ваші поточні інструменти (документи, дизайн-системи, таск-трекери).
11. Залишитися в циклі:
12. дозволити ШІ виконувати 80% роботи;
13. зосередитися на перевірці, корекції й прийнятті рішень.

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

Джерело

• Відео: How Anthropic Employees ACTUALLY Use Claude Code

Сучасні компанії можуть мати «ідеально працюючі» дата-пайплайни, регулярні batch-запуски й красиві звіти — і водночас втрачати мільйони через затримку в лічені хвилини. На каналі Confluent Developer пояснюють, як застарілі підходи до обробки даних перетворюють бізнес-обіцянки на ризик, і чому індустрія масово переходить до потокової обробки та подієвої архітектури.

Коли 59 хвилин затримки руйнують бізнес-модель

Уявімо онлайн-рітейлера, який побудував бренд на обіцянці «доставка наступного дня». Логістика відпрацьована, платформа виглядає надійною — але в архітектурі ховається один елемент, який не відповідає реальності бізнесу: legacy batch-оновлення.

Сценарій простий:

• о 9:01 продається останній смартфон вартістю $1000;
• система продажів і система інвентаризації — різні, синхронізуються щогодини;
• до 10:00 сайт продовжує «думати», що товар є в наявності, й приймає сотні чи тисячі замовлень;
• кожне замовлення — це не лише $1000 потенційного повернення, а й обіцянка доставки наступного дня, яку виконати вже неможливо.

О 10:00 batch-джоб нарешті оновлює інвентар, і система «бачить правду». Далі — каскад проблем: скасування замовлень, термінове перенаправлення поставок з інших складів, додаткові витрати, компенсації, втрата довіри до ключової обіцянки бренду. Визначальна перевага («доставка наступного дня») перетворюється на зобов’язання, яке компанія системно порушує.

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

Подібні збої масштабуються разом із навантаженням. Показовий приклад — скандал навколо продажу квитків на Taylor Swift Eras Tour через Ticketmaster: мільйони користувачів, «історично безпрецедентний» попит, розсинхронізація інвентарю місць у кошиках і при оплаті, перевантаження системи, зупинка передпродажу, політичний та юридичний шлейф. Точні технічні причини там різні й не зводяться лише до batch-процесів, але кейс демонструє, як «невелика» невідповідність даних реальності стає критичною на великому масштабі.

Чому batch-процеси більше не відповідають реальності

Batch-оновлення історично були нормою в дата-інженерії. Walmart роками працював на batch-інвентаризації, перш ніж перейти до архітектури реального часу на основі event streaming. Щоб зрозуміти, чому цей перехід стає масовим, варто подивитися на бізнес без програмного коду.

Події як природна модель бізнесу

У фізичному магазині поведінка клієнта — це послідовність подій у реальному часі:

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

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

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

Це обмеження існує лише в софті й не має жодного сенсу в бізнес-домені. Воно з’явилося як компроміс епохи, коли:

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

У цифровому світі все навпаки:

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

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

Потокова обробка та Shift-Left Analytics: нова роль дата-інженера

Відповіддю на ці виклики стає перехід від накопичення даних у batch до їхньої організації в потоки подій і обробки в момент надходження. Це основа stream processing та подієвої архітектури (event-driven architecture), які реалізуються, зокрема, за допомогою Apache Kafka, Apache Flink та подібних платформ.

Як працює потокова модель

У сценарії з онлайн-рітейлером це виглядає так:

• о 9:01 відбувається продаж останнього гаджета;
• генерується подія product_sold і публікується в стрім;
• система інвентаризації підписана на ці події й одразу оновлює залишки;
• коли кількість товару стає нульовою, формується подія product_sold_out;
• сайт, підписаний на цей стрім, миттєво припиняє приймати замовлення на товар, якого вже немає.

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

Shift-Left Analytics: аналітика «зсувається вліво»

Традиційно дата-інженери будували batch-пайплайни, які:

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

З появою потокових платформ ці операції «зсуваються вліво» — ближче до джерела даних. Цей підхід отримав назву Shift-Left Analytics (або просто Shift Left) і означає:

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

Це дає три ключові переваги:

1. Мінімальна затримка
   Дані стають доступними одразу, без очікування «вікон» batch-обробки.

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

3. Менше дублювання
   Замість повторювати однакову логіку очищення й трансформації в різних batch-джобах, створюються повторно використовувані потокові «data products», які можуть споживати як аналітичні, так і операційні системи.

На цьому тлі змінюється й професійний профіль. Класичний дата-інженер, який будував batch-пайплайни для аналітики, еволюціонує в data stream engineer — фахівця, що створює реальні потокові дата-продукти для всього ландшафту систем, включно з операційними.

Від batch до стрімів: вирівнювання системи з реальністю

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

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

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

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

Джерело

The Hidden Cost of Batch Processing | Modern Data Engineering Pipelines — Confluent Developer

Попри вибухове зростання обсягів інформації, більшість компаній досі не вміють ефективно працювати з даними. Gartner оцінює втрати від низької якості даних у середньому в 12,9 млн доларів на рік для однієї організації, а інженери витрачають до 80% робочого часу на «прибирання» чужих помилок. Канал Confluent Developer розбирає, де саме в сучасних дата-пайплайнах ховаються ці втрати й які архітектурні компроміси визначають, чи стануть дані конкурентною перевагою, чи дорогим тягарем.

Життєвий цикл даних: чотири етапи та їхні пастки

Сучасна інженерія даних пропонує дивитися на дані як на безперервний життєвий цикл із чотирьох етапів:

1. Генерація
2. Інжестія (завантаження в пайплайн)
3. Трансформація
4. Сервінг (надання доступу споживачам)

На кожному з цих кроків доводиться робити вибір між зручністю, вартістю, швидкістю та якістю.

Генерація: чистити на джерелі чи «латати» потім

На етапі генерації дані з’являються в системі:
– кліки користувачів в e-commerce,
– показники IoT?сенсорів,
– логи застосунків, що фіксують поведінку користувачів.

Головна проблема тут — якість:
– користувачі вводять некоректні значення,
– сенсори дають збої,
– логи виявляються неповними.

Ключове рішення:
покращувати дані максимально близько до джерела чи миритися з «брудом» і чистити далі в пайплайні?

Аргументи на користь очищення на джерелі:

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

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

Інжестія: як реальний час перетворюється на батчі

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

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

Компроміс виглядає так:

• Батч-обробка
• простіше реалізувати;
• дозволяє ефективніше використовувати ресурси;

• але:

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

• Стрімінг у реальному часі

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

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

Трансформація: моноліт проти модульності

Третій етап — трансформація — це місце, де живе основна бізнес-логіка:

• агрегації,
• зміна структури даних,
• очищення та нормалізація значень.

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

Тут постає ще один архітектурний вибір:
монолітні чи модульні трансформації?

• Монолітний підхід
• простіше зрозуміти «кінець у кінець»;
• легше дебажити проблеми, що стосуються всього пайплайна;

• швидший старт для молодого бізнесу:

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

• Модульний підхід

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

У міру зростання бізнесу моноліт стає дедалі дорожчим:

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

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

Сервінг: реальний час проти зручності запитів

Фінальний етап — сервінг, коли дані стають доступними для людей і систем:

• сховища даних, дата-лейки, lakehouse?платформи
• зручні для аналітичних запитів;

• але зазвичай жертвують реальним часом;

• API

• дають контрольований програмний доступ;

• стрімінгові платформи на кшталт Apache Kafka

• зберігають реальний час;
• проте складніші для класичної аналітики й ad-hoc?запитів.

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

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

Критична асиметрія:
– реальний час завжди можна «приземлити» в статичне сховище для аналітики;
– але зі статичних батчів неможливо відновити справжній real-time.

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

Медальна архітектура: Bronze, Silver, Gold

Ще один спосіб мислити про пайплайн — так звана Medallion Architecture, що ділить його на три шари за аналогією з олімпійськими медалями:

1. Bronze — сирі дані
2. Silver — очищені та змодельовані
3. Gold — бізнес-орієнтовані агрегати

Bronze: страховка й джерело істини

Bronze?шар відповідає етапу інжестії:

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

Його цінність — у тому, що це «страхова копія» та джерело істини:

• можна перезапустити трансформації;
• додати нові кроки;
• виправити помилки в логіці, не втрачаючи оригіналу.

Silver: структурований фундамент

Silver?шар відповідає трансформації з чітким фокусом:

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

Компроміс:

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

Silver стає базовим шаром, на якому будуються і Gold?агрегати, і безпосередня аналітика.

Gold: інсайти замість деталізації

Gold?шар — це бізнес-готові дані:

• агреговані під конкретні сценарії;
• оптимізовані під запитання бізнесу й дашборди.

Головний компроміс:
втрачається деталізація в обмін на швидкість і зручність отримання інсайтів.

Для аналітики зазвичай використовують обидва шари:

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

ELT, ETL і роль медальної моделі

Medallion Architecture найкраще лягає на ELT?підхід:

• дані спочатку завантажуються в lakehouse (Bronze),
• а вже там трансформуються в Silver і Gold.

У класичних ETL?сценаріях (трансформація до завантаження) Bronze?шар може взагалі не існувати як окрема сутність — сирі дані не зберігаються в lakehouse.

Стрімінг проти батчів у контексті всієї архітектури

У батч?реалізаціях Bronze, Silver і Gold зазвичай — це статичні датасети в lakehouse:

• легко запускати SQL?запити;
• просто пояснювати структуру аналітикам;
• але немає справжнього real-time.

У стрімінгових реалізаціях кожен етап трансформації — це новий потік:

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

Чому все ж так важко зробити дані корисними

Складність не в тому, що бракує технологій — у відео згадуються Kafka, data warehouses, lakes, lakehouses, ETL/ELT?пайплайни, стрімінгові платформи. Проблема в ланцюжку компромісів на кожному етапі життєвого циклу:

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

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

Джерело

Why Is It So Hard to Make Data Useful? | Modern Data Engineering Pipelines — Confluent Developer

Аллі Міллер — одна з найвідоміших бізнес-експерток у сфері штучного інтелекту, колишня керівниця напрямів AI в IBM та AWS, радниця великих корпорацій і венчурних фондів. Вона не просто говорить про продуктивність з AI — вона живе в режимі, де приблизно сотня агентів працюють на неї цілодобово. Її особиста система включає 36 проактивних воркфлоу, які запускаються автоматично, поки вона спить, гуляє чи проводить зустрічі.

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

Від 20–30% до 2–10 разів продуктивніше: що змінилося з появою агентів

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

Сьогоднішня система Аллі базується на іншій парадигмі — агентному AI, який не просто генерує текст, а виконує делеговану роботу. Вона порівнює ці два стани досить жорстко. Старий підхід, де AI лише відповідає на запитання, давав відчуття додаткових 20–30% продуктивності. Натомість нинішня модель, де агенти беруть на себе цілі шматки процесів і керують багатогодинними воркфлоу, дає залежно від задачі від дворазового до десятиразового приросту ефективності.

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

36 воркфлоу, близько 100 агентів: як влаштована система

У центрі її підходу — 36 проактивних воркфлоу, які працюють постійно. Вони не чекають, поки їх попросять щось зробити; вони самі ініціюють дії за заданим графіком або тригерами. Над ними стоїть приблизно 28 «майстер-агентів» — це вищого рівня агенти, які керують підпроцесами. Кожен із них у середньому створює ще кілька субагентів, тож загалом система налічує близько сотні активних агентів.

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

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

Розклад замість ручних запитів: як працює автоматизація в Claude

Технічно вся ця система тримається на можливості планувати й запускати сценарії всередині різних режимів Claude. Міллер використовує одразу кілька інструментів Anthropic:

Claude Cowork — бізнес-орієнтовану агентну платформу, яка вміє працювати з локальними файлами, створювати документи на кшталт Google Docs і загалом виконувати дії, а не лише відповідати на запитання.

Claude X (у розмові згадується як окремий режим) — ще один контекст, де можна налаштовувати автоматичні процеси.

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

У кожному з цих середовищ можна задавати розклад: наприклад, щодня о 6:00 ранку запускати ранковий брифінг, щоп’ятниці — підсумковий аналіз пошти, щогодини — моніторинг певних джерел. Важливо, що користувачеві не потрібно писати код, щоб це налаштувати. Код, API-виклики та інтеграції існують, але «під капотом» — у вигляді готових конекторів до Gmail, Google Workspace, сервісів на кшталт Fireflies чи Granola.

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

Email як головна панель керування: чому результати приходять у папки

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

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

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

П’ятничний «рятувальний круг» для інбоксу: як агент розгрібає пошту

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

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

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

Технічно цей агент працює через інтеграцію Claude з Gmail та іншими елементами Google Workspace. Але з точки зору користувача все виглядає як ще один лист у спеціальній папці — з готовим планом дій щодо інбоксу.

Ранковий брифінг: новини, події та підготовка до зустрічей в одному листі

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

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

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

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

«Почніть зі скарги»: як Claude сам пропонує воркфлоу

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

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

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

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

«Запитай мене питання»: як Claude сам проєктує ваші сценарії

Ще один інструмент, який Міллер активно використовує, — вбудований у Claude Code скіл «ask user questions». Це готова функція, яка дозволяє моделі не просто відповідати, а проводити повноцінне інтерв’ю з користувачем, щоб спроєктувати потрібний воркфлоу.

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

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

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

Чотири режими доступу до Claude: від простого чату до керування браузером

Система Міллер спирається на те, що Claude існує не в одному, а в кількох режимах доступу, кожен із яких має свою роль.

Базовий рівень — веб-додаток Claude, знайомий більшості користувачів. Це середовище для одиничних чатів, де можна ставити запитання, отримувати відповіді, користуватися веб-браузингом, створювати проєкти й підключати готові конектори до Notion, Gmail та інших сервісів. Він добре підходить для пошуку й аналізу, але має обмежені можливості щодо активних дій.

Наступний рівень — Claude Cowork, орієнтований на бізнес-користувачів. Тут з’являється можливість працювати з локальними файлами на комп’ютері, створювати документи в Google Docs та виконувати інші дії, які виходять за межі «запитання?відповідь». Саме в цьому середовищі зручно будувати частину проактивних воркфлоу.

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

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

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

Без коду, але з API: як працюють інтеграції «під капотом»

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

Водночас це не означає, що коду немає. Щоб, наприклад, витягнути листи з Gmail, знайти файли в Google Workspace, отримати записи зустрічей із Fireflies чи Granola, Claude має звернутися до відповідних API, авторизуватися, зробити запити, обробити відповіді. Усе це — код, який виконується у фоновому режимі.

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

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

Висновок: як виглядає «норма» роботи з AI через рік

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

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

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

Джерело

Ex-Amazon AI Leader: In 1 Year, the Gap Between AI Users and Everyone Else Will Be Irreversible

Інструменти на кшталт Claude Code обіцяють «суперсили» навіть тим, хто ніколи не писав код. Але разом із цим з’являється новий клас помилок, які традиційні розробники добре відчувають, а новачки — ні. На основі порад із каналу Austin Marchese розбираємо три ключові пастки, у які масово потрапляють користувачі Claude Code, і практичні способи їх обійти.

1. Коли ШІ «вирішує не ту проблему»

Головна особливість будь-якої моделі — вона максимально швидко розв’язує саме те завдання, яке ви їй сформулювали. Не те, що ви «мали на увазі», а те, що буквально написали.

Симптоми: виправлений баг, але дані зламані

Уявімо застосунок, який показує баланс банківського рахунку та дозволяє перекази. На екрані — 1000 доларів, у банку — 900. Ви просите ШІ: «Виправ баланс, у мене 900». Модель просто змінює відображення на 900 — і формально все «правильно». Але першопричина зникнення 100 доларів так і не знайдена.

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

Як діяти: спочатку визначити, що таке «працює»

Щоб уникнути цього, варто запозичити підхід інженерних команд:

• Писати короткий product doc перед великими фічами.
  У ньому фіксується:
• що саме будується;
• навіщо це потрібно;

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

• Використовувати ШІ для виявлення «сліпих зон».
  Замість одразу просити «зроби мені фічу», корисно дати промпт на кшталт:
  – «Постав мені всі запитання, які потрібні, щоб чітко визначити, що таке “готова й робоча функція” в цьому випадку».

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

• Планувати перед кодом.
  У Claude Code є режим планування (plan mode), який можна ввімкнути через Shift+Tab. Досвідчені користувачі починають більшість сесій саме з плану й не дозволяють моделі писати жодного рядка коду, доки план не узгоджений.

Мінімальні доступи замість «повного контролю»

Другий ключовий принцип — мінімізувати права доступу ШІ:

• чітко розділяти read (читання) та read/write (читання й запис);
• давати тільки ті дозволи, які критично потрібні для задачі.

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

2. «Гра в крота»: коли один і той самий баг з’являється всюди

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

Як це виглядає на практиці

Є сайт із формою, де користувач вводить ім’я та email. Така форма використовується:

• під час реєстрації;
• у блоці «Зв’язатися з нами»;
• у процесі онбордингу.

Новачок у «vibe coding» часто створює три окремі форми, які виглядають однаково, але технічно це три різні шматки коду. В результаті:

• баг з’являється в реєстрації — ви його виправляєте;
• потім той самий баг вилазить у «Контактах» — виправляєте ще раз;
• потім — в онбордингу.

Причина проста: ви лагодите копії, а не єдине джерело істини.

Компоненти та змінні: базова дисципліна

У розробці це вирішується через:

• Компоненти — один раз створений елемент (наприклад, форма), який використовується в різних місцях. Виправлення в компоненті автоматично поширюється всюди, де він підключений.
• Змінні — дані, які зберігаються в одному місці й підтягуються в різні частини інтерфейсу.
  Наприклад, ім’я користувача, яке показується в шапці, профілі, налаштуваннях і листах, має братися з одного джерела. Зміна імені в одному місці оновлює його скрізь.

Корисно мислити так:

• компонент — це контейнер (форма, картка, кнопка);
• змінні — це вміст (ім’я, email, телефон).

Які промпти допомагають уникнути дублювання

Перед тим, як просити Claude Code створити щось нове, варто ставити моделі такі запитання:

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

Це дозволяє:

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

Глобальні налаштування замість «налаштувань у кожному проєкті»

Той самий принцип працює й для конфігурацій Claude Code:

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

Схема така:

1. У терміналі перейти в домашню директорію:
   cd ~
2. Створити/оновити там конфіг для Claude (наприклад, settings.json).
3. Ці глобальні налаштування автоматично застосовуватимуться до всіх підпроєктів.

Тоді зміни в одному місці поширюються на все середовище, а не налаштовуються вручну щоразу.

3. «Напівготове все»: коли прогрес — ілюзія

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

Аналогія з кредитними картками

Чим більше кредиток — тим більше можна витрачати. Але разом із цим зростає борг і відсотки. Так само й із фічами:

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

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

Чому маленькі продукти працюють краще

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

• роблять одну річ;
• роблять її добре;
• зрозумілі користувачам.

Приклади такого підходу:

• Резюме-скринер: завантажуєш резюме — отримуєш оцінку (ATS score). Проста функція, яка зібрала сотні тисяч переглядів і тисячі зацікавлених користувачів.
• real.ai: дивишся на зображення й вгадуєш, воно реальне чи згенероване ШІ. Одна дія, зрозумілий результат.
• Продукт Calorie AI: сфотографував їжу — отримав підрахунок калорій. Уся цінність — в одній чіткій можливості.

Спільне в цих кейсах — дуже вузький, чітко окреслений перший реліз.

Як обрізати зайве в першій версії

Перед додаванням будь-якої фічі варто чесно відповісти:

• «Чи обов’язково це має бути у версії 1?»
• «Чи може це спокійно поїхати у версію 2?»

Це просте запитання різко зменшує обсяг роботи й підвищує шанси довести продукт до робочого стану.

Дисципліна сесій у Claude Code

Ще одна форма «напівготовості» — хаос у сесіях:

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

Ефективніша стратегія:

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

Якщо кожне завдання зупиняється на 80%, це не прогрес, а накопичення боргу — та сама кредитна історія, тільки в коді.

Висновок: системність важливіша за «магію ШІ»

Claude Code та подібні інструменти справді знімають бар’єр входу в розробку. Але без базових інженерних принципів вони так само швидко створюють хаос:

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

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

Джерело

The Claude Code Trap (What You Don’t See That Programmers Do) — Austin Marchese

На початку 2026 року Google опублікувала наукову роботу, яка прозвучала як попередження для всієї криптоіндустрії: за оцінкою компанії, квантовий комп’ютер зможе зламати шифрування Bitcoin за дев’ять хвилин, причому використовуючи приблизно у 20 разів менше ресурсів, ніж вважалося раніше. Для світу, де трильйони доларів зберігаються під захистом публічних ключів, це не просто технічна деталь, а потенційний системний ризик.

Про масштаби цієї загрози говорить Джон Мартініс — фізик, чия демонстрація квантового тунелювання в макроскопічному електричному колі у 1985 році відкрила шлях до практичних кубітів і квантових комп’ютерів. За це відкриття він отримав Нобелівську премію, а нині входить до наукової ради президента США Дональда Трампа поруч із Марком Цукербергом, Сергієм Бріном та Дженсеном Хуангом. Мартініс оцінює, що на створення квантової машини, здатної зламати сучасну публічну криптографію, залишилося 5–10 років, і наполягає: за цей самий час увесь інтернет має перейти на квантово-стійкі протоколи.

Від «обчислення довше за вік Всесвіту» до дев’яти хвилин проти Bitcoin

Щоб зрозуміти, чому попередження про дев’ять хвилин для зламу Bitcoin звучить настільки тривожно, варто згадати ще один рубіж. У грудні 2024 року Google продемонструвала квантовий процесор, який виконав обчислення за лічені хвилини, тоді як найпотужнішим сучасним суперкомп’ютерам на це знадобилося б більше часу, ніж вік Всесвіту. Це не просто прискорення, а інший клас обчислювальної машини.

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

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

Старий Bitcoin як відкрита ціль: хто в зоні найбільшого ризику

Ключова теза Мартініса щодо криптовалют звучить просто: не всі монети однаково захищені від квантових атак. Особливо вразливими є старі схеми кодування, включно з ранніми версіями Bitcoin.

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

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

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

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

Як власники можуть захистити свої монети: «перепакування» в квантово-стійкі схеми

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

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

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

Такий підхід має кілька важливих наслідків.

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

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

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

Мертві гаманці як системний ризик: чому уряди вже цікавляться «загубленим» Bitcoin

Одне з найтривожніших спостережень Мартініса стосується саме таких «забутих» активів. Він зазначає, що в мережі Bitcoin накопичилася велика кількість старих, невитрачених монет, власники яких давно не проявляли активності. Частина з них належить людям, які втратили приватні ключі, померли або просто перестали цікавитися криптовалютою. Інша частина може бути пов’язана з ранніми майнерами чи великими гаманцями, які ніколи не рухали кошти.

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

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

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

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

Ахіллесова п’ята криптоіндустрії: коли нерегульоване зустрічається з надпотужним

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

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

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

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

П’ять–десять років на перезавантаження безпеки інтернету

Проблема, однак, не обмежується криптовалютами. Ті самі публічні криптографічні схеми, які захищають Bitcoin, лежать в основі безпеки майже всього інтернету — від HTTPS-з’єднань у браузері до VPN корпоративних мереж і оновлень програмного забезпечення.

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

Ця оцінка не унікальна. IBM, за словами Мартініса, озвучує подібні часові рамки. Генеральний директор Google публічно говорить навіть про агресивніший сценарій у 3–5 років. Водночас Google вже використовує квантово-стійкі протоколи принаймні для частини свого трафіку, що демонструє: великі гравці не чекають, поки загроза стане очевидною для всіх.

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

Мартініс підкреслює, що часові рамки для переходу й появи загрози майже збігаються. Якщо на повну міграцію піде 5–10 років, а квантовий комп’ютер, здатний зламувати публічні ключі, з’явиться в тому ж інтервалі, простору для помилок практично немає. Будь-яке зволікання збільшує період, коли старі, вразливі системи ще працюють, а нові атаки вже можливі.

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

Висновок: квантова ера як дедлайн для безпеки

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

Попередження про дев’ять хвилин для зламу Bitcoin і про 20-кратне зниження оцінених ресурсів — це не кінець історії, а її початок. Старі криптовалютні схеми, великі масиви невитраченого Bitcoin, нерегульовані сегменти фінансової системи, інтернет-протоколи, що не оновлювалися десятиліттями, — усе це має бути переосмислене в горизонті одного десятиліття.

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

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

Джерело

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

У великих технологічних компаніях процес підвищення часто виглядає непрозорим навіть для досвідчених інженерів. Інженерка №19 у WhatsApp Джин Лі в розмові на подкасті The Pragmatic Engineer пояснює, чому інтуїтивні уявлення про кар’єрне зростання в Big Tech часто не відповідають реальності — і що насправді впливає на рішення про промоушен.

Менеджер не «дає» підвищення — він лише ваш адвокат

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

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

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

Видимість роботи: чому про вас мають знати не лише в команді

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

У такій системі перевагу отримують ті, хто:

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

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

Як будувати кейс на підвищення в умовах Big Tech

З урахуванням цієї логіки, стратегія кар’єрного зростання в Big Tech змінюється:

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

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

Джерело

Подкаст The Pragmatic Engineer, епізод із Джин Лі: https://www.youtube.com/watch?v=arFszOVcecg

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

Саме його робота з квантового тунелювання в макроскопічних електричних колах запустила поле, яке через десятиліття привело до проривів Google у квантових процесорах. У грудні 2024 року компанія показала чип, що виконав обчислення за хвилини, тоді як сучасним суперкомп’ютерам на це знадобилося б більше часу, ніж існує Всесвіт. Тепер Мартініс намагається перетворити фундаментальну фізику на промислову платформу — з мільйонами кубітів і загальновживаними квантовими машинами.

Як «квантова стіна» стала машиною: експеримент 1985 року

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

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

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

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

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

Саме за цю демонстрацію квантового тунелювання в макроскопічному електричному колі Мартініс отримав Нобелівську премію. Його експерименти стали відправною точкою для цілого напряму — надпровідних квантових схем, які сьогодні лежать в основі більшості промислових квантових процесорів.

Від фундаменту до «вікна у Всесвіт»: як це привело до прориву Google

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

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

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

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

Цей результат часто порівнюють із першим польотом братів Райт: він не перевозив пасажирів через океан, але довів, що принципово новий тип машини працює. І в цьому сенсі лінія, що починається з тунелювання в макроскопічному колі 1985 року, тягнеться до квантового процесора Google 2024?го прямою науково?інженерною траєкторією.

Навіщо взагалі потрібні квантові комп’ютери: від молекул до ліків

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

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

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

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

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

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

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

Чому без кращих кубітів не буде трильйонного ринку

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

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

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

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

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

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

Ставка на надпровідні кубіти й напівпровідникові фабрики

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

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

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

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

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

Якщо це вдасться, надпровідні кубіти перестануть бути штучним лабораторним продуктом і стануть тим, чим стали транзистори в середині XX століття: стандартизованим, масовим будівельним блоком, який можна масштабувати від сотень до мільйонів екземплярів на одному чипі.

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

«Дефінітний оптиміст» у світі невизначених ставок

Щоб зрозуміти, як Мартініс мислить про майбутнє квантових технологій, він сам пропонує корисну рамку — з книги Пітера Тіля «Zero to One». Тіль ділить людей на «дефінітних» і «індефінітних» оптимістів. Перші мають чітке уявлення, що саме потрібно будувати, другі вірять у краще майбутнє, але не мають конкретного плану.

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

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

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

Від AI до квантового світу: чому «наступна хвиля» знову про залізо

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

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

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

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

Висновок: від лабораторного ефекту до інфраструктури майбутнього

За чотири десятиліття шлях Джона Мартініса пройшов від демонстрації квантового тунелювання в макроскопічному колі до спроби побудувати промислову квантову платформу. Його експерименти 1985 року довели, що квантова механіка може працювати в реальних електричних пристроях, а не лише в атомах. Це створило поле, з якого виросли кубіти й сучасні квантові комп’ютери.

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

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

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

Джерело

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

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

Робота з файлами: від обмежень до прямого доступу

У Claude Chat взаємодія з документами побудована навколо завантаження файлів у хмару. Це накладає два ключові обмеження:

• не більше 20 файлів в одній розмові;
• ліміт 30 МБ на кожен файл.

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

Claude Cowork працює інакше: він читає файли безпосередньо з комп’ютера користувача. Це означає:

• відсутність обмеження на кількість файлів;
• відсутність ліміту на розмір файлу.

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

Контекстне вікно: наскільки далеко «пам’ятає» ШІ

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

У Claude Chat контекстне вікно менше. Коли розмова затягується або в неї підвантажують багато матеріалів, система починає:

• «стискати» попередні повідомлення;
• втрачати деталі з ранніх етапів діалогу.

У результаті відповіді можуть ставати менш точними щодо початкових вимог або даних.

Claude Cowork має значно більший контекст, тож:

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

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

Формат результату: від текстової відповіді до готових файлів

Claude Chat повертає результат у вигляді тексту в чаті. Далі користувачеві потрібно:

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

Це зручно для швидких відповідей, але додає ручної роботи, коли йдеться про структуровані результати.

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

Показовий приклад — обробка понад сотні квитанцій. На основі цього масиву Claude Cowork:

• згенерував повний звіт про витрати у форматі Excel;
• додатково позначив рядки, які потребують уваги та перевірки.

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

Кому що підходить

З урахуванням цих трьох відмінностей можна окреслити базові сценарії використання:

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

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

Джерело

YouTube: #claude Chat vs. Cowork: Biggest 3 differences

Коли говорять про Duolingo, зазвичай мають на увазі вивчення мов, зелену сову й гейміфіковані вправи. Але сьогодні в додатку мільйони людей щодня вчаться не лише говорити іспанською чи англійською — близько семи мільйонів користувачів тренуються… грати в шахи. І цей курс став найшвидше зростаючим в історії компанії.

У розмові на каналі Silicon Valley Girl співзасновник і CEO Duolingo Луїс фон Ан розповів, як саме з’явився курс шахів, чому його зробили двоє людей без інженерного бекграунду і без знання самого предмета, та яку роль у цьому зіграли сучасні AI?інструменти. Ця історія — не просто анекдот про «магію ШІ», а показовий кейс того, як змінюється розробка освітніх продуктів і як великі компанії можуть відкривати шлях «знизу вгору» для нових ідей.

Від «це просто гра» до освітньої місії: як шахи потрапили в Duolingo

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

Двоє співробітників Duolingo, які самі хотіли навчитися грати в шахи, прийшли до Луїса фон Ана з пропозицією: додати шахи як новий курс у додатку. Це сталося приблизно за рік до того, як курс отримав «зелене світло». Першою реакцією CEO була відмова. Аргумент був простий і, на перший погляд, логічний: Duolingo — це освітній застосунок, а шахи — «просто гра».

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

Ця фраза стала поворотною. Шахи раптом перестали бути «просто грою» і перетворилися на інструмент розвитку логічного мислення — фундаментальної когнітивної навички, яка напряму пов’язана з освітою. Для фон Ана це стало аргументом, що шахи цілком вписуються в місію Duolingo.

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

«У нас немає для вас інженерів»: як обмеження штовхають до AI?рішень

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

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

У цій точці вступає в гру те, що в Duolingo називають «vibe coding» — підхід, коли люди без глибоких технічних навичок використовують AI?асистентів для створення прототипів, невеликих застосунків і внутрішніх інструментів. Компанія вже встигла зробити це частиною культури: проводила окремий день, коли кожен співробітник — від HR до фінансів — мав «завібкодити» щось своє, а в Slack працюють канали «best AI practices» та «AI fails», де діляться як успіхами, так і помилками.

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

Шість місяців на прототип: як AI перетворив двох співробітників на «команду продукту»

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

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

Далі почалося власне «vibe coding». Один із членів команди встановив Cursor — середовище розробки з вбудованим AI?асистентом, яке дозволяє писати код у тісній співпраці з моделлю. На перших порах вони зосередилися на створенні шахових задач. Це логічний вибір: задачі — базовий будівельний блок навчання шахам, що дозволяє тренувати конкретні тактичні й стратегічні патерни.

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

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

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

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

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

Від прототипу до продакшну: де закінчується «vibe coding» і починається інженерія

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

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

Це розділення ролей — ще один важливий урок. AI?асистенти й «vibe coding» чудово підходять для швидкого пошуку продукт?маркет фіту, створення MVP і тестування гіпотез. Але коли йдеться про продакшн?рівень, де продуктом користуються мільйони людей щодня, класична інженерія нікуди не зникає.

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

Шахи як тест на масштаб: сім мільйонів DAU і нова роль AI в EdTech

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

Це досягнення варто розглядати в кількох площинах.

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

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

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

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

Що ця історія означає для майбутнього роботи й продуктів

Курс шахів у Duolingo — це не лише про конкретний продукт. Це про зміну парадигми того, хто й як може створювати складні цифрові сервіси.

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

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

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

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

Висновок: шахи як пролог до нової ери освітніх продуктів

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

Це не історія про те, що «ШІ зробив усе сам». Це історія про те, як ШІ змінив ролі в команді, прискорив цикл від ідеї до прототипу, дозволив bottom?up?ініціативі прорватися в ядро продукту й водночас не скасував потребу в професійній інженерії на фінальному етапі.

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

Джерело

Duolingo CEO: You Only Need 2 People and 6 Months to Build the Next Big Product

Коли засновник Duolingo Луїс фон Ан (Luis von Ahn) говорить про штучний інтелект, у нього немає ані технооптимістичного пафосу, ані апокаліптичних прогнозів. У розмові на каналі Silicon Valley Girl він описує дуже приземлену картину: AI вже глибоко вбудований у роботу компанії, але щоразу впирається в межі якості, надійності та людського судження.

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

Шахи як полігон для AI: від сирих задач до тренованої моделі

Новий курс з шахів у Duolingo став показовим кейсом того, як AI може бути одночасно рушієм інновацій і джерелом дуже конкретних проблем якості.

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

Це «якось» виявилося глибоким зануренням у AI?інструменти. Один із ініціаторів мав базові технічні навички, і команда пішла шляхом так званого vibe coding — коли людина з мінімальним досвідом програмування використовує AI?асистентів, щоб швидко збирати прототипи. Вони встановили Cursor — редактор коду з вбудованими моделями — і почали з найочевиднішого: генерації шахових задач.

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

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

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

Далі команда зосередилася на мобільному досвіді. Вони знову і знову збирали прототипи інтерфейсу, ігрових сценаріїв, уроків — і показували їх Луїсу фон Ану. Лише коли він, як CEO і головний «редактор» продукту, вирішив, що курс достатньо якісний, шахи отримали місце в основному застосунку.

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

AI?кодинг: швидкий старт, болісний дебаг і чому інженери все ще незамінні

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

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

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

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

Це особливо помітно в освітньому застосунку масштабу Duolingo, де будь?яка помилка може вплинути на мільйони користувачів. Коли йдеться про продакшн?код, компанія не може дозволити собі покладатися на «мабуть, воно працює» від моделі. Дебаг AI?згенерованого коду часто виявляється настільки трудомістким, що вигода від швидкого старту нівелюється.

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

Масове генерування контенту: чому більшість AI?історій не доходить до користувача

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

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

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

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

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

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

Людське судження як останній фільтр: від мобільних прототипів до дорожньої карти предметів

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

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

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

Однак попри цю свободу експериментів, Duolingo свідомо обмежує фокус. Зараз компанія концентрується на чотирьох напрямах: мови, математика, музика й шахи. Ідеї на кшталт K–12 science чи курсу з малювання залишаються в довгостроковому списку бажань, але не переходять у стадію активної розробки.

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

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

Культура експериментів з AI: від «обов’язкового» використання до здорового скепсису

Внутрішня культура Duolingo навколо AI теж пройшла помітну еволюцію. Компанія активно заохочує співробітників експериментувати: проводила день, коли кожен — від HR до фінансів — мав щось «завібкодити», підтримує Slack?канали з найкращими AI?практиками й окремий канал «AI fails», де діляться невдалими кейсами.

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

Водночас спроба формалізувати використання AI через систему оцінювання продуктивності виявилася невдалою. Коли Duolingo тимчасово включив «AI?продвинутость» у performance review, співробітники почали ставити логічне запитання: чи очікує від них керівництво використання AI «заради галочки», навіть там, де це не додає цінності?

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

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

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

Майбутнє AI в освіті: менше магії, більше ремесла

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

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

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

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

По?четверте, культура використання AI виявляється не менш важливою, ніж самі моделі. Там, де AI стає обов’язковою «галочкою» в performance review, він перетворюється на бюрократичний тягар. Там, де AI?помилки обговорюються відкрито, а успішні кейси поширюються горизонтально, інструменти природно вбудовуються в роботу.

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

І поки Duolingo зосереджується на шахах, математиці, музиці й мовах, а мрії про K–12 science та курси з малювання залишає на майбутнє, головний урок виглядає так: AI уже може допомогти створити «наступний великий продукт» за шість місяців і двома людьми. Але зробити його справді хорошим — усе ще завдання для людей.

Джерело

Duolingo CEO: You Only Need 2 People and 6 Months to Build the Next Big Product — Silicon Valley Girl

У розмові з YouTube-каналом Silicon Valley Girl співзасновник і CEO Duolingo Луїс фон Ан розкрив, як компанія інтегрує штучний інтелект не лише в продукт, а й у щоденну роботу співробітників. Мова йде не про черговий «AI-маніфест», а про досить приземлену, але послідовну культуру: від внутрішнього «золотого правила» до обов’язкового дня vibe coding для всієї компанії, Slack-каналів з провалами та саморобних дашбордів KPI.

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

Золоте правило Duolingo: AI тільки якщо виграє учень

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

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

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

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

Це створює помітний контраст із компаніями, де штучний інтелект стає новою метрикою лояльності: «доводь, що ти достатньо AI-native, інакше відстанеш». У Duolingo AI — це інструмент, а не культ.

День загального vibe coding: коли HR і фінанси теж пишуть код

Один із найяскравіших елементів AI?культури Duolingo — це спеціальний день, коли буквально кожен співробітник мав «vibe code» щось своє. Не лише інженери, а й люди з HR, фінансів та інших нефахових з точки зору розробки команд.

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

Такий формат вирішує одразу кілька завдань.

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

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

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

Важливо, що цей день не був одноразовим шоу заради піару. Він став логічним продовженням загальної лінії: зробити AI?інструменти настільки буденними, щоб ними користувалися всі, а не лише вузьке коло ентузіастів.

Slack-канали «best AI practices» і «AI fails»: як нормалізувати помилки

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

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

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

Така відкритість має кілька наслідків.

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

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

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

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

Саморобні дашборди й міні-додатки: як AI розширює повноваження «нетехнарів»

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

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

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

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

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

Коли AI стає метрикою: чому Duolingo відмовився від «обов’язкового AI» у performance review

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

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

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

Цей епізод важливий із кількох причин.

По?перше, він показує, наскільки легко навіть прогресивні компанії можуть скотитися до AI?формалізму: коли технологія стає не інструментом, а KPI. Включення AI до performance review виглядає логічним кроком, але на практиці швидко створює перекоси.

По?друге, реакція Duolingo демонструє готовність коригувати курс. Компанія не стала наполягати на своєму, а визнала, що такий підхід більше шкодить, ніж допомагає. Це рідкісний випадок, коли AI-політика змінюється не під тиском зовнішньої критики, а завдяки внутрішньому діалогу.

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

Як ця культура впливає на продукт: від мов до шахів

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

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

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

Важливо, що навіть із такими успіхами Duolingo не кидається додавати десятки нових предметів. Компанія свідомо обмежує фокус: мови, математика, музика, шахи. Це ще один прояв обережного підходу до AI?експансії: технологія дозволяє рухатися швидко, але стратегія вимагає рухатися вибірково.

Висновок: AI як інфраструктура, а не як ідеологія

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

внутрішнє «золоте правило», яке змушує кожне AI?рішення виправдовувати себе перед користувачем, а не перед трендами;
відмова від формального обліку «AI-заміщуваних» задач, щоб не перетворювати технологію на інструмент тиску;
масовий день vibe coding, що знімає бар’єр між технічними й нетехнічними ролями;
Slack-канали, де успіхи й провали з AI стають колективним досвідом, а не приватною історією;
готовність відкотити рішення про включення AI до performance review, коли воно починає стимулювати використання «для галочки».

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

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

Джерело

Duolingo CEO: You Only Need 2 People and 6 Months to Build the Next Big Product