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

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

Скляна спинка як радіатор, або чому «бронечохол» шкодить

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

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

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

Бездротова зарядка й тепловий «термос»

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

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

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

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

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

Які чохли справді допомагають, а які створюють «парник»

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

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

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

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

UV-скла та «намертво» заклеєні динаміки

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

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

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

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

Як захисне скло може спровокувати вигорання дисплея

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

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

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

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

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

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

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

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

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

Непомітні звички, які скорочують життя смартфона

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

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

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

Джерело

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

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

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

Локальні рутини як основа: навіщо тягнути все в десктоп

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

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

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

Один orchestration‑скіл для ingestion: мінімум точок лому

Щоб не плодити зайву складність, Марчезе пропонує об’єднати весь регулярний притік даних у єдину точку входу — orchestration‑скіл /data_ingestion.

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

• синхронізація історії сесій Claude (sync claude sessions),
• підвантаження даних з особистої екосистеми (sync ecosystem data),
• обробка зовнішнього curated‑контенту (sync curated content).

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

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

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

Окремий трек для покращень: чому ingestion і зміни системи не змішують

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

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

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

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

Людина в лупі: третя рутина як запобіжник від «автоматичного дрейфу»

Третій обов’язковий елемент — рутина human review. Йдеться вже не про код чи промпти, а про звичку й процес для власника системи.

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

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

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

У підсумку всі три рутини формують повноцінний цикл:

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

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

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

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

Джерело

YouTube: How to Build A Self-Improving System with Claude Code

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

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

Що таке «смак» насправді: не про красу, а про систему

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

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

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

Чому вихід ШІ-дизайну «рідко буває тим самим»

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

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

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

Чому дизайн складніше «загрейдити», ніж код

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

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

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

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

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

Культурний контекст і пастка «клону Linear»

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

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

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

Чому в дизайні новизна важить більше, ніж у коді

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

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

Тобто дизайнерська задача — не просто «вибрати з меню відомих патернів», а знайти поєднання, яке одночасно:

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

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

Невидима складність: абстракції між інтерфейсом і кодом

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

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

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

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

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

Людський смак як незамінний елемент зворотного зв’язку

Амброзіно багато разів повертається до «смаку» як до того, що одночасно:

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

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

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

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

Чи зможе ШІ колись «закрити» дизайн

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

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

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

Висновок: дизайн як останній опір «усередненню»

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

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

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

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

Джерело

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

Чи не ті речі будує Кремнієва долина?

Попри дещо «самодопоміжну» назву, нова книжка письменника, дизайнера й академіка Ієна Богоста The Small Stuff: How to Lead a More Gratifying Life ставить гострі запитання про те, як технології змінили наш досвід фізичного світу. Взявши за відправну точку свою популярну статтю в Atlantic про занепад автомобілів із механічною коробкою передач, Богост у The Small Stuff стверджує, що багато аспектів нашого повсякденного життя — від машин до дверей і туалетів — пережили дематеріалізацію.

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

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

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

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

Від механічної коробки до «дрібниць»

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

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

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

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

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

Що таке дематеріалізація

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

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

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

Для мене дематеріалізація — це назва цілої «родини» станів, які віддаляють нас від нашого сенсорного життя.

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

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

Зручність проти досвіду

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

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

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

Я великий шанувальник Корі Доктороу, але коли звучать тези на кшталт: «Ось ця економічна система й система технологічних цінностей очевидно є причиною всіх наших проблем, і я назву це „ензасранням“ (enshittification)» — це, безумовно, популярне пояснення. Люди явно хочуть отримати просту відповідь, але при цьому думають: «Мені подобається Amazon Prime, мені подобається можливість шукати інформацію в Google».

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

Менше гніву, більше уваги до повсякденності

— Одна з речей, які мене вразили у вашій книжці, якщо порівнювати з роботами того ж Доктороу чи книжкою Дженні Одделл How to Do Nothing й подібними текстами, — у вас менше гніву. Критичний тон є, але він інший.

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

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

Чи справді бізнес обирає неправильні цілі

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

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

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

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

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

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

Як будувати продукти, не вбиваючи досвід

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

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

У 1970-х у Xerox PARC і в Apple існувала потужна концепція «обчислювальної» версії ергономіки, human factors engineering: усвідомлення, що моє тіло має вміститися в крісло чи пройти у дверний проріз. І це було справді важливим для комп’ютерів десятиліттями — до 1990-х. А вже у 2000-х, коли відбувся справжній захід культури під владу обчислень, ми відвернулися від спроби вести діалог між комп’ютингом і людиною.

З цього випливає висновок: важливим є не лише результат, а й досвід виконання дії. Ми одержимося результатом, а досвіду виконання приділяємо дедалі менше уваги. Сьогодні, якщо ви почнете говорити про «досвід виконання» чогось із карикатурним підприємцем із Кремнієвої долини, він скаже: «Навіщо? Ми це автоматизуємо. ШІ це вирішить. Передамо це у Філіппіни».

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

Джерело

TechCrunch

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

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

Активніше використовуйте рекуперативне гальмування

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

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

Охолоджуйте салон, поки авто ще на зарядці

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

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

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

Зважайте на холод: низькі температури «з’їдають» запас ходу

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

Тести Consumer Reports показали, що за температури близько –9 °C (16 °F) запас ходу електромобіля на швидкості 70 миль/год (близько 113 км/год) падає приблизно на 25 відсотків у порівнянні з поїздкою за аналогічних умов, але за температури близько +18 °C. Додатково частину енергії забирає опалення салону — так само, як у спеку працюючий кондиціонер скорочує запас ходу.

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

Аеродинаміка впливає на ефективність усіх авто, але для електромобілів це один із ключових факторів, за яким розраховується запас ходу. Чим менший опір повітрю, тим далі проїде авто — тому виробники так охоче хваляться низьким коефіцієнтом лобового опору, як, наприклад, у Lucid Air із показником 0,197.

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

Не «тапкуйте в підлогу»: плавний розгін економить кілометри

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

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

Також слід пам’ятати: що вища швидкість, то більший опір повітря. Тести Car and Driver показали, що різниця між рухом на 55 миль/год і 75 миль/год (близько 88 та 121 км/год) може «з’їсти» понад 100 миль запасу ходу на прикладі Kia EV9.

Джерело

Engadget

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

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

Від дорогого коду до дешевої імплементації

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

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

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

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

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

Бум прототипів і спокуса «PRD мертві»

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

Він бачить дві симетричні спокуси.

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

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

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

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

Небезпека «прототипу, що виглядає як прод»

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

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

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

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

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

Документ чи прототип: як тепер обирати медіум

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

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

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

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

«Смак» як нова дефіцитна компетенція

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

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

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

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

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

Коли дешево будувати, дорожче стає відбирати

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

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

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

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

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

Висновок: ШІ не скасовує процес, а вимагає переосмислити його

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

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

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

Джерело

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

Американський підприємець і розробник Остін Маркізі будує власні self‑improving системи навколо Claude Code й детально документує цей процес на своєму YouTube‑каналі. В одному з останніх розборів він переходить від абстрактних «штук з ШІ» до дуже приземленої теми: як налаштувати реальні data pipelines — від історії сесій з Claude до листів з розсилок — так, щоб модель постійно жила на свіжих даних, а не на разовому дампі.

Йдеться не про класичну MLOps‑інфраструктуру, а про персональну «озерну» систему даних, яку можна зібрати силами одного інженера чи ноу‑код‑розробника. Центр цієї конструкції — skill‑driven data ingestion: кожен потік даних входить у систему лише через тестований скіл, який гарантовано обробляє raw‑контент так, як потрібно саме вам.

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

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

Він прямо порівнює: на етапі bulk‑upload ми «напоунили» озеро, а далі виникає проблема — якщо не буде нової води, це озеро перестане бути корисним. Тому наступний крок — inflow: створення data pipelines, які працюють як річки й постійно живлять систему новою інформацією.

Саме тут, за його словами, «ламаються 99% людей»: вони або зупиняються на разовому імпорті, або намагаються автоматизувати все без чіткого контролю того, як необроблені дані потрапляють усередину. Відповідь на цю проблему — skill driven data ingestion.

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

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

Тільки після цього поверх скілів будуються автоматичні improvement‑loops. Без надійних скілів автоматизація перетворюється на джерело хаосу.

Пайплайн 1: синхронізація історії сесій з Claude

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

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

На етапі bulk‑ingest ця історія вже аналізувалася як разовий дамп. Однак для self‑improving системи цього мало: потрібна безперервна обробка нових сесій. Для цього вводиться окремий скіл — sync claude sessions.

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

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

Пайплайн 2: персональна екосистема — дзвінки, Slack, YouTube

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

На власному прикладі він зводить це до трьох основних джерел: клієнтські та командні дзвінки, Slack‑повідомлення і YouTube‑відео.

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

Slack‑канал вирішується через пряме підключення: Claude отримує доступ до історії чатів і «claw» (як він висловлюється) цю історію, щоб витягти її в систему. YouTube‑відео він публікує з увімкненими транскриптами, щоб потім мати змогу посилатися не на «чернетки» ідей, а на фінальний опублікований продукт. Саме цей фінальний текст він і затягує до своєї бази знань.

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

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

Пайплайн 3: curated‑контент через email‑аліаси

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

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

Щоб не перетворити основну скриньку на смітник з розсилок, Маркізі пропонує використовувати email‑аліас. У прикладі з умовним «Brad» це виглядає як brad+newsletter@gmail.com, де частина +newsletter фактично створює фільтрований псевдонім. Під цей аліас підписуються на потрібні теми — наприклад, розсилки про AI‑практики — а далі система працює вже з окремим потоком листів.

Тут теж центр ваги — у скілі. У цьому випадку це sync curated content. Він підключається до alias‑інбоксу, витягує листи, видобуває з кожного ключові твердження й заносить це у wiki‑частину системи. Формат для email‑розсилок, але логіка та сама підходить і для інших джерел на кшталт блогів чи відео — достатньо змінити шар підключення.

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

Пайплайн 4: періодичні «дампи» досвіду наприкінці дня й тижня

Четвертий тип пайплайна повертає фокус до особистого досвіду, але вже не як разового «лайфсторі», а як регулярної практики. Маркізі описує її як periodic data dumps: наприкінці дня чи тижня він просто проговорює вголос уроки, які засвоїв, і тим самим вивантажує lived experience в Claude.

Технічно це виглядає як «rant into Claude code» за допомогою voice‑to‑text інструментів, які він згадує — Hex або Whisper Flow. Голос перетворюється на текст, а далі в гру вступає вже знайомий базовий скіл add new resource, налаштований ще на старті системи. Саме він відповідає за те, щоб будь‑який raw‑файл потрапив у RAW‑частину проєкту й був відреферений з wiki в потрібному контексті.

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

Skill‑оркестрація замість хаотичної інтеграції

Коли всі чотири пайплайни описані й реалізовані через скіли, Маркізі зводить їх разом одним рухом. Він показує єдиний промпт, який створює одразу три синхронізаційні скіли — для сесій Claude, персональної екосистеми та curated‑контенту — і тим самим формує «постійний потік» в data lake.

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

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

Висновок: self‑improving починається з дисципліни даних

На словах «self‑improving система» легко уявити собі магічний автономний ШІ, який «сам усе робить». У підході Маркізі магія приземляється на дуже конкретну дисципліну роботи з даними.

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

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

Джерело

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