Карта поверхонь і робочого процесу курсу

1. У Claude Code не один екран, а декілька

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

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

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

2. Курс стартує з terminal-first

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

Візьмімо навчальний репозиторій Commerce OS: замовлення, підтримка, платежі, аналітика. Запустивши Claude з терміналу в корені, ви даєте сигнал: ось робочий простір, ось межі. Це не браузерний чат, де ви переказуєте проєкт: «там десь сервіс замовлень, а файл, здається, на літеру O…».

cd commerce-os   # переходимо до репозиторію проєкту
claude           # запускаємо Claude Code всередині цієї папки

Нічого хакерського — і це плюс. Claude не вгадує, де проєкт, він і так стоїть усередині.

Terminal-first не означає terminal-only. IDE не заборонена. Каркас роботи ми збираємо навколо запуску через термінал, інші поверхні додаємо там, де вони корисні.

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

3. IDE поруч, а не замість

Тут легко піти в хибний вибір: або «все тільки в терміналі», або «навіщо CLI, коли є вікно з кнопками». Обидва слабкі. IDE — не заміна Claude Code, а поверхня перевірки: читати реальні файли, бачити діапазони рядків, дивитися diff поруч із кодом, помічати, що саме змінилося.

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

Термінал запускає процес. IDE перевіряє результат. Claude щось запропонував — дивіться у файлі та в diff, а не тільки в тексті.

4. Workflow курсу: від проєкту до артефакту

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

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

Саме в цій послідовності Claude Code перестає бути генератором сюрпризів.

Головне — остання ланка. Спокуса думати про ШІ як про скорочення шляху: «Claude відповів — задача вирішена». Думайте інакше: Claude дав матеріал для рішення, не саме рішення. Фінальна точка — не «готово» від моделі, а момент, коли результат можна показати колезі.

Звідси PR-ready artifact: зміни в стані, коли їх можна віддати на ревʼю. Відкривати pull request прямо зараз не потрібно — але код, diff, результати перевірок і опис уже готові до чужих очей. Навіть якщо працюєте самі: код, який соромно показати колезі, і самому приймати рано.

Той самий маршрут коротше:

Термінал → проєкт → зміни → IDE → перевірки → рішення людини

Термінал — старт і контекст. Git — страховка й історія. IDE — видимість. Перевірки — докази. Людина — останній фільтр. Приберіть ланку — процес хитається. Особливо якщо це читання diff.

5. Поверхні, які знаємо, але не вмикаємо одразу

Новий інструмент будить порив: «раз є desktop, web, remote, Slack, CI, mobile, хмара — відкрию все одразу». Зрозуміло й невигідно. На старті достатньо знати, що ці поверхні існують, не тягнучи їх у базовий процес. Інакше замість робочої схеми вийде екскурсія інтерфейсами.

Поверхні не другорядні: CI та командні сценарії в GitHub реально прискорюють команду. Але поки не усталилася ланка «проєкт → diff → перевірки → рішення», зайве не допомагає, а шумить.

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

6. Робочий день у Commerce OS: ланцюжок поверхонь

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

commerce-os/
  orders/
  payments/
  support/
  dashboard/

Ви заходите в проєкт через термінал, запускаєте Claude і просите знайти, де в модулі orders живе логіка сортування. Claude дивиться на реальну папку commerce-os, не на переказ. Показав файли або запропонував правку — переходите в IDE і дивитеся очима: метод може жити не в тому сервісі, поруч може бути схожа логіка, правка може зачепити зайвий файл.

Робиться правка — не «повірити на слово», а перевірити diff і поведінку. Навіть у крихітному сценарії корисний формат:

Змінено:
- orders/OrderService.java

Перевірено:
- список замовлень відкривається
- нові замовлення відображаються зверху

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

Зведете все в одну точку входу — процес деформується. Тільки термінал — важче контролювати зміни очима. Тільки IDE без запуску Claude — втрачається звʼязок із робочим контекстом. Тільки веб — переказуєте проєкт замість роботи з ним. Тільки Slack — активність без інженерної опори.

Workflow курсу спокійний саме тому, що розставляє поверхні за ролями. Термінал запускає роботу зсередини проєкту. IDE заземлює зміни. Перевірки підтверджують результат. Людина вирішує.

7. Решта стека: Java, Gradle і Python

У попередній лекції ми поставили два «квитки на вхід» — Git і Node.js. Руками й заздалегідь: без Git не збирається workflow, Node.js страхує встановлення CLI. Тепер — решта стека: Java (JDK), Gradle і Python. Підхід тут інший.

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

Чому. Git і Node.js потрібні до появи CLI — інакше їх нікому поставити. А Java, Gradle і Python потрібні для роботи над проєктом, до цього моменту CLI вже буде. Встановлення перетворюється на реальну задачу: ви бачите, як агент ставить інструмент, перевіряє версію, за потреби виправляє оточення. Корисніше, ніж мовчки скопіювати команду з гайда.

Окремо про Gradle, бо тут легко заплутатися. У реальному Java-проєкті збирання запускають не глобальною командою gradle, а через Gradle Wrapper — скрипт ./gradlew (або gradlew.bat на Windows), який лежить прямо в репозиторії. Wrapper сам завантажує і використовує ту версію Gradle, яка прописана в проєкті. Це гарантує, що в усіх учасників команди збирання йде однією й тією самою версією, незалежно від того, що в кого встановлено глобально.

Тоді навіщо взагалі ставити Gradle глобально? Рівно для одного сценарію: створити Wrapper у новому проєкті з нуля (gradle wrapper). Після цього ви перемикаєтеся на ./gradlew і про глобальний Gradle забуваєте. Тобто глобальне встановлення — це «стартер» для нових проєктів, а повсякденна робота в готовому проєкті йде через Wrapper. Запамʼятайте це одразу, щоб не зловити класичну плутанину «в мене глобально одна версія, а проєкт хоче іншу»: у готовому проєкті версію диктує Wrapper, а не ваше глобальне встановлення.

Варіант А: поставити руками зараз

Команди за операційними системами. Та сама застережність про version-resilience: точні рядки звіряйте з офіційною документацією, версії підбирайте під актуальну LTS.

# macOS — через Homebrew
brew install openjdk        # JDK (Java)
brew install gradle         # Gradle (глобально, для bootstrap нових проєктів)
brew install python         # Python 3

# Linux — через менеджер пакетів
sudo apt install default-jdk gradle python3   # Debian / Ubuntu
sudo dnf install java-latest-openjdk gradle python3   # Fedora / RHEL

# Windows — через winget
winget install --id EclipseAdoptium.Temurin.25.JDK
winget install --id Gradle.Gradle
winget install --id Python.Python.3.13

Перевірка після встановлення (у новому вікні терміналу):

java -version            # наприклад: openjdk version "25"
gradle -version          # наприклад: Gradle 9.5.x
python3 --version        # наприклад: Python 3.13.x

Варіант Б: попросити Claude Code

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

Перевір, чи встановлені на моїй машині JDK, Gradle і Python 3.
Чого не вистачає — постав через мій менеджер пакетів (Homebrew),
після встановлення покажи версії: java -version, gradle -version, python3 --version.

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

Який би варіант ви не обрали, підсумок один: до моменту, коли почнеться змістовна робота над Commerce OS, на машині мають спокійно відповідати java -version, gradle -version і python3 --version. А як саме вони туди потрапили — руками чи силами агента — уже справа смаку.