Швидкий розвиток агентних систем на базі великих мовних моделей (LLM) оголює одну ключову проблему: штучний інтелект добре оперує фактами, але погано знає, як саме виконувати реальну роботу крок за кроком. Канал IBM Technology пропонує концепцію «навичок агентів» (agent skills) як відкритий стандарт, що додає агентам саме таку процедурну «пам’ять».

Факти проти процедур: чого бракує AI‑агентам

Сучасні LLM чудово відповідають на запитання про архітектуру Kubernetes, історію SQL чи будь-які інші факти. Але коли йдеться про конкретний бізнес‑процес — наприклад, 47‑кроковий робочий процес формування регуляторно коректного фінансового звіту — модель опиняється в глухому куті.

У такій ситуації є лише два варіанти:

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

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

Що таке навичка агента: структура skill.md

Навичка агента — це не складний сервіс, а звичайний файл skill.md у папці. Формат навмисно простий і побудований на markdown.

1. YAML‑шапка: ім’я та опис

У верхній частині skill.md розміщується YAML‑front matter з мінімальним обов’язковим набором полів:

• name — назва навички;
• description — опис того, що робить навичка і коли її слід застосовувати.

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

• name: PDF Builder
• description: «Використовувати, коли користувач просить витягти дані з PDF».

Додатково можуть бути поля на кшталт author чи version, але вони не є обов’язковими.

2. Тіло навички: інструкції та приклади

Під YAML‑шапкою розташовується основний вміст — власне інструкції:

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

Це звичайний markdown, який LLM читає як «процедурну пам’ять» для конкретного типу задач.

3. Додаткові папки: скрипти, посилання, ресурси

Папка навички може містити необов’язкові підкаталоги:

• scripts/ — виконувані скрипти (JavaScript, Python, Bash тощо), які агент може запускати;
• references/ — додаткова документація, яку агент підвантажує за потреби;
• assets/ — статичні ресурси: шаблони, файли даних та інші допоміжні матеріали.

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

Як агент працює з сотнями навичок: прогресивне розкриття

Якщо агенту додати десятки або сотні навичок, наївне завантаження всього в контекст LLM миттєво «з’їсть» токен‑бюджет. Щоб цього уникнути, використовується механізм прогресивного розкриття (progressive disclosure) у три рівні.

Рівень 1: лише метадані

На старті агент завантажує тільки:

• name
• description

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

Рівень 2: повні інструкції

Коли запит користувача відповідає опису певної навички, агент:

• підтягує повний вміст skill.md у контекст;
• використовує ці інструкції як детальний сценарій виконання завдання.

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

Рівень 3: ресурси й скрипти

Лише коли конкретне завдання цього потребує, агент:

• завантажує скрипти з scripts/;
• читає додаткові матеріали з references/;
• використовує файли з assets/.

Таким чином, агент:

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

Навички, MCP, RAG і fine‑tuning: хто за що відповідає

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

MCP: доступ до інструментів

Model Context Protocol (MCP) дає агенту змогу:

• викликати зовнішні API;
• взаємодіяти з сервісами та інструментами.

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

RAG: фактичні знання

Retrieval Augmented Generation (RAG) забезпечує:

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

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

Fine‑tuning: знання в вагах моделі

Fine‑tuning:

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

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

Навички: процедурна пам’ять

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

• як виконувати завдання;
• у якій послідовності;
• з якими умовами та судженнями.

Оскільки це просто файли:

• їх можна версіонувати;
• легко оновлювати;
• переносити між платформами.

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

Від когнітивної науки до архітектури агентів

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

• Семантична пам’ять — факти («Рим — столиця Італії»).
• Епізодична пам’ять — особистий досвід («Я був у Римі минулого літа»).
• Процедурна пам’ять — навички («Як керувати скутером у римському трафіку»).

Агентні архітектури починають віддзеркалювати цю структуру:

• семантична пам’ять → RAG і бази знань;
• епізодична пам’ять → журнали діалогів та історія взаємодій;
• процедурна пам’ять → файли навичок (skill.md).

Таким чином, навички стають ключовим шаром, який перетворює «знання фактів» на «вміння працювати».

Безпека та довіра: навички як залежності

Оскільки навички можуть містити:

• виконувані скрипти;
• доступ до файлової системи;
• роботу з змінними середовища та API‑ключами,

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

Аудити публічно доступних навичок уже виявляли:

• prompt‑ін’єкції;
• «отруєння» інструментів;
• приховане шкідливе ПЗ.

Рекомендація очевидна: ставитися до встановлення навичок так само, як до встановлення будь‑якої бібліотеки чи пакета:

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

Відкритий стандарт і крос‑платформеність

Формат skill.md описаний як відкритий стандарт на сайті agent-skills.io і ліцензований за Apache 2.0. Його вже підтримують низка платформ для AI‑розробки, зокрема середовища на кшталт Claude Code, OpenAI Codex та інші інструменти.

Ключова перевага такого підходу:

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

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

Джерело

What AI Agent Skills Are and How They Work — IBM Technology

Paperclip — це відкритий «human control plane» для AI‑праці, який позиціонується як інфраструктура оркестрації для «zero‑human» компаній. Проєкт створив анонімний розробник Dotta, а його публічний реліз як open source відбувся 4 березня. Ідея проста, але радикальна: замість одного «чарівного» бота користувач будує повноцінну оргструктуру з десятків і сотень AI‑агентів — CEO, CTO, розробників, маркетологів, QA — і керує ними як справжньою компанією.

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

Перший крок: npx paperclip-ai onboard і що насправді відбувається

Старт у Paperclip максимально наближений до звичного для розробників досвіду: достатньо відкрити термінал і виконати команду npx paperclip-ai onboard. За бажанням можна додати прапорець --yes, щоб прийняти налаштування за замовчуванням і пришвидшити онбординг.

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

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

Чому все починається з CEO‑агента

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

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

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

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

Автономні «найми»: як CEO пропонує CTO, інженерів та інші ролі

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

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

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

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

Bring‑your‑own‑agent: Paperclip як вендор‑нейтральний «каркас» для моделей

Одна з ключових ідей Paperclip — не прив’язувати користувача до одного AI‑провайдера. Замість того, щоб будувати все навколо конкретної моделі, система дозволяє «приводити» власних агентів на базі різних LLM. У ролі співробітників можуть виступати моделі Gemini, Pi, Hermes, OpenAI‑моделі, Claude та інші, підключені через OpenRouter.

Це не просто можливість вибору, а фундаментальна властивість архітектури. Кожен агент у Paperclip — це поєднання ролі (наприклад, «Codex coder», «Claude coder», «QA‑агент», «контент‑стратег») і конкретної моделі, яка стоїть за цією роллю. У реальній організації, яку демонструє автор Paperclip, під CTO працює ціла група кодерів, але найчастіше використовуються два: Codex coder і Claude coder. Вони мають різні сильні сторони, стилі роботи й «особистості», і саме це використовується як перевага.

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

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

Спеціалізовані типи агентів: від Claude Code до Cursor

Щоб покрити різні стилі роботи й спеціалізації, Paperclip підтримує кілька типів агентів, які спираються на різні моделі. Серед них — Claude Code, Codex, Gemini, Hermes, Pi, Cursor та інші. Кожен тип орієнтований на певний клас задач і спосіб взаємодії.

Кодер на базі Claude Code може бути зручним для складних рефакторингів і роботи з великими контекстами. Codex‑агент — для генерації коду й швидких ітерацій. Gemini може краще вписуватися в сценарії, де важлива інтеграція з екосистемою Google або мультимодальні можливості. Pi — для більш м’якої, діалогової взаємодії, коли потрібні пояснення й поступове уточнення вимог. Cursor‑агенти — для сценаріїв, де важлива інтеграція з інструментами розробника та IDE‑подібний досвід.

Усе це не просто перелік підтримуваних моделей. Важливо, що Paperclip дозволяє будувати оргструктуру, де кожен агент — це не абстрактний «LLM», а конкретний «співробітник» з певним стилем роботи. Менеджер (людина або CEO‑агент) може свідомо вирішувати, кому доручити завдання: більш обережному QA‑агенту, агресивному кодеру, креативному маркетологу чи аналітичному планувальнику.

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

OpenRouter і OpenCode: доступ до десятків моделей і дешеві експерименти

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

Серед доступних через OpenRouter моделей згадується, зокрема, Qwen 3.6 Plus — безкоштовний варіант, який можна використовувати як експериментальний або допоміжний агент. Це суттєво знижує вартість входу: замість того, щоб одразу будувати команду на дорогих комерційних моделях, користувач може протестувати процеси на безкоштовних або дешевших альтернативах.

OpenCode‑агент виступає своєрідним шлюзом: він знає, як звертатися до OpenRouter, як конфігурувати моделі, як передавати їм контекст і отримувати відповіді у форматі, зручному для Paperclip. Для користувача це виглядає як ще один тип агента, але під капотом відкривається доступ до широкого спектра LLM.

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

Планування, QA та рутини: як агенти перетворюються на керовану організацію

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

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

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

По‑третє, Paperclip підтримує рутини — повторювані робочі процеси, які можна запускати за розкладом або вручну. Наприклад, створення changelog’у, формування повідомлення в Discord про всі злиті в master гілки за день, підготовка підсумку PR. Рутини можуть містити шаблонні змінні, як‑от назва гілки, які користувач заповнює під час запуску. Це дозволяє перетворити разові «промпти» на стабільні, відтворювані процеси.

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

Від одного CEO до багаторівневої AI‑компанії

Якщо підсумувати, шлях користувача в Paperclip виглядає приблизно так. Спочатку — технічний онбординг через npx paperclip-ai onboard, який готує середовище й базову конфігурацію. Далі — створення першої компанії, де з’являється CEO‑агент як верхньорівневий координатор. Користувач починає делегувати йому задачі, а CEO — розбивати їх на підзадачі, пропонувати нові ролі, ініціювати «найми» CTO, інженерів, маркетологів, QA.

Паралельно користувач підключає моделі через OpenRouter, створює спеціалізованих агентів на базі Claude Code, Codex, Gemini, Hermes, Pi, Cursor та інших. Кожен агент отримує свою роль, скіли, зону відповідальності. З часом з’являються QA‑процеси, плани, рутини, інтеграції на кшталт Greptile для перших проходів код‑рев’ю.

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

У цьому сенсі Paperclip дійсно поводиться як «human control plane for AI labor»: людина задає напрямок, ухвалює ключові рішення й затверджує «найми», а все інше — від розподілу задач до технічних деталей виконання — поступово бере на себе мережа агентів.

Джерело

Paperclip: Open Source Human Control Plane for AI Labor — Dotta Bippa

Anthropic запустила Claude Design — вебінструмент, вбудований безпосередньо в Claude AI, який обіцяє автоматизувати значну частину рутинної роботи над інтерфейсами. Android‑розробник і автор навчальних курсів Philipp Lackner протестував його на реальному сценарії: створенні застосунку для перегляду відеокурсів. На цьому прикладі добре видно, як Claude Design працює з ескізами, уточнює вимоги, пропонує варіанти UX і врешті генерує React‑код для вебу.

Від брифу до структури: як Claude Design уточнює вимоги до застосунку

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

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

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

Ескізи як мова спілкування з AI: грубий малюнок перетворюється на UI

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

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

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

Дашборд курсового застосунку: які блоки пропонує Claude Design

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

Серед типових блоків, які з’являються в макеті, можна виділити кілька ключових:

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

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

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

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

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

Варіації UX: списки, сітки та різна щільність дашборда

Ще одна сильна сторона Claude Design — робота з варіаціями. Замість одного «правильного» макета інструмент генерує кілька альтернатив, які відрізняються як структурою, так і візуальною щільністю.

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

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

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

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

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

Вихід на код: JSX‑компоненти як міст між дизайном і розробкою

Ключовий момент, який відрізняє Claude Design від багатьох інших AI‑інструментів для UI, — орієнтація на конкретний кодовий вихід. Для веб‑реалізацій система генерує React JSX‑файли, які відповідають створеним макетам.

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

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

Водночас такий підхід підкреслює, що Claude Design сьогодні помітно краще «відчуває» веб, ніж нативні мобільні платформи. Для Android чи iOS розробників JSX‑вихід не є безпосередньо придатним, його доведеться переосмислювати в термінах Jetpack Compose, SwiftUI чи інших UI‑фреймворків. Це не робить інструмент марним для мобільних команд, але змінює сценарій використання: Claude Design стає радше джерелом візуальної та структурної референції, а не генератором готового продакшн‑коду.

Експорт без Figma: ZIP із JSX, PDF і Canva як поточний максимум

Після завершення роботи над макетами Claude Design пропонує кілька варіантів експорту. Найпрактичніший для веб‑команд — вивантаження проєкту у вигляді ZIP‑архіву з JSX‑файлами. Це дозволяє одразу передати результат фронтенд‑розробникам або інтегрувати його в існуючий репозиторій.

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

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

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

Для невеликих команд або сольних розробників це може бути прийнятним компромісом, особливо якщо основний фокус — веб і React. Але для великих продуктів із налагодженим Figma‑центрованим пайплайном відсутність прямого експорту поки що обмежує роль Claude Design у загальній екосистемі інструментів.

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

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

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

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

Джерело

https://www.youtube.com/watch?v=YTGT4HqEMSo

AI‑асистенти вже давно вийшли за межі чатів у браузері, але саме інтеграція в повсякденні робочі інструменти показує їхню реальну цінність. Один із таких прикладів — Claude для Excel: штучний інтелект від Anthropic, який працює у вигляді бічної панелі всередині Microsoft Excel і вміє читати й змінювати відкриту книгу. У відеоуроці на каналі Teacher’s Tech викладач Джеймі демонструє, як цей інструмент допомагає розібратися в чужих складних файлах, очистити «брудні» дані, витягнути транзакції з PDF‑звітів і навіть одразу перетворити аналіз на презентаційний слайд у PowerPoint.

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

Розуміння чужих книг: від структури аркушів до формул INDEX+MATCH

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

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

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

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

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

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

Очищення «брудних» даних: дати, телефони, дублікати, компанії та адреси

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

Починається все з дат. У стовпці F — кілька різних форматів: від «2024-01-05» до «5/1/24» чи текстових варіантів. Користувач просить Claude стандартизувати всі дати в цьому стовпці до конкретного формату. Асистент перетворює значення на внутрішні серійні номери Excel, що означає коректне розпізнавання дат, але візуально стовпець виглядає як набір чисел. Після уточнення «застосуй такий‑то формат відображення дат» Claude змінює формат клітинок, і користувач отримує єдиний, читабельний вигляд дат.

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

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

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

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

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

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

Від PDF‑виписки до зведеної таблиці й діаграми: повний цикл аналізу

Третій сценарій демонструє, як Claude для Excel працює з даними, які взагалі не існують у вигляді таблиці. Йдеться про типовий квартальний звіт від постачальника у форматі PDF: 27 рядків транзакцій, розкиданих по двох сторінках. Для малого бізнесу це знайома ситуація: щоб зрозуміти, на що саме йдуть гроші, доводиться вручну переносити дані в Excel або покладатися на ненадійні конвертори.

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

Claude створює новий аркуш із логічною назвою й заповнює його 27 рядками, що відповідають транзакціям у PDF. Стовпець дат має тип Date, суми — числовий формат із валютним відображенням, категорії очищені. Це вже не просто «текст із PDF», а повноцінний набір даних, готовий до аналізу. За оцінкою ведучого, те, що вручну зайняло б щонайменше 20 хвилин уважного набору, тут виконується за 20–30 секунд.

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

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

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

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

Від аналізу до презентації: спільний контекст між Excel і PowerPoint

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

Claude для Excel використовує спільний контекст між Excel і PowerPoint, щоб скоротити цей розрив. Аналіз, виконаний у книзі Excel, може бути безпосередньо використаний під час генерації слайдів у PowerPoint. У демонстрації після побудови зведеної таблиці й діаграми за витратами постачальника Claude отримує завдання створити однослайдовий виконавчий підсумок (executive summary) щодо витрат на цього вендора.

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

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

Висновки: Excel як розмова з даними

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

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

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

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

Джерело

How to Use Claude AI in Excel – Complete Beginner Guide

У 2026 році запустити технологічний продукт можна, маючи лише ноутбук, доступ до AI‑інструментів і готовність працювати. У розмові на каналі Silicon Valley Girl підприємці на кшталт Деніела Прістлі, Амджада Масада (CEO Replit), засновника Opus Clip Янга Чжао, CEO ElevenLabs Маті Станішевського та сама Марина Могилко описують, як би вони стартували з нуля й вийшли на $10 000 на місяць без коду, команди й венчурного капіталу. З їхніх історій складається доволі конкретний, приземлений плейбук: вузька ніша, простий AI‑продукт, перші продажі за лічені тижні й системна робота з клієнтами.

Тиха сила простих AI‑продуктів: кейс Score App і CFO, який став засновником

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

Показовий приклад — британський підприємець Деніел Прістлі, який автоматизував чотири свої агентства за допомогою AI‑платформи. Один із цих проєктів, Score App, починався як разова клієнтська розробка за $15 000, яку команда робила вручну. Сьогодні це вже продукт із 8 500 клієнтами та зростанням близько 4% щомісяця. Без гучних раундів, без агресивного спалювання бюджету — здебільшого на власні кошти, із контрольованими витратами й фокусом на прибуток.

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

Ще один показовий приклад — історія фінансового директора венчурного фонду, яку розповідає CEO Replit Амджад Масад. CFO, який роками працював із фондами, добре розумів домен, але не мав технічної команди, щоб реалізувати власні ідеї. За допомогою Replit він за три місяці самостійно зібрав додаток, який вирішував його професійну проблему, вийшов на ринок, отримав контракти й тепер, за словами Масада, рухається до $5 млн виручки. Він звільнився й став повноцінним підприємцем.

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

Як будувати без коду: AI як «джуніор‑інженер», а не магічна чорна скринька

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

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

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

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

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

Вузько, нудно, але прибутково: як обрати нішу, яка реально платить

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

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

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

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

Третій фільтр — наявність існуючих сервісів. Чжао описує перехід від класичного SaaS («software as a service») до моделі «service as software»: там, де сьогодні працюють агентства, фрилансери або «костильні» внутрішні інструменти, завтра може з’явитися AI‑додаток, який робить те саме швидше й дешевше. Якщо у вибраній ніші вже є люди або компанії, які продають послугу вручну, це сильний сигнал: попит існує, залишилося його автоматизувати.

Марина наводить показовий побутовий приклад такого «нудного» AI‑бізнесу. Під час поїздки з дітьми в готель її донька попросила розмальовки з оленями й єдинорогами. Замість того, щоб шукати й друкувати випадкові картинки, вона натрапила на сайт, який пропонував згенерувати 30 розмальовок під вік дитини й бажану тематику за 50 центів. Вона заплатила й миттєво отримала готовий PDF для друку.

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

Голосові агенти й локальний B2B: як заробляти на AI, просто «приносячи» його в офлайн

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

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

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

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

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

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

Контент, email і перший долар: як виглядає 90‑денний плейбук

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

Гері Вайнерчук, відповідаючи на гіпотетичне питання «що робити, якщо завтра все згорить», формулює свою стратегію максимально просто: зробити додаток із підпискою $5–50 на місяць і залити соцмережі контентом. Він говорить про «необмежений органічний контент» у LinkedIn, X (Twitter) і TikTok як про головний двигун зростання. Соціальні платформи, на його думку, — це глобальна рекламна система, яка не вимагає стартового бюджету: один вдалий ролик може привести тисячі людей на ваш продукт.

Цей підхід добре поєднується з тим, що описує Марина як «плейбук на 90 днів». У спрощеному вигляді він виглядає так: обрати вузьку нішу, за 24 години зібрати MVP за допомогою AI‑інструментів, за перші 30 днів отримати перший платіж, а далі нарощувати до $10 000 на місяць через органічний контент і послідовне покращення продукту.

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

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

За заявленими даними, клієнти Omnisend у середньому отримують близько $79 доходу на кожен витрачений долар. Компанія також пропонує безкоштовну міграцію з інших сервісів за 3–5 днів: переносяться контакти, автоматизації, SMS‑номери, при цьому старий інструмент продовжує працювати, щоб уникнути втрати лідів. Підтримка — 24/7 із середнім часом відповіді менше п’яти хвилин. Для нових користувачів діє промокод MARINA на 30% знижки протягом перших трьох місяців.

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

Чому не потрібні інвестори, щоб дійти до мільйона ARR

Окремий пласт розмови стосується ролі венчурного капіталу. Засновник Higgsfield Алекс Машрабов має унікальну перспективу: його компанія вийшла на річний темп виручки близько $200 млн за дев’ять місяців, причому гроші були залучені ще до появи перших доходів. Однак, розмірковуючи про те, як би він стартував сьогодні з нуля, Машрабов формулює зовсім інший підхід.

Його порада: зосередитися на тому, щоб отримати перший долар до 30‑го дня розробки продукту, а до 90‑го дня вийти на річний темп близько $1 млн (приблизно $80 000 на місяць). Лише після цього має сенс думати, чи потрібен взагалі венчурний капітал. На його думку, багато AI‑бізнесів сьогодні можуть вирости до десятків мільйонів доларів виручки, залишаючись прибутковими й не залучаючи інвестицій.

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

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

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

Висновок: AI‑бізнес як ремесло, а не лотерея

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

Деніел Прістлі показує, як сервісний проєкт за $15 000 може перетворитися на продукт із тисячами клієнтів і стабільним зростанням. CFO, який став засновником завдяки Replit, демонструє, що навіть нетехнічний фахівець може самостійно створити додаток і вийти на мільйонні обороти. Янг Чжао й Маті Станішевський окреслюють карту можливостей у «нудних» нішах і локальному B2B, де AI ще майже не присутній. Марина формулює практичний плейбук: вузька ніша, MVP за 24 години, перший долар до 30‑го дня, органічний контент і власні канали комунікації.

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

Джерело

Start a $10K/Month AI Business in 90 Days — No Code, No Team

У розмові на подкасті 20VC засновник і CEO Replit Амджад Масад розкриває те, що зазвичай залишається за лаштунками гучних анонсів про “агентів”, “фронтирні моделі” та “AI‑революцію”: економіку стеку штучного інтелекту. Як розподіляються гроші між стартапами, хмарними гігантами й виробниками чипів? Чому Replit свідомо відмовився від майже досягнутої прибутковості заради запуску Agent 4? І навіщо, на його думку, державі потрібна власна відкрита фронтирна модель?

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

Скільки насправді “з’їдають” моделі: Replit проти Nvidia‑економіки

Один із ключових страхів навколо продуктів на базі LLM — що це бізнеси з “паперовою” виручкою, де майже всі гроші йдуть постачальникам моделей і GPU. Масад визнає: витрати на моделі для Replit — справді суттєві. Але до катастрофічних 80% від доходу, про які часто говорять на ринку, компанії далеко.

За його словами, частка виручки, що йде модель‑провайдерам, у Replit “значна, але точно не 80%”. Це важливий сигнал для всієї індустрії: навіть у компанії, яка масово ганяє токени через Anthropic і Google, залишається простір для здорової маржі — особливо в міру масштабування.

Для порівняння Масад наводить приклад Anthropic. Їхні валові маржі, за його словами, близько 40%. Це означає, що приблизно 60% кожних 100 доларів виручки йде на обчислення, передусім Nvidia. І це ще з урахуванням того, що самі модельні компанії сьогодні часто субсидують ціни, щоб захопити ринок.

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

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

Чому Replit пожертвував прибутковістю заради Agent 4

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

Agent 4 описується як масово паралельний агент, здатний координувати близько 20 під‑агентів одночасно, щоб будувати продукт у рази швидше. Така архітектура означає не лише складну інфраструктуру, а й вибухове зростання обчислювального навантаження: кожен під‑агент — це додаткові токени, додаткові запити до моделей, додаткові рахунки від Anthropic, Google та інших.

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

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

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

Цикл “спочатку швидкість, потім маржа”: як Replit керує економікою продукту

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

У першій фазі компанія поводиться як класичний “growth‑mode” стартап: головне — зробити продукт відчутно кращим за конкурентів. Це означає:

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

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

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

Це добре видно на прикладі Intercom, який Масад наводить як ілюстрацію. Компанія заявляє, що її власна, спеціально натренована модель на певний час (3–6 місяців) перевершує фронтирні моделі в задачах підтримки клієнтів. У такій ситуації інвестиція в власну модель виправдана: домен відносно стабільний, а перевага в якості й вартості може напряму конвертуватися в виграш на ринку.

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

“Суспільство моделей”: як Replit грає на ціновому фронті між Anthropic і Google

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

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

Водночас Google Gemini, за словами Масада, сьогодні часто виграє на фронті price‑performance. Для задач, де потрібна “достатньо хороша” якість за нижчу ціну, Replit створює дешевші під‑агенти й віддає їх на Gemini. Це можуть бути, наприклад, пошукові завдання або допоміжні кроки, які не критичні для кінцевого результату, але створюють значну частину токен‑навантаження.

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

Такий підхід перетворює Replit на своєрідний “агент‑лаб”: компанію, чия ключова компетенція — не власна фронтирна модель, а вміння:

– швидко оцінювати нові моделі;
– будувати промпти й інфраструктуру навколо них;
– створювати внутрішні бенчмарки;
– проводити масштабні A/B‑тести, щоб зрозуміти, де яка модель дає найкращий результат.

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

Відкритий код як протиотрута від AI‑олігархії

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

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

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

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

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

Державна відкрита модель і обережність щодо Китаю

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

Така модель могла б стати:

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

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

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

Висновок: економіка AI‑стеку ще не усталилася — і саме в цьому шанс

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

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

Поки AI‑ринок залишається “флешем капіталу”, як каже Масад, логіка проста: спочатку — максимальна продуктивність, потім — оптимізація. Але вже зараз зрозуміло, що наступний етап буде визначатися не лише тим, хто збудує найрозумнішого агента, а й тим, хто зможе зробити це без того, щоб 60–80% кожного долара назавжди осідали в обчислювальному шарі.

Джерело

Replit CEO: Why the SaaS Apocalypse is Justified & Why Coding Models are Plateauing | Amjad Masad

УТ‑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 #вайбкодинг