Урок 0: робоче середовище для розробки.

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

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

Цільова аудиторія курсу - розробники з досвідом:

• фронтенд;
• бекенд;
• DevOps;
• суміжні напрями.

Курс не для початківців. Мінімальний рівень такий:

• ви пишете код;
• ви читаєте чужий код;
• ви запускаєте код і знаходите в ньому помилки.

Інші знання ви отримаєте під час курсу.

Мінімум для уроків

Кожен урок курсу - це один Python-файл. Файл не залежить від інших файлів курсу. Робота з уроком має 4 кроки:

1. Завантажте файл.
2. Запустіть файл.
3. Зламайте агента.
4. Виправте агента.

Курс не використовує фреймворки. Курс використовує тільки SDK anthropic. Тому для роботи достатньо 5 команд:

python3 --version                          # версія 3.11 або новіша
python3 -m venv .venv && source .venv/bin/activate
pip install anthropic
export ANTHROPIC_API_KEY=sk-...            # ключ з console.anthropic.com
python lesson-1-orchestrator.py

Моє налаштування Claude Code

Я рекомендую такий перший крок після встановлення Claude Code: перевірте всі підключені плагіни, скіли і MCP-сервери. Мій підхід простий. Вимкніть усе.

Кожен увімкнений плагін додає контекст у кожну сесію. Також плагін дає можливості, якими ви не керуєте. Після цього увімкніть тільки ті інструменти, які ви використовуєте. У мене таких інструментів 3:

Також я використовую 2 необов’язкові зручності:

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

Ще я використовую текстовий редактор, у якому мені зручно робити рев’ю коду. Це весь базовий мінімум для розробки.

Одне правило важливіше за все середовище

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

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

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

Тести без шуму

Друга частина фільтра якості - верифікація. Ваш проєкт повинен мати тести. Ці тести повинні мати високу якість.

Типова помилка юніт-тестів від моделі - шум. Шумний тест має такі ознаки:

• мок на логер;
• мок на телеметрію в Datadog;
• моки на всю observability;
• фабрика на пів екрана;
• в кінці тест перевіряє, що код викликав логер 1 раз.

# шум: тест перевіряє моки, а не поведінку
def test_calc_discount(monkeypatch):
    monkeypatch.setattr("app.obs.datadog", Mock())
    monkeypatch.setattr("app.log.logger", Mock())
    svc = ServiceFactory().with_db(FakeDB()).with_cache(FakeCache()).build()
    svc.calc_discount(price=10.0, plan="pro")
    app.log.logger.info.assert_called_once()

# поведінка: вхід -> вихід, і більше нічого
def test_calc_discount():
    assert calc_discount(price=10.0, plan="pro") == 8.5

Для тесту діє те саме правило, що й для рев’ю. Тест перевіряє значення, які повертає код. Тест не перевіряє факт виклику логера.

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

Еволюція вимог

Робоче середовище проходить цикл v1 -> v2. У наступних уроках кожен агент проходить такий самий цикл:

1. Ви робите наївну версію.
2. Ви знаходите проблеми.
3. Ви доповнюєте вимоги.

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