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

Від ідеї до робочого застосунку: поріг входу знижується

Один із показових прикладів — створення десктопного застосунку для запису подкастів. За допомогою Codex у зв’язці з GPT‑5.5 було реалізовано програму, яка:

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

Ключовий ефект тут не лише в самому застосунку, а в тому, що:

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

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

Від MVP до продакшену: роль GPT‑5.5 у масштабуванні

Ще один важливий сценарій — еволюція внутрішніх платформ. Попередню мінімально життєздатну версію (MVP) внутрішнього сервісу було створено з допомогою GPT‑5.4. Наступний етап — доведення цього рішення до продакшен-рівня — уже відбувався з використанням Codex і GPT‑5.5.

У цьому контексті GPT‑5.5 допомагає:

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

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

Довіра до моделі: коли ШІ знаходить те, про що його не питали

Окремий аспект GPT‑5.5 — зміна рівня довіри до моделі з боку інженерів. Важливий момент: система не обмежується буквальним виконанням запиту, а:

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

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

Новий рівень мотивації для розробників

Ще один непрямий, але показовий ефект — зміна ставлення до самої роботи над ПЗ. Коли інструмент:

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

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

Джерело

Відео OpenAI «Introducing GPT-5.5 with NVIDIA»: https://www.youtube.com/watch?v=VdXdGS7hUSY

Великі мовні моделі (LLM) стрімко змінюють те, як пишуть код: дедалі більше розробників делегують генерацію фрагментів програм ШІ-асистентам. У розмові на каналі The Pragmatic Engineer автор книжки Designing Data-Intensive Applications Мартін Клеппманн пояснює, чому така зміна підходу робить формальні методи й автоматичну перевірку коректності коду не просто бажаними, а необхідними.

«Vibe coding»: коли код пише ШІ

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

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

Людський код-рев’ю більше не масштабується

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

• код-рев’ю колегами;
• тестування (юнiт-, інтеграційні, end-to-end тести);
• статичний аналіз.

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

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

Безпека як головний аргумент

Проблема особливо гостра в контексті безпеки. Достатньо однієї дрібної помилки, щоб:

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

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

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

Формальні методи: від нішевого інструмента до масового

Формальна верифікація — це підхід, коли властивості програми (наприклад, відсутність певного класу помилок) доводяться математично. Історично такі методи вважалися:

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

Клеппманн висловлює надію, що LLM змінять цю ситуацію. Якщо моделі навчаться:

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

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

У підсумку поєднання LLM та формальних методів може виглядати так:

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

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

Джерело

Martin Kleppmann: Vibe coding → more demand for formal methods — The Pragmatic Engineer

У центрі нинішньої хвилі AI‑інструментів для розробників стоїть парадокс: моделі здатні писати тисячі рядків коду за хвилини, але саме це й загрожує перетворити проєкти на некерований хаос. Британський інженер і викладач Метт Поко́к, автор курсу «Claude Code for Real Engineers», пропонує протилежний підхід: не скасовувати класичні інженерні практики, а зробити їх ядром AI‑першого процесу розробки.

У своїй доповіді на каналі AI Engineer він показує, як поєднати промпт‑патерни, доменно‑орієнтований дизайн, типи, браузер, тести та архітектуру глибоких модулів так, щоб LLM працювала не як генератор «спагеті‑коду», а як дисциплінований співрозробник. Ключові елементи цієї системи — власний «grill me»‑промпт, «убіквітарна мова» у форматі markdown, тест‑драйв і архітектура, яка не дає моделі потонути у власних модулях.

Від «специ до коду» до спільної «design concept»

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

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

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

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

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

Щоб цього уникнути, він пропонує починати не з «генерації активів», а з досягнення спільної «design concept» — терміна Фредеріка П. Брукса з «The Design of Design». Design concept — це невидима, спільна для всіх учасників ідея того, що саме будується. Її не можна просто записати в один файл; це радше узгоджена ментальна модель системи.

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

«Grill me»: промпт, який перетворює AI на вимогливого співрозмовника

Для цього Поко́к створив окремий «skill» — промпт «grill me». Його суть вкрай проста, але наслідки виявилися масштабними. Промпт наказує моделі:

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

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

Результат виявився настільки затребуваним, що GitHub‑репозиторій із цим skill’ом набрав близько 13 тисяч зірок. Розробникам сподобалася не магія, а дисципліна: кілька рядків інструкцій перетворюють LLM на інструмент глибокого прояснення вимог.

У практиці це виглядає так: модель може поставити 40, 60, а іноді й понад 100 запитань, перш ніж «задовольнитися» тим, що спільна design concept досягнута. На виході розробник отримує не код, а насичену розмову, яку можна перетворити на документ вимог, набір задач або безпосередньо передати агентам для реалізації.

Поко́к прямо порівнює цей підхід із вбудованим «plan mode» у Claude Code, яким сам користується. На його думку, стандартний режим надто прагне «створити актив» — швидко видати план і перейти до коду. «Grill me» навпаки затримує цей момент, змушуючи спочатку вибудувати спільну design concept. Саме тому він віддає перевагу власному skill’у: якість плану та відповідність намірам розробника виявляються вищими.

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

Убіквітарна мова для людини й моделі: markdown як контракт

Навіть коли спільна design concept досягнута, наступна типова проблема — надмірна багатослівність і «розмови навхрест». Модель пояснює очевидне, плутає терміни, дублює одні й ті самі ідеї різними словами. Це не лише дратує, а й ускладнює планування та рев’ю.

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

Доменно‑орієнтований дизайн (Domain‑Driven Design, DDD) пропонує протиотруту — концепцію ubiquitous language, «убіквітарної мови». Це узгоджений набір термінів, який однаково використовується в розмовах між розробниками, у спілкуванні з бізнесом і в самому коді. У DDD це не просто словник, а відображення доменної моделі.

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

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

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

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

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

У підсумку ubiquitous language у форматі markdown стає ще одним видом контракту між людиною й моделлю, подібно до того, як інтерфейси й типи виступають контрактами всередині коду.

Типи, браузер і тести: як побудувати корисні фідбек‑цикли для LLM

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

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

Щоб повернути контроль, Поко́к наполягає на трьох типах зворотного зв’язку, до яких варто обов’язково підключати модель.

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

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

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

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

Щоб змусити модель рухатися дрібнішими кроками, Поко́к пропонує повернутися до ще однієї старої практики — тест‑драйв розробки.

TDD як «обмежувач швидкості» для AI‑розробника

Тест‑драйв розробки (Test‑Driven Development, TDD) традиційно вважається складною дисципліною. Потрібно вирішити, який саме блок тестувати, які сценарії покрити, що замокати, як уникнути крихкості тестів. Усе це — пов’язані між собою рішення, і саме тому багато команд або відмовляються від TDD, або застосовують його фрагментарно.

Парадоксально, але саме ця «важкість» робить TDD корисним у поєднанні з LLM. Поко́к пропонує використовувати його як спосіб примусово зменшити розмір кроків, які робить модель.

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

Це дає кілька переваг.

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

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

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

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

Глибокі модулі проти «AI‑архітектури з тисячі дрібних файлів»

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

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

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

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

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

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

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

Висновок: AI‑перший процес як повернення до класики

Підхід, який описує Метт Поко́к, виглядає парадоксально консервативним на тлі хайпу навколо «агентних» систем, що нібито здатні самостійно проєктувати й будувати складні застосунки. Замість того щоб мріяти про повну автоматизацію, він пропонує повернутися до старих книжок — Остергаута, Брукса, «The Pragmatic Programmer», Domain‑Driven Design — і використати їх як основу для AI‑першого процесу.

«Grill me»‑промпт допомагає досягти спільної design concept до того, як буде написано код. Убіквітарна мова в markdown зменшує семантичний шум і вирівнює план із реалізацією. Статичні типи, доступ до браузера й автоматизовані тести створюють щільні фідбек‑цикли, які не дозволяють «обігнати власні фари». TDD змушує модель рухатися дрібними, контрольованими кроками. А архітектура глибоких модулів забезпечує середовище, у якому LLM може ефективно орієнтуватися й еволюціонувати систему без вибуху складності.

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

Джерело

It Ain’t Broke: Why Software Fundamentals Matter More Than Ever — Matt Pocock, AI Hero @mattpocockuk

Hermes Agent — це самонавчальний AI‑агент від Nous Research з вбудованим «learning loop», який може запускатися на вашому власному сервері й працювати як персональний цифровий асистент. У великому туторіалі на каналі Tech With Tim демонструється повний шлях від вибору мовної моделі до підключення агента до Telegram. Нижче — розбір ключових технічних рішень і нюансів, які важливо врахувати, якщо ви хочете отримати стабільного й безпечного бота на базі Hermes.

Вибір модельного провайдера: чому ставка робиться на OpenAI Codeex і Minimax

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

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

Рекомендація Tech With Tim проста й прагматична: OpenAI Codeex і Minimax — одні з найбільш вигідних варіантів за співвідношенням ціна/якість. Hermes Agent може працювати з різними LLM‑провайдерами, але для більшості користувачів важливі дві речі: вартість токенів і стабільність. Обидва згадані сервіси дають достатню продуктивність для повсякденних задач агента, не роздуваючи рахунок за інференс.

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

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

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

GPT 5.4 як «двигун мислення» Hermes Agent

Після авторизації в OpenAI Codeex наступний крок — вибір конкретної моделі. У туторіалі в ролі основної обирається GPT 5.4. У контексті Hermes це не просто технічний параметр, а визначення того, як агент буде поводитися, міркувати й навчатися.

GPT 5.4 виступає головним reasoning‑двигуном Hermes Agent. Саме ця модель:

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

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

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

Чому Telegram стає головним інтерфейсом для Hermes Agent

Hermes Agent підтримує кілька платформ для обміну повідомленнями, зокрема Telegram, Slack і Discord. Однак у практичному сценарії налаштування основний акцент робиться саме на Telegram, і це не випадковість.

По‑перше, Telegram значно простіше в інтеграції для пересічного користувача. Створення бота тут не вимагає складної реєстрації застосунку, OAuth‑процедур чи налаштування callback‑URL, як це часто буває зі Slack або Discord. Усе відбувається всередині самого Telegram через спеціального системного бота BotFather.

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

У конфігурації Hermes це відображається як вибір Telegram у блоці «Messaging setup». Інтерфейс попереджає, що Slack і Discord потребують більше кроків для створення бота, тоді як Telegram рекомендований як стартова платформа, особливо для тих, хто вперше налаштовує подібну систему.

Фактично Telegram стає основним «обличчям» Hermes Agent для користувача. Усі складні процеси — виклики до GPT 5.4, виконання навичок, робота з пам’яттю — залишаються на сервері, а користувач бачить лише звичний чат‑інтерфейс, де агент відповідає, ставить уточнювальні запитання й надсилає результати виконаних дій.

Як правильно створити Telegram‑бота для Hermes: BotFather, токен і унікальний username

Щоб Hermes Agent міг працювати через Telegram, йому потрібен токен бота — це ключ, який дозволяє системі надсилати й отримувати повідомлення від імені конкретного Telegram‑акаунта‑бота. Отримується він через офіційного бота BotFather.

Процес виглядає так: у Telegram відкривається пошук, знаходиться BotFather з синьою галочкою, і в діалозі з ним надсилається команда /newbot. Далі BotFather послідовно запитує два параметри.

Перший — це ім’я бота (display name). Це те, що користувачі бачитимуть у заголовку чату. Воно не повинно бути унікальним, тож тут можна обрати будь‑яку зручну назву — наприклад, «Hermes Tutorial».

Другий — це username. І тут починаються обмеження, які важливо врахувати:

Telegram вимагає, щоб username бота був глобально унікальним і закінчувався на _bot. Це означає, що ви не можете використати ім’я, яке вже зайняте будь‑ким у світі, і обов’язково маєте додати суфікс _bot. У демонстрації використовується щось на кшталт Hermes_tutorialbot234_bot — з додатковими цифрами, щоб уникнути конфлікту з уже існуючими іменами.

Якщо username прийнятий, BotFather створює бота й повертає HTTP API token. Саме цей токен потрібно скопіювати й вставити в конфігурацію Hermes Agent у полі «Telegram bot token». У терміналі при вставці токена вхідні символи не відображаються, але це нормальна поведінка: після натискання Enter Hermes зберігає значення й переходить до наступного кроку.

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

Обмеження доступу: allowed user IDs як базовий рівень безпеки

Після введення токена Hermes Agent запитує список дозволених Telegram user ID. Це ще один важливий запобіжник, без якого бот фактично стає публічним.

Якщо не вказати жодного ID, будь‑який користувач, який знайде вашого бота в Telegram, зможе почати з ним спілкування. Для звичайного чат‑бота це може бути прийнятно, але для Hermes Agent, який має доступ до сервера, файлової системи й може виконувати автономні дії, такий сценарій небезпечний.

Тому система вимагає щонайменше один allowed user ID. Це список Telegram‑ідентифікаторів користувачів, яким дозволено взаємодіяти з ботом. Усі інші повідомлення Hermes просто ігноруватиме.

Щоб дізнатися власний Telegram user ID, використовується ще один службовий бот — userinfobot. У пошуку Telegram вводиться його назва, відкривається чат, і надсилається команда /start. У відповідь бот повертає інформацію про акаунт, зокрема числовий ID. Саме це число потрібно скопіювати й передати Hermes у полі allowed user IDs.

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

Локальна взаємодія: TUI Hermes як консольний фронтенд

Окрім інтеграції з месенджерами, Hermes Agent надає локальний термінальний інтерфейс користувача (TUI). Він запускається простою командою hermes у терміналі й відкриває консольний інтерфейс для спілкування з агентом безпосередньо на машині, де він встановлений.

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

Усередині TUI Hermes підтримує низку slash‑команд. Серед них — /new, яка створює нову сесію або контекст розмови. Це важливо, коли потрібно «обнулити» попередній діалог і почати спілкування з чистого аркуша, не тягнучи за собою старий контекст. Для агента з довгостроковою пам’яттю це зручний інструмент керування тим, що саме має враховуватися в поточній взаємодії.

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

Gateway як «серце» інтеграції з Telegram: чому його не можна зупиняти

Навіть після того, як модель налаштована, Telegram‑бот створений, токен переданий, а allowed user IDs задані, Hermes Agent ще не готовий до повноцінної роботи через месенджер. Для цього потрібен окремий компонент — messaging gateway.

Gateway запускається командою hermes gateway. Це окремий процес, який виступає посередником між Telegram API й ядром Hermes. Саме він:

• приймає вхідні повідомлення від Telegram‑бота;
• передає їх у Hermes для обробки мовною моделлю й навичками;
• повертає відповіді назад у Telegram.

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

Ключовий практичний момент: gateway має працювати постійно. Якщо процес зупинити (наприклад, натиснувши Ctrl+C у терміналі, де він запущений), інтеграція з Telegram миттєво перестає працювати. Бот продовжує існувати, але перестає відповідати на повідомлення, доки hermes gateway знову не буде запущений.

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

Висновки: модель, бот і gateway як три кити робочого Hermes Agent

Налаштування Hermes Agent — це не лише питання розгортання на VPS чи локальній машині. Щоб отримати по‑справжньому корисного й безпечного агента, потрібно правильно зібрати кілька ключових компонентів.

По‑перше, вибір модельного провайдера й конкретної моделі визначає інтелектуальні можливості системи та її вартість у довгостроковій перспективі. Орієнтація на OpenAI Codeex і Minimax як на економічно доцільні варіанти, а також використання GPT 5.4 як основного reasoning‑двигуна, формує баланс між якістю й бюджетом.

По‑друге, Telegram виступає оптимальним фронтендом для більшості користувачів: просте створення бота через BotFather, зрозумілі обмеження на username з суфіксом _bot, зручний доступ із будь‑якого пристрою. Але разом із цим приходить і відповідальність за безпеку: токен бота має залишатися секретом, а список allowed user IDs — обов’язковою умовою, щоб агент не став публічним інструментом у руках сторонніх.

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

У сукупності ці елементи перетворюють Hermes Agent із абстрактної «платформи AI‑агента» на конкретний робочий інструмент: персонального асистента в Telegram, який мислить на базі GPT 5.4, працює на вашому обладнанні й підкоряється лише тим, кому ви явно дозволили до нього доступ.

Джерело

Hermes Agent Full Tutorial for Beginners | Setup Guide — Tech With Tim

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

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

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

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

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

Особистий досвід як головний експертний ресурс

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

Алгоритм простий:

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

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

Від «інфлюенсера» до лідера: роль особистого бренду

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

Кілька важливих акцентів:

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

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

Мережа починається з найближчих людей

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

Тому важливо:

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

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

Онлайн і офлайн: єдина траєкторія лідерства

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

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

Джерело

Leadership starts with showing up — online and offline #TEDTalks

У розмові на подкасті 20VC with Harry Stebbings пролунала проста, але показова теза: сучасні AI‑інструменти вже дозволяють командам будувати інтерфейси й прототипи без традиційного залучення дизайнерів. Це не про ще один «вбивцю Figma», а про зміну самої моделі роботи з дизайном.

Коли Figma-файл уже не потрібен

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

Учасники дискусії ставлять під сумнів саму цінність цього етапу для невеликих команд:

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

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

AI як міст між ідеєю та робочим продуктом

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

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

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

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

Як AI «кусатиме» Figma та Adobe без прямої конкуренції

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

Важливіше інше:

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

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

Що це означає для дизайнерів і команд

З описаної тенденції випливають кілька практичних висновків:

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

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

Джерело

YouTube: Why wait 30 days for a designer anymore?

У квітні 2026 року розробник і серійний «тінкерер» Кітзе (@thekitze на X), якому саме виповнилося 34, виступив на конференції AI Engineer з історією своїх експериментів із продуктивністю, особистими агентами та штучним інтелектом. Центральним прикладом став його багаторічний сайд‑проєкт Benji — гігантський «life OS» із десятками функцій, який так і не вийшов на ринок, попри вірусний успіх окремих AI‑демо. На його фоні особливо контрастує успіх інших засновників, які взяли одну вузьку ідею — наприклад, AI‑трекінг їжі з фото — і перетворили її на багатомільйонний бізнес.

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

60 функцій в одному застосунку: коли «life OS» стає надто щільним

Benji народився у 2022 році як кульмінація більш ніж двадцятирічної одержимості Кітзе системами продуктивності. Після текстових файлів, автоматизацій через Tasker, експериментів із Google Home та IFTTT, а також попередніх застосунків на кшталт Toodo і Better, він вирішив зробити «один застосунок, щоб керувати всім».

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

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

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

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

Голосовий асистент Benji: вірусне демо, якого так і не стало продуктом

Найяскравішим епізодом у розвитку Benji став експеримент із голосовим асистентом на базі LLM. У 2023 році, ще до того, як великі моделі стабільно повертали валідний JSON, Кітзе додав у Benji можливість, яка на той момент виглядала майже магічно.

Користувач натискав гарячу клавішу, застосунок починав запис із мікрофона, а потік голосу в реальному часі відправлявся до мовної моделі. Далі Benji періодично «нарізав» фрагменти сказаного, інтерпретував їх через LLM, а потім викликав внутрішні API застосунку. На очах у користувача в реальному часі змінювалися календар, список завдань та інші сутності: події додавалися, задачі створювалися або оновлювалися, усе — без ручного введення у форми.

Технічно це було нетривіально. Моделі тоді ще не вміли надійно повертати структуровані дані. Щоб отримати JSON, придатний для виклику API, доводилося буквально «булити» модель у промптах: забороняти Markdown, просити суворо дотримуватися формату, а потім усе одно пост‑обробляти відповідь — парсити, обрізати зайве, виправляти помилки, поки не вийде валідний JSON. Це був ручний шар інженерії поверх сирих можливостей LLM, без якого голосовий асистент просто не працював би.

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

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

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

Вузькі AI‑застосунки проти «швейцарського ножа»: хто знаходить product‑market fit

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

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

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

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

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

Як технічні обмеження LLM формували Benji — і чому це важливо для продуктів

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

У 2023 році, коли Кітзе будував голосовий асистент, моделі ще не вміли надійно повертати JSON. Будь‑який виклик LLM, який мав закінчитися структурованими даними, перетворювався на міні‑битву: потрібно було жорстко формулювати інструкції, забороняти форматування, а потім писати власні парсери, що відрізають зайві символи, лапки, коментарі й виправляють синтаксичні помилки.

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

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

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

Чому Benji так і залишився сайд‑проєктом — і що це говорить про стратегію

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

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

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

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

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

Висновок: уроки Benji для епохи AI‑продуктів

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

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

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

По‑третє, технічні обмеження моделей — такі як відсутність надійного JSON‑виводу в 2023 році — не лише ускладнюють інженерію, а й впливають на продуктову стратегію. Чим більше сил іде на обхід тимчасових недоліків технології, тим менше залишається на пошук product‑market fit.

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

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

Джерело

The End of Apps — Kitze, Sizzy.co (YouTube)

Подкаст 20VC з Гаррі Стеббінгсом розібрав потенційну синергію між компанією, схожою на Cursor, та бізнесом на кшталт SpaceX/х Musk‑екосистеми, показуючи, чому така угода може бути економічно й стратегічно виправданою для обох сторін.

Дві протилежні проблеми: надлишок і дефіцит

Один бік потенційної угоди — компанія з вибуховим зростанням виручки: «пара мільярдів доларів ARR», але з «поганою валовою маржею». Причина — залежність від власної AI‑моделі та потреба у величезних обчислювальних ресурсах (compute).

Це класична ситуація для генеративного AI‑сектору:
– продукт добре продається;
– витрати на інфраструктуру (GPU, дата-центри, енергія) «з’їдають» маржу;
– без контролю над моделлю та обчисленнями бізнес стає вразливим і фінансово важким.

На протилежному боці — гравець із протилежною структурою:
– «ціла купа compute»;
– «досить хороша модель»;
– «буквально нуль доходу».

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

«Шлюб, укладений на небесах»: як складається пазл

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

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

• дає більше контролю над якістю й швидкістю роботи сервісу.

• Інфраструктурний гравець із надлишком compute нарешті знаходить реальний бізнес-кейс:

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

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

Що це показує про ринок AI‑інфраструктури

Цей кейс ілюструє кілька ширших тенденцій на ринку штучного інтелекту:

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

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

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

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

Джерело

Why the SpaceX-Cursor deal makes sense — 20VC with Harry Stebbings

Anthropic, компанія за Claude, Claude Code та Cowork, не лише створює одні з найпомітніших AI‑продуктів, а й експериментує з тим, як має виглядати продуктова організація в епоху моделей, що оновлюються кожні кілька місяців. Кат Ву, Head of Product для Claude Code та Cowork, опинилася в центрі цієї трансформації: її команда працює на межі між дослідженнями, платформою для розробників, ентерпрайз‑клієнтами й швидкісним зростанням продукту.

Щоб зрозуміти, чому Anthropic встигає адаптуватися до нових можливостей моделей і потреб ринку швидше за більшість конкурентів, варто подивитися не лише на їхні моделі, а й на те, як саме влаштована продуктова функція: від дослідницьких PM до growth‑команди, від API‑платформи до глибоко технічних продактів і дизайнерів, які самі пишуть код.

Мозаїка замість моноліту: як влаштована продуктова команда Anthropic

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

Ключові блоки цієї організації виглядають так. Є команда дослідницьких PM, яка працює безпосередньо з моделями; є команда платформи для розробників Claude, що відповідає за API та такі можливості, як керовані агенти; є продуктова команда Claude Code та Cowork, яка створює прикладні інструменти поверх моделей; є окрема ентерпрайз‑команда, що фокусується на безпеці, контролі витрат і керуванні доступами; нарешті, є growth‑команда, яка працює горизонтально по всіх цих напрямках.

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

У центрі цієї системи — Claude Code та Cowork, за які відповідає Кат Ву. Поруч із нею — техлід і продукт‑візіонер Борис Черні, який задає тримісячний‑піврічний горизонт розвитку. Візія, яку формує технічний лідер, і шлях до неї, за який відповідає продакт, накладаються на складну, але чітко структуровану PM‑організацію, що дозволяє одночасно розвивати моделі, платформу, прикладні продукти й бізнес‑метрики.

Дослідницькі PM: «сполучна тканина» між моделлю та продуктом

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

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

У традиційній схемі R&D часто живе окремим життям від продукту: дослідники публікують результати, а продакти й інженери згодом намагаються знайти їм застосування. В Anthropic дослідницькі PM виконують роль сполучної тканини, яка не дозволяє цим двом світам розійтися. Вони допомагають вирішити ключове питання епохи AI: не «що вміє модель в абстракції», а «як саме ці можливості мають проявитися в конкретних функціях Claude, Claude Code, Cowork чи API».

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

Платформа для розробників: Claude як фундамент, а не лише застосунок

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

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

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

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

Ентерпрайз як окремий продукт: безпека, контроль витрат і RBAC

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

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

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

Growth по всій ширині: коли команда зростання не має «свого» продукту

Ще одна нетипова деталь — те, як Anthropic організовує зростання. Замість того, щоб прив’язати growth‑команду до одного продукту, компанія розміщує її горизонтально поверх Claude Code, Cowork і Claude API.

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

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

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

Claude Code як AI‑нативна команда: продакти й дизайнери, які пишуть код

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

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

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

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

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

Як процеси підлаштовуються під таку структуру

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

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

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

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

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

Висновок: продуктова організація як конкурентна перевага в AI‑гонці

Anthropic часто сприймають насамперед як компанію моделей — Claude, Claude Code, Cowork. Але за швидкістю їхніх релізів і здатністю адаптуватися до нових можливостей AI стоїть не лише інженерна майстерність, а й уважно спроєктована продуктова організація.

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

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

Джерело

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

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

Від «сирих дошок» до стандартного дизайну

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

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

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

Патерн 1: єдине очищення та валідація як джерело правди

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

Приклад: у записах продажів частина цін — null.

• фінанси замінюють null на 0 доларів;
• маркетинг просто відкидає такі записи.

У підсумку:

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

Щоб уникнути цього, правила очищення й валідації мають бути:

1. Уніфікованими — визначеними один раз разом із доменними експертами (наприклад, null → 0, але з прапорцем для подальшої перевірки).
2. Реалізованими в одному пайплайні — який формує «єдине джерело правди» для всіх споживачів.

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

Патерн 2: уніфікація форматів замість зоопарку структур

Навіть після очищення дані часто залишаються несумісними через різні формати:

• різні назви полів (customer_id vs user_id);
• різна структура адрес (один рядок проти окремих полів «місто», «штат», «поштовий індекс»);
• різні формати даних (JSON проти Protocol Buffers);
• різні формати дат (YYYY-MM-DD, MM/DD/YYYY, Unix timestamp).

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

Рішення — побудувати уніфіковану модель даних, до якої транслюються всі вхідні формати. Це включає:

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

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

Патерн 3: збагачення подій ближче до джерела

Більшість бізнес-запитань не обмежуються «голими» ідентифікаторами. Продаж із полями customer_id, product_id, price мало що скаже про:

• регіональні тренди;
• поведінку сегментів клієнтів;
• динаміку категорій товарів.

Традиційний підхід — кожна команда самостійно «збагачує» події, приєднуючи:

• дані про клієнтів;
• каталоги продуктів;
• географічну інформацію;
• зовнішні довідники.

Це знову призводить до дублювання запитів і логіки приєднання.

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

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

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

Патерн 4: попередня агрегація як спільний сервіс

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

Типовий сценарій:

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

Проблеми очевидні:

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

Вихід — агрегувати дані в самому пайплайні й публікувати вже готові агреговані події:

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

Такі агрегати:

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

Від batch до real-time: роль Apache Flink

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

Сучасні стримінгові платформи, зокрема Apache Flink, дозволяють застосовувати ті самі патерни в реальному часі:

• очищення й валідація подій «на льоту»;
• трансформація в уніфікований формат;
• збагачення за рахунок приєднання кількох потоків і зовнішніх джерел;
• агрегація з використанням вікон (hourly/daily/monthly) у стримінговому режимі.

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

Що таке data-продукт і чому це «IKEA для даних»

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

Такий продукт має чотири ключові властивості:

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

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

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

4. Готовність до негайного використання
   Попередньо збагачені й агреговані дані покривають до 90% типових потреб; залишкові 10% — це вже специфічна надбудова для конкретної задачі.

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

Джерело

Why are data engineers building custom furniture (and how to stop)? — YouTube

НА ПРАВАХ РЕКЛАМИ
Ринок мобільних аксесуарів сьогодні надзвичайно насичений, але лише частина брендів стабільно поєднує якість, інновації та доступну ціну. Саме такі виробники формують довіру клієнтів і забезпечують стабільні продажі як в онлайн, так і в офлайн-магазинах.

Популярні бренди якісних мобільних аксесуарів

Ринок мобільних аксесуарів пропонує велику кількість брендів, але лише частина з них стабільно поєднує якість, функціональність і привабливу ціну. Саме такі виробники формують довіру клієнтів і забезпечують стабільні продажі. Знайти товари цих виробників можна на сайті https://easytrade.ua/ .

Серед популярних брендів варто виділити:

• McDodo – технологічний бренд, який спеціалізується на зарядних рішеннях і пропонує інноваційні кабелі та адаптери з функціями безпечної та швидкої зарядки;
• Remax – один із наймасовіших брендів із широким асортиментом аксесуарів, який поєднує доступність, стильний дизайн і великий вибір товарів;
• Momax – преміальний бренд із високою якістю матеріалів і сучасними технологіями, орієнтований на користувачів, які цінують надійність і довговічність;
• ACEFAST – новий, але перспективний бренд із сучасними рішеннями, такими як швидкі зарядки та аксесуари нового покоління;
• Nillkin – відомий виробник захисних аксесуарів, який пропонує надійні чохли та захисне скло з високим рівнем захисту;
• Monblan — бренд захисного скла та чохлів для Apple-техніки, орієнтований на преміальний сегмент, що ідеально підходить для перепродажу;
• Alabay — бренд захисного скла та чохлів для Apple-техніки в більш бюджетному сегменті для щоденного використання.

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

Чому краще працювати з перевіреними брендами

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

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

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

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

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

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

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

Нові великі мовні моделі часто обіцяють «магію», але в роботі розробників усе вирішують практичні речі: швидкість, якість коду та здатність розгрібати технічний борг. Саме на це звертає увагу засновниця ChatPRD та ведуча «How I AI» Клер Во, яка однією з перших отримала доступ до GPT‑5.5 від OpenAI і протестувала модель на реальних задачах у власному продукті.

Швидкість без компромісів в інтелекті

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

У випадку GPT‑5.5 ситуація інша:

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

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

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

Отримавши доступ до GPT‑5.5, Клер Во одразу перевела модель у режим активної розробки: підключила її в Codex і почала запускати робочі гілки (worktrees) для численних проєктів — як уже запланованих, так і тих, що існували лише як ідеї.

Це демонструє кілька важливих моментів:

• Модель підходить для паралельної роботи над багатьма задачами. GPT‑5.5 не обмежується точковими запитами, а може стати ядром для масштабного «розгортання» нових фіч і сервісів.
• Підтримує підхід «мислити з надлишком» (abundance mindset). Коли запуск нового проєкту або експерименту стає дешевшим і швидшим, з’являється можливість тестувати більше ідей без значного навантаження на команду.

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

Автономне виправлення багів: кейс ChatPRD

Найпоказовіший тест GPT‑5.5 — робота з технічним боргом і багами в ChatPRD. У процесі швидкої розробки AI‑продуктів неминуче накопичуються:

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

У цьому випадку було зроблено так:

1. Зібрано беклог багів у CSV.
   Усі накопичені задачі зведено в структурований файл.
2. Передано цей CSV у GPT‑5.5.
   Моделі поставили конкретне завдання: виправити кілька категорій багів, які особливо заважали.
3. Модель самостійно пропрацювала рішення.
   GPT‑5.5 виконала приблизно 98% роботи з виправлення, після чого залишилося лише «підчистити» деталі вручну.

Результат:

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

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

Якість коду та робота з великими кодовими базами

Окремий акцент — на тому, як GPT‑5.5 поводиться в складних кодових базах:

• Краще розуміння структури проєкту.
  Модель здатна «проходити» через великий і заплутаний код, не втрачаючи контекст.
• Групування та архітектура рішень.
  GPT‑5.5 не просто пропонує локальні патчі, а формує рішення, які враховують загальну архітектуру, групує зміни логічно й послідовно.
• Менше «бебі-сітингу».
  Розробнику не потрібно постійно контролювати кожен крок моделі. Рівень автономності достатній, щоб довірити їй значну частину роботи й лише фінально перевіряти результат.

У підсумку це означає, що модель може:

• писати якісніший код;
• ефективно працювати як із новими проєктами, так і з існуючими системами;
• реально впливати на метрики якості — наприклад, на швидкість «спалювання» дефектів (bug burndown) та зменшення кількості алертів.

Що це означає для команд розробки

Перший досвід використання GPT‑5.5 у продакшен‑сценаріях показує кілька тенденцій, важливих для інженерних команд:

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

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

Джерело

First impressions of GPT-5.5 from Claire Vo — OpenAI (YouTube)

У 2026 році створити AI‑продукт технічно простіше, ніж будь-коли: готові моделі, no‑code платформи, голосові агенти «з коробки». Справжній дефіцит уже не в коді, а в правильному виборі ніші й каналу дистрибуції. У розмові на каналі Silicon Valley Girl засновники Opus Clip, ElevenLabs, Higgsfield та інші діляться тим, як би вони запускали бізнес із нуля: без команди, без коду, без інвестицій — лише з ноутбуком і AI.

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

Вузько, ще вужче: чому «китайські ресторани» — це не ніша

CEO Opus Clip Ян Чжао пропонує радикально переглянути саме поняття «ніша». Те, що більшість фаундерів вважає сегментацією, насправді є надто широкими ринками, де шансів на помітний product‑market fit майже немає.

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

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

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

Чим жорсткіше сегментування, тим простіше:

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

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

«Нудні» ніші й сервіс як софт: де ховаються справжні гроші

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

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

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

Ян описує важливий зсув: від «software as a service» до «service as a software». Тобто не вигадувати нові задачі для AI, а брати вже існуючі платні сервіси й перетворювати їх на продукт.

Логіка проста. Якщо:

• бізнес уже платить агентству або фрилансеру,
• процес уже формалізований (є бриф, чек‑листи, шаблони),
• результат більш-менш стандартизований,

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

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

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

Голосові агенти для локального бізнесу: недооцінений ринок 2026 року

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

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

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

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

Голосовий агент, підключений до календаря, може:

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

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

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

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

Це класичний приклад того, як «service as a software» працює в голосовому світі: замість кол‑центру або адміністратора — спеціалізований голосовий агент як SaaS‑підписка.

Перший долар важливіший за перший раунд: нова метрика успіху AI‑стартапу

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

Його нова рамка успіху:

• перший зароблений долар — до 30‑го дня розробки продукту,
• вихід на річний ARR у 1 млн доларів (приблизно 80 тис. доларів на місяць) — до 90‑го дня.

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

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

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

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

Цей кейс добре ілюструє, як виглядає «здоровий» AI‑бізнес 2026 року:

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

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

Як запустити AI‑продукт без реклами: драбина органічного розповсюдження

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

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

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

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

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

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

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

Соцмережі як безкоштовний двигун: стратегія Ґері Вайнерчука

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

По‑перше, він створив би додаток із підпискою в діапазоні 5–50 доларів на місяць. Тобто не дорогий enterprise‑продукт, а доступний SaaS для масового або SMB‑сегмента. Такий ціновий діапазон дозволяє:

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

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

Цей підхід добре резонує з реаліями AI‑ринку:

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

У поєднанні з вузькою нішею та чітким болем це створює робочу формулу: простий AI‑сервіс + доступна підписка + високочастотний контент у соцмережах.

Власні канали проти алгоритмів: чому email усе ще критичний

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

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

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

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

За наведеними даними, клієнти Omnisend у середньому отримують близько 79 доларів доходу на кожен витрачений долар, а міграція з інших систем займає 3–5 днів і відбувається без простою. Платформа також пропонує цілодобову підтримку з середнім часом відповіді менше п’яти хвилин, а за промокодом MARINA діє знижка 30% на перші три місяці.

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

Висновок: формула AI‑бізнесу 2026 року

Зі слів засновників Opus Clip, ElevenLabs, Higgsfield і підходу Ґері Вайнерчука вимальовується доволі прагматична формула AI‑бізнесу в 2026 році.

По‑перше, радикально вузька ніша. Не «ресторани» й навіть не «китайські ресторани», а максимально конкретний сегмент із чітким болем і готовністю платити.

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

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

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

І нарешті, дистрибуція: старт через X, подальше підхоплення AI‑новинними сторінками, Instagram, креаторами й іншими платформами, підкріплене власними каналами на кшталт email. У поєднанні з низькоціновим SaaS і масованим органічним контентом це дає реальний шанс побудувати прибутковий AI‑бізнес без бюджету на рекламу й без залежності від інвесторів.

Джерело

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

У час, коли увагу розривають сповіщення, новини й хронічна тривога, питання внутрішнього діалогу перестає бути темою психологічних есе й стає питанням виживання. Співачка, авторка пісень та акторка Ронда Росс, випускниця Brown University й номінантка на премію «Еммі», уже близько 25 років розвиває та викладає власну практику роботи з мисленням. На сцені TEDNext 2025 вона розповіла, як перетворює руйнівні автоматичні думки на персоналізовані музичні мантри — «songtras» — і чому це для неї не метафора, а реальний інструмент емоційної регуляції.

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

Крок перший: визнати, що внутрішній саундтрек — це ваша зона відповідальності

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

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

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

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

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

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

Крок другий: точно назвати почуття — і дати йому розсіятися

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

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

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

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

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

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

Крок третій: виявити думку-тригер і дати ім’я автоматичним руйнівним шаблонам

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

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

Саме ці твердження вона називає «automatic screwy thoughts» або «automatic sabotaging thoughts» — автоматичні «криві» чи саботуючі думки. Скорочено — ASTs.

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

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

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

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

Від AST до INT: як створюється персональна афірмація

Коли автоматична руйнівна думка виявлена й названа, Ронда переходить до наступного етапу — свідомої заміни. Вона пропонує трансформувати AST у те, що називає INT — «intentionally nourishing thought», тобто «навмисно живильна думка».

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

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

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

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

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

Від думки до музики: як народжуються «songtras»

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

Вона не просто формулює INT — вона перетворює їх на мелодії. Так з’являється те, що вона називає «songtras» — поєднання слів «song» (пісня) і «mantra».

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

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

«Songtra» — це не просто пісня з позитивним текстом. Це персоналізована музична формула, в якій:

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

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

Щоденна практика й «швидка допомога»: як працюють songtras у реальному житті

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

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

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

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

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

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

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

Висновок: внутрішній голос як інтерфейс до власної сили

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

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

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

Джерело

How to Tune Your Inner Voice | Rhonda Ross, Daniel Alexander Jones | TED

У час, коли GitHub Copilot, Claude Code та інші AI-асистенти пишуть цілі модулі за один запит, у багатьох інженерів виникає тривожне запитання: чи не знецінюються класичні навички розробки? Британський інженер і викладач Метт Поко́к, автор курсу «Claude Code for Real Engineers», пропонує радикально протилежну відповідь. На його думку, базові принципи програмної інженерії сьогодні важливіші, ніж будь-коли раніше — саме тому, що AI став настільки потужним.

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

«Specs to code»: привабливий, але руйнівний анти-патерн

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

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

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

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

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

Складність як ворог: Остергаут і небезпека AI-посиленої заплутаності

Щоб зрозуміти, чому «specs to code» так швидко заводить проєкти в глухий кут, Поко́к звертається до класичної роботи Джона Остергаута «A Philosophy of Software Design». Остергаут пропонує чітке й практичне визначення складності: це все, що в структурі програмної системи ускладнює її розуміння та модифікацію.

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

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

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

Ентропія коду в епоху LLM: як AI прискорює природний розпад систем

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

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

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

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

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

Міф про «дешевий код»: чому поганий код став дорожчим, ніж будь-коли

Одним із гасел, що підживлюють AI-оптимізм, стало твердження «code is cheap» — код дешевий. Мовляв, якщо модель може за хвилину написати те, на що раніше йшли години, то вартість коду як ресурсу різко впала. Поко́к категорично не погоджується з цим.

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

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

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

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

Як якість коду множить ефективність AI

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

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

генерувати зміни, які природно вписуються в існуючу структуру;

легше знаходити правильні місця для нової логіки;

краще використовувати типи, тести й інші сигнали якості.

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

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

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

Спільний дизайн-концепт: чому AI «не робить те, що ви хотіли»

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

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

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

Щоб подолати цей розрив, Поко́к створив просту, але показову «навичку» для AI — промпт під назвою «grill me». Його суть: змусити модель не поспішати до генерації коду, а спочатку «допитати» розробника до стану справжнього спільного розуміння. Інструкція звучить приблизно так: «Інтерв’юй мене безжально щодо кожного аспекту плану, поки ми не досягнемо спільного розуміння. Пройдися по кожній гілці дерева дизайну, розв’язуючи залежності між рішеннями одне за одним».

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

Показово, що репозиторій із цією навичкою зібрав близько 13 тисяч зірок на GitHub — явна ознака того, що проблема спільного розуміння з AI болить багатьом. Поко́к навіть стверджує, що такий підхід кращий за стандартний «plan mode» у Claude Code, який надто поспішає створити артефакт — план або код — замість того, щоб спочатку досягти глибокої узгодженості.

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

Спільна мова з AI: як зменшити багатослівність і підвищити точність

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

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

Domain-Driven Design (DDD) давно пропонує рішення цієї проблеми — «ubiquitous language», або повсюдна мова. Ідея проста: усі розмови між розробниками, доменними експертами й навіть структура коду мають спиратися на єдину, чітко визначену модель термінів. Це не просто глосарій, а жива мова проєкту, яку всі учасники використовують послідовно.

Поко́к переносить цю ідею у взаємодію з AI. Він створює навичку, яка сканує кодову базу, витягує ключову термінологію й формує markdown-файл із таблицями термінів і визначень — фактично, файл ubiquitous language. Цей документ потім передається моделі й використовується самим розробником під час «допитів» у стилі «grill me» та планування.

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

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

Фідбек як межа швидкості: чому AI «обганяє власні фари»

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

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

Але навіть за наявності цих інструментів AI часто використовує їх погано. Моделі мають схильність робити «занадто багато за раз»: генерувати великі шматки коду, а потім лише побіжно проганяти типчекер або тести. Це прямо суперечить порадам із «The Pragmatic Programmer», де автори попереджають про небезпеку «out-running your headlights» — рухатися швидше, ніж дозволяє ваш горизонт огляду.

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

AI за замовчуванням не дотримується цього принципу. Він не має інстинктивного страху перед великими дифами, не відчуває болю від дебагу. Тому розробник має нав’язати моделі дисципліну дрібних кроків. Поко́к бачить у цьому ще одну причину повернутися до класики — до тест-орієнтованої розробки (TDD), яка примушує рухатися маленькими, перевіреними кроками: спочатку тест, потім мінімальна реалізація, потім рефакторинг.

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

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

Висновок: AI не скасував основи — він зробив їх умовою виживання

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

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

Натомість добре спроєктовані системи, побудовані на класичних принципах — від Остергаута й Брукса до «The Pragmatic Programmer» і DDD, — виявляються ідеальним середовищем для AI. У таких кодових базах моделі працюють як дисципліновані помічники, а не як генератори спагеті-коду.

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

Джерело

YouTube: It Ain’t Broke: Why Software Fundamentals Matter More Than Ever — Matt Pocock, AI Hero @mattpocockuk