Claude Code: agentic середовище для програмування

1. Сьогодні перший день вашого нового життя

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

Наш курс із Claude Code — це швидкий вхід у AI-native розробку. Тут ви навчатиметеся працювати з ШІ як з інженерним важелем: формулювати мету, спрямовувати хід роботи, отримувати план, запускати зміни, перевіряти підсумок і збирати працюючий результат. Крок за кроком ви почнете робити те, що раніше здавалося доступним лише найсильнішим розробникам 🧠.

Claude Code робить вас сильнішими, розумнішими. Він робить вас кращими 🔥.

Саме цьому присвячено курс: ви будете опановувати нову роль розробника — не людини, яка просто пише код руками, а інженера, який уміє керувати розробкою разом із ШІ. Сьогодні ви робите перший крок у AI-native розробку. Попереду будуть завдання, помилки, відкриття й перші перемоги. І колись ви усвідомите: «Тепер я можу усе». 🏆

2. Claude Code — це не чат у терміналі

Як усі уявляють Claude Code? Як «ще одного чат-бота, тільки в терміналі»? Образ зрозумілий — і дуже далекий від істини. Поки ви так думатимете — ви нічого не навчитеся.

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

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

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

Цю різницю зручно побачити в одній таблиці:

І ось тут з’являється перша важлива формула курсу. Її варто буквально тримати в голові вже з цієї лекції:

Claude пришвидшує інженерну роботу, але за результат усе одно відповідаєте ви.

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

3. Що означає «діє»

Слово agentic іноді звучить так, ніби його вигадали маркетологи після третьої чашки кави. Але за ним стоїть цілком практичний зміст. Claude Code не просто пише красивий текст про код, а може виконувати обмежені дії всередині робочого середовища. Саме це перетворює взаємодію зі ШІ з листування на інженерний процес, де вже важливі межі, перевірка й дисципліна.

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

Уявіть інтернет-магазин Commerce OS. У ньому є модуль повернень, черга заявок підтримки й логіка, яка визначає, які звернення оператор бачить першими. Припустімо, менеджер помічає проблему: термінові заявки на повернення іноді опиняються нижче за звичайні. У звичайному чаті із ШІ ви б скопіювали шматок методу, лог помилки або опис проблеми й запитали: «Як думаєш, що не так?» Це корисно, але чат і далі залишається поза проєктом.

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

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

Claude: «Знайшов сервіс сортування, пов’язаний контролер і тест.
Пропоную спочатку перевірити правило сортування, потім показати diff.»

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

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

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

4. Один рядок змінює логіку роботи

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

Припустімо, у Commerce OS була така логіка: термінову заявку на повернення піднімаємо нагору.

if (refundRequest.isUrgent()) {
    moveToTop(refundRequest);
}

А потім Claude Code запропонував або навіть уніс таку правку:

if (refundRequest.isUrgent() || refundRequest.amount() > 100) {
    moveToTop(refundRequest);
}

Виглядає невинно? Лише одна додана частина умови. Але фактично поведінка системи змінилася. Тепер нагору піднімаються не лише термінові повернення, а й усі повернення на велику суму. Можливо, це добра ідея. А можливо, це зовсім інше бізнес-правило, яке ніхто не просив запроваджувати. Ось чому у звичайному чаті із ШІ така правка була б просто порадою в тексті, а в Claude Code вона вже стає реальною зміною поведінки.

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

Саме тому погане формулювання завдання у звичайному чаті із ШІ найчастіше дає погану відповідь.

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

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

5. Базовий цикл роботи

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

Схема виглядає так:

flowchart TD
    A[Завдання від розробника] --> B[Claude вивчає контекст]
    B --> C[Пропонує план або невелику зміну]
    C --> D[Розробник читає diff]
    D --> E[Запускаються перевірки]
    E --> F[Людина ухвалює рішення]

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

Наступний крок — читання diff, тобто списку змін. Після цього запускаються перевірки. Якщо ви лише починаєте програмувати, корисно не лякатися слів. Tests — це автоматичні перевірки поведінки. Build — перевірка, що проєкт узагалі збирається. Lint — перевірка на технічні та стилістичні проблеми в коді. Іноді ще роблять простий пробний запуск ключового сценарію, щоб переконатися, що система хоча б не розсипалася одразу після правки. Усе це потрібно не для краси, а щоб відповісти на просте запитання: зміна справді працює так, як ми очікували, чи нам просто хочеться в це вірити?

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

Ви: «Виправте порядок відображення повернень. Спочатку покажіть план.»

Claude: «Знайшов 3 пов’язані файли. Пропоную змінити правило сортування
і перевірити наявний тест на чергу повернень.»

Ви: «Добре. Покажіть diff після зміни та що саме перевірити.»

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

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

6. Діяти й відповідати — не одне й те саме

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

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

Цю межу зручно побачити так:

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

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

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

7. Вивчайте принцип, а не команди

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

Якщо тримати в голові лише список команд, то будь-яке оновлення продукту відчувається як маленький землетрус. Учора команда називалася так, сьогодні інакше, в когось інший інтерфейс, чиєсь зображення вже застаріло — і все, здається, що ґрунт пішов з-під ніг. А якщо тримати в голові основну ідею, усе спокійніше. Ви розумієте, що Claude Code — це дієвий помічник усередині проєкту. Він працює з кодовою базою, може пропонувати й уносити зміни, а отже, вам потрібні завдання, межі, diff і перевірка. Як саме називається кнопка або команда, — уже друге питання.

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

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

8. Середовище до Claude Code: Git і Node.js

А тепер трохи практики. Перш ніж ми дійдемо до встановлення самого Claude Code, на машині мають жити дві речі: Git і Node.js. Їх ми встановлюємо вручну й заздалегідь, ще до CLI. Звучить як зайвий крок, але це саме той випадок, коли пʼять хвилин підготовки економлять годину подиву пізніше.

Чому саме ці два інструменти й саме до Claude Code?

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

Node.js — це страховка встановлення самого Claude Code. Як ви побачите в третій лекції, у CLI є кілька шляхів встановлення, і один із них — через npm (пакетний менеджер Node.js). Якщо основний спосіб встановлення на вашій машині раптом не спрацює — а на Windows і на корпоративних машинах це зовсім не рідкість — наявність Node.js дає вам запасний шлях поставити CLI через npm або швидко спробувати через npx. Плюс Node.js знадобиться далі по курсу для фронтенд-частини навчального проєкту. Тобто це не разова страховка, а інструмент, який усе одно згодиться.

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

Git за операційними системами

# macOS — через Homebrew (або встановиться разом із Command Line Tools)
brew install git
# або, якщо Homebrew немає:
xcode-select --install

# Linux — через пакетний менеджер дистрибутива
sudo apt install git        # Debian / Ubuntu
sudo dnf install git        # Fedora / RHEL

# Windows — через winget (або інсталятор із git-scm.com)
winget install --id Git.Git

Node.js за операційними системами

Усюди беріть версію з позначкою LTS (Long-Term Support) — це стабільна гілка, на яку розраховано більшість інструментів. Гнатися за найсвіжішою нестабільною версією на старті немає сенсу.

# macOS — через Homebrew
brew install node

# Linux — рекомендовано через nvm (Node Version Manager),
# щоб версії Node жили в домашньому каталозі, а не в системних директоріях
# встановлення nvm дивіться в його офіційному репозиторії, потім:
nvm install --lts

# Windows — через winget (або інсталятор із nodejs.org)
winget install --id OpenJS.NodeJS.LTS

Перевірка, що все на місці

Після встановлення відкрийте нове вікно термінала (це важливо — PATH оновлюється не в поточній сесії, а в новій) і виконайте три короткі перевірки:

git --version          # наприклад: git version 2.47.x
node --version         # наприклад: v24.x.x  (LTS)
npm --version          # наприклад: 11.x.x

Якщо всі три команди вивели версію без помилок — базове середовище готове, і в третій лекції можна спокійно переходити до встановлення самого Claude Code. Якщо якась команда відповідає command not found — майже завжди річ у тому, що термінал не перезапущено після встановлення. Це той самий сигнал PATH, який ми докладно розберемо на прикладі Claude Code. Логіка всюди одна: інструмент встановлено, але shell ще не знає, де його шукати.

Коли ви вперше відкриєте проєкт типу Commerce OS і побачите поруч не просто вікно переписки, а дієвого помічника з доступом до коду, корисно згадати саме цей стан: спокій, межі та відповідальність. Саме з такого ставлення й починається доросла розробка з підтримкою ШІ.