Після скорочення залежності від поштової служби США та інших перевізників Amazon відкриває власні логістичні й доставні сервіси для сторонніх компаній. “Сьогодні Amazon оголошує про запуск Amazon Supply Chain Services (ASCS), відкриваючи свій повний портфель можливостей з вантажних перевезень, дистрибуції, фулфілменту та посилкової доставки для бізнесів усіх типів і розмірів, а не лише для продавців на Amazon”, — заявила компанія у пресрелізі.

Новий сервіс Amazon запускає разом із кількома великими клієнтами, серед яких Procter & Gamble, 3M, Lands’ End та American Eagle Outfitters Inc. Для 3M і P&G логістика Amazon забезпечуватиме перевезення продукції від виробничих майданчиків до дистрибуційних мереж, а для Lands’ End та American Eagle — виконання замовлень безпосередньо до кінцевих покупців.

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

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

Джерело

Engadget

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

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

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

Щоб підготувати технологію до виходу на ринок, Barocal залучила посівні інвестиції у розмірі 10 млн доларів, розповіли в компанії ексклюзивно TechCrunch. Серед інвесторів — World Fund, Breakthrough Energy Discovery, Cambridge Enterprise Ventures та IP Group.

Ядро технології Barocal походить із досліджень засновника стартапу Хав’єра Мойї. «Мене завжди дуже цікавили технології нагріву й охолодження», — розповів він TechCrunch. Свій інтерес він пов’язує з дитинством в Іспанії, де годинами готувався до занять у маленькій задушливій кімнаті. «Дуже добре пам’ятаю, коли в будинку з’явився кондиціонер — це було як вау!» — згадує він.

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

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

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

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

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

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

Джерело

TechCrunch

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

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

Водночас мітки “AI creator” є повністю опціональними. Це означає, що багато користувачів і надалі бачитимуть AI-контент лише з більш розмитою позначкою “AI info” або взагалі без будь-якої мітки. Як нещодавно зауважила Наглядова рада Meta, такі позначення застосовуються доволі непослідовно, адже компанія не має можливості надійно виявляти весь контент, згенерований штучним інтелектом, який проходить через її додатки. (Компанія ще не відреагувала на рекомендації ради щодо вдосконалення методів виявлення AI-контенту.)

Попри це, Meta заохочує авторів, які часто публікують AI-контент, користуватися новою функцією. “Ця мітка підвищує довіру, допомагаючи вашій аудиторії зрозуміти, що саме вона бачить в Instagram”, — йдеться в повідомленні в застосунку. Звісно, якби компанія справді хотіла максимально “посилити довіру”, вона могла б вмикати такі мітки за замовчуванням, зробити їх обов’язковими або навіть обмежувати охоплення акаунтів, які відмовляються їх використовувати. Поки що Meta обирає значно м’якший підхід. Але з поширенням згенерованого AI-контенту (який стає дедалі важче розпізнати неозброєним людським оком) компанії, ймовірно, знову доведеться переглянути своє ставлення до маркування штучного інтелекту.

Джерело

Engadget

Профіль у LinkedIn дедалі частіше стає першим «екраном співбесіди» — ще до будь-якої розмови з рекрутером чи інвестором. У подкасті 20VC з Гаррі Стеббінгсом гість звертає увагу на просту, але критичну річ: якщо, дивлячись на ваш LinkedIn, неможливо зрозуміти, яку історію розповідає ваша кар’єра, ви втрачаєте шанс справити сильне перше враження.

Проблема «мішанини компаній»

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

• 2 роки в Snowflake
• 4 роки в Lattice
• 3 роки в Marketo

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

• Яку саме експертизу людина будує?
• У чому її професійний фокус?
• Яка логіка переходів між ролями?

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

Чому важлива цілісна історія

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

• у чому ви сильні;
• як ви приймаєте кар’єрні рішення;
• яку цінність можете принести саме зараз.

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

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

Як зробити так, щоб профіль «розповідав» за вас

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

1. Визначити головну лінію експертизи

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

• певний тип продуктів (B2B SaaS, маркетингові платформи, інфраструктура даних);
• функція (продажі, продукт, маркетинг, інженерія);
• етапи компаній (ранні стартапи, scale-up, пізня стадія).

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

2. Пояснити логіку переходів

Кожен перехід між компаніями повинен виглядати як крок уперед у межах обраної історії. Для цього варто:

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

3. Підкреслити накопичення, а не розпорошення досвіду

Замість того щоб виглядати як людина, яка «просто працювала в кількох хороших компаніях», варто показати:

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

LinkedIn як інструмент стратегії, а не архіву

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

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

Джерело

YouTube: Does your LinkedIn show a story?

Як один Claude‑скіл замінив крихкий n8n‑конвеєр для розсилки

Щотижнева розсилка — типовий кандидат на автоматизацію: багато рутинних кроків, повторювані дії, купа дрібних перевірок. Для досвідченого інженера це виглядає як ідеальне завдання для складного workflow‑оркестратора. Саме так кілька місяців тому працював Кріс Парсонс — інженер із майже 30‑річним стажем, колишній CTO VC‑беканих стартапів і керівник агенції, який нині допомагає командам впроваджувати AI у повсякденну роботу.

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

Коли автоматизація стає роботою замість того, щоб її знімати

Початковий підхід Парсонса до автоматизації розсилки виглядав дуже знайомо для будь‑кого, хто працював з no‑code/low‑code оркестраторами. У n8n він зібрав велику діаграму з десятків вузлів: окремий потік для «featured article», який читав пости з блогу, перевіряв, чи публікувалися вони раніше, узагальнював їх за допомогою AI і формував блок розсилки; інший потік — для лінків, які він додавав у спеціальний список, з автоматичною генерацією коротких коментарів; додаткові гілки для форматування, перевірок, публікації.

Цей конвеєр був не просто складним — він був крихким. Майже кожного понеділка о 14:00 Парсонс отримував сповіщення від n8n: workflow впав. Замість того щоб натискати «Send» і займатися іншими справами, він відкривав діаграму, намагався зрозуміти, який саме вузол зламався, перезапускав окремі гілки, лагодив дрібні помилки.

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

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

Від графа до скіла: як JSON‑workflow перетворився на один цикл

Перелом стався тоді, коли Парсонс перестав сприймати AI як «чорну коробку» всередині workflow і почав дивитися на нього як на самодостатнього агента, здатного самостійно керувати процесом. Замість того щоб оркеструвати десятки кроків у n8n, він вирішив описати весь процес розсилки як один Claude Code skill.

Стартовий крок виглядав майже карикатурно просто: він узяв JSON‑опис свого n8n‑workflow, скопіював його і вставив у Claude Code з інструкцією: «Створи скіл на основі цього flow». Модель проаналізувала граф, зрозуміла, які кроки виконуються, у якій послідовності, які дані потрібні, і згенерувала один скіл, що інкапсулює всю логіку створення newsletter’а.

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

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

Як працює «нескінченний» newsletter‑цикл у Claude Code

Ключ до нового підходу — у тому, як саме працює Claude Code зі скілами. На відміну від традиційного workflow‑оркестратора, де кожен крок жорстко зафіксований, Claude фактично виконує один і той самий цикл:

спочатку читає опис скіла, тобто інструкції, що саме потрібно зробити, які є інструменти, які обмеження та критерії якості;

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

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

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

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

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

Чому простий цикл дає кращий перший драфт, ніж складний workflow

Найцікавіша частина історії Парсонса — не лише в тому, що новий підхід виявився менш крихким. Виявилося, що Claude Code‑скіл дає кращий перший драфт розсилки, ніж попередній n8n‑конвеєр.

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

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

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

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

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

Останній елемент цієї історії робить її особливо показовою для майбутнього автоматизації. Парсонс не просто запустив Claude Code‑скіл і залишив його в спокої. Наприкінці кожної сесії створення newsletter’а він додає ще один крок: просить Claude оновити сам скіл на основі досвіду поточного запуску.

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

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

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

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

Висновок: кінець епохи «інженерних діаграм» для AI‑процесів?

Історія з newsletter’ом Парсонса — це не просто анекдот про те, як один інженер втомився від падінь n8n по понеділках. Це показовий кейс зміни підходу до AI‑автоматизації.

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

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

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

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

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

Джерело

YouTube: Ralph Loops: Build Dumb AI Loops That Ship — Chris Parsons, Cherrypick

Системний дизайн у світі мобільних застосунків давно перестав бути темою лише для бекенд‑інженерів. Від Android‑та iOS‑розробників на співбесідах усе частіше очікують, що вони зможуть спроєктувати умовний WhatsApp, Instagram чи YouTube — не на рівні макетів екранів, а як цілісну систему. У свіжому гайді розробник Philipp Lackner пропонує просту, але показову модель: дивитися на мобільний system design через три рівні «зуму» — від продуктового бачення до архітектури й конкретного техстеку.

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

Рівень 1: продуктове бачення — хто користується і що саме робить застосунок

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

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

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

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

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

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

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

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

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

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

Рівень 2: архітектура — як організувати код і відповідальності

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

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

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

Якщо ж майбутнє продукту невизначене, а потенціал зростання великий, доводиться закладати більш серйозні архітектурні принципи. Тут у гру входять патерни на кшталт MVVM чи MVI у презентаційному шарі, підхід «чистої архітектури» з чітким розділенням доменних, дата‑ та UI‑шарів, використання use case‑інтерфейсів і репозиторіїв як абстракцій над джерелами даних.

MVVM і MVI по‑різному організовують потоки даних між UI та логікою, але в обох випадках ідеться про те, щоб зробити поведінку передбачуваною, тестованою й масштабованою. Чиста архітектура додає до цього жорсткіші кордони між шарами, що дозволяє легше змінювати, наприклад, джерело даних (локальне сховище, REST‑API, WebSocket) без переписування бізнес‑логіки.

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

На цьому рівні також приймаються рішення про те, як саме застосунок взаємодіє з бекендом. Сам факт, що потрібен сервер, ще нічого не говорить про протокол чи модель обміну даними. Саме тут визначається, чи достатньо класичного REST поверх HTTP, чи потрібні WebSocket‑з’єднання, чи варто дивитися в бік GraphQL або server‑sent events.

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

Рівень 3: техстек — протоколи, API, схеми даних і кешування

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

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

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

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

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

На рівні даних постає питання схеми бази. Для соціального застосунку типовим буде набір таблиць на кшталт users, posts, comments, follows із чітко визначеними зв’язками. Один користувач може мати багато постів, але кожен пост належить лише одному користувачу. Один пост може мати багато коментарів, але кожен коментар прив’язаний до конкретного поста. Таблиця підписок описує, хто на кого підписаний, причому один користувач може мати багато підписників, і кожен підписник може стежити за багатьма користувачами. Такі правила задаються саме на рівні системного дизайну, а не «по ходу» реалізації.

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

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

Навіщо це все на співбесіді: не «вгадати WhatsApp», а показати мислення

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

На продуктовому рівні важливо, чи вміє кандидат ставити запитання про користувачів, сценарії використання, обмеження середовища, а не одразу малює схему мікросервісів. На архітектурному — чи може він обґрунтувати вибір патернів, розділення шарів, інтеграцій, виходячи з вимог, а не з моди. На рівні техстеку — чи розуміє компроміси між REST і WebSocket, між товстими відповідями й GraphQL, між простим кешем і складним offline‑first, між зручністю й безпекою.

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

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

Мобільний system design дедалі більше стає обов’язковою компетенцією для Android‑ та iOS‑інженерів. Від них очікують не лише вміння писати якісний UI‑код, а й здатності мислити категоріями продукту, архітектури й техстеку одночасно.

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

Джерело

Beginner’s Guide to Mobile App System Design (+ Tips for Interviews!)

Коли канадська Shopify виходила на біржу у 2015 році, ринок бачив у ній перспективний, але все ж «звичайний» SaaS‑бізнес з оцінкою близько 1,67 млрд доларів. Сьогодні це компанія, яка в різні моменти торгувалася приблизно у 100 разів дорожче за свою IPO‑оцінку, а її засновник і CEO Тобіас Лютке відкрито говорить, що майже ніколи не дивиться на курс акцій.

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

Від $1,67 млрд до 100×: що означає «успішне IPO» насправді

Shopify вийшла на біржу у 2015 році з початковою оцінкою приблизно 1,67 млрд доларів. Для канадського технологічного ринку це вже був помітний успіх: компанія з корінням у світі інді‑e‑commerce‑розробників перетворювалася на глобальну платформу для онлайн‑торгівлі.

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

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

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

Shopify пішла іншим шляхом: вийшла на біржу відносно рано, але з чітким наміром грати в довгу. І це відчувалося вже в тому, як компанія підійшла до найчутливішого моменту — ціноутворення на IPO.

Як CEO переграв банкірів: ручне налаштування ціни IPO

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

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

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

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

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

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

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

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

Від «IPO‑моменту» до режиму глибокого ігнору курсу акцій

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

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

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

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

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

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

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

Довгострокове мислення як умова для «довіреної публічної компанії»

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

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

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

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

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

Коли банкір стає CFO: довіра як стратегічний актив

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

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

Факт, що саме банкір IPO став CFO, свідчить про кілька речей.

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

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

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

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

Чому ігнор курсу акцій — не розкіш, а стратегія виживання

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

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

У цій моделі є кілька практичних наслідків.

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

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

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

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

Висновок: уроки Shopify для наступної хвилі публічних техкомпаній

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

Ключові елементи цієї конструкції виглядають так:

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

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

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

Джерело

Shopify CEO on How AI is a Scapegoat for Mass Layoffs & Trump Derangement Syndrome in Canada — 20VC

Meta придбала Assured Robot Intelligence (ARI) — стартап, який розробляє штучний інтелект для роботів, щоб “вирішувати критично важливі завдання” на “ринках праці з високою доданою вартістю”. Компанія вже займається розробкою робототехнічного заліза та ШІ всередині корпорації, але, як повідомив речник Meta в коментарі Bloomberg, ARI “принесе глибоку експертизу в тому, як ми можемо проєктувати наші моделі та передові можливості для керування роботами й самонавчання для керування повнотілими гуманоїдами”. Фінансові умови угоди не розкриваються.

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

Ван, його співзасновники Сюсін Чен і Леррел Пінто, а також уся команда ARI приєднаються до підрозділу Meta Superintelligence Labs. Пінто також є співзасновником Fauna Robotics, але залишив компанію торік, ще до того, як її купила Amazon для власного проєкту гуманоїдного робота.

Джерело

Engadget

Глядачам доведеться зачекати ще кілька місяців на фільм «Narnia: The Magician’s Nephew» – дату релізу перенесено з Дня подяки на 12 лютого 2027 року.

Окрім перезапуску «Нарнії» на великих екранах і того, що це стане першим фільмом Ґрети Ґервіг після «Барбі», «The Magician’s Nephew» виглядає як наступний крок Netflix у співпраці з кінотеатрами. А завдяки перенесенню релізу цей крок стає ще масштабнішим.

Раніше компанія заявляла, що «The Magician’s Nephew» ексклюзивно показуватимуть лише в залах Imax принаймні два тижні перед стрімінговою премʼєрою на Різдво. За мірками Netflix це досить амбітний кінотеатральний реліз, але все ж обмежений порівняно з багатьма іншими голлівудськими блокбастерами.

Тепер Netflix повідомляє, що ексклюзивні превʼю в Imax розпочнуться 10 лютого 2027 року, а широкий світовий прокат у кінотеатрах стартує 12 лютого. За словами Netflix, це буде «глобальний евент-реліз». Фільм не зʼявиться на стрімінгу до 2 квітня.

У заяві компанії не уточнюється, в яких саме мережах кінотеатрів показуватимуть «The Magician’s Nephew», однак Imax у своєму коментарі наголосила, що перенесення дасть змогу фільму отримати «повноцінне кінотеатральне вікно», тож великі мережі навряд чи скаржитимуться.

Ба більше, AMC Theatres нещодавно відзначила успіх показів фіналу «Stranger Things» у своїх кінотеатрах і заявила, що планує подальші колаборації з Netflix. Водночас обмежена підтримка кінотеатральних релізів з боку стрімінгового сервісу та небажання надавати ексклюзивні кінотеатральні вікна, за повідомленнями, стали «каменем спотикання» в переговорах із творцями «Stranger Things», які зрештою підписали ексклюзивну угоду з Paramount.

У фільмі, де знімаються Деніел Крейґ і Меріл Стріп, «The Magician’s Nephew» екранізує одну з пізніших книг класичної фентезійної серії Клайва Стейплза Льюїса – приквел, що розповідає про витоки Нарнії.

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

Джерело

TechCrunch

Tesla знизила поріг доступності електромобілів у Канаді завдяки новій комплектації Model 3 Premium з заднім приводом. Повертаючи на ринок свою базову версію седана, компанія пропонує задньопривідну Model 3 за ціною від 39 490 канадських доларів (приблизно 29 000 доларів США). Це майже вдвічі дешевше за попередню стартову ціну Model 3 у Канаді — 79 990 канадських доларів (близько 59 000 доларів США).

У верхньому ціновому сегменті Tesla також знизила вартість Model 3 Performance для канадських покупців — з 89 000 до 74 990 канадських доларів (приблизно 55 000 доларів США).

Різке здешевлення пояснюється глобальним ланцюжком постачання Tesla та мінливою тарифною політикою у світі. До 2024 року жителі Канади могли купувати Model 3, вироблену на заводі Tesla в Шанхаї. Однак згодом Канада запровадила додаткове 100-відсоткове мито на електромобілі, вироблені в Китаї.

У відповідь Tesla переключилася на постачання для канадського ринку електрокарів, зібраних на її заводі у Фримонті, штат Каліфорнія. Проте після тарифної кампанії адміністрації Дональда Трампа Канада запровадила 25-відсоткові дзеркальні мита на автомобілі, вироблені у США. Саме це й призвело до того, що найдоступніша Model 3 у Канаді на той момент коштувала 79 990 канадських доларів.

Джерело

Engadget

Кодинг «за настроєм» став трохи милішим. OpenAI додала до застосунку Codex, свого агентного інструмента для допомоги з програмуванням, віртуальних AI-петів.

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

Щоб викликати або прибрати віртуального супутника, достатньо ввести в Codex команду “/pet”. Доступно вісім вбудованих «петів», але користувачі можуть згенерувати власного за допомогою AI через команду “/hatch” — наприклад, милого гобліна-компаньйона. Перші користувачі вже завантажили чимало варіантів, серед яких навіть інтерпретації відомого Microsoft Clippy.

Пети вже доступні у версіях Codex для Windows і macOS. До того ж OpenAI на обмежений час пропонує 30 днів ChatGPT Pro авторам десяти улюблених згенерованих компаньйонів.

Джерело

Engadget

Сервіс пошуку та запитань-відповідей Ask.com, який раніше був відомий як Ask Jeeves, припинив роботу.

Ask Jeeves запустили у 1996 році. Завдяки фокусу на відповідях на розмовні запитання, сформульовані природною мовою, його можна вважати свого роду попередником сучасних чат-ботів на базі ШІ. Однак більшу частину своєї майже 30-річної історії сервіс залишався в тіні інших пошукових продуктів, насамперед Google.

Холдинг IAC придбав Ask Jeeves у 2005 році, швидко прибрав з назви «Jeeves», а до 2010-го скоротив власне пошуковий продукт, переорієнтувавшись на формат запитань і відповідей. У тому ж 2010 році голова IAC Баррі Діллер на конференції TechCrunch Disrupt визнав, що Ask.com не може конкурувати з Google і що ринок не враховує вартість цього сервісу в капіталізації IAC.

Зараз на сайті Ask.com розміщене повідомлення: «У міру того як IAC продовжує зосереджуватися на ключових напрямах, ми ухвалили рішення припинити наш пошуковий бізнес, включно з Ask.com. Після 25 років відповідей на запитання світу Ask.com офіційно закрився 1 травня 2026 року».

Водночас на сайті запевняють: «Дух Дживза зберігається».

Джерело

TechCrunch

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

Американська кіноакадемія (Academy of Motion Picture Arts and Sciences) заявила, що на «Оскар» зможуть претендувати лише ті акторські роботи, які «вказані в офіційних титрах фільму та продемонстровано, що вони виконані людьми за їхньою згодою». Аналогічно, сценарії мають бути «створені людиною», щоб мати право на номінацію.

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

Ці зміни з’явилися на тлі виробництва незалежного фільму з використанням згенерованої ШІ версії Вела Кілмера, зростаючої популярності ІІ-«акторки» Тіллі Норвуд, а також появи нових відеомоделей, які змушують частину режисерів говорити про кризу та занепад професії. Питання штучного інтелекту було одним із ключових під час страйків акторів і сценаристів у 2023 році.

Джерело

TechCrunch