УТ‑2 поговорив із Максом Лобовським, співзасновником і CEO Formlabs — однієї з найпомітніших компаній у професійному 3D‑друці, яка оцінювалася приблизно у $2 млрд ще у 2021 році. Formlabs відвантажила понад 100 тисяч принтерів, генерує понад $200 млн річного доходу й працює прибутково. Її обладнання використовують Tesla, Apple, медичні клініки, стоматологія, аерокосміка та оборонка.

У центрі цієї історії — не стільки бізнес, скільки технологія: дві основні платформи Formlabs (SLA та SLS) і те, як компанія будує навколо них закриту, але надійну екосистему «залізо + софт + матеріали».

Дві технологічні платформи Formlabs: смола та порошок замість розплавленої нитки

Formlabs свідомо не грає на полі масового FDM‑друку, який більшість людей асоціює з 3D‑принтерами. Компанія сфокусована на двох інших технологіях — SLA та SLS, які орієнтовані насамперед на професійних користувачів.

SLA (stereolithography) — це друк із фотополімерної смоли. Рідкий полімер у ванні локально засвічується джерелом світла, твердне шар за шаром і формує деталь. SLS (selective laser sintering) — це друк із порошкових пластикових матеріалів, зазвичай нейлону: лазер локально спікає порошок у тверду структуру.

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

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

SLA Formlabs: швидкість, деталізація і ізотропна міцність

Ключова відмінність SLA‑платформи Formlabs — у поєднанні швидкості, якості поверхні та механічних властивостей.

Повний шар за 10 секунд

У сучасних SLA‑принтерах Formlabs ціла площина побудови розміром приблизно 350×200 мм може засвічуватися за близько 10 секунд. Це означає, що час друку залежить переважно від висоти моделі, а не від того, наскільки щільно заповнена платформа.

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

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

Ізотропна механіка проти шарової слабкості FDM

Ще одна принципова різниця — механічні властивості. SLA‑деталі Formlabs мають ізотропні характеристики: міцність у напрямку X, Y і Z приблизно однакова. Це досягається за рахунок того, що смола полімеризується в об’ємі, а не просто «наклеюється» шарами, як у FDM.

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

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

Висока роздільна здатність і «нелайк‑3D‑друк» вигляд

Ще один аспект — візуальна якість. SLA забезпечує дуже високу роздільну здатність і гладку поверхню. Лобовський підкреслює: якщо дати людині в руки SLA‑деталь Formlabs, вона часто не здогадується, що це 3D‑друк — настільки вона схожа на деталь, виготовлену литтям під тиском.

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

Слабке місце SLA — крихкість. Formlabs намагається його закрити

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

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

Щоб зменшити цей розрив, Formlabs активно працює над хімією смол. Нещодавно компанія запустила дві нові SLA‑смоли зі значно вищою ударною в’язкістю. Це не робить фотополімери повним замінником усіх FDM‑матеріалів, але розширює спектр застосувань, де SLA‑деталі можуть працювати як кінцеві вироби, а не лише як прототипи.

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

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

Якщо SLA — це про гладку поверхню, високу деталізацію й ізотропну міцність, то SLS у виконанні Formlabs — про складну геометрію, відсутність підтримок і матеріали, придатні для кінцевих промислових деталей.

Порошок як природна підтримка

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

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

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

Нейлон із хорошими термомеханічними властивостями

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

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

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

Закрита інтегрована екосистема: чому Formlabs не грає в open‑source

На відміну від багатьох FDM‑платформ, які виросли з open‑source‑руху, Formlabs із самого початку будує закриту, щільно інтегровану екосистему. Принтери, програмне забезпечення й матеріали розробляються як єдине ціле.

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

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

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

У 3D‑друці існує open‑source‑спільнота, особливо навколо FDM. Але, на думку Лобовського, такі рішення загалом відстають від провідних закритих систем за продуктивністю, надійністю й якістю. У цій сфері поки немає аналога Linux — відкритого й водночас найкращого у своєму класі.

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

Чому швидкий 3D‑друк — це крок до того, щоб «залізо працювало як софт»

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

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

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

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

Висновки: професійний 3D‑друк виходить за межі «іграшок для ентузіастів»

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

SLA‑платформа компанії дає високу швидкість (повний шар 350×200 мм приблизно за 10 секунд), ізотропні механічні властивості й поверхню, яка майже не відрізняється від лиття. SLS дозволяє друкувати складну геометрію без підтримок із нейлону, придатного для кінцевих деталей, і займає проміжне місце за роздільною здатністю між FDM та SLA.

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

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

Джерело

Як зробити $2B на 3D-друку, конкуренція з Китаєм, враження від України. CEO Formlabs Макс Лобовскі — УТ‑2

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

Довгі автономні завдання без втрати темпу

Одна з ключових змін — здатність GPT‑5.5 працювати над одним завданням десятки годин поспіль. За словами Фріела, інженери запускали модель на окремих задачах більш ніж на 40 годин без перерв, і вона доводила ці завдання до завершення.

Це відкриває сценарії, які раніше були малопрактичними:

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

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

Codex для (майже) всього: не лише для бекенду

Важливу роль у використанні GPT‑5.5 відіграє оновлений застосунок Codex — «Codex for (almost) everything». Він став інструментом не тільки для класичних задач бекенд- і платформної розробки, а й для:

• фронтенд‑розробки;
• побудови функціоналу поверх ChatGPT;
• роботи з внутрішніми продуктами та сервісами.

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

Підсилення не лише інженерів: код як спільний ресурс

Ще один помітний ефект — розширення кола людей, які реально взаємодіють із кодом. За спостереженнями Фріела, GPT‑5.5 підвищує внесок не тільки інженерів і дослідників, а й співробітників з інших функцій.

Модель дає змогу:

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

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

Друге життя старих проєктів і GPT як викладач

Окремий пласт можливостей стосується роботи зі старим кодом. Фріел розповідає, що повернувся до власних проєктів 10–15‑річної давнини — ще з часів навчання в коледжі — і зміг довести їх до робочого стану, хоча вони не збиралися вже 5–10 років.

GPT‑5.5 у поєднанні з Codex допомагає:

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

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

Для розробників це означає можливість:

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

Джерело

First impressions of GPT-5.5 from Aaron Friel — OpenAI (YouTube)

Багато охочих увійти в AI-інженерію застрягають в одному й тому самому сценарії: нескінченні курси, конспекти, плейлисти на YouTube — а коли доходить до написання коду, в голові порожньо. Канал Tech With Tim пропонує чіткий, практичний план, як вийти з цього кола й почати будувати реальні AI-застосунки на Python з нуля.

Який Python насправді потрібен для старту в AI

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

Для перших AI-застосунків достатньо відносно невеликого, але цільового набору інструментів:

• Базові конструкції мови
• змінні та типи даних
• форматовані рядки (f-strings)
• списки та словники
• цикли й умовні оператори

• функції

• Робота з помилками та середовищем

• базове оброблення помилок через try/except
• читання та запис файлів

• використання змінних середовища (щоб не хардкодити API-ключі)

• Інструменти екосистеми

• робота з JSON (майже всі AI API повертають саме його)
• менеджер пакетів pip або альтернативи на кшталт uv
• розуміння віртуальних середовищ і запуску скриптів

Натомість не обов’язково на старті занурюватися в:

• глибоке ООП і метакласи
• асинхронність
• декоратори
• велику частину стандартної бібліотеки

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

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

Пасивне навчання проти активного: чому «просто дивитися» не працює

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

Дослідження показують, що:

• пасивне навчання (перегляд, читання) дає близько 20% засвоєння матеріалу;
• активне навчання (написання реального коду, розв’язання задач) може підняти це до 75–90%.

Звідси проста, але жорстка формула:
якщо ви не друкуєте код — ви майже не вчитеся.

Будь-який ресурс, який ви обираєте для вивчення Python і AI, має:

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

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

Перший тиждень: свій перший AI-застосунок на Python

Найшвидший спосіб «приклеїти» Python у пам’яті — якнайшвидше підключити його до реальної AI-моделі. Рекомендація: зробити перший виклик до LLM API вже в перший тиждень навчання.

Базовий план:

1. Отримати API-ключ
   Зареєструватися в OpenAI або Anthropic і згенерувати ключ доступу.

2. Встановити SDK
   Через pip install додати офіційний SDK обраного сервісу.

3. Написати мінімальний скрипт (≈10 рядків)

4. сформувати простий prompt;
5. надіслати його до моделі;

6. вивести відповідь у консоль.

7. Обгорнути це у функцію й додати цикл

8. зчитувати введення користувача;
9. передавати його в модель;
10. виводити відповіді в терміналі;
11. повторювати в циклі — вийде простий CLI-чатбот.

Цей невеликий проєкт одразу дає контекст для базових понять:

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

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

Три проєкти, які закладають фундамент AI-інженера

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

1. CLI-чатбот із пам’яттю

Функціональність:

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

Що це дає:

• глибше розуміння списків і словників (збереження історії);
• роботу з циклом запит–відповідь до LLM API;
• перші кроки до організації коду в більш структурований застосунок.

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

2. AI-сумаризатор файлів або Doc Q&A

Ідея:

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

Ключові навички:

• file I/O — читання файлів, обробка тексту;
• chunking — розбиття великих текстів на фрагменти;
• основи RAG (Retrieval-Augmented Generation) — патерн, де модель отримує не лише запит, а й релевантні фрагменти з бази знань.

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

3. AI-агент з інструментами

Суть:

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

Критерій готовності:

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

Що це розвиває:

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

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

Як не зірватися назад у «ще один курс» і продовжити рости

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

Щоб цього уникнути, варто дотримуватися кількох правил.

1. Документація — перше джерело, а не останнє

Замість того, щоб шукати відео на будь-яке питання, корисно:

• читати офіційну документацію бібліотек, які ви вже використовуєте:
• OpenAI SDK, Anthropic;
• FastAPI, Pydantic;
• LangChain, LangGraph тощо;
• знаходити в ній функції й можливості, про які ви ще не знали;
• одразу пробувати їх у власних проєктах.

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

2. Перебудова існуючих проєктів

Замість запускати новий курс, можна:

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

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

3. Туторіали — тільки під конкретний запит

Відеоуроки варто використовувати точково:

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

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

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

Джерело

Do THIS instead of watching endless tutorials — how to learn Python for AI — Tech With Tim

Онлайн‑сервіси для розробників дедалі частіше працюють не з одним, а з цілою екосистемою великих мовних моделей. У розмові на подкасті 20VC with Harry Stebbings представник Replit окреслив підхід компанії до вибору й комбінування моделей — від Anthropic до Google Gemini — та пояснив, чому майбутнє бачить як «суспільство моделей», а не монокультуру одного провайдера.

Anthropic як «робоча конячка», але не єдина

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

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

Gemini і критерій «ціна–якість»

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

Це особливо помітно в спеціалізованих задачах, наприклад:

• court search (пошук по судових або подібних корпусах даних)
• інші підзадачі, де не потрібна максимальна «розумність», але важлива економічність

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

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

«Суспільство моделей» і поява agent labs

Ще у 2022 році в Replit сформулювали концепцію, яку назвали «суспільство моделей» (society of models). Її суть:

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

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

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

До таких компаній, окрім Replit, зараховують, наприклад, Cursor та інших гравців, які створюють «розумні» середовища розробки на базі LLM‑агентів.

Від задачі до технології, а не навпаки

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

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

У результаті формується багаторівнева система, де:

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

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

Джерело

What models does Replit use? — 20VC with Harry Stebbings

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

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

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

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

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

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

Ручне керування пам’яттю: команда compact

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

compact

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

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

Як зберегти важливе під час очищення

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

compact <опис того, що потрібно залишити>

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

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

Таким чином, користувач отримує можливість:

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

Чому це важливо для розробників

Керування контекстом — одна з центральних задач при роботі з AI-інструментами для коду. Від того, наскільки грамотно організована «пам’ять» системи, залежить:

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

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

Source

Повний огляд Claude Code – Частина 15 #аі #python #вайбкодинг

У світі споживчих соцмереж майже ніхто не зміг повторити шлях Snapchat. За 15 років сервіс виріс до понад 1 млрд активних користувачів на місяць, понад $6 млрд річної виручки та 8 млрд AR‑фото на день. Його співзасновник і CEO Еван Шпігель рідко дає інтерв’ю, але саме через його призму добре видно, як виглядає довгострокова гра в індустрії, де кожну вдалу ідею миттєво копіюють, а технологічні тренди змінюються швидше, ніж покоління користувачів.

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

Чому лідери мають виходити за межі дашбордів

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

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

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

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

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

Як із поведінки користувачів народилися Stories

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

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

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

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

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

Скриншоти як фундамент довіри: малопомітна фіча, що врятувала ранній Snapchat

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

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

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

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

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

Життя під мікроскопом: коли кожну фічу копіюють гіганти

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

Практика це підтверджує. Майже кожна велика інновація Snap — Stories, swipe‑навігація, камера як головний екран, AR‑лінзи, підписка Snapchat Plus — рано чи пізно з’являлася в продуктах більших гравців. Останній приклад, який він згадує, — Instagram Plus, що вийшов слідом за Snapchat Plus, коли у підписки Snap вже було 25 млн користувачів і понад $1 млрд річного доходу в річному перерахунку.

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

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

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

«Середня дитина» між стартапами й гігантами

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

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

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

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

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

Екранний час і діти: не про заборони, а про намір

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

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

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

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

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

Довга дистанція в епоху AI та копіювання

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

У поєднанні з усім вищесказаним вимальовується цілісна філософія довгострокового будівництва:

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

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

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

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

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

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

Висновок: коли головний ресурс — не код, а розуміння людей

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

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

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

Джерело

YouTube: The AI era has made distribution the most important moat | Evan Spiegel (Snapchat CEO)

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

Світ, спроєктований під «модульного чоловіка»

Історично людське тіло в архітектурі й промисловому дизайні уявляли як чоловіче. Від «Вітрувіанської людини» Леонардо да Вінчі до концепції «Modular Man» у ХХ столітті — саме чоловічі параметри ставали стандартом для розмірів меблів, будівель, автомобілів.

Наслідок очевидний:
– жінок рідко вимірювали,
– їхній досвід не враховували,
– їхню присутність у просторі не цінували.

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

• жіночі краш-тести з’явилися лише близько 20 років тому;
• жінок почали включати в медичні дослідження лише з 1991 року.

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

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

Офіс, де жінкам справді зручно: що змінюється

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

Фізичний простір: від паркінгу до дверей

Серед типових «дрібниць», які виявляються зовсім не дрібницями:

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

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

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

Робота й догляд: не робити вигляд, що дітей не існує

Одна з найгостріших тем — поєднання роботи й догляду за дітьми:

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

Альтернатива — вбудувати догляд у структуру робочого дня:

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

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

Соціальний вимір: навчання й амбіції

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

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

У такому середовищі:

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

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

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

На рівні міст проблема ще масштабніша. Формально 94% міст у США мають затверджені плани розвитку. Але лише 2% цих документів хоч якось згадують жінок.

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

Невидима робота: догляд як ключ до міського дизайну

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

• середній профіль доглядальниці за літньою людиною — 49-річна жінка,
• вона працює повний день,
• і додатково витрачає приблизно 20 годин на тиждень на догляд за родичем.

Попри це:

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

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

Уявний день, який міг би стати нормою

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

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

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

Економічний ефект: чому це вигідно всім

Аргумент «це правильно» часто не працює в політиці й бізнесі без цифр. Але вони теж на боці змін.

• У робочій силі чоловіків більше, ніж жінок, а рівень участі жінок у праці в США зараз приблизно такий самий, як 30 років тому — прогрес застиг.
• Якщо б жінки працювали на тих самих рівнях, що й чоловіки, ВВП США зріс би на 5%, або приблизно на 1 трильйон доларів.

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

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

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

Що потрібно змінити: не «підлаштувати», а переосмислити

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

Це означає:

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

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

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

Джерело

Why the World Is Still Not Built for Women | Virginia Santy | TED

Сервіси на кшталт Claude Code дедалі частіше використовують як інструмент для програмування, аналізу коду та роботи з великими текстами. Автор каналу KODARIK у своєму повному огляді пояснює один із ключових технічних аспектів таких систем — контекстне вікно (CTX) і механізм його автоматичного очищення.

Що таке CTX і чому воно обмежене

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

• Зазвичай контекстне вікно має обмеження, наприклад:
• стандартні моделі — близько 200 000 токенів;
• розширені — до 1 млн токенів.
• Індикатор CTX показує, наскільки ця «пам’ять» заповнена. У прикладі з огляду — лише 10%.

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

Що відбувається, коли контекст переповнюється

Коли CTX у Claude Code заповнюється повністю, система не просто «обриває» історію діалогу. Замість цього працює спеціальний механізм самоочищення контексту.

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

Механізм самоочищення: як модель вирішує, що зберегти

Алгоритм роботи з переповненим контекстом у Claude Code можна описати поетапно:

1. Повторне читання історії
   Модель перечитує всю історію розмови — весь поточний контекст.

2. Виділення найважливішого
   Із цієї історії вибираються ключові моменти:

3. важливі факти;
4. суттєві уточнення;

5. критичні деталі завдання чи коду.

6. Формування короткого підсумку
   На основі відібраного створюється стислий підсумок — конденсована версія всієї розмови.

7. Оновлення контексту
   У контексті залишається саме цей підсумок, а все інше — другорядні деталі, «вода», повтори — видаляється.

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

Чому це важливо для розробників і користувачів

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

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

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

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

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

Source

Повний огляд Claude Code – Частина 14 #аі #python #вайбкодинг

У розмові на подкасті Lenny’s Podcast співзасновник і CEO Snap Еван Шпігель описує момент, у якому опинилася компанія, як «crucible moment» — випробувальний, переломний рік. Snapchat, що виріс до понад 1 млрд активних користувачів на місяць і більш ніж $6 млрд річної виручки, входить у фазу, де штучний інтелект не просто додається до продукту, а перебудовує сам спосіб, яким цей продукт створюється й як ним керують.

Йдеться не лише про нові AI-фічі в додатку. У Snap змінюється класична тріада «дизайнер — продакт-менеджер — інженер», дизайнери починають напряму шипити код, компанія переводить трансформацію в рамку jobs-to-be-done, а сама роль CEO, за словами Шпігеля, за 15 років змінилася до невпізнання. І все це відбувається на тлі його переконання: справжнім обмеженням епохи AI стане не технологія, а готовність суспільства її прийняти.

Кінець класичної тріади: коли дизайнер шипить код

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

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

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

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

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

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

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

Швидкість проти надійності: навіщо дизайнерам «рейки безпеки»

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

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

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

Це особливо важливо для компанії масштабу Snap, де понад 1 млрд людей щомісяця користуються продуктом, а щодня публікується понад 8 млрд фото з AR-лінзами. Будь-яка помилка в коді може миттєво торкнутися гігантської аудиторії.

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

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

AI як інструмент для «робіт, які потрібно виконати», а не магічний шар

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

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

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

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

Такий підхід важливий з кількох причин.

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

По-друге, jobs-to-be-done дає Snap структурну мову для внутрішньої координації. Коли дизайнер, інженер, продакт і CEO говорять не про «моделі» чи «ендпойнти», а про конкретні «роботи» користувача, легше узгодити пріоритети й зрозуміти, де AI справді створює нову цінність.

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

Людська готовність як головний «вузький прохід» епохи AI

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

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

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

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

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

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

Як змінилася робота CEO: від інтуїтивного лідерства до структурованої комунікації

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

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

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

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

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

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

Чому «вирішальний рік» для Snap має непропорційне значення

Коли Шпігель називає поточний рік «crucible moment» для Snap, він має на увазі не просто черговий етап реструктуризації чи зміну пріоритетів. Йдеться про період, у якому ставки для довгострокової траєкторії компанії особливо високі.

Причин кілька.

По-перше, ринок споживчих технологій переживає фазу, коли класичні програмні «ріви» — унікальні фічі, інтерфейси, навіть цілі формати — стрімко девальвуються. Сам Шпігель згадує, що Snap ще 15 років тому усвідомив: софт сам по собі не є захистом. Сьогодні, в епоху AI, це стає загальновизнаним фактом. Моделі дозволяють швидко відтворювати й покращувати функціональність конкурентів, а великі гравці не соромляться копіювати успішні ідеї. Історія зі Stories, AR-ефектами, підпискою Snapchat Plus, яку згодом віддзеркалюють конкуренти, лише підкреслює це.

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

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

«Crucible moment» — це не лише про ризики, а й про можливість. Якщо Snap зможе успішно поєднати:

• AI як прискорювач роботи дизайнерів і команд;
• чіткі guardrails, які захищають надійність і безпеку;
• jobs-to-be-done як компас, що тримає фокус на реальних задачах користувачів;
• і нову, більш структуровану модель лідерства,

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

Чому «бути ближче до користувача» стає ще важливіше в епоху AI

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

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

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

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

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

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

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

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

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

Організовувати AI-трансформацію варто не навколо технології, а навколо jobs-to-be-done — конкретних «робіт», які користувачі намагаються виконати.

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

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

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

Джерело

The AI era has made distribution the most important moat | Evan Spiegel (Snapchat CEO)

Google представив новий інструмент Android CLI — командний інтерфейс для керування середовищем Android Studio та емуляторами безпосередньо з термінала. Автор каналу Philipp Lackner демонструє, як цей інструмент вбудовується в «AI-first» робочі процеси, де значну частину роботи виконують агентні системи на кшталт Claude чи інших код-асистентів.

Навіщо Android CLI у світі агентів та AI-first розробки

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

Android CLI якраз і виступає такою «API-шкою» для агента:

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

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

Встановлення та ініціалізація: що змінюється після android init

Android CLI не входить до стандартної поставки Android Studio — його потрібно завантажити окремо з офіційної сторінки Google:

https://developer.android.com/tools/agents/android-cli

Після встановлення вбудований термінал Android Studio (або будь-який інший) починає розуміти команду android -h, яка показує список доступних підкоманд.

Ключовий крок — ініціалізація:

android init

Ця команда:

• налаштовує середовище для роботи CLI;
• встановлює «skills» (навички) для агентів, таких як Claude чи Codex;
• додає інструкції для агентів, як саме використовувати Android CLI, які є команди та для чого вони потрібні.

Окремо доступний механізм «skills», які можна переглянути:

android skills list

Серед навичок, які пропонує Google:

• міграція XML-компонентів у Jetpack Compose;
• робота з Navigation 3;
• підтримка edge-to-edge;
• оновлення Google Play Billing Library.

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

Керування проєктами та емуляторами з термінала

Створення нового Android-проєкту

Android CLI дозволяє створювати нові Android Studio-проєкти без відкриття майстра в IDE. Наприклад:

mkdir demo-app
cd demo-app
android create --name "DemoApp"

У результаті в каталозі з’являється повноцінний Android-проєкт на базі стандартного шаблону (за замовчуванням — Empty Activity). Для агента це означає можливість:

• створити новий проєкт «з нуля»;
• одразу почати генерувати код, не взаємодіючи з UI Android Studio.

Робота з емуляторами

CLI надає набір команд для роботи з Android-емуляторами:

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

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

Пошук в офіційній документації

Окрема команда — пошук по офіційній Android-документації:

android docs search navigation

CLI повертає список результатів із URL, які агент може далі завантажити й використати як джерело правдивої інформації (наприклад, щодо Navigation 3). Це зменшує ризик «галюцинацій» моделі, коли вона вигадує API чи поведінку фреймворку.

Аналіз UI: від JSON-структури до точних координат кліку

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

android layout: текстовий опис поточного UI

Команда android layout повертає JSON-структуру поточного екрана:

• список UI-елементів;
• їхні координати в пікселях;
• вирівнювання;
• текстові значення (наприклад, "0 of 1 habits").

Для агента це зручний спосіб:

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

Раніше схожу задачу можна було вирішити через adb exec-out uiautomator dump, який повертає XML-структуру з більш детальною інформацією (фокус, доступність, enabled-стан тощо). Але:

• XML-вивід значно довший;
• споживає більше токенів при передачі в LLM.

JSON-вивід android layout — компактніший, що важливо для агентних сценаріїв.

Скриншоти з анотаціями: android screen capture --annotate

Android CLI також уміє робити скриншоти екрана:

android screen capture

Це звичайний PNG-файл, який можна використати для візуальної перевірки інтерфейсу, зокрема:

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

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

android screen capture --annotate

У цьому режимі CLI:

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

Ці номери — ключ до наступного кроку: перетворення «елемент №4» на конкретні координати для кліку.

Визначення координат елемента: android screen resolve

Після отримання анотованого скриншота агент може звернутися до CLI, щоб дізнатися координати конкретного елемента:

android screen resolve \
  --screenshot screenshot.png \
  --action "tap #4"

CLI повертає готову shell-команду з реальними координатами елемента з номером 4. Далі це можна поєднати з ADB:

adb shell input tap <x> <y>

У підсумку агент отримує повний цикл:

1. Зробити анотований скриншот.
2. Обрати потрібний елемент за номером.
3. Отримати координати через android screen resolve.
4. Виконати tap через adb shell input.

Цей підхід дозволяє:

• клікати по конкретних елементах (іконках, кнопках, вкладках);
• переходити між екранами;
• далі аналізувати новий стан UI через android layout або новий скриншот.

Частина цих можливостей і раніше була доступна через «чистий» ADB та UI Automator, але Android CLI:

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

AI-first Android-розробка як новий стандарт

Android CLI вписується в ширший тренд: перехід до агентно-орієнтованої розробки, де:

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

Важливий акцент: використання агента не робить розробника «вайб-кодером», якщо він:

• розуміє платформу (наприклад, нативний Android);
• володіє архітектурними підходами та системним дизайном;
• уміє будувати чіткі AI-first робочі процеси й грамотно формулювати завдання для агента.

Компанії вже починають оцінювати на співбесідах:

• якість промптингу;
• вміння працювати з AI-інструментами;
• підхід до створення фіч у зв’язці «розробник + агент».

Android CLI у цьому контексті — ще один крок до того, щоб Android-розробка стала більш автоматизованою, а роль інженера — більш стратегічною.

Джерело

Android Got a New CLI Tool! (Game Changer For AI-First Setups!)

У 2024 році Snapchat — це понад 1 мільярд щомісячних активних користувачів, більш як $6 млрд річного доходу та понад 8 мільярдів AR‑фото з лінзами щодня. Для компанії, яку багато років поспіль системно копіюють гіганти на кшталт Meta, питання «що таке справжній moat» — не теоретична дискусія, а питання виживання.

У розмові на Lenny’s Podcast співзасновник і CEO Snap Еван Шпігель описує, як компанія за 15 років дійшла до висновку, що сам софт — не захист, і як на цій основі вибудовує нову оборонну лінію: спільноти творців, масштабовану AR‑платформу та довгу ставку на апаратне забезпечення — від Spectacles до нових окулярів Specs, які мають вийти для масового ринку вже цього року.

Коли софт перестає бути moat: урок 15‑річної давнини

Snap опинилася в унікальній позиції: майже кожна її велика інновація — Stories, камера як головний екран, swipe‑навігація, AR‑фільтри, навіть формат підписки Snapchat Plus — рано чи пізно з’являлася в продуктах конкурентів.

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

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

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

Snap відчувала це на собі знову і знову. Останній яскравий приклад — підписка Snapchat Plus. Сервіс, який Snap розвиває як надбудову над основним застосунком, уже набрав 25 мільйонів передплатників і вийшов на річний run rate понад $1 млрд. Не дивно, що Meta запустила Instagram Plus — не лише з подібною моделлю, а навіть із тією ж назвою.

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

Екосистема як захист: творці, AR‑розробники та мережевий ефект

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

За роки розвитку AR‑інструментів зовнішні розробники створили на платформі Snap мільйони лінз. Це не просто бібліотека ефектів, а постійно оновлюваний шар креативу, який живе власним життям. Масштаб видно по цифрах: користувачі Snapchat щодня публікують понад 8 мільярдів фото з AR‑лінзами.

Це означає, що:

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

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

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

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

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

Підписка як другий поверх: Snapchat Plus і новий тип монетизації

Ще один елемент захисту — не просто мати велику аудиторію, а вміти будувати над нею стійкі бізнес‑моделі. Snap довго покладався переважно на рекламу, але останні роки активно розвиває підписку Snapchat Plus як додатковий шар монетизації.

Snapchat Plus — це не окремий продукт, а надбудова над основним застосунком. Вона дає доступ до додаткових можливостей і експериментальних фіч, орієнтованих на найактивніших користувачів. За відносно короткий час сервіс набрав 25 мільйонів передплатників і перевищив позначку $1 млрд річного доходу в перерахунку на річний run rate.

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

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

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

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

Той факт, що Meta запустила Instagram Plus, підкреслює: модель працює настільки добре, що її варто копіювати. Але, як і у випадку з AR‑екосистемою, просте копіювання формату не означає автоматичного відтворення всієї системи взаємодій, яку Snap вибудовував роками.

Чому Snap іде в «найважчий бізнес»: апаратне забезпечення як стратегічний moat

На тлі того, що софт легко клонувати, Snap свідомо робить ставку на те, що копіювати складніше: апаратне забезпечення. Шпігель прямо називає hardware стратегічним moat.

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

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

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

Snap уже багато років інвестує в AR‑залізо. Серед ключових кроків:

• Spectacles — ранні спроби розумних окулярів із камерою, які поєднували моду й технології;
• камера‑дрон (Pixy) як експеримент із новими формами зйомки та перспективи.

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

На цьому фундаменті компанія готується до наступного кроку — запуску споживчих AR‑окулярів Specs, які мають вийти цього року. Шпігель позиціонує їх як кульмінацію багаторічних інвестицій у hardware та AR і як ключовий елемент майбутнього moat Snap.

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

• глибоку AR‑платформу з мільйонами лінз;
• величезну базу користувачів Snapchat;
• власний апаратний пристрій, оптимізований під цей досвід,

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

Камера‑перша парадигма й glasses‑комп’ютинг: довга ставка Snap

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

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

У випадку AR‑окулярів Snap має кілька переваг:

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

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

по‑третє, спільнота розробників, які вже вміють створювати контент для AR‑середовища Snap. Для них Specs можуть стати ще одним, більш глибоким полотном.

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

Висновок: moat як система, а не одна фіча

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

• екосистема творців і AR‑розробників, які роблять платформу живою та унікальною;
• AR‑платформа з мільйонами лінз і мільярдами щоденних взаємодій;
• підписка Snapchat Plus як стабільний, повторюваний дохід і додатковий шар лояльності;
• довга ставка на hardware — від Spectacles і дрона до майбутніх Specs — як на moat, який складно відтворити.

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

Джерело

The AI era has made distribution the most important moat | Evan Spiegel (Snapchat CEO)

GitHub давно став синонімом спільної розробки, але поява потужних AI‑агентів радикально змінила саму структуру роботи над кодом. У GitHub Next — експериментальній лабораторії компанії, що займається ризикованими й дослідницькими проєктами, — над цим працює Меґґі Епплтон, staff researcher engineer і дизайнер за походженням. Її команда створює ACE (Agent Collaboration Environment) — дослідницький прототип нового типу середовища, де люди й агенти працюють разом у реальному часі, а не кожен у своєму ізольованому CLI.

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

Від «один девелопер і дві дюжини агентів» до спільного середовища

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

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

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

Сесія як канал і як комп’ютер: що таке ACE насправді

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

Кожна сесія підкріплена власною мікро‑віртуальною машиною (microVM) у хмарі, яка працює на окремій Git‑гілці. Це означає кілька важливих речей.

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

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

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

Прозорий контекст: як ACE дає змогу «зайти в чужу голову»

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

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

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

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

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

MicroVM, термінал і live‑прев’ю: чому ACE — це не «Slack з ботом»

Зовні ACE справді нагадує чат, але під капотом це повноцінне хмарне середовище розробки. Кожна сесія має свій microVM, де можна виконувати звичні термінальні команди. Розробник запускає, наприклад, bun install і bun dev, і в інтерфейсі ACE з’являється живий прев’ю застосунку в браузері, прив’язаний до цієї ж microVM.

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

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

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

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

Автоматичні коміти й PR: як агент вбудовується в Git‑процес

ACE не намагається скасувати Git чи pull request, але змінює спосіб, у який агент взаємодіє з ними. Кодуючий агент у сесії може не лише редагувати файли, а й автоматично фіксувати зміни. Після виконання завдання ACE створює коміт із згенерованим повідомленням, яке описує суть змін. Розробник може відкрити дифи, переглянути, що саме було змінено, і за потреби скоригувати результат.

Далі агент може безпосередньо з ACE створити pull request у GitHub. У описі PR додається посилання назад на вихідну ACE‑сесію. Це важливий місток між новим середовищем і звичною інфраструктурою: рецензент, який бачить PR, може одним кліком перейти до повного контексту — чату, історії промптів, попередніх ітерацій, live‑прев’ю.

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

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

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

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

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

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

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

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

Новий цикл: коли планування й реалізація зливаються

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

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

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

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

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

Висновок: ACE як лабораторія майбутнього командної розробки

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

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

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

Джерело

Collaborative AI Engineering: One Dev, Two Dozen Agents, Zero Alignment — Maggie Appleton, GitHub

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

Коли дощі більше не гарантія врожаю

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

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

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

Сонячний насос: технологія без пального й мережі

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

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

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

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

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

Від виживання до розвитку: що змінює надійна вода

Після встановлення насоса господарство Джозефін буквально «ожило»:

• кавові дерева відновилися й почали давати врожай;
• зацвіли квіти;
• ферма перестала «з’їдати» гроші й почала їх приносити.

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

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

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

Кліматична стійкість і продовольча безпека

Історія Джозефін показує ширший контекст:

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

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

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

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

Джерело

The relationship between farmers and the sun just got an upgrade #TEDTalks

Snapchat сьогодні — один із небагатьох споживчих соціальних продуктів, що не просто вижив, а й закріпився на глобальному ринку. Понад 1 млрд людей щомісяця користуються сервісом, компанія генерує більш як $6 млрд на рік, а щодня користувачі публікують понад 8 млрд фото з AR-лінзами. При цьому ядро дизайн-функції Snap — це крихітна команда з 9–12 людей без посад і формальної ієрархії, яка щотижня проганяє через себе сотні ідей разом із CEO Евана Шпігеля. Як така структура взагалі працює на цьому масштабі — і чому вона не розвалюється під тиском?

Маленька команда для гігантського продукту

На тлі гігантських продуктових організацій великих технологічних компаній структура Snap виглядає майже парадоксально. Соціальний продукт із мільярдом активних користувачів, десятками мільйонів платних підписників Snapchat Plus (сервіс уже перевищив $1 млрд річного revenue run rate), складною рекламною інфраструктурою та AR-екосистемою — і при цьому всього 9–12 людей у ядрі дизайну.

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

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

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

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

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

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

Дизайн без посад: як відсутність ієрархії зменшує політику

Ще одна принципова особливість Snap — повна відсутність титулів у дизайн-команді. Немає «старших», «головних», «VP of Design» усередині цієї групи. Формально всі — просто дизайнери.

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

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

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

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

Перший день — перша презентація: культура «робити, а не чекати»

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

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

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

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

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

Сотні ідей на тиждень: як CEO перетворює дизайн на високошвидкісний цикл

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

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

Ця філософія працює на кількох рівнях.

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

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

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

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

Дизайн як навмисне «вузьке горлечко» для цілісності продукту

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

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

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

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

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

Діалог інновацій і операцій: як Snap організовує структуру навколо маленького ядра

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

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

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

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

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

Коли софт — не moat: чому структура дизайну стала відповіддю на копіювання

Snap ще 15 років тому зробив висновок, до якого сьогодні приходить усе більше компаній: сам по собі софт не є захисним ровом. Функції легко копіюються. Історії, AR-ефекти, swipe-навігація, камера як головний екран — усе це з’явилося в Snapchat, а потім було відтворене конкурентами.

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

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

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

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

Висновок: уроки Snap для епохи, де AI стирає переваги софту

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

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

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

Джерело

The AI era has made distribution the most important moat | Evan Spiegel (Snapchat CEO)