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

«Золий стандарт» навчання і його головна проблема — ціна

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

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

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

AI як майже репетитор: що вже вміють моделі

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

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

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

Освіта за 100 доларів: коли ціна змінює все

Один із найяскравіших моментів дискусії — зіставлення вартості традиційної освіти та її AI-альтернативи. Та сама освіта, за яку сьогодні батьки платять 12 000 доларів на рік у початковій чи середній школі, або 80 000 доларів на рік в університеті, за рахунок AI може бути надана приблизно за 100 доларів.

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

З цього випливає кілька наслідків.

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

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

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

Діти з AI і діти без: розрив, що тільки зростатиме

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

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

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

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

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

Школи, що не адаптуються: сценарій зникнення

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

Аргумент тут подвійний.

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

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

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

«Кожна школа, кожен клас має прийняти AI»

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

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

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

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

«AI — це не про списування»: чому нинішня дискусія хибна

На цьому тлі особливо різко звучить критика нинішньої публічної розмови в освіті про AI. Зведення всієї проблематики до питання «це списування чи ні?» порівнюється з хибним вибором між «закритою» та «відкритою» книжкою на іспиті. Така рамка, за висловом Фей-Фей Лі, «просто не те місце, де ми маємо бути».

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

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

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

Висновок: не інструмент проти школи, а школа з інструментом

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

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

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

Джерело

Godmother of AI: In 10 Years There Will Be Only 2 Kinds of Workers

Розмови про штучний інтелект дедалі гучніші — й дедалі простіші до примітивності. Від «богоподібного розуму, що врятує світ» до «технології, яка знищить усі роботи», публічний наратив коливається між двома крайнощами. На цьому тлі докторка Фей-Фей Лі, одна з найвпливовіших дослідниць у сучасному AI, та підприємець Давид Рож’є, CEO MasterClass, пропонують іншу оптику: розглядати штучний інтелект як потужний, але все ж інструмент. Їхня спільна розмова на каналі Silicon Valley Girl дає рідкісний погляд на «нюансований центр», якого майже немає в публічних дебатах.

Поляризований дискурс: «бог» проти «диявола»

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

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

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

AI як інструмент, а не заміна людини

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

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

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

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

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

«Нюансований центр», якого не вистачає

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

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

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

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

Чому риторика «нульової вартості інтелекту» шкодить

Окремо Фей-Фей Лі зупиняється саме на популярній фразі про те, що «cost of intelligence goes to zero». Вона прямо каже: «Я дуже стурбована риторикою про те, що “вартість інтелекту дорівнює нулю”… це саме та риторика, яка змушує людей бути настільки анти-AI».

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

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

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

«Ми вчимо дітей користуватися вогнем. Тепер має навчитися суспільство»

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

Це означає дві речі одночасно.

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

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

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

Час змін: між втратою та можливістю

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

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

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

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

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

Як зробити перший крок: порада тим, хто вже боїться

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

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

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

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

Висновок: повернути дискусію людям

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

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

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

Джерело

Godmother of AI: In 10 Years There Will Be Only 2 Kinds of Workers — Silicon Valley Girl

Відомий розробницький канал Tech With Tim показав, як перетворити консольний Codex CLI від OpenAI на справжнього бекграунд‑агента: замість того, щоб сидіти й чекати завершення довгих AI‑сесій, винести їх на VPS і підв’язати до класичного Linux‑планувальника cron. У фокусі — не інсталяція, а саме автоматизація: як змусити Codex щодня самостійно рев’ювати pull request’и, шукати вразливості в коді чи збирати changelog, поки власник спить.

Автоматизація без «магії»: cron замість вбудованого планувальника

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

Тому логіка така: за розклад відповідає сама операційна система, а Codex — лише інструмент, який виконує конкретну команду. Саме тут у гру входить cron — стандартний Linux‑механізм, який дозволяє на рівні сервера сказати: «запускай о такій‑то годині ось цю команду». Завдання Codex — бути цією командою.

Власний VPS у такій схемі стає ключовим елементом. Він працює 24/7, не засинає, не залежить від кришки ноутбука чи домашнього Wi‑Fi. Якщо потрібно, щоб щось стабільно й передбачувано виконувалося щодня, по таймеру, — cron на VPS дає це «залізне» виконання, якого важко досягти на особистій машині.

Що може робити Codex на автопілоті: від безпеки до документації

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

Серед прикладів регулярних завдань, які можна віддати такому агенту:

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

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

Окремо виділяється автоматична генерація changelog’ів. Можна налаштувати, щоб Codex щоденно будував markdown‑файл зі змінами в репозиторії за останній період: які PR були змінені, що додано чи виправлено. Аналогічно, агент може оновлювати README‑файли, синхронізуючи їх з актуальним станом проєкту.

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

Codex exec: як запустити агента без інтерактивної сесії

Ключовий інструмент, який дозволяє зв’язати cron і Codex, — команда codex exec. На відміну від стандартного запуску Codex CLI, який відкриває інтерактивну сесію і чекає на діалог із користувачем, codex exec веде себе як одноразова команда.

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

Це ідеально пасує під cron. Планувальник очікує «звичайну» команду, яку можна поставити в розклад. codex exec цю роль виконує: cron у визначений час викликає codex exec з потрібними параметрами, а Codex уже всередині запускає повний сценарій — перевіряє репозиторій, взаємодіє з GitHub, створює файли, оновлює документацію.

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

Приклад: щоденний рев’ю PR + звіт у markdown

Щоб показати, як це працює в реальному сценарії, використовується конкретний кейс: проста автоматизація, яка щодня проганяє рев’ю pull request’ів у репозиторії й формує звіт у вигляді markdown‑файлу.

Формулювання задачі до агента виглядає приблизно так: потрібно налаштувати автоматизацію, що щоденно, через Codex CLI, запускає cron‑завдання. Це завдання повинно:

працювати по цільовому репозиторію;

переглядати всі відкриті PR’и;

на основі аналізу створювати markdown‑файл із переліком PR, їх статусом і рекомендацією, чи варто їх схвалювати.

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

Далі в гру вступає codex exec: в самій cron‑конфігурації прописується виклик цієї команди з потрібними параметрами. Cron відповідає за розклад, codex exec — за логіку всередині CLI, а сам Codex — за взаємодію з GitHub і генерування результату.

Cron на VPS: як виглядає «підкапотна» автоматизація

Після того як сценарій описаний, Codex фактично генерує налаштування cron job: команду, яка додається в crontab, розклад виконання і конкретний виклик codex exec. Користувачеві залишається погодитися з тим, що агент пропонує виконати в терміналі.

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

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

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

Навіщо все це: VPS як постійний бекграунд‑агент

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

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

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

Джерело

YouTube: I Gave Codex a 24/7 Server. Now It Codes While I Sleep.

У новому технічному розборі автор каналу Tech With Tim демонструє, як перетворити хмарний сервер із Codex CLI на практично «безсмертного» код‑агента, яким можна керувати з будь‑де — навіть з телефона. Ключ до цього — поєднання tmux для стійких SSH‑сесій і мобільного SSH‑клієнта Termius.

Матеріал цікавий насамперед розробникам, які запускають довгі AI‑задачі й не хочуть прив’язуватися до відкритого ноутбука чи стабільного Wi‑Fi.

Чому без tmux ваш агент зникає разом із терміналом

Після базового налаштування VPS і встановлення Codex CLI постає практичне питання: що відбувається з довгою задачею, якщо термінал закрити або з’єднання по SSH обірветься?

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

Щоб цього не сталося, пропонується встановити утиліту tmux. Її роль сформульована дуже прямо: «перше, що нам потрібно зробити, — це встановити інструмент під назвою tmux… він дозволить нам зберігати SSH‑сесію навіть тоді, коли ми не підключені до virtual private server».

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

Як побудувати стійку сесію Codex за допомогою tmux

Після встановлення tmux через стандартну для Linux команду пропонується кілька базових прийомів роботи. Вони не перетворюються на повноцінний туторіал по tmux, але фокусуються на мінімально потрібному наборі для керування Codex.

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

Щоб отримати дійсно корисну «довгоживу» оболонку, використовується інша команда:

«ми можемо виконати tmux new -s, а потім дати цій оболонці ім’я. У цьому випадку я назву її Codex».

Створюється сесія Codex, всередині якої запускається Codex CLI. Для прикладу — простий hello world, але важливий саме принцип: у цій оболонці може працювати будь‑яка довга задача агента.

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

спочатку tmux ls — у списку видно, що сесія codex усе ще працює;

потім tmux attach — без параметрів команда під’єднає до найсвіжішої сесії, яка й є Codex;

за потреби можна явно вказати сесію: tmux attach -t codex, і «це зараз поверне мене в ту саму оболонку».

Таким чином демонструється ключовий ефект: сесія з Codex продовжувала існувати й виконувати свою роботу, навіть коли SSH‑клієнт на ноутбуці було закрито. Саме на такій стійкій сесії далі будується мобільний сценарій.

Termius як мобільний міст до вашого VPS

Наступний крок — навчитися керувати тим самим сервером і тією ж tmux‑сесією вже зі смартфона.

Для цього пропонується встановити SSH‑клієнт на телефон: «ми підемо в App Store і нам потрібно завантажити так званий SSH client… додаток, який я тут рекомендую, називається Termius… він безкоштовний. Вам не потрібно нічого платити».

Наголошується, що Termius — не єдиний варіант; на Android можна використати будь‑який SSH‑клієнт. Головна вимога — вміти підключатися до сервера по SSH.

У Termius створюється новий хост:

в полі label — будь‑яка зручна назва, наприклад Codex CLI;

у полі IP or hostname — та сама IP‑адреса VPS, яку використовував комп’ютерний термінал;

як username — root (у демонстрації сервер налаштований саме так);

як password — той самий root‑пароль, що застосовувався раніше.

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

Головний момент: «ефективно ми просто зайдемо й увійдемо у наш virtual private server з телефона». Тобто телефон стає повноцінною консоллю до того ж самого VPS, на якому вже крутиться tmux із Codex.

Як прикріпити телефон до вже запущеної сесії Codex

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

У Termius робиться те саме, що й на ноутбуці:

вводиться команда tmux ls, яка показує список сесій. У демонстрації видно, що сесія codex активна й «currently attached»;

далі виконується tmux attach -t codex, і телефон під’єднується до тієї ж оболонки.

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

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

Це наочна демонстрація того, що:

ноутбук і телефон дивляться в одну й ту саму сесію;

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

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

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

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

Мобільний контроль довгих задач: як це виглядає на практиці

У демонстрації з телефона запускається реальна робоча команда. У tmux‑сесію із Codex вставляється URL GitHub‑репозиторію, до якого агент має доступ через попереднє налаштування GitHub‑інтеграції, й дається інструкція: «hey, can you review all PRs in this repo?».

Після натискання Enter Codex починає проглядати pull request’и й повертати висновки: якими PR варто зацікавитися, які варто схвалити, які ні. Усе це виконується в тій самій сесії tmux, запущеній на VPS, але керується вже з телефона.

При цьому кілька разів підкреслюється:

можна закрити мобільний клієнт, знову підключитися, зробити tmux attach і повернутися до тієї ж сесії;

можна відійти на ноутбук, приєднатися до неї там і продовжити роботу вже за великим екраном;

завжди можна повністю вийти з tmux‑сесії, якщо завдання завершено або агент більше не потрібен.

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

Висновок: tmux + SSH‑клієнт перетворюють Codex на хмарного напарника

У підсумку показаний зв’язок доволі простий, але потужний.

tmux на VPS вирішує фундаментальну проблему: стандартна SSH‑сесія гине разом із терміналом, а persistent‑сесія tmux продовжує жити й тримати запущений Codex CLI.

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

У результаті розробник отримує можливість запускати довгі AI‑агентні задачі, під’єднуватися до них із різних пристроїв, дивитися прогрес, віддавати нові команди, не боячись ані закритого кришки ноутбука, ані випадкових розривів Wi‑Fi.

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

Джерело

YouTube: I Gave Codex a 24/7 Server. Now It Codes While I Sleep.

У свіжому гайді на каналі Tech With Tim автор показує, як перетворити Codex CLI на повноцінного «хмарного» код‑агента, що не лише працює 24/7 на VPS, а й безпосередньо керує репозиторіями в GitHub. Ключовий елемент цієї схеми — правильне підключення до GitHub з тонким налаштуванням прав доступу та валідацією того, що агент справді може створювати репозиторії, робити pull‑request’и й запускати автоматизації.

Навіщо Codex потрібен доступ до GitHub

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

У фокусі — кілька типових задач, які стають можливими після підключення:

Codex може створювати нові репозиторії, клонувати їх на VPS та ініціалізувати структуру проєкту. Він здатен відкривати й оновлювати pull‑request’и, що відкриває дорогу до напівавтоматичного код‑рев’ю та оновлень гілок. Додатково агент може використовувати репозиторії як точку входу для будь‑яких автоматизацій: від регулярного аналізу PR’ів до генерації звітів за змінами.

Усе це зав’язано на можливості Codex викликати GitHub‑команди зсередини VPS. Тому інтеграція складається з двох великих частин: створення fine‑grained токена в GitHub з потрібними правами та налаштування GitHub CLI на сервері.

Створення fine‑grained токена GitHub для Codex

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

У налаштуваннях профілю GitHub треба перейти в розділ Settings, а далі внизу в Developer settings. Саме там створюється API‑ключ, який потім використовуватиметься на VPS для підключення до акаунта GitHub.

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

У розділі Personal access tokens обирається вкладка Fine‑grained tokens і натискається Create new token. Далі формується токен під VPS‑сценарій:

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

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

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

Після цього починається найважливіша частина — вибір дозволів.

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

Fine‑grained токени GitHub дозволяють дуже точно вказати, що саме можна, а що не можна робити з репозиторіями. Для сценарію з Codex виділяється кілька ключових permission‑груп:

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

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

Pull‑request’и. Для роботи з PR’ами вмикається категорія pull requests. Вона дозволяє отримувати інформацію про запити на злиття, коментарі, асайні, статуси і, за потреби, створювати та оновлювати самі PR’и.

Окремий акцент робиться на режимах читання й запису. Для більшості сценаріїв без участі людини доведеться надавати read and write, інакше агент не зможе створювати нові репозиторії, гілки чи pull‑request’и. Водночас у демонстрації спершу вибирається більш консервативний варіант: деякі дозволи лишаються в режимі read only, щоб зменшити ризик небажаних дій на кшталт видалення репозиторіїв.

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

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

GitHub CLI на VPS: як навчити Codex працювати з репозиторіями

Створити токен — лише половина справи. Щоб Codex CLI міг використовувати його, на віртуальному сервері встановлюється офіційний інструмент GitHub — gh.

У середовищі VPS, де вже розгорнуто Codex CLI, у терміналі виконується команда встановлення:

apt install gh -y

Це ставить GitHub CLI й одразу приймає всі необхідні підтвердження завдяки флагу -y. Після інсталяції можна просто ввести в терміналі gh, щоб переконатися, що інструмент доступний.

Далі йде авторизація GitHub CLI:

викликається команда gh auth login;

у діалозі обирається платформа github.com;

як протокол підключення використовується https;

для способу авторизації обираються GitHub credentials з токеном.

На завершальному етапі CLI просить вставити токен, створений раніше у Developer settings. Після вставки й підтвердження GitHub CLI повідомляє, що автентифікація успішна, і показує, під яким акаунтом виконано вхід. У прикладі це акаунт Tech With Tim.

На цьому моменті вся зв’язка сходиться: VPS має доступ до GitHub через gh, а Codex CLI, який працює в тому ж середовищі, може викликати ці команди для виконання будь‑яких GitHub‑операцій у межах прав токена.

Перевірка доступу: як упевнитися, що Codex бачить ваші репозиторії

Щоб не працювати «всліпу», після налаштування радять зробити простий тест: переконатися, що Codex справді може користуватися GitHub CLI й бачить потрібні репозиторії.

У сесії Codex CLI на VPS можна сформулювати запит до агента в явному вигляді: пояснити, що в нього є доступ до команди gh і що потрібен список репозиторіїв для валідації підключення. Також згадується ім’я користувача — у демонстрації це Tech With Tim — аби агент знав, до якого акаунта звертатися.

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

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

Висновки: GitHub як природне середовище для AI‑агента

Після того як Codex CLI працює на VPS і має налаштований доступ до GitHub через fine‑grained токен і gh‑CLI, агент перестає бути просто «розумною підказкою коду». Він отримує повноцінний операційний контекст: може створювати й змінювати репозиторії, працювати з pull‑request’ами та бути вмонтованим у рутинні процеси розробки і супроводу коду.

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

створення окремого fine‑grained токена в GitHub із чітким набором дозволів;

усвідомлений вибір рівня доступу — від read only для перших тестів до read and write для продакшн‑сценаріїв, де агент має створювати репозиторії та гілки;

встановлення та авторизація GitHub CLI (gh) на VPS, щоб Codex міг використовувати GitHub‑команди всередині того ж середовища;

явна перевірка доступу через запит до Codex з використанням gh і виведення списку доступних репозиторіїв.

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

Джерело

YouTube: I Gave Codex a 24/7 Server. Now It Codes While I Sleep.

Розробник і ютубер Tech With Tim показує, як перетворити Codex CLI на постійно доступного код‑агента, винісши його з локального ноутбука на віртуальний приватний сервер. Ідея проста: замість того, щоб ходити з напівзакритим ноутом, чекаючи на завершення довгого завдання, Codex працює 24/7 у хмарі, а ви підключаєтесь до нього з будь‑якого пристрою.

У цьому матеріалі — саме технічна частина: вибір VPS‑плану, базове підключення через SSH, встановлення Codex CLI в headless‑середовище та автентифікація через існуючу ChatGPT‑підписку. Без ліричних відступів і без занурення в інші теми на кшталт GitHub‑інтеграції чи мобільного доступу, які розкриваються окремо.

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

Перший крок — віртуальний приватний сервер. Без нього говорити про 24/7‑агента немає сенсу. Автор відразу окреслює, що підійде будь‑який VPS, але для демонстрації використовує Hostinger, тому що, як він формулює, це «some of the best virtual private servers on the market» і «they are the most reliable».

Конкретна рекомендація для тих, хто хоче повністю повторити конфігурацію: план KVM 2. Прямо звучить порада: «I would recommend going with the KVM 2 plan if you want to follow along with me here». Решта тарифів також доступні, але вся подальша інструкція прив’язана до цього класу ресурсів.

Далі — стандартний сценарій розгортання:

спочатку обирається план і тривалість підписки, потім — регіон (у прикладі це датацентр в Індонезії), а в конфігурації серверу — варіант «OpenAI Codex» як one‑click‑деплой. Це готовий шаблон, який одразу піднімає потрібні залежності, зокрема Codex CLI, і економить кілька кроків ручної установки.

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

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

Перший вхід: IP‑адреса, SSH і root‑доступ

Коли VPS готовий, завдання номер один — підключитися до нього з локальної машини. Для цього в панелі керування потрібно знайти IP‑адресу сервера. Це окрема акцентована порада: «what we’re going to need to do though is find the IP address of our server so we can SSH into it and start configuring a few things».

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

Подальший сценарій на боці розробника виглядає так:

у терміналі на локальному комп’ютері відкривається нове вікно, і туди вставляється команда на кшталт ssh root@IP_СЕРВЕРА. Саме так і формулюється інструкція: «we’re going to paste the command SSH root at and then the IP address of our server».

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

Після введення команди SSH, клієнт попросить підтвердити довіру до нового хоста — на це відповідають «yes», далі вводять пароль (курсору і символів не видно — це очікувана поведінка), натискають Enter і в разі успіху бачать промпт на кшталт root@srv…. Цей індикатор означає, що сесія вже всередині VPS, і можна переходити до налаштування середовища.

Встановлення Codex CLI: від curl‑скрипта до робочої команди

Далі потрібно переконатися, що Codex CLI встановлений. Якщо під час створення VPS використовувався варіант «OpenAI Codex» як one‑click‑деплой, команда codex має бути доступною одразу. Якщо ні, доведеться встановити інструмент вручну.

Весь процес зводиться до запуску одного рядка з офіційної документації. У гайді це описано так: «there’s a curl, you can just copy this, paste this as the command and run it and that that install the Codex CLI for you». Йдеться про стандартний інсталер через curl, який витягується з docs Codex CLI.

Після виконання скрипта є тонкий, але важливий момент: змінна PATH може не оновитися в поточній SSH‑сесії. Тому якщо після установки команда codex не знаходиться, радять просто розірвати підключення й підключитися до сервера знову. Формулювання тут чітке: іноді «the path variable needs a second to refresh», тому варто «close it and re‑SSH back in and it should work».

Як тільки codex починає викликатися без помилок «command not found», середовище для наступного кроку готове.

Автентифікація через ChatGPT‑підписку: вхід по device code

Мати встановлений двійковий файл Codex CLI — лише половина справи. Щоб інструмент працював, його потрібно прив’язати до свого облікового запису. На VPS немає браузера, тож класичний логін «через веб» замінюється схемою з device code.

Залежно від конфігурації автор згадує і можливість використання API‑ключа, але акцент ставиться на іншому шляхові: «from here, we should be able to trigger the Codex command… we’re going to go to sign in with device code… it’s probably going to be better to use your existing ChatGPT subscription».

Старт відбувається з запуску codex у терміналі на VPS. Усередині інструменту обирається опція «sign in with device code». Далі Codex CLI показує два елементи: URL, який треба відкрити в браузері на локальному пристрої, та одноразовий код.

Порядок дій:

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

Після підтвердження у браузері повертаються до терміналу на VPS і натискають Enter, щоб завершити прив’язку. У CLI з’являється повідомлення про успішний вхід, користувач погоджується з продовженням сесії («we’re just going to go yes, continue, that’s fine») — і Codex переходить у стандартний робочий режим.

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

Після автентифікації Codex CLI відкриває інтерактивну сесію в терміналі. У гайді показується найпростіший тест: набирається щось на кшталт «hello world», і інструмент генерує відповідь. У цьому стані «we’ve now open up Codex and we’re able to start triggering something».

Далі одразу робиться важливе застереження: це не повноцінний навчальний курс по функціоналу агента. Прямим текстом зазначається: «I’m not going to give you a full tutorial on how Codex works here. There’s a lot of different slash commands that you can use».

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

Після цього Codex CLI можна сприймати як вже повноцінно настроєний інструмент у headless‑середовищі. Сесію, за потреби, завершують по Ctrl+C, термінал очищують командою clear, і VPS готовий до наступних кроків — інтеграції з іншими сервісами, мобільного доступу чи автоматизацій.

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

Загальна логіка налаштування виявляється простішою, ніж може здатися ззовні. Алгоритм зводиться до кількох чітких дій: створити VPS (у прикладі — з планом KVM 2 на Hostinger), знайти IP‑адресу і зайти по SSH як root, встановити Codex CLI через curl‑скрипт із документації або скористатися one‑click‑деплоєм, після чого прив’язати інструмент до свого облікового запису через схему sign in with device code, бажано використовуючи вже наявну ChatGPT‑підписку.

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

Джерело

YouTube — I Gave Codex a 24/7 Server. Now It Codes While I Sleep.

У новому відео автор каналу Tech With Tim показує, як перетворити Codex CLI на «нічного кодувальника», що працює безперервно в хмарі. Замість того, щоб ходити з напіввідкритим ноутбуком і чекати, поки агент допише код, він переносить усі довгі задачі на віртуальний приватний сервер (VPS) і керує ними дистанційно — з ноутбука чи навіть телефону.

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

Проблема «напіввідкритого ноутбука» і навіщо тут VPS

Сценарій, знайомий багатьом розробникам: агент коду щось генерує або переписує, процес триває годинами, а ноутбук не можна закрити, щоб не зупинити виконання. Тим описує власну ситуацію в аеропорту, коли мусив ходити з відчиненим ноутом, бо «needed my Claude Coder Codex agent to finish running».

Це, на його думку, «a problem that doesn’t need to exist because you can actually run agents in the cloud if you configure them correctly». Рішення — перенести довгі задачі з локальної машини на VPS, тобто віртуальний приватний сервер.

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

Власне відповідь: «the solution here is to have a VPS or virtual private server where you can delegate long-running tasks». Локально лишається «активна» робота, а все, що потенційно триває години, віддається у віддалене середовище.

Чому саме Codex CLI і чим він відрізняється від інших агентів

Для такої архітектури Тим обирає Codex CLI. Причина не лише у функціональності, а й в економіці: «Codex… can actually run faster than Claude Code and, more importantly, is significantly cheaper to use, especially on a subscription basis».

Він підкреслює, що на підписці використання практично «необмежене», якщо не запускати агента одночасно в десятках сесій цілодобово. У поєднанні з тим, що Codex працює в headless‑режимі (без GUI) і добре почувається в терміналі, це робить його зручним кандидатом для запуску на VPS.

Codex CLI дозволяє:

• працювати повністю в консолі,
• використовувати існуючу підписку (через авторизацію по device code),
• запускатися як у звичному «сеансовому» режимі, так і через окрему команду codex exec, яка просто виконує задану інструкцію без відкриття інтерактивного інтерфейсу.

Останній момент стає важливим на етапі автоматизації, коли Codex потрібно вбудувати в cron‑завдання на сервері.

VPS як «несхлопуваний» комп’ютер: стабільність, інтернет, швидкість

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

По‑перше, «a virtual private server doesn’t go to sleep, it’s available 24/7 in a secure environment with a hardwired connection so the internet just doesn’t go out». На відміну від ноутбука, VPS не засинає, не лягає разом з операційною системою після оновлення, не залежить від того, чи закрили ви кришку.

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

По‑третє, важлива «фізика» дата‑центру. «You can just use the virtual private server and get significantly faster speeds for downloading something, uploading something, getting a data set, training a model». Для тих, хто часто мандрує або працює в середовищі з нестабільним інтернетом, це додає відчутної різниці: важкі завантаження, вибірки даних, навчання моделей проходять через канал дата‑центру, а не домашнього Wi‑Fi.

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

Архітектура: як виглядає «Codex у хмарі»

Логіка побудови середовища досить лінійна. Спочатку піднімається VPS у будь‑якого провайдера, далі на ньому встановлюється Codex CLI й виконується авторизація в обліковому записі. Після цього той самий Codex, який зазвичай працював локально, починає жити в окремому серверному світі.

Тим описує це як «how we can set up Codex so that it’s running 24/7 in the cloud so we never need to have our laptop screen half open». Ключовий момент — немає різниці, звідки надходять команди: із фізичного ноутбука чи телефона, адже всі дії виконуються в одному й тому самому середовищі на VPS.

Далі йде важливе розділення:

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

Це знижує ризик одночасно втратити і час, і прогрес через банальний sleep‑режим або обрив мережі.

Коли ноутбук уже не потрібен: tmux і доступ зі смартфона

Окремий пласт у побудові цієї інфраструктури — забезпечити, щоб сесія Codex не обривалася навіть при розриві SSH‑з’єднання. Для цього Тим використовує класичний інструмент командного рядка tmux.

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

У цій схемі Codex запускається всередині tmux‑сесії. Далі користувач може:

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

Саме так реалізується те, що він формулює як: «you can be on the go and you can actually trigger a task to run from your phone… if that screen closes, your task keep running». Екран телефону або ноутбука може гаснути скільки завгодно, але процеси в tmux‑сесії на VPS не зупиняються.

Доступ з мобільного реалізується через стандартного SSH‑клієнта: користувач додає хост VPS, логін root (або інший системний користувач), пароль, і далі працює з терміналом фактично так само, як і з десктопа. Усе управління Codex — через ті самі команди, просто на екрані смартфона.

Де VPS + Codex дають найбільше вигоди

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

Вигода проявляється у кількох типових кейсах.

По‑перше, довгі «нічні» задачі. Якщо потрібно, щоб агент кілька годин аналізував велику кодову базу, генерував звіти, робив рефакторинг чи інші ресурсомісткі речі, це сенсно виносити на VPS. Сеанс у tmux лишається активним, навіть якщо ноутбук закрили й пішли спати.

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

По‑третє, сценарії з поганим інтернетом. Коли сам користувач перебуває в «low internet environment», він може доручити важкі мережеві операції VPS, який сидить на стійкому каналі в дата‑центрі: «you can just use the virtual private server and get significantly faster speeds for downloading something, uploading something, getting a data set, training a model». Локальна машина в такому випадку перетворюється лише на інтерфейс доступу.

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

Висновок: «агент, що не спить», як новий стандарт роботи з AI‑кодерами

Технічна суть підходу, який демонструє Tech With Tim, зводиться до трьох елементів: Codex CLI як код‑агент, VPS як завжди доступний обчислювальний вузол і tmux як шар стійкості між ними та клієнтом.

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

На тлі того, що Codex, на думку автора, «can actually run faster than Claude Code» і «is significantly cheaper to use» на підписці, така архітектура виглядає логічним наступним кроком для розробників, які хочуть вичавити максимум з AI‑інструментів для коду й не залежати від випадкового sleep‑режиму власного ноутбука.

Джерело

YouTube: I Gave Codex a 24/7 Server. Now It Codes While I Sleep.

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

Від генерації картинок до ультразвукового сканера

Midjourney офіційно представила свій перший фізичний продукт. Це інноваційний ультразвуковий сканер усього тіла, який назвали Mid Journey Scanner. Концептуально він замахується на роль альтернативи магнітно-резонансній томографії: поки що не повноцінної заміни, але вже дуже прозорого натяку на це.

Щоб здійснити цей стрибок з царини творчих нейромереж у високорегульований світ медичної техніки, компанії довелося змінити власну структуру. Для нового напрямку створили окремий медичний підрозділ під назвою Mid Journey Medical. А для апаратної частини проекту залучили партнерів, які давно працюють на цьому ринку: Midjourney запартнерилася з Butterfly Network — гравцем, якого в індустрії описують як дуже сильного в галузі портативних УЗД-апаратів.

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

Кіберпанк у ванні: як працює Mid Journey Scanner

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

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

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

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

Два петафлопси проти хаосу даних

Обсяг інформації, який генерує тисяча датчиків за хвилину сканування, колосальний. Щоб обробити весь цей масив, Mid Journey Scanner використовує обчислювальну потужність до двох петафлопсів. Після цього в гру вступають алгоритми штучного інтелекту — та сама сфера, де Midjourney почувається максимально впевнено.

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

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

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

Без дозволів лікарів, але зі ставкою на фітнес

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

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

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

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

Mid Journey Spa: спортзал, сауни й десять сканерів

Стратегія Midjourney виходить далеко за межі продажу одного пристрою. До кінця 2027 року компанія планує відкрити у Сан-Франциско власний Mid Journey Spa. Концепція — щось середнє між фітнес-клубом, медичним центром та кіберпанковим санаторієм.

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

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

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

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

Від котиків до печінки: чому цей крок важливий

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

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

Наскільки далеко зайде такий підхід і чи зможе ультразвукове 3D-сканування вийти на рівень повноцінної альтернативи МРТ — відкрите питання. Але вже зараз очевидно, що на перетині ШІ, медтеху та фітнес-індустрії з’являється новий, дуже амбіційний гравець.

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

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

Ставка на AI-окуляри як щоденний гаджет

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

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

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

10 мільйонів у оптику: для чого Qualcomm Inspe

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

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

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

«Головний мозок» нового покоління ШІ‑пристроїв

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

Голова компанії Крістіано Амон, за словами Лучкова, повідомив, що Qualcomm нині розробляє понад 40 різних варіантів розумних пристроїв. І це не лише окуляри. У переліку фігурують розумні каблучки, нашийники на шию, брошки, шпильки та навіть навушники з вбудованими камерами.

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

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

Snapdragon Reality Elite: обчислювальна база для змішаної реальності

Щоб забезпечити необхідний рівень продуктивності без постійної прив’язки до хмари, Qualcomm презентувала нову платформу для окулярів змішаної реальності — Snapdragon Reality Elite.

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

Snapdragon Reality Elite закриває одразу кілька задач. По‑перше, це обчислювальна потужність для AR‑проекцій, які мають працювати гладко й без ривків. По‑друге, це інференс ШІ‑моделей, які розуміють, що відбувається навколо користувача, та генерують корисні відповіді. По‑третє, це енергетична ефективність, адже окуляри й прикраси фізично не можуть мати такі ж батареї, як смартфони чи ноутбуки.

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

Start: конструктор, що відкриває ринок для будь-якого бренду

Якщо Snapdragon Reality Elite — це низькорівнева база, то друга новинка Qualcomm — програма Start — працює на рівні готового продуктового рішення. Лучков описує її як «готовий конструктор для будь-якого бренду».

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

Це кардинально знижує вхідний бар’єр. Для компаній, які не мають власних R&D‑команд у сфері mixed reality чи комп’ютерного зору, поява такого «конструктора» означає можливість швидко вийти на ринок AI‑окулярів чи інших носимих девайсів, не витрачаючи роки на розробку базових компонентів.

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

Швидкий підйом ринку носимих ШІ-пристроїв

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

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

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

Висновок

Рухи Qualcomm — інвестиція в оптику Inspe, запуск чипа Snapdragon Reality Elite та програми Start — складаються в цілісну стратегію. Компанія готується до епохи, в якій основними точками контакту з ШІ стануть не смартфони, а окуляри, навушники, прикраси й інші об’єкти, які ми носимо щодня.

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

Джерело

YouTube: Apple СКАСУЄ осінні iPhone?! Тім Кук ШОКУВАВ заявою про ціни на Apple

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

Витоки з Geekbench: Valv Fremont і ставка на SteamOS

Поштовхом до нової хвилі обговорень стали результати тестів у базі Geekbench. Там з’явився пристрій під кодовою назвою Valv Fremont — саме його пов’язують із наступним поколінням стаціонарної Steam-консолі.

Минулого року цей залізний прототип ганяли на Windows 11, але нова серія бенчмарків показує принципово іншу картину: пристрій вперше працює на рідній SteamOS, яка базується на Linux. Для індустрії, де десятиліттями Windows залишалася де-факто стандартом для ПК-геймінгу, це помітний зсув.

Ведучий прямо порівнює відчуття від ситуації «до» і «після». Раніше саме Windows 11 була очевидною відповіддю на питання «де все працює», тоді як macOS і Linux сприймалися як проблемні платформи для ігор. Тепер, із появою сучасної SteamOS, стало «незручно й незвично» констатувати, що Windows 11 більше не є найкращою платформою для геймінгу з погляду оптимізації.

Зміна ОС — не просто технічна деталь. Це демонстрація амбіцій Valve: зробити SteamOS не другорядною оболонкою для портативного Deck, а повноцінною базовою платформою для серйозного ігрового заліза.

Шестиядерний AMD на 5 ГГц і бенчмарки вище десктопних Ryzen

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

Результати тестів це підтверджують. У Geekbench нова консоль показує вражаючий приріст як в однопотоковому, так і в багатопотоковому режимі. За підсумковими балами вона в середньому набирає в півтора раза більше, а іноді й удвічі більше, ніж Steam Deck, який до цього був референсним пристроєм Valve у світі геймінгу.

Ще цікавіше порівняння з десктопною класикою. Valv Fremont у цих бенчмарках на 5–10% випереджає популярний процесор Ryzen 5 5600X. Тобто йдеться не просто про черговий «ігровий гаджет», а про машину, яка за процесорним ресурсом виходить на рівень добре відомих настільних конфігурацій.

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

140 тонн консолей і корабель із VR: Valve готується без дефіциту

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

З 10 червня до США прибув ще один корабель — уже з обладнанням для віртуальної реальності. У документах зазначено близько 13 тонн VR-комплектів. Ця зв’язка дозволяє зробити логічний висновок: разом із новою Steam‑консоллю виходить і новий VR-шолом компанії.

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

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

Десктоп у форм-факторі консолі та удар по Xbox

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

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

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

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

Ціна понад $1000 і календар релізу

Окремий блок витоків стосується грошей і таймінгу. За наявною інформацією, ціна нової Steam‑машини буде більшою за 1000 доларів США. Це автоматично виводить пристрій у сегмент, де він конкурує не тільки з консолями, а й з готовими ігровими ПК.

Для Valve така стратегія виглядає логічною: потужність на рівні та вище десктопних CPU, ставка на власну ОС та інтеграція з VR — усе це формує продукт преміум-класу. На цьому тлі бренд і екосистема Steam стають важливими аргументами, здатними виправдати високу ціну в очах аудиторії, яка готова платити за продуктивність і гнучкість.

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

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

Підсумок: коли ПК- та консольний світи стирають кордони

Новий пристрій під кодовою назвою Valv Fremont виглядає як спроба Valve переписати правила гри в сегменті домашнього геймінгу. Перехід із тестів Windows 11 на рідну SteamOS, шестиядерний AMD-чип на 5 ГГц, бенчмарки вище популярного Ryzen 5 5600X і масштабні поставки консолей разом із VR-шоломами — усі ці елементи складаються в єдину картину.

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

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

Джерело

YouTube — «Apple СКАСУЄ осінні iPhone?! Тім Кук ШОКУВАВ заявою про ціни на Apple»

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

Пам’ять дорожча за камеру й процесор

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

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

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

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

Від смартфонів до ноутбуків і консолей: «липень — початок лиха»

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

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

На підтвердження цієї тенденції вже є кілька показових рішень на ринку персональних комп’ютерів.

Microsoft «мовчки» переписала цінники на всю лінійку Surface. Базові 13‑дюймові Surface Pro піднялися з 999 доларів до 1500. Тобто плюс 500 доларів «просто на рівному місці». Це не косметична правка, а суттєвий зсув у позиціонуванні продукту: пристрій, який раніше стояв на нижній межі «преміального» сегмента, тепер опинився в значно вищій ціновій лізі.

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

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

Як дата-центри «виїдають» ринок споживчої пам’яті

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

Лучков наводить оцінку аналітиків: лише цього року дата-центри з’їдять 70% усіх випущених чипів пам’яті у світі. Паралельно доходи виробників пам’яті вже зросли на 260%. Це означає, що основний потік DRAM і флеш-пам’яті тепер іде не в смартфони й ноутбуки, а в сервери, які навчають та обслуговують моделі ШІ.

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

Головні виробники пам’яті самі не приховують, що на горизонті немає швидкого полегшення. В Samsung кажуть, що дефіцит триватиме щонайменше до середини 2027 року. А їхній найбільший конкурент SK Hynix (у трансрипті згаданий як SKX) узагалі не радить чекати закінчення кризи раніше 2030 року.

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

Що це означає для покупців і чому раптом важливі чохли

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

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

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

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

Висновок: ера ШІ як виклик для масового «заліза»

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

Коли більше 50% собівартості смартфона перетворюється на пам’ять, яка подвійно дорожчає ще до виходу моделі на ринок; коли Microsoft додає 500 доларів до базового Surface Pro, а портативна консоль MSI коштує близько 10 000 доларів; коли дата-центри забирають собі до 70% світових поставок чипів пам’яті, — усе це складається в цілісну картину. І в цій картині дешевої масової електроніки найближчими роками ставатиме менше.

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

Джерело

YouTube — «Apple СКАСУЄ осінні iPhone?! Тім Кук ШОКУВАВ заявою про ціни на Apple»

У свіжому випуску свого техновлогу Іван Лучков, відомий оглядач ґаджетів та ведучий каналу «Канал Лучкова», розбирає одну з найжорсткіших новин для фанатів Apple за останні роки. Після інтерв’ю Тіма Кука The Wall Street Journal стало зрозуміло: подорожчання айфонів, маків та іншої техніки компанії вже не питання «чи», а лише «наскільки» і «коли».

«Неминуче» подорожчання: Apple більше не тримає удар самостійно

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

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

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

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

iPhone 18 Pro плюс $270: нова реальність флагманів

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

Розрахунки виглядають жорстко: щоб просто не просісти по маржі, компанії доведеться підняти ціну на майбутній iPhone 18 Pro приблизно на 270 доларів. Йдеться не про «суперпреміум»-надбавку за нові функції, а про компенсацію зростання собівартості.

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

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

Mac Mini подорожчав, навіть якщо ціну не підняли

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

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

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

Цей кейс із Mac Mini можна розглядати як пробну модель для інших лінійок. Якщо ринок сприйме такий крок без значного відтоку попиту, схожі маневри можуть з’явитися і в інших категоріях.

Три тижні «старих» цін і глобальний стрибок із липня

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

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

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

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

Кук виходить зі сцени перед бурею

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

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

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

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

Що це означає для користувачів Apple сьогодні

З сукупності цих фактів вибудовується доволі чітка картина. Apple опинилася в ситуації, коли:

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

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

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

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

Джерело

YouTube: Apple СКАСУЄ осінні iPhone?! Тім Кук ШОКУВАВ заявою про ціни на Apple

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

iPhone Air 2: «найсексуальніший» ультратонкий айфон дорослішає

У закритих стінах Apple нове покоління Air проходить під кодовою назвою V62. За інсайдерськими витоками, вихід пристрою планується на весну 2027 року. Тобто йдеться не про експериментальний концепт, а про конкретний елемент оновленої лінійки, який уже вписують у довгостроковий календар.

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

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

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

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

Топовий мозок без компромісів: A20 Pro в «тонкому» корпусі

Окрема, показова деталь — вибір процесора. У випадку з Air 2 Apple, судячи з витоків, не збирається гратися в кастровані чипи. «Мозок пристрою не буде урізаним… під капотом планують ставити топовий процесор A20 Pro, такий самий, як і в осінніх флагманах того ж року», підкреслює Лучков.

Такий крок виводить Air з ніші стильних «лайт-версій» у повноцінну вищу лігу. Якщо раніше компактні чи дизайнерські моделі Apple часто супроводжувалися менш продуктивними процесорами або обмеженнями по частотах та можливостях, то тут ідеться про паритет із ювілейними iPhone 18 Pro.

Це має одразу кілька наслідків.

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

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

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

Нова карта року: осінь для «важкої артилерії», весна для базових моделей

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

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

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

Таким чином формується дворівневий ритм:

осінь — про-лінійка і складаний iPhone як вітрина інновацій та максимальних чеків;

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

Два релізи на рік як логічна маркетингова стратегія

Ідея поділу року на дві окремі презентаційні хвилі для Apple не з’являється на порожньому місці. «До 27-го року ще багато води спливе, але… це вже далеко не перший натяк на те, що Apple розбиває свій релізний рік на дві частини», нагадує Лучков. На його думку, «маркетингово це дуже логічно».

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

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

розносити інформаційні піки, щоб кожна хвиля релізів отримувала власну увагу ЗМІ та користувачів;

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

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

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

Що означає поява iPhone Air 2 у новому циклі

У цій новій ритміці iPhone Air 2 займає особливе місце. Це не просто ще один корпус із тонкими рамками, а елемент більшої стратегії:

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

отримання другої камери та топового процесора A20 Pro робить Air повноцінним учасником вищої ліги, а не стилізованим компромісом;

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

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

Джерело

YouTube — «Apple СКАСУЄ осінні iPhone?! Тім Кук ШОКУВАВ заявою про ціни на Apple»

Фіона Фанг — керівниця команд Claude Code і Co‑work в Anthropic, інженерка з понад 25‑річним стажем, яка раніше будувала Visual Studio та TypeScript у Microsoft, запускала Facebook Marketplace та працювала над AR‑і VR‑продуктами в Meta та Instagram. У розмові на подкасті Lenny’s Podcast вона дивиться не тільки на те, як AI вже радикально змінив інженерію, а й на те, що досі залишається болючим і нерозв’язаним: від автоматичних рев’ю й верифікації досвіду до освіти нових інженерів і збереження командної культури у гіперрості.

Межі автоматизації: коли “авто‑рев’ю” вже занадто далеко

Одна з найбільш практичних, але все ще відкритих дилем — наскільки далеко можна просунутися в бік повністю автоматизованих code review. Anthropic уже сильно розвантажує інженерів Claude‑рев’ю, і вузьке місце “людських” рев’ю істотно послабилося. Але питання не зникає, а радше загострюється:

«How far do you push fully automated reviews?»

Фіона наголошує на принципі “trust but verify”: моделі стають дедалі кращими, проте існують зони, де “глибока предметна експертиза” все ще критична. Для “жорстких” ділянок — системного рівня, складних розподілених сервісів, критичних поверхонь продукту — людський рев’ювер лишається обов’язковим.

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

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

Найскладніше — перевірити не факт, а досвід

На рівні інженерних метрик — продуктивність, crash‑rate, latency — у Anthropic вже вибудувано помітно більше інструментів: моніторинг, фреймворки “bad vs sad”, експерименти з автоматизацією тестів і контент‑перевірок. Але верифікація “досвіду” користувача залишається набагато важчою задачею.

Фіона формулює це так:

«Basically, how do you solve how do you set up a verification that the experience is what you want it to be?… that one is still a hard one to crack.»

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

Тому Anthropic комбінує кілька підходів:

• стандарти “bad vs sad” — чітке розділення між фатальними, нерепарованими провалами (“bad”) і дрібними болями, які окремо терпимі, але у сумі перетворюють досвід на поганий (“sad”);
• автономію команд у визначенні, що саме в їхньому домені вважається “bad” і “sad” (наприклад, для CLI — краш із втратою роботи, для UI — миготіння чи нестабільність);
• постійне “догфудинг‑тиском” лідерів: Фіона свідомо щодня користується продуктами, які будує команда, саме як кінцевий користувач, а не тільки як менеджер, що дивиться в дашборди.

Однак навіть з цими шарами контроль над “тим самим” досвідом лишається одним із головних інженерних відкритих питань.

Асинхронні рутини й нова втома від контекст‑світчингу

Ще одна свіжа проблема виникає не з браку, а з надлишку автоматизації. З появою рутин у Claude Co‑work команда перейшла від ручних ранкових ритуалів до “флоту агентів”, які працюють у фоновому режимі: моніторять Slack‑канали з фідбеком, генерують PR‑и, агрегують інциденти, шукають патерни.

Це кардинально змінює стиль роботи:

«Because with routines and everything being more async… I do see the context switching load increasing.»

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

«I think there is starting to be a high load on our context switching… I even remember I myself was like, oh I kicked like I kicked off…»

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

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

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

Ким стане “молодий інженер”, якщо код пише модель

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

«How we grow the next generation just because how you and me got to our engineering path is just so different.»

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

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

«I wonder if it’s… for software engineering, it’s almost like you go more towards a fellowship or apprenticeship program.»

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

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

Головний страх — не технології, а культура однієї команди

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

«The thing that keeps me up at night is… the culture of the team… as we grow… maintaining the things… that one team mentality.»

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

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

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

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

Нерозв’язані задачі як дорожня карта

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

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

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

Джерело

Lenny’s Podcast — Building the most AI-pilled engineering team in the world | Fiona Fung (Anthropic)

Коли досвідчена інженерна керівниця Фіона Фанг прийшла в Anthropic очолити команди Claude Code та Co‑work, вона вже мала за плечима понад 25 років в розробці, керувала інфраструктурою та продуктами в Microsoft і Meta та відповідала за організацію з сотень людей в Instagram. В Anthropic вона опинилася в іншій реальності: код пишуть з допомогою AI, темпи релізів радикально зростають, а відрив менеджерів від продукту миттєво карається якістю.

Відповідь компанії на цей виклик радикальна: всі менеджери стартують як індивідуальні контриб’ютори (IC) і продовжують писати код. Не як хобі, а як системна вимога до лідерства. Фіона пояснює, чому цей підхід став фундаментом культури Anthropic, як він змінює онбординг, довіру в команді та навіть кар’єри менеджерів, які давно не відкривали IDE.

«Спочатку — клавіатура». Як Anthropic перевертає траєкторію менеджера

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

Формула проста й без прикрас: перш ніж підтримувати людей, дай собі «maker time», щоб «actually type deep into the code and learn the code base». Лід не отримує команду доти, доки не проживе життя рядового інженера на цьому ж коді та в цьому ж продукті.

Це не теоретична позиція. Ще в Meta Фіона, прийшовши менеджером, навмисно провела перший квартал як IC, щоб відчути, «що таке шипити як Meta engineer». Вона згадує, як цінними виявилися ці перші місяці — саме тоді з’явилося розуміння інструментів, процесів, реальних болів у пайплайні поставки коду.

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

Чому менеджер має шипити PR-и — навіть якщо вони дрібні

Фіона не приховує: пул-реквести, які вона робить зараз, — не про блискучі фічі. «The PRs I do are… it’s more about for me it’s important because it keeps me in the flow because we’re making so many changes to Co-work and Code».

Тобто значення має не масштаб зміни, а сам факт участі в потоці розробки. Anthropic живе в режимі постійних змін інструментів і досвіду: Claude Code, Co‑work, нові рутини, нові способи валідації. Якщо лід не в коді, він буквально випадає з реальності продукту.

Фіона прямо формулює цей ризик: «If you as a leader… you’re not living and breathing your product every day you sometimes kind of lose touch of touch and feel of the product».

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

Інший ефект — довіра команди. Фіона помітила повторювану реакцію в будь‑якому продукті, куди приходила: VR, AR, Instagram, тепер Claude. «One of the first comments that comes back to me is, ‘Hey, you know what? I really love how you’re actually using what we build.’»

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

Як AI повертає менеджерів до коду — і чому це корисно

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

Повернутися до коду допоміг саме Claude. Перший тиждень в Anthropic вона майже автоматично пішла старою траєкторією — знайомитися з людьми, пити каву, питати, чим допомогти. Потім зупинилася й змінила маршрут: «oh wait, wait, wait, let me ask Claude». Модель стала для неї «onboarding buddy»:

• пояснювала кодову базу;
• підказувала, як написати тести в стилі test‑driven development;
• допомагала придумати сценарії ручного тестування, щоб покрити всі кейси.

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

Виявилося, що вона не одна така. «I’ve actually had a lot of friends reach out to me that have been managers for a while that’s like, ‘Hey, I’m shipping code again thanks to Claude.’»

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

Менеджер як головний догфудер

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

Цей патерн повторювався в кожній ролі: Facebook Marketplace, VR‑ і AR‑продукти, Instagram, тепер Claude. Де б вона не опинялася, перший крок — стати важким користувачем того, що робить команда. І це не лише про інженерну якість.

В Marketplace, наприклад, саме особистий досвід продажу речей виявив новий вектор шахрайства, який не ловили метрики. У VR — її специфічне сетап‑середовище допомагало стабільно відтворювати дивні проблеми з висотою підлоги. У Claude Co‑work — регулярне використання для власних задач (зокрема, ненависних ейчар‑та витратних процесів) підсвітило сценарії, які виявилися життєво важливими для малих бізнесів.

У Anthropic це стало частиною очікувань до лідерів. Якщо ти ведеш продукт, до якого маєш доступ як користувач, — використовуйте його сам. Якщо ти керуєш командою, де складно самому бути користувачем (наприклад, складна B2B‑інфраструктура), — компенсуй це постійними зустрічами з клієнтами. «If you’re leading a team where it’s really hard for you to use the product, then meet with customers… every time I’ve done customer visits, I always learn something new.»

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

Культура «менеджер = IC»: що це змінює на рівні організації

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

Коли менеджери стартують як IC і продовжують писати код, виникає кілька ефектів:

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

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

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

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

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

Висновок: управління в епоху AI — це знову про ремесло

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

Фіона Фанг формулює це не як романтичну ностальгію, а як практичний інструмент. Без «maker time» на старті, без регулярних PR‑ів, без «living and breathing your product every day» лід дуже швидко втрачає зв’язок із реальністю — особливо там, де AI щодня змінює саму природу роботи.

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

Джерело: Building the most AI-pilled engineering team in the world | Fiona Fung (Anthropic)