Claude Certified Architect — Підготовка до екзамену (UA)

1.1 Огляд екзамену

Модуль 1 · Вступ до сертифікації

Уявіть: ви щойно побудували складну систему на Claude — з агентами, інструментами, MCP-серверами. Все працює. Клієнт задоволений. І тут колега питає: «А у тебе є сертифікація?» Ось для цього і існує Claude Certified Architect.

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

Що таке Claude Certified Architect?

Claude Certified Architect — Foundations — це офіційна сертифікація від Anthropic, яка підтверджує вашу здатність проєктувати, будувати та оптимізувати production-grade рішення на базі Claude. Це не теоретичний тест для студентів — це практичний екзамен для людей, які вже працюють з Claude API, Agent SDK і Claude Code.

Цільовий кандидат — solution architect з 6+ місяцями реального досвіду. Якщо ви хоча б раз побудували agentic workflow, налаштували MCP-сервер або написали CLAUDE.md для команди — ви вже на правильному шляху.

Доступ та вартість

Ексклюзив для Anthropic Partners — потрібно бути співробітником партнерської компанії
Безкоштовно для перших 5 000 співробітників партнерів (Early Access)
Після Early Access — $99
Не партнер Anthropic? Подати заявку на партнерство →

Формат: 60 питань за 120 хвилин

Давайте розберемо формат, щоб не було сюрпризів у день екзамену:

Параметр	Значення
Кількість питань	60 питань multiple choice
Тривалість	120 хвилин (2 години)
Формат	Прокторований — без перерв, без зовнішніх ресурсів
Тип питань	Multiple choice (одна правильна відповідь з 4 варіантів)
Прохідний бал	720 з 1000 (scaled scoring)
Штраф за неправильну відповідь	Немає — завжди відповідайте!
Сценарії	6 сценаріїв, з яких 4 випадкових на екзамені
Результати	Протягом 2 робочих днів з детальним розбором по секціях

Пастка на екзамені

Немає штрафу за неправильну відповідь! Ніколи не залишайте питання без відповіді. Навіть якщо не впевнені — виберіть найбільш вірогідний варіант. Порожня відповідь гарантовано дає 0 балів, а вгадування — 25% шанс на правильну.

5 доменів: карта знань архітектора

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

Agentic Architecture27% — найбільша вага

Claude Code Config20%

Prompt Engineering20%

Tool Design & MCP18%

Context & Reliability15%

Ваги 5 доменів на екзамені (загалом 100%)

Ключове для екзамену

Домен 1 (Agentic Architecture) має найбільшу вагу — 27%. Це більше ніж чверть вашого балу. Навіть якщо ви ідеально знаєте всі інші домени, провал у агентній архітектурі може коштувати вам сертифікації. А Домен 5 (15%) — найлегший за вагою, але часто має найскладніші питання.

6 сценаріїв: реальний світ на екзамені

Екзамен — не абстрактна теорія. Він побудований навколо 6 реальних сценаріїв, з яких випадково обираються 4 для вашого конкретного екзамену:

Customer Support Agent — AI-агент підтримки з маршрутизацією, ескалацією та CRM-інтеграцією
Code Generation з Claude Code — налаштування CLAUDE.md, commands, skills для команди
Multi-Agent Research — оркестрація кількох агентів для збору та аналізу даних
Developer Productivity — code review, рефакторинг, автоматизація через Claude Code
CI/CD Integration — Claude у pipelines: review, тестування, генерація документації
Structured Data Extraction — витягування даних з документів, batch processing, валідація

Пастка на екзамені

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

Стратегія балів: де інвестувати час

Бал формується на основі правильних відповідей, зважених відповідно до домену. Мінімальний прохідний бал — 720 з 1000. Якщо ви сильні у Домені 1 (27%), це дає значно більший внесок у підсумковий бал, ніж досконалість у Домені 5 (15%). Але не ігноруйте жоден домен — кожен бал рахується.

Протягом цього курсу ми будемо використовувати наскрізний приклад — OrderBot, AI-асистент для e-commerce стартапу «FreshMart». Він допомагає клієнтам з замовленнями, обробляє повернення, і відповідає на питання. Ви побачите OrderBot у кожному модулі — від агентних циклів до CI/CD.

Перевірка знань

Який домен має найбільшу вагу на екзамені Claude Certified Architect?

A) Tool Design & MCP Integration (18%) B) Agentic Architecture & Orchestration (27%) C) Claude Code Configuration (20%) D) Prompt Engineering & Structured Output (20%)

Правильно — B! Agentic Architecture & Orchestration має найбільшу вагу — 27%. Це означає, що більш ніж чверть вашого балу залежить від розуміння агентних циклів, мульти-агентної оркестрації та воркфлоу-патернів.

Практична вправа

Розрахуйте: якщо ви відповіли правильно на 90% питань з Домену 1 (27%), 80% з Домену 3 (20%), 70% з Домену 4 (20%), 75% з Домену 2 (18%) і 60% з Домену 5 (15%), чи пройдете ви екзамен? Порахуйте зважений бал.

Розрахунок:
Домен 1: 0.90 × 270 = 243
Домен 2: 0.75 × 180 = 135
Домен 3: 0.80 × 200 = 160
Домен 4: 0.70 × 200 = 140
Домен 5: 0.60 × 150 = 90
Разом: 243 + 135 + 160 + 140 + 90 = 768 з 1000
Так, ви пройдете екзамен (768 > 720). Зверніть увагу: навіть 60% у Домені 5 не заважає пройти, якщо інші домени сильні. Але якби Домен 1 був 70% замість 90%, ваш бал упав би до 714 — і ви б не пройшли.

1.2 Стратегія підготовки

Модуль 1 · Вступ до сертифікації

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

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

8 рекомендацій з офіційного Exam Guide

Anthropic прямо каже: «Hands-on experience is essential.» Ось 8 порад, які вони дають, з нашими практичними коментарями:

1. Пройдіть курси Anthropic Academy

Anthropic рекомендує 4 курси, і ми серйозно радимо не ігнорувати їх:

Building with the Claude API (84 лекції, 8.1 год, 10 квізів) — фундамент всього: API, tool_use, structured output, batch, agentic systems
Introduction to Model Context Protocol — MCP архітектура, Python SDK, ресурси, транспорт
Claude Code in Action (15 лекцій, 1 год) — CLAUDE.md, commands, skills, GitHub інтеграція
Claude 101 — базові знання для тих, хто починає з нуля

Де знайти курси

Всі курси безкоштовні на Anthropic Academy (Skilljar):
anthropic.skilljar.com → розділ Courses

2. Практикуйте з реальними проєктами

Читання документації — необхідно, але недостатньо. Побудуйте хоча б один проєкт з tool_use та MCP. Наш OrderBot — хороший шаблон для початку.

3. Розумійте trade-offs

Більшість питань — не «що правильно?», а «що найкраще у даному сценарії?». Model-driven чи pre-configured? Hub-and-spoke чи pipeline? Prompt-based чи programmatic enforcement? Ви повинні знати компроміси.

4-8. Глибоке занурення в кожен домен

Вивчіть файлову структуру Claude Code напам'ять. Зрозумійте MCP протокол на рівні конфігурації. Опануйте prompt engineering від few-shot до structured output. Розберіться з batch API. Не ігноруйте error handling.

Ключове для екзамену

Exam Guide наголошує: «Hands-on experience is essential.» Теоретичних знань недостатньо. Якщо ви ніколи не писали agentic loop, не налаштовували .mcp.json, не створювали CLAUDE.md — витратьте час на практику перед екзаменом.

План підготовки на 2 тижні

Ось реалістичний план, якщо у вас є базовий досвід з Claude:

Тиждень 1: Теорія + Курси AnthropicДні 1-7: Academy + Модулі 1-4

↓

Тиждень 2: Практика + СимуляціяДні 8-14: Проєкт + Модулі 5-7

Тиждень 1: Теорія та курси (деталі)

День 1-2: Claude 101 + «Claude Code in Action» на Academy
День 3-4: «Building with Claude API» (перші 40 лекцій)
День 5: «Introduction to MCP» + решта API курсу
День 6-7: Модулі 2-4 цього курсу, виконайте всі квізи

Тиждень 2: Практика та симуляція (деталі)

День 8-9: Побудуйте agentic workflow з MCP інтеграцією (власний OrderBot)
День 10-11: Модулі 5-6 цього курсу + batch API експерименти
День 12: Налаштуйте CI/CD pipeline з Claude Code для реального проєкту
День 13-14: Модуль 7 (практичний екзамен), повторіть слабкі місця

Ресурси для підготовки

Ресурс	Що покриває	Пріоритет
Anthropic Academy	Всі 5 доменів	Критичний
Claude Code Documentation	Домени 3, 4	Високий
MCP Specification	Домен 2	Високий
Claude API Reference	Домени 4, 5	Середній
Цей курс	Всі 5 доменів + практика	Критичний

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

Перевірка знань

Скільки сценаріїв із загальних 6 буде на вашому екзамені?

A) Всі 6 B) 5 випадкових C) 4 випадкових D) 3 випадкових

Правильно — C! На кожному екзамені випадково обираються 4 з 6 можливих сценаріїв. Тому потрібно готуватись до всіх шести, бо ви не знаєте, які саме потраплять.

Практична вправа

Проведіть самооцінку: оцініть свій рівень знань за кожним з 5 доменів від 1 (нічого не знаю) до 5 (експерт). Визначте 2 найслабших домени — саме на них потрібно зосередити підготовку.

Приклад самооцінки:
1. Agentic Architecture: 3/5 — працював з агентами, але не з мульти-агентними системами
2. Tool Design & MCP: 2/5 — використовую MCP, але не проєктував власні інструменти
3. Claude Code Config: 4/5 — добре знаю CLAUDE.md та commands
4. Prompt Engineering: 3/5 — знаю основи, але не працював з batch API
5. Context Management: 2/5 — слабке місце

Фокус: Домени 2 і 5 — найслабші. Виділити додатковий час на Tool Design та Context Management.

2.1 Агентні цикли (Agentic Loops)

Модуль 2 · Агентна архітектура (27%)

Ваш стартап «FreshMart» хоче автоматизувати підтримку клієнтів. Клієнт пише: «Де моє замовлення #4521?» Бот повинен знайти замовлення в базі, перевірити статус доставки і відповісти. Це не один виклик API — це цикл: запитай модель, вона вирішить зателефонувати до бази, отримає результат, подумає ще, і нарешті відповість. Ласкаво просимо в агентний цикл.

Агентний цикл — це як розмова між шеф-кухарем і його помічниками. Шеф (Claude) отримує замовлення (запит користувача), вирішує, що потрібно (подивитися рецепт, перевірити холодильник, увімкнути піч), дає команди помічникам (tool calls), отримує результати («масла немає!»), приймає нове рішення («замінимо оливковою олією») — і цей цикл триває, поки страва не готова (end_turn).

Серце циклу: stop_reason

Увесь агентний цикл тримається на одному полі у відповіді API — stop_reason. Це як світлофор для вашого коду:

Надіслати запитmessages → API

→

Claude думаєобирає дію

→

stop_reason?tool_use / end_turn

tool_use → виконати інструмент і повторити | end_turn → зупинити цикл

stop_reason	Що це означає	Що робити
`tool_use`	Claude хоче викликати інструмент	Виконайте інструмент, поверніть результат, продовжуйте цикл
`end_turn`	Claude завершив роботу	Зупиніть цикл, поверніть текстову відповідь
`max_tokens`	Вичерпано ліміт токенів	Можна продовжити з новим запитом або повідомити користувача

Ключове для екзамену

Агентний цикл продовжується поки stop_reason === "tool_use". Коли модель повертає stop_reason === "end_turn", це сигнал зупинки. Результати інструментів додаються до історії повідомлень (message history), а не передаються окремо.

OrderBot: наш перший агентний цикл

Повернемось до FreshMart. Ось як OrderBot обробляє запит «Де моє замовлення?»:

import anthropic client = anthropic.Anthropic() def run_orderbot(user_message: str, tools: list) -> str: """Агентний цикл OrderBot для FreshMart.""" messages = [{"role": "user", "content": user_message}] while True: response = client.messages.create( model="claude-sonnet-4-20250514", max_tokens=4096, tools=tools, messages=messages ) # Додаємо відповідь моделі до історії messages.append({ "role": "assistant", "content": response.content }) # Перевіряємо stop_reason if response.stop_reason == "end_turn": return next( (block.text for block in response.content if hasattr(block, "text")), "" ) # stop_reason == "tool_use" - виконуємо інструменти tool_results = [] for block in response.content: if block.type == "tool_use": result = execute_tool(block.name, block.input) tool_results.append({ "type": "tool_result", "tool_use_id": block.id, "content": result }) messages.append({"role": "user", "content": tool_results})

Model-driven vs Pre-configured

Тепер ключове архітектурне рішення: хто вирішує, що робити далі — модель чи ваш код?

Model-driven (адаптивний)

Модель сама обирає інструменти і порядок. Гнучко, але менш передбачувано.

Коли: research agent, складні задачі з невизначеним потоком

Pre-configured (фіксований)

Ви визначаєте послідовність кроків. Передбачувано, але негнучко.

Коли: ETL pipeline, генерація звітів з фіксованими секціями

Для OrderBot ми обираємо model-driven: клієнт може запитати про замовлення, повернення, або доставку — бот сам вирішить, які інструменти викликати.

Пастка на екзамені

Anti-pattern: парсинг природної мови замість tool_use. Деякі розробники витягують дії з тексту через regex. Це ненадійно. Завжди використовуйте tool_use — Claude сам вирішить, коли і який інструмент викликати. Ще один anti-pattern: довільний max_iterations=3 без обґрунтування. Агент може потребувати 1 крок або 10 — залежно від задачі.

У наступному уроці ми масштабуємо OrderBot: замість одного агента — цілу команду спеціалізованих ботів із координатором.

Перевірка знань

Що означає stop_reason === "tool_use" у відповіді Claude API?

A) Модель завершила відповідь і готова до нового запиту B) Модель хоче викликати інструмент — потрібно виконати виклик і повернути результат C) Виникла помилка при обробці запиту D) Модель вичерпала ліміт токенів

Правильно — B! Коли stop_reason === "tool_use", модель вирішила, що потрібно викликати інструмент. Ваш код повинен виконати виклик, отримати результат і додати його до message history для наступної ітерації циклу.

Практична вправа

Опишіть словами (або псевдокодом) агентний цикл для задачі: «Знайти в базі даних всі замовлення клієнта за останній місяць, порахувати загальну суму, і надіслати email зі звітом». Які інструменти потрібні? Model-driven чи pre-configured?

Інструменти: query_orders, calculate_total, send_email

Підхід: Pre-configured (prompt chaining) — тому що послідовність чітко визначена:
1. query_orders(customer_id, date_range) → список замовлень
2. calculate_total(orders) → сума
3. send_email(to, subject, body) → підтвердження

Model-driven тут надлишковий — немає потреби в адаптивності, потік лінійний. Pre-configured дасть передбачуваний результат і менше токенів.

2.2 Мульти-агентна оркестрація

Модуль 2 · Агентна архітектура (27%)

OrderBot FreshMart росте. Тепер він обробляє не лише замовлення, а й повернення, скарги, і питання про доставку. Один агент з 15 інструментами починає плутатися — обирає пошук доставки, коли клієнт питає про повернення. Що робити? Розділити одного «універсала» на команду спеціалістів.

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

Hub-and-spoke: координатор і субагенти

Ось як ми реорганізували OrderBot:

OrderBot Coordinator
Приймає запит, визначає тип, делегує

|———— делегує задачі ————|

Orders Agentquery_order
track_delivery

Returns Agentprocess_return
check_policy

FAQ Agentsearch_kb
format_answer

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

Ключове для екзамену

Субагенти мають ізольований контекст. Координатор передає тільки необхідну інформацію через prompt підзадачі. Оптимальна кількість інструментів на агента — 4-5. Якщо агент має 15+ інструментів, якість вибору різко падає. Розділіть на спеціалізованих субагентів.

Task tool, allowedTools та паралельні виклики

Task tool створює субагентів. allowedTools обмежує їхні можливості (принцип найменших привілеїв):

# AgentDefinition для Returns Agent { "name": "returns_agent", "description": "Обробляє запити на повернення товарів", "allowedTools": ["check_return_policy", "process_return", "calculate_refund"], "prompt": "Ви агент повернень FreshMart. Обробіть запит на повернення." } # Координатор може запустити кілька субагентів ПАРАЛЕЛЬНО: response.content = [ {"type": "tool_use", "name": "Task", "input": {"agent": "orders_agent", "task": "Знайди замовлення #4521"}}, {"type": "tool_use", "name": "Task", "input": {"agent": "faq_agent", "task": "Яка політика повернень?"}} ] # Обидва працюють одночасно, результати повертаються координатору

Пастка на екзамену

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

Task tool vs fork_session

Task tool

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

Для: незалежних підзадач, паралельних викликів

fork_session

Нова сесія наслідує контекст батьківської. Зберігає частину історії.

Для: продовження роботи в паралельній гілці

Тепер наш OrderBot масштабується: координатор + 3 субагенти, кожен з 2-3 інструментами, з можливістю паралельного виконання. У наступному уроці ми додамо воркфлоу-логіку — ескалацію до людини і programmatic guards.

Перевірка знань

Яка ключова характеристика субагентів у hub-and-spoke архітектурі?

A) Субагенти діляться контекстом з координатором для кращої координації B) Субагенти мають ізольований контекст і отримують тільки свою задачу C) Субагенти можуть бачити контекст інших субагентів D) Субагенти завжди виконуються послідовно, один за одним

Правильно — B! Ізоляція контексту — фундаментальна характеристика hub-and-spoke. Координатор передає субагенту тільки необхідну інформацію через prompt задачі, а субагент не бачить контекст координатора або інших субагентів.

Практична вправа

Спроєктуйте мульти-агентну систему для code review. Визначте: 1) скільки субагентів, 2) які allowedTools для кожного, 3) які задачі паралельні, а які послідовні.

Координатор: приймає PR, розбиває на підзадачі

3 субагенти (паралельні):
1. style_checker [allowedTools: read_file, grep] — перевіряє стиль
2. security_reviewer [allowedTools: read_file, grep, search_cve] — шукає вразливості
3. logic_analyzer [allowedTools: read_file, run_tests] — перевіряє логіку

1 субагент (послідовний, після паралельних):
4. summary_writer [allowedTools: write_comment] — синтезує результати

Паралельні: 1, 2, 3. Послідовний: 4 (потребує результатів 1-3).

2.3 Воркфлоу та ескалація

Модуль 2 · Агентна архітектура (27%)

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

Уявіть банківського клерка. Він може сам обробити переказ до 5000 грн. Але якщо клієнт хоче перевести 500 000 грн — клерк не відмовляє, а ескалює: «Одну хвилину, мені потрібно підтвердження менеджера». Так само працює агент: prompt-based правила — це «корпоративна культура» (клерк зазвичай дотримується, але теоретично може порушити), а programmatic enforcement — це «замок на сейфі» (фізично неможливо обійти).

Programmatic vs Prompt-based enforcement

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

Programmatic (гарантовано)

Hooks, validators, guards. Код блокує заборонену дію — модель не може обійти.

if tool_name == "delete_account": return escalate_to_human()

Prompt-based (надійно, не гарантовано)

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

system: "Ніколи не видаляйте дані без підтвердження"

Пастка на екзамені

Екзамен часто питає: «Який підхід гарантує, що агент не виконає заборонену дію?» Правильна відповідь завжди — programmatic enforcement. Для production найкращий підхід — комбінація: prompt для м'яких правил + programmatic guards для жорстких лімітів.

Hooks в Claude Code: PostToolUse

OrderBot FreshMart використовує hook для аудиту всіх операцій з замовленнями:

# PostToolUse hook: логування + валідація def post_tool_use_hook(tool_name, tool_input, tool_result): # Аудит: логуємо кожну дію з замовленнями if tool_name in ["process_return", "cancel_order"]: log_audit(tool_name, tool_input) # Guard: блокуємо повернення вище ліміту if tool_name == "process_return": if tool_input.get("amount", 0) > 500: return {"error": "Amount exceeds auto-refund limit", "action": "escalate_to_manager"} return tool_result

Task decomposition: prompt chaining vs dynamic

Prompt Chaining (статичний)Крок 1 → Крок 2 → Крок 3 (фіксовано)

↓

Обирайте коли: потік лінійний, кроки відомі, потрібна передбачуваність

Dynamic Decomposition (адаптивний)Модель сама визначає кількість і порядок кроків

↓

Обирайте коли: задача невизначена, потрібна адаптивність

Session management

Механізм	Опис	Коли використовувати
`--resume`	Продовжити попередню сесію з повним контекстом	Повернення до незавершеної задачі
`fork_session`	Нова сесія, що наслідує контекст	Паралельна робота над різними аспектами
`/compact`	Стиснути контекст, зберігши ключове	Коли контекстне вікно заповнюється

Ключове для екзамену

Prompt chaining — коли потік лінійний (ETL, звіти). Dynamic decomposition — коли задача невизначена (дослідження, рефакторинг). Комбінація prompt + programmatic enforcement — найкращий підхід для production.

Ми завершили найважливіший домен — агентну архітектуру (27% балу). Тепер переходимо до другого стовпа: як правильно проєктувати інструменти, з якими працюють ваші агенти.

Перевірка знань

Агент повинен виконувати фінансові транзакції. Який підхід до контролю обрати?

A) Prompt-based: додати інструкцію «завжди перевіряй суму перед транзакцією» B) Programmatic enforcement: hook, який блокує транзакції вище ліміту C) Комбінація: prompt для м'яких порад + programmatic для жорстких лімітів D) Жодного контролю: Claude достатньо розумний для самостійних рішень

Правильно — C! Найкращий підхід — комбінація. Prompt-based дає контекст (наприклад, «попереджай про великі суми»), а programmatic enforcement гарантує жорсткі ліміти (блокує транзакції > $10,000 без підтвердження людини).

Практична вправа

Визначте, який підхід до task decomposition краще підходить для кожного сценарію: (1) Генерація щоденного звіту з фіксованими секціями, (2) Дослідження нового ринку з невідомою кількістю джерел, (3) Рефакторинг великого файлу.

1. Щоденний звіт → Prompt chaining — секції фіксовані, порядок відомий
2. Дослідження ринку → Dynamic decomposition — невідомо скільки джерел потрібно
3. Рефакторинг → Dynamic decomposition — агент спершу аналізує код, визначає проблеми, потім рефакторить. Кількість кроків залежить від складності.

3.1 Проєктування інструментів

Модуль 3 · Інструменти та MCP (18%)

Повернемося до OrderBot. Уявіть: у нього є інструмент manage_order з описом «Manages orders». Клієнт питає: «Скасуйте моє замовлення». Claude дивиться на опис... «Manages orders»... Що саме manage? Створити? Видалити? Оновити? Модель вгадує — і часто помиляється.

Опис інструменту — це як вивіска на дверях магазину. Якщо написано просто «Товари» — незрозуміло, чи тут продають хліб, чи автомобілі. Але якщо написано «Свіжа випічка: хліб, круасани, торти. Щоденно з 7:00 до 20:00» — клієнт одразу знає, чи йому сюди. Claude обирає інструменти за їх описом, а не за назвою. Точний опис = точний вибір.

Чотири питання хорошого опису

Кожен tool description повинен відповідати на 4 питання:

ЩО робить (і коли НЕ використовувати)

ЯКІ параметри приймає

ЩО повертає (формат, обмеження)

Погано: розмитий опис

"name": "get_data", "description": "Gets data"

Яку дату? Звідки? В якому форматі?

Добре: точний контракт

"name": "get_customer_orders", "description": "Returns list of orders for customer by ID. Fields: order_id, date, amount. Empty array if none found."

OrderBot: розділення manage_order

Ми розбили один «God tool» на 4 чітких інструменти:

# БУЛО: один інструмент робить все {"name": "manage_order", "description": "Manages orders"} # СТАЛО: 4 спеціалізовані інструменти {"name": "get_order", "description": "Retrieves order details by order_id. Returns: id, items, total, status, delivery_date. Returns null if not found."}, {"name": "cancel_order", "description": "Cancels an active order. Only works for orders with status 'processing'. Returns refund amount. Do NOT use for delivered orders."}, {"name": "track_order", "description": "Returns real-time delivery tracking for an order. Includes: carrier, tracking_number, estimated_delivery, current_location."}, {"name": "update_order", "description": "Updates shipping address or delivery instructions for an active order. Cannot change items or quantities after processing."}

MCP isError pattern: помилка vs порожній результат

Ось де багато хто помиляється на екзамені:

Це НЕ помилка

Пошук повернув 0 результатів. is_error: false, content: []

Модель скаже: «Нічого не знайдено»

Це ПОМИЛКА

База даних не відповідає. is_error: true, isRetryable: true

Модель спробує ще раз або ескалює

# Structured error response для MCP tool { "type": "tool_result", "tool_use_id": "toolu_01abc...", "is_error": true, "content": { "errorCategory": "EXTERNAL_SERVICE_ERROR", "message": "Database connection timeout after 30s", "isRetryable": true, "suggestedFix": "Retry in 5 seconds" } } # isRetryable: true - модель спробує ще раз # isRetryable: false - модель повідомить користувача

Ключове для екзамену

Tool description відповідає на 4 питання: що робить, які параметри, що повертає, коли НЕ використовувати. Порожній результат — це не помилка. is_error: true тільки для фактичних збоїв (мережа, авторизація, validation).

Пастка на екзамені

Коли API пошуку повертає порожній масив — це валідна відповідь, а не помилка. Не ставте is_error: true для порожніх результатів. Екзамен дуже любить цю різницю.

Перевірка знань

API пошуку повертає порожній масив для запиту «xyz123». Яку відповідь tool повинен повернути?

A) is_error: true, message: "No results found" B) is_error: false, content: [] (порожній масив) C) is_error: true, isRetryable: true D) Не повертати нічого, нехай модель зрозуміє з контексту

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

Практична вправа

У вас є інструмент «manage_database» з описом «Manages the database», який підтримує: query, insert, update, delete, backup, restore. Перепроєктуйте його — розділіть на окремі інструменти з точними описами.

6 окремих інструментів:

1. db_query: «Executes a read-only SQL SELECT query. Returns rows as JSON array. Max 1000 rows.»
2. db_insert: «Inserts one or more rows. Returns inserted row IDs. Validates schema before insert.»
3. db_update: «Updates rows matching WHERE clause. Returns count of affected rows. Requires WHERE clause.»
4. db_delete: «Soft-deletes rows matching WHERE clause. Does NOT permanently remove data.»
5. db_backup: «Creates full database backup. Returns backup path and size. Takes 2-5 minutes.»
6. db_restore: «Restores from backup. DESTRUCTIVE: overwrites current data. Requires human confirmation.»

3.2 Інтеграція MCP серверів

Модуль 3 · Інструменти та MCP (18%)

OrderBot FreshMart потребує доступу до бази замовлень, GitHub для трекінгу багів, і Slack для нотифікацій менеджерам. Як підключити ці зовнішні сервіси? Через MCP — Model Context Protocol. Але де зберігати конфігурацію: у проєкті чи персонально?

MCP конфігурація працює як розетки в офісі. .mcp.json (project-level) — це розетки, вбудовані в стіни офісу: вони є для всіх, хто працює в цьому приміщенні, і ділиться через план будівлі (Git). ~/.claude.json (user-level) — це ваш особистий подовжувач, який ви носите з собою: ваші персональні інструменти, які не стосуються команди.

Два рівні конфігурації MCP

.mcp.json (Project-level)

У корені проєкту. Ділиться через Git. Для командних інструментів (БД, GitHub, CI).

~/.claude.json (User-level)

У домашній директорії. Персональний. Для індивідуальних інструментів (Obsidian, Notion).

// .mcp.json для OrderBot FreshMart { "mcpServers": { "postgres": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-postgres"], "env": { "DATABASE_URL": "${DATABASE_URL}" // змінна середовища! } }, "github": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-github"], "env": { "GITHUB_TOKEN": "${GITHUB_TOKEN}" // НЕ hardcode! } } } } // НІКОЛИ не зберігайте API ключі напряму!

Ключове для екзамену

.mcp.json = project-level, Git, для команди. ~/.claude.json = user-level, персональний. Секрети — через ${VARIABLE} (environment variable expansion). Екзамен питає: «Де розмістити MCP сервер для БД проєкту?» — відповідь .mcp.json.

MCP: Tools, Resources, Prompts

MCP сервери надають три типи можливостей:

Tools — дії, які модель може викликати (search, write, deploy)
Resources — контекстні дані, що автоматично додаються (schema, docs)
Prompts — шаблони промптів, специфічні для MCP сервера

tool_choice: контроль вибору інструментів

Значення	Поведінка	Коли використовувати
`auto`	Модель сама вирішує, чи потрібен інструмент	За замовчуванням
`any`	Модель ПОВИННА викликати хоча б один інструмент	Коли відповідь без tool не має сенсу
`{"type":"tool","name":"X"}`	ПРИМУСОВИЙ виклик конкретного інструменту	Structured output через tool_use

Пастка на екзамені

Не давайте одному агенту 20 інструментів. Оптимум — 4-5 на агента. При більшій кількості якість вибору різко падає. Варіант «додати всі інструменти одному агенту» на екзамені завжди неправильний.

Перевірка знань

Де потрібно розмістити конфігурацію MCP сервера PostgreSQL для проєкту команди?

A) ~/.claude.json — щоб кожен розробник мав доступ B) .mcp.json у корені проєкту — ділиться через Git C) В системному промпті Claude Code D) В CLAUDE.md файлі

Правильно — B! .mcp.json — project-level, ділиться через Git. Кожен член команди отримає однаковий набір MCP серверів. ~/.claude.json — персональна конфігурація.

Практична вправа

Напишіть .mcp.json для проєкту, який потребує: (1) PostgreSQL, (2) GitHub, (3) Slack. Використовуйте environment variable expansion для секретів.

{ "mcpServers": { "postgres": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-postgres"], "env": {"DATABASE_URL": "${DATABASE_URL}"} }, "github": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-github"], "env": {"GITHUB_TOKEN": "${GITHUB_TOKEN}"} }, "slack": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-slack"], "env": { "SLACK_BOT_TOKEN": "${SLACK_BOT_TOKEN}", "SLACK_TEAM_ID": "${SLACK_TEAM_ID}" } } } }

Всі секрети через ${...}. Зберігайте у .env (додайте .env до .gitignore!).

3.3 Вбудовані інструменти Claude Code

Модуль 3 · Інструменти та MCP (18%)

Ви попросили Claude Code: «Знайди всі місця, де використовується функція processPayment, і додай логування». Як він це зробить? Не магією — а чіткою послідовністю з шести вбудованих інструментів. Знати їх — обов'язково для екзамену.

Шість вбудованих інструментів Claude Code — це як набір хірургічних інструментів. Скальпель (Edit) — для точних розрізів. Рентген (Grep) — щоб побачити, що всередині. Стетоскоп (Read) — щоб послухати конкретний орган. Кожен має своє призначення, і використання молотка (Bash) замість скальпеля (Edit) — це поганий знак.

6 інструментів: коли який використовувати

Інструмент	Призначення	Коли використовувати
Read	Читання файлів	Знаєте точний шлях — прочитайте
Write	Створення або повне перезаписування	Новий файл або повна заміна
Edit	Точкова зміна частини файлу	Зміна конкретних рядків (хірургічно)
Bash	Shell-команди	Тести, git, npm — все, що у терміналі
Grep	Пошук по вмісту файлів	«Де використовується ця функція?»
Glob	Пошук самих файлів по імені	«Які .py файли є в проєкті?»

Incremental codebase understanding

Ось як Claude Code поступово розуміє великий проєкт (це pattern, який треба знати):

1. GlobЗнайти структуру: **/*.py

↓

2. ReadКлючові файли: README, main.py, config

↓

3. GrepЗнайти паттерни: "def processPayment"

↓

4. ReadДетально вивчити знайдені файли

↓

5. Edit/WriteЗробити зміни

↓

6. BashЗапустити тести, перевірити

Ключове для екзамену

Розрізняйте Grep (пошук по вмісту) та Glob (пошук файлів по імені). Також: Edit (хірургічна зміна) vs Write (повна заміна). На екзамені часто дають сценарій і питають, який саме інструмент обрати.

Пастка на екзамені

Не використовуйте Bash для читання файлів (cat, head) або пошуку (grep, find), коли є спеціалізовані інструменти Read, Grep, Glob. Спеціалізовані інструменти ефективніші та безпечніші.

Перевірка знань

Вам потрібно знайти всі місця в проєкті, де використовується функція validateInput(). Який інструмент обрати?

A) Glob — знайти файли з цією функцією B) Grep — пошук по вмісту файлів C) Bash — виконати grep у терміналі D) Read — прочитати кожен файл окремо

Правильно — B! Grep шукає по вмісту файлів і підтримує regex. Glob шукає файли по імені, а не по вмісту. Bash(grep) працює, але спеціалізований Grep ефективніший.

Практична вправа

Для кожної задачі оберіть правильний інструмент: (1) Створити config.yaml, (2) Змінити timeout з 30 на 60, (3) Знайти всі .tsx файли, (4) Запустити npm test, (5) Знайти де імпортується auth.

1. Write — створення нового файлу
2. Edit — точкова зміна (не потрібно перезаписувати весь файл)
3. Glob — пошук файлів по патерну (components/**/*.tsx)
4. Bash — виконання CLI команди
5. Grep — пошук по вмісту (import auth, from auth)

4.1 Ієрархія CLAUDE.md

Модуль 4 · Конфігурація Claude Code (20%)

Ви працюєте над OrderBot у команді з 5 розробників. Один пише коментарі англійською, інший — українською. Один використовує tabs, інший — spaces. Як забезпечити, щоб Claude Code дотримувався єдиних конвенцій для всіх? Відповідь — CLAUDE.md, файл інструкцій з чіткою ієрархією пріоритетів.

CLAUDE.md — це як система законів у державі. User-level (~/.claude/CLAUDE.md) — це ваші особисті звички (мова, стиль). Project-level (.claude/CLAUDE.md) — це закони компанії (конвенції, архітектура). Directory-level (CLAUDE.md у папці) — це правила конкретного відділу. І як у реальному житті, більш конкретний закон перевизначає загальний: правила відділу > закони компанії > особисті звички.

Три рівні: User → Project → Directory

Directory CLAUDE.md (найвищий пріоритет)

Project .claude/CLAUDE.md

User ~/.claude/CLAUDE.md (найнижчий)

Рівень	Розташування	Scope	Git
User	~/.claude/CLAUDE.md	Всі проєкти	Ні
Project	.claude/CLAUDE.md	Цей проєкт	Так
Directory	CLAUDE.md у підпапці	Ця директорія	Так

@import та .claude/rules/ з path-scoping

# .claude/CLAUDE.md для OrderBot FreshMart Це проєкт e-commerce бота FreshMart. @docs/coding-standards.md @docs/api-conventions.md ## Правила - TypeScript strict mode - Всі API endpoints мають OpenAPI docs

# .claude/rules/backend.md --- path: "src/api/**/*.ts" --- # Backend правила - Завжди валідуй вхідні дані через Zod - Async/await для всіх I/O операцій - Structured error responses

Ключове для екзамену

Пріоритет: Directory > Project > User. Файли у .claude/rules/ з path: застосовуються тільки до файлів, що відповідають патерну. @import вставляє файли inline для модульної організації.

Пастка на екзамені

Файли у .claude/rules/ з path: frontmatter застосовуються тільки до файлів, які відповідають glob-патерну. Якщо Claude працює з файлом поза патерном — ці правила не діють.

Перевірка знань

У проєкті є ~/.claude/CLAUDE.md з правилом «Пиши коментарі англійською» і .claude/CLAUDE.md з правилом «Пиши коментарі українською». Яке правило буде застосовано?

A) Англійською — user-level має вищий пріоритет B) Українською — project-level перевизначає user-level C) Обидва правила будуть застосовані одночасно D) Виникне конфлікт і Claude запитає уточнення

Правильно — B! Project-level має вищий пріоритет ніж user-level. Більш специфічний контекст перевизначає загальний.

Практична вправа

Створіть структуру CLAUDE.md для проєкту з frontend (React) та backend (Python FastAPI). Визначте: які правила у project-level, які у .claude/rules/ з path-scoping.

Project-level (.claude/CLAUDE.md): Git commit format, PR template, архітектура, @import docs/api-schema.md

.claude/rules/react.md: path: "frontend/src/**/*.tsx" — Функціональні компоненти, hooks, TanStack Query

.claude/rules/python.md: path: "backend/**/*.py" — Type hints, async/await, Pydantic models

User-level (~/.claude/CLAUDE.md): «Відповідай українською», персональні преференції

4.2 Команди та навички (Commands & Skills)

Модуль 4 · Конфігурація Claude Code (20%)

Команда FreshMart щодня робить code review. Кожен раз розробник пише: «Проведи review PR, перевір security, performance, style...». Це 5 хвилин на промпт кожен раз. А якби можна було просто набрати /review і отримати все автоматично?

Commands і Skills — це як макроси у Excel або aliases у bash. Замість повторення одних і тих самих дій, ви записуєте їх один раз і викликаєте однією командою. Commands — простий макрос (текстовий промпт). Skills — розширений макрос з контролем доступу і ізоляцією (як stored procedure з правами доступу).

Commands: кастомні slash-команди

.claude/commands/ (Project)

Ділиться через Git. Для команди.

Приклад: /review, /deploy

~/.claude/commands/ (Personal)

Персональний. Не у Git.

Приклад: /explain-ua

# .claude/commands/review.md (для всієї команди FreshMart) Проведи code review поточного PR: 1. git diff main...HEAD 2. Перевір security: SQL injection, hardcoded secrets 3. Перевір performance: N+1 queries, unnecessary loops 4. Перевір style: ESLint, naming conventions 5. Сформуй звіт: критичні → важливі → nice-to-have

Skills: розширені команди з ізоляцією

Skills живуть у .claude/skills/ і мають YAML frontmatter з трьома ключовими полями:

# .claude/skills/deploy/SKILL.md --- context: fork allowed-tools: - Bash - Read argument-hint: "environment (staging|production)" --- # Deploy Skill Деплой OrderBot у вказане середовище. 1. npm test 2. npm run build 3. ./scripts/deploy.sh $ARGUMENTS 4. Health check 5. Повідомити результат

Поле	Значення	Що робить
`context: fork`	Ізольована сесія	Skill не бачить попередній контекст розмови
`allowed-tools`	Список інструментів	Обмежений набір — принцип least privilege
`argument-hint`	Підказка	Що передати як аргумент

Ключове для екзамену

.claude/commands/ = project, Git, команда. ~/.claude/commands/ = personal, не Git. context: fork = ізольована сесія без попереднього контексту. allowed-tools обмежує доступні інструменти для безпеки.

Пастка на екзамені

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

Перевірка знань

Що означає context: fork у SKILL.md frontmatter?

A) Skill створює новий Git branch B) Skill виконується у fork'нутій (ізольованій) сесії без попереднього контексту C) Skill форкає репозиторій на GitHub D) Skill виконується паралельно, зберігаючи контекст

Правильно — B! context: fork створює нову ізольовану сесію. Skill не бачить попередній контекст розмови, що забезпечує безпеку і чистоту виконання.

Практична вправа

Створіть SKILL.md для skill «migrate-db», який виконує міграцію бази даних. Визначте frontmatter і кроки.

--- context: fork allowed-tools: - Bash - Read argument-hint: "migration name (e.g., add_users_table)" --- # Database Migration 1. alembic history 2. alembic revision --autogenerate -m "$ARGUMENTS" 3. Прочитати згенерований файл 4. alembic upgrade head --sql (перевірка) 5. alembic upgrade head (застосування) 6. alembic current (верифікація)

context: fork для ізоляції, allowed-tools обмежені до Bash і Read (міграції через alembic, не вручну).

4.3 CI/CD інтеграція

Модуль 4 · Конфігурація Claude Code (20%)

OrderBot FreshMart зростає: 3 розробники, 10 PR на тиждень. Хто буде робити code review? Людина? Занадто повільно. Claude Code у CI/CD pipeline — автоматичний review на кожен PR, з JSON-звітом і блокуванням merge при критичних проблемах.

Claude Code в CI/CD — це як автоматична система контролю якості на заводі. Кожен продукт (PR) проходить через сканер (Claude Code з -p), отримує звіт (JSON), і якщо знайдено дефект (critical issue) — конвеєр зупиняється. Людина не стоїть біля конвеєра 24/7 — система працює автоматично.

Ключовий набір: -p + --output-format json

PR створено

→

claude -p "Review"--output-format json

→

JSON результатseverity, file, message

→

Critical?Block / Pass

# Non-interactive: -p передає prompt напряму claude -p "Review the changes in this PR" --output-format json # З pipe: diff як вхідні дані git diff main...HEAD | claude -p "Review for security" --output-format json # З schema: гарантія формату claude -p "Analyze quality" --output-format json --json-schema '{ "type": "object", "properties": { "issues": { "type": "array", "items": { "type": "object", "properties": { "severity": {"type": "string", "enum": ["low","medium","high","critical"]}, "file": {"type": "string"}, "description": {"type": "string"} }, "required": ["severity", "file", "description"] } } } }'

Ключове для екзамену

У CI/CD: -p (non-interactive) + --output-format json (structured output). --json-schema гарантує формат. Кожен review — ізольована сесія (без --resume). Один PR = один чистий контекст.

Пастка на екзамені

Не використовуйте --resume для CI/CD review. Кожен review повинен мати чистий контекст. «Respond in JSON» у промпті — ненадійно. --json-schema — єдиний спосіб гарантувати формат.

Iterative refinement: 3 техніки

Input/Output examples — покажіть бажаний формат на прикладі
Test-driven — спочатку тести, потім генерація коду
Interview pattern — Claude ставить уточнюючі питання перед виконанням (тільки interactive)

Перевірка знань

Як забезпечити, що Claude Code в CI pipeline повертає результат у визначеному JSON форматі?

A) Додати інструкцію «respond in JSON» у промпт B) Використати --output-format json з --json-schema C) Парсити текстову відповідь через regex D) Використати --resume для збереження формату

Правильно — B! --output-format json + --json-schema гарантує формат. Промптинг ненадійний, regex крихкий, --resume не пов'язаний з форматом.

Практична вправа

Напишіть GitHub Actions workflow: при push у main Claude Code аналізує зміни, виводить JSON з severity/file/message, блокує merge при critical issues.

name: Claude Code Analysis on: [pull_request] jobs: analyze: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 with: { fetch-depth: 0 } - name: Analyze run: | git diff ${{ github.event.pull_request.base.sha }}..HEAD | \ claude -p "Analyze for issues" \ --output-format json \ --json-schema '{"type":"object","properties":{"issues":{"type":"array","items":{"type":"object","properties":{"severity":{"type":"string"},"file":{"type":"string"},"message":{"type":"string"}}}}}}' > analysis.json - name: Check critical run: | CRITICAL=$(jq '[.issues[]|select(.severity=="critical")]|length' analysis.json) if [ "$CRITICAL" -gt 0 ]; then echo "CRITICAL!"; exit 1; fi

5.1 Precision та few-shot

Модуль 5 · Prompt Engineering (20%)

OrderBot FreshMart отримує скаргу: «Ваш сайт — повний жах, нічого не працює!». Бот повинен класифікувати тікет. Промпт «Classify this ticket» дасть непередбачуваний результат. Але промпт з чіткими критеріями і прикладами — стабільну класифікацію щоразу.

Prompt engineering — це як написання технічного завдання для підрядника. Скажіть «зробіть красиво» — отримаєте щось на смак підрядника. Скажіть «білі стіни RAL 9003, підлога дуб 120мм, стеля 2.7м, 3 розетки на стіну» — отримаєте саме те, що хотіли. Precision = конкретні критерії. Few-shot = показати приклади готового результату.

Explicit criteria vs Vague instructions

Розмитий промпт

"Review this code and suggest improvements"

Які improvements? Security? Performance? Style? Все одразу?

Precision промпт

"Review for: 1. SQL injection (raw concat) 2. Missing validation 3. Bare except clauses For each: file, line, severity, fix with code example"

Few-shot examples для OrderBot

2-4 різноманітних прикладів — це оптимум. Обов'язково включіть ambiguous case:

"Categorize FreshMart support tickets. Example 1: Input: 'My order #4521 was charged twice' Output: {'category': 'billing', 'priority': 'high', 'action': 'refund_review'} Example 2: Input: 'How do I change my delivery address?' Output: {'category': 'account', 'priority': 'low', 'action': 'self_service'} Example 3 (ambiguous): Input: 'I want to cancel' Output: {'category': 'retention', 'priority': 'medium', 'action': 'clarify', 'note': 'Unclear: cancel order or cancel subscription. Ask.'} Now categorize: '$TICKET_TEXT'"

False positive reduction

Покажіть не тільки що шукати, а й що НЕ рахувати проблемою:

"DO flag: - SQL queries with string concatenation - Hardcoded API keys Do NOT flag: - Parameterized queries (these are safe) - Test files with mock credentials - Environment variables (runtime, not hardcoded)"

Ключове для екзамену

Precision промпт: (1) що шукати, (2) як оцінювати (severity), (3) як форматувати. Few-shot: 2-4 різноманітних приклади з ambiguous case. Всі приклади — в однаковому форматі.

Пастка на екзамені

Few-shot examples повинні бути різноманітними і покривати edge cases. 4 однакових приклади — марна трата контексту. Включіть ambiguous case. Рекомендована кількість — 2-4.

Перевірка знань

Яка рекомендована кількість few-shot examples для типової задачі класифікації?

A) 1 приклад достатньо B) 2-4 різноманітних приклади C) 10+ прикладів для максимальної якості D) Few-shot не потрібен, достатньо детального промпту

Правильно — B! 2-4 targeted examples — оптимум. 1 недостатньо для різноманітності. 10+ витрачає контекст без пропорційного покращення. Ключове — різноманітність, а не кількість.

Практична вправа

Напишіть few-shot промпт (3-4 приклади) для класифікації git commit messages за типом (feat, fix, refactor, docs, test, chore). Включіть ambiguous case.

"Classify git commits by type. Ex 1: 'Add JWT authentication' Out: {'type': 'feat', 'confidence': 'high'} Ex 2: 'Fix null pointer in payment' Out: {'type': 'fix', 'confidence': 'high'} Ex 3: 'Extract validation logic' Out: {'type': 'refactor', 'confidence': 'high'} Ex 4 (ambiguous): 'Update user service' Out: {'type': 'refactor', 'confidence': 'low', 'note': 'Could be feat or refactor. Need diff.'} Classify: '$COMMIT_MSG'"

5.2 Structured Output через tool_use

Модуль 5 · Prompt Engineering (20%)

OrderBot FreshMart повинен витягувати дані з інвойсів постачальників: назва, номер, дата, сума, товари. Промпт «Extract invoice data as JSON» іноді повертає JSON, іноді — текст з JSON всередині, іноді — markdown таблицю. Як гарантувати стабільний JSON кожного разу?

Просити модель «respond in JSON» — це як просити офіціанта «принести щось солодке». Може принесе торт. Може — цукерку. А може — солодкий чай. Але якщо ви покажете меню і скажете «номер 15 — Наполеон» — отримаєте саме Наполеон. tool_choice: forced + JSON schema — це «номер 15» для structured output.

tool_use як механізм structured output

Замість «прохання» — примус через tool_choice:

extract_tool = { "name": "extract_invoice", "description": "Extracts structured data from invoice", "input_schema": { "type": "object", "properties": { "vendor": {"type": "string"}, "invoice_number": {"type": "string"}, "total": {"type": "number"}, "currency": {"type": "string", "enum": ["USD","EUR","UAH","other"]}, "currency_raw": {"type": ["string","null"], "description": "Original text if 'other'"} }, "required": ["vendor", "invoice_number", "total"] } } response = client.messages.create( model="claude-sonnet-4-20250514", tools=[extract_tool], tool_choice={"type": "tool", "name": "extract_invoice"}, # ПРИМУС messages=[{"role": "user", "content": f"Extract: {text}"}] ) # response.content[0].input -- завжди валідний JSON за schema

Enum + "other": escape hatch

Жорсткий enum без «other» змушує модель вгадувати. З «other» — вона чесно каже «не знаю»:

Без escape hatch

"enum": ["USD", "EUR"]

Інвойс у CAD? Модель обере EUR — hallucination!

З escape hatch

"enum": ["USD", "EUR", "other"]
+ currency_raw для деталей

Інвойс у CAD? Модель: «other», raw: «CAD»

Nullable fields: ключ проти hallucination

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

# ПОГАНО: модель ЗМУШЕНА вигадати номер телефону "phone": {"type": "string"} // required, non-nullable # ДОБРЕ: модель може чесно сказати "немає" "phone": {"type": ["string", "null"], "description": "Phone number. null if not in document."}

Ключове для екзамену

tool_choice: {"type": "tool", "name": "X"} — примусовий structured output. Enum + «other» — escape hatch для невідомих значень. type: ["string", "null"] — запобігає hallucination для optional полів.

Пастка на екзамені

Не робіть поле required, якщо дані можуть бути відсутніми. Модель не може повернути null для required non-nullable поля — вона буде змушена вигадати (hallucinate).

Перевірка знань

Як запобігти hallucination при extraction, коли поле може бути відсутнім?

A) Зробити required і додати «don't make up values» B) Видалити поле з schema C) Зробити nullable: type: ["string", "null"] D) Використати default value

Правильно — C! Nullable дозволяє повернути null замість вигадування. Промптинг «don't make up» не гарантує, якщо поле required і non-nullable.

Практична вправа

Створіть JSON schema для tool, який витягує з резюме: ім'я, email, телефон (nullable), досвід (масив), навички (масив), бажана зарплата (nullable, з enum валюти + other).

{ "name": "extract_resume", "input_schema": { "type": "object", "properties": { "full_name": {"type": "string"}, "email": {"type": "string"}, "phone": {"type": ["string", "null"], "description": "null if not in resume"}, "experience": {"type": "array", "items": { "type": "object", "properties": { "company": {"type": "string"}, "role": {"type": "string"}, "years": {"type": "number"} }, "required": ["company","role","years"] }}, "skills": {"type": "array", "items": {"type": "string"}}, "salary": {"type": ["number","null"]}, "salary_currency": {"type": ["string","null"], "enum": ["USD","EUR","UAH","other",null]} }, "required": ["full_name","email","experience","skills"] } }

phone та salary nullable — можуть бути відсутні у резюме.

5.3 Batch Processing та Review

Модуль 5 · Prompt Engineering (20%)

FreshMart отримує 500 інвойсів від постачальників щомісяця. Обробляти по одному — дорого і повільно. Message Batches API — це «оптовий магазин» для API-запитів: 50% дешевше, обробка до 24 годин.

Batch API — це як відправка посилок. Можна нести кожну на пошту окремо (звичайний API — дорого, але швидко). Або зібрати всі в одну коробку і відправити оптом (Batch API — вдвічі дешевше, але доставка до 24 годин). Якщо посилки не терміново — оптом вигідніше.

Message Batches API: 50% savings

# Batch: 500 інвойсів FreshMart за 50% ціни batch = client.messages.batches.create( requests=[ { "custom_id": f"inv-{invoice.id}", # ваш трекер "params": { "model": "claude-sonnet-4-20250514", "max_tokens": 1024, "tools": [extract_invoice_tool], "tool_choice": {"type": "tool", "name": "extract_invoice"}, "messages": [{"role": "user", "content": invoice.text}] } } for invoice in invoices # до тисяч запитів ] ) # Перевірка: batch.processing_status: "in_progress" | "ended" # Результати: client.messages.batches.results(batch.id)

Multi-pass review: незалежні instance

Для якісного review — кілька незалежних проходів, кожен з чистим контекстом:

Security PassНезалежний

Performance PassНезалежний

Quality PassНезалежний

↓ Всі результати → Synthesis Instance → Final Report

Ключове для екзамену

Batch API: 50% дешевше, до 24 годин, custom_id для трекінгу. Self-review (та ж модель перевіряє свій output) має confirmation bias. Для якості — independent instances з чистим контекстом.

Пастка на екзамені

Self-review менш ефективна за independent review: модель схильна підтверджувати свої попередні рішення. Для якісного review — окремі API виклики з чистим контекстом і фокусом на конкретному аспекті.

Перевірка знань

Яка головна перевага Message Batches API?

A) Вища якість відповідей B) Миттєва відповідь C) 50% економія вартості при великих об'ємах D) Доступ до більших моделей

Правильно — C! Batch API дає 50% знижку. Компроміс — результати до 24 годин (не миттєво). Якість і моделі — такі ж.

Практична вправа

Спроєктуйте multi-pass review для AI-generated коду: скільки проходів, що перевіряє кожен, де використати Batch API.

4 проходи (паралельно через Batch API, 50% економія):
1. Correctness: чи код робить те, що просили?
2. Security: вразливості, injection, secrets
3. Performance: O-нотація, N+1, memory
4. Maintainability: readability, naming, SOLID

Synthesis (звичайний API, потребує результатів): зводить 4 звіти в один.

6.1 Управління контекстом

Модуль 6 · Контекст та надійність (15%)

OrderBot працює з клієнтом вже 30 хвилин: обговорили замовлення, повернення, знижку, новий адрес доставки. І раптом клієнт питає: «А що з тим поверненням?» Бот: «Яким поверненням?» Контекст загубився у довгій розмові. Як цього уникнути?

Контекстне вікно моделі — це як робочий стіл. Він має обмежений розмір. Якщо ви складаєте на нього все підряд (tool outputs, довгі діалоги), рано чи пізно він переповнюється і документи починають падати на підлогу. Стратегія: важливі документи — у рамку на стіну (system prompt, case facts). Проміжні записки — у шухляду (scratchpad file). Сміття — у кошик (trimming).

Lost-in-the-middle: де модель «бачить» найкраще

Увага моделі: високо на початку, низько в середині, високо в кінці

Модель найкраще бачить початок і кінець контексту. Середина — «мертва зона». Висновок: критичні факти — на початку (system prompt) або в кінці (останнє повідомлення).

3 техніки збереження контексту

1. Case facts block

system_prompt = """You are OrderBot for FreshMart. CASE FACTS (do not lose these): - Customer: Олена Петренко (ID: 7823) - Order: #4521 (3 items, $89.99, delivered) - Issue: Double charge on credit card - Previous contacts: 2 (unresolved) Use these facts throughout the conversation."""

2. Trimming tool outputs

def trim_output(output, max_chars=2000): if len(output) <= max_chars: return output half = max_chars // 2 return output[:half] + f"\n[{len(output)-max_chars} chars trimmed]\n" + output[-half:]

3. Scratchpad files

# Агент зберігає проміжні результати у файл Write("scratchpad.md", """ ## Key Findings: - Average price: $99/month - Market size: $2.3B ## TODO: - Analyze reviews """)

Ключове для екзамену

Case facts block на початку system prompt — найефективніший спосіб зберегти критичну інформацію. Scratchpad file — для довгих сесій. /compact — коли контекст заповнюється. Lost-in-the-middle: важливе — на початку або кінці.

Пастка на екзамені

Progressive summarization (автоматичне стиснення) ризикує втратою деталей при кожному стисненні. Альтернатива: зберігайте критичні факти у case facts block або scratchpad, стискайте тільки діалоговий контекст.

Перевірка знань

Агент «забуває» критичне обмеження після 50 повідомлень. Яке найкраще рішення?

A) Повторити обмеження у кожному повідомленні B) Розмістити обмеження у case facts block на початку system prompt C) Використати progressive summarization D) Зменшити кількість повідомлень до 20

Правильно — B! Case facts block на початку system prompt — найефективніше. Початок контексту має найвищу «увагу» моделі. Повторення у кожному повідомленні витрачає токени.

Практична вправа

Спроєктуйте стратегію управління контекстом для агента-дослідника, який працює 2+ години. Як зберегти знахідки, уникнути lost-in-the-middle, коли використати /compact?

1. Case facts у system prompt: мета, обмеження, критерії
2. Scratchpad file: структурований (Completed, Findings, TODO)
3. Trim outputs: до 2000 символів, повні дані — у файли
4. /compact: після кожних 20-30 tool calls
5. Final synthesis: Read scratchpad + Create report

6.2 Ескалація та обробка помилок

Модуль 6 · Контекст та надійність (15%)

Клієнт FreshMart просить OrderBot повернути замовлення на $3,000. Бот повинен автоматично обробити? Ні. Це high-risk operation. Бот збирає інформацію, готує запит і передає людині. Ескалація — це фіча, а не failure.

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

5 тригерів ескалації

Тригер	Приклад	Дія
Low confidence	Модель не впевнена (<70%)	Передати людині з контекстом
High-risk operation	Видалення даних, великі суми	Запитати підтвердження
Missing information	Не вистачає даних для рішення	Запитати додаткову інформацію
Policy violation	Запит за межами дозволеного	Повідомити + передати спеціалісту
Repeated failures	3+ невдалих спроб	Зупинити + ескалювати

Access failure vs Empty result

Access failure (is_error: true)

«Database connection refused»

Не змогли дістатися до даних. Retry або ескалація.

Empty result (is_error: false)

«No matching records», content: []

Дістались, але нічого немає. Інформуємо користувача.

Confidence calibration та information provenance

# OrderBot: confidence-based routing def process_with_review(result): if result.confidence < 0.7: return escalate(result, priority="high") # обов'язковий review if result.risk_level == "high": return submit_for_approval(result) # підтвердження if result.confidence < 0.9: submit_for_review(result, priority="low") # async review return result return result # auto: high confidence, low risk

Ключове для екзамену

Ескалація — feature, а не failure. Access failure (is_error: true) vs Empty result (is_error: false) — критична різниця. Confidence calibration визначає routing: auto / review / escalate.

Пастка на екзамені

«Database returned 0 rows» — це empty result (is_error: false). «Database connection refused» — це access failure (is_error: true). Різниця визначає реакцію моделі.

Ми завершили всі теоретичні домени! Тепер — практика: 6 сценаріїв екзамену з реальними питаннями.

Перевірка знань

Агент customer support отримує запит на повернення $5,000. Яка правильна дія?

A) Автоматично обробити — стандартна операція B) Відхилити — сума надто велика C) Ескалювати до людини — high-risk operation D) Запитати у клієнта додаткові документи

Правильно — C! Повернення великої суми — high-risk operation. Агент збирає інформацію і передає людині для підтвердження.

Практична вправа

Спроєктуйте escalation matrix для OrderBot FreshMart: 5 категорій запитів, рівень ризику, поріг confidence, дія (auto/review/escalate).

Категорія	Ризик	Confidence	Дія
FAQ	Low	>70%	Auto
Статус замовлення	Low	>80%	Auto
Зміна адреси	Medium	>85%	Auto + verify
Повернення <$100	Medium	>90%	Review (async)
Повернення >$100	High	N/A	Escalate (завжди)

Будь-який запит з confidence < 70% — escalate незалежно від категорії.

7.1 Сценарії 1-3: Support, Code Gen, Research

Модуль 7 · Практичний екзамен

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

Сценарій 1: Customer Support Agent

Ви проєктуєте AI-агента підтримки для e-commerce (як наш OrderBot): маршрутизація запитів, ескалація до людини, CRM інтеграція.

Домени у цьому сценарії

Tool Design (CRM tools) + Agentic Architecture (ескалація, routing) + Context Management (case facts) + Prompt Engineering (few-shot класифікація)

Сценарій 1 — Питання 1

API інструмент іноді повертає помилки таймауту. Яка найкраща стратегія обробки?

A) Ескалювати до людини при будь-якій помилці B) Повернути structured помилку з isRetryable: true C) Мовчки ігнорувати помилку D) Завершити сесію

Правильно — B! Structured помилка з isRetryable: true дозволяє моделі автоматично повторити. Це найкращий підхід для transient помилок.

Сценарій 1 — Питання 2

Агент має 15 інструментів і якість відповідей нижча за очікувану. Причина і рішення?

A) Потрібна більша модель B) 15 інструментів забагато — розділити на субагентів по 4-5 C) Додати більше few-shot examples D) Збільшити max_tokens

Правильно — B! 15 інструментів перевищують оптимальні 4-5 на агента. Рішення — hub-and-spoke з спеціалізованими субагентами.

Сценарій 2: Code Generation з Claude Code

Налаштування Claude Code для команди: CLAUDE.md, commands, skills, MCP.

Сценарій 2 — Питання 1

Різні конвенції для frontend (React) та backend (Python). Як налаштувати CLAUDE.md?

A) Один великий CLAUDE.md з усіма правилами B) Project-level для загальних + .claude/rules/ з path-scoping для кожного C) Два окремих репозиторії D) Тільки user-level CLAUDE.md

Правильно — B! Project-level для загальних правил + .claude/rules/ з path-scoping для технологія-специфічних.

Сценарій 2 — Питання 2

Deployment skill: обмежені інструменти, без попереднього контексту. Який frontmatter?

A) context: inherit, allowed-tools: [all] B) context: fork, allowed-tools: [Bash, Read] C) context: shared, allowed-tools: [Bash] D) context: fork, allowed-tools: []

Правильно — B! context: fork — ізольована сесія. allowed-tools: [Bash, Read] — мінімум для deployment.

Сценарій 3: Multi-Agent Research

Мульти-агентна система для дослідження: збір, аналіз, синтез даних.

Сценарій 3 — Питання 1

Research, analysis, writer агенти. Який паттерн оркестрації найкращий?

A) Всі паралельно і діляться контекстом B) Hub-and-spoke: research + analysis паралельно, потім writer C) Строго послідовно D) Один агент робить все

Правильно — B! Паралельне виконання незалежних задач + послідовне для залежних. Субагенти НЕ діляться контекстом.

Сценарій 3 — Питання 2

Research субагент знайшов 50 сторінок. Як передати координатору?

A) Передати всі 50 сторінок B) Субагент підсумовує, передає тільки summary C) Зберегти у файл, передати шлях D) Обрізати до перших 5 сторінок

Правильно — B! Субагент підсумовує і повертає structured summary. Це зберігає контекстне вікно координатора.

Практична вправа

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

Сценарій 1: Всі 5. Найважливіший: Tool Design. Помилка: 15+ інструментів одному агенту.

Сценарій 2: Config, MCP, Prompt. Найважливіший: Config. Помилка: монолітний CLAUDE.md.

Сценарій 3: Agentic, Context, Tools. Найважливіший: Agentic. Помилка: субагенти діляться контекстом.

7.2 Сценарії 4-6: Productivity, CI/CD, Data Extraction

Модуль 7 · Практичний екзамен

Другий блок сценаріїв: як Claude Code підвищує продуктивність розробника, інтегрується в CI/CD, і витягує дані з тисяч документів.

Сценарій 4: Developer Productivity

Claude Code для code review, рефакторингу та автоматизації.

Сценарій 4 — Питання 1

Розробник просить зрозуміти велику кодову базу (500+ файлів). Правильна послідовність?

A) Read кожен файл (всі 500) B) Bash: find . | xargs cat C) Glob → Read (ключові) → Grep (паттерни) → Read (деталі) D) Попросити описати словами

Правильно — C! Incremental codebase understanding: Glob (структура) → Read (ключові файли) → Grep (паттерни) → Read (деталі).

Сценарій 4 — Питання 2

Reusable команда для review, доступна всій команді. Де розмістити?

A) ~/.claude/commands/review.md B) .claude/commands/review.md C) CLAUDE.md D) .mcp.json

Правильно — B! .claude/commands/ — project-level, Git, для всієї команди.

Сценарій 5: CI/CD Integration

Claude Code у pipeline: автоматичний review, structured output.

Сценарій 5 — Питання 1

CI pipeline: незалежний JSON review для кожного PR. Як налаштувати?

A) claude --resume B) claude -p "..." --output-format json з ізольованою сесією C) Зберігати результати і порівнювати D) Batch API для всіх PR

Правильно — B! -p для non-interactive, --output-format json для structured output. Кожен PR — ізольована сесія.

Сценарій 5 — Питання 2

Гарантувати формат JSON відповіді для CI?

A) «Respond in JSON» у промпт B) Парсити regex C) --output-format json з --json-schema D) jq без гарантій

Правильно — C! --json-schema валідує структуру. Промптинг і regex ненадійні.

Сценарій 6: Structured Data Extraction

Обробка тисяч документів: tool_use, batch, validation-retry.

Сценарій 6 — Питання 1

PO number може бути відсутнім в інвойсі. Як уникнути hallucination?

A) Required + «guess if not found» B) Nullable: type: ["string", "null"] C) Видалити поле зі schema D) Default «N/A»

Правильно — B! Nullable дозволяє повернути null замість вигадування.

Сценарій 6 — Питання 2

10,000 інвойсів, результат потрібен до завтра. Який підхід?

A) Послідовні API виклики B) Message Batches API з custom_id C) Один великий запит D) 10 паралельних сесій

Правильно — B! Batch API: 50% дешевше, до 24 годин, custom_id для mapping.

Практична вправа

Для сценарію 6 спроєктуйте pipeline: PDF → extraction → validation → retry → DB.

Pipeline:
1. PDF Parser: PDF → text (pypdf + OCR)
2. Batch API: 10,000 запитів, tool_choice forced, custom_id = filename
3. Tool schema: nullable для optional, enum + other
4. Validator: jsonschema + бізнес-правила
5. Retry Queue: failed → single API (макс 2 спроби)
6. Output: JSON → PostgreSQL

7.3 Фінальний тест — 10 питань

Модуль 7 · Практичний екзамен

Фінальне випробування. 10 питань з усіх 5 доменів — подібні за стилем і складністю до реального екзамену. Відповідайте на всі — немає штрафу за помилку. Після кожної відповіді — детальне пояснення.

Правила

10 питань, всі 5 доменів
Відповідайте на всі — немає штрафу за неправильну відповідь
Детальне пояснення після кожної відповіді

Питання 1/10 — Agentic Architecture

Агентний цикл виконав 8 tool calls і отримав stop_reason === "end_turn". Що це означає?

A) Помилка, цикл зупинився примусово B) Модель вирішила, що завдання виконане C) Вичерпано ліміт ітерацій (8 = максимум) D) Контекстне вікно переповнене

Правильно — B! end_turn = модель вважає завдання завершеним. Це нормальне завершення циклу. 8 — не фіксований максимум.

Питання 2/10 — Agentic Architecture

Координатор потребує результати research та analysis агентів. Вони НЕ залежать один від одного. Як запустити?

A) Послідовно B) Паралельно через множинні Task tool calls C) В одному агенті з 10 інструментами D) Через Batch API

Правильно — B! Незалежні задачі — паралельно через множинні Task tool calls. Швидше за послідовне, зберігає ізоляцію.

Питання 3/10 — Tool Design

MCP інструмент пошуку товарів повертає таймаут сервера. Яку відповідь повернути?

A) is_error: false, content: [] B) is_error: true, EXTERNAL_SERVICE_ERROR, isRetryable: true C) is_error: true, VALIDATION_ERROR, isRetryable: false D) Не повертати нічого

Правильно — B! Таймаут = access failure (is_error: true), transient (isRetryable: true). Порожній масив (A) — для випадку, коли пошук працює, але нічого не знайдено.

Питання 4/10 — Tool Design & MCP

API ключ збережено прямо у .mcp.json і закомічено в Git. Як виправити?

A) Все правильно B) Використати ${API_KEY} — environment variable expansion C) Перенести в ~/.claude.json D) Зашифрувати ключ

Правильно — B! API ключі не повинні бути в Git. ${VARIABLE} підставляє з environment. Ключі — у .env (в .gitignore).

Питання 5/10 — Claude Code Config

.claude/rules/api.md з path: "src/api/**/*.ts" і правилом Zod. Розробник працює з src/utils/helpers.ts. Чи діє правило?

A) Так — діє на весь проєкт B) Ні — helpers.ts не відповідає патерну src/api/**/*.ts C) Залежить від контексту D) Так, якщо файл імпортує з src/api/

Правильно — B! Path-scoped rules діють тільки для файлів, що відповідають glob-патерну.

Питання 6/10 — Claude Code Config

Slash-команда /deploy тільки для вас (не для команди). Де розмістити?

A) .claude/commands/deploy.md B) ~/.claude/commands/deploy.md C) .claude/skills/deploy/SKILL.md D) CLAUDE.md

Правильно — B! ~/.claude/commands/ — user-level, персональні, не в Git.

Питання 7/10 — Prompt Engineering

Модель занадто часто класифікує тікети як «critical». Як зменшити false positives?

A) Прибрати категорію critical B) Додати негативні приклади: «Do NOT flag as critical: password resets, FAQ» C) Збільшити temperature D) Інша модель

Правильно — B! Негативні приклади — найефективніший спосіб зменшити false positives. Вони показують boundary між категоріями.

Питання 8/10 — Prompt Engineering

Tool schema для ціни. Валюта може бути непередбачуваною. Найкраща schema для currency?

A) {"type": "string"} — вільний текст B) {"type": "string", "enum": ["USD", "EUR", "GBP"]} C) {"type": "string", "enum": ["USD", "EUR", "GBP", "UAH", "other"]} + currency_raw D) {"type": "integer"} — числовий код

Правильно — C! Enum + «other» + currency_raw — баланс між структурованістю та гнучкістю. Жорсткий enum (B) призведе до hallucination.

Питання 9/10 — Context Management

Claude Code «забуває» вимоги під час довгої сесії. Ефективне рішення (окрім повторення)?

A) Нова сесія B) Зберегти вимоги у scratchpad файл і періодично Read C) Збільшити max_tokens D) Вимкнути tool calls

Правильно — B! Scratchpad file зберігає вимоги персистентно. Працює навіть після /compact. Нова сесія (A) втрачає весь контекст.

Питання 10/10 — Reliability

Чому self-review менш ефективна за independent review instances?

A) Дорожча B) Confirmation bias — модель підтверджує свої попередні рішення C) Повільніша D) Заборонена ToS

Правильно — B! Confirmation bias: модель схильна підтверджувати свої попередні рішення. Independent instances з чистим контекстом оцінюють «свіжим поглядом».

Вітаємо! Ви пройшли весь курс!

Перед екзаменом рекомендуємо:

Повторити слабкі домени (перегляньте квізи, де помилилися)
Побудувати хоча б 1 agentic workflow з MCP (свій OrderBot)
Пройти курси Anthropic Academy
Пам'ятайте: 720/1000, немає штрафу, відповідайте на все

Фінальна вправа

Перегляньте всі квізи курсу. Визначте: 1) найсильніший домен, 2) найслабший, 3) план на 3 дні перед екзаменом.

День 1: Повторити найслабший домен. Перечитати уроки, зробити квізи ще раз.
День 2: Практика: побудувати мініпроєкт з MCP, commands, CLAUDE.md. Протестувати Batch API.
День 3: Фінальний тест ще раз. Перечитати всі карточки «Ключове для екзамену» та «Пастка на екзамені».

Пам'ятайте: Домен 1 (Agentic Architecture) = 27% балу. Якщо він слабкий — це пріоритет #1.