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

Як влаштовані такі Telegram-канали

Мова йде про Telegram-канали та пов’язані з ними сайти, де розміщуються фото підлітків із вкрай жорсткими, принизливими коментарями. Частина цих зображень має інтимний характер.

Ключові елементи схеми:

• Публікація фото підлітків – зокрема 16-річних, часто без їхньої згоди.
• Анонімність майданчика – Telegram не завжди оперативно блокує подібний контент; видалення часто відбувається лише після того, як батьки знаходять фото та починають діяти.
• Механіка «зливу» – типовий сценарій: конфлікт між підлітками (наприклад, «не пішла на побачення») переростає в погрозу «злити голі фото» в такі канали.

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

Шантаж як бізнес-модель

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

Схема виглядає так:

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

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

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

Чому це працює і чому так важко зупинити

Є кілька причин, чому подібні схеми продовжують існувати:

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

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

Що це означає для батьків і підлітків

З описаної схеми випливають кілька важливих висновків:

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

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

Джерело

https://www.youtube.com/watch?v=0yLND_p4Zb8

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

Що таке локальний AI насправді

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

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

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

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

Чому без дискретної Nvidia не обійтися

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

MacBook у цьому сенсі виглядає краще, але теж із застереженнями. Локальний AI на MacBook працює, однак з обмеженнями і не завжди швидко. Частина моделей поводиться прийнятно, інші помітно гальмують. Екосистема інструментів для macOS розвивається, але більшість популярного софту для локальних моделей оптимізовано під іншу платформу.

Ключова рекомендація для тих, хто хоче серйозно працювати з локальним ШІ, — повноцінна дискретна відеокарта Nvidia з підтримкою CUDA. Причина проста: майже весь актуальний софт для локального AI сьогодні написаний під CUDA‑ядра. Це власна технологія Nvidia, яка стала де-факто стандартом для прискорення обчислень у нейромережах на споживчому «залізі».

Без CUDA користувачеві доведеться або шукати рідкісні альтернативні збірки, або миритися з істотним падінням швидкості, коли обчислення виконуються на процесорі чи через менш оптимізовані бекенди. У результаті досвід роботи з локальним AI перетворюється на серію компромісів.

VRAM як головний ресурс: скільки пам’яті потрібно

У класичному геймерському дискурсі відеокарти оцінюють за кількістю ядер, частотами та пропускною здатністю. Для локального ШІ пріоритети зміщуються. Ключовим параметром відеокарти стає обсяг відеопам’яті, щоб модель повністю вміщувалася у VRAM.

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

Навколо мінімально необхідного обсягу відеопам’яті точиться чимало суперечок. Частина спільноти вважає, що можна починати з 8 ГБ. Лучков пропонує більш прагматичний поріг: мінімально комфортним обсягом відеопамʼяті для входу в локальний AI він називає 12 ГБ VRAM. Менше — це вже зона постійних обмежень, де доведеться або сильно стискати моделі, або миритися з повільною роботою.

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

Від 12 до 32 ГБ: які відеокарти підходять для локального ШІ

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

На стартовому рівні Лучков наводить як приклад RTX 5060 Ti або RTX 4070. Обидві карти мають достатній обсяг відеопам’яті, щоб працювати з моделями до 8 млрд параметрів. Це дозволяє запускати сучасні мовні моделі середнього розміру, експериментувати з локальними чатботами, обробляти документи, генерувати текст і базові зображення. Такий набір можливостей він оцінює як адекватний для експериментів, але не для серйозної щоденної роботи, де потрібні більші моделі й вища стабільність.

Окремо у відео згадується партнерська відеокарта ASUS Prime GeForce RTX 5070 White OC 12GB, яку пропонують купити як «вхідний квиток» у безкоштовний AI. Її 12 ГБ VRAM відповідають тому мінімуму, з якого, за словами автора, локальний ШІ починає бути практично корисним, а не лише демонстраційним.

«Золотою серединою» для локального AI Лучков називає відеокарту з 16 ГБ відеопамʼяті. У цьому сегменті він розміщує власну конфігурацію: у своєму ПК автор використовує Nvidia RTX 5080 з 16 ГБ GDDR7. На цій карті він запускає мовні моделі до 14 млрд параметрів і модель Flux 2 для генерації зображень. Усі локальні інструменти, які демонструються у випуску, працюють саме на RTX 5080 з 16 ГБ пам’яті.

Практичні заміри показують, як саме використовується ресурс такої відеокарти. Під час генерації самері великого документа в LM Studio одна з моделей займає близько 15 ГБ відеопам’яті з 16 доступних. При цьому GPU завантажений лише приблизно на 30%, температура тримається на рівні 41 °C, а енергоспоживання становить близько 76 Вт. Модель видає відповідь зі швидкістю приблизно 40 токенів за секунду — це швидше за типову взаємодію з ChatGPT у хмарі. Якість відповідей не дотягує до топових хмарних моделей на кшталт Opus 4.7 від Claude, але для щоденної рутини цього більш ніж достатньо.

Нарешті, у верхньому сегменті розташовується RTX 5090 з 32 ГБ VRAM. На такій карті, за оцінкою Лучкова, можна запускати моделі до 70 млрд параметрів і локальну генерацію відео без компромісів. Це вже рівень, де локальний AI наближається до можливостей великих хмарних моделей не лише в тексті, а й у мультимедіа. Водночас вартість такого рішення відповідає його можливостям і навряд чи буде виправданою для масового користувача.

Таким чином, 16 ГБ VRAM виглядають оптимальним балансом між ціною та функціональністю. Це той рівень, на якому локальний AI починає реально конкурувати з хмарними сервісами у щоденних задачах, не змушуючи користувача постійно думати про обмеження пам’яті.

Як виглядає реальна робота локального ШІ на ПК

Щоб локальний AI не залишався абстракцією, Лучков демонструє конкретні сценарії роботи на своєму ПК з RTX 5080. Один із ключових інструментів — LM Studio. Це застосунок із інтерфейсом, дуже схожим на звичні чат‑боти: користувач вводить запит і отримує відповідь. Важливо, що LM Studio виступає оболонкою для завантаження й запуску будь-яких сумісних мовних моделей офлайн.

Усередині LM Studio доступні як власні моделі Nvidia, наприклад Nemotron 3 Nano 4B, що важить близько 3 ГБ, так і партнерські моделі, зокрема Gemma 4 від Google у різних конфігураціях. Повна версія Gemma 4 займає майже 18 ГБ, що наочно демонструє, чому 16 ГБ VRAM стають практичним мінімумом для комфортної роботи з такими моделями. Для порівняння, мобільна версія Gemma на смартфоні займає близько 3 ГБ, але й можливості в неї відповідно скромніші.

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

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

Другий інструмент, Anything LM, орієнтований на складніші сценарії, але в межах цього фрагмента розмови деталі його роботи лише анонсуються. Важливим залишається інше: усі ці інструменти працюють на одному й тому ж «залізі» — RTX 5080 з 16 ГБ GDDR7, що підтверджує практичну достатність такої конфігурації для широкого спектра задач.

Де зібрати ПК під локальний ШІ

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

У відео він рекомендує збирати ПК для локального AI у компанії Artline і згадує їх онлайн‑конфігуратор. Користувач може прийти з конкретним сценарієм використання — від роботи з мовними моделями до генерації зображень і відео — і отримати збірку, оптимізовану під ці задачі. Такий підхід дозволяє уникнути типових помилок, коли, наприклад, ставлять потужний процесор, але економлять на відеопам’яті, що критично для локального ШІ.

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

Висновок: локальний ШІ як новий стандарт «домашнього комп’ютера»

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

У цій моделі головним стає не бренд сервісу, а конфігурація ПК. Дискретна Nvidia з CUDA, достатній обсяг VRAM — від 12 ГБ для старту до 16 ГБ як «золотої середини» і 32 ГБ для ентузіастів — визначають, які моделі можна запускати, з якою швидкістю й у яких сценаріях локальний AI зможе повністю замінити хмарні сервіси.

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

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

Джерело

YouTube: «Локальний ШІ: як перестати платити за підписки?»

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

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

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

Шіппер прямо заперечує популярний наратив: «AI job apocalypse is not really a thing». Його позиція не ґрунтується на абстрактних міркуваннях — Every за останній рік виросла приблизно з 15 до майже 30 людей, попри те, що це одна з найбільш AI‑орієнтованих компаній у своїй ніші. Якщо AI мав би «з’їдати» робочі місця, саме такі організації мали б скорочувати штат, а не подвоювати його.

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

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

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

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

Саме тому Шіппер називає себе одночасно «extremely AI‑pilled» і «very bullish on humans». Він вірить у моделі, але ще більше — у людей, які вміють ними користуватися.

«Автоматизація — це брехня»: чому кожному агенту потрібна людина

Одна з найрадикальніших тез Шіппера звучить майже як провокація: «Automation is a lie. Every agent needs a human». У світі, де стартапи й корпорації змагаються в обіцянках «повністю автоматизованих» процесів, це звучить контрінтуїтивно. Але його власний досвід роботи з AI‑агентами підштовхує до протилежного висновку.

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

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

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

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

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

Парадокс продуктивності: більше AI — більше роботи

Особистий досвід Шіппера добре ілюструє парадокс, який уже починають відчувати багато знаннєвих працівників: чим кращими стають інструменти, тим більше ми працюємо. У Every всі, включно з нетехнічними співробітниками, активно користуються Codex, Claude Code та Co‑work, щоб виконувати значну частину завдань. Це не зменшило потребу в людях — компанія подвоїла штат. І це не скоротило години роботи засновника — навпаки.

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

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

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

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

Чому PM‑и стануть ключовими гравцями AI‑ери

На тлі розмов про те, що AI нібито «з’їсть» середню ланку менеджменту, Шіппер формулює протилежну позицію: він «super super bullish on PMs». У його баченні саме продукт‑менеджери опиняються в центрі нової архітектури роботи.

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

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

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

Це вимагає нового набору навичок. До класичного інструментарію продукт‑менеджера додаються:

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

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

Full‑stack дизайнери як «супергерої» нової епохи

Другу групу, щодо якої Шіппер демонструє особливий оптимізм, становлять full‑stack дизайнери. Він прямо каже, що вважає їх майбутніми «superheroes». Причина — у поєднанні двох типів важелів: креативного й технічного.

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

Якщо дизайнер здатен:

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

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

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

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

Claude Code, що «прокинувся»: як попередній прогноз підтвердив тезу про розширення роботи

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

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

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

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

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

Креативність проти «слопу»: як виділитися в океані AI‑контенту

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

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

Люди, навпаки, сильні там, де потрібен вихід за межі шаблонів. Вони можуть:

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

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

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

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

Його ключові тези можна звести до кількох ліній:

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

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

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

Джерело

The AI paradox: More automation, more humans, more work | Dan Shipper

У розмові на подкасті Lenny’s Podcast засновник і CEO медіа‑та‑софтверної компанії Every Ден Шіппер описує те, що він фактично вже проживає щодня: роботу в AI‑першому середовищі, де всі — від редакторів до сапорту — працюють через Codex, Claude Code та Co‑work. На цьому тлі він формулює низку контрінтуїтивних прогнозів про майбутнє SaaS, кінець епохи CLI як основного робочого інтерфейсу та появу продуктів, які одночасно обслуговують людей і AI‑агентів.

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

Коли робочий стіл — це Codex: SaaS переїжджає в in‑app браузери агентів

Шіппер прогнозує, що в найближчі роки більшість знаннєвої роботи на комп’ютері відбуватиметься не у звичних десктопних додатках чи браузерних вкладках, а всередині середовищ на кшталт OpenAI Codex або Claude Co‑work. Для Every це вже не теорія: він сам використовує Codex як основне робоче середовище, а команда — як технічні, так і нетехнічні співробітники — проводить значну частину часу в Codex, Claude Code та Co‑work.

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

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

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

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

Bring your own tokens: хто платитиме за інференс і чому це рятує маржу SaaS

Одна з найрадикальніших тез Шіппера стосується економіки AI всередині SaaS. Сьогодні типовий підхід виглядає так: SaaS‑постачальник інтегрує LLM, платить за інференс OpenAI, Anthropic чи іншому провайдеру, а потім намагається «зашити» ці витрати в підписку. Це створює низку проблем — від непередбачуваних рахунків за compute до складності ціноутворення.

Шіппер очікує, що модель зміниться на bring‑your‑own‑tokens. Користувачі приходитимуть у SaaS‑додатки зі своїми власними токенами або обліковими записами в AI‑провайдерів, і саме вони оплачуватимуть інференс, який споживає їхня робота в продукті. SaaS‑вендор у такій схемі більше не виступає посередником між користувачем і моделью на рівні білінгу.

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

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

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

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

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

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

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

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

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

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

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

Кінець епохи CLI як робочого столу: чому термінал програє агентам

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

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

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

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

Цей зсув добре видно на особистих практиках самого Шіппера. Він підтримує inbox zero не за рахунок агресивної фільтрації в поштовому клієнті чи складних скриптів, а завдяки Codex та агенту Cora, якого побудували в Every. Вони обробляють вхідну пошту, готують чернетки відповідей, а він лише переглядає й затверджує. Це типовий приклад того, як AI‑орієнтоване середовище витісняє класичні інструменти, включно з CLI‑автоматизацією.

SaaS як спільний простір: люди, агенти й довгострокова цінність

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

AI‑середовища на кшталт Codex і Claude Co‑work стають новим робочим столом, де живуть агенти й куди користувачі приносять свої токени. SaaS‑продукти переїжджають у вбудовані браузери цих середовищ і фокусуються на тому, що в них найкраще виходить: доменна логіка, надійність, безпека, UX для складних бізнес‑процесів.

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

На цьому тлі твердження Шіппера про те, що він би купував акції SaaS‑компаній зараз, виглядає не просто провокацією, а логічним висновком із його власного досвіду. Every за рік виросла з приблизно 15 до майже 30 людей, залишаючись при цьому однією з найбільш AI‑орієнтованих компаній у своїй ніші. Для нього це прямий емпіричний аргумент: AI не знищує попит на софт і людей, а радше змінює те, як саме вони працюють разом.

Висновок: адаптація замість апокаліпсису

Якщо звести погляди Дена Шіппера до однієї тези, вона звучатиме так: SaaS не помирає, він адаптується до світу, де AI‑агенти — повноправні учасники роботи. Змінюється робочий стіл (Codex замість десктопа), змінюється білінг (bring‑your‑own‑tokens замість прихованого інференсу), змінюються інтерфейси (approval inbox, логи, швидкий rollback замість суто людських UI), змінюється роль CLI.

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

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

Джерело

Оригінальна розмова: The AI paradox: More automation, more humans, more work | Dan Shipper

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

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

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

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

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

Перш ніж перейти до подкастів, варто розібратися загалом, як працює Dreamie.

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

Режим «wind down» запускає вечірню рутину, сигналізуючи, що вже майже час лягати. У мене він налаштований на звук потріскування каміна з м’яким помаранчевим світлом, яке тьмяніє та розгорається, імітуючи справжній вогонь. Каміна мені вистачає приблизно на 25 хвилин, зазвичай у цей час я читаю. Потім Dreamie переходить у режим «noise mask», який я налаштувала як грозу. Але якщо я починаю хотіти спати раніше, можу ввімкнути його одразу. Обраний звук програватиметься до моменту, коли запуститься ваш ранковий сценарій пробудження: світло «світанку» поступово стає яскравішим, поки не спрацює будильник. (Можна обрати й повну тишу, якщо так комфортніше.)

Найкраща функція Dreamie – режим «back to sleep». Якщо ви прокидаєтеся посеред ночі, можна увімкнути «back to sleep», і пристрій відтворюватиме обраний вами медіаконтент: вбудовану дихальну вправу, інший звуковий ландшафт або будь-який подкаст. Ви можете заздалегідь обрати випуск чи шоу, щоб не блукати по інтерфейсу серед ночі й не розбудити себе ще більше. Dreamie можна використовувати з Bluetooth-навушниками, тож якщо ви ділите ліжко з кимось, не заважатимете їй/йому… але тоді доведеться спати в навушниках.

Dreamie підтримує Wi-Fi, тож може завантажувати будь-які подкасти з інтернету. За це можна подякувати архітектурі подкастів: вони поширюються через RSS-стрічки, а це означає, що будь-який розробник може створити власний RSS-клієнт – так Dreamie й отримує доступ до подкастів. (Можна на хвилину оцінити велич RSS – однієї з останніх реліквій відкритого інтернету, яку Spotify активно намагається витіснити на користь свого закритого «садка».)

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

У цьому, звісно, винні лише мої дії, але я знаю, що мої шкідливі звички не унікальні. Одне опитування 2000 дорослих американців показало, що 87% із нас сплять із телефонами в спальні. Мені не потрібні наукові дослідження, щоб зрозуміти: я сплю гірше, коли зависаю в телефоні перед сном, але дані це підтверджують. Завдяки Dreamie я можу просто свайпнути вниз, увімкнути режим «back to sleep» і слухати, як нёрди обговорюють бейсбольну статистику.

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

Dreamie коштує $250 – доволі дорого для будильника. Принаймні тут немає підписок і не потрібно окремого застосунка. Попри велику кількість можливостей, інтерфейс досить простий і нагадує застосунок «Годинник» на iPhone.

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

Я не знаю, чи зможе Dreamie коли-небудь реально підтримувати застосунки на кшталт Libby або Libro.fm – тут є технічні обмеження. Можливо, у майбутньому Dreamie дозволить завантажувати власні медіафайли, включно з аудіокнигами.

Джерело

TechCrunch

Нещодавно я отримав можливість протестувати Bee — носимий AI‑ґаджет на зап’ястя, стартап якого Amazon придбала торік і з того часу встигла додати до нього чимало нових функцій.

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

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

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

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

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

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

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

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

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

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

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

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

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

Як підсумок, Bee — це цікавий ґаджет, який із часом і певними доробками може стати перспективним інструментом для роботи. Як цифровий асистент для особистого життя, утім, він може виявитися занадто нав’язливим для частини користувачів.

Джерело

TechCrunch

Robotaxi вже тут. І водночас — ще ні.

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

Waymo призупинила роботу в Атланті, Далласі, Гʼюстоні та Сан-Антоніо через те, що її роботаксі погано справляються з сильною зливою та затопленими дорогами — зокрема з тим, щоб правильно визначити моменти, коли не можна на них виїжджати. Коли я готувала цей дайджест до відправки, стало відомо, що компанія поширила цю паузу також на Остін і Нешвілл. Це давня проблема для Waymo, яка минулого тижня вже призвела до відкликання програмного забезпечення.

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

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

«Ситуаційні стосунки» чи максимізація корпорацій?

Цього разу я відмовляюся від звичної рубрики «Little bird», щоб зануритися у SpaceX, її IPO та «ситуаційні стосунки» в бізнес-всесвіті Ілона Маска.

Зазвичай я не приділяю стільки уваги космічній тематиці в цьому дайджесті. Але цього тижня зʼявилася заявка SpaceX на IPO, а людина на її чолі одночасно глибоко повʼязана з Tesla. Тож доводиться говорити і про космос, і про те, як Маск використовує ресурси однієї компанії для підтримки іншої.

Тісний звʼязок Tesla та SpaceX не є секретом: Tesla — публічна компанія й розкриває фінансові операції з іншими структурами, повʼязаними з Маском. Нова заявка SpaceX на IPO робить те саме, але з дещо більшою деталізацією. А з огляду на те, що компанія Маска xAI обʼєдналася зі SpaceX, ця заявка фактично виводить усі ці транзакції під дах однієї корпорації.

Наприклад, SpaceX у 2025 році придбала в Tesla комерційні системи зберігання енергії Megapack на суму 506 млн доларів — майже утричі більше, ніж роком раніше. Також SpaceX купила Cybertruckʼів на 131 млн доларів торік. Інфраструктурній компанії Маска The Boring Company SpaceX заплатила 1 млн доларів за будівництво тунелів у місті Бастроп, штат Техас. Соцмережа X, яку минулого року придбала xAI, а згодом обʼєднала зі SpaceX, також витратила 1 млн доларів на оренду площ у The Boring Company.

Окремий епізод — інвестиція Tesla в xAI. Після того, як SpaceX придбала xAI, ця інвестиція була конвертована в частку в капіталі SpaceX.

У майбутньому ці витрати, ймовірно, затьмарять два нові спільні проєкти SpaceX і Tesla: будівництво Terafab, фабрики з виробництва чипів, та Macrohard — AI-платформи, яку компанії розробляють для використання автономних агентів, що мають доповнювати роботу людей.

Усе це підводить до запитання: чи зіллються SpaceX і Tesla в одну компанію?

Угоди та інвестиції

Aboard, стартап із Південної Каліфорнії, який розробляє електричні причіпні будинки з розширеним запасом ходу, залучив 13 млн доларів у раунді pre-Series A під керівництвом Ondine Capital та Llama Ventures. Цікавий факт: компанія запросила Річарда Кіма — відомого автодизайнера, який працював над BMW i3 та i8 і був співзасновником тепер уже неіснуючого EV-стартапу Canoo, — як консультанта.

Quartermaster, стартап з Арлінгтона (штат Вірджинія), що розробляє розподілену мережу сенсорів для кораблів, залучив 43 млн доларів у раунді Series A, який очолили First Round Capital та Quiet Capital.

May Mobility, стартап з розробки технологій автономного транспорту, уклав стратегічну угоду з Ecarx — автотех-компанією, що підтримується засновником Geely Лі Шуфу. За умовами угоди Ecarx поставить May Mobility тисячі спеціально побудованих роботаксі. Компанії планують разом із третім партнером розпочати перші розгортання автономних таксі вже наступного року й вийти на комерційний масштаб до 2028 року. Загальна вартість проєкту оцінюється приблизно у 750 млн доларів за весь період реалізації.

Scapia, індійський стартап у сфері онлайн-бронювання подорожей, залучив 63 млн доларів у раунді під керівництвом General Catalyst за участю чинних інвесторів Peak XV Partners та Z47.

Uber збільшила свою частку й тепер володіє 19,5% німецької компанії з доставки їжі Delivery Hero, повідомляє Bloomberg.

Інші новини та аналітика

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

Глобальна економіка електромобілів має «К-подібну» форму, і є країни, які в цьому процесі відстають.

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

Стартап зі сфери автопілоту Nuro найняв Майкла Манчіні на посаду фінансового директора. Раніше він був CFO в Energy Recovery, Astranis Space Technologies і Aerion Supersonic.

Stellantis — автовиробник, якому належать бренди Jeep і Ram, — залучив стартап Wayve для впровадження безручного керування у своїх авто з 2028 року. Паралельно Stellantis презентував план розвороту бізнесу вартістю 70 млрд доларів, який включає 11 нових моделей для Північної Америки — і навіть кілька нових Chrysler.

Програмне забезпечення Tesla Full Self-Driving (Supervised) тепер доступне в Литві. Це лише друга європейська країна, яка дозволила його використання. Нагадування: вихід FSD на європейський ринок критично важливий для Tesla та Ілона Маска. Це також фінансово значущо для самого Маска, чий пакет опціонів на 1 трлн доларів привʼязаний до досягнення низки продуктових цілей, зокрема досягнення «10 млн активних підписок FSD» до 2035 року.

Лікар із Сан-Франциско, який подав до суду на Waymo через те, що система ідентифікації компанії помилково визначила його як терориста, відкликав позов після того, як компанія розвʼязала проблему.

Ще трохи про електромобілі: оновлений Nissan Leaf

Останній раз я їздила на Nissan Leaf два роки тому, коли тестувала Nissan Leaf SV Plus 2024 року вартістю 37 815 доларів (з урахуванням доставки). Тоді я описала досвід як «змішаний». Нещодавно я знову повернулася за кермо Leaf, цього разу — версії Nissan Leaf Platinum+ 2026 року вартістю 42 635 доларів з доставкою та додатковими опціями на кшталт двоколірного кузова та фірмових килимків.

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

Минулого разу я нарікала на брак технологій для авто, що коштує понад 30 тисяч доларів, — зокрема на відсутність якісної камери заднього виду. Тепер кілька помітних покращень ідуть уже в базі й частково нівелюють цю критику: зʼявилася 360-градусна камера, бездротовий Apple CarPlay та Android Auto, а також адаптивний круїз-контроль. Цього разу я була справді рада повернутися за кермо Nissan Leaf.

Джерело

TechCrunch

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

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

NoshOne Kitchen Robot – $1 499

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

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

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

Nosh One вже доступний для передзамовлення на Kickstarter, поставки очікуються влітку 2026 року.

StirMate Automatic Pot Stirrer – $89,99

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

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

Такий пристрій може стати й корисним інструментом доступності для людей з обмеженою мобільністю або хронічним болем.

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

KitchenArm Smart Bread Machine – $149,99

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

KitchenArm Smart Bread Machine має 29 автоматичних програм із 21 режимом для хліба, зокрема білий, французький, цільнозерновий, житній і солодкий хліб, а також режими для йогурту, варення та кекса. Є й повністю налаштовуваний режим Homemade, де можна вручну змінювати час вимішування й вистоювання.

De’Longhi Rivelia Espresso Machine – $1 499,95

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

De’Longhi Rivelia — відносно нова модель, яка привернула увагу завдяки «розумній» персоналізації. Окрім автоматичного помелу зерен, приготування еспресо та спінювання молока, Rivelia підтримує до чотирьох користувацьких профілів, запам’ятовує улюблені напої й міцність, а з часом адаптує рекомендації, виходячи з ваших звичок. Функція Coffee Routines навіть може пропонувати різні напої залежно від часу доби.

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

Nama M1 Plant Milk Maker – $449

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

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

KitchenArt Auto-Measure Spice Carousel – $45,95

KitchenArt Auto-Measure Spice Carousel — один із найпростіших продуктів у цьому списку, але він вирішує дуже реальну проблему: випадково висипати півбанки часникового порошку в страву, бо кришка зі спеціями раптово підвела. Ця обертова карусель вміщує до 12 видів спецій і дозує їх порціями по 1/4 чайної ложки або дає можливість насипати звичайним потоком через вбудовані носики.

Ніяких застосунків, ШІ чи складного налаштування — просто справді практичний кухонний інструмент.

Джерело

TechCrunch

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

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

«Усі втрачають гроші», — каже Чі Сю, засновник і CEO компанії Xreal, що розробляє смартокуляри та давно співпрацює з Google. Ми зустрілися на конференції Google I/O в Маунтін-В’ю минулого тижня, де він презентував Xreal Project Aura — нову спробу створити XR-окуляри, якими люди справді захочуть користуватися.

«Те, що ми робимо, дуже складно», — додає він.

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

Ця потенційна точка повороту пов’язана з Meta, яка у 2023 році запустила в партнерстві з Ray-Ban одну з перших лінійок окулярів, що справді добре продаються. Втім, варто зазначити, що підрозділ Reality Labs, який відповідає за ці пристрої, досі працює зі значними збитками.

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

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

Втім, в обмін на незручність додаткового блока користувач отримує ширший набір можливостей, зокрема занурюваний додаток Google Maps, VR-відео на YouTube і «додаток для малювання», який завдяки трекінгу рук дозволяє створювати голографічні зображення, видимі лише вам. Також заявлені ігри з керуванням рухами рук та базові можливості перегляду вебсторінок.

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

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

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

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

Джерело

TechCrunch

Нещодавно мені випала нагода поговорити з Френсісом де Соуза, операційним директором Google Cloud, за лаштунками одного заходу в Лос-Анджелесі. Серед навколишнього гамору де Соуза, який говорить спокійно й виважено, як університетський професор, поділився корисними порадами для компаній, що зараз проходять через етап «моменту безпеки ШІ». На його думку, «буде перехідний період, а потім, гадаю, ми вийдемо в кращу точку».

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

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

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

Він також наголосив, що ландшафт загроз змінився настільки фундаментально, що старі моделі захисту стали надто повільними. За його словами, середній час між початковим зламом і переходом до наступного етапу атаки скоротився з восьми годин до 22 секунд, а поверхня атаки вийшла далеко за межі традиційного мережевого периметра. «Окрім вашої звичної інфраструктури, тепер у вас є моделі. Є конвеєри даних для їхнього навчання. Є агенти, є підказки (prompts). Усе це має бути захищеним».

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

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

Однак, навіть якщо ШІ бере на себе дедалі більше робіт із захисту, людей, які здатні цим керувати, бракує — а вразливості, які сам ШІ породжує, множаться швидше, ніж команди безпеки встигають їх усувати. «Нам потрібні люди, які впораються з “bug-pocalypse” — апокаліпсисом багів», — сказала CISO LinkedIn Лея Кісснер в інтерв’ю New York Times цього тижня, додавши, що не очікує, що індустрія зрозуміє безпеку ШІ в сталому, довгостроковому вимірі бодай у найближчі кілька років.

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

Род Данан, генеральний директор платформи для підготовки до співбесід Prentus, розповів, що його рахунок сягнув $10 138 приблизно за 30 хвилин після того, як зловмисники скористалися скомпрометованим ключем API. Ісуру Фонсека, розробник із Сіднея, який опинився в подібній ситуації, прокинувся й побачив нарахування приблизно на 17 000 австралійських доларів, хоча вважав, що встановив ліміт витрат у $250. Ніхто з них не знав, що автоматичні системи Google підвищили їхній тарифний план з огляду на історію акаунта, фактично збільшивши стелю витрат до $100 000 без явної згоди користувачів.

Після публікації першого матеріалу The Register Google повернув обом клієнтам кошти. Втім, компанія повідомила виданню, що не планує змінювати свою політику автоматичного підвищення тарифу, пояснюючи це тим, що пріоритезує запобігання збоям у сервісі, а не дотримання заявлених користувачами бюджетів.

Тим часом постає окреме питання: що відбувається, коли розробник намагається все негайно вимкнути. На цьому тижні The Register написало про дослідження компанії Aikido, яке показало, що навіть ті розробники, які помічають скомпрометований ключ і одразу його видаляють, можуть залишатися під загрозою. За даними Aikido, зловмисники можуть продовжувати використовувати цей ключ до 23 хвилин, оскільки відкликання ключа Google розповсюджується інфраструктурою поступово. Дослідник Aikido Джозеф Леон розповів The Register, що в цей проміжок імовірність проходження запитів непередбачувана — у деякі хвилини понад 90% запитів усе ще автентифікувалися — і зловмисники можуть використати цей час, щоб вивести файли та кешовані дані розмов із Gemini.

Леон також зазначив, що нові формати облікових даних Google, схоже, не мають такої проблеми: облікові дані сервісних акаунтів відкликаються приблизно за п’ять секунд, а новий формат ключів Gemini із префіксом AQ — приблизно за хвилину. «Обидва працюють у масштабі Google, — написав він у супровідній публікації Aikido. — Обидва свідчать, що технічно Google API-ключі теж можна зробити такими». Іншими словами, за словами Леона, 23-хвилинне «вікно» — це не технічне обмеження, а питання пріоритетів компанії.

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

Джерело

TechCrunch

Я б майже не хотів називати Meshchera грою в жанрі match-3, бо це ніби занижує, наскільки вона захоплива. Але формально це гра на полі 6×6 клітинок, де потрібно групувати однакові плитки в кластери по три й більше, щоб вони зливалися та перетворювалися на інші, цінніші плитки. Тож так ми її й описуватимемо. Водночас атмосфера тут просто зашкалює — те, чого зазвичай не очікуєш від такого типу ігор. Малюнки надзвичайно деталізовані, а на фоні грає музика, в якій легко загубитися.

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

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

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

Наразі в Meshchera є 10 челенджів, і розробник обіцяє додати ще. Гра вийшла справді дуже вдалою та відчувається як проєкт, до якого можна повертатися нескінченно. Вона вже оселилася в моїй папці «must-have» ігор для Playdate.

Джерело

Engadget

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

Кібервійна як нова норма

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

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

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

Женевська конвенція і «біла пляма» кіберпростору

Окремий акцент робиться на міжнародному гуманітарному праві. Класичні Женевські конвенції регулюють:

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

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

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

«Усіма можливими формами та методами»

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

У цьому контексті кібератаки:

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

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

Після війни: нові конвенції і нові обмеження

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

Ймовірно, майбутні оновлені конвенції:

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

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

Джерело

YouTube: «Що з є*алом, вас зламали? Чому атакувати росіян — це наше законне право»

У розмові на подкасті Lenny’s Podcast підприємець і CEO медіа‑та‑софтверної компанії Every Ден Шіппер описує майбутнє офісної роботи так, ніби воно вже настало в його команді. Every за рік виросла приблизно з 15 до майже 30 людей, залишаючись однією з найбільш «AI‑пілд» компаній: редактори, сейлзи, сапорт і дизайнери щодня працюють через Codex, Claude Code та Co‑work. На цьому практичному досвіді Шіппер будує доволі конкретний прогноз: найближчим часом основним робочим середовищем стануть AI‑орієнтовані «робочі столи» на кшталт Codex чи Claude Co‑work, а в кожній компанії з’явиться один загальний «суперагент» у Slack, якому співробітники регулярно делегуватимуть завдання.

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

Новий робочий стіл: Codex і Claude Co‑work замість десктопа

Ключова теза Шіппера стосується того, де фактично відбувається знаннєва робота. Сьогодні більшість людей живе між браузером, поштою, Slack і набором SaaS‑інструментів. У найближчий рік, вважає він, цей шар буде «накритий» новим середовищем — Codex або Claude Co‑work, які стануть головною робочою поверхнею.

Шіппер сам уже працює саме так: OpenAI Codex — його основне щоденне середовище. Через вбудований браузер він відкриває інші інструменти, включно з власним markdown‑редактором Proof, який команда Every створила як онлайн‑редактор для письма. Codex у цьому сценарії — не просто чат із моделлю, а операційна система поверх усіх інших додатків.

Звідси випливає кілька важливих наслідків.

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

По‑друге, SaaS‑додатки в цьому світі все частіше житимуть не як самодостатні «місця роботи», а як сервіси, до яких звертається агент. Шіппер прямо формулює це: більшість робочих SaaS‑інструментів використовуватимуться всередині in‑app‑браузерів Codex чи Claude Co‑work, а не через власні AI‑функції, вбудовані в кожен продукт окремо.

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

По‑третє, змінюється й інтерфейс для технічних користувачів. На тлі моди на повернення до терміналу й CLI Шіппер стверджує, що «ми проспідранили еру CLI» і що командний рядок як основна робоча поверхня для більшості користувачів — уже минуле. У Every, за його словами, більшість технічних людей більше не використовують CLI як головне середовище: вони працюють через AI‑інструменти на кшталт Claude Code, спілкуючись із комп’ютером природною мовою.

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

Один суперагент у Slack замість сотні персональних ботів

Друга опорна ідея Шіппера — поява в кожній компанії хоча б одного загального «суперагента» в Slack. Це не вузький бот для HR чи сапорту, а універсальний агент, якому будь‑який співробітник може регулярно делегувати роботу.

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

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

Спільного агента легше:

керувати як продуктом — у нього є єдина конфігурація, єдині інтеграції, єдина політика доступу до даних;

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

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

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

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

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

Чому кожному агенту потрібен «людський власник»

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

Цей власник:

розуміє бізнес‑контекст, у якому працює агент;

налаштовує інтеграції, доступи, політики безпеки;

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

слухає користувачів усередині компанії, збирає фідбек, пріоритизує нові можливості.

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

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

Це добре видно навіть на особистих прикладах. Сам Шіппер підтримує «inbox zero» не магією, а завдяки поєднанню Codex і внутрішнього email‑агента Cora, які обробляють пошту й готують чернетки відповідей. Але остаточні рішення, пріоритизація й тон комунікації залишаються за людиною. Агент знімає рутину, але не замінює відповідальність.

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

Forward deployed engineer як новий ключовий гравець

Хто має стати таким власником? Шіппер пропонує конкретну відповідь: роль, яку він називає forward deployed engineer. Це людина, яка одночасно глибоко технічна й максимально наближена до бізнес‑користувачів.

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

розуміє щоденні болі цих команд;

може швидко прототипувати й запускати агентів під реальні задачі;

говорить мовою користувачів, а не лише мовою коду;

здатен перетворювати розмиті запити на чіткі сценарії для агентів.

У контексті суперагента в Slack саме forward deployed engineer стає його де‑факто продукт‑менеджером і техлідом одночасно. Ця людина:

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

налаштовує права доступу, щоб агент бачив рівно стільки, скільки потрібно;

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

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

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

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

Від спільних агентів до персональних: що змінить зростання автономії моделей

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

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

Коли ж моделі стануть значно більш автономними, персональний агент зможе:

самостійно будувати й підтримувати власні робочі процеси;

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

адаптуватися до стилю роботи конкретної людини, не потребуючи щоденного «донавчання».

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

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

Як виглядає перехідний період: приклади Shopify, Ramp і Every

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

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

Every, своєю чергою, демонструє, як виглядає компанія, де AI‑середовище вже стало повсякденністю. За рік команда виросла майже вдвічі, залишаючись при цьому «AI‑форвард»: усі, включно з нетехнічними співробітниками, працюють через Codex, Claude Code і Co‑work. Це створює «кишеню майбутнього», як описує Шіппер: середовище, де всі — ранні адоптери, де нові моделі тестують ще до релізу, а робочі процеси постійно перебудовуються під можливості агентів.

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

Висновок: архітектура роботи змінюється тихо, але радикально

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

По‑перше, змінюється базовий робочий шар: замість набору розрізнених додатків і CLI‑інструментів з’являються AI‑орієнтовані середовища на кшталт Codex і Claude Co‑work, які стають головним робочим столом для знаннєвої роботи.

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

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

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

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

Джерело

The AI paradox: More automation, more humans, more work | Dan Shipper

Коли говорять про «AI‑нативні» компанії, зазвичай уявляють невеликі команди, де більшість завдань виконують моделі, а людей стає дедалі менше. Досвід Every — медіа‑та софтверної компанії, яку очолює співзасновник і CEO Ден Шіппер, — демонструє протилежне. За рік команда виросла приблизно з 15 до майже 30 людей, залишаючись при цьому однією з найбільш AI‑орієнтованих компаній у галузі.

Every фактично працює як живий експериментальний майданчик: усі співробітники, включно з редакторами, сейлзами й операційниками, щодня працюють у середовищах на кшталт OpenAI Codex, Claude Code та Claude Co‑work. Це не «додаткові інструменти», а основний робочий простір. І саме через цю радикальну інтеграцію AI у повсякденну роботу Every дає рідкісний погляд на те, як може виглядати офісна праця вже найближчими роками.

Компанія, де всі — AI‑ранні адоптери

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

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

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

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

Codex як нова «операційна система» роботи

Найрадикальніша зміна в особистій роботі Дена Шіппера — те, що він фактично переселився в OpenAI Codex. Для нього це не просто чат‑інтерфейс, а головне робоче середовище, щось на кшталт «операційної системи для знань».

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

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

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

Inbox zero як сервіс: як Cora і Codex розгрібають пошту CEO

Один із найпоказовіших прикладів того, як Every перетворює AI на інфраструктуру повсякденної роботи, — це електронна пошта Дена Шіппера. Він підтримує стан inbox zero не завдяки залізній дисципліні, а завдяки зв’язці Codex і власного email‑агента Cora.

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

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

Той факт, що CEO компанії з майже 30 людьми може реально тримати inbox zero, — не просто особиста перемога в боротьбі з хаосом. Це демонстрація того, як можуть виглядати робочі процеси менеджерів і керівників у найближчому майбутньому, якщо AI‑агенти стануть стандартною частиною корпоративної інфраструктури.

Proof: AI‑нативний редактор, який живе всередині агента

Ще один ключовий елемент AI‑нативного робочого середовища Every — власний онлайн‑редактор Proof. Це markdown‑редактор, створений спеціально для письма в епоху AI, але важливий не лише сам продукт, а й те, як він використовується.

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

Ключова деталь: Proof є open source. Це означає, що будь‑яка команда може взяти той самий підхід — AI‑нативний markdown‑редактор, який живе всередині агента, — і адаптувати його під власні потреби.

Відкритість коду тут важлива не лише з міркувань спільноти. Вона підкреслює, що Every не намагається монополізувати саму ідею AI‑нативного письма. Навпаки, компанія демонструє робочий патерн: основне середовище — агент (Codex чи Claude Co‑work), а всі інші інструменти — це «вкладки» всередині нього. Proof — лише один приклад такого інструмента, але саме він показує, як може виглядати контент‑продукція в епоху, коли AI стає постійним спів‑автором.

Коли агент сам пише баг‑репорти: як Every автоматизує зворотний зв’язок

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

Продукти Every приймають звіти про помилки, сформовані агентами, причому на рівні, який зазвичай очікують від уважного QA‑інженера. У таких репортах є кроки для відтворення (repro steps), гіпотези щодо причин помилки на рівні коду, а також структурована інформація, потрібна для подальшої роботи розробників.

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

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

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

Весь офіс — у режимі «AI‑лабораторії»

Ключова відмінність Every від більшості компаній, які «експериментують з AI», полягає в масштабі. Тут немає чіткого поділу на «AI‑команду» й «усіх інших». Усі — від авторів до сапорту — працюють із Codex, Claude Code та Co‑work як із базовими інструментами.

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

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

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

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

Що це говорить про майбутнє офісної роботи

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

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

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

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

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

Висновок: AI як новий робочий шар, а не заміна людей

Every сьогодні виглядає як компанія з майбутнього: майже 30 людей, усі — AI‑ранні адоптери, основний робочий простір — Codex і Claude Co‑work, письмова робота — через Proof, пошта CEO — через Cora, а баг‑репорти — від агентів, які самі формують GitHub‑issues.

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

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

Джерело

The AI paradox: More automation, more humans, more work | Dan Shipper

Мова програмування C# сьогодні лежить в основі величезної екосистеми .NET, корпоративних застосунків, ігор на Unity та хмарних сервісів. В інтерв’ю на каналі The Pragmatic Engineer творець C#, TypeScript, Turbo Pascal і Delphi Андерс Гейлсберг розповів, як саме організували роботу над дизайном C# — і чому для цього вистачило всього шести людей.

Команда з шести: чому «малий штаб» працює краще

На старті розробки C# не було великої армії інженерів. Замість цього зібрали невелику групу — приблизно шість–сім людей. Усі вони вже мали досвід створення або розробки мов програмування. Це означало:

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

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

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

Процес був чітко структурований. Команда:

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

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

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

Дизайн через критику: ідеї мають витримати «обстріл»

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

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

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

Це створювало культуру, де:

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

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

Чому цей підхід досі актуальний

Історія створення C# показує, що:

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

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

Джерело

Anders Hejlsberg: C# was designed by 6 people — The Pragmatic Engineer