Український техноблогер Іван Лучков у великому розборі про довговічність гаджетів присвятив окремий блок тому, як насправді гинуть смартгодинники та TWS‑навушники. Перегрів і зарядка — лише частина історії. Рівно так само небезпечні душ, сауна, гаряча пара у ванній кімнаті, піт на контактах і звичка зберігати техніку в сирих приміщеннях. А ще — постійний стрес крихітних акумуляторів у навушниках та елементарний бруд.

IP68 і «5 ATM»: чому ці цифри зовсім не про водоспади

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

IP — це скорочення від «Ingress Protection», тобто захист від проникнення. Перша цифра в IP відповідає за тверді частинки. Шістка в IP68 означає повну пилонепроникність. Друга цифра — це вже вода.

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

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

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

Чому душ убиває годинники частіше, ніж річка

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

Герметичність годинника забезпечують дуже тонкі гумові кільця‑ущільнювачі (O‑ring) та спеціальний силікатний клей. Ця система розрахована на воду, а не на коктейль із гелю для душу, шампуню та мила.

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

по‑перше, хімічно руйнують клей, що тримає компоненти й ущільнювачі;

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

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

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

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

Піт, сіль і зарядка: як спорт добиває контакти

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

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

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

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

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

Невидима волога: гаряча пара й конденсат проти мікросхем

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

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

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

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

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

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

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

Чому TWS-навушники рідко доживають до двох років

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

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

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

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

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

Коли «поламався» звук: майже завжди винен бруд

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

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

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

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

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

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

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

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

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

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

Джерело

YouTube: 90% людей НИЩАТЬ свої гаджети! Як зберегти техніку?

Американський підприємець і розробник Остін Маркезе у своєму детальному гіді про побудову самооптимізуючих систем на базі Claude Code пропонує досить приземлений погляд на “автономний” AI. Замість модної риторики про повністю самостійну систему він розкладає по поличках ризики такої автономії й показує, як організувати безпечний контур змін через один центральний скіл improve system і трирівневий bucket‑ревʼю.

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

Міф про “справжню” self‑improving систему

На четвертому кроці свого B.U.I.L.D‑фреймворку Маркезе переходить до головного — improvement loop. Він формулює типове хибне уявлення: більшість людей вважає, що якщо система самооптимізується, то вона має працювати “повністю сама по собі”, без будь‑якого людського втручання.

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

Щоб пояснити це інтуїтивно, він звертається до фітнес‑аналогії. Уявімо систему, яка “автоматично покращує вашу фізичну форму”.

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

Друга версія — augmented‑підхід. Система формує план тренування й пропонує його на затвердження. Людина дивиться, схвалює або коригує, і тільки потім “автоматичний тренажер” виконує програму вже без її участі.

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

Один скіл для всіх змін: improve system як центр самооптимізації

Щоб контролювати розвиток системи, Маркезе пропонує не розпорошуватися по десятках дрібних сценаріїв, а винести всю логіку самооптимізації в один скіл — improve system. Саме він аналізує нові дані, поведінку системи й пропонує зміни. Головна ідея: будь‑яке “покращення”, яке система збирається внести, має спершу пройти через категоризацію за трьома “кошиками”.

Через improve system проходить усе — від дрібних правок у wiki до створення нових скілів. Це дозволяє уніфікувати процес: немає хаотичних змін у різних місцях, усі ініціативи спочатку маркуються за рівнем ризику.

Сам скіл, за описом Маркезе, спроєктований так, щоб на виході завжди був структурований список пропозицій, уже розкладений по bucket‑ам. Далі питання лише в тому, як ви обходитесь з кожним із трьох типів змін.

Bucket 1: auto approve — дрібні правки й “сміття” без вашої участі

Перший кошик — auto approve. Сюди потрапляє те, що Маркезе прямо називає low‑risk: прибирання “жиру” у даних, усунення “data bloat”, додавання очевидних лінків між файлами, технічні або косметичні виправлення, які не змінюють суті процесів.

Усе, що потрапляє в цей bucket, Claude застосовує автоматично в рамках самого скіла improve system. Людина про ці зміни може навіть не знати: система просто вносить правки й паралельно веде change log. Якщо потрібно, до цього журналу можна повернутися й подивитися, що саме відбулося, але за замовчуванням він не вимагає уваги.

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

Bucket 2: need signoff — зміни, які можуть зламати якість

Другий кошик — need signoff. Це зона підвищеного ризику, яку Маркезе описує як “higher stake stuff”: редагування скіла, створення нового скіла, будь‑яка дія, де неправильне рішення здатне погіршити якість вихідних результатів.

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

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

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

Bucket 3: more context required — коли AI не вистачає інформації

Третій кошик — more context required. Сюди потрапляють ситуації, коли improve system щось проаналізував, бачить потенційну можливість покращення, але не може самостійно вирішити, що саме робити.

Маркезе описує цей bucket як “просто речі, де вам потрібно надати більше інформації”. Це не обов’язково високо ризикові зміни, радше ті, де бракує доменної експертизи або бізнес‑контексту, який не очевидний з даних.

Важливий нюанс: пропозиції з bucket 2 і bucket 3 об’єднуються в один і той самий файл для ревʼю. Тобто користувач отримує єдину точку входу для всіх змін, що потребують уваги — як для тих, що вимагають “так/ні”, так і для тих, де потрібно дописати контекст. Це зменшує фрикцію: замість того, щоб стрибати по різних місцях, достатньо періодично відкривати один документ і проходити його “чек-листом”.

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

Після опису трьох bucket‑ів Маркезе формулює ту саму “вісь рішень”, на якій і розташовується його модель.

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

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

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

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

Висновок: self‑improving як співпраця, а не заміна людини

Модель bucket‑ревʼю, яку описує Остін Маркезе, пропонує практичну відповідь на головний страх розробників і продактів: “А що, якщо система сама себе зламає?” Замість того щоб або повністю віддати кермо Claude, або ж завалити себе нескінченними ревʼю, він радить поставити один скіл improve system у центрі всієї еволюції й навчити його чітко сортувати зміни за рівнем ризику.

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

Для тих, хто будує складні LLM‑проєкти на базі Claude Code й побоюється дрейфу якості при автоматичному редагуванні скілів чи бази знань, цей підхід дає зрозумілий і відтворюваний фреймворк. Він не обіцяє магії, зате чітко окреслює, де саме варто залишати людину “в контурі” — і як при цьому не перетворитися на вузьке місце у власній самооптимізуючій системі.

Джерело

How to Build A Self-Improving System with Claude Code

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

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

Приватний дисплей як новий стандарт для Android‑флагманів

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

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

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

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

Galaxy S27 Pro: спроба поєднати приватність і комфорт

На тлі розкрутки приватних екранів Samsung, за інсайдами, готує і структурну зміну у власній лінійці. Компанія планує додати до сімейства Galaxy модель S27 Pro — окремий флагман, який має закрити одразу кілька давніх претензій до бренду.

Концепція звучить досить амбітно. Йдеться фактично про смартфон рівня Galaxy S27 Ultra, але без стилуса S Pen, із більшим акумулятором і при цьому зі скромнішою діагоналлю — приблизно 6,47 дюйма. Для тих, хто втомився від «лопат» і шукає справді потужний, але більш компактний апарат, це виглядає як майже ідеальна конфігурація.

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

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

Однак саме тут і криється найбільша технологічна інтрига.

Сліпа зона Samsung: приватність є, якість страждає

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

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

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

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

І ось саме в цю тріщину в конструкції Samsung збираються заходити китайські вендори.

Китайська відповідь: шанс виграти з першої спроби

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

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

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

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

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

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

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

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

Samsung має гандикап у часі та впізнаваності: саме Galaxy S26 Ultra змусив масову аудиторію уважно подивитися на приватний режим. Однак збереження нинішньої якості картинки в S27 Pro й інших моделях відкриває вікно можливостей для китайських брендів. Якщо вони справді покажуть приємніші для очей приватні дисплеї вже цієї осені, ринок отримає рідкісний випадок, коли копіювання тренду обертається перемогою над його першовідкривачем.

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

Джерело

YouTube — «iPhone ВТРАТИТЬ $1300 за рік: Прокляття Samsung діє?»

У подкасті Lenny’s Podcast продакт та інженерний лід десктоп‑додатку Codex в OpenAI Ендрю Амброзіно розповідає, як виглядає продуктовий менеджмент на передовій генеративного ШІ. Один із ключових викликів, який він описує, — планування в середовищі, де моделі стрибкоподібно змінюють свої можливості за лічені місяці, а значить — змінюють і шанси функцій на успіх.

Як виглядає роадмап, коли будь‑який план на дев’ять місяців уперед ризикує стати фантазією вже наступного кварталу? І як балансувати між амбіційними AGI‑формами продукту та реальним рівнем можливостей моделей «прямо зараз»?

Хибна точність: чому детальні плани на 9 місяців — самообман

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

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

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

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

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

Щоб не впасти в хаос повної імпровізації, в Codex сформували іншу опору: системне прототипування «наперед».

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

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

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

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

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

Codex, який би провалився: як три місяці моделей змінили долю продукту

Один із найяскравіших прикладів ролі таймінгу — сам десктоп‑додаток Codex.

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

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

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

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

Коли надто «AGI‑pilled»: провал форми, що випередила час

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

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

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

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

Фічі «наперед»: артефакти для майбутніх моделей, а не релізи «за будь-яку ціну»

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

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

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

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

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

Плутанина процесу: коли виглядає як продакшен, але це ще дизайн

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

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

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

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

Як планувати, коли форма стабільна, а інтелект — ні

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

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

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

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

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

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

Джерело

OpenAI Codex lead on the new shape of product work | Andrew Ambrosino

Для багатьох людей лід у напої майже такий самий важливий, як і сам напій. Саме на таку аудиторію орієнтувалася Govee, розробляючи свій новий льодогенератор GoveeLife Smart Nugget Ice Maker Pro. Цей «розумний» гаджет для дому вартістю близько $500 адресований тим, хто обожнює так званий «правильний лід» — м’які, жувальні крижинки, знайомі за напоями у фастфудах і ресторанах.

За словами Govee, стильний настільний апарат видає перші порції nugget-льоду вже через шість хвилин — і це справді підтверджується тестуванням. За добу пристрій може виробити до 60 фунтів (приблизно 27 кг) льоду, а кошик для льоду місткістю 3,5 фунта автоматично поповнюється, щойно ви дістаєте з нього кригу.

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

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

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

Льодогенератор також підтримує голосові команди через Alexa та Google Assistant, тож коротке «Hey Google, start the ice maker» перетворюється на порцію свіжого льоду.

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

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

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

Габарити пристрою — 17,28 дюйма вглиб, 13,98 дюйда завширшки і 17,01 дюйда заввишки (приблизно 44×35×43 см), вага — близько 50 фунтів (понад 22 кг). Льодогенератор займає чимало місця на кухонній стільниці й виглядає масивно, особливо в невеликій кухні. За своїм доволі стриманим, «домашньо-смартовим» дизайном він навіть не одразу читається як льодогенератор.

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

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

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

Чи підходить вам GoveeLife Smart Nugget Ice Maker Pro, залежить від того, наскільки сильно ви цінуєте можливість мати nugget-лід «за вимогою» і як часто насправді його використовуватимете. Якщо ви рідко додаєте лід у напої, то, очевидно, такий доволі нішевий пристрій вам не потрібен.

Але якщо ви постійно п’єте напої з льодом і обожнюєте саме такий формат «good ice», цей льодогенератор може виявитися тим гаджетом, про який ви навіть не підозрювали, що він вам потрібен.

Джерело

TechCrunch

Після того як Австралія першою у світі запровадила заборону на соцмережі для користувачів молодше 16 років, уряд вирішив посилити покарання за її порушення. В офіційному повідомленні австралійський уряд оголосив, що максимальний штраф для соцмереж, які не дотримуються мінімального віку користувачів, зросте з 49,5 мільйона до 99 мільйонів австралійських доларів, тобто більш ніж до 68 мільйонів доларів США.

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

Разом із підвищенням максимального штрафу уряд Австралії розширює повноваження свого eSafety Commissioner Джулі Грант. Тепер комісар може вимагати від соцмереж надання доказів того, як саме вони не допускають реєстрацію акаунтів дітьми до 16 років.

Важливо, що відомство з онлайн-безпеки зможе збирати докази дотримання заборони не лише від самих соцмереж, а й від третіх сторін – наприклад, постачальників систем вікової верифікації чи магазинів застосунків, йдеться у повідомленні. Агентство також заявило, що й надалі «активно розслідує можливі порушення» з боку Facebook, Instagram, Snapchat, TikTok та YouTube.

Джерело

Engadget

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

Про це розповідає Ендрю Амбросіно, продуктово‑інженерний лід Codex із бекграундом дизайну, розробки, продакт‑менеджменту та заснування стартапів. У розмові на подкасті Lenny’s Podcast він описує, як виглядає «колапс ролей» у реальній роботі, чому ліквідація продакт‑функції — помилка, як працює модель zone defense для продактів і чому в епоху агентів «усі трошки менеджери».

Колапс ролей є, зникнення спеціальностей — ні

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

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

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

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

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

Небезпечна спокуса «прибрати ролі»

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

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

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

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

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

«Ти те, що ти робиш в середньому»: нова оптика на функції

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

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

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

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

У підсумку посадовий рядок у профілі стає менш важливим, ніж відповідь на питання: що ця людина реально робить 80% свого часу?

Zone defense: як продакти закривають хаос «будь‑хто може зібрати будь‑що»

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

На цьому тлі продакт в Codex — не класичний «власник фічі», який сидить поруч із командою, а радше гравець у схемі zone defense. Амбросіно описує це як «force‑directed activity»: продакт‑організація постійно дивиться, де в компанії з’являються прогалини, і розподіляє людей так, щоб досягти «company coverage».

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

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

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

Усі трошки менеджери: як агенти змінюють і IC, і керівників

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

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

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

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

Легше перейти роль, складніше стати професіоналом

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

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

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

Висновок: роль як середнє, а не як ярлик

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

Але за цією гнучкістю ховається чітка рамка:

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

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

Джерело

OpenAI Codex lead on the new shape of product work | Andrew Ambrosino

На YouTube-каналі «Канал Лучкова» Іван Лучков розбирає нову ігрову консоль Steam Machine від Valve (у відео стабільно звучить як «Steam машин» чи «Welf» замість Valve) як симптом глибших проблем індустрії: дефіциту оперативної пам’яті, дивних схем бронювання і технічної «кремнієвої лотереї», яка робить однакові на папері приставки нерівними в реальному житті.

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

Дорога «коробка» дешевша за ПК, але дорожча за PlayStation

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

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

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

RAM як інструмент тиску: «мафія» диктує умови

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

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

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

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

Бронювання як рулетка: «лист щастя» замість передзамовлення

Через «дикий дефіцит» оперативної памʼяті просте нарощування виробництва Steam Machine виявляється технічно і економічно нереалістичним. Навіть купити 100 консолей «просто так» — тобто просто розмістити стандартне велике замовлення — неможливо.

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

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

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

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

Кремнієва лотерея: одна назва, різна швидкість

Найнеприємнішим наслідком дефіциту памʼяті стала так звана «кремнієва лотерея». Через те, що виробнику доводиться буквально скуповувати ОЗП «де завгодно і як завгодно», аби хоч якось тримати конвеєр у русі, Steam Machine виходять дуже нерівними.

У мережі вже з’явилися підтвердження, що консолі збирають з того, що є під рукою. Це означає, що дві приставки з однією й тією ж назвою моделі можуть істотно відрізнятися за швидкістю. Комусь пощастить — і йому дістанеться консоль з швидкою двоканальною памʼяттю. Інший отримає версію з одноканальною, яка, за оцінками, виявляється на 10–15% повільнішою.

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

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

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

Втеча на ПК: коли Steam більше не привʼязаний до коробки

На цьому тлі цікавим виглядає паралельний крок Valve у бік відкритішої платформи. Компанія офіційно оголосила, що вже дає можливість встановити Steam (у контексті — оптимізоване програмне середовище, яке використовується в Steam Machine) на ПК на базі AMD і веде перемовини з Nvidia, щоб усе коректно працювало і на її конфігураціях.

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

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

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

Коли консолі перетворюються на азартну гру

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

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

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

Джерело: https://www.youtube.com/watch?v=qMj8b9AXbmk

Добірка матеріалів цього тижня демонструє, що увага до автоматизованої системи керування Tesla під назвою Full Self-Driving (Supervised) не лише не спадає, а й зростає. Фатальна аварія за участі Tesla, що в’їхала в житловий будинок у Техасі й призвела до загибелі 76-річної жінки, отримала широке висвітлення в національних медіа після того, як водій повідомив поліції, що на момент зіткнення був увімкнений Autopilot — базова система допомоги водієві, яку компанія вже припинила пропонувати.

Ашок Елусвамі, віцепрезидент Tesla з програмного забезпечення ШІ, оприлюднив іншу версію інциденту. У дописі в X він заявив, що водій «перекрив» режим самокерування, «натиснувши педаль акселератора на 100% у цій житловій зоні».

Його коментарі натякають, що авто могло бути обладнане саме FSD (Supervised), а не Autopilot. Без незалежного розслідування цього достеменно не знаємо. Але з часом, імовірно, дізнаємося.

Національне управління безпеки дорожнього руху США (NHTSA) та Національна рада з безпеки на транспорті (NTSB) вже відкрили власні розслідування цієї аварії.

Тим часом Tesla врегулювала позов, пов’язаний із фатальною аварією 2023 року за участі авто з увімкненим FSD (Supervised). Ця ДТП є частиною іншого розслідування NHTSA щодо Tesla FSD, де регулятор вивчає, чи здатна система «виявляти та належно реагувати на умови зі зниженою видимістю дороги», зокрема «сонячну засліпленість, туман або пил у повітрі».

Уся ця увага прикута до Tesla саме в момент, коли компанія позиціонує себе як гравця в галузі ШІ та робототехніки. FSD (Supervised) нині — найпомітніший і найприбутковіший продукт, прямо пов’язаний із цим позиціонуванням.

Новий флот роботаксі Waymo

Читач, який раніше вже ділився з нами цікавими підказками, звернув увагу на аналітичний звіт щодо Waymo та її зростаючого флоту роботаксі Ojai. Нагадаємо: Waymo уклала контракт із брендом Zeekr, що належить китайській Geely Holding Group, на постачання електромобіля, спеціально розробленого для роботи в режимі роботаксі.

Мінівеноподібний роботаксі спроєктований у Швеції, а виготовляється в Китаї. Ці авто не містять модулів зв’язку для транспортних засобів; чинна політика США забороняє використання пов’язаних із Китаєм технологій підключених автомобілів. Після прибуття в США Waymo дооснащує машини власною системою автономного керування. Ojai отримує шосте покоління системи Waymo — 13 камер, чотири лідари, шість радарів та набір зовнішніх аудіосенсорів.

Нью-йоркська дослідницька компанія MoffettNathanson провела своєрідне «польове розслідування», щоб оцінити масштаби програми Ojai. Аналітики вивчили коносаменти — детальні документи про вантажні перевезення, які подаються до уряду США. Вони рахували автомобілі Zeekr із маркуванням CM1e або CME — це позначення машин, призначених для Waymo.

MoffettNathanson, яка поділилася звітом із TechCrunch, з’ясувала, що Waymo рухається в напрямку імпорту близько 3 156 транспортних засобів до США цього року, тобто приблизно 300 авто щомісяця.

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

Aseon Labs, стартап із Кремнієвої долини, що розробляє мобільні модулі для автономного огляду, мийки та заряджання роботаксі, залучив $10 млн у посівному раунді під проводом Crane Venture Partners. Серед інших інвесторів — Y Combinator, венчурний фонд Expa співзасновника Uber Гарретта Кемпа, Robin Hood Ventures та Founders Capital.

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

Elroy Air, стартап, що розробляє автономні безпілотники для перевезення важких вантажів, планує вийти на біржу через злиття зі спеціальною компанією-покупцем Columbus Circle Capital Corp II. Угоду оцінюють приблизно в $1 млрд.

Partly, компанія, що створює інструменти ШІ для ланцюжка постачання автозапчастин та ремонту, залучила $50 млн у раунді серії B під проводом DST Global Partners.

Spiro, африканська платформа електротранспорту та «чистої» енергетичної інфраструктури, завершила угоду на інвестицію в $55 млн від китайського фонду зростання NewTrails Capital.

Terawatt Infrastructure, компанія, яка забезпечує зарядну інфраструктуру для електричних автопарків, зокрема для Waymo та інших автономних і електричних флотів, відкрила п’ятирічну кредитну лінію з забезпеченням старшого пріоритету, що дає змогу позичити до $300 млн у банків. За словами компанії, кошти підуть на купівлю та розвиток зарядних хабів.

Інші важливі новини й тренди

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

Lucid Motors скорочує 18% штату — близько 1 500 співробітників — і відмовляється від другої зміни виробництва електромобілів на заводі в Каса-Гранде (Аризона). Нагадаємо, що лише чотири місяці тому виробник EV уже скоротив 12% працівників. CEO Сільвіо Наполі пояснив, що ці кроки є частиною зусиль «спростити структуру компанії, підсилити виконання та з часом зробити Lucid більш конкурентоспроможною». Але в погоні за спрощенням, на що саме Lucid буде змушена піти?

CEO Lyft Девід Рішер опублікував блог, який привернув увагу. У ньому він описав багатосенсорний стандарт безпеки для автономних поїздок у сервісі. Суть у тому, що автономні авто з одним типом сенсорів не зможуть працювати в мережі Lyft. У компанії підтвердили, що це означає виключення таких моделей, як Tesla Cybercab і Tesla роботаксі з FSD (Unsupervised), які покладаються лише на камери. Ці правила, втім, не стосуються систем допомоги водієві, тож усі водії з Tesla в застосунку Lyft і далі працюватимуть без змін.

OpenAI запросила президента Uber India Прабджіта Сінгха на роль першого керівного директора компанії.

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

Samsara, компанія з управління автопарками, виводить на ринок наклейки-трекери розміром із візитівку для боротьби з крадіжками вантажів.

Електровантажівка від Slate Auto з радикально простим дизайном стартує від $24 950. Питання лише в тому, чи готові покупці заплатити близько $25 тис. за двомісний пікап із запасом ходу 205 миль, ручними склопідйомниками, без мультимедійної системи й у сірому композитному виконанні (натомість виробник пропонує індивідуальні вінілові обгортування).

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

Waymo створила юридичну особу в Німеччині, про що першою повідомила місцева газета Frankfurter Allgemeine Zeitung. З реєстраційних документів видно, що компанія готується до запуску сервісу роботаксі в країні. Втім, за словами обізнаних джерел, це не означає, що старт відбудеться дуже скоро. Тим часом Waymo скасувала список очікування в Нешвіллі, зробивши свій сервіс доступним для всіх охочих.

Джерело

TechCrunch

Apple може пропустити покоління своїх чіпів M6 Pro та Max, але це не обов’язково означає відтермінування виходу чуток про сенсорний ноутбук. За даними Марка Гурмана з Bloomberg, новий MacBook вийде з потужними чіпами M5, які були представлені раніше цього року. Як і раніше очікується, 14-дюймова та 16-дюймова моделі з’являться наприкінці 2026-го — на початку 2027 року. Наступне покоління сенсорного MacBook отримає чіпи M7 уже незабаром після цього.

За словами Гурмана, який посилається на джерела, знайомі з планами компанії, версії з M7 вже перебувають на фінальних етапах тестування і можуть з’явитися до кінця 2027 року. Очікується, що сенсорний MacBook принесе із собою низку змін, окрім самого сенсорного екрана. Серед них — поява інтерфейсу Dynamic Island з iPhone, OLED-дисплей і «оновлений промисловий дизайн», повідомляє Гурман.

Передбачається, що Apple представить базовий чіп M7 на початку 2027 року, а через кілька місяців до нього додадуться версії M7 Pro та M7 Max. Також Гурман раніше зазначав, що найпотужніший M7 Ultra може вийти у 2028 році.

Джерело

Engadget

Американська компанія Anthropic, одна з найпомітніших гравчинь на ринку генеративного ШІ, опинилася в центрі гучної історії з держбезпекою США. Ведучий каналу «Канал Лучкова» Іван Лучков у своєму щотижневому техновипуску розповів про тестування нової моделі Mythos (у відео фігурує як Mittos) в Агентстві нацбезпеки США (АНБ) та про те, як ця історія переросла в обмеження експорту й дискусію про доступ до потужних моделей за «правом громадянства».

Модель, яка «зламала майже все»: що сталося в АНБ

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

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

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

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

Червона кнопка Anthropic: експортна заборона і вимкнені моделі

Найпосутніше продовження цієї історії — реакція регуляторів на Anthropic. За словами Лучкова, компанія, яка розробила Mythos, несподівано отримала дуже жорстку заборону на експорт двох своїх моделей — Mythos та Fable.

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

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

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

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

Доступ до ШІ «за паспортом»: як США готують новий цифровий кордон

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

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

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

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

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

Громадянство як новий цифровий привілей

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

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

Окремо він наводить досвід свого знайомого, який довго користувався смартфонами Pixel поза США, а потім переїхав до Штатів. Враження користувача після переїзду: «За функціональністю це зовсім інший смартфон. У нас він працює на 50%». Це живий приклад того, як один і той самий пристрій з тим самим залізом у різних юрисдикціях перетворюється фактично на різні продукти через обмеження сервісів, ШІ-функцій і програмних можливостей.

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

Куди веде «ефект Mythos» і що робити користувачам

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

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

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

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

Джерело

YouTube — «iPhone ВТРАТИТЬ $1300 за рік: Прокляття Samsung діє?»

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

Від «писати код у Codex» до «керувати продуктом у Codex»

Особиста планка Амброзіно на старті була максимально конкретною: Codex мав стати його основним середовищем розробки.

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

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

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

Автоматизація релізів: Slack, pull request’и та «Codex для майже всіх»

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

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

• автоматизував збір оновлень зі Slack‑каналів;
• тягнув статуси з pull request’ів;
• оновлював трекер статусів через Codex.

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

Ранок із Codex: дайджест 3000 Slack‑каналів і «п’ять запитань»

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

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

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

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

«Скажи додатку, що тобі потрібно»: як Codex сам налаштовує конектори

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

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

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

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

Від CLI до десктопу: чому всі тікали з інших продуктів назад у Codex

Характерна риса еволюції Codex — те, як внутрішні користувачі компанії самі голосували «ніжками» за його форму.

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

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

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

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

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

Codex як «домашня база» для всіх ваших застосунків

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

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

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

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

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

Відеоредактор, який навчив Codex будувати свої розширення

Напевно, найяскравіша ілюстрація цієї моделі — історія внутрішнього відеографа OpenAI Брента, який отримав завдання змонтувати ролики про Codex, зняті у тій самій студії, де записувався подкаст.

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

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

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

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

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

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

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

Коли Амброзіно говорить про мету «зробити Codex найкращим десктоп‑додатком, який коли‑небудь існував», за цим стоїть не реклама, а досить чітке розуміння місця цього продукту в екосистемі:

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

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

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

Джерело

OpenAI Codex lead on the new shape of product work | Andrew Ambrosino

Підприємець і розробник Остін Маркезе, відомий своїми практичними гайдами з побудови AI‑проєктів на базі Claude Code, пропонує п’ятиетапний фреймворк для створення «self‑improving» систем. Завершальний, п’ятий етап — DRIVE — взагалі майже не про інструменти. Це про мислення людини, яка керує вже побудованою системою. Саме тут вирішується, чи стане ваш Claude‑проєкт справжнім робочим «двигуном», чи залишиться ще одним «ідеальним, але мертвим» сетапом на GitHub.

«Run it. Don’t overengineer it»: навіщо взагалі потрібен окремий крок про мислення

Маркезе формулює п’ятий крок дуже жорстко: «Step five, drive. Run it. Don’t overengineer it. This step is the mindset you need to actually run the system you just built». Ідея проста: можна налаштувати базу знань, скіли, пайплайни, лупи покращень — і все одно зламати собі продуктивність, якщо ставитися до системи як до крихкого артефакту, а не як до інструмента, який має працювати під навантаженням і змінюватися разом із вами.

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

Принцип №1: «Slow is smooth, smooth is fast» — чому не можна робити все одразу

Перший принцип він формулює максимально прямолінійно: «The first is slow is smooth, smooth is fast. Don’t try and do everything at once. Move slow, move methodical… Just go one step at a time and don’t be discouraged».

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

• базова структура проєкту з knowledge base;
• скіли для типових операцій;
• пайплайни даних;
• improvement‑loop з bucket‑рев’ю.

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

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

Принцип №2: «You’re the leader. The system serves you» — як не стати заручником власної архітектури

Другий принцип — про субординацію між людиною і системою: «Two is you’re the leader. The system serves you. If a piece of the system isn’t actively making you better, just get rid of it».

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

Він підкріплює це тезою: «If you added a skill and you don’t like it, just delete it. You don’t have to wait for someone’s permission to do something. Just do it». Для індивідуальних розробників та засновників це влучний удар по внутрішньому «change control board», який часто сидить у голові й блокує прості зміни.

У практичному сенсі це означає, що:

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

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

Принцип №3: «Compress your feedback loops» — чому не варто чекати, поки система «сама покращиться»

Третій принцип прямо пов’язаний із суттю self‑improving‑підходу: «Three, compress your feedback loops… Self-improving systems are valuable because they compress feedback loops. But the loops only learn if you’re actually using the tools».

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

Конкретна порада звучить так: «If a skill didn’t work the way you wanted and you already went back and forth with Claude to actually fix the final output, just say based on this conversation, improve this skill». Іншими словами, кожен живий діалог із моделлю — це не тільки шлях до правильного разового результату, а й навчальний приклад для самої системи.

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

Принцип №4: «It is not that serious. Bias to action» — війна з дрібним перфекціонізмом

Четвертий принцип спрямований проти ще однієї пастки — нескінченного обговорення незначних рішень: «Four, it is not that serious. Bias to action… People always ask me, ‘What tools should I use? Should I make it raw/inputs? Should I make it raw/ sessions folder? Should I run these things at 6:00 a.m. or 9:00 a.m.?’ The honest answer for any of those smaller things, it just doesn’t matter».

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

У його формулюванні: «AI is really good, so just use it and build things. These systems sharpen through reps, not whiteboard sessions». Ключові слова тут — «репи» проти «whiteboard». Система стає кращою через багаторазове застосування, а не через ідеально прорахований дизайн.

Він підкріплює цю установку цитатою засновника великої криптокомпанії: «One of my favorite quotes of all time is from Brian Armstrong… He said, ‘Action produces information.’… These systems sharpen through reps, not whiteboard sessions». Це не просто красивий слоган: у контексті self‑improving‑архітектури «дія як джерело інформації» означає, що кожен запуск скіла, кожна помилка, кожна корекція — це нові дані для того самого improvement‑loop, який ви вже заклали в систему.

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

• не знаєте, чи потрібна окрема папка raw/sessions чи raw/inputs — оберіть будь‑який варіант і почніть працювати;
• не впевнені, коли краще запускати ingestion‑рутину — поставте будь-який час і подивіться, чи заважає це вам через тиждень;
• не можете вирішити між двома невеликими змінами в склі — реалізуйте одну й подивіться на результат.

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

Коли mindset важливіший за архітектуру

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

У підсумку Маркезе зводить self‑improving‑систему до дуже простої формули:

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

Це не тільки порада для роботи з Claude Code. Це загальний рецепт, як не перетворити будь-яку AI‑ініціативу на вічний «pet project», що ніколи не виходить у реальну роботу. У цій логіці справжня «self‑improvement» починається не з фреймворку, а з готовності власника системи часто натискати кнопку «run», видаляти зайве і не боятися помилкових рішень, якщо вони прийняті в дії, а не на білих дошках.

Джерело

How to Build A Self-Improving System with Claude Code — Austin Marchese

Частка цифрових платежів в Індії зростає з року в рік: система миттєвих переказів Unified Payments Interface (UPI) уже обробляє понад 750 млн транзакцій щодня. З амбіцією вийти на понад 1 млрд операцій на день Діліп Асбе, керуючий директор і CEO корпорації National Payments Corporation of India (NPCI), яка розвиває UPI, вважає, що штучний інтелект відіграватиме ключову роль у наступному етапі зростання — від залучення користувачів до боротьби з шахрайством і розподілу кредитів.

Під час інтерв’ю з TechCrunch на Mumbai Tech Week (MTW) 2026 минулого місяця Асбе сказав, що ШІ може допомогти залучити наступні пів мільярда користувачів за умови спільної роботи NPCI, центробанку Індії та уряду.

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

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

ШІ у фінансах і регулювання

У США стартапи та публічні компанії змагаються в інтеграції ШІ у фінансові сервіси. Coinbase і Robinhood уже дозволяють агентам здійснювати операції від імені користувачів, а OpenAI дає можливість завантажити персональні фінансові дані в ChatGPT для отримання порад. NPCI минулого року демонструвала кілька рішень навколо «агентної» комерції та платежів разом із Razorpay. Однак широкого запуску таких можливостей поки немає.

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

Окрім використання готових моделей, Асбе вважає, що індійська фінансова екосистема має можливість створювати власні малі мовні моделі.

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

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

Конкуренція на ринку UPI

NPCI давно прагне підтримувати здорову конкуренцію між додатками UPI, але, за даними ринку, понад 80% транзакцій припадає на PhonePe (належить Walmart) і Google Pay. План регулятора обмежити частку одного додатка 30% має набути чинності 31 грудня 2026 року, якщо термін знову не відтермінують.

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

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

У 2024 році платіжна корпорація виокремила свій застосунок BHIM UPI, щоб зробити його більш конкурентним і наростити використання. Обсяг його транзакцій зріс, але загальна частка ринку становить близько 1%. За словами Асбе, для BHIM NPCI не має конкретної цільової частки, натомість прагне зробити його суверенною та безпечною альтернативою іншим застосункам.

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

Джерело

TechCrunch

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

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

Станом на закриття торгів у п’ятницю капіталізація Micron становила близько $1,27 трлн, тоді як Meta — $1,39 трлн, а Tesla — $1,42 трлн. Акції Micron за останній місяць зросли більш ніж на 236%, завершивши п’ятницю на рівні $1 132 за штуку. Для порівняння, до середини 2025 року їхня ціна роками трималась нижче $100.

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

Інвесторів ця стара продуктова лінійка вже не хвилює. Micron виграє від будівництва дата-центрів для AI, яке спричинило дефіцит системної пам’яті — як DRAM, так і NAND, зокрема пам’яті з високою пропускною здатністю (HBM), яку також виробляє компанія. Один AI-сервер потребує на порядок більше пам’яті, ніж звичайний ноутбук.

Виробники AI-систем, як-от Nvidia, а також гіпермасштабні хмарні провайдери, які створюють власні рішення, масово скуповують пам’ять. Серед них — Microsoft, Amazon AWS, Google, Meta та Oracle. Це змушує й усі інші компанії, яким потрібна пам’ять, теж її запасати — від виробників ПК на кшталт Dell і HP до виробників інших типів пристроїв.

Такий дефіцит, уже прозваний RAMageddon, за прогнозами триватиме до 2027 року. Він уже штовхає вгору ціни на споживчу електроніку, включно з продуктами Apple та ігровими консолями Xbox.

На тлі загального голоду ринку на чипи пам’яті Micron минулого тижня оприлюднив «вибухові» результати за третій квартал. Виручка компанії зросла вчетверо у річному вимірі — до $41,45 млрд, а прибуток за той самий період підскочив з $1,88 млрд до $28,2 млрд. Micron також дав оптимістичний прогноз, очікуючи виручку в четвертому кварталі на рівні від $49 млрд до $51 млрд.

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

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

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

Це переконало низку аналітиків у тому, що компанія може стати довгостроковою прибутковою інвестицією. У аналітичній записці технологічний аналітик William Blair Себастьєн Наджі зазначив, що зростання попиту й далі випереджає темпи введення в дію нових чистих приміщень (cleanroom) для виробництва.

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

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

Джерело

TechCrunch