На початку 2000-х Blizzard уже встигла перетворитися на студію, чиї назви Warcraft, StarCraft і Diablo звучали як окремий жанр. Але всередині це ще була невелика команда менш ніж із двох сотень людей, які працювали в кампусі Університету Каліфорнії в Ірвайні, спали на футоні в офісі й кидали фрізбі між мітингами. Саме в цю атмосферу в травні 2002 року потрапив Джефф Каплан — майбутній креативний директор World of Warcraft та Overwatch, а нині співзасновник студії Kintsugiyama.

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

Острів антикультури в кампусі університету

Офіс Blizzard на початку 2000-х розташовувався в дослідницькому парку UC Irvine — поруч із Cisco та іншими типовими «серйозними» технокомпаніями. На під’їзді все виглядало максимально корпоративно, поки погляд не впирався в єдину аномалію: групу людей у чорних футболках і шортах, які грали у фрізбі, Hacky Sack, каталися на скейтбордах і самокатах.

Це й була Blizzard.

Всередині офіс більше нагадував студентський гуртожиток, ніж штаб-квартиру студії, яка вже створила Warcraft I та II, працювала над Warcraft III і розвивала StarCraft. Стіни були завішані постерами, у кімнатах стояли футон-ліжка — люди реально ночували на роботі, коли дедлайни стискалися до небезпечних масштабів. Але це не була токсична «культура перегорання» в сучасному розумінні. Радше — фанатична відданість спільній справі, коли розробники добровільно вкладали в гру все, що мали.

На момент приходу Каплана в компанії працювало менше ніж 200 людей, і це разом із Blizzard North у Сан-Матео, яка відповідала за Diablo. Південний офіс в Ірвайні, Blizzard South, робив StarCraft і Warcraft. У межах Blizzard South існували лише дві команди розробки — Team One і Team Two, і між ними вже тоді формувалася внутрішня міфологія.

Team One була «золотою дитиною» студії — RTS-команда, яка створила Warcraft II та StarCraft і в той момент працювала над Warcraft III. Їхня репутація всередині компанії була майже культовою. Team Two, навпаки, вважали «пасинком» — до приходу Каплана кілька спроб розгорнути другу повноцінну команду провалилися. Спочатку Team Two працювала над проєктом під кодовою назвою Nomad, але його скасували, а керівник студії Аллен Адемо (Allen Adham) розвернув команду в бік нового, на той час ризикованого задуму — World of Warcraft.

Саме в цю «другу» команду й потрапив Каплан.

Від EverQuest до World of Warcraft: коли розробники фанатіють одне від одного

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

Технічну групу Team Two очолював Джон Кеш — програміст, відомий за роботою в id Software та навіть як ігровий персонаж у Quake III. Коли Каплан прийшов у Blizzard, йому сказали: «Іди до Джона Кеша, він видасть тобі логін». Для нього це було як зустріч із рок-зіркою.

Ситуація виявилася дзеркальною. Кеш виявився завзятим гравцем EverQuest і впізнав у Каплані людину, яка керувала одним із найвідоміших рейдових гільдій того часу — Legacy of Steel. Вони буквально «зафанбоїли» одне одного: один — легендарний програміст із id, інший — харизматичний лідер топ-гільдії в EverQuest.

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

Саме в цій атмосфері зароджувався World of Warcraft. Ключовими дизайнерами Team Two тоді були Ерік Доддс і Кевін Джордан. Доддс згодом стане геймдиректором Hearthstone, але вже тоді він разом із Джорданом формував базові системи WoW. Поруч працювала технічна команда Кеша, а до команди поступово приєднувалися нові люди, яких Blizzard могла собі дозволити обирати з найкращих у галузі.

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

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

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

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

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

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

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

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

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

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

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

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

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

Сила малих команд: гучний голос замість «гвинтика в машині»

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

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

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

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

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

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

Культура довіри: наймай найкращих і стався до них відповідно

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

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

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

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

Висновок: як «дорм-рум із фрізбі» задав стандарт індустрії

Рання Blizzard була парадоксом: зовні — компанія в університетському кампусі з людьми в чорних футболках, які грають у Hacky Sack перед входом; всередині — одна з найструктурованіших і найамбітніших студій свого часу, яка вже тоді формувала нові стандарти для жанрів RTS і MMO.

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

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

Джерело

Lex Fridman Podcast #493 — Jeff Kaplan: World of Warcraft, Overwatch, Blizzard, and Future of Gaming

Коли йдеться про Blizzard, зазвичай згадують тріумфи: World of Warcraft, Overwatch, Diablo. Але один із найважливіших уроків студії народився не з успіху, а з масштабного провалу — амбітного MMO-проєкту Titan, який розробляли сім років і закрили, витративши десятки мільйонів доларів.

У розмові з Лексом Фрідманом колишній провідний геймдизайнер Blizzard Джефф Каплан, який керував WoW і став обличчям Overwatch, детально розбирає, чому Titan так і не став «MMO, що завершить еру MMO», і які управлінські та продуктові уроки з цього має винести індустрія.

Мрія про «наступний WoW»: як народжувався Titan

Початок історії Titan — це не стільки креативний порив, скільки стратегічний страх. На піку успіху World of Warcraft всередині Blizzard панувало переконання, що WoW не триватиме вічно. У студії припускали, що гра протримається приблизно п’ять років, а потім «постаріє» — і компанія опиниться в небезпечній залежності від одного продукту.

Щоб уникнути цього, ще близько 2005–2006 року в офісі почали серйозно обговорювати потребу в «наступному великому MMO». Паралельно команда працювала над доповненням Burning Crusade, але паралельно вже збиралися перші зустрічі з умовною назвою Titan. Керівництво доручило старт розробки Робу Пардо, одному з ключових дизайнерів Blizzard.

Повноцінна робота розгорнулася приблизно у 2007 році. Першим співробітником Titan став програміст Джон ЛаФлер, який узявся за новий рушій з нуля. Це вже був сигнал масштабу амбіцій: замість того, щоб розвивати перевірені технології, студія вирішила створити все заново — і технологію, і IP, і команду.

Концепція Titan виглядала як мрія геймера, який любить і MMO, і шутери, і життєві симулятори. Дія мала розгортатися на Землі майбутнього. Гравець — секретний агент, який живе подвійним життям.

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

Денна частина гри надихалася Animal Crossing, Harvest Moon та The Sims. До команди запросили Мета Брауна, колишнього креативного директора The Sims, щоб вибудувати глибокі соціальні та побутові механіки: будівництво будинку, життя в районі, управління бізнесом.

Паралельно на технічному рівні ставили ще одну надзадачу: на відміну від «шардованого» WoW, де гравці розподілені по різних серверах, Titan мав стати «одним світом на одному сервері» для всіх.

Цей світ планували зробити гігантським. У студії вже будували «Bay City» — версію Сан-Франциско, Голлівуд, простір між ними, а також Каїр, Лондон та інші міста. У грі мали бути повноцінні автомобілі та їзда в стилі GTA.

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

Коли віз тягне коня: новий рушій, новий IP і відсутність правил світу

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

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

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

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

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

Для великого MMO це смертельно: гравець має відчувати єдиний світ, а не колекцію розрізнених зон.

Паралельно розробка рушія буксувала. Внутрішній редактор Titan Edit (TED), який сьогодні використовується в Overwatch, тоді працював настільки нестабільно, що технічний художник Ділан Джонс у 40-годинний робочий тиждень міг реально працювати в інструменті лише близько 20 годин. Решту часу забирали падіння, очікування, технічні проблеми.

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

Коли ідей забагато, а бачення немає: лідерство, що не змогло сказати «ні»

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

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

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

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

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

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

Художня — відсутність єдиного стилю, що робило гру візуально розмитою.

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

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

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

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

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

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

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

Окремий пласт провалу Titan — це управління командою та найм.

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

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

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

Реальність виявлялася шокуючою. Людина приїжджала, умовно, з Бельгії, очікуючи, можливо, «World of StarCraft» або щось подібне, а натомість бачила проєкт без чіткої ідентичності, де навіть базові питання сетингу не вирішені.

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

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

Фінансовий масштаб проблеми теж був значним: за роки розробки Titan коштував Blizzard близько 83 мільйонів доларів. Для великої компанії це не смертельний удар, але це серйозний сигнал про те, що система управління портфелем проєктів дає збій.

Коли чесність дорожча за інерцію: момент, коли треба було зупинитися

Найбільш показовий момент у цій історії — не технічний, а управлінський.

Каплан згадує, що вже приблизно у 2009 році він внутрішньо розумів: у поточному вигляді Titan ніколи не вийде. До 2010 року він неодноразово намагався донести це до керівництва.

Він пішов до тодішнього CEO Blizzard Майка Морхайма з прямим посланням: «Вам потрібно нас закрити. Ми просто будемо спалювати гроші».

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

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

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

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

У випадку Blizzard, попри затримку, закриття Titan виявилося стратегічно правильним кроком. Воно звільнило ресурси — і людські, і технологічні — для створення Overwatch, який став одним із найуспішніших нових IP компанії за останні десятиліття.

Уроки Titan: фокус, маленькі команди й дисципліна «ні»

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

Порівняння Titan і Overwatch — це, по суті, порівняння двох підходів до розробки.

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

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

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

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

Для індустрії з цього випливають кілька практичних висновків.

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

По-друге, новий рушій, новий IP і новий жанровий мікс — це три великі ризики. Братися за всі три одночасно можна лише за наявності надзвичайно сильної, консолідованої візії та досвіду.

По-третє, культура «казати ні» — не менш важлива, ніж культура креативності. Ідеї нескінченні, але ресурси — ні.

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

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

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

Висновок: провал як інвестиція в майбутнє

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

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

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

Джерело

Lex Fridman Podcast #493 — Jeff Kaplan: World of Warcraft, Overwatch, Blizzard, and Future of Gaming

Коли легендарний геймдизайнер Blizzard Джефф Каплан сьогодні згадує про Overwatch, це звучить як історія успіху: одна з найвпливовіших ігор десятиліття, новий стандарт командних шутерів, мільйони фанатів. Але точкою старту для Overwatch став не тріумф, а один із найболючіших провалів Blizzard — скасування амбітного MMO-проєкту Titan.

У розмові з Лексом Фрідманом Каплан детально розклав по поличках, як із руїн Titan за лічені тижні народилася концепція Overwatch, чому перші дві ідеї — StarCraft Frontiers та CrossWorlds — так і не стали реальністю, і як правильне управління масштабом перетворює мрію на гру, яку реально зробити.

Крах Titan: деморалізована команда і «неможливий» ультиматум

Titan мав стати наступним великим MMO Blizzard після World of Warcraft. Команда налічувала понад 140 людей, роки розробки, величезні очікування. Коли проєкт скасували, це був не просто бізнес-рішення, а особиста драма для розробників.

Каплан згадує атмосферу тих днів як «найбільш деморалізовану» за всю свою кар’єру. Він не був упевнений навіть у власному майбутньому в компанії — чи не стане провал Titan кінцем його шляху в Blizzard. На цьому тлі керівництво ухвалює доленосне рішення: більшу частину команди розподіляють по інших проєктах — Heroes of the Storm, доповнення до Diablo III, World of Warcraft, Hearthstone.

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

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

1. Вийде за два роки.
2. Має потенціал приносити дохід рівня World of Warcraft.

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

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

Три шанси на порятунок: як організували шість тижнів

Маленька команда отримала шість тижнів і три ідеї, які потрібно було перетворити на повноцінні пітчі: StarCraft MMO, нове IP під назвою CrossWorlds і ще один, поки безіменний проєкт, який згодом стане Overwatch.

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

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

Усередині цих двох тижнів діяли ще дві важливі установки. По-перше, у фазі брейншторму команда мала мислити масштабно: «Що буде по-справжньому неймовірним? Чого хочуть гравці? Яка головна фантазія, яку має втілити гра?» Це один із ключових дизайн-принципів Blizzard — «What is the fantasy?».

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

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

StarCraft Frontiers: гра, у яку всі хотіли б пограти, але ніхто не міг зробити за два роки

Першою ідеєю став StarCraft MMO під робочою назвою StarCraft Frontiers. На папері це виглядало як мрія фанатів: нарешті зануритися у всесвіт StarCraft не як командир армії, а як окремий герой.

Ключова відмінність від класичного StarCraft полягала саме в перспективі. RTS-версія — це завжди три раси, масові битви, тисячі юнітів. World of Warcraft свого часу відрізнявся від Warcraft тим, що замість «одного з багатьох» гравець ставав окремим авантюристом, який залишає власний слід у світі. Frontiers мав зробити те саме для StarCraft.

Натхненням став старий малюнок креативного директора Blizzard Кріса Метцена — космічний старатель, самотній шукач ресурсів десь на краю галактики. Уявіть собі: десь далеко гримлять грандіозні битви між Зергами, Протосами й Терранами, а на забутій планеті один-єдиний персонаж спускається в загадкові підземелля, шукає мінерали й натрапляє на монстрів. Це не солдат у строю — це «Індіана Джонс у космосі».

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

Пізніше саме цей образ переродиться в іншого героя — ковбоя МакКрі з Overwatch. Але тоді він був візуальним серцем StarCraft Frontiers.

За два тижні команда встигла зробити набагато більше, ніж просто красиву картинку. Було продумано дизайн світу, класи, прогресію, навіть приблизне бачення того, як працюватимуть доповнення та лайв-контент. Це був не сирий ескіз, а повноцінний пітч великого MMO.

Проблема була в іншому: у нього не було шляху до реальності.

Навіть у найоптимістичнішому сценарії, за оцінкою Каплана, StarCraft Frontiers вимагав би щонайменше п’яти років розробки, 150–200 людей і відсутності серйозних проблем по дорозі. Для Blizzard це реалістична планка для MMO. Для сорока людей із дедлайном у два роки — ні.

До того ж всесвіт StarCraft був створений під RTS, а не під MMO. Потрібно було б переосмислити планети, логіку переміщення між ними, структуру контенту. Окремий пласт — космічні перельоти. Зробити їх просто кат-сценами — швидко, але гравці цього не пробачать. Зробити повноцінний космічний геймплей — додати ще кілька років розробки. І як зробити «космічну гру без космічного польоту», коли всі знають, як виглядають такі компроміси?

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

CrossWorlds: космічний «Мос-Айслі» як платформа для майбутніх світів

Друга ідея — CrossWorlds — народилася з іншого типу амбіцій. Якщо Frontiers був насамперед грою, то CrossWorlds був передусім всесвітом.

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

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

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

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

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

Але, як і у випадку зі StarCraft Frontiers, постало питання масштабу. Чи можна створити переконливий, густонаселений, візуально багатий космічний порт, наповнений історіями, за два роки й силами невеликої команди? Чи не ризикуєш отримати «недоварений» світ, який не дотягує до планки Blizzard?

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

Як Overwatch став тим самим «баченням, а не просто ідеєю»

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

На відміну від двох попередніх, Overwatch не намагався бути черговим гігантським MMO. Це був перехід до іншого жанру, з іншим масштабом і зовсім іншими вимогами до контенту. Там, де StarCraft Frontiers і CrossWorlds вимагали створення величезних світів, Overwatch концентрувався на компактних аренах, чітких ролях і яскравих героях.

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

Показово, що навіть у цій історії Overwatch не виник «з нуля». Образ космічного старателя, який став МакКрі, — прямий місток від StarCraft Frontiers. Досвід побудови великих світів Titan і двох скасованих концепцій теж не зник: він перетворився на розуміння, як зробити компактний, але відчутно «великий» за відчуттями всесвіт, де кожен герой несе за собою натяк на ширшу історію.

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

Там, де StarCraft Frontiers і CrossWorlds залишалися чудовими, але надто великими ідеями, Overwatch став баченням: конкретною, здійсненною відповіддю на виклик «два роки, маленька команда, але Blizzard-якість».

Уроки Overwatch: хто насправді має «різати» мрію

Історія шести тижнів після Titan — це не лише сюжет про народження Overwatch. Це ще й концентрований урок про те, як у великих студіях мають ухвалюватися творчі рішення.

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

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

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

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

Overwatch став саме такою формою. Він не відмовився від амбіцій — просто переніс їх із масштабу світу на глибину героїв і бою.

Висновок: провал як найкращий ґрунт для великої гри

Скасування Titan могло стати для Blizzard травмою, після якої команда розсипається, а таланти розходяться по інших студіях. Натомість воно стало відправною точкою для однієї з найуспішніших ігор компанії.

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

StarCraft Frontiers і CrossWorlds залишилися в минулому як «ігри, у які всі хотіли б пограти». Overwatch став грою, у яку мільйони людей справді пограли. Різниця між ними — у наявності не лише ідеї, а й бачення: чіткого, приземленого плану, як перетворити мрію на продукт.

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

Джерело

Jeff Kaplan: World of Warcraft, Overwatch, Blizzard, and Future of Gaming | Lex Fridman Podcast #493

У новому проєкті Tech With Tim показано не просто «черговий скрепер», а повноцінну продакшн‑архітектуру для великомасштабного збору цін з Amazon у різних країнах. Одна з найцікавіших частин цієї системи — AI‑шар поверх історичних даних, який дозволяє ставити запитання на кшталт «Яка ціна iPad?» і отримувати відповідь не з живого сайту, а з власної бази, наповненої скрепером.

Цей матеріал розбирає саме цю AI‑надбудову: як поєднуються MongoDB, Qdrant, OpenAI та LangChain, чому дані зберігаються одразу у двох різних сховищах і як це перетворює звичайний скрепер на інструмент аналітики для e‑commerce.

Від «скрипта на вихідні» до AI‑шару над історичними даними

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

Система збирає інформацію про товари з Amazon у різних країнах, порівнює ціни для одного й того ж ASIN і зберігає результати. Користувач може через інтерфейс ввести ASIN, обрати країни (США, Канада, Велика Британія, Франція, Іспанія, Австралія, Японія, ОАЕ тощо) і отримати таблицю з цінами та додатковими атрибутами. Є окрема вкладка для візуального порівняння товарів, які присутні одразу в кількох регіонах.

Але ключова інновація — не в UI, а в тому, що над усім цим збудовано AI‑чат. Замість того, щоб писати SQL‑запити або вручну фільтрувати таблиці, користувач може просто запитати: «What is the price of an iPad?» і отримати відповідь, сформовану на основі вже зібраної бази. Це не «пошук по сайту Amazon», а запит до власного сховища scraped‑даних, яке система підтримує та оновлює.

Щоб це працювало, архітектура розділяє ролі між кількома компонентами:

MongoDB — основне джерело істини для структурованих даних про товари.

Qdrant — локальна векторна база для семантичного пошуку по тим самим товарам.

OpenAI — генератор ембедингів і LLM‑модель, яка формує відповіді.

LangChain — «клей», що збирає все це в агента з інструментами.

MongoDB як джерело істини: чому класична база все ще критична

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

Коли скрепер успішно витягує сторінку товару, він парсить HTML (через Beautiful Soup) і формує структурований запис: назва, бренд, ціна, валюта, категорії, країна, ASIN та інші атрибути. Цей запис потрапляє в MongoDB і залишається там як історичний факт. Якщо товар оновлюється або скрепер запускається повторно, система може зберігати нові «зрізи» даних, формуючи часовий ряд цін.

Такий підхід вирішує кілька задач одночасно.

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

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

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

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

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

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

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

Таким чином, кожен товар існує у двох формах:

як структурований документ у MongoDB;

як вектор у Qdrant, що відображає його семантичний зміст.

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

Такий підхід дозволяє знаходити товари навіть тоді, коли формулювання запиту не збігається з точними назвами в базі. Наприклад, запит «cheap Apple tablet» може привести до того самого iPad, навіть якщо в назві товару немає слова «cheap», а в базі він зберігається як «Apple iPad 10.2‑inch (9th Generation)».

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

OpenAI та LangChain: як зібрати агента з інструментами

Щоб перетворити MongoDB і Qdrant на єдиний інтелектуальний шар, система використовує LangChain — фреймворк для побудови LLM‑агентів. У цій архітектурі LangChain виступає як диспетчер, що дає моделі набір інструментів і навчає її, коли і як ними користуватися.

Набір інструментів агента включає три основні можливості.

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

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

По‑третє, інструмент для виклику скрепера Amazon. Якщо в базі немає потрібних даних або вони застарілі, агент може ініціювати новий скрепінг через бекенд, який у свою чергу використовує проксі Thor Data та Beautiful Soup. Це дозволяє поєднати історичні дані з можливістю оновлення в реальному часі, хоча ключовий акцент саме на роботі з уже зібраною історією.

OpenAI у цій схемі виконує дві ролі.

Перша — генерація ембедингів для товарів і запитів, які потім потрапляють у Qdrant.

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

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

Як працює запит користувача: від фрази до конкретної ціни

Щоб зрозуміти, як усі ці компоненти взаємодіють, варто розкласти типовий сценарій запиту на кроки. Наприклад, користувач у чаті вводить: «What is the price of an iPad?».

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

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

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

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

Чому історичні scraped‑дані мають жити під AI‑шаром

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

Система спроєктована так, що все, що колись було зібрано скрепером, залишається доступним для запитів через AI‑агента. Це означає, що:

аналітик може повернутися до даних за минулі місяці й порівняти динаміку цін без необхідності піднімати старі CSV;

бізнес може ставити запитання природною мовою, не думаючи про структуру бази, назви полів чи формат дат;

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

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

Важливо й те, що AI‑шар не замінює класичні інструменти аналітики, а доповнює їх. Ті самі дані можуть одночасно використовуватися в SQL‑звітах, BI‑дашбордах і в AI‑чаті. MongoDB забезпечує стабільне зберігання, Qdrant — семантичний пошук, OpenAI — інтелектуальну інтерпретацію запитів, а LangChain — координацію всього процесу.

Висновок: скрепінг як основа для власних доменних AI‑систем

Проєкт Amazon Price Scraper у виконанні Tech With Tim показує, як змінюється роль скрепінгу в епоху LLM. Замість того щоб бути разовим інструментом для отримання таблиці, він стає джерелом даних для власної доменної AI‑системи.

Зберігаючи scraped‑продукти в MongoDB як основне джерело істини, паралельно вбудовуючи їх у Qdrant, використовуючи OpenAI для ембедингів і відповідей, а LangChain — для побудови агента з інструментами, архітектура перетворює «сирі» HTML‑сторінки Amazon на запитувану вільною мовою базу знань про товари й ціни.

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

Джерело

How to Design a Production-Grade System in Python — Tech With Tim

Open‑source проєкт Paperclip, який його творець Dotta описує як «human control plane for AI labor», пропонує не просто набір агентів на базі LLM, а повноцінну інфраструктуру для керування «штатом» штучних співробітників. Його позиціонують як оркестратор для zero‑human компаній, де бізнес‑процеси виконують десятки й сотні агентів — від CEO до кодерів, маркетологів і QA.

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

Скіли як нова «інфраструктура компетенцій» для агентів

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

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

Показовий приклад — робота з відео. Для створення ролика, що святкує 40 000 GitHub‑зірок Paperclip, у системі було використано скіл Remotion best practices. Remotion — open‑source інструмент для генерації відео на базі React, і замість того, щоб щоразу пояснювати агенту, як правильно з ним працювати, ці знання було винесено в окремий скіл.

Організаційний рівень тут критичний: CEO‑агент у Paperclip вміє самостійно «наймати» нових агентів і встановлювати їм потрібні скіли. У сценарії з відео CEO створив роль video writer, підключив їй Remotion best practices і передав завдання. Далі агент уже працював як спеціалізований відео‑продюсер, а не як «чиста» LLM.

Цей підхід дозволяє кодувати доменну експертизу безпосередньо в агентів. Наприклад, можна створити Paperclip‑специфічний скіл, який включає бренд‑гайд, візуальний стиль, типову тривалість кадрів, тональність тексту. З часом, аналізуючи фідбек, який люди дають агентам (наприклад, що всі зрізи у відео мають бути по 2 секунди, а не по 6), ці патерни можна винести в окремий скіл і зробити їх частиною «корпоративної пам’яті» для всіх відео‑агентів.

Таким чином, skills.sh і вбудований менеджер скілів у Paperclip перетворюють розрізнені інструкції на централізовану систему компетенцій, яку легко масштабувати на всю організацію агентів.

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

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

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

У випадку з Remotion‑відео це виглядало так: людина задала короткий промпт на кшталт «подивися на дашборд зі статистикою, сплануй відео для святкування 40 000 зірок». Агент не почав одразу генерувати код чи сторіборд, а спершу створив план. Людина швидко переглянула його, внесла корекції — наприклад, скоротити тривалість кадрів до 2 секунд, змінити акценти анімації — і лише після цього агент перейшов до реалізації.

Такий поділ «планування» і «виконання» дає кілька важливих ефектів.

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

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

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

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

Друга лінія оборони: QA‑агенти, браузерний скіл і ланцюжки «виконавець–рев’юер–апрувер»

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

Paperclip вводить окрему роль QA‑агента, який може автоматично підключатися до завдань як рев’юер. Цей агент зазвичай оснащений спеціальним браузерним скілом — agent browser skill. Він дозволяє відкривати сайти, заповнювати форми, натискати кнопки та виконувати інші дії у веб‑інтерфейсі.

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

У Paperclip завдання можуть бути сконфігуровані так, що їх не можна завершити без рев’ю з боку QA‑агента. Система дозволяє задавати вимогу «потрібен рев’юер» і, за потреби, ще й окремий «апрувер».

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

Важливий момент: Paperclip задуманий як вендорно‑нейтральний оркестратор. У реальних сценаріях команди часто працюють із різними моделями — Codex, Claude, Gemini, Hermes, Pi, OpenAI‑моделями через OpenRouter тощо. Кожна з них має свої «звички» й обмеження, а інтеграції на кшталт веб‑хуків реалізуються по‑різному. Paperclip пропонує єдиний «каркас» для побудови таких ланцюжків незалежно від того, яка саме модель стоїть за конкретним агентом.

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

Рутини як «операційний автопілот»: від changelog’ів до PR‑оглядів

Окрім разових завдань, у будь‑якій організації є величезний пласт повторюваних процесів: щоденні дайджести, оновлення changelog’ів, підготовка підсумків по pull request’ах, формування повідомлень у Discord чи Slack.

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

Наприклад, можна створити рутину, яка щодня формує повідомлення в Discord про все, що було вмерджено в master‑гілку, і паралельно генерує текст релізного changelog’а. Або рутину, яка обробляє конкретний GitHub‑pull request: аналізує зміни, формує резюме, перевіряє відповідність стилю коду.

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

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

Рутини не існують у вакуумі — вони можуть використовувати скіли. Якщо в організації вже є скіл для роботи з PR, його можна підключити до рутини, щоб не дублювати логіку. У випадку Paperclip як open‑source проєкту в рутинах використовується, зокрема, інтеграція з Greptile — зовнішнім інструментом для першого проходу код‑рев’ю GitHub‑pull request’ів.

Сценарій виглядає так: після створення PR запускається рутина, яка, серед іншого, викликає Greptile‑скіл. Той звертається до GitHub, аналізує зміни, формує відгук і повертає його в контекст Paperclip. Далі вже інші агенти або люди можуть доповнити цей огляд, але перший, базовий рівень аналізу виконано автоматично.

Таким чином, рутини в Paperclip працюють як операційний автопілот: вони перетворюють розрізнені «одноразові» промпти на стабільні, повторювані процеси, які легко масштабувати й комбінувати з іншими елементами системи — скілами, QA‑агентами, планами.

Від коду до маркетингу: як доменна експертиза вшивається в агентів

Хоча приклади з PR‑оглядами й Greptile показують силу Paperclip у розробницьких сценаріях, сам проєкт із самого початку позиціонується як загальний бізнес‑оркестратор, а не суто інструмент для коду.

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

Скіли дозволяють кодувати доменну експертизу: бренд‑гайди, tone of voice, правила роботи з конкретними інструментами (від Remotion до CRM‑систем). Плани дають змогу структурувати кампанії, контент‑серії, сценарії відео. QA‑агенти можуть перевіряти, чи відповідає контент бренду, чи коректно працюють лендинги, чи правильно налаштовані форми збору лідів.

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

Ключовий момент у тому, що Paperclip не намагається «зробити все сам». Замість цього він виступає як шар оркестрації, який поєднує різні моделі (через OpenRouter та інші інтерфейси), зовнішні сервіси на кшталт Greptile і внутрішні скіли організації в єдину систему.

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

Висновок: від «чату з моделлю» до керованої AI‑організації

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

формалізовані скіли як носії компетенцій, які можна перевикористовувати й поширювати між агентами;

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

QA‑агентів із браузерними скілами та ланцюжками «виконавець–рев’юер–апрувер», які додають другу й третю лінію захисту якості;

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

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

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

Джерело

Paperclip: Open Source Human Control Plane for AI Labor — Dotta Bippa

Коли говорять про легендарних дизайнерів Blizzard, ім’я Джеффа Каплана зазвичай згадують у контексті World of Warcraft та Overwatch. Але до того, як опинитися в офісі в Ірвайні, він був просто одержимим гравцем EverQuest під ніком Tigole — відомим рейд-лідером і нещадним критиком розробників. Його шлях до Blizzard — це історія про онлайн-спільноту, приховану ідентичність геймера, випадкові (на перший погляд) знайомства та дуже нетиповий для індустрії спосіб найму.

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

Гільдія як школа лідерства: як EverQuest змінив траєкторію життя

Початок історії — не в офісі Blizzard, а в гільдії Legacy of Steel на сервері Nameless в EverQuest. Це була одна з так званих «убер-гільдій» — топових рейдових колективів, які першими проходили найскладніший контент. Каплан грав під ніком Tigole і вже тоді був помітною фігурою в спільноті: жорсткі, подекуди токсичні, але завжди конкретні тиради на адресу розробників зробили його відомим. Він не просто «говорив, що все погано», а пропонував детальні рішення — як переробити рейди, баланс, механіки.

Коли засновник гільдії з ніком Dread пішов, Legacy of Steel опинилася в підвішеному стані. Новим лідером стала гравчиня під ніком Ariel — «блондиниста» ельфійка-воїн, яка принципово не носила шолом, щоб не закривати обличчя персонажа. Вона зробила Tigole офіцером, асистентом лідера та рейд-лідером.

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

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

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

Редактор на диску: як аматорські рівні Half-Life стали портфоліо

Паралельно з EverQuest у житті Каплана з’являється ще одна важлива лінія — аматорський левел-дизайн. Епоха Half-Life та Duke Nukem принесла з собою одну принципову річ: разом із грою на диску постачався редактор рівнів. Для допитливих гравців це був прямий вхід у світ розробки.

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

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

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

«Ariel з Ірвайна»: коли гільдія виявляється Blizzard

Запит на Half-Life-рівні від Ariel супроводжувався ще однією несподіванкою. Після того як Каплан відправив диск, гільдійний лідер зізнався: його звати Роб, він — дизайнер у Blizzard Entertainment, а адреса в Ірвайні — це не випадковий офіс, а штаб-квартира студії.

Більше того, він знав, що Tigole живе в Пасадені, бо той писав на гільдійному сайті про місцеві події на кшталт Rose Parade. Виявилося, що між Пасаденою та Ірвайном — година їзди, і Роб запропонував: приїхати в гості до Blizzard, подивитися студію і заодно познайомитися з іншими гільдійцями, які теж там працюють.

Для Каплана це було дивним і трохи тривожним досвідом. На той час знайомитися з людьми з інтернету в реальному житті було нетипово й навіть небезпечно. Він не був фанатом Blizzard: через обмежений бюджет просто не купував усі ігри підряд і ніколи не грав у Warcraft, StarCraft чи Diablo. Його світ тоді обертався навколо Half-Life, Quake, Quake III та EverQuest.

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

На місці виявилося, що за ніком Ariel ховається Роб Пардо — на той момент головний дизайнер Warcraft III. За іншими нікнеймами з гільдії — ще кілька співробітників Blizzard: зокрема, Скотт Мерсер (енчантер Dalomin) та Роман Кенні, який грав психованого мага.

Замість формальної екскурсії по студії — звичайний обід у ресторані в Ірвайні. Але саме він став для Каплана переломним моментом.

«Вперше відчув себе собою»: вихід із геймерського «підпілля»

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

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

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

Після цього обіду були ще зустрічі, ще поїздки до Ірвайна, ще розмови про ігри. Для Каплана це виглядало як природне продовження дружби, що почалася в EverQuest. Він не сприймав це як «серію співбесід», хоча саме так усе й виглядало з боку Blizzard.

Один із найяскравіших епізодів цієї гільдійно-Blizzard-історії пов’язаний із персонажем на ім’я Barfa — тролем-воїном, який грав у Legacy of Steel не надто регулярно, але мав «інсайдерський» статус. Під час проходження нового на той час підземелля The Hole рейд провалився, усі ледве вибралися, а Barfa застряг у виході: модель троля була настільки великою, що він фізично не міг вистрибнути.

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

На одному з обідів у Ірвайні Роб Пардо представив Каплану ще одного колегу: «Це Аллен Едхем. Він грає за Barfa». Аллен виявився не просто співробітником, а співзасновником Blizzard і фактичним головою студії разом із Майком Морхаймом і Френком Пірсом. Сцена, де творець компанії дякує гравцеві за те, що той «врятував його троля в The Hole», виглядає майже символічною: віртуальні вчинки раптом отримують дуже реальну вагу.

«Перевір завтра сайт вакансій Blizzard»: як гільдійні обіди перетворилися на офіційний найм

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

На той момент студія вже анонсувала World of Warcraft. На сайті з’явилася нова позиція — associate quest designer, молодший дизайнер квестів для WoW. В описі вакансії була деталь, яка виглядала майже як персональне звернення: серед вимог або бажаних якостей значилася наявність диплома з креативного письма. Саме такий ступінь мав Каплан.

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

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

Тому співбесіди були жорсткими. Каплан зустрічався з ключовими фігурами Blizzard, серед яких — Кріс Метцен, головний креативний драйвер всесвітів Warcraft, StarCraft і Diablo. Одна з інтерв’ю-сесій виглядала як «парне інтерв’ю»: тихий, недооцінений дизайнер Kevin Jordan, який стояв біля витоків класового дизайну та PvP у WoW, і харизматичний Метцен, який «захоплює кімнату» однією лише присутністю.

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

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

Що ця історія говорить про майбутніх геймдизайнерів

Історія найму Джеффа Каплана в Blizzard важлива не лише як анекдот про те, як рейд-лідер EverQuest став дизайнером World of Warcraft. Вона показує кілька глибинних тенденцій, актуальних і сьогодні.

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

По-друге, онлайн-спільноти можуть стати реальним професійним ліфтом. Legacy of Steel була не просто гільдією, а соціальною мережею до появи соцмереж. Усередині неї перетиналися гравці, які виявилися співробітниками Blizzard, включно із засновником компанії. Випадковий вчинок — віддати дорогий еліксир тролю Barfa — виявився жестом, який запам’ятався людині, що ухвалювала стратегічні рішення в студії.

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

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

Висновок: коли «говорити про драконів» стає професією

Шлях Джеффа Каплана до Blizzard почався не з резюме, надісланого на загальну пошту, а з нічних рейдів у EverQuest, жорстких, але чесних постів на форумах і аматорських рівнів для Half-Life, записаних на CD. Він пройшов через гільдійне лідерство, випадкові (на перший погляд) знайомства, обіди в Ірвайні, де вперше можна було не соромитися того, що ігри — це не просто хобі, а частина особистості.

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

А для самого Каплана це був момент, коли «легендарний троль EverQuest» перетворився на людину, яка допоможе створити World of Warcraft — гру, що назавжди змінить уявлення про онлайн-світи, в яких рейд-лідери більше не мусять приховувати, ким вони є насправді.

Джерело

Jeff Kaplan: World of Warcraft, Overwatch, Blizzard, and Future of Gaming | Lex Fridman Podcast #493

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

Чи існував Рагнар насправді?

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

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

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

Ідеальний вікінг: багатство, слава і честь у бою

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

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

Франкські джерела пов’язують його з нападом на Париж 845 року, коли вікінги під проводом Рагнара піднялися Сеною і змусили короля Карла Лисого заплатити величезний викуп — близько 7 тисяч фунтів срібла. Така сума не лише збагатила ватажка, а й фактично підірвала авторитет самого короля.

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

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

Так Рагнар продовжує рейди вже проти Англії, де, за переказами, діє близько 15 років.

Смерть у ямі зі зміями та кривавий орел

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

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

«Коли вепр стече кров’ю, поросята прийдуть».

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

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

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

Родина, що стала династією: Аслауг і сини

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

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

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

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

Цей епізод підкреслює, що від жінок у скандинавському суспільстві очікували не лише краси, а й кмітливості. Пара Рагнар–Аслауг у саговій традиції — «ідеальний союз», що поєднує воїнську славу й інтелект.

Їм приписують 12 синів, серед яких — Івар Безкістий та Бйорн Залізнобокий. На відміну від самого Рагнара, ці постаті фігурують у джерелах як реальні ватажки великих вікінзьких сил, що діяли в Англії, нападали на ісламську Іспанію та здійснювали рейди по всій Європі.

Між сагами, серіалами й фрагментами історії

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

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

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

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

Джерело

Lex Clips — Ragnar Lothbrok: The Legendary Viking Warrior explained by Historian | Lars Brownworth

У новому технічному розборі на каналі Tech With Tim показано, як на практиці виглядає продакшн‑рівень система для масового збору цін з Amazon у різних країнах. Йдеться не про черговий «скрипт на 50 рядків», а про інфраструктуру, яка вміє працювати безперервно, масштабуватися по регіонах, зберігати історичні дані й давати до них доступ через AI‑шар. Ключовий елемент цієї системи — надійний веб‑скрейпінг без браузерної автоматизації, побудований на HTTP‑запитах, мережі резидентних проксі Thor Data та HTML‑парсері Beautiful Soup.

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

Чому масштабний скрейпінг Amazon — це вже не «просто код»

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

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

У розглянутій системі завдання сформульовано чітко: потрібно порівнювати ціни одного й того ж товару (за ASIN) на різних локалізованих доменах Amazon — від США й Канади до Франції, Іспанії, Австралії, Японії та ОАЕ. Для цього скрейпер має:

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

Саме тут у гру входить резидентна проксі‑мережа Thor Data та класичний HTML‑парсинг через Beautiful Soup, які дозволяють обійтися без Selenium чи Playwright і водночас працювати на продакшн‑масштабах.

Thor Data як основа геоспецифічного скрейпінгу Amazon

Навіщо резидентні проксі, а не «рандомний» дата‑центр

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

У цій системі використовується Thor Data як резидентна проксі‑мережа. Її завдання — зробити трафік максимально схожим на реальних користувачів: запити йдуть з IP‑адрес, прив’язаних до звичайних підключень у різних країнах, а не з очевидних дата‑центрів. За словами автора проєкту, без такого рівня інфраструктури реалізувати подібний скрейпер на масштабі було б просто неможливо.

Thor Data, згідно з відео, надає понад 60 мільйонів IP‑адрес у більш ніж 190 країнах. Для задачі порівняння цін це означає, що практично будь‑який локальний домен Amazon — від .com до .fr, .es, .ae чи .co.jp — можна опитувати з «правильної» геолокації, не боячись масових блокувань.

Як конфігуруються проксі Thor Data

Щоб інтегрувати Thor Data в Python‑скрейпер, кожен запит до Amazon проходить через проксі‑сервер, налаштований з конкретними параметрами. Конфігурація включає:

• ім’я користувача та пароль — для автентифікації в мережі Thor Data;
• хост проксі та порт — адресу, через яку йде трафік;
• код країни — щоб зафіксувати геолокацію запиту (наприклад, US, CA, FR, AE);
• опційний session ID — для керування сесіями й повторного використання одного й того ж IP.

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

У результаті кожен HTTP‑запит до Amazon стає не просто зверненням до URL, а частиною керованого потоку трафіку, де чітко визначено, з якої країни, з якої IP‑адреси і в рамках якої сесії він має виглядати.

HTTP‑запити замість Selenium: чому це важливо на масштабі

Відмова від браузерної автоматизації

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

У розглянутій системі обрано інший шлях: замість браузерної автоматизації використовуються «чисті» HTTP‑запити — GET і POST — які йдуть через проксі Thor Data. Це дає кілька важливих переваг:

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

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

Потік скрейпінгу: від HTML до структурованих даних

Логіка роботи скрейпера в такій конфігурації виглядає послідовно. Спочатку система формує HTTP‑запит до конкретного домену Amazon з урахуванням країни, яку потрібно опитати. Запит проходить через проксі Thor Data з відповідним кодом країни та, за потреби, session ID. У відповідь повертається HTML‑сторінка, вже «пофарбована» геолокацією: ціни, валюта, доступність товару — усе так, як це бачить користувач у цій країні.

Далі в гру вступає Beautiful Soup. Отриманий HTML не зберігається як «чорний ящик» — він розбирається, і з нього витягуються структуровані атрибути товару. Серед них:

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

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

Beautiful Soup як робоча конячка парсингу Amazon

Чому класичний HTML‑парсер досі актуальний

Попри поширену думку, що сучасні сайти неможливо скрейпити без повноцінного браузера, приклад з Amazon показує, що класичний HTML‑парсер на кшталт Beautiful Soup залишається ефективним інструментом, якщо правильно організувати мережевий рівень.

У цій системі Beautiful Soup використовується як основний інструмент для розбору HTML‑відповідей, отриманих через Thor Data. Після того як сторінка товару завантажена, парсер проходить по DOM‑структурі, знаходить потрібні елементи й витягує ключові атрибути. Це дозволяє:

• стандартизувати дані з різних локалізованих версій Amazon;
• відокремити мережеву логіку (Thor Data, HTTP‑запити) від логіки парсингу;
• швидко адаптуватися до змін верстки, змінюючи лише селектори в Beautiful Soup.

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

Витягування атрибутів товару для порівняння цін

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

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

По‑друге, ціна. Саме вона є основою для побудови аналітики: система показує, як вартість одного й того ж товару відрізняється між, скажімо, Францією, Іспанією, Австралією та Японією, навіть якщо валюта однакова (наприклад, євро), але цифри різні.

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

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

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

Геоспецифічний скрейпінг Amazon: як це виглядає для користувача

Один ASIN — багато країн

З погляду кінцевого користувача система працює як «агент порівняння цін» для Amazon. У демо‑додатку можна ввести ASIN — унікальний ідентифікатор товару на Amazon — і вибрати цільові країни, з яких потрібно зібрати дані. Серед доступних варіантів — США, Канада, Велика Британія, Франція, Іспанія, Австралія, Японія, ОАЕ та інші локалізовані домени.

Далі запускається процес скрейпінгу: для кожної обраної країни система формує HTTP‑запит до відповідного домену Amazon, пропускає його через Thor Data з потрібним кодом країни, отримує HTML‑сторінку й розбирає її через Beautiful Soup. Якщо товар з таким ASIN існує на кількох сайтах, користувач отримує таблицю з цінами, назвами, брендами й іншими атрибутами для кожного регіону.

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

Масштабування без зміни підходу

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

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

Чому без Thor Data цей проєкт не працював би на продакшн‑масштабі

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

Причин кілька.

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

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

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

У сукупності це робить Thor Data не просто «постачальником IP», а інфраструктурним шаром, без якого навіть найкращий парсер на Beautiful Soup і найакуратніший HTTP‑клієнт не змогли б стабільно працювати з Amazon у десятках країн.

Висновок: класичний стек, продакшн‑масштаб

Розглянута система показує, що для побудови продакшн‑рівня скрейпера Amazon не обов’язково йти шляхом важкої браузерної автоматизації. Комбінація «чистих» HTTP‑запитів, резидентної проксі‑мережі Thor Data та перевіреного HTML‑парсера Beautiful Soup дозволяє:

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

На цьому фундаменті вже можна будувати складніші речі — від історичної аналітики цін до AI‑агентів, які відповідають на запитання природною мовою. Але саме мережевий шар на Thor Data й парсинг через Beautiful Soup роблять можливим головне: стабільний, відтворюваний і геоспецифічний доступ до даних Amazon у продакшн‑умовах.

Джерело

How to Design a Production-Grade System in Python — Tech With Tim

Коли легендарний геймдизайнер Blizzard Джефф Каплан згадує народження World of Warcraft, він описує не стільки створення MMO, скільки побудову цілого всесвіту. У розмові з Лексом Фрідманом він повертається у початок 2000‑х, коли невелика, строката команда Blizzard намагалася конкурувати з EverQuest II та Star Wars Galaxies — і водночас формувала нову філософію онлайн‑ігор: «світ — перший герой».

Ця філософія, роль креативного директора Криса Мецена, суперечливе рішення розділити гравців на Орду й Альянс та «наївність» команди, яка ще не знала, як «правильно» робити MMO, стали фундаментом феномену WoW.

Світ як головний персонаж

У класичному визначенні World of Warcraft — це масова багатокористувацька онлайн‑RPG, де гравець створює персонажа, виконує квести, ходить у підземелля, прокачує рівень і спорядження в фентезійному світі Азерот. Але всередині Blizzard на це дивилися інакше.

Креативний директор Кріс Мецен сформулював тезу, яка стала мантрою для всієї команди: «Головний персонаж World of Warcraft — це світ». Не герой, не сюжетна лінія, не система прогресу — саме світ. І це не красива метафора, а практичний дизайн‑принцип.

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

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

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

Орда проти Альянсу: суперечливе рішення, яке сформувало ідентичність

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

Співзасновник Blizzard Ален Едхем був головним адвокатом цієї ідеї. На відміну від Каплана та Роба Пардо, які прийшли з EverQuest, де всі раси могли грати разом, Едхем орієнтувався на Dark Age of Camelot — MMO з трьома фракціями та сильним PvP‑фокусом. Його аргумент був простим і водночас радикальним: гравець має бути «миттєво в команді». Навіть якщо він сам по собі одинак, гра з першої хвилини повинна давати йому відчуття приналежності до сторони конфлікту, до великої спільноти.

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

Ключовий момент настав уже напередодні бети, коли Едхем раптово пішов з Blizzard, щоб займатися фінансами й покером, і залишив команду менш ніж за рік до релізу WoW. Новим провідним дизайнером став Роб Пардо. І саме він, попри те, що раніше був противником поділу на фракції, першим сказав: якщо Ален так завзято боровся за цю ідею, її потрібно не відкотити, а реалізувати до кінця.

Це рішення стало поворотним. Команда не просто «залишила» Орду й Альянс, а «пішла ва-банк» — почала будувати навколо фракцій усе: квести, зони, міста, естетику, навіть маркетинг. У результаті поділ перетворився на потужний інструмент формування ідентичності гравців.

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

«Погана новина» для експертів: успіх команди, яка не знала, як робити MMO

Ще один парадокс WoW полягає в тому, що його створювала команда, яка в значній мірі не мала досвіду розробки MMO. Blizzard на той момент уже була успішною студією з хітами на кшталт StarCraft, Diablo та Warcraft, але масова онлайн‑RPG була для неї новою територією.

Каплан описує ранню команду WoW як «Bad News Bears» — строкату суміш ветеранів і людей, які «просто дуже багато грали в EverQuest». Частину розробників підземель найняли прямо з Quake‑спільноти, і вони буквально будували перші данжі як рівні Quake. На певному етапі World of Warcraft навіть створювався в QERadiant — редакторі рівнів для Quake, перш ніж команда перейшла на власний рушій.

Дизайнерів MMO як окремої спеціалізації фактично не існувало. Було кілька ключових людей — Кевін, Ерік, Ален, — але загалом це була команда, яка вчилася на ходу. Каплан сам прийшов у Blizzard як фанат EverQuest і дуже швидко опинився в ролі квест‑дизайнера для WoW.

Згодом він порівнює цей досвід з Titan — амбітним, але провальним проєктом Blizzard, який мав стати наступним великим MMO після WoW. Titan зібрав «найкращих з найкращих», людей, які вже знали, як робити успішну онлайн‑гру. І саме це, на думку Каплана, стало проблемою: надто багато експертизи, надто сильна впевненість у тому, «як має виглядати проривна MMO».

У випадку WoW команда не знала, як саме виглядає «правильна» MMO, і це звільняло від невидимих обмежень. Вони не намагалися повторити формулу успіху, якої ще не існувало в усталеному вигляді. Вони просто вірили, що можуть конкурувати з Sony Online, яка тоді готувала EverQuest II, і з LucasArts, що працювала над Star Wars Galaxies з дизайнером Ultima Online Рафом Костером.

Контекст був жорстким: EverQuest уже став феноменом, EverQuest II виглядав природним спадкоємцем, а Star Wars Galaxies мав за спиною одну з найсильніших медіафраншиз у світі. Усередині Blizzard панувало відчуття: «Ми приречені. Як ми взагалі можемо з цим змагатися?» Саме в такій атмосфері невпевненості, але й азарту, народжувався WoW.

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

Той факт, що багато дизайнерів прийшли з інших жанрів, теж зіграв свою роль. Люди з Quake‑спільноти привносили відчуття просторового дизайну, ритму бою, структури рівня. Ветерани RTS і action‑RPG — розуміння темпу прогресу, економіки, «петлі задоволення» гравця. Усе це змішувалося в нову формулу MMO, яка не була прямим нащадком жодної з попередніх ігор.

Квести, підземелля, фракції: як філософія світу формувала контент

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

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

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

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

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

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

Ціна світу: «кранч», виснаження і добровільна одержимість

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

Каплан згадує, що тоді в Blizzard працювали «божевільні» години. Його особистий рекорд — 30‑годинна зміна без перерви під час фінального тестування Warcraft III. Хоча він формально не був частиною команди War III, після E3 2002 студія перевела всіх, хто міг допомогти, на «усе на палубу» для завершення гри. Новачку‑дизайнеру Каплану доручили одну з наймонотонніших задач: безкінечно проганяти кат‑сцену, щоб відловити рідкісний креш, поки програмісти збирали лог‑дані.

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

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

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

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

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

Висновок: коли світ важливіший за героя

Історія створення World of Warcraft показує, як кілька ключових ідей можуть визначити долю гри — і жанру загалом. Філософія «світ — перший герой» змусила команду мислити Азерот як живий організм, а не як фон для механік. Суперечливе рішення розділити гравців на Орду й Альянс перетворилося на потужний інструмент формування ідентичності й соціальної динаміки. Відсутність «правильних» експертів з MMO дозволила команді експериментувати й не боятися відходити від шаблонів.

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

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

Джерело

Lex Fridman Podcast #493 — Jeff Kaplan: World of Warcraft, Overwatch, Blizzard, and Future of Gaming

У свіжому випуску подкасту 20VC with Harry Stebbings обговорюється малопомітна, але важлива тенденція: створення глибокотехнологічних (deep tech) компаній за межами Кремнієвої долини. Попри очевидні мінуси віддаленості від головного технологічного центру світу, така стратегія може стати потужною конкурентною перевагою — особливо для команд, які мислять на горизонті десятиліть, як це було з DeepMind.

Менше «шуму» — більше глибокого мислення

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

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

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

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

Deep tech проти модних трендів

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

У такому контексті:

• Орієнтація на «останній тренд» стає ризиком. Вона може відволікати від довгострокової наукової чи технічної стратегії.
• Стійкість до моди — перевага. Команда, яка не реагує на кожен новий хайп, має більше шансів послідовно рухатися до великої цілі.
• Фокус на 20-річному горизонті. Саме так описується місія DeepMind на старті: як проєкт на 20 років, а не на один-два інвестиційні цикли.

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

Довга дистанція як стратегія

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

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

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

Джерело

YouTube: Building out of the Valley is a MASSIVE Advantage

Акторка, продюсерка та співзасновниця Optimist Project Яра Шахіді — одна з тих публічних фігур, які намагаються системно осмислити, як жити й діяти в складному світі, не вигораючи. Вона почала навчання в Гарварді у серпні 2018 року, паралельно знімалася у другому сезоні серіалу Grown-ish, а згодом успішно поєднала кар’єру в кіно з соціальними ініціативами та інтелектуальною роботою.

У розмові на базі свого TED-виступу Шахіді описує не лише шлях від короткого періоду песимізму до дисциплінованої практики оптимізму, а й дуже конкретний інструмент, який допомагає їй тримати цю практику «в робочому стані» — так званий hard yes list, список «жорстких так». Це не мотиваційний слоган, а продумана особиста система, яка працює як інструмент саморегуляції, захисту радості та встановлення меж.

Від «року ні» до «року так»: чому без фільтра радості не працюють

Історія hard yes list почалася з радикального експерименту з кордонами. У певний момент Шахіді оголосила собі «рік ні» — період, коли вона свідомо відмовлялася від більшості запитів і можливостей. Мета була проста й водночас нетипова для молодої зірки: навчитися вільно казати «ні» й дуже точно визначати, куди вона хоче вкладати свій час і енергію.

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

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

Саме на цьому зламі й народилася ідея hard yes list — не просто «більше так», а «дуже конкретні так», які не підлягають сумніву, бо доведено приносять радість і відновлення.

Як народжується «hard yes»: спільна розробка з матір’ю та партнеркою по бізнесу

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

У цих розмовах поступово сформувалася ідея: варто не просто інтуїтивно відчувати, що приносить радість, а системно це фіксувати. Так з’явився hard yes list — список речей, подій, людей і навіть дрібних деталей, які гарантовано дають Ярі відчуття радості й наповненості.

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

Це перетворило hard yes list на живий документ — не декларацію намірів, а накопичену емпіричну базу власної радості.

Що потрапляє до списку: кольори, кава з друзями й живий звук

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

Шахіді описує, що до її списку потрапляють:

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

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

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

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

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

«Арсенал дій» на важкі дні: як працює hard yes як інструмент перезапуску

Шахіді прямо називає свій hard yes list «арсеналом» — набором засобів, до яких можна звернутися в момент, коли «двері можливостей здаються зачиненими», а тиск реальності — надмірним.

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

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

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

Таким чином, список стає інструментом:

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

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

Радість як ресурс для дії: як hard yes вбудований у практику оптимізму

Для Шахіді hard yes list — не ізольований лайфхак, а частина ширшої концепції, у якій радості й оптимізму відведено принципово важливу роль.

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

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

Hard yes list — один із таких інструментів. Він «операціоналізує» оптимізм, роблячи його не емоцією, а набором практик.

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

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

Межі, час і запити: як «жорсткі так» допомагають казати «ні»

Ще одна важлива функція hard yes list — це інструмент встановлення меж.

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

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

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

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

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

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

Чому турбота про власну радість — не егоїзм, а умова стійкого активізму

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

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

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

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

Як почати власний hard yes list: уроки з підходу Шахіді

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

Її підхід можна описати кількома принципами.

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

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

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

По-четверте, використовувати список активно, а не зберігати як красиву ідею. У важкі дні до нього варто звертатися так само практично, як до аптечки чи інструкції з безпеки.

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

Висновок: оптимізм як робота, а не настрій

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

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

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

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

Джерело

How to Find Your Purpose (W/ Yara Shahidi) | How to Be a Better Human | TED

Ранній етап розвитку компаній зі штучного інтелекту часто виглядає ззовні як стрімкий успіх. Насправді ж за гучними партнерствами на мільярди доларів стоять місяці нерозуміння, скепсису й відмов. Один із показових прикладів — історія Anthropic, яку в подкасті 20VC з Гаррі Стеббінгсом розповідають як кейс того, наскільки важко було пояснити інвесторам потенціал сучасних моделей ШІ навіть після появи GPT‑3.

«Що таке GPT‑3?»: коли інвестори не знають базових речей

На старті Anthropic зіткнулася з тим, що значна частина венчурних інвесторів просто не розуміла, що відбувається в машинному навчанні. Команда, до якої входили люди, причетні до створення GPT‑3, чула відмову за відмовою — загалом 21 «ні».

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

Це створювало парадокс: команда з глибоким науковим бекграундом, досвідом у комп’ютерному зорі та участю в проривних моделях мала витрачати час не на обговорення стратегії, а на базову просвіту інвесторів.

Амбіції на $500 млн і «реанкеринг» до $100 млн

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

У результаті Anthropic довелося «переприв’язати» очікування й орієнтуватися на $100 млн посівного раунду. Навіть ця цифра на той момент здавалася значною, але в контексті галузі була скромною: OpenAI вже залучила близько $1 млрд. Ідея умовної «одиниці інтелекту за шість разів менші гроші» виявилася для більшості фондів незрозумілою та нелегкою для оцінки.

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

Чому Amazon побачив логіку там, де інші — ризик

Попри серію відмов, для великого гравця з хмарної інфраструктури ситуація виглядала інакше. Amazon уважно стежив за тим, як Microsoft через Azure вибудовує партнерство з OpenAI, і бачив, як це змінює розклад сил на ринку.

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

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

Так сформувалася «глибока» угода: обчислювальні ресурси й капітал в обмін на частку в компанії. Партнерство з Amazon, яке оцінювали в $4 млрд, стало результатом саме такого стратегічного бачення, а не класичного венчурного підходу до оцінки ризик/прибуток.

Виснажливий старт і роль команди

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

Цей кейс показує кілька важливих тенденцій для всієї галузі:

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

Історія Anthropic на ранньому етапі — це не лише про складні перемовини з інвесторами. Це ілюстрація того, як швидко розвивається ШІ, і як повільно до нього адаптуються традиційні фінансові інституції.

Джерело

Anthropic’s 1st Round: We Got 21 No’s — 20VC with Harry Stebbings

У подкасті IBM Security Intelligence ведучий Метт Косінскі разом із експертами IBM Security та X‑Force обговорюють не лише гучну історію з Claude Mythos і Project Glasswing від Anthropic, а й те, як штучний інтелект уже змінює ландшафт кіберзлочинності. На тлі нових «супермоделей» ШІ виходять свіжі цифри з доповіді FBI Internet Crime Report 2025 та дослідження Accenture, які показують: збитки від онлайн‑шахрайств стрімко зростають, а паралельно формується вибуховий ринок інсайдерів — співробітників, готових продати доступ до своїх компаній.

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

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

Останній звіт FBI Internet Crime Complaint Center (IC3) за 2025 звітний період фіксує понад мільйон звернень про кіберзлочини. Це не повна картина реальності — далеко не всі жертви звертаються до правоохоронців, але навіть офіційні цифри демонструють масштаб проблеми.

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

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

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

ШІ у шахрайстві: від «поганої англійської» до майже бездоганних підробок

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

Найчастіше ШІ з’являється у трьох категоріях:

інвестиційні шахрайства,
романтичні (romance) схеми,
компрометація ділової електронної пошти (Business Email Compromise, BEC).

Усі три типи атак традиційно спираються на довіру та емоції. Генеративний ШІ робить їх значно переконливішими.

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

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

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

Business Email Compromise: тихий лідер за збитками

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

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

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

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

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

«AI slop» і навантаження на відкриті проєкти

ШІ впливає на безпеку не лише як інструмент шахрайства, а й як джерело шуму. В епізоді згадується показовий приклад: популярний open source‑проєкт curl отримав хвилю низькоякісних, згенерованих ШІ звітів про вразливості — те, що розробники називають «AI slop».

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

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

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

Ринок інсайдерів: коли співробітник стає вхідною точкою

Якщо ШІ робить зовнішні атаки ефективнішими, то паралельно зростає ще одна загроза — інсайдери. Дослідження Accenture, на яке посилаються учасники подкасту, показує тривожну динаміку: у 2025 році кількість випадків, коли співробітники самі пропонують свій доступ хакерам, зросла на 69% порівняно з 2024‑м.

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

Причини такої динаміки багатошарові. Експерти пов’язують її з:

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

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

З точки зору нападника, інсайдер — це спосіб обійти дорогі й складні зовнішні атаки. Замість того щоб витрачати ресурси на експлуатацію вразливостей у периметрі, можна просто купити доступ до VPN, VDI, Citrix, AnyDesk або будь‑якої іншої точки входу у внутрішню мережу. Це дешевше, швидше й часто надійніше.

Lapsus, LockBit та «оголошення про роботу» для зрадників

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

облікових даних VPN,
доступу до VDI‑середовищ,
логінів до Citrix,
доступу через AnyDesk,
будь‑яких інших внутрішніх точок входу.

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

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

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

Коли інсайдер не знає, що він інсайдер: кейс північнокорейських ІТ‑працівників

Ще один вимір інсайдерського ризику — ситуації, коли співробітник формально не має злочинних намірів, але фактично працює в інтересах ворожої держави чи угруповання. У подкасті згадується дослідження IBM X‑Force спільно з Flare щодо північнокорейських ІТ‑працівників.

Схема виглядає так: фахівці з КНДР влаштовуються на роботу як віддалені підрядники або фрилансери, часто під чужими іменами та з підробленими профілями. Вони виконують реальні завдання, отримують доступ до внутрішніх систем, репозиторіїв коду, інфраструктури. При цьому їхня діяльність може координуватися державними структурами або пов’язаними з ними організаціями.

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

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

Чому інсайдери вигідніші за зовнішні атаки

З технічної точки зору сучасні корпоративні периметри стають дедалі складнішими для злому. Використовуються багатофакторна автентифікація, сегментація мереж, системи виявлення вторгнень, EDR‑рішення, Zero Trust‑підходи. Це не робить організації невразливими, але значно підвищує вартість атаки для зловмисника.

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

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

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

Висновок: подвійний тиск ШІ та людського фактора

Дані FBI та Accenture, а також приклади з практики, які обговорюють експерти IBM, показують дві паралельні тенденції.

По‑перше, генеративний ШІ робить традиційні шахрайські схеми — від романтичних афер до BEC‑атак — значно переконливішими й масштабованішими. Кількість скарг із компонентом ШІ поки що відносно невелика, але майже 900 мільйонів доларів задекларованих збитків свідчать: це вже не експериментальний етап, а реальний фактор ризику.

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

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

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

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

Джерело

Security Intelligence Podcast — Claude Mythos: Marketing hype or the end of cybersecurity?

У розмові на каналі Axios про інтерв’ю з генеральним директором JPMorgan Chase Джеймі Даймоном пролунала не лише оцінка економіки, штучного інтелекту та геополітики, а й тривожний сигнал: навіть найвпливовіші бізнес-лідери дедалі обережніше говорять про політику. Це створює вакуум лідерства, який уже відчувають суспільство й інституції.

AI: оптимізм проти швидкості змін

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

Водночас у цій позиції є кілька важливих нюансів:

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

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

Найнебезпечніший період з часів Другої світової: фокус на Китаї

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

Серед загроз, на які звертається увага:

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

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

Мовчання про Трампа й страх регуляторної відплати

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

Картина виглядає так:

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

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

Вакуум лідерства й наступний крок великих CEO

На цьому тлі постає ширша проблема: хто взагалі має бути публічним лідером у США, коли довіра до традиційних інституцій падає?

Кілька ключових тез:

• Бізнес запізнився. Визнано, що компанії помилилися, не включившись у суспільні процеси раніше. Очікувати, що політики самі розв’яжуть усі проблеми, — нереалістично.
• Довіра змістилася вниз. Люди можуть не любити «великий бізнес» загалом, але довіряють своєму конкретному роботодавцю. Те саме — з місцевими громадами проти абстрактного «населення країни».
• Моральна відповідальність. У бізнесу є не лише фідуціарний обов’язок перед акціонерами, а й моральний — перед працівниками та громадами, де компанії працюють.

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

Чому не президентство і що далі

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

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

Натомість більш реалістичний сценарій:

• перехід у статус виконавчого голови JPMorgan Chase у найближчі 2–3 роки (що традиційно створює напруження для наступного CEO);
• написання книги та активні публічні виступи;
• створення аналітичного центру з фокусом на публічній політиці;
• потенційний запуск медійного проєкту, орієнтованого на аудиторію бізнес-лідерів і «політичних гіків», з акцентом на освіту й пояснення складних політичних рішень.

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

Джерело

What Jamie Dimon DIDN’T say about AI and Trump spoke volumes | The Axios Show Recap