Claude Code від Anthropic поступово перетворюється з «чергового AI?асистента» на повноцінного співрозробника, який працює безпосередньо з локальним кодом. Канал KODARIK підготував детальний практичний гайд по цьому інструменту, а в цьому матеріалі зосередимося на тому, як саме промптити Claude Code в CLI, як посилатися на файли, керувати дозволами та використовувати вбудовані команди.

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

Від «чату з кодом» до агента в проєкті: як працюють промпти в Claude Code

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

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

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

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

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

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

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

Посилання на файли через @: як точніше спрямовувати Claude Code

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

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

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

По?перше, зникає ризик, що модель переплутає файли з однаковими назвами в різних директоріях. У великих проєктах типові імена на кшталт index.tsx, config.json або login.js можуть зустрічатися десятки разів. Текстове пояснення «у файлі login» в такій ситуації не завжди достатньо однозначне. Посилання через @ прив’язує завдання до конкретного шляху в файловій системі.

По?друге, це зручніше, ніж щоразу описувати шлях до файлу текстом. Замість «відкрий файл src/components/auth/LoginForm.tsx і додай в нього…» можна ввести @, обрати файл зі списку й продовжити: «…додай в нього валідацію для поля email». Claude Code вже розуміє, про який саме файл ідеться.

По?третє, такий підхід добре масштабується на складніші сценарії. Можна в одному промпті послатися на кілька файлів, наприклад: «онови @LoginForm.tsx, щоб використовувати новий API з @authService.ts і опиши зміни в @README.md». Для моделі це чіткий сигнал, які саме файли потрібно читати й змінювати.

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

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

Дозволи як запобіжник: чому Claude Code завжди питає «можна?»

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

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

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

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

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

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

По?друге, це знижує ризик помилок через неточні промпти. Якщо запит сформульовано нечітко, модель може інтерпретувати його ширше, ніж очікував користувач. Але перед тим, як щось змінити, Claude Code все одно покаже, які саме файли планує зачепити, і попросить дозволу.

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

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

Меню команд зі зворотним слешем: як працює інтерфейс CLI

Хоча основна взаємодія з Claude Code відбувається через промпти природною мовою, CLI?версія інструмента має ще один важливий шар керування — систему команд. Вони дозволяють швидко змінювати модель, перемикати режими, керувати сесіями та виконувати інші службові дії без довгих текстових пояснень.

CLI Claude Code надає команди через меню з префіксом слеш, яке з’являється при введенні символу \ в полі вводу. Як тільки користувач набирає зворотний слеш, у нижній частині інтерфейсу відкривається список доступних команд. По ньому можна переміщатися стрілками й обирати потрібну дію.

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

Наприклад, команда \model відкриває інтерфейс вибору моделі. У Claude Code підтримуються три основні сімейства моделей — Haiku, Sonnet та Opus, причому деякі з них доступні у варіантах зі стандартним і розширеним контекстом до 1 млн токенів. Через меню команд можна швидко перемкнутися з більш потужної, але дорогої моделі Opus на швидку й економну Haiku, якщо потрібно виконати прості тестові дії й не витрачати зайві токени.

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

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

Коли природна мова, а коли команди: практичний баланс

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

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

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

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

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

У підсумку Claude Code в CLI виглядає не як «чарівна чорна скринька», а як керований агент, з яким можна будувати зрозумілий робочий процес. Природна мова задає цілі, @?посилання уточнюють об’єкти, а \?команди керують самим середовищем.

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

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

Ключовими елементами цього підходу є:

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

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

Джерело

Claude Code — повний огляд від А до Я | Все що потрібно знати

Девід Хайнемайєр Ханссон (DHH) — співзасновник Basecamp, автор Ruby on Rails і давній фанат комп’ютерного «заліза» — останні роки активно виходить за межі «яблучної» екосистеми. У розмові на каналі The Pragmatic Engineer він описує, як конкуренція між Apple, Intel і Qualcomm, поява ARM?чипів нового покоління, 240?герцові екрани та модульні Linux?ноутбуки на кшталт Framework формують зовсім інший, значно цікавіший ринок персональних комп’ютерів.

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

Від «яблучної печери» до 240 Гц і OLED: де Apple раптом не лідер

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

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

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

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

Після п’яти років домінування M?серії: Apple більше не на самоті

Коли Apple представила свої M?чипи, вони фактично «перезапустили» уявлення про те, якими можуть бути мобільні комп’ютери. Співвідношення продуктивності до енергоспоживання, тиша, автономність — усе це стало новим стандартом, до якого індустрія довго не могла підібратися. Приблизно п’ять років Apple фактично одноосібно задавала тон.

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

З боку Intel ключовою фігурою тут стає генеральний директор Пат Ґелсінґер. У компанії є п’ятирічний план виходу на виробничий вузол 18A. Цей техпроцес задуманий як база для чипів, здатних конкурувати з поколінням Apple Panther Lake — тобто не з минулими, а з майбутніми ітераціями Apple Silicon. DHH підкреслює, що Panther Lake виробляють в Аризоні й називає це великим досягненням: повернення високотехнологічного виробництва на територію США має і промислове, і політичне, і технологічне значення.

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

Новий ARM?чип Qualcomm X Elite 2, за оцінкою DHH, уже наздогнав або навіть випередив Panther Lake за конкурентоспроможністю щодо Apple Silicon. Це означає, що в сегменті ARM?ноутбуків більше немає одного беззаперечного лідера. З’являється реальна тристороння конкуренція: Apple зі своїм вертикально інтегрованим стеком, Intel із амбіціями повернути технологічну першість на новому вузлі 18A, і Qualcomm, який переносить свій мобільний досвід у «великі» комп’ютери.

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

MacBook Neo, X Elite 2 і Panther Lake: коли ціна?якість стає головною зброєю

Попри критику бізнес?практик Apple, DHH не применшує технічних досягнень компанії. Більше того, він відверто радіє, коли Apple тисне на конкурентів там, де це корисно споживачам. Один із таких прикладів — MacBook Neo.

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

З іншого боку, Qualcomm X Elite 2 і майбутні чипи на базі Intel 18A створюють альтернативу тим, хто хоче ARM?ефективність або високу продуктивність, але не хоче чи не може жити в екосистемі Apple. ARM?ноутбуки на Windows або Linux із X Elite 2 можуть запропонувати співставну з Apple Silicon продуктивність, але з іншими форм?факторами, портами, дисплеями, можливістю запускати ігри й софт, які на macOS працюють гірше або не працюють взагалі.

Panther Lake, який DHH називає великим досягненням, додає ще один вимір: це спроба Intel не просто наздогнати, а знову стати технологічним еталоном у класі x86?процесорів. Якщо план Ґелсінґера з 18A спрацює, ринок отримає одразу кілька лінійок чипів, які в різних сценаріях можуть бути «кращими» за Apple Silicon — за продуктивністю, енергоефективністю, ціною чи підтримкою певного ПЗ.

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

Framework 13 проти ASUS Zephyrus G14: «домашній сарай» і відполірований геймерський болід

На рівні заліза ця конкуренція проявляється не тільки в чипах, а й у форм?факторах. DHH описує свій перший «серйозний» Linux?ноутбук — Framework Laptop 13. Це модульна машина, яку користувач купує як набір і збирає самостійно приблизно за п’ять хвилин. Такий підхід створює відчуття особистої причетності — ефект LEGO або IKEA, коли річ подобається більше саме тому, що ти її зібрав власноруч.

Framework 13 особливо добре підходить для продуктивності: співвідношення сторін 3:2 робить його зручним для коду, тексту й роботи з документами. Вертикального простору більше, ніж у класичних 16:9 чи 16:10, і це відчутно в IDE, терміналі, браузері. Для розробника, який проводить більшість часу в текстових інтерфейсах, це дрібниця, що швидко перетворюється на звичку.

Водночас DHH чесно визнає: у порівнянні з деякими преміальними Windows?ноутбуками Framework відчувається як «домашній сарай». У цьому є свій шарм — ти ніби сам збудував цей сарай, знаєш кожен гвинтик, можеш будь?коли щось замінити чи оновити. Але якщо поставити його поруч із ASUS Zephyrus G14, різниця в «полірованості» стає очевидною.

Zephyrus G14 — це вже інший полюс. Це геймерський ноутбук із OLED?дисплеєм, продуманим дизайном і акуратною «ігровою» естетикою, яка не перетворюється на дискотеку з RGB?підсвіткою. На кришці — програмований LED?«слеш», який можна налаштувати під різні патерни. Клавіатура має RGB?підсвітку, яку DHH навіть інтегрував у власний софт: зміна теми в редакторі змінює й кольори підсвітки (Tokyo Night — фіолетові відтінки, Nord — холодні сірі й блакитні).

Це приклад того, як «ігровий» ноутбук може залишатися стриманим, але водночас виразним. І водночас — як далеко пішли Windows?машини в сегменті, де Apple взагалі не грає: поєднання потужного GPU, високої частоти оновлення, OLED?екрана й кастомізованої естетики.

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

OLED як одкровення: коли Fortnite стає тестом для дисплея

Ще один момент «прозріння» для DHH — це перший серйозний досвід з OLED?екраном у ноутбуці. До цього він роками користувався або Mac’ами, або тим самим Framework 13 — усі з IPS чи mini?LED панелями. OLED?телевізор у вітальні не дав такого ефекту: відстань до екрана велика, і хоч картинка чудова, вона не настільки «інтимна».

На ноутбуці все інакше. Відстань до екрана — 30 сантиметрів. І коли на такому OLED?дисплеї запускаєш гру на кшталт Fortnite, враження зовсім інші. Яскраві, насичені кольори, глибокий чорний, контраст — усе це в поєднанні з динамічним, візуально строкатим світом гри створює ефект, якого важко досягти на IPS чи навіть на хорошому mini?LED.

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

Цей досвід підсвічує ще одну важливу зміну на ринку ноутбуків. Якщо раніше OLED був радше екзотикою в телевізорах і кількох дорогих моделях, то тепер він поступово стає стандартом у преміальному сегменті Windows?машин. Apple поки що обережно підходить до OLED у ноутбуках, роблячи ставку на mini?LED у MacBook Pro. Це знову відкриває нішу, де конкуренти можуть запропонувати щось відчутно інше — і для геймерів, і для творців контенту, і просто для тих, хто хоче максимально якісну картинку.

У поєднанні з високою частотою оновлення OLED?екрани перетворюють ноутбук на пристрій, який одночасно і робочий інструмент, і джерело естетичного задоволення. І тут уже не так важливо, чи це Mac, чи Windows, чи Linux: важливо, що конкуренція змушує виробників шукати нові способи зробити досвід кращим.

Клавіатури, «thock» і майбутнє без ноутбуків

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

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

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

У цьому контексті конкуренція між Apple, Intel і Qualcomm — не просто боротьба корпорацій за ринкову частку. Це механізм, який робить комп’ютери цікавішими, доступнішими й різноманітнішими. Від дешевшого, але все ще потужного MacBook Neo до модульного Framework 13, від OLED?боліда ASUS Zephyrus G14 до ARM?машин на X Elite 2 — усе це різні відповіді на одне й те саме запитання: яким має бути комп’ютер, щоб ним хотілося користуватися щодня.

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

Новий ландшафт ноутбуків і персональних комп’ютерів формується на перетині кількох тенденцій. Apple більше не є єдиним еталоном продуктивності й енергоефективності. Intel із планом 18A і Panther Lake, Qualcomm із X Elite 2, виробники на кшталт ASUS і Framework із різними підходами до дизайну й модульності — усі вони створюють середовище, де жодна компанія не може дозволити собі застигнути.

Відсутність у Apple 240?герцових дисплеїв відкриває нішу для геймерських і продуктивних Windows?машин. Поява доступного MacBook Neo тисне на конкурентів у нижчому ціновому сегменті. ARM?чипи Qualcomm і нові вузли Intel змушують Apple тримати темп розвитку власних M?серій. А модульні Linux?ноутбуки й відполіровані OLED?боліди показують, що «комп’ютер» може виглядати й відчуватися дуже по?різному.

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

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

Джерело

YouTube: DHH: how to escape the “Apple bubble”

Claude Code від Anthropic — це інструмент для розробників, який працює безпосередньо з локальними файлами проєкту: читає, редагує, створює й видаляє файли, запускає команди й перевіряє, чи нічого не зламалося. На відміну від звичайного чат-бота, він не просто генерує фрагменти коду, а реально втручається у ваш репозиторій і виконує завдання «під ключ». Автор каналу KODARIK, який протестував багато AI?інструментів для розробки й залишив у щоденній роботі саме Claude Code, детально розбирає не лише функції, а й економіку його використання.

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

Чому безкоштовного Claude недостатньо для роботи з проєктами

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

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

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

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

Скільки коштує Claude Pro і що ви реально платите щомісяця

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

При оплаті за рік Pro коштує приблизно 17 доларів на місяць. Якщо платити помісячно, ціна зростає до 20 доларів. До цього додається ПДВ, і підсумкова сума для користувача виходить близько 24 доларів на місяць.

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

З погляду розробника, який використовує Claude Code щодня, це фактично фіксований абонплатіж за доступ до інструмента, що:

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

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

Pro проти Max: коли базового тарифу стає замало

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

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

Max відрізняється насамперед вищими лімітами використання. Це критично, якщо:

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

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

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

Ліміти Pro: як працюють 5?годинне й 7?денне вікна

Навіть маючи платну підписку, користувач Claude Pro не отримує необмежений доступ до Claude Code. Сервіс працює з двома ковзними лімітами: 5?годинним і 7?денним. Обидва відображаються безпосередньо в інтерфейсі Claude Code, тож користувач завжди бачить, скільки ресурсу вже витрачено.

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

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

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

Якщо один із лімітів вичерпано, Claude Code тимчасово перестає працювати. Користувач не може продовжити сесію, доки відповідне вікно не оновиться — тобто поки частина попередньої активності не «випаде» з останніх 5 годин або 7 днів.

Це створює специфічну динаміку роботи. Наприклад, якщо ви провели дуже інтенсивну 4?годинну сесію, а потім через годину знову спробували активно навантажити Claude Code, можете несподівано впертися в 5?годинний ліміт. Або якщо кілька днів поспіль працювали по кілька годин, до кінця тижня 7?денне вікно може виявитися повністю заповненим.

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

Чому API?доступ до Claude Code може виявитися дорожчим, ніж здається

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

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

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

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

Саме тому рекомендація зводиться до простого правила: для початку й для повсякденної роботи з проєктами варто брати саме Pro як підписку, а не будувати роботу навколо API. API має сенс у вузьких сценаріях, де потрібна глибока інтеграція в інфраструктуру, але як основний спосіб взаємодії з Claude Code він часто виявляється фінансово невигідним.

Як економіка тарифів впливає на стиль роботи з Claude Code

Особливості тарифів і лімітів Claude Code неминуче формують певну культуру використання інструмента. Розробник, який розуміє, як працюють 5?годинне й 7?денне вікна, скільки коштує Pro й чому API може бути дорогим, інакше планує свої сесії й завдання.

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

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

По?третє, розробник починає свідомо вибирати модель під задачу. У Claude Code доступні різні моделі — від швидкої й дешевої Haiku до потужної, але дорогої Opus, а також збалансована Sonnet, яку рекомендують для 90% щоденних задач. Розуміння того, що потужніші моделі споживають більше токенів, а отже, швидше «з’їдають» ліміти й дорожчі в API?сценаріях, стимулює використовувати їх лише там, де це справді потрібно.

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

Висновки: як обрати свій шлях у тарифах Claude Code

Економіка Claude Code будується навколо простої, але жорсткої логіки. Безкоштовний план не дає доступу до головної цінності — роботи безпосередньо з проєктами. Мінімальний вхід — підписка Claude Pro, яка коштує близько 24 доларів на місяць з урахуванням ПДВ і дає зрозумілі, але обмежені 5?годинні та 7?денні ліміти.

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

Використання Claude через API, попри технічну гнучкість, виявляється відносно дорогим: при активній роботі щоденні витрати на рівні 5–6 доларів швидко перевищують вартість Pro. Тому для повсякденної розробки рекомендація однозначна — починати саме з підписки, а не з API.

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

Джерело

Claude Code — повний огляд від А до Я | Все що потрібно знати

У лютому 2026 року в подкасті Confluent Developer технічний чемпіон Confluent Джозеф Мораїс і ведучий Тім Берглунд говорили не про абстрактне «майбутнє AI», а про те, як саме вони вже сьогодні пишуть код разом із моделями. Без спонсорських угод і рекламних інтеграцій, лише з позиції розробників, які щодня пробують нові інструменти — від Claude Code до Gemini — у реальних проєктах, від бекенду на Kotlin до візуалізацій на Raspberry Pi та побутових задач на кшталт вибору автомобіля.

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

Від скепсису до «це вже продакшн»: якісний стрибок моделей наприкінці 2025 року

Ще близько року до запису епізоду, коли Тім Берглунд уперше серйозно спробував AI-асистентів для коду, враження були радше стримані. Він узяв особистий хардверний проєкт — LED-версію ніксі-годинника на мікроконтролері з Wi?Fi — і поставив перед моделлю цілком практичні задачі.

Перша задача здавалася ідеальною для сучасних моделей: написати Netlify Function, яка за IP-адресою робить реверс-геокодування, визначає, чи діє літній час, і повертає компактну відповідь, зручну для парсингу в обмеженому C++?фірмварі. Код функції модель згенерувала, але далі все розвалилося: Next.js не збирався, деплой на Netlify не проходив. Для екосистеми, де є величезний масив відкритого коду й документації, це виглядало як провал.

Друга задача стосувалася підтримки HTTPS у тому ж мікроконтролерному проєкті. Тім спробував отримати від моделі робочий приклад із використанням Raspberry Pi Pico SDK. Результат виявився «сміттям»: приклади не працювали, довелося розбиратися вручну й реалізовувати все «по-старому». Висновок на той момент був простий: мовні моделі цікаві, але як інструмент для реальної інженерної роботи — ще не готові.

Цей фон робить контраст із кінцем 2025 року особливо разючим. Узимку, буквально за кілька місяців до розмови, Тім повернувся до теми, уже з Claude Code. І цього разу сценарій був інший: бекенд на Kotlin для особистого проєкту, який спілкується з пристроєм по Bluetooth. Він сформулював задачу — і отримав працюючий застосунок. Без довгих танців із бубном, без тотальної переробки. Код «розгорнувся» і запрацював.

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

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

Claude Code в реальному стеку: від Kotlin-бекенду до OpenGL на Raspberry Pi

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

Перший приклад — згаданий бекенд на Kotlin, який спілкується з пристроєм через Bluetooth. Це не «hello world», а типовий для продакшн-проєктів шматок серверної логіки: робота з протоколами, обробка даних, інтеграція з оточенням. Claude Code згенерував код, який запрацював без тривалого дебагу. Для розробника, який ще рік тому бачив, як моделі «спотикаються» на базових речах на кшталт деплою в Netlify, це радикальна зміна.

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

Третій, і, можливо, найяскравіший приклад — невелика система візуалізації, схожа на осцилограф, на одногігабайтному Raspberry Pi 5. Це OpenGL?візуалізація, яка в реальному часі показує сигнал, — типове завдання для студентів-електронників, але з усіма притаманними йому технічними деталями: робота з графічним стеком, оптимізація під обмежені ресурси, обробка потоку даних.

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

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

Джозеф Мораїс: від CLI та контейнерів до «інтелектуального субстрату» для ідей

Для Джозефа Мораїса, технічного чемпіона Confluent, поява Claude Code у власному робочому процесі в 2026 році стала черговою «точкою радості» в кар’єрі. Він порівнює це відчуття з першими спробами розгорнути контейнер або працювати з Cisco IOS через CLI — моментами, коли нова технологія буквально «вмикає дитину всередині».

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

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

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

Показовий приклад — демо, яке він будує навколо Confluent Cloud і Claude. Мораїс хоче створити end?to?end сценарій із потоковою обробкою даних, але замість того, щоб одразу деталізувати всі події, топіки й сервіси, він задає лише загальний наратив: тематика гостинності, два продюсери, один консюмер, інтеграція з Flink, усе це на Confluent Cloud.

Claude Code на основі цього формує змістовну модель подій: часи check?in, замовлення в номер, об’єднання цих потоків у 360?градусний профіль гостя, тригери для SMS?сповіщень про готовність номера чи доставку їжі. Усе це — без того, щоб Мораїс вручну прописував кожен тип події чи бізнес-правило. AI фактично пропонує логічний доменний сценарій, який добре лягає на початкову ідею.

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

AI як посередник між людиною та інфраструктурою: CLIs, SaaS і новий тип взаємодії

Окрема лінія в міркуваннях Мораїса — це роль AI як посередника між розробником і складними інтерфейсами, насамперед CLI та SaaS?платформами. З огляду на його операторський досвід, це не теоретична розмова, а спроба зрозуміти, як зміниться повсякденна робота інженера.

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

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

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

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

Розділення ролей: Claude для коду, Gemini для довгих досліджень

Цікаво, що в особистому житті Мораїс також активно використовує AI?інструменти, але вже з іншим розподілом ролей. Claude Code для нього — насамперед про код і технічні демо. А от для довгих, багатокрокових досліджень, які виходять за межі чистої розробки, він звертається до Gemini.

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

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

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

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

Чесні рекомендації: чому важливо, що Anthropic не спонсорує розмову

У розмові неодноразово звучить назва Claude Code, і Тім Берглунд спеціально підкреслює: Anthropic не є спонсором епізоду. Немає жодних комерційних домовленостей, немає платної інтеграції. Це важливе застереження в контексті 2026 року, коли ринок AI?інструментів насичений маркетингом, а межа між щирим досвідом і рекламою часто розмита.

У цьому випадку і Берглунд, і Мораїс говорять про Claude Code, Gemini та інші інструменти як про засоби, які вони реально використовують у роботі й особистих проєктах. Вони не приховують недоліків (як-от проблеми з геопросторовими обчисленнями в проєкті з дроном) і не намагаються створити враження «магії», яка все робить сама.

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

Висновок: новий досвід розробника — це робота з ідеями, а не з інтерфейсами

Досвід Тіма Берглунда й Джозефа Мораїса показує, що до початку 2026 року агентні AI?інструменти перестали бути експериментом і стали частиною повсякденної роботи розробника. Claude Code генерує продакшн?якісний бекенд на Kotlin, допомагає будувати OpenGL?візуалізації на Raspberry Pi й пропонує осмислені доменні сценарії для потокових демо. Gemini бере на себе довгі дослідження, перетворюючи виснажливий збір інформації на серію діалогів.

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

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

Джерело

The AI Impact on the Developer Future with Joseph Morais | Ep. 27 | Confluent Developer Podcast

Claude Code від Anthropic поступово перетворюється з «розумного чат?асистента в терміналі» на повноцінне робоче середовище для розробників. У проміжному?до?просунутому гайді на каналі Tech With Tim автор демонструє свій професійний сетап: від конфігурації MCP?серверів до підключення GitHub та зовнішніх плагінів на кшталт Context 7. На практиці це означає, що Claude може не лише писати код, а й самостійно створювати репозиторії, пушити зміни та читати актуальну документацію.

Цей матеріал зосереджений саме на тому, як налаштувати MCP?сервери й персональні плагіни в Claude Code, щоб автоматизувати роботу з GitHub і дати моделі доступ до зовнішніх інструментів.

Архітектура MCP у Claude Code: рівні доступу та команда /mcp

Щоб зрозуміти, як підключати GitHub та інші сервіси, спершу варто розібратися, як Claude Code організовує конфігурацію MCP?серверів.

Система підтримує три рівні (scope), на яких можна оголошувати MCP?сервери та інші налаштування: проєктний, користувацький і глобальний. Від обраного рівня залежить, де саме будуть доступні інструменти.

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

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

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

Важливий нюанс: якщо додати MCP?сервер лише на рівні поточного проєкту, він не з’явиться в інших сесіях Claude Code. Тому при налаштуванні варто свідомо обирати scope — локальний чи користувацький — залежно від того, чи має інструмент бути універсальним, чи прив’язаним до конкретного коду.

GitHub як MCP?сервер: Claude сам створює репозиторії та пушить код

Одна з найпрактичніших інтеграцій, яку зараз можна додати до Claude Code, — GitHub MCP?сервер. Його роль — дати моделі можливість напряму працювати з віддаленими репозиторіями: створювати їх, пушити файли, оновлювати вміст, не вимагаючи від користувача вручну виконувати послідовність git?команд.

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

У демонстрації GitHub MCP?сервер використовується саме так: після налаштування Claude отримує інструкцію створити новий репозиторій, згенерувати README й запушити його. Інтеграція успішно створює живий віддалений репозиторій на GitHub, що підтверджує, що модель не просто симулює дії, а реально взаємодіє з API GitHub через MCP.

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

Як додати GitHub MCP?сервер: токен, scope і правильний термінал

Налаштування GitHub MCP?сервера в Claude Code відбувається через окрему термінальну команду. Важливо, що її потрібно запускати не всередині сесії Claude Code, а в звичайному терміналі операційної системи.

Команда має вигляд, подібний до:

claude mcp add json github …

У ній вказується конфігурація сервера та GitHub Personal Access Token (PAT), який виступає ключем доступу до вашого облікового запису. Саме PAT дозволяє Claude від вашого імені створювати репозиторії та пушити зміни.

Щоб отримати цей токен, потрібно зайти у свій акаунт GitHub і пройти кілька кроків у налаштуваннях. У меню Settings слід перейти до розділу Developer settings, далі — до Personal access tokens, і там обрати Fine?grained tokens. У цьому інтерфейсі створюється новий токен з потрібними правами доступу. Для роботи GitHub MCP?сервера зазвичай достатньо дозволів на рівні репозиторіїв, щоб можна було створювати й змінювати їхній вміст.

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

Ще один ключовий параметр — scope. Якщо не вказувати додаткових опцій, GitHub MCP?сервер буде додано в локальний контекст поточного проєкту. Для більшості користувачів логічніше зробити його доступним глобально, щоб Claude міг працювати з GitHub у будь?якій директорії. Для цього до команди додається прапорець -d-scope user, який означає користувацький рівень, фактично глобальний для всіх проєктів на цій машині.

Після запуску команди в звичайному терміналі Claude Code зчитує нову конфігурацію. Щоб переконатися, що все працює, достатньо перезапустити Claude, виконати /mcp і перевірити, що GitHub з’явився в списку підключених серверів. У цьому ж інтерфейсі можна переглянути деталі, повторно ініціалізувати з’єднання або, за потреби, відключити сервер.

Без OAuth і зайвих діалогів: як працює аутентифікація через PAT

Окрема перевага GitHub MCP?інтеграції в Claude Code — спрощена модель аутентифікації. Після того як користувач один раз створив fine?grained токен у GitHub і вніс його в конфігурацію MCP?сервера, додатковий OAuth?флоу не потрібен.

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

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

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

Context 7 та інші персональні плагіни: живі документи й «суперсили» для Claude

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

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

Context 7 встановлюється через інтерфейс персональних плагінів у десктопному застосунку Claude. Після активації він стає ще одним інструментом, до якого Claude може звертатися під час виконання завдань у Claude Code, зокрема в поєднанні з MCP?серверами.

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

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

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

Керування інструментами й продуктивністю: чому важливо не перевантажувати Claude

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

У самому Claude Code це добре видно через команду /context, яка показує, скільки токенів уже використано, які системні промпти, інструменти, навички й повідомлення зараз перебувають у контексті. У прикладі з відео видно, що в сесію підтягується велика кількість MCP?інструментів, зокрема від Zapier, які в конкретний момент не потрібні. Вони лише збільшують обсяг контексту й потенційно ускладнюють вибір інструментів для моделі.

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

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

Висновки: Claude Code як керований хаб інструментів розробника

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

Команда /mcp забезпечує прозорий огляд усіх підключених серверів, а використання GitHub Personal Access Token спрощує аутентифікацію, усуваючи потребу в додаткових OAuth?процедурах. Після одноразового налаштування Claude може працювати з GitHub практично так само природно, як із локальною файловою системою.

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

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

Джерело

The Ultimate Claude Code Guide | MCP, Skills & More — Tech With Tim

Девід Хайнемайєр Ханссон (DHH) — співзасновник Basecamp, автор Ruby on Rails і давній публічний голос у світі розробки — останніми роками став ще й одним із найяскравіших критиків технологічної монокультури. В розмові на каналі The Pragmatic Engineer він розповідає, як вийшов із багаторічної «Apple?бульбашки», чому розробникам варто перестати мислити категоріями «один головний ноутбук на все життя» і як брендова війна «Apple vs PC» заважає бачити головне — прогрес обчислень.

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

«Психологія одного ноутбука»: чому розробники бояться мати кілька машин

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

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

Парадоксально, що ті ж самі розробники щодня користуються «мільйонами CPU» у хмарі — через ChatGPT, веб?додатки, CI?системи. Вони чудово розуміють, що обчислення давно розподілені й масштабуються горизонтально. Але вдома продовжують мислити так, ніби їм «дозволено» лише один фізичний комп’ютер.

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

Mac Mini для LLM як символ нового підходу

Один із найяскравіших прикладів зміни мислення — хвиля покупок Mac Mini під локальні LLM. Ханссон згадує, як «відкрите claw?явище» (мова про локальний запуск моделей на кшталт Claude/LLM) підштовхнуло багатьох розробників просто піти й купити окремий Mac Mini, щоб ганяти на ньому свої моделі.

Ці машини не замінювали основний ноутбук. Вони ставали «коробкою для LLM» — окремим вузлом у домашній інфраструктурі розробника. Фактично, це маленький локальний дата?центр на столі, який живе поруч із основним робочим комп’ютером.

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

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

Життя в «Apple?садку» і момент остаточного розриву

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

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

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

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

Один із таких прикладів — монітори з частотою оновлення 240 Гц. Для геймерів це давно стандарт, але в екосистемі Mac подібних продуктів немає: Apple не пропонує жодного дисплея з 240 Гц. Якщо ви живете всередині Apple?світу, ви можете навіть не знати, наскільки по?іншому виглядає й відчувається зображення на такому екрані в динамічних іграх.

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

Технічний респект до Apple і неприйняття «воротарства»

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

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

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

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

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

Брендова війна «Apple vs PC» як токсична плутанина

Окрема тема, яка проходить через усю розмову, — це те, як обговорення комп’ютерів в інтернеті перетворилося на квазіспортивне протистояння. Ханссон описує дискусії на X (колишній Twitter) як глибоко партійні: якщо ти любиш Apple, від тебе чекають, що ти будеш зневажати PC, і навпаки.

Це особливо помітно, коли мова заходить про нові чипи й архітектури. Наприклад, він згадує про план CEO Intel Пета Гелсінгера вивести компанію на виробничий вузол 18A — саме для того, щоб випускати чипи, здатні конкурувати з тим, що Apple робить у поколінні Panther Lake. Для Ханссона це надихає: американська компанія з довгою історією намагається повернути собі лідерство.

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

Ханссон порівнює це з класичним «bike?shed effect»: чим нижчі реальні ставки, тим запекліші суперечки. Вибір ноутбука — саме така тема. Для більшості людей це не питання життя й смерті, але емоційні інвестиції в «свою команду» роблять дискусію токсичною.

Те саме він бачить і в реакції на Qualcomm. Компанія, яка фактично живить більшість мобільних комп’ютерів у світі завдяки домінуванню Android на «кишенькових» пристроях, робить вражаючі речі з ARM?архітектурою. Її X Elite 2, за словами Ханссона, вже наздогнав, а подекуди й перевершив Panther Lake у конкурентності з Apple Silicon.

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

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

Конкуренція як справжній союзник користувача

Попри всю емоційну риторику навколо брендів, реальні вигодонабувачі від конкуренції — це користувачі. Ханссон прямо говорить: суперництво між Apple, Intel і Qualcomm робить продукти кращими й дешевшими.

Після приблизно п’яти років домінування Apple у сфері мобільних чипів, коли M?серія задавала тон, решта індустрії нарешті почала наздоганяти. Intel із планом 18A, Qualcomm із X Elite 2, виробники ноутбуків, які будують машини на ARM і x86, — усе це створює тиск на Apple. А тиск — це завжди стимул рухатися швидше, знижувати ціни, шукати нові форм?фактори.

У цьому сенсі навіть ті, хто ніколи не купить ноутбук на Windows чи ARM?машину від Qualcomm, виграють від того, що ці продукти існують і успішні. Вони змушують Apple не розслаблятися, не перетворюватися на монополіста, який може дозволити собі повільні оновлення й агресивніші бізнес?практики.

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

«Базова модель»: любов до комп’ютерів, а не до логотипів

Щоб не потонути в брендово?партійних війнах, Ханссон виробив для себе просту ментальну модель. Коли він ловить себе на емоційній реакції — захопленні чи відразі — до чергової новини про Apple, Intel, Qualcomm чи будь?якого іншого гравця, він ставить собі запитання: це справжня оцінка суті, чи просто «реакція мого табору»?

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

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

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

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

Історія DHH — це не маніфест проти Apple і не реклама будь?якого іншого бренду. Це радше запрошення переглянути власні установки.

По?перше, розробникам варто перестати мислити категоріями «один головний ноутбук». У світі, де ви й так щодня користуєтеся розподіленими обчисленнями, мати вдома кілька спеціалізованих машин — нормальна й часто економічно виправдана практика. Mac Mini для локальних LLM, окремий Linux?бокс для експериментів, ігровий ПК чи ноутбук — це не розкіш, а інструменти.

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

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

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

Джерело

YouTube: DHH: how to escape the “Apple bubble”

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

Що таке фізичний ШІ і чим він відрізняється від класичної робототехніки

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

Фізичний ШІ змінює цю парадигму. Йдеться про системи, які:

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

Це можуть бути не лише роботизовані руки, а й:

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

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

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

Чому фізичний ШІ став гарячою темою саме зараз

Розвиток фізичного ШІ довго гальмували кілька вузьких місць. Сьогодні вони частково подолані, і це різко прискорило прогрес.

1. Моделі нового типу: Vision-Language-Action (VLA)

Одним із ключових проривів стали vision-language-action моделі (VLA). Їхня назва відображає три складові:

• Vision — бачення: сприйняття світу через зображення чи відео.
• Language — мова: здатність описувати, інтерпретувати й робити висновки.
• Action — дія: перетворення розуміння ситуації на конкретні фізичні дії.

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

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

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

2. Подолання «sim-to-real gap»

У робототехніці давно відома проблема sim-to-real gap — розриву між симуляцією та реальністю. Робот, який чудово працює у віртуальному середовищі, часто «ламається» в реальному світі, де:

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

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

3. Стрибок у продуктивності обчислень

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

Це означає:

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

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

Як навчають фізичний ШІ: від віртуальної фабрики до реального конвеєра

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

Старт із симуляції: створення віртуального світу

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

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

Критично важливо закласти domain randomization — навмисне варіювання параметрів, зокрема:

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

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

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

Далі застосовується reinforcement learning (RL) — навчання з підкріпленням. Схема виглядає так:

1. Робот виконує дію в симуляції (наприклад, намагається взяти деталь і встановити її в потрібне місце).
2. Якщо завдання виконано успішно — модель отримує «нагороду».
3. Якщо ні — нагорода не нараховується (або застосовується «штраф»).
4. Процес повторюється тисячі чи мільйони разів.

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

Вихід у реальний світ і зворотний зв’язок

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

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

Ці реальні дані:

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

Такий замкнений цикл «симуляція ? реальність ? симуляція» поступово звужує sim-to-real gap, роблячи поведінку системи стабільнішою й надійнішою в «брудному» реальному світі.

Від бітів до атомів: куди рухається фізичний ШІ

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

• на виробництві;
• на складах;
• у транспортній інфраструктурі.

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

Джерело

What is Physical AI? How Robots Learn & Adapt in Real Life — IBM Technology

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

Цей матеріал зосереджується саме на оптимізації сесій: як правильно обирати модель (Opus, Sonnet, Haiku), як використовувати службові команди на кшталт /model, /insights, /cost, /context та /compact, і чому контроль контексту стає критично важливим у довгих робочих сесіях.

Чому вибір моделі в Claude Code напряму впливає на гаманець і продуктивність

Claude Code дозволяє перемикатися між моделями за допомогою команди /model. Здавалося б, дрібниця, але саме тут більшість користувачів починають втрачати гроші й продуктивність. У стандартному наборі доступні три моделі: Opus, Sonnet і Haiku, і кожна з них має своє оптимальне застосування.

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

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

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

Ключова рекомендація для розробників, які працюють у Claude Code регулярно: свідомо обирати модель під конкретне завдання. Тримати Sonnet як базовий варіант, підключати Opus лише тоді, коли справді потрібен додатковий інтелектуальний «запас міцності», і використовувати Haiku для простих або масових операцій. Перемикання /model — це не косметична опція, а інструмент керування витратами й продуктивністю.

Як /insights перетворює ваш стиль роботи з AI на аналітичний звіт

Ще один маловідомий, але вкрай корисний інструмент у Claude Code — команда /insights. Вона генерує локальний HTML?звіт про те, як саме ви використовуєте Claude Code: які завдання ставите, як формулюєте запити, де модель допомагає ефективно, а де ви витрачаєте ресурси даремно.

Після запуску /insights Claude Code створює локальний файл, який можна відкрити у браузері, наприклад у Chrome. Усередині — не просто «лог сесій», а структурований аналітичний дашборд: графіки, діаграми, текстові пояснення, огляд сильних сторін вашої взаємодії з інструментом і типові помилки. Це свого роду «рев’ю» вашого стилю роботи з AI?асистентом.

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

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

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

У підсумку /insights — це спосіб подивитися на себе як на користувача AI?інструменту з боку. Для розробника, який хоче не просто «балакати з моделлю», а системно підвищувати власну продуктивність, це один із найцінніших вбудованих інструментів Claude Code.

Вартість, контекст і приховані інструменти: як /cost, /context і вимкнення MCP?тулів економлять токени

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

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

Набагато глибше зрозуміти, куди саме йдуть токени, дозволяє команда /context. Вона показує поточне використання контексту: скільки токенів уже зайнято, яка загальна місткість, який відсоток припадає на системний промпт, інструменти, навички (skills), повідомлення користувача та «вільний простір». У прикладі з гайду видно, як Claude Code показує, що вже використано 25 тисяч токенів із доступного мільйона, а також розкладає це по категоріях.

Особливо показовий блок із MCP?інструментами. Claude Code може підключати велику кількість MCP?серверів і тулів — від GitHub до Zapier. Але кожен підключений інструмент збільшує контекст, який модель має «тримати в голові». Якщо в сесії активні десятки тулів, якими ви фактично не користуєтеся, вони просто «роздувають» контекст, уповільнюють відповіді й збільшують витрати токенів.

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

Таким чином, /context — це не просто діагностичний екран, а інструмент для прийняття рішень: які інструменти залишити, які вимкнути, коли варто «очистити» історію, а коли — змінити модель на дешевшу. У поєднанні з /cost він дає розробнику контроль над тим, що зазвичай залишається «під капотом» LLM?сервісів.

/compact: як «очистити» історію, не втративши нитку розмови

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

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

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

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

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

Прихована інфраструктура Claude Code: .claude, рівні конфігурації та роль MCP

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

У кожному проєкті, де ви працюєте з Claude Code, інструмент автоматично створює приховану директорію .claude. Усередині зберігаються налаштування, специфічні для цього проєкту, зокрема файл settings.local.json. Саме сюди потрапляють конфігурації, які ви додаєте на рівні проєкту: наприклад, MCP?сервери, навички (skills) чи інші локальні параметри.

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

Наприклад, GitHub MCP?сервер, який дозволяє Claude Code автоматично створювати віддалені репозиторії та пушити туди код, логічно додати на глобальному (user) рівні, оскільки він корисний у більшості проєктів. Для цього використовується спеціальна команда додавання MCP?сервера з параметром -d-scope user. Якщо ж додати його лише на рівні поточного проєкту, він не з’явиться в інших сесіях, і доведеться повторювати налаштування.

Керувати MCP?серверами зсередини Claude Code допомагає команда /mcp. Вона показує список доступних серверів, їхній статус (увімкнені, вимкнені, вбудовані) й дозволяє швидко перевірити, чи правильно підключено, наприклад, той самий GitHub. Це знову ж таки впирається в контекст: чим більше глобальних інструментів ви підключаєте, тим уважніше потрібно стежити за тим, які з них реально використовуються в конкретній сесії.

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

Висновки: Claude Code як інструмент, яким потрібно вміти керувати

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

Перемикання моделей через /model дозволяє підібрати оптимальний баланс між потужністю й вартістю: Sonnet як базовий варіант, Opus для справді складних задач, Haiku для простих і довготривалих операцій. Команди /insights, /cost і /context дають прозору картину того, як ви працюєте з Claude Code, скільки це коштує й куди саме йдуть токени. Вимкнення непотрібних MCP?інструментів і використання /compact у потрібний момент допомагають утримувати контекст у розумних межах, не жертвуючи якістю роботи.

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

Джерело

The Ultimate Claude Code Guide | MCP, Skills & More — Tech With Tim

Коли інженер зі зберігання даних і дата-центрів переходить у світ стрімінгу подій, а потім опиняється в епіцентрі AI?революції в розробці, це вже не просто особиста історія. Це зріз того, як змінюється вся індустрія. Саме така траєкторія у Джозефа Морайса — нині Technical Champion у Confluent, ведучого шоу для техлідів “Life Is But a Stream” і одного з публічних облич дисципліни data streaming.

Розмова з ним прозвучала у Confluent Developer Podcast (колишній “Streaming Audio”) — подкасті, який еволюціонував разом із самим екосистемним поняттям “стрімінг даних”. На цьому тлі кар’єрний шлях Морайса, його погляд на керовані платформи, AI?асистентів і нові ролі розробників дає доволі точну карту того, куди рухається професія.

Витоки в залізі: SAN, дата?центри і погляд оператора

До того, як опинитися в Confluent, Джозеф працював SAN?адміністратором і оператором дата?центру. Це класичний “залізний” бекграунд: масиви зберігання, мережі, фізична інфраструктура, CLI, конфігурації, зміни вночі, коли вікно для простою мінімальне. Такий досвід формує дуже специфічний тип мислення — операторський.

Цей операторський погляд добре помітний у тому, як він сьогодні говорить про стрімінг даних і хмарні сервіси. Для людини, яка роками відповідала за стабільність і масштабування систем, “fully managed” — не маркетинговий штамп, а реальна відповідь на біль. Коли він описує, чому так відверто “pro?Confluent”, це не про бренд, а про те, що означає зняти з команди тягар експлуатації складної розподіленої системи.

Перехід із класичної інфраструктури до стрімінгу даних добре вкладається в ширший тренд: ролі, які раніше були прив’язані до “заліза” й on?prem, переформатовуються навколо керованих сервісів, хмарних платформ і подієвих архітектур. Історія Морайса — приклад того, як інженер, що починав із SAN, може опинитися в центрі нової дисципліни — data streaming engineering.

Technical Champion і “Life Is But a Stream”: як виглядає адвокація стрімінгу

Сьогодні Джозеф обіймає роль Technical Champion у Confluent. Формально це близько до класичного developer relations: робота з технічною спільнотою, публічні виступи, контент, демонстрації. Але є важливий нюанс: якщо частина DevRel?команди зосереджена на відкритому ПЗ — Apache Kafka, Apache Flink, інші проєкти Apache Software Foundation, — Морайс відкрито позиціонує себе як адвоката саме керованої платформи Confluent.

Це логічне продовження його операторського минулого. Для людини, яка знає, що означає самостійно розгортати, оновлювати й утримувати кластери, аргумент “fully managed and easy to deploy” — не абстракція. Він апелює до тих, хто любить технологію Kafka, але впирається в обмеження open source?інсталяцій: масштабування, відмовостійкість, відсутність певних enterprise?функцій. Саме з цією аудиторією він працює як Technical Champion, пояснюючи, де керована платформа знімає ризики й операційні витрати.

Окремий вимір його ролі — шоу “Life Is But a Stream”, орієнтоване на технічних лідерів, які приймають рішення щодо архітектури й технологічного стека. Це не контент “як підняти кластер”, а розмова про те, як стрімінг даних змінює бізнес?процеси, інтеграцію систем, аналітику в реальному часі. Фактично, це міст між світом інженерів і світом тих, хто визначає стратегію.

Той факт, що Confluent Developer Podcast сам пройшов ребрендинг — із “Streaming Audio” до “Confluent Developer Podcast” — теж показовий. Спочатку фокус був майже виключно на Kafka й стрімінгу як технології. Зараз це ширший простір: Kafka, Flink, хмара, реальні кейси, кар’єрні траєкторії. Екосистема виросла, і разом із нею змінилася рамка розмови.

Від on?prem до хмари — і тепер до AI: кар’єра як модель технологічних зсувів

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

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

Сьогодні такою точкою для нього стала поява сучасних AI?інструментів для розробки — зокрема Claude Code, до якого він отримав доступ уже в 2026?му і чесно визнає, що почувався майже лудитом, який запізнився на вечірку. Але ефект виявився тим самим, що й колись із контейнерами: повернення відчуття гри, експерименту, “технічної радості”.

Саме тут він проводить важливу аналогію. Перехід від on?prem до хмари радикально змінив ролі: частина класичних адміністраторів зникла або трансформувалася в SRE, cloud engineer, platform engineer. Тепер, на його думку, AI робить щось подібне з роллю розробника. Не обов’язково “скорочує” професію, але змінює її зміст.

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

Від CLI до “інтелектуального субстрату”: як AI змінює роботу з інструментами

Один із найконкретніших прогнозів Морайса стосується того, як розробники, інженери й дата?саєнтисти працюватимуть із SaaS?сервісами та CLI?інструментами. Замість того, щоб вивчати кожен CLI, його параметри, формати конфігурацій, він очікує появи стійкого “AI?посередника”.

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

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

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

Цей зсув добре видно на прикладі демо, яке Морайс будує, комбінуючи Claude і Confluent Cloud. Він описує, як, працюючи над демонстрацією, задав лише загальну рамку: потрібен сценарій у сфері гостинності, два продюсери, один консюмер, інтеграція з Flink. Решту — конкретні вхідні дані, логіку об’єднання подій, SMS?сповіщення — AI запропонував сам, побудувавши цілісну й осмислену історію.

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

Від задач до ідей: як AI змінює когнітивну модель інженера

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

З появою AI?асистентів він говорить про перехід від “objective?based” до “idea?based” мислення. Знаючи, що є “друзі?агенти” — Claude, Gemini чи інші — які можуть взяти на себе значну частину роботи з деталізацією цілей і реалізацією задач, інженер може довше залишатися на рівні ідей.

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

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

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

Confluent Developer як інфраструктура для нової дисципліни

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

Там зібрані безкоштовні курси, туторіали, гайд?старти й тематичні розбори по Apache Kafka, Apache Flink, Confluent Cloud і Confluent Platform. Це не просто документація, а структурований шлях: від перших кроків до складних патернів побудови реальних систем у реальному часі.

Ключовий елемент цієї екосистеми — безкоштовна онлайн?сертифікація Data Streaming Engineer на developer.confluent.io. Її поява означає, що стрімінг даних розглядається не як “ще одна навичка” у резюме, а як окрема професія зі своїм тілом знань, практиками й очікуваним рівнем компетенцій.

У поєднанні з тим, що сама платформа Confluent позиціонується як “data substrate” або “data plane” для систем реального часу, це створює цікаву паралель із тим, як Морайс описує AI?інструменти. Якщо Kafka, Flink і Confluent Cloud — це “субстрат даних”, на якому будуються подієві системи, то Claude, ChatGPT та інші моделі стають “інтелектуальним субстратом”, який можна “підключити” до ідеї.

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

Погляд уперед: як історія однієї кар’єри допомагає не загубитися в AI?перехід

Історія Джозефа Морайса — це не лише анекдот про високого Technical Champion’а, якому жартома “підібрали” відповідний титул. Це приклад того, як інженер може пройти через кілька хвиль технологічних зрушень — від фізичної інфраструктури до хмари, від хмари до стрімінгу даних, від стрімінгу до AI?асистованої розробки — і щоразу знаходити нову роль.

Його порівняння нинішнього AI?зсуву з попереднім переходом у хмару варто сприймати серйозно. Тоді зникли або радикально змінилися ролі, які здавалося вічними: класичні системні адміністратори, оператори дата?центрів. З’явилися SRE, cloud engineer, platform engineer. Сьогодні подібна трансформація чекає на розробників, data engineer’ів, аналітиків.

У цьому контексті важливо не стільки вивчити черговий інструмент, скільки зрозуміти нову модель: робота на рівні ідей, делегування задач AI?агентам, використання “інтелектуального субстрату” поверх “субстрату даних”. Платформи на кшталт Confluent, освітні ресурси Confluent Developer і формалізація ролі Data Streaming Engineer дають інфраструктуру для цієї адаптації.

Кар’єра Морайса показує, що перехід можливий: із SAN?адміністратора в Technical Champion’и стрімінгу даних і публічні обличчя нової дисципліни. Питання в тому, чи готові інші інженери побачити в нинішньому AI?зсуві не лише загрозу, а й чергову інфлексійну точку, яка відкриває нові ролі — так само, як колись це зробила хмара.

Джерело

The AI Impact on the Developer Future with Joseph Morais | Ep. 27 | Confluent Developer Podcast

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

Цей матеріал зосереджується саме на оптимізації сесій: як правильно обирати модель (Opus, Sonnet, Haiku), як використовувати службові команди на кшталт /model, /insights, /cost, /context та /compact, і чому контроль контексту стає критично важливим у довгих робочих сесіях.

Чому вибір моделі в Claude Code напряму впливає на гаманець і продуктивність

Claude Code дозволяє перемикатися між моделями за допомогою команди /model. Здавалося б, дрібниця, але саме тут більшість користувачів починають втрачати гроші й продуктивність. У стандартному наборі доступні три моделі: Opus, Sonnet і Haiku, і кожна з них має своє оптимальне застосування.

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

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

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

Ключова рекомендація для розробників, які працюють у Claude Code регулярно: свідомо обирати модель під конкретне завдання. Тримати Sonnet як базовий варіант, підключати Opus лише тоді, коли справді потрібен додатковий інтелектуальний «запас міцності», і використовувати Haiku для простих або масових операцій. Перемикання /model — це не косметична опція, а інструмент керування витратами й продуктивністю.

Як /insights перетворює ваш стиль роботи з AI на аналітичний звіт

Ще один маловідомий, але вкрай корисний інструмент у Claude Code — команда /insights. Вона генерує локальний HTML?звіт про те, як саме ви використовуєте Claude Code: які завдання ставите, як формулюєте запити, де модель допомагає ефективно, а де ви витрачаєте ресурси даремно.

Після запуску /insights Claude Code створює локальний файл, який можна відкрити у браузері, наприклад у Chrome. Усередині — не просто «лог сесій», а структурований аналітичний дашборд: графіки, діаграми, текстові пояснення, огляд сильних сторін вашої взаємодії з інструментом і типові помилки. Це свого роду «рев’ю» вашого стилю роботи з AI?асистентом.

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

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

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

У підсумку /insights — це спосіб подивитися на себе як на користувача AI?інструменту з боку. Для розробника, який хоче не просто «балакати з моделлю», а системно підвищувати власну продуктивність, це один із найцінніших вбудованих інструментів Claude Code.

Вартість, контекст і приховані інструменти: як /cost, /context і вимкнення MCP?тулів економлять токени

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

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

Набагато глибше зрозуміти, куди саме йдуть токени, дозволяє команда /context. Вона показує поточне використання контексту: скільки токенів уже зайнято, яка загальна місткість, який відсоток припадає на системний промпт, інструменти, навички (skills), повідомлення користувача та «вільний простір». У прикладі з гайду видно, як Claude Code показує, що вже використано 25 тисяч токенів із доступного мільйона, а також розкладає це по категоріях.

Особливо показовий блок із MCP?інструментами. Claude Code може підключати велику кількість MCP?серверів і тулів — від GitHub до Zapier. Але кожен підключений інструмент збільшує контекст, який модель має «тримати в голові». Якщо в сесії активні десятки тулів, якими ви фактично не користуєтеся, вони просто «роздувають» контекст, уповільнюють відповіді й збільшують витрати токенів.

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

Таким чином, /context — це не просто діагностичний екран, а інструмент для прийняття рішень: які інструменти залишити, які вимкнути, коли варто «очистити» історію, а коли — змінити модель на дешевшу. У поєднанні з /cost він дає розробнику контроль над тим, що зазвичай залишається «під капотом» LLM?сервісів.

/compact: як «очистити» історію, не втративши нитку розмови

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

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

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

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

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

Прихована інфраструктура Claude Code: .claude, рівні конфігурації та роль MCP

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

У кожному проєкті, де ви працюєте з Claude Code, інструмент автоматично створює приховану директорію .claude. Усередині зберігаються налаштування, специфічні для цього проєкту, зокрема файл settings.local.json. Саме сюди потрапляють конфігурації, які ви додаєте на рівні проєкту: наприклад, MCP?сервери, навички (skills) чи інші локальні параметри.

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

Наприклад, GitHub MCP?сервер, який дозволяє Claude Code автоматично створювати віддалені репозиторії та пушити туди код, логічно додати на глобальному (user) рівні, оскільки він корисний у більшості проєктів. Для цього використовується спеціальна команда додавання MCP?сервера з параметром -d-scope user. Якщо ж додати його лише на рівні поточного проєкту, він не з’явиться в інших сесіях, і доведеться повторювати налаштування.

Керувати MCP?серверами зсередини Claude Code допомагає команда /mcp. Вона показує список доступних серверів, їхній статус (увімкнені, вимкнені, вбудовані) й дозволяє швидко перевірити, чи правильно підключено, наприклад, той самий GitHub. Це знову ж таки впирається в контекст: чим більше глобальних інструментів ви підключаєте, тим уважніше потрібно стежити за тим, які з них реально використовуються в конкретній сесії.

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

Висновки: Claude Code як інструмент, яким потрібно вміти керувати

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

Перемикання моделей через /model дозволяє підібрати оптимальний баланс між потужністю й вартістю: Sonnet як базовий варіант, Opus для справді складних задач, Haiku для простих і довготривалих операцій. Команди /insights, /cost і /context дають прозору картину того, як ви працюєте з Claude Code, скільки це коштує й куди саме йдуть токени. Вимкнення непотрібних MCP?інструментів і використання /compact у потрібний момент допомагають утримувати контекст у розумних межах, не жертвуючи якістю роботи.

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

Джерело

The Ultimate Claude Code Guide | MCP, Skills & More — Tech With Tim

У сучасній розробці програмного забезпечення якість коду часто важливіша за кількість написаних рядків. Канал Tech With Tim нагадує про один із базових, але критично важливих принципів — Single Responsibility Principle (SRP), або принцип єдиної відповідальності. Це правило напряму впливає на зрозумілість, тестованість і гнучкість будь-якого коду — від навчальних пет-проєктів до комерційних систем.

Що таке принцип єдиної відповідальності

Single Responsibility Principle стосується класів і функцій: кожен елемент коду має відповідати лише за одну чітко визначену задачу.

Ідея проста:

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

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

Як виглядає порушення SRP на практиці

Типовий приклад — функція process_orders, яка:

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

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

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

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

Рефакторинг: розбиваємо на малі, зрозумілі функції

Виправлення такої ситуації не потребує складних патернів — достатньо винести окремі операції в малі функції. Наприклад:

• is_order_fulfillable(order) — перевірка, чи можна виконати замовлення;
• update_inventory(order) — оновлення залишків;
• generate_receipt(order) — створення чеку;
• print_processing_status(order) — вивід інформації про обробку.

Після такого розбиття основна функція process_orders перетворюється на читабельний «сценарій»:

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

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

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

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

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

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

Джерело

This is the MOST important coding principle. — Tech With Tim

Фінансова грамотність часто здається закритим клубом із власним жаргоном, дорогими консультантами й правилами, які «знають усі, крім мене». У виступі на TEDNext 2025 фінансова освітниця та колишня трейдерка з Волл-стріт Вівіан Ту (канал YourRichBFF) ділиться підходами, які допомогли їй пройти шлях від приниження через «картка відхилена» до побудови кар’єри у сфері фінансової освіти. Її досвід лягає в три прості, але системні кроки: вивчити «мову грошей», створити спільноту навколо теми фінансів і користуватися сучасними інструментами замість застарених порад.

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

Фінанси справді нагадують вивчення нової мови: 401(k), IRA, 529, FICO, APY, AGI — для більшості це набір незрозумілих абревіатур. Водночас саме незнання термінів часто тримає людей у стані постійного стресу через гроші, навіть якщо вони мають престижну роботу.

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

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

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

Показовий підхід — пояснювати складні процеси через яскраві образи: наприклад, жартівливо називати голову ФРС США «Fed Daddy», щоб пояснити, як зниження ставок впливає на кредити й заощадження, або розбирати, як зірки на кшталт Кендрика Ламара будують і зберігають капітал. Коли мова стає ближчою до повсякденного життя, фінансові рішення перестають бути «чорною скринькою».

2. Гроші як тема для розмови: чому спільнота важливіша за «таємницю зарплати»

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

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

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

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

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

3. Сучасні проблеми — сучасні фінансові інструменти

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

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

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

Натомість з’являється нова інфраструктура:

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

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

Один із прикладів — побудова застосунку, який поєднує:

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

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

Фінансова грамотність як інфраструктура для меншої нерівності

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

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

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

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

Джерело

3 Things I Wish I Knew When I Was Broke | Vivian Tu | TED

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

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

Від «чату з кодом» до повноцінного агента в проєкті

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

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

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

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

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

Три обличчя Claude Code: десктоп, редактор і CLI

Anthropic пропонує три основні способи роботи з Claude Code: через офіційний десктоп?додаток, через плагін до редактора коду (наприклад, розширення для VS Code) та через CLI у терміналі. Формально це один і той самий «двигун», але інтерфейси дають різний рівень контролю і глибини інтеграції.

Десктоп?додаток: хмарний сценарій через GitHub

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

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

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

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

Плагін для редактора: компроміс між зручністю і потужністю

Другий варіант — інтеграція Claude Code безпосередньо в редактор коду. У прикладі з відео використовується Antigravity (форк VS Code), але принцип той самий для будь?якого сумісного редактора: у розділі розширень встановлюється плагін Claude Code for VS Code, після чого у верхній частині інтерфейсу з’являється кнопка виклику агентського вікна.

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

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

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

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

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

Встановлення виглядає максимально просто: на сайті Claude публікується одна команда інсталяції, яку потрібно скопіювати, вставити в будь?який термінал і виконати. Це може бути стандартний термінал macOS чи Windows або сторонній, як у прикладі з Warp. Після короткого процесу інсталяції у вікні з’являється повідомлення «Installation Complete» — Claude Code CLI готовий до роботи.

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

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

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

Як Claude Code працює з файлами та дозволами в CLI

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

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

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

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

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

У прикладі з відео агенту дають завдання створити тестовий файл README. Claude Code формує запит, пояснює, що збирається зробити, чекає підтвердження, після чого створює файл. Далі цей файл уже можна згадувати через «@», редагувати, доповнювати, просити AI переписати опис проєкту тощо. У терміналі, якщо використовується такий інструмент, як Warp, зручно одразу бачити файлову структуру і перевіряти, що саме з’явилося в директорії.

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

Моделі Haiku, Sonnet і Opus: який «двигун» обрати для свого проєкту

Під капотом Claude Code може працювати на різних моделях Anthropic. У CLI це налаштовується через команду \model, яка відкриває список доступних варіантів. Метафора, яку використовує автор, — це «двигун в автомобілі»: кузов (агентська оболонка Claude Code) залишається тим самим, але двигун може бути швидшим, потужнішим або економнішим.

Підтримуються три основні сімейства моделей: Haiku, Sonnet і Opus.

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

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

Sonnet займає проміжне положення і фактично є «робочою конячкою» Claude Code. Розробники інструменту рекомендують використовувати Sonnet для близько 90% щоденних завдань розробки як баланс між можливостями і вартістю. Як і Opus, Sonnet доступний у стандартному варіанті та з 1?мільйонним контекстом, що дає гнучкість залежно від розміру проєкту і характеру задач.

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

Чому саме Claude Code залишився в щоденному стеку

На ринку вже є чимало AI?асистентів для розробників — від вбудованих у IDE підказок до окремих агентів, що працюють через API. Попри це, автор відео наголошує, що після численних експериментів саме Claude Code став єдиним інструментом, який залишився в його щоденній роботі.

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

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

По?друге, гнучкість інтерфейсів. Можливість обрати між десктоп?додатком, плагіном до редактора і CLI дозволяє підлаштувати інструмент під власний стиль роботи. Хтось віддає перевагу візуальному контролю в IDE, хтось — швидкості й потужності терміналу. При цьому саме CLI дає максимальний контроль і розкриває повний потенціал Claude Code.

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

По?четверте, природна взаємодія. Claude Code приймає звичайні текстові запити, дозволяє посилатися на файли через «@», має власне меню команд через «\». Це поєднання природної мови і структурованих інструментів робить роботу з ним схожою на діалог із колегою, який одночасно вміє виконувати конкретні технічні дії.

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

Висновок: AI, який живе в репозиторії, а не в браузерній вкладці

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

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

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

Джерело

Claude Code — повний огляд від А до Я | Все що потрібно знати

Швидке впровадження інструментів на кшталт Claude Code радикально змінює баланс сил усередині продуктових команд. Інженери отримують кратне зростання продуктивності, тоді як продакт-менеджери (PM) та дизайнери змушені працювати з дедалі більшим «віртуальним» інженерним штатом — без формального розширення команд. Це ставить під сумнів не стільки потребу в PM, скільки їхню кількість та роль. На ці зміни звертають увагу учасники подкасту Lenny’s Podcast, де обговорюють, як AI переформатовує роботу продуктових команд.

Як AI змінює структуру типової продуктової команди

Класична конфігурація команди: п’ять інженерів, один дизайнер і один продакт-менеджер. З появою інструментів на кшталт Claude Code продуктивність інженерів зростає вдвічі-тричі. Фактично це означає, що ті ж п’ять розробників працюють так, ніби їх уже 10–15.

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

У підсумку виникає нова «дефолтна» реальність: умовні 15–20 інженерів на двох PM і двох дизайнерів — навіть якщо в штатному розписі цифри залишилися старими.

Чому PM та дизайн опиняються «затиснутими»

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

Це створює асиметрію:

• Інженери можуть реалізовувати більше фіч, запускати більше експериментів, швидше ітеративно змінювати продукт.
• PM і дизайнери змушені координувати вже не умовних п’ятьох, а фактично команду, що працює як 15–20 інженерів.

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

Чи означає це, що PM стає більше, а не менше?

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

Команди стикаються з тим, що:

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

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

Новий баланс ролей у командах з AI

AI не скасовує ролі продакт-менеджера — він змінює контекст, у якому ця роль працює:

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

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

Джерело

Do we still need PMs? – Lenny’s Podcast