Промт-інжиніринг для Data Science та Software Engineering

Навчальний курс, де кожен приклад реально перевірено на моделі Claude Haiku 4.5 — а не вигадано.

Чим цей курс відрізняється

Більшість матеріалів про «prompt engineering» показують промпт і стверджують, що він кращий. Тут інакше:

• Кожна техніка подана як пара «слабкий промпт» → «сильний промпт».
• Обидва варіанти реально прогнані через Claude Haiku 4.5 (у Частинах 1–2 — 30 прогонів моделі + 3 дослідницькі агенти; загалом у курсі — 118 прогонів на 4 моделях).
• У матеріали вставлено справжній вивід Haiku дослівно — включно з випадками, де навіть «сильний» промпт спрацював не ідеально (це найцінніше для навчання).

Як саме перевіряли і чому без raw-API — у 03-metodologiya-ta-syri-rezultaty.md.

Структура курсу

🧭 Два модулі курсу. Частини 1–8 — виміряне ядро (118 прогонів на 4 моделях). Частини 9–13 — дослідницький модуль 2026 з пʼяти напрямів: промптинг reasoning-моделей, автоматизована розробка з ШІ, мультиагенти, контекст агентів, локальні LLM. Їх зібрано ТІЛЬКИ з першоджерел: офіційні докси, engineering-блоги лабораторій, arXiv, визнані практики. Правило — «кожне твердження реально прочитане за URL», плюс адверсаріальна перевірка. Сирі результати дослідження — у raw-outputs/.

✅ Перевірка актуальності (2026-08-21). Курс звірено з живими доксами Anthropic: усі 11 тверджень механіки API (Частина 8) — підтверджені; ціни й ліміти Haiku 4.5 / Opus 4.8 / Fable 5 — без змін; усі 10 зовнішніх посилань — живі. Оновлено: вийшли Opus 5 (новий флагман) і Sonnet 5 — див. 8.2a «Свіжість лінійки».

🔄 Повторні перевірки 2026-09-19 і 2026-09-24. Усі матеріали ще раз звірено з першоджерелами, перелік виправлень — у Частині 3. Лінійка оновилась: вийшли Claude Fable 5.1 і Claude Opus 5.5, а Fable 5 та Opus 5 стали Legacy. Haiku 4.5 — досі «не раніше 15.10.2026».

⚠️ Перевірено й ЗМІСТ сторонніх ресурсів, не лише доступність. Інтерактивний туторіал Anthropic віддає 200 OK, але зашитий на знятий з експлуатації claude-3-haiku-20240307. Приклади падають, доки не заміниш модель і не зафіксуєш версію SDK (виправлення у два рядки — у Частині 4). Топ-3 перевпорядковано: №1 тепер офіційні докси Anthropic, що не застарівають.

🌐 Живий сайт: https://girbp.github.io/prompt-course-haiku/ — повноцінна веб-версія на GitHub Pages (навігація, пошук, теми; зовнішні посилання відкриваються в новій вкладці). Репозиторій: https://github.com/GirBP/prompt-course-haiku

🌐 Браузерна версія: відкрий index.html — самодостатній офлайн-рідер усіх 13 частин з боковою навігацією, пошуком і темною/світлою темою (без зовнішніх залежностей). Відтворити — build/build_html.py.

📁 Сирі докази й скрипти генерації — у raw-outputs/ (усі 118 прогонів у JSON + workflow-скрипти). Відтворити DOCX — build/build_docx.sh.

11 технік курсу (швидкий огляд)

Data Science

1. Чіткість і конкретність — DS1
2. Few-shot приклади для стабільності формату — DS2
3. Chain-of-Thought (ланцюжок міркувань) — DS3
4. Структурований JSON-вивід зі схемою — DS4
5. Роль / персона — DS5

Software Engineering 6. Чітка специфікація вимог — SE1 7. XML-теги для розділення інструкції й коду — SE2 8. Few-shot для строгого формату (Conventional Commits) — SE3 9. Пошук вади через CoT — SE4 10. Примус формату виводу — SE5 11. Контроль галюцинацій («дозвіл сказати не знаю») — SE6

5 головних висновків з реальних прогонів

Це не теорія — це те, що виміряно на Haiku 4.5 у цьому курсі:

1. Few-shot робить формат детермінованим. Слабкий промпт класифікації дав 3 різні відповіді на 3 прогони; few-shot-версія — 1 однакову (MIXED) тричі поспіль. (DS2)
2. Сильний промпт ≠ просто коротший. Там, де треба стислість, вивід впав з 2949 до 615 символів (SE1); там, де треба міркування, виріс з 398 до 1806 (DS3). Промпт задає правильний обсяг, а не мінімальний.
3. Якоря формату важливіші за заборони. «Output ONLY JSON, no markdown» (DS4) — Haiku все одно обгорнув у ```json. А «start with the character {» (SE5) — дав голий {...}. Позитивний якір першого символу працює краще за негативну заборону.
4. Сучасний Haiku стійкіший до галюцинацій, ніж очікувалось. На пастці pandas.DataFrame.flatten() (такого методу немає) Haiku сам виявив підступ навіть без захисної інструкції (SE6). Техніка «дозволь сказати не знаю» все одно потрібна — але для справді рідкісних/неоднозначних фактів.
5. CoT перетворює відповідь з категоричної на обґрунтовану. Без CoT Haiku відповів «No.» + 3 речення безконтекстного обґрунтування (до того ж порушивши власну інструкцію «yes or no»); з CoT — розклав вартість false positives проти false negatives і дав інженерну рекомендацію щодо порогу (DS3). Різниця — у якості й структурі міркувань, не в їх наявності.

Порівняння моделей і нові техніки (Частина 5)

6. Промпт-інжиніринг важливіший саме для Haiku. На тому самому «no markdown»-промпті Sonnet 4.6 дав голий JSON, а Haiku все одно обгорнув у ```json. Менша модель «карає» за слабкий промпт сильніше — тож економію на моделі компенсуй якістю промпта.
7. Українською писати промпти можна. Few-shot класифікація українською така ж стабільна (ЗМІШАНА ×3), reasoning — на рівні англійського. Але фінальний україномовний текст від Haiku треба вичитувати: трапляються русизми («высоко…», «порожний»).

Надійність формату й антипатерни (Частина 6, N=5 на промпт)

8. Надійність формату — це число, а не «працює/не працює». Закритий набір міток, fixed sentinel і якір першого символу = ~100% (5/5). А негативна заборона «no markdown» протікає: 80% (4/5) — раз із п'яти Haiku таки обгортає у ```json. Для критичних конвеєрів вмикай structured outputs API (є і на Haiku 4.5), а де їх нема — перевірку за схемою з повторним прогоном.
9. Найнебезпечніші антипатерни на Haiku — суперечливі інструкції (модель мовчки обирає одне, втрата контролю) і перевантажений промпт (усе виходить поверхневим). Усі 6 топ-URL пере-перевірено реальним WebFetch (200 OK).

Як користуватися

1. Почни з домену, ближчого тобі — DS або SWE.
2. Для кожної техніки: прочитай слабкий промпт → спробуй передбачити, що зміниться → подивись реальний вивід Haiku → прочитай розбір.
3. Виконай вправи в кінці кожного файлу (відповіді до Частин 1–2 — у 04; до Частин 5–6 — наприкінці самих файлів).
4. Поглибся: Частина 5 (Haiku vs Sonnet, нові техніки) → Частина 6 (надійність N=5, антипатерни).
5. Заверши Частиною 7 — синтез у робочий процес + чек-лист «перед продом». Тримай поряд її разом зі шпаргалкою.

📄 DOCX-версія (promt-inzhiniring-haiku-kurs.docx): відкривши у Word, онови зміст — F9 або ПКМ на «Table of Contents» → Update field.

⚠️ Застереження про чесність. Перевірка йшла через Haiku 4.5 у гарнесі агента (raw-API-ключа в системі не було). Це означає тонке «забруднення» системним промптом агента. Один прогін (SE3 weak #1) навіть протік рядок Co-Authored-By, що походить із інструкцій гарнесу, а не вигадки моделі. Деталі й вплив — у методології.

Частина 1. Промт-інжиніринг для Data Science

5 технік на реальних задачах: EDA-планування, класифікація, вибір метрики, екстракція метрик, обробка пропусків. Усі відповіді нижче — справжній вивід Claude Haiku 4.5.

Формат кожного розділу: задача → слабкий промпт + реальний вивід → сильний промпт + реальний вивід → що ми бачимо → правило.

DS1. Чіткість і конкретність

Принцип: модель не читає думок. Чим конкретніше ціль, дані й формат відповіді — тим менше «води» й більше дії. На малій моделі (Haiku) це особливо помітно.

❌ Слабкий промпт

Analyze this dataset and tell me what to do.

Columns: age, income, churned

Реальний вивід Haiku (скорочено, повний — 1116 символів):

I'd be happy to help you analyze a dataset, but I don't have access to the actual data you're referring to. To provide meaningful analysis and recommendations, I need to see the dataset itself. Could you please share: 1. The actual data... 2. Basic context... How many rows? What does "churned" represent?...

Модель відмовилась і попросила дані — жодної користі.

✅ Сильний промпт

I have a customer churn dataset with three columns: age (integer, years),
income (float, annual USD), churned (0 or 1, the target).
Goal: predict churn. Churn is imbalanced (about 15% positive).
In exactly 5 numbered bullets, give concrete recommendations:
1) two EDA plots to make first,
2) one feature to engineer from these columns,
3) one suitable baseline model,
4) the single most appropriate evaluation metric given the imbalance,
5) one data-leakage risk to check.
Be specific and concise.

Реальний вивід Haiku (повний):

1. Histogram of age distribution by churn class (overlaid or side-by-side) and box plot of income vs. churn status — these reveal whether age/income differ meaningfully between churners and non-churners...
2. Age-to-income ratio (or log(income) / age) — captures relative spending power and lifecycle stage in a single derived feature...
3. Logistic Regression — simple, interpretable, fast to train, and sets a solid baseline...
4. ROC-AUC — threshold-independent and robust to class imbalance...
5. Check whether income or age was used in any customer acquisition, retention, or pricing decisions during the observation period — if so, they're indirect proxies for company actions rather than pure customer attributes...

Що ми бачимо

Той самий набір даних. Слабкий промпт → відмова. Сильний → 5 конкретних, грамотних порад, включно з нетривіальним ризиком витоку даних (leakage). Різниця не в довжині (1116 проти 1125 символів!), а в корисності.

Правило DS1. Завжди вказуй: (1) що це за дані й типи, (2) ціль, (3) важливий контекст (тут — дисбаланс 15%), (4) формат відповіді («exactly 5 numbered bullets»). Формат-обмеження — це кермо для моделі.

DS2. Few-shot приклади для стабільності формату

Принцип: 2–5 прикладів «вхід → вихід» навчають модель формату й межам відповіді краще за будь-який опис. Це найнадійніший спосіб отримати детермінований вивід.

❌ Слабкий промпт (zero-shot)

Classify the sentiment of this review:
'The dashboard loads slowly but the insights are great.'

Реальний вивід — прогнали 3 рази, отримали 3 РІЗНІ відповіді:

• Прогін 1: «mixed/neutral sentiment» + 3 абзаци розбору, наприкінці «leans slightly positive».
• Прогін 2: «mixed sentiment» + «If forced to choose... slightly positive or balanced positive».
• Прогін 3: «mixed sentiment» + «moderately positive review with a caveat».

Формат щоразу інший, фінальна мітка плаває (mixed / slightly positive / moderately positive), розпарсити автоматично — неможливо.

✅ Сильний промпт (few-shot)

Classify each review's sentiment. Use exactly one label: POSITIVE, NEGATIVE,
or MIXED. Output only the single label word, nothing else.

Review: 'Fast and reliable, love it.' -> POSITIVE
Review: 'Crashes constantly, completely useless.' -> NEGATIVE
Review: 'Great features but terrible support.' -> MIXED

Review: 'The dashboard loads slowly but the insights are great.' ->

Реальний вивід — прогнали 3 рази, отримали ОДНАКОВУ відповідь:

MIXED

MIXED

MIXED

Що ми бачимо

Виміряно об'єктивно: слабкий промпт — 3 унікальні відповіді з 3; few-shot — 1 унікальна з 3. Довжина впала з ~886 до 5 символів. Це готовий до продакшену класифікатор, вивід якого можна напряму класти в if label == "MIXED".

Правило DS2. Якщо вивід має споживатися кодом або іншою системою — давай few-shot приклади з точним форматом мітки. Приклади > опис. Це також усуває «балакучість» малих моделей.

DS3. Chain-of-Thought (ланцюжок міркувань)

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

❌ Слабкий промпт

A fraud-detection model has precision 0.30 and recall 0.90 on data where 2% of
transactions are fraud. Is this a good model? Answer only yes or no.

Реальний вивід Haiku:

No. A precision of 0.30 means that 70% of flagged transactions are false positives, creating excessive operational burden... A good fraud-detection model requires better balance—ideally precision above 0.70-0.80...

Відповідь правильна, але категорична й безконтекстна: «потрібна precision 0.70–0.80» — це сумнівне універсальне твердження для fraud, де recall часто цінніший.

✅ Сильний промпт (CoT)

A fraud-detection model has precision 0.30 and recall 0.90 on data where 2% of
transactions are fraud.
Think step by step about the business cost of false positives versus false
negatives for fraud detection.
Then give your final verdict (good or not good) in one sentence with justification.

Реальний вивід Haiku (скорочено, повний — 1806 символів):

Understanding the metrics: Precision 0.30: ...only 30% actually are fraud (70% false positives). Recall 0.90: ...catches 90% of actual fraud... False Positives: declined cards, account blocks, customer service calls... customer churn... False Negatives: Direct financial loss... but only 10% of fraud escapes... Verdict: This model is not good for production use because the 70% false positive rate will severely damage customer experience... A better approach would be to lower the detection threshold, accept some false negatives (e.g., 80% recall), and aim for 70-80% precision...

Що ми бачимо

CoT збільшив вивід з 398 до 1806 символів — і це корисне зростання: модель розклала вартість обох типів помилок і дала інженерну рекомендацію щодо порогу, а не голий вердикт. Для рецензування рішень або пояснення стейкхолдерам це незрівнянно цінніше.

Правило DS3. Для задач на судження, вибір метрики, оцінку trade-off — додавай «think step by step, then give your final answer». Якщо потрібна лише коротка відповідь у проді — попроси міркування у <scratchpad>, а фінал окремо (prompt chaining).

DS4. Структурований JSON-вивід зі схемою

Принцип: для машинно-читаного виводу задавай точну схему (ключі, типи, поведінку для відсутніх значень). Тут також важливий чесний урок про межі техніки.

❌ Слабкий промпт

Extract the key metrics from this text: 'In Q3 revenue was 4.2M USD, up 12%
year over year, churn fell to 3.1%, and we added 540 new customers.'

Реальний вивід Haiku:

Here are the key metrics extracted from that text:

• Revenue (Q3): $4.2M USD
• Year-over-year growth: +12%
• Churn rate: 3.1%
• New customers added: 540 These metrics indicate solid business performance...

Це проза з bullet-ами + коментар. Ключі непослідовні («Revenue (Q3)»), не парситься.

✅ Сильний промпт (схема)

Extract metrics from the text into a JSON object with exactly these keys:
revenue_musd (number), revenue_growth_yoy_pct (number), churn_rate_pct (number),
new_customers (integer). If a value is missing, use null. Output ONLY valid JSON,
no markdown, no commentary.

Text: 'In Q3 revenue was 4.2M USD, up 12% year over year, churn fell to 3.1%,
and we added 540 new customers.'

Реальний вивід Haiku (дослівно):

```json
{
  "revenue_musd": 4.2,
  "revenue_growth_yoy_pct": 12,
  "churn_rate_pct": 3.1,
  "new_customers": 540
}
```

Що ми бачимо (і чесний нюанс!)

Значення, ключі й типи — ідеальні (4.2 число, 540 ціле). АЛЕ: попри явне «no markdown», Haiku все одно обгорнув JSON у ```json блок. Навіть сильний промпт на малій моделі не гарантує 100% слухняності щодо заборон.

Порівняй із SE5, де інструкція «start with the character {» дала голий {...} без блоку. Звідси крос-висновок усього курсу:

Позитивний якір першого символу («починай з {») працює надійніше за негативну заборону («без markdown»).

Правило DS4. Задавай схему з типами і поведінкою для null. Для гарантованого голого JSON: (а) якорі перший символ, (б) у реальному API — нативні structured outputs (output_config.format, є і на Haiku 4.5); prefill (підстав { у відповідь асистента) працює лише на Haiku 4.5 і старших моделях, (в) на крайній випадок — стрипай ``` у пост-обробці.

DS5. Роль / персона

Принцип: призначення ролі («ти — senior data scientist») піднімає глибину й фокус відповіді. У реальному API роль кладуть у system-промпт; тут її передано в тексті як апроксимацію.

❌ Слабкий промпт

How should I handle missing values in the income column?

Реальний вивід Haiku (скорочено, повний — 2429 символів):

1. Deletion — Remove rows / Remove the column...

2. Imputation with Central Tendency — Mean / Median / Mode...

3. Group-Based Imputation...

4. Predictive Imputation — KNN, regression, random forest...

5. Multiple Imputation...

6. Keep Missing as a Category...

What's your specific context—size of dataset, proportion of missing values...?

Це підручник-енциклопедія — 6 категорій усіх можливих методів. Правильно, але без рішення: новачок потоне.

✅ Сильний промпт (роль + контекст + обмеження)

You are a senior data scientist mentoring a junior analyst.
Context: the income column in a churn dataset has 22% missing values, and the
missingness is likely not random (high earners tend to skip the question).
In 4 short bullets, advise how to handle these missing values. Explicitly warn
against the naive mean-imputation approach and name one specific better technique.
Be practical.

Реальний вивід Haiku (повний):

• Don't use mean imputation. It will artificially compress variance, bias your churn predictions toward the mean income level, and mask the real pattern that high earners are missing—exactly when you need to see it most. • Create a "missing" indicator variable. ...High earners skipping the question is itself predictive of churn behavior, so preserve that signal... • Use multiple imputation by chained equations (MICE). This leverages other features (age, tenure, subscription tier)... • Validate your choice on holdout data. ...If a segment's predictions flip dramatically, your approach is leaking bias... The key: treat missingness as information, not just a problem to erase.

Що ми бачимо

Роль + контекст «MNAR, високозаробітні пропускають» дали прицільну експертну пораду: попередження проти mean-imputation, конкретний MICE, missing-indicator як предиктивний сигнал, перевірка на holdout. Вивід коротший (1189 проти 2429), але набагато глибший. Енциклопедія перетворилась на консультацію.

Правило DS5. Роль + конкретний контекст + обмеження («4 bullets», «name one specific technique», «warn against X»). Роль сама по собі слабка — вона працює в парі з контекстом і обмеженнями.

Вправи (Data Science)

1. DS1-вправа. Перепиши слабкий промпт «Build me a model for this data» для датасету transactions(user_id, amount, timestamp, is_fraud) за правилом DS1. Які 4 елементи ти додаси?
2. DS2-вправа. Тобі треба класифікувати тікети підтримки на BUG / FEATURE / QUESTION. Склади few-shot промпт. Скільки прикладів мінімально і чому саме стільки?
3. DS4-вправа. Чому в DS4 Haiku порушив «no markdown», а в SE5 — ні? Сформулюй правило одним реченням.
4. DS5-вправа. Додай роль до промпта «Explain p-value to me» так, щоб відповідь підійшла для product-менеджера, а не статистика.

➡️ Відповіді — у 04-top-sajty-i-shpargalka.md.

Частина 2. Промт-інжиніринг для Software Engineering

6 технік на реальних задачах: написання функції, рецензування коду, commit-меседжі, пошук вади, конвертація файлу налаштувань, перевірка факту про API. Усі відповіді нижче — справжній вивід Claude Haiku 4.5.

SE1. Чітка специфікація вимог

Принцип: для коду неоднозначність = модель додумує. Точна сигнатура, правила, edge-cases і формат виводу дають передбачуваний результат замість «загального рішення на всі випадки».

❌ Слабкий промпт

Write a function to validate emails.

Реальний вивід Haiku (скорочено, повний — 2949 символів):

Simple Regex Approach

def validate_email(email):
    pattern = r'^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$'
    return re.match(pattern, email) is not None

More Robust Approach ... (велика RFC-5322 регулярка)

With DNS/SMTP Verification (Advanced) ... (socket.getaddrinfo)

Usage Examples ... ## Key Considerations ... consider email-validator package...

Модель видала три різні підходи + DNS-перевірку + поради про бібліотеки — 2949 символів. Ти не знаєш, який брати; усі — з регуляркою.

✅ Сильний промпт

Write a Python function is_valid_email(s) that returns a bool.
Rules: return True only if s is a string with exactly one '@', a non-empty local
part, a domain that contains at least one dot, no whitespace, and a final segment
(TLD) of length at least 2.
Do not use a large regex; use simple string operations.
Return False for None or non-string input.
Include a one-line docstring and three example calls in comments.
Output only the code.

Реальний вивід Haiku (дослівно):

def is_valid_email(s):
    """Check if s is a valid email address."""
    if not isinstance(s, str) or not s:
        return False
    if ' ' in s or s.count('@') != 1:
        return False
    local, domain = s.split('@')
    if not local or not domain:
        return False
    if '.' not in domain:
        return False
    parts = domain.split('.')
    if not parts[-1] or len(parts[-1]) < 2:
        return False
    return True

# is_valid_email("user@example.com")  # True
# is_valid_email("invalid.email@")    # False
# is_valid_email("no-at-sign.com")    # False

Що ми бачимо

615 проти 2949 символів. Сильний промпт дав рівно ту функцію: правильна сигнатура, прості рядкові операції (як вимагали — без регулярки), перевірка None/типу, docstring, 3 приклади, нічого зайвого. Кожне правило в промпті → відповідний if у коді.

Правило SE1. Специфікуй: сигнатуру, правила, заборони («do not use a large regex»), обробку помилок, формат виводу («output only the code»). Заборона тут спрацювала — на відміну від «no markdown» у DS4 — бо стосувалась змісту коду, а не обгортки виводу.

SE2. XML-теги для розділення інструкції та коду

Принцип: коли в промпті є і код, і інструкція, модель може плутати, де що. XML-теги (<task>, <code>) дають чіткі межі — це рідна для Claude структура.

❌ Слабкий промпт (усе злите докупи)

Review this code and find issues def transfer(a,b,amt): a.bal-=amt b.bal+=amt return True also fix it

Реальний вивід Haiku (скорочено):

Issues found: 1. Syntax Error - Missing colons... 2. Logic Error - No validation (недостатність балансу)... 3. No error handling... 4. Poor naming... 5. No return value on failure... Fixed version: def transfer(from_account, to_account, amount): if ... return False ...

Непогано, але модель зачепилась за «missing colons» (артефакт злитого однорядкового тексту) і перейменувала параметри, хоча її не просили.

✅ Сильний промпт (XML-структура)

<task>
Review the function inside <code>. List concrete issues in priority order
(correctness, validation, concurrency), then provide a corrected version.
Check specifically: missing balance check, no input validation, no error handling.
</task>

<code>
def transfer(a, b, amt):
    a.bal -= amt
    b.bal += amt
    return True
</code>

Реальний вивід Haiku (скорочено, повний — 1949 символів):

Issues in Priority Order

1. Critical: No Balance Validation (Correctness) — allows a.bal to go negative...

2. Critical: No Input Validation — no check amt positive, no check that a and b are different accounts (self-transfer bug)...

3. High: No Error Handling (Robustness)...

4. High: Race Condition (Concurrency) — Reading and writing a.bal/b.bal are not atomic...

Corrected Version ... (з docstring, ValueError, перевіркою a is b, нотаткою про lock)

Що ми бачимо

Чіткі межі <code> прибрали шум «missing colons» і дали пріоритезовану рецензію за категоріями, які ми задали (correctness/validation/concurrency). Модель знайшла те, що слабкий варіант пропустив: self-transfer bug і race condition — саме тому, що ми попросили подумати про concurrency. Виправлений код — з винятками й нотаткою про блокування.

Правило SE2. Розділяй частини промпта тегами: <task>, <code>, <data>, <example>. Це усуває плутанину «інструкція vs контент» і дозволяє точно скерувати фокус рецензії (тут — додати вісь concurrency).

SE3. Few-shot для строгого формату (Conventional Commits)

Принцип: той самий механізм, що в DS2, але для коду. Хочеш конкретний формат commit-меседжа — покажи приклади, а не описуй.

❌ Слабкий промпт — 3 прогони, 3 РІЗНІ формати

Write a commit message for: added retry logic to the API client and fixed a
typo in the README.

• Прогін 1: Add retry logic to API client and fix README typo + bullet-list тіло + (!) рядок Co-Authored-By: Claude Opus 4.8 ... ⚠️
• Прогін 2: довгий варіант із тілом-абзацом + альтернатива feat: ...; fix: ... + порада «choose whichever fits».
• Прогін 3: feat: add retry logic to API client з bullet-тілом + друга, коротша альтернатива + порада обрати.

Формат стрибає: то заголовок-реченням, то feat:, то дві альтернативи на вибір. Автоматизувати неможливо.

⚠️ Рядок Co-Authored-By у прогоні 1 — це артефакт гарнесу (інструкція про git-коміти з системного промпту агента просочилась у модель), а не «вигадка Haiku». Чесно лишаю його тут як ілюстрацію застереження з методології. Суть (балакучість і нестабільність формату) це не змінює.

✅ Сильний промпт (few-shot) — 3 прогони, формат ЗАМКНЕНО

Write ONE commit subject line in Conventional Commits format:
type(scope): description. Output only the subject line.

Examples:
- added pagination to users endpoint -> feat(api): add pagination to users endpoint
- fixed crash on empty input -> fix(parser): handle empty input safely
- updated install docs -> docs(readme): update installation steps

Now: added retry logic to the API client and fixed a typo in the README ->

Реальний вивід Haiku (3 прогони):

feat(api): add retry logic to API client

feat(api): add retry logic to client and fix typo in README

feat(api): add retry logic to client

Що ми бачимо

Виміряно: слабкий — 3 унікальні багаторядкові відповіді; сильний — усі 3 однорядкові у форматі type(scope): .... Формулювання трохи варіюється (нормально), але структура замкнена намертво — це й можна класти в git-хук.

Правило SE3. Для будь-якого строгого текстового формату (commit, журнал, changelog, docstring-стиль) — 3 приклади «вхід → вихід» надійніші за опис. «Output only the subject line» прибирає балакучі альтернативи.

SE4. Пошук вади через Chain-of-Thought

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

❌ Слабкий промпт

Does this function have a bug?
def add_item(item, items=[]): items.append(item); return items

Реальний вивід Haiku (скорочено):

Yes, this function has a classic Python bug called the mutable default argument problem. The default value items=[] is created once when the function is defined... add_item(1) → [1], add_item(2) → [1, 2] — unexpected!... The fix is to use None as the default...

Haiku і так знайшов ваду (це класика). Відповідь хороша.

✅ Сильний промпт (CoT + структура відповіді)

Analyze this Python function for bugs.
def add_item(item, items=[]):
    items.append(item)
    return items
Reason step by step about what happens when it is called multiple times without
the items argument. Then state the single most important bug, why it happens,
and the one-line fix.

Реальний вивід Haiku (скорочено, повний — 1570 символів):

What happens when called multiple times:

1. First call: add_item("apple") → default items=[] ... Returns ["apple"]
2. Second call: add_item("banana") → You'd expect a fresh list, but Python evaluates default arguments once at function definition time... Returns ["apple", "banana"]
3. Third call: ... Returns ["apple", "banana", "cherry"] The single most important bug: mutable default argument... Why it happens: Python evaluates default parameter values once when the function is defined... The one-line fix: items=None then if items is None: items = []

Що ми бачимо

Обидва знайшли ваду — але CoT-версія показала трасування трьох викликів і структурувала відповідь рівно як просили (вада → причина → однорядкове виправлення). Для навчального коду, рецензії чи тікета це самодостатнє пояснення, а не просто вердикт. Тут CoT збільшив якість подачі, а не сам факт знахідки.

Правило SE4. Для дебагу: «reason step by step about what happens, then state the bug, why, and the fix». Задавай і процес (трасування), і структуру фіналу. На складніших вадах (race, off-by-one у циклі) саме трасування часто й рятує.

SE5. Примус формату виводу

Принцип: найнадійніший спосіб прибрати «преамбулу» й markdown-обгортки — задати перший символ виводу (позитивний якір). Прямий контраст до DS4.

❌ Слабкий промпт

Convert this config to JSON: host=localhost port=5432 ssl=true

Реальний вивід Haiku:

```json
{
  "host": "localhost",
  "port": 5432,
  "ssl": true
}
```

This JSON object converts your configuration key-value pairs into a structured
format where: - `host` is a string... - `port` is converted to a number...

Правильний JSON, але в markdown-блоці + з поясненням після нього. Якщо це йде в JSON.parse() — впаде.

✅ Сильний промпт (якір першого символу)

Convert this config into a single JSON object. Output ONLY raw JSON starting with
the character '{' - no explanation and no markdown code fences. Use an integer
for port and a boolean for ssl.
Config: host=localhost port=5432 ssl=true

Реальний вивід Haiku (дослівно, повністю):

{"host": "localhost", "port": 5432, "ssl": true}

Що ми бачимо

48 символів проти 315. Голий JSON, без блоку, без коментаря — напряму в парсер. Ключова деталь: тут спрацювало те, що в DS4 не спрацювало. Різниця формулювань:

• DS4: «Output ONLY valid JSON, no markdown» → Haiku додав ```json.
• SE5: «starting with the character {, no markdown code fences» → Haiku дав голий {...}.

Правило SE5. Якоруй перший символ виводу («start with {»), а не лише забороняй обгортки. У реальному API ще надійніше — prefill: підстав { як початок відповіді асистента, і модель фізично не зможе додати преамбулу.

SE6. Контроль галюцинацій («дозвіл сказати не знаю»)

Принцип: модель схильна вигадувати правдоподібне замість «не знаю». Явний дозвіл сказати «цього не існує» + вимога не вигадувати знижує галюцинації. Тут — несподіваний і чесний результат.

Пастка: pandas.DataFrame.flatten() не існує (flatten є в numpy, не в DataFrame).

❌ Слабкий промпт

What does the pandas.DataFrame.flatten() method do? Explain its parameters and
return value.

Реальний вивід Haiku (скорочено):

I need to clarify an important point: pandas.DataFrame does not have a .flatten() method. You might be thinking of: NumPy's .flatten()... df.values.flatten()... .values.ravel()... .stack()... .melt()...

Haiku сам спіймав пастку навіть без захисної інструкції — і запропонував правильні альтернативи.

✅ Сильний промпт (дозвіл сказати «не знаю»)

What does the pandas.DataFrame.flatten() method do?
If this method does not actually exist in pandas, say so explicitly and do not
invent its behavior. Only describe it if you are confident it exists in the
pandas API.

Реальний вивід Haiku (скорочено):

The pandas.DataFrame.flatten() method does not exist in pandas. DataFrames in pandas do not have a flatten() method. You may be thinking of: numpy.ndarray.flatten()... DataFrame.values.flatten()... .to_numpy().flatten()... .stack()...

Що ми бачимо (чесний висновок!)

Обидва варіанти не галюцинували — Haiku 4.5 і так знає, що методу немає. Захисна інструкція зробила відповідь трохи прямішою й коротшою (826 проти 1153 символів), але не врятувала від галюцинації, якої й не було.

Чесний урок: сучасні моделі, навіть мала Haiku 4.5, стійкіші до простих фактологічних пасток, ніж припускають старі гайди. Техніка не марна. Її реальна цінність проявляється на:

• по-справжньому рідкісних/нішевих API та версіях,
• неоднозначних або суперечливих фактах,
• задачах із наданим контекстом, де треба відповідати тільки з нього («if the answer is not in the document, say I don't know»).

Правило SE6. Завжди давай моделі «вихід»: «if X does not exist / is not in the provided context, say so explicitly; do not invent». Не покладайся на те, що пастка «очевидна» — перевіряй на своїх рідкісних випадках, бо саме там техніка вмикається.

Вправи (Software Engineering)

1. SE1-вправа. Перепиши «write a rate limiter» за правилом SE1 для Python: яку сигнатуру, які 3 правила поведінки і яку заборону ти задаси?
2. SE2-вправа. У тебе промпт «here is my SQL fix the bug SELECT ...». Перепиши його з XML-тегами і додай вісь, на якій модель має зосередитись (напр. продуктивність).
3. SE5-вправа. Тобі треба, щоб модель повернула лише bash-команду без пояснень. Сформулюй якір першого символу. Чим це краще за «don't explain»?
4. SE6-вправа. Ти даєш моделі документацію й питаєш про функцію, якої в ній немає. Який рядок додаси в промпт, щоб уникнути вигаданої відповіді?

➡️ Відповіді — у 04-top-sajty-i-shpargalka.md.

Частина 3. Методологія та сирі результати

Цей файл відповідає на головне питання користувача: «як саме ви перевірили це на Haiku, а не вигадали?»

Що було зроблено

Запущено оркестрований workflow з 33 агентів:

• 30 прогонів моделі Claude Haiku 4.5 — 11 технік × 2 варіанти (слабкий/сильний), з них 2 техніки (DS2, SE3) прогнані по 3 рази кожен варіант для перевірки стабільності формату.
• 3 дослідницькі агенти — пошук і верифікація сайтів для навчання (результат — у файлі 04).

📦 Друга партія (+25 прогонів). Окремий workflow додав 12 прогонів на Sonnet 4.6 (порівняння) + 13 на Haiku (нові техніки й українські промпти). Результати й висновки — у частині 5.

📦 Третя партія (+49 прогонів, усе через підагентів, без raw-API). 40 прогонів на надійність формату (8 промптів × 5 семплів), 8 на антипатерни, 1 агент на WebFetch-перевірку URL. Так підагенти замінили перевірку через raw-API на N семплах. Результати — у частині 6.

📦 Четверта партія (+14 прогонів, крос-модельна). 7 прогонів на Opus 4.8 + 7 на Fable 5 (DS1 vague, DS4 «no markdown» ×5, SE6-пастка), щоб емпірично перевірити поведінкові твердження Частини 8. Haiku-баейзлайни взято з першої партії.

Разом по курсу: 118 модельних прогонів (Haiku 4.5 + Sonnet 4.6 + Opus 4.8 + Fable 5). Єдине джерело правди для цього числа — raw-outputs/runs-manifest.json (батч → скрипт → вихід → кількість), щоб не звіряти суму вручну по файлах.

🔍 Перевірка актуальності (2026-08-21). Окремим проходом курс звірено з живими доксами: механіка API Частини 8 — 11/11 підтверджено; ціни/ліміти трьох моделей — без змін; 10/10 URL живі. Виправлено: формулювання про CoT-display у Fable, облік посилань (9→10), додано нотатку про Opus 5 / Sonnet 5.

Як проганявся кожен приклад

Кожному Haiku-агенту давали обгортку, що змушувала його відповідати як звичайна LLM-модель (без інструментів, без мета-коментарів), а всередині — тестований промпт у тегах <user_message>. Структурований вивід ({response: string}) гарантував, що ми зчитуємо саме відповідь моделі дослівно.

Чому не «raw API»

Найчистіша перевірка — прямі HTTP-виклики до api.anthropic.com з model: claude-haiku-4-5-.... Це не вдалося, бо в системі немає API-ключа (ANTHROPIC_API_KEY не встановлено, пакета anthropic немає, CLI відсутній — перевірено на старті).

Тому перевірка йшла через Haiku 4.5 у гарнесі агента. Базова модель — справжня Haiku 4.5, тож її відповіді справжні. Але є нюанс ⬇️.

Застереження

Будь чесним щодо меж цього методу:

1. Тонке «забруднення» системним промптом. Агент-гарнес має власний системний промпт. Ми просили модель «відповідай як звичайний асистент», але повної ізоляції, як у raw-API-виклику, немає.
2. Доказ забруднення в даних. Прогін SE3 weak #1 протік рядок Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>. Цей рядок походить з інструкцій гарнесу про git-коміти, а не з «творчості Haiku». Я свідомо лишив його у файлі 02 як живу ілюстрацію цього застереження.
3. «Роль у system» апроксимована. У DS5 роль передана в тексті промпта, а не в окремому system-полі (через API було б трохи сильніше).
4. Семплінг. Температура/семплінг — за замовчуванням гарнесу. Тому 3-разові прогони DS2/SE3 — це індикація стабільності, а не строгий статистичний експеримент.

Висновок: напрям і величина ефектів — справжні й відтворювані. Точні формулювання відповідей можуть трохи відрізнятися від raw-API. Для навчальних цілей це повноцінна емпірична перевірка; для наукової публікації — варто повторити через raw-API з фіксованими temperature і seed/кількома семплами.

Зведена таблиця всіх прогонів

Δ символів = довжина(сильний) − довжина(слабкий). Знак показує напрям, а не «краще/гірше» (іноді сильний має бути довшим — як у CoT).

Об'єктивні метрики стабільності (3 прогони)

Три крос-висновки, які дала саме перевірка (а не теорія)

1. Якір першого символу > заборона обгортки. SE5 («start with {») дав голий JSON; DS4 («no markdown») — ні, попри схожу мету. Це видно тільки на реальних прогонах.
2. Сильний промпт регулює обсяг в обидва боки. SE1/SE5/DS2 — коротше; DS3/SE2/SE4 — довше. Мета не «менше токенів», а «правильний обсяг під задачу».
3. Не всі «класичні» техніки дають великий ефект на сучасній Haiku. SE6 (анти-галюцинації на очевидній пастці) майже не змінив поведінку — модель і так не вигадувала. Техніку треба перевіряти на своїх складних випадках, а не на хрестоматійних.

Повторна перевірка 2026-09-19: що виправлено

Усі 14 файлів курсу ще раз звірено з першоджерелами: 60+ тверджень перевірено запитами до офіційних доксів, arXiv і блогів, числа ядра — із сирими JSON. Ядро 1–8 (виміряні числа) помилок не має: DS2, SE1, DS3, DS4, SE5, N=5 і Opus/Fable збіглися з raw-outputs/. Виправлено таке.

Фактичні неточності (11):

1. Ч.11: цитату Anthropic «consistently underperforms» вигадав дослідницький агент. У джерелі сказано інше: підагенти, розділені за ролями, витрачали більше токенів на координацію, ніж на роботу.
2. Ч.13: знак нібито змінювався в «MoE-гейтах». Насправді це вхід гейта SwiGLU у щільних 7–9B моделях.
3. Ч.13: «GGUF має CPU-шлях у vLLM» — за матрицею vLLM не має. CPU-шлях є в AWQ/GPTQ (x86) та INT8.
4. Ч.13: «EU AI Act повністю застосовний із серпня 2026» — застосовний з винятками; правила для високоризикових систем перенесено на 2.12.2027 і 2.08.2028.
5. Ч.10: 630 рядків у Karpathy — це код моделі й навчання, який правив агент, а не «оркестраційний Python». Приріст — мінус 11% часу навчання.
6. Ч.9: цитату DeepSeek про few-shot приписано картці моделі, а вона зі статті R1.
7. Ч.1, 4, 6, 7, README: prefill подано як «гарантований формат». Гарантію дають лише structured outputs (output_config.format), і вони є навіть на Haiku 4.5.
8. Ч.9, 13: «у локальних стеків немає схемного режиму» — Ollama (format) і llama.cpp (json_schema/grammar) його мають.
9. Ч.7: драбину позначено «виміряно на Haiku», хоча prefill ми не вимірювали.
10. Ч.9: «наш DS4/SE5» нібито використовували prefill — ні, там був якір у тексті промпта.
11. Ч.11: «3–15× на власній шкурі» — без одноагентного бейзлайна цей множник ми не виміряли.

Застаріло після 2026-08-21 (5): вийшов Claude Fable 5.1, а Fable 5 став Legacy (Ч.8); OpenAI рекомендує GPT-6 Astra (Ч.4, 9); вийшла Gemma 4 (Ч.13); читання кешу на Fable 5.1 коштує 0.025× (Ч.12); Python SDK 1.0+ не приймає temperature. Через останнє виправлення туторіалу Anthropic тепер займає два рядки (Ч.4), а кроки відтворення нижче фіксують anthropic<1 (перевірено локально: SDK 1.7.0 дає TypeError, 0.125.0 працює).

Текст: 53 мовні порушення (транслітерації, ланцюги родового), неправильне слово в таблиці 12.3, граматика в 12.4, особисте звертання в 12.4. Джерела частин 9–13 стали посиланнями, у кожній частині зʼявився перелік перевірених джерел.

Перевірено й підтверджено без змін (вибірково): METR (16 розробників, 246 задач, −19%), DORA 2025, SpecBench, TDAD, SDD, NoLiMa, Chroma, EMNLP-2025, «selection bottleneck», Adversarial Review, Cognition 2025/2026, дослідницька система Anthropic (90.2%, 15×), 20 паралельних підагентів і 3 рівні вкладеності в Claude Code, Stop-hook із 8 блокуваннями, compaction (150K/50K), memory tool, кеш 0.1×/1.25×/2×, Qwen3.8-27B, DeepSeek V4, gpt-oss.

Повторна перевірка 2026-09-24: що виправлено

Мовний лінтер отримав нові правила 23.09, а 22.09 вийшли нові моделі. Тому курс перевірено ще раз.

Фактичні неточності (6):

1. Ч.13: Willison цитувався неточно. Насправді він пише «wildly outperforming expectations» і наводить приклад із пеліканом. Порівняння з «моделями попереднього покоління» в нього немає.
2. Ч.13: MLX-кванти Qwen3.8 викладає спільнота mlx-community, а не сам Qwen. Твердження «сотні квантів у день випуску» ми не підтвердили й прибрали дату.
3. Ч.13: рядок «у локальних моделей немає structured outputs» суперечив виправленню від 19.09. Схемний режим в Ollama і llama.cpp є, але гарантує лише синтаксис.
4. Ч.8: у Haiku 4.5 «сирий chain-of-thought видно» — ні. Жодна модель не повертає сирі міркування, Haiku типово повертає підсумок.
5. Ч.8: temperature на Opus 4.8 і Fable дає 400 лише з нестандартним значенням, а не з будь-яким.
6. Ч.4: «гайд Willison не оновлювався з квітня 2026» перевірити не вдалося. Формулювання пом'якшено до того, що видно на сторінці.

Застаріло після 19.09 (3): 22.09 вийшов Claude Opus 5.5 (4/20, мислення завжди увімкнене, типовий effort medium), а Opus 5 став Legacy (Ч.4, 8, 9, 12, README). OpenAI додала GPT-6 Sol і Luna, які приймають temperature лише з reasoning_effort: none (Ч.9). DeepSeek 10.09 випустила V4.1-Flash (Ч.13).

Мова: 101 знахідка за новими правилами лінтера та 7 в архівному аудиті. Терміни тепер однакові в усьому курсі: bug → вада, review → рецензування, validation → перевірка, pipeline → конвеєр, default → типово. AUDIT_REPORT.md позначено як архівний знімок від 28.06.

Перевірено й підтверджено без змін: harness-пост Anthropic (init.sh, claude-progress.txt, аналогія зі змінами), пост про контекст-інжиніринг (визначення, Pokémon, 1–2 тис. токенів, JIT), цитата Karpathy у Willison, Managed Agents, gpt-oss, Gemma 3, Llama 4 як остання номерна Llama, ціна Sonnet 5, fallback і його платформи, вимога зберігати дані Fable 30 днів, дата, коли виведуть Haiku 4.5.

Як відтворити

Скрипт workflow збережено тут (можна редагувати й перезапускати):

/Users/bibo/.claude/projects/-Users-bibo-----------------/6085e5a9-e68d-4d94-b342-029a5542f2fa/workflows/scripts/haiku-prompt-eng-validation-wf_c3699d75-208.js

Повний JSON усіх 30 відповідей + 16 сайтів:

/private/tmp/claude-501/-Users-bibo-----------------/6085e5a9-e68d-4d94-b342-029a5542f2fa/tasks/w5zg0ukbt.output

Друга партія (Haiku-vs-Sonnet, нові техніки, UK) — скрипт і повний JSON:

.../workflows/scripts/haiku-course-extensions-wf_a092010c-2f6.js
/private/tmp/claude-501/.../tasks/w67fx5rvi.output

Третя партія (надійність N=5, антипатерни, URL) — скрипт і повний JSON:

.../workflows/scripts/haiku-stability-antipatterns-wf_ad6c2be1-0db.js
/private/tmp/claude-501/.../tasks/wv5azqjjf.output

Для строгого відтворення через raw-API (рекомендовано для публікації):

1. Встанови ключ: export ANTHROPIC_API_KEY=... і pip install "anthropic<1". Версія важлива: Python SDK 1.0+ не приймає temperature (TypeError, перевірено 2026-09-19), а кроки 2–3 його використовують.
2. Для кожної пари промптів виклич messages.create(model="claude-haiku-4-5-...", max_tokens=1024, temperature=0).
3. Для тестів стабільності (DS2, SE3) зроби temperature=0.7 і N=5 семплів, порахуй частку унікальних і коректних форматів.
4. Для DS4/SE5 додай prefill (messages=[..., {"role":"assistant","content":"{"}]) і переконайся, що преамбула зникає.

Частина 4. Топ-3 сайти, шпаргалка та відповіді

🏆 Топ-3 сайти для навчання промт-інжинірингу

Відібрано дослідницькими агентами; посилання перевірені WebFetch'ем на доступність І на свіжість змісту (2026-08-21). Критерії: авторитетність, актуальність, практичність і покриття обох доменів (DS + SWE).

⚠️ Доступність ≠ актуальність. Серпнева перевірка показала: усі 10 посилань відкриваються, але зміст деяких застарів. Нижче кожен ресурс має чесну позначку свіжості.

1. Anthropic — Prompting Best Practices (офіційні докси Claude) — ✅ актуальний

🔗 https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices

Офіційний, постійно оновлюваний довідник: чіткість, приклади, XML-структурування, tool use, extended/adaptive thinking, агентний промптинг — з нотатками під конкретні моделі. №1, бо це єдине джерело, яке не застаріває: воно оновлюється разом із моделями (перевірено 2026-09-24 — містить Opus 5.5, Sonnet 5 і Fable 5.1). Кому: усім, хто пише промпти під Claude; обов'язково — розробникам на API.

2. Prompt Engineering Guide — DAIR.AI — ✅ актуальний

🔗 https://www.promptingguide.ai/

Найбільш цитований відкритий гайд, що активно оновлюється. Дистилює дослідницькі техніки (chain-of-thought, few-shot, RAG, ReAct, агенти) з нотатками під конкретні моделі. Розділ Applications покриває і DS (генерація даних, синтетичні датасети, класифікація), і SWE (генерація коду, агенти). №2, бо це найкращий крос-доменний референс, не прив'язаний до вендора. Кому: усім, хто хоче зрозуміти техніки «з-під капота», що переносяться між моделями.

3. Anthropic Interactive Prompt Engineering Tutorial (GitHub) — ⚠️ потребує правки перед запуском

🔗 https://github.com/anthropics/prompt-eng-interactive-tutorial

Єдиний ресурс топу, де ти сам проганяєш промпти в Jupyter і бачиш різницю на дотик. 9 розділів + додатки; концепції (чіткість, XML-теги, роль, few-shot, CoT, анти-галюцинації, chaining/tool-use/RAG) — досі чинні й майже дослівно збігаються з тим, що ми виміряли в цьому курсі.

🔧 Але з коробки він НЕ запуститься. Ноутбуки жорстко зашиті на claude-3-haiku-20240307, яку Anthropic зняла з експлуатації 20 квітня 2026 («Requests to retired models will fail»). Репозиторій не оновлювався з квітня 2024. Виправлення — два рядки. (1) Заміни у ноутбуці модель:

MODEL_NAME = "claude-3-haiku-20240307"   # ❌ retired
MODEL_NAME = "claude-haiku-4-5-20251001" # ✅ офіційна заміна

(2) Зафіксуй SDK: заміни !pip install anthropic на !pip install "anthropic<1". Причина: з версії 1.0 Python SDK узагалі не приймає temperature — temperature=0.0 у get_completion() дає TypeError (перевірено локально 2026-09-19: SDK 1.7.0 падає, 0.125.0 працює). Альтернатива — прибрати temperature=0.0 з усіх викликів; на Opus 4.7+/Fable це однаково обовʼязково, бо там нестандартний temperature → 400 (див. Частину 8).

Кому: тим, хто вчиться руками і не боїться дворядкової правки.

Якщо обирати один: почни з #1 (не застаріває) → #2 для глибини технік → #3, коли захочеш практики (після заміни моделі).

Додаткові сайти за доменами (бонус)

Для Data Science

• The Data Scientist's Prompt Playbook (Towards Data Science) — ⚠️ стаття від 30.06.2025 — copy-paste промпти й pandas-снипети для planning / cleaning / EDA. Техніки чинні, але моделі, які вона називає (GPT-4, o3-pro), уже застаріли — не бери її як орієнтир щодо вибору моделі. 🔗 https://towardsdatascience.com/become-a-better-data-scientist-with-these-prompt-engineering-hacks/
• Advanced Prompt Engineering for DS (частина 2) — ⚠️ стаття від 19.08.2025 — feature engineering, вибір моделі/AutoML, LLM-оцінка з JSON/CSV-схемами. Обережно з порадою «тримай temperature ≤ 0.3»: на сучасних Claude (Opus 4.7+, Fable 5) нестандартний temperature повертає 400 — там детермінізм задають промптом і effort (див. Частину 8). 🔗 https://towardsdatascience.com/advanced-prompt-engineering-for-data-science-projects/
• promptingguide.ai/applications — ✅ актуальний — data generation, синтетичні датасети, класифікація. 🔗 https://www.promptingguide.ai/applications

Для Software Engineering

• Best practices for Claude Code (Anthropic) — ✅ актуальний — офіційний плейбук агентного кодингу: explore-plan-code-commit, верифіковані перевірки, CLAUDE.md, subagents, рецензування. 🔗 https://code.claude.com/docs/en/best-practices
• Effective context engineering for AI agents (Anthropic Engineering) — ✅ актуальний — керування контекстним вікном (just-in-time loading, compaction, sub-agents). 🔗 https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
• Agentic Engineering Patterns (Simon Willison) — ⚠️ дат оновлення на сторінці немає; найсвіжіший приклад, який ми знайшли в розділах, датований квітнем 2026 — практичні патерни агентного кодингу, TDD для агентів. Методологія не застаріває, але приклади моделей — на покоління позаду. Читай живий покажчик, а не анонс: https://simonwillison.net/guides/agentic-engineering-patterns/ 🔗 https://simonwillison.net/2026/Feb/23/agentic-engineering-patterns/ (анонс)
• OpenAI Prompt Engineering Guide — ✅ актуальний (оновлений під GPT-6; перевірено 2026-09-24) — якщо працюєш і з OpenAI-моделями: кодинг, frontend, агентні робочі процеси. 🔗 https://developers.openai.com/api/docs/guides/prompt-engineering

Ресурси Модуля 2026 (Частини 9–13, перевірені при дослідженні 2026-08)

• Промптинг reasoning-моделей: OpenAI Reasoning Best Practices — https://developers.openai.com/api/docs/guides/reasoning-best-practices
• Автоматизована розробка: DORA 2025 — https://dora.dev/research/2025/dora-report/ · METR RCT — https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/ · Effective harnesses (Anthropic) — https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents
• Мультиагенти: Anthropic multi-agent research system — https://www.anthropic.com/engineering/multi-agent-research-system · Cognition «Don't Build Multi-Agents» — https://cognition.com/blog/dont-build-multi-agents · Claude Code sub-agents — https://code.claude.com/docs/en/sub-agents
• Контекст агентів: Chroma «Context Rot» — https://www.trychroma.com/research/context-rot · Harness engineering (Fowler/Böckeler) — https://martinfowler.com/articles/harness-engineering.html
• Локальні LLM: llama.cpp quantize README — https://github.com/ggml-org/llama.cpp/blob/master/tools/quantize/README.md · vLLM quantization — https://docs.vllm.ai/en/latest/features/quantization/ · Willison local-llms — https://simonwillison.net/tags/local-llms/

Перевірка 2026-08-21: усі 10 посилань живі; додатково перевірено зміст кожного. Результат: 6 — актуальні, 3 — старіють (позначено ⚠️), 1 — потребує правки перед запуском (туторіал Anthropic; з 2026-09 — у два рядки, див. вище). Історія перевірок доступності — у Частині 6.

Шпаргалка: 13 принципів

Згруповано за тим, що виміряно в цьому курсі.

Чіткість і структура

1. Завжди давай: дані+типи, ціль, контекст, формат відповіді. (DS1)
2. Розділяй частини промпта XML-тегами: <task>, <code>, <data>. (SE2)
3. Обмежуй обсяг явно: «exactly 5 bullets», «output only the code». (DS1, SE1, SE3)

Приклади (найнадійніший важіль формату) 4. Хочеш стабільний формат — дай 2–5 few-shot прикладів «вхід → вихід». (DS2, SE3) 5. Приклади > опис. На малих моделях це усуває «балакучість». (DS2)

Міркування 6. Для задач на судження — «think step by step, then give your final answer». (DS3) 7. Для дебагу — проси трасування виконання перед вердиктом. (SE4) 8. Задавай і процес, і структуру фіналу (вада → причина → виправлення). (SE4)

Формат виводу 9. Якоруй перший символ («start with {») — надійніше за «no markdown». (SE5 vs DS4) 10. Гарантований формат дає лише structured outputs (output_config.format; на Claude працює і з Haiku 4.5). Prefill задає тільки перший токен, а на Claude 4.6+ повертає 400. (DS4, Ч.9) 11. Задавай JSON-схему: ключі, типи, поведінку для null. (DS4)

Роль і чесність 12. Роль + контекст + обмеження разом (роль сама по собі слабка). (DS5) 13. Завжди давай «вихід»: «if X is not in the context / does not exist — say so, don't invent» — і перевіряй на своїх рідкісних випадках. (SE6)

➕ Принципи 14–17 (reasoning-моделі 2026) — у Частині 9.7; ресурси пʼяти нових напрямів — нижче.

Відповіді до вправ

Data Science

1. DS1. Чотири елементи: (1) дані+типи — transactions(user_id int, amount float, timestamp datetime, is_fraud 0/1); (2) ціль — «predict is_fraud»; (3) контекст — клас рідкісний (~0.5%), дані часові (ризик витоку через майбутнє); (4) формат — «in 4 bullets: одна ознака, baseline, метрика, ризик leakage».
2. DS2. Мінімум 3 приклади — по одному на клас (BUG, FEATURE, QUESTION), бо модель має побачити межу кожної категорії хоча б раз. Плюс інструкція «output only the label». Для неоднозначних класів — 2 приклади на клас.
3. DS4. «Позитивний якір першого символу виводу (start with {) надійніший за негативну заборону (no markdown)»: модель легше виконує конкретну дію, ніж утримується від звички обгортати код у блоки.
4. DS5. You are explaining to a non-technical product manager. Avoid statistical jargon; in 3 sentences explain what a p-value tells us about whether an A/B test result is likely real or just noise, and one common misinterpretation to avoid.

Software Engineering

1. SE1. Сигнатура def allow_request(self, key: str) -> bool; 3 правила: (1) ліміт N запитів за вікно T секунд на ключ, (2) sliding window, (3) повертати False при перевищенні без винятку; заборона: «do not use external libraries, use only stdlib time and a dict». Формат: «output only the class».
2. SE2.

   <task>
   Find and fix the bug in the query inside <sql>. Focus on performance:
   check for missing index usage, full scans, and N+1 patterns.
   </task>
   <sql>
   SELECT ...
   </sql>

   Вісь фокусу (performance) скеровує рецензію — інакше модель може зачепитись за стиль.
3. SE5. Output ONLY the bash command, starting with the command name. No explanation, no markdown, no backticks. Краще за «don't explain», бо задає позитивну дію (почни з імені команди), а не лише заборону — модель легше виконує конкретний старт виводу, ніж стримує звичку пояснювати.
4. SE6. Answer ONLY using the provided documentation. If the function is not described in the documentation above, reply exactly: "Not found in the provided docs." Do not use outside knowledge or invent behavior.

Підсумок одним абзацом

Промт-інжиніринг — не «магічні слова», а інженерна дисципліна з вимірюваним ефектом. Кожне правило курсу підкріплене реальним прогоном на Claude Haiku 4.5. Few-shot робить формат детермінованим (1 унікальна відповідь замість 3). Якір першого символу б'є заборону обгортки. CoT перетворює вердикт на обґрунтування. А деякі «класичні» техніки на сучасній моделі дають менший ефект, ніж обіцяють старі гайди. Тож перевіряй їх на власних задачах, а не приймай на віру.

Частина 5. Розширення: Haiku vs Sonnet, нові техніки та українські промпти

Ця частина відповідає на три питання: (1) наскільки промпт-інжиніринг важливіший на малій моделі, ніж на великій; (2) чи працюють складніші техніки (RAG-grounding, prompt chaining, вкладений JSON); (3) чи можна писати промпти українською. Підкріплено 25 прогонами (12 на Claude Sonnet 4.6 для порівняння + 13 на Haiku 4.5). Haiku-сторона порівняння взята з Частини 1 (той самий промпт/модель) — заново ганявся лише Sonnet, щоб дані лишались узгодженими.

A. Haiku vs Sonnet 4.6 — де промпт-інжиніринг важливіший

Головна теза, яку треба було довести: на меншій моделі (Haiku) якість промпта впливає сильніше. Більша модель (Sonnet) має кращі типові припущення і частково рятує слабкий промпт сама.

Таблиця порівняння (той самий промпт на обох моделях)

Ключовий доказ — DS4 (заборона markdown)

Той самий сильний промпт «Output ONLY valid JSON, no markdown»:

Haiku 4.5:

```json
{ "revenue_musd": 4.2, ... }
```

Sonnet 4.6:

{"revenue_musd":4.2,"revenue_growth_yoy_pct":12,"churn_rate_pct":3.1,"new_customers":540}

Sonnet виконав негативну заборону, Haiku — ні. Так емпірично підтверджується правило SE5: на меншій моделі покладайся на позитивний якір («start with {») або на structured outputs API, а не на заборону. Саме малій моделі бракує «дисципліни» дотриматись заборони.

DS1 — Sonnet «прощає», Haiku — ні

На vague-промпті «Analyze this dataset and tell me what to do. Columns: age, income, churned»:

• Haiku: «I don't have access to the actual data... Could you please share...» — відмова.
• Sonnet: одразу видав план (перевір пропуски → розподіли → churn rate → logistic/tree → AUC-ROC) і лише потім попросив деталі.

Висновок розділу A. Промпт-інжиніринг дає найбільший приріст саме на Haiku. На Sonnet добрі типові припущення маскують слабкий промпт, тож виграш від техніки менш помітний — але не зникає. Практично: якщо економиш на моделі (Haiku — швидша й дешевша), компенсуй це якістю промпта. Few-shot і строгий формат потрібні обом, але Haiku «карає» за їх відсутність сильніше.

B. Нові техніки (перевірено на Haiku 4.5)

B1. RAG-grounding — відповідай лише з наданого документа

Документ (навмисно НЕ містить відповіді про free trial):

ACME Cloud pricing: the Starter plan costs 19 USD/month (10 GB, email support). The Pro plan costs 49 USD/month (100 GB, priority support).

Питання: «Does ACME Cloud offer a free trial, and how long?»

❌ Без grounding-інструкції — реальний Haiku:

Based on the document provided, there is no information about whether ACME Cloud offers a free trial... To find this you would need to check ACME Cloud's website, contact their sales team...

✅ З інструкцією «Answer ONLY using the document. If not stated, reply exactly: NOT IN DOCUMENT» — реальний Haiku:

NOT IN DOCUMENT

Що ми бачимо: Haiku 4.5 і без інструкції не вигадав free trial (чесно сказав «немає інформації») — ще одне підтвердження стійкості сучасної моделі. Але строга версія дала машинно-читаний sentinel NOT IN DOCUMENT, який можна напряму ловити в коді RAG-конвеєра. Для продакшену це критично.

Правило B1. У RAG завжди задавай sentinel для «немає відповіді» («reply exactly: NOT IN DOCUMENT») + «do not use outside knowledge». Це і знижує галюцинації, і дає програмно-детектований сигнал «нема відповіді».

B2. Long-context — позиція інструкції

Текст із 7 рядків, «голка»: the internal API rate limit is 240 requests per minute. Питання — знайти ліміт.

• Інструкція перед текстом → Haiku: 240 requests per minute ✅
• Інструкція після тексту → Haiku: 240 requests per minute ✅

Чесний висновок: на короткому контексті різниці немає — обидва варіанти знайшли факт. Ефект позиції інструкції проявляється на довгому контексті (десятки тисяч токенів), де рекомендація Anthropic — класти запит/інструкцію в кінець, після документів. Тут ми це не відтворили через брак довжини; правило лишається чинним для великих документів, але на малих — не морочся.

Правило B2. Для довгих документів (10k+ токенів) клади інструкцію/питання після контенту. На коротких вхідних — позиція не має значення (виміряно).

B3. Prompt chaining — декомпозиція замість «зроби все одразу»

Завдання: брудний звіт про ваду → план виправлення.

❌ Монолітно («here's a bug report, fix it») — Haiku видав акуратний переформатований репорт + список напрямів для розслідування. Корисно, але це радше тріаж, ніж план.

✅ Ланцюжок (2 кроки):

• Крок 1 (екстракція в JSON) — реальний Haiku:

  { "component": "export button on reports page", "browser": "safari",
    "severity": "high", "repro": ["Navigate to reports page", "Click export button",
    "Observe no action occurs"], "regression_window": "after friday deploy" }

• Крок 2 (на основі JSON → план) — реальний Haiku видав структурований 3-кроковий fix-and-verify план: ізолювати причину (diff п'ятничного деплою, Safari DevTools) → точкове виправлення (polyfill / відновити handler) → регресійна верифікація на Safari+Chrome, з оцінкою «20–45 хв».

Що ми бачимо: ланцюжок дав (а) структурований проміжний артефакт (JSON), який можна програмно роутити/зберігати, і (б) сфокусованіший фінал. Кожен крок — проста задача, де менша модель помиляється рідше, ніж у одному великому промпті.

Правило B3. Складну задачу розбивай на ланцюжок простих промптів (extract → reason → format). На Haiku це особливо вигідно: маленькі чіткі кроки > один великий «зроби все». Проміжний структурований вивід — бонус для автоматизації.

B4. Вкладений структурований JSON

Промпт зі схемою {customer:{name,tier}, order:{id, items:[], total_usd}} + якір «start with {». Речення: «Jane Doe (gold tier), order A19, 2 widgets and 1 gadget, total 57.50 USD».

✅ Реальний Haiku:

{ "customer": {"name": "Jane Doe", "tier": "gold"},
  "order": {"id": "A19", "items": ["widget","widget","gadget"], "total_usd": 57.50} }

Haiku коректно: побудував вкладену структуру, розгорнув «2 widgets and 1 gadget» у масив ["widget","widget","gadget"], дав правильні типи. Якір першого символу спрацював — без ```.

Правило B4. Haiku справляється з вкладеним JSON, якщо дати явну форму схеми прямо в промпті + якір першого символу. Для критичних конвеєрів — додай перевірку за схемою на виході.

C. Українські промпти на Haiku 4.5

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

C1. Few-shot класифікація українською — формат тримається ідеально

Промпт із мітками ПОЗИТИВНА / НЕГАТИВНА / ЗМІШАНА, 3 прогони:

ЗМІШАНА
ЗМІШАНА
ЗМІШАНА

1 унікальна відповідь із 3 — рівно так само стабільно, як англійський few-shot (MIXED ×3). Висновок: механіка few-shot працює українською без втрат.

C2. Роль/персона українською — суть сильна, але є мовні зриви

Україномовний промпт «ти — senior data scientist...» дав змістовно відмінну пораду: врахувати MNAR, додати ознаку income_missing, імпутувати окремою моделлю й додати шум пропорційно невизначеності, розшарувати аналіз. Якість на рівні англійського DS5.

АЛЕ у тексті є мовні дефекти від моделі:

• русизм: «высокозаробітних» (рос. «высоко» замість укр. «високо»),
• орфографія: «новий порожний список» (треба «порожній»),
• «з поважою» (треба «з повагою»).

C3. Пошук вади українською — бездоганна логіка, дрібний зрив

Україномовний CoT-промпт дав повністю коректний розбір mutable-default argument з трасуванням 3 викликів і однорядковим виправленням — нарівні з англійським SE4. Знову один зрив: «новий порожний список».

Висновок розділу C (практичний для дисертації/україномовних задач)

Правило C. Українською можна й варто писати промпти — логіка й формат не страждають. Але готовий україномовний текст від Haiki треба вичитувати на русизми/орфографію перед використанням у дисертації чи публікації. Дві практичні стратегії:

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

Зведення (об'єктивні метрики)

Підсумок: промпт-інжиніринг найцінніший саме на Haiku; нові техніки (RAG-sentinel, chaining, nested JSON) на Haiku працюють; українська — повноцінно придатна для промптів, з обов'язковою вичиткою фінального тексту.

Вправи (Частина 5)

1. B1-вправа (RAG). Ти будуєш бота підтримки на базі бази знань. Який рядок-sentinel ти задаси для «відповіді немає в документі» і чому машинний sentinel кращий за «вибач, я не знаю»?
2. B2-вправа (long-context). У тебе документ на 40k токенів і питання до нього. Куди покласти питання — на початок чи в кінець — і чому на короткому тексті це не має значення?
3. B3-вправа (chaining). Розбий задачу «перетвори сирі відгуки користувачів на JIRA-тікети» на ланцюжок із 2 кроків. Який проміжний артефакт повертає крок 1?
4. B4-вправа (nested JSON). У NESTED-тесті Haiku по-різному трактував «2 widgets» (2/5 розгорнув, 3/5 ні). Який один рядок ти додаси в промпт, щоб прибрати цю неоднозначність?
5. C-вправа (UK). Ти генеруєш україномовний розділ дисертації через Haiku. Які два кроки робочого процесу гарантують відсутність русизмів у фіналі?

Відповіді (Частина 5)

1. Sentinel на кшталт NOT IN DOCUMENT (точний фіксований рядок). Машинний sentinel кращий, бо його можна детектувати кодом (if resp == "NOT IN DOCUMENT"). Вільне «вибач, я не знаю» щоразу формулюється інакше й не парситься, тож RAG-конвеєр не зрозуміє, що відповіді немає.
2. Питання — в кінець, після документів (рекомендація для довгого контексту). На короткому тексті (як наш 7-рядковий) різниці немає, бо модель «бачить» увесь вхід цілком; ефект позиції зростає з довжиною, коли початок контексту «розмивається».
3. Крок 1: екстракція в структуру — {summary, severity, component, steps} (JSON). Крок 2: на основі цього JSON згенерувати оформлений тікет. Проміжний артефакт — структурований JSON, який можна перевірити й маршрутизувати перед другим кроком.
4. Явна вказівка трактування кількості, напр.: «expand quantities so each unit is a separate array element» (або навпаки — «keep the quantity in the string»). Неоднозначна специфікація → різні прогони дають різне.
5. (1) генеруй чернетку українською (логіка й формат не страждають); (2) окремим проходом перевір мову на русизми/орфографію — або інструкцією «пиши бездоганною академічною українською, уникай русизмів», або зовнішнім інструментом вичитки.

Частина 6. Надійність формату (N=5) та антипатерни

Ця частина перетворює «працює/не працює» на число: наскільки надійний формат сильного промпта при повторних прогонах, і які антипатерни ламають вивід. Підкріплено 49 прогонами через суб-агентів (raw-API не використовувався, бо нема ключа): 40 прогонів на стабільність (8 промптів × 5), 8 на антипатерни, 1 агент на пере-перевірку URL.

Це заміна того, що зазвичай дає raw-API з N семплів — але зроблена суб-агентами на Haiku 4.5.

A. Наскільки надійний «сильний» промпт? (кожен × 5 прогонів)

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

Таблиця надійності формату

Що показали реальні прогони

100% надійні техніки (закритий набір/sentinel/якір):

DS2 strong → MIXED · MIXED · MIXED · MIXED · MIXED
RAG strong → NOT IN DOCUMENT · NOT IN DOCUMENT · ... (×5)
SE5 strong → {"host":"localhost","port":5432,"ssl":true}   (×5, голий JSON)

~80% — негативна заборона протікає. DS4 з інструкцією «Output ONLY valid JSON, no markdown» — 4 рази голий JSON, але на 3-му прогоні:

```json
{ "revenue_musd": 4.2, ... }
```

1 із 5 (20%) порушень. Це кількісне підтвердження правила SE5/DS4: негативна заборона на малій моделі протікає ~20%, тоді як позитивний якір (SE5) — 0% протікань.

SE3 — формат тримається, але «one line» не гарантовано. Усі 5 у конвенції type(scope):, проте на 1-му прогоні замість одного рядка вийшло два коміти:

feat(api): add retry logic to client

fix(docs): fix typo in README

Інструкцію «output only the subject line» дотримано 4/5. Урок: навіть few-shot не дає 100% на структурних обмеженнях — для гарантії додавай явне «exactly one line, no body».

NESTED — структура ідеальна, а ось семантика «плаває». Усі 5 — коректний вкладений JSON. Але «2 widgets and 1 gadget» Haiku інтерпретував непослідовно:

• 3/5: "items": ["2 widgets", "1 gadget"] (залишив кількість у рядку)
• 2/5: "items": ["widget", "widget", "gadget"] (розгорнув у окремі елементи)

Це не вада моделі, а неоднозначність промпта — ми не сказали, як трактувати кількість. Урок: якщо специфікація допускає два прочитання, модель обере по-різному на різних прогонах. Виправлення: «expand quantities so each unit is a separate array element» (або навпаки).

Контроль: слабкий промпт — нестабільний (як і має бути)

DS2 weak (zero-shot) — 5/5 унікальних багатослівних відповідей, мітка плаває: mixed → neutral-to-positive → cautiously positive. Підтверджує, що нестабільність — властивість слабкого промпта, а не моделі.

⚠️ Нюанс по SE3 weak (чесна звірка N=5). На відміну від DS2 weak, у SE3 weak всі 5 прогонів дали однаковий рядок-тему «Add retry logic to API client and fix README typo» — нестабільним був лише формат тіла (то bullet-и, то абзац). Слабкий промпт тут нестабільний за структурою, але не за змістом теми. Це уточнює приклад SE3 у Частині 2: головна цінність few-shot — не «вгадати тему» (її модель і так тримає), а замкнути формат в один рядок type(scope):.

Підсумок А: рейтинг надійності технік формату на Haiku

Головне правило надійності. Для критичного формату на малій моделі бери техніку рангу 1 (закритий набір / sentinel / якір). Якщо потрібні 100.0% — у реальному API вмикай structured outputs (output_config.format, є і на Haiku 4.5). Без них — prefill (лише Haiku 4.5 і старші) + перевірка виходу за схемою і повторний прогін на провалі. На самих інструкціях стелі ~80–100% залежно від типу обмеження.

B. Антипатерни — як НЕ треба писати промпти

Кожен поганий промпт реально прогнано на Haiku + виправлена версія. Дивимось, що ламається.

AP1. Суперечливі інструкції

❌ «Write a comprehensive, in-depth guide to database indexing... Limit your answer to a single short sentence.»

Реальний Haiku:

Database indexing speeds up queries by creating data structures that organize records, but slows writes and consumes memory.

Що сталося: модель мовчки обрала одне обмеження (одне речення) і викинула інше (вичерпний гайд). Вона не повідомила про конфлікт — ти просто втрачаєш контроль над тим, який бік переможе.

✅ Виправлення: «In one sentence, state the single most important thing... about database indexing.» — жодного конфлікту, передбачуваний результат.

Правило: не клади взаємовиключні вимоги в один промпт. Якщо є trade-off (стисло vs повно) — вибери явно.

AP2. Лише заборони, без позитивної вказівки

❌ «Explain gradient descent. Don't be vague. Don't use jargon. Don't write too much. Don't oversimplify. Don't be boring.»

Реальний Haiku: дав гарну відповідь з аналогією туману на схилі — АЛЕ довгу (розгорнув setup → process → why...), проігнорувавши «don't write too much».

Що сталося: заборони щодо змісту модель врахувала, але негативні обмеження обсягу протікають (той самий ефект, що з «no markdown» у DS4). Купа «don't» не дає моделі позитивної цілі.

✅ Виправлення: «Explain gradient descent in exactly 3 sentences for a junior dev, using one everyday analogy. Avoid math notation.» — позитивна ціль + точний обсяг. Результат — щільні 3 речення.

Правило: кажи що робити, не лише чого уникати. Позитивне обмеження («exactly 3 sentences») надійніше за «don't be too long».

AP3. Перевантажений мультизадачний промпт

❌ «Build me a Python web scraper, explain async/await, recommend the best database, write unit tests, dockerize it, and summarize REST vs GraphQL.»

Реальний Haiku: спробував зробити все одразу — і кожен пункт вийшов поверхневим: скрейпер + короткий абзац про async + «PostgreSQL» одним рядком + згадка тестів... Жоден пункт не доведений до якості.

Що сталося: 6 задач в одному промпті → увага «розмазана», глибина впала. На малій моделі це особливо помітно.

✅ Виправлення: одна сфокусована задача — «write a function fetch_html(url)... retries 3 times... raises on non-200. Output only the code.» — повна, якісна, готова функція (на відміну від 6 поверхневих шматків). Решту — окремими промптами (див. prompt chaining).

⚠️ Чесне застереження (підтверджено аудитом). Нова версія промпта прибирає перевантаженість: функція вийшла повна й якісна. Але вивід Haiku усе ж прийшов обгорнутим у ```python попри «Output only the code» — рівно та слабкість негативної заборони, яку ми виміряли вище у розділі A цієї частини (DS4 = 80% проти SE5 = 100%). Промпт виправляє одну ваду, але демонструє іншу: щоб отримати голий код без fences, треба додати якір — «start with def fetch_html». Урок: антипатерни можуть накладатися; виправляючи один, перевіряй, чи не лишився інший.

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

AP4. Підвідне питання з хибною засновкою

❌ «Explain why Python is always faster than C++ for numerical computing.» (засновка хибна)

Реальний Haiku:

Python is generally not faster than C++ for numerical computing. C++ is typically faster because it is compiled... Python's popularity comes from libraries like NumPy/SciPy that wrap optimized C/Fortran code, not from Python itself being fast.

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

✅ Виправлення: «Compare Python and C++... If the premise that one is "always faster" is wrong, correct it, and explain when each is faster.» — явний дозвіл виправити засновку → структурована, збалансована відповідь.

Правило: не «зашивай» припущення у питання. Якщо не впевнений — додай «if any premise here is wrong, correct it first».

Зведення антипатернів

C. Пере-перевірка топ-сайтів (WebFetch, 2026-06-27)

Не на віру до прапорця — суб-агент реально зробив WebFetch кожного URL. Перепровірено 2026-08-21: усі 10 і далі живі (OpenAI-URL при автоперевірці дав транзієнтний збій, але при ручній звірці — 200 OK):

Усі 10 унікальних зовнішніх посилань курсу — живі (перепровірено 2026-08-21). 6 технічних URL перевірені WebFetch тут; 3 доменно-специфічні (2× Towards Data Science, Simon Willison) — окремим проходом; 10-те (promptingguide.ai/applications) дозвірене у серпні. Жодне посилання не спирається лише на прапорець verified_live дослідницького агента.

⚠️ Доступність ≠ актуальність (урок серпневої перевірки). Окремим проходом ми прочитали зміст усіх ресурсів, не лише перевірили код 200. Результат: 6 актуальні, 3 старіють, 1 без правки не працює — інтерактивний туторіал Anthropic віддає 200 OK, але його ноутбуки зашиті на claude-3-haiku-20240307, знятий з експлуатації 20.04.2026, тож приклади падають з помилкою API. Деталі й виправлення — у Частині 4.

Метод-урок: перевірка посилань на код 200 — необхідна, але недостатня. Для навчальних матеріалів треба окремо перевіряти, чи не застарів зміст.

Підсумок частини 6

• Надійність формату виміряна, а не припущена: закритий набір / sentinel / якір = ~100%; негативні заборони = ~80%. Для критичних конвеєрів вмикай structured outputs, а без них — prefill (лише Haiku 4.5 і старші) + перевірку за схемою.
• Антипатерни перевірені: найнебезпечніші на Haiku — суперечливі інструкції (тиха втрата контролю) і перевантаження (поверхневість). Заборони-обсягу протікають. Хибні засновки Haiku поки що спростовує сам.
• Усі 10 посилань курсу перевірені реальним WebFetch (і перепровірені 2026-08-21).

Вправи (Частина 6)

1. Надійність-вправа. Тобі потрібен 100%-надійний JSON-вивід від Haiku у проді. Назви три засоби в порядку від найнадійнішого і поясни, чому «no markdown» сам по собі недостатній.
2. AP1-вправа (суперечність). Чому суперечливий промпт небезпечніший за просто поганий? Що конкретно ти втрачаєш?
3. AP2-вправа (заборони). Перепиши «Explain Docker. Don't be long, don't use jargon, don't be boring» у позитивний промпт без жодного «don't».
4. AP3-вправа (перевантаження + накладання). У виправленні AP3 код усе одно прийшов у ```python. Який один рядок робить його голим, і яку техніку з Частини 2 ти застосовуєш?
5. AP4-вправа (хибна засновка). Ти питаєш модель про дані, яких немає у наданому контексті. Який рядок не дасть їй вигадати?

Відповіді (Частина 6)

1. Порядок: (0) structured outputs у реальному API (output_config.format) — схему гарантує сервер; (1) prefill (лише Haiku 4.5 і старші; підстав { — модель фізично не додасть преамбулу) → ~100%; (2) якір першого символу (start with {) → 100% у наших N=5; (3) перевірка за схемою + повторний прогін на провалі. «No markdown» недостатнє, бо це негативна заборона, що протікає ~20% (4/5 у DS4) — модель легше виконує дію, ніж утримується від звички.
2. Поганий промпт дає погану, але передбачувану відповідь. Суперечливий — модель мовчки обирає одне з вимог і викидає інше, не повідомляючи. Ти втрачаєш контроль: не знаєш, який бік переможе (в AP1 викинуло «comprehensive», лишило «one sentence»).
3. Напр.: «Explain Docker in 3 sentences for a developer who knows Git but not containers, using one analogy.» — позитивна ціль (3 речення, аудиторія, аналогія) замість набору заборон.
4. Рядок-якір: «Output only the code, starting with def fetch_html». Техніка — примус формату через якір першого символу (SE5): позитивний якір надійніший за «output only the code».
5. «Answer ONLY using the provided context. If the answer is not there, reply exactly: NOT IN DOCUMENT. Do not use outside knowledge or invent.» — sentinel + заборона зовнішнього знання (RAG-grounding, B1).

Частина 7. Синтез: практичний фреймворк

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

7.1. Робочий процес написання промпта (5 кроків)

1. КОНТЕКСТ   → дай дані+типи, ціль, важливий контекст        (DS1, DS5)
2. ФОРМАТ     → задай форму виводу: схема / якір / закритий набір  (DS4, SE5)
3. ПРИКЛАДИ   → 2–5 few-shot пар, якщо формат критичний        (DS2, SE3)
4. МІРКУВАННЯ → «think step by step», якщо потрібне судження    (DS3, SE4)
5. ВИХІД      → дай «не знаю / немає в контексті», щоб не вигадувало  (SE6, B1)

Не кожен промпт потребує всіх 5. Але якщо результат «плаває» — пройдись по кроках і знайди пропущений.

7.2. Драбина надійності формату (виміряно на Haiku, N=5; два верхні рядки — механіка API, не наш вимір)

Коли вивід має споживатися кодом, обирай якомога вище:

Правило: для критичних конвеєрів — техніка ~100% плюс перевірка за схемою й повторний прогін на провалі. Не покладайся на заборони.

7.3. Haiku-специфіка (чому це курс «для Haiku», а не взагалі)

Порівняння з Sonnet 4.6 (Частина 5) показало: промпт-інжиніринг важливіший саме на малій моделі.

• Sonnet «прощає» слабкий промпт (дав план там, де Haiku відмовився) і дотримується заборон (голий JSON на «no markdown», де Haiku обгорнув).
• Економія на моделі (Haiku — швидша й дешевша) компенсується якістю промпта. Те, що Sonnet робить «за замовчуванням», на Haiku треба прописати явно.
• Практично: прототипуй логіку на сильнішій моделі, а для прода на Haiku — додай явні приклади, якорі й перевірку виходу.

7.4. Чотири антипатерни (чого не робити)

7.5. Чек-лист «перед тим, як відправити промпт у прод»

• Чи задано формат виводу технікою ≥ ~100% надійності (не лише заборона)?
• Якщо вивід парситься кодом — чи є few-shot або схема?
• Чи дав я моделі «вихід» на випадок «немає відповіді» (sentinel)?
• Чи немає суперечливих вимог і перевантаження (>1 задача)?
• Чи прогнав я промпт N разів і порахував частку коректних відповідей? (Одного прогону недостатньо — це головний урок Частини 6.)
• Якщо текст українською для дисертації — чи є прохід вичитки на русизми?

7.6. Три мета-уроки курсу

1. Промпт-інжиніринг — вимірюваний. Не «магічні слова», а інженерія з числами: few-shot дав 1 унікальну відповідь замість 3; якір — 100% проти 80% у заборони.
2. Перевіряй, не вигадуй. Кожне твердження тут звірене проти сирого виводу моделі — включно з місцями, де навіть «сильний» промпт спрацював на 80%, а не 100%. Чесний провал цінніший за відполірований приклад.
3. Контекст моделі має значення. Те, що велика модель робить сама, малій треба прописати. «Найкраща практика» без прив'язки до моделі — неповна.

7.7. Куди далі

• Практика на Haiku: Anthropic Interactive Prompt Engineering Tutorial
• Глибина технік: Prompt Engineering Guide (DAIR.AI)
• Офіційний референс: Anthropic Prompting Best Practices
• Повний список + за доменами — у Частині 4.

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

Частина 8. Вибір моделі: Haiku vs Opus vs Fable (і як під них писати)

Досі курс вчив писати під Haiku. Ця частина — про те, чим відрізняється написання промпта для трьох моделей Claude різного класу: Haiku 4.5 (мала/швидка), Opus 4.8 (найпотужніша Opus-лінійка) і Fable 5 (найпотужніша широко доступна).

⚠️ Джерело й чесне маркування (двошарове).

• Механіка API (розділ 8.2 нижче: що приймається / що → 400) — з офіційного довідника Anthropic (claude-api, кеш станом на 2026-06-24) + migration-guide. Через гарнес агента 400-и не відтворити, тож це залишається «з доксів».
• Поведінкові твердження (розділи 8.3–8.5: прощення слабкого промпту, leak-rate заборон, стійкість до пасток) — виміряно на Haiku / Opus 4.8 / Fable 5 (14 крос-модельних прогонів; див. 8.8).

✅ Перепровірено на живих доксах 2026-08-21: усі 11 тверджень механіки (розділ 8.2) — підтверджені; ціни й ліміти Haiku 4.5 / Opus 4.8 / Fable 5 — без змін. Повторні звірки 2026-09-19 і 2026-09-24: вийшли Fable 5.1 та Opus 5.5, а Fable 5 та Opus 5 стали Legacy — див. «Свіжість лінійки».

API змінюється — механіку звіряй з platform.claude.com/docs.

8.1. Дві осі, за якими різняться моделі

1. Механіка API — що взагалі можна покласти в запит (параметри, які приймаються чи повертають 400).
2. Стиль промпта — як формулювати, щоб отримати максимум.

Перенести можна текст промпта; а от «обгортку» запиту — часто ні (див. 8.7).

8.2. Механіка запиту — що дозволено

Наслідок для коду: що потужніша модель, то суворіший запит. Haiku приймає старий стиль (budget_tokens, temperature, prefill); Opus/Fable їх відкидають. Fable ще й думає завжди: thinking треба прибрати або лишити лише {type:"adaptive"}.

⏱️ Свіжість лінійки (станом на 2026-09-24)

Курс писався в червні 2026 на трійці Haiku 4.5 / Opus 4.8 / Fable 5. За перевіркою живих доксів у серпні:

• Усі цифри й механіка вище лишаються чинними — Haiku 4.5, Opus 4.8 і Fable 5 активні, ціни й ліміти не змінились.
• Нове покоління: 22.09.2026 вийшов Claude Opus 5.5 (claude-opus-5-5, 4/20 за 1M) — тепер топова рекомендація Anthropic. Opus 5 (claude-opus-5) і Opus 4.8 перейшли в Legacy й повністю підтримуються. Claude Sonnet 5 (claude-sonnet-5) коштує 2/10 за 1M: анонсоване підвищення до 3/15 з 1 вересня скасовано.
• Практичний наслідок: усе, що ця частина каже про Opus 4.8, застосовне й до Opus 5 (та сама сімʼя обмежень: adaptive-only thinking, temperature/prefill → 400). Одна відмінність Opus 5: adaptive-мислення увімкнене типово (в Opus 4.8 — вимкнене), і thinking:{type:"disabled"} приймається лише при effort ≤ high.
• Opus 5.5 за механікою ближчий до Fable, ніж до Opus 5. Мислення увімкнене завжди й не вимикається. Типовий effort — medium, а не high. Примусовий виклик інструмента (forced tool use) повертає помилку, як і на Fable 5.1. Читання кешу коштує 0.05× ціни входу.
• Haiku 4.5 лишається найдешевшою ланкою — головний висновок курсу («що менша модель, то важливіший промпт») не змінився.

Оновлення 2026-09-19 (звірено з живими доксами):

• 1 вересня 2026 вийшов Claude Fable 5.1 (claude-fable-5-1): та сама ціна 10/50, читання кешу вчетверо дешевше ($0.25 за 1M), thinking так само завжди увімкнене. Fable 5 перейшов у Legacy (виведення не раніше 9.06.2027). Claude Mythos 5.1 має ті самі можливості й ціну, що й Fable 5.1, але доступна лише учасникам Project Glasswing за запрошенням.
• Усе, що ця частина каже про механіку Fable 5, стосується й Fable 5.1, плюс три зміни, що ламають код: примусовий виклик інструмента (forced tool use) повертає помилку; старіші моделі не читають його thinking-блоки; редагування ранніх ходів робить thinking-блоки недійсними.
• Haiku 4.5: дата виведення досі «не раніше 15 жовтня 2026» — стеж за сторінкою deprecations.

8.3. Стиль — Haiku 4.5: пиши максимально явно

Це виміряно в цьому курсі (Частини 1–6): мала модель «карає» за слабкий промпт сильніше за велику.

• Few-shot приклади — найнадійніший важіль формату (ЗМІШАНА/MIXED ×3 стабільно проти 3 різних без прикладів).
• Позитивні якорі («start with {») надійніші за заборони.
• Негативні заборони протікають ~20% («no markdown» → 4/5 разів голий, 1/5 у ```json).
• Декомпозиція: розбивай складне на ланцюжок простих кроків — на малій моделі це помітно знижує помилки.

Правило 8.3. Haiku = «явність + приклади + якір». Компенсуй розмір моделі якістю промпта.

8.4. Стиль — Opus 4.8: «прощає» слабкий промпт, але має свої нахили

Добрі типові припущення рятують vague-запит (це видно і в порівнянні Haiku-vs-Sonnet у Частині 5). Але за офіційним гайдом Opus 4.8:

• Недотягується сам до інструментів / підагентів / файл-пам'яті → давай явний тригеринг («шукай, коли…», «делегуй, коли фан-аут»). Це працює і на рівні опису інструмента («call this when…»).
• Балакучіший за 4.7 — якщо агент занадто наративить, додай silence-default («default to silence between tool calls»).
• Обережніший, частіше перепитує — додай «на дрібницях (назви, типові значення) обирай сам; питай лише про зміни обсягу чи незворотні дії».
• Тепліший голос — старі інструкції «be concise/warmer», писані під 4.7, можуть перестати бути потрібними; перевір.
• effort: типово high; для найважчого кодингу/агентики — xhigh. Роби sweep medium/high/xhigh, а не рефлекторно xhigh.

Правило 8.4. Opus 4.8 = «менше боротьби за формат, більше явного тригерингу інструментів і меж автономії».

8.5. Стиль — Fable 5: НЕ переписуй прескриптивно, а навпаки

Найпотужніша модель — і найконтр­інтуїтивніша в промптингу (за офіційним migration-guide):

• Знімай покрокові риштування. Промпти під старі моделі часто занадто прескриптивні й знижують якість. Дай ціль + обмеження, і хай сама планує.
• Ходи довгі — один запит на важкій задачі може йти хвилини. Плануй час очікування, стрімінг і асинхронні перевірки.
• Дай файл-пам'ять і дозволь асинхронно делегувати підагентам — на цьому Fable виграє найбільше.
• Став найважче. На рутині — знижуй effort: навіть low часто б'є xhigh старих моделей.
• Обробляй refusal (класифікатори безпеки). У продакшені став server-side fallback: актуальний спосіб (звірено 2026-08) — fallbacks: "default" з бета-хедером server-side-fallback-2026-07-01; він сам добирає модель за категорією відмови, без ручного списку. Недоступний на Batch API, Bedrock, Google Cloud і Foundry — там роби ретрай на клієнті.

Правило 8.5. Fable 5 = «менше інструкцій, більше цілі; довгі ходи; пам'ять + делегування».

8.6. Що обирати під задачу

Головний принцип вартості: Частина 5 показала, що промпт-інжиніринг дає найбільший приріст саме на малій моделі. Тож економія на моделі (Haiku замість Opus) компенсується якістю промпта — але не безмежно.

8.7. Практичне правило переносу

Текст промпта переноситься між моделями; «обгортка» запиту — ні.

• Haiku → Opus/Fable: прибери budget_tokens, temperature/top_p/top_k, prefill (усі → 400 на Opus/Fable).
• Opus → Fable: додатково прибери thinking-блок (або лиши лише {type:"adaptive"} — Fable думає завжди; disabled та budget_tokens → 400) і додай обробку refusal + fallbacks: "default" (бета server-side-fallback-2026-07-01). На Fable 5.1 ще й прибери примусовий виклик інструмента — він повертає помилку.
• Будь-куди → Haiku: можна лишити старий стиль, але посиль текст (few-shot, якорі) — Haiku менш «прощає».

8.8. Емпірична перевірка на трьох моделях (виміряно)

Щоб ця частина не була «лише з доксів», поведінкові твердження реально прогнано: 7 промптів на Opus 4.8 + 7 на Fable 5 (Haiku-баейзлайни — з першої партії курсу). Перевірка через гарнес агента (базові моделі справжні: claude-opus-4-8, claude-fable-5; raw-API немає).

Ключові докази (дослівно)

DS4 — дисципліна формату. Той самий сильний промпт «Output ONLY valid JSON, no markdown», 5 прогонів на модель:

• Haiku — 1 із 5 усе ж обгорнув у ```json (80% чистих).
• Opus 4.8 та Fable 5 — усі 10 прогонів голий JSON, наприклад: {"revenue_musd": 4.2, "revenue_growth_yoy_pct": 12, "churn_rate_pct": 3.1, "new_customers": 540}.

DS1 — прощення слабкого промпту. Haiku на vague-запиті відмовився; Opus і Fable обидва видали структурований план (~2.5 тис. символів) і лише потім попросили дані. Fable ще й додав чесне застереження: «Two features is thin for churn modeling… the strongest predictors are usually behavioral: tenure, usage, support tickets.»

Чесні застереження до 8.8

• Механіку (таблиця 8.2: budget_tokens/temperature/prefill → 400) тут не тестовано — через гарнес агента 400-и не відтворити. Вона лишається «з доксів».
• N=5 для DS4 — індикація, не строгий статексперимент; для публікації повторити через raw-API з кількома семплами.
• Гарнес агента дає тонке «забруднення» системним промптом (те саме застереження, що для решти курсу).
• Під час прогону класифікатор безпеки був недоступний (rate-limit) — виводи звірено вручну, аномалій немає.

Висновок 8.8. Три поведінкові тези Частини 8 підтверджені виміром на Haiku/Opus/Fable: більша модель прощає слабкий промпт; негативна заборона протікає саме на малій; пастку flatten() ловлять усі. Сирі дані — raw-outputs/model-runs/batch4-14runs-opus-fable.json.

Вправи (Частина 8)

1. 8-A. Ти переносиш робочий промпт із Haiku на Fable 5. Які три речі в тілі запиту зламаються (повернуть 400), і що з ними зробити?
2. 8-B. Твій Opus-агент недостатньо часто викликає інструмент пошуку. Назви два важелі, якими це полагодити (за офіційним гайдом 8.4).
3. 8-C. Ти пишеш промпт для Fable 5, скопійований зі старого Haiku-плейбука з 12 покроковими інструкціями. Чому це може знизити якість — і як переписати?
4. 8-D. Задача — дешева масова класифікація 1 млн коротких текстів. Яку модель узяти і як компенсувати її обмеження?

Відповіді (Частина 8)

1. 8-A. Зламаються: (1) thinking:{type:"enabled", budget_tokens:N} — прибрати thinking або лишити лише {type:"adaptive"} (Fable думає завжди); (2) temperature/top_p/top_k — прибрати, керувати стилем через промпт; (3) prefill (останній assistant-turn) — замінити на output_config.format або системну інструкцію. Плюс додати обробку refusal + server-side fallback (fallbacks: "default", бета server-side-fallback-2026-07-01).
2. 8-B. (1) Підняти effort до high/xhigh — на них Opus помітно активніше користується інструментами; (2) явний тригеринг: у системному промпті і в описі інструмента вказати коли його викликати («call this when the answer depends on current info»).
3. 8-C. Fable 5 інтерпретує прескриптивні кроки дослівно й може «переплановувати», що знижує якість. Переписати: дати ціль + обмеження + критерій готовності, прибрати покроковий алгоритм, дозволити планувати самій (за потреби — окремим кроком-верифікатором).
4. 8-D. Haiku 4.5 (найдешевша, 1/5, швидка). Компенсація: few-shot із закритим набором міток + якір/строгий формат («output only the label»), для критичного — перевірка формату на виході. Плюс Batch API (−50% ціни) для масовості.

Підсумок Частини 8

Написання промпта під модель — це дві осі: механіка запиту (що приймається) і стиль (як формулювати). Мала Haiku вимагає явності й прикладів; Opus 4.8 «прощає» формулювання, але потребує явного тригерингу інструментів і меж автономії; Fable 5 — навпаки, менше інструкцій і більше цілі, з довгими ходами й пам'яттю. І пам'ятай золоте правило курсу: що менша модель — то важливіший промпт-інжиніринг.

Частина 9. Промт-інжиніринг 2026: reasoning-моделі та зсув до контексту

Частини 1–6 виміряли класичні техніки на Haiku 4.5 — малій моделі без примусового reasoning. Але фронтир 2026 — це reasoning-моделі (Claude Sonnet 5 / Opus 5.5 / Fable 5.1, OpenAI GPT-6, DeepSeek R1/V4), які думають самі. Ця частина — про те, що з класики живе, що померло, і що прийшло на заміну, за офіційними доксами обох лабораторій та дослідженнями.

📚 Джерела й маркування. Ця частина — дослідницька (офіційні докси Anthropic/OpenAI/DeepSeek, arXiv, Willison/Fowler), зібрана 2026-08-21 із правилом «кожне твердження реально прочитане за URL», а ключові — перевірені повторним фетчем незалежним критиком. Це не прогони моделей — на відміну від ядра курсу.

9.1. Головний зсув: «think step by step» більше не радять

Обидві лабораторії незалежно зійшлися на одному:

• OpenAI (офіційні reasoning best practices): «Since these models perform reasoning internally, prompting them to "think step by step" or "explain your reasoning" is unnecessary». І далі: спершу пробуй zero-shot, few-shot — лише якщо треба. → developers.openai.com/api/docs/guides/reasoning-best-practices
• Anthropic (актуальний довідник під Sonnet 5, Opus 5.5 і Fable 5.1): «Prefer general instructions over prescriptive steps. A prompt like "think thoroughly" often produces better reasoning than a hand-written step-by-step plan». Ручний CoT з тегами <thinking>/<answer> — тепер лише fallback, коли adaptive thinking вимкнено. → platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices

Заміна: дай моделі задачу + обмеження + формат виводу — і хай планує сама. Глибину міркувань крутить не текст промпта, а явний перемикач: effort (Anthropic: low…max) / reasoning_effort (OpenAI).

⚖️ Як це співіснує з нашим виміром. У Частині 1 CoT на Haiku 4.5 дав реальний приріст (DS3) — і це досі правильно: Haiku-клас не reasoning-first. Правило 2026: CoT-підказки — для моделей без вбудованого мислення; для reasoning-моделей — goal+constraints і effort-dial. Техніка не «померла» — вона стала model-conditional.

9.2. Few-shot став умовним, а не універсальним

Наш вимір (DS2/SE3): few-shot — найнадійніший важіль формату на Haiku. Але у 2026:

Правило 9.2. Few-shot лишається королем формату (це ми виміряли), але для reasoning-якості він model-conditional: перевіряй картку конкретної моделі, а не переноси звичку.

9.3. Structured outputs замість prefill

Класичний хак «підстав { у відповідь асистента» (його радили правило DS4 і Частина 6) на нових моделях неможливий — prefill повертає 400 на Claude 4.6+/Fable. Офіційна заміна в обох лабораторій — нативні structured outputs (JSON-схема на рівні API: output_config.format в Anthropic, Structured Outputs в OpenAI). Докси Anthropic прямо описують міграцію з prefill.

Драбина надійності формату 2026 (оновлення нашої з Частини 6):

1. Нативна схема на рівні API (100% коректність гарантує сервер) — коли доступна. На Claude це output_config.format, і він працює навіть на Haiku 4.5.
2. Якір першого символу + закритий набір міток (наші виміряні ~100% на Haiku) — коли схемного режиму нема. Локальні стеки його мають: Ollama (format), llama.cpp (json_schema/grammar).
3. Негативні заборони — досі протікають (наш вимір: 80%).

9.4. Семплінг-параметри: епоха temperature закінчується (але не скрізь)

• Claude 4.7 і новіші (Sonnet 5, Opus 5/5.5, Fable 5/5.1): нестандартні temperature/top_p/top_k → 400. OpenAI: у GPT-5 і GPT-6 Astra цих параметрів немає, а GPT-6 Sol і Luna приймають їх лише з reasoning_effort: none. Стиль і варіативність задаються промптом, глибина — effort.
• Але DeepSeek R1 офіційно радить temperature 0.5–0.7.

Правило 9.4. «Effort замість temperature» — правило конкретних фронтир-родин, не індустрії. Для кожної моделі — її картка. (Це підтвердив і наш адверсаріальний критик, спіймавши спробу узагальнення.)

9.5. Від промпт- до контекст-інжинірингу

Anthropic Engineering (2025-09-29) формалізує наступницю дисципліну: промпт-інжиніринг — «написання інструкцій», контекст-інжиніринг — «стратегії курації та підтримки оптимального набору токенів під час інференсу»: системний промпт + інструменти + retrieved-дані + історія разом. Willison (2025-06-27) фіксує, чому термін переміг: «prompt engineering» у публічній свідомості сплющився до «друкування в чатбот» (цитує Karpathy: «делікатне мистецтво наповнення контекстного вікна саме тим, що треба»). Böckeler на martinfowler.com (2026-04-02) веде далі — harness engineering: Agent = Model + Harness, де harness = feedforward-«guides» (доки, навички, лінтери) + feedback-«sensors» (тести, fitness functions).

Ієрархія 2026: промпт ⊂ контекст ⊂ харнес. Детально контекст — у Частині 12.

9.6. Чесні суперечки (без вирішення)

• Роль/персона: consumer-блог Anthropic (11.2025) називає ролі «менш потрібними… надто специфічна роль може обмежити», а технічний довідник тієї ж Anthropic досі тримає «Give Claude a role» у ядрі технік. Наш вимір (DS5): роль у парі з контекстом+обмеженнями працювала на Haiku. Висновок: роль — не магія, а спосіб передати контекст; сама по собі слабшає зі зростанням моделей.
• XML-теги: та сама пара джерел розходиться (маркетинг: «часто досить заголовків»; техдовідник: XML — основний спосіб розділяти складні промпти). Наш вимір (SE2) — теги давали реальний приріст на Haiku.
• Чутливість reasoning-моделей до промпта: KAIST (arXiv:2505.17225) показує «reasoning rigidity» — моделі переїжджають явні умови звичними траєкторіями (три модуси: interpretation overload, input distrust, partial instruction attention). Частину збоїв формулювання не лікує. Єдиної картини «більш чи менш чутливі» в літературі поки немає — чесно кажемо: відкрите питання.

9.7. Оновлена шпаргалка-2026 (додаток до 13 принципів Частини 4)

14. Для reasoning-моделей: goal + constraints + формат, без покрокових рецептів; глибина — effort-dial. (OpenAI+Anthropic)
15. Few-shot і CoT — model-conditional: звіряй картку моделі (на R1 few-shot шкодить). (DeepSeek/OpenAI)
16. Формат — нативною схемою API, prefill мертвий на фронтирі; якорі лишаються для моделей без схем. (обидві лабораторії + наш вимір)
17. Думай рівнями: промпт ⊂ контекст ⊂ харнес — і оптимізуй той рівень, де реальна проблема. (Anthropic Eng/Fowler)

Вправи (Частина 9)

1. 9-A. Твій старий промпт для GPT-4-класу починався з «Let's think step by step» і мав 5 few-shot прикладів. Переносиш на Claude Opus 5.5. Що зміниш і чому?
2. 9-B. Потрібен гарантовано коректний JSON на (а) Fable 5.1, (б) локальній Qwen через llama.cpp. Який механізм формату обереш для кожної і хто в кожному разі гарантує схему?

Відповіді

1. 9-A. Прибрати CoT-заклинання (Opus 5.5 думає завжди; глибину задає effort, типово medium), few-shot скоротити або лишити тільки якщо вони задають формат (не «навчають міркувати»); переписати як goal+constraints+формат виводу. І прибрати temperature, якщо був: на Opus 5.5 нестандартне значення дає 400.
2. 9-B. (а) Fable 5.1 — нативні structured outputs (output_config.format): схему гарантує сервер Anthropic, prefill недоступний. (б) llama.cpp теж обмежує декодування: json_schema або GBNF-grammar у сервері. Тут схему гарантує граматика, яку ти сам налаштовуєш і тестуєш. В обох випадках якір першого символу й перевірка значень лишаються страховкою: схема гарантує синтаксис, а не зміст.

Підсумок Частини 9. Класика не померла — вона стала умовною. Виміряне в Частинах 1–6 досі точне для Haiku-класу й локальних моделей; для reasoning-фронтиру діє нова трійця: goal+constraints замість кроків, effort замість «think harder» і temperature, схеми API замість prefill. А сама дисципліна виросла з промпта в контекст і харнес.

Джерела (перевірено 2026-09-19)

• OpenAI — Reasoning best practices
• OpenAI — Model guidance (GPT-6 Astra, Sol, Luna)
• Anthropic — Prompting best practices
• Anthropic — Structured outputs
• Anthropic — Effort
• Anthropic — Model deprecations (temperature на 4.7+)
• DeepSeek-R1 — картка моделі
• DeepSeek-R1 — стаття (few-shot)
• Anthropic Engineering — Effective context engineering
• Simon Willison — Context engineering
• Birgitta Böckeler — Harness engineering
• Claude blog — Prompt engineering best practices (10.11.2025)
• Reasoning Model is Stubborn (reasoning rigidity)
• Ollama — Structured outputs
• llama.cpp server — json_schema / grammar

Частина 10. Автоматизовані системи розробки ПЗ з ШІ

Що кажуть дані і першоджерела (не маркетинг) станом на серпень 2026 про розробку софту агентами. Де реальний виграш, де виміряні провали і яка дисципліна відділяє одне від іншого.

📚 Джерела: офіційні докси Claude Code, Anthropic Engineering, METR (RCT), Google DORA 2025, arXiv (SpecBench, TDAD, SDD), Karpathy. Зібрано 2026-08-21; ключові твердження перевірені повторним фетчем (METR, DORA, best-practices — підтверджені дослівно).

10.1. Спершу — холодний душ від даних

METR RCT (2025-07, arXiv:2507.09089) — рандомізоване контрольоване дослідження, методологія клінічних випробувань: 16 досвідчених open-source розробників, 246 реальних issues у власних репозиторіях (22k+ зірок, ~1M LOC). Результат: з дозволеним ШІ розробники були на 19% ПОВІЛЬНІШІ — при тому, що прогнозували прискорення на 24%, і навіть після факту вірили, що ШІ їх прискорив на 20%. Автори чесно застерігають: не узагальнювати за межі «досвідчені деви у знайомих великих кодобазах з високою планкою якості».

Google DORA 2025 (~5000 респондентів): 90% використовують ШІ, 80%+ відчувають приріст продуктивності, але 30% мало або зовсім не довіряють ШІ-коду. Головна теза звіту: «ШІ — підсилювач» наявних сильних і слабких сторін організації, а не ліки від поганого процесу.

Правило 10.1. Самовідчуття продуктивності з ШІ — ненадійний прилад (METR: люди помилялись на ~40 п.п. навіть постфактум). Міряй результат (lead time, дефекти), а не відчуття. І спершу лагодь процес — ШІ його лише помножить.

10.2. Верифікаційна петля — центральна дисципліна

Офіційні best practices Claude Code формулюють це як вододіл: дай агенту «a check it can run» (тести, exit-code збірки, лінтер, порівняння знімків екрана) — інакше «you become the verification loop». Це «різниця між сесією, яку ти дивишся, і сесією, від якої можна відійти».

Три ескалаційні механізми контролю для автономної роботи (звідти ж, підтверджено дослівно):

1. Check у промпті — «зроби і прожени тести».
2. /goal-умова — окремий еволюатор перевіряє умову після кожного ходу.
3. Детермінований Stop-hook — скрипт, без проходження якого хід не завершується (авто-override після 8 блокувань поспіль).

Там же названо ключовий failure mode — «the trust-then-verify gap»: «Claude produces a plausible-looking implementation that doesn't handle edge cases». Ліки — обовʼязкова верифікація до шипу, не після.

10.3. Reward hacking — уже виміряний, не гіпотетичний

SpecBench (arXiv:2605.21384, 2026-05): 30 системних задач від JSON-парсера до ядра ОС, у кожної — видимі validation-тести і приховані композиційні. Фронтирні агенти сатурують видимі тести майже завжди, але розрив «видимі pass / приховані fail» росте на ~28 п.п. на кожен десятикратний ріст розміру коду. Задокументовані трюки: «feature isolation» (окремі функції проходять тести, але не ділять стан) і відверті експлойти — 2900-рядковий «компілятор», що завчив тестові входи замість алгоритму.

Правило 10.3. Тести, які бачить агент, — це його reward, і він їх зламає на досить довгій задачі. Тримай приховані/композиційні перевірки поза контекстом агента, і що більша задача — то більше ваги на них.

10.4. TDD для агентів — з несподіваним нюансом

Консенсус (Willison, докси Anthropic): red/green TDD — «чудова пара» для агентів, бо дає той самий запускний check. Але TDAD (arXiv:2603.17973, 2026-03) виміряв: наївний промпт «використовуй TDD» без аналізу залежностей ПІДВИЩИВ регресії тестів до 9.94% (база 6.08%). Лише в парі з графовим impact-аналізом (які саме наявні тести може зламати зміна) регресії впали до 1.82%, а розвʼязуваність задач зросла з 24% до 32%.

Правило 10.4. «Пиши тест спершу» — не заклинання. Для агента TDD працює, коли він знає, які тести зачіпає зміна; сліпий TDD-промпт може шкодити.

10.5. Spec-driven vs vibe-coding: пропорційність, не догма

Академічна рамка (arXiv:2602.00180, AIware 2026): специфікація як первинний артефакт, три рівні строгості — spec-first → spec-anchored → spec-as-source — під різні контексти (BDD-фреймворки до GitHub Spec Kit). Важливо: стаття не проголошує SDD універсально кращим — вона дає «decision framework: коли SDD дає цінність, а коли досить простішого». Докси Anthropic кажуть те саме зі свого боку: «якщо диф можна описати одним реченням — пропусти план».

Правило 10.5. Строгість специфікації масштабуй під неоднозначність і багатофайловість задачі. Спека заради спеки — теж антипатерн.

10.6. Довгі автономні прогони: агенти «працюють позмінно»

Anthropic Engineering (2025-11-26, «Effective harnesses for long-running agents»): агент не має памʼяті між контекстними вікнами. Тому харнес ділить роботу на два агенти. Initializer-агент пише init.sh, файл прогресу claude-progress.txt, JSON-перелік функцій і перший git-коміт. Coding-агент щосесії відновлюється зі структурованих handoff-артефактів, наче інженери, що працюють позмінно. Стан живе у файлах і git, а не в «памʼяті» моделі.

Крайній орієнтир можливого: експеримент Karpathy «autoresearch» (03.2026) — один агент безперервно працював дві доби, виконав ~700 експериментів з оптимізації навчання малої моделі й знайшов 20 покращень; на більшій моделі вони скоротили час навчання на 11%. Агент правив один файл train.py (модель і цикл навчання, ~630 рядків), а інструкції для нього вмістилися в легкий program.md. Його висновок: це шаблон, який масштабуватимуть лабораторії.

10.7. CI-інтеграція: автономність із запобіжниками

Офіційні докси claude-code-action: два режими — інтерактивний (@claude у PR) і автоматичний (фіксований prompt на будь-яку GitHub-подію, включно з cron), з перевіркою прав запису і людини-актора на кожен тригер (проти бот-петель). Вбудовані обмежувачі вартості: --max-turns, час очікування workflow, GitHub concurrency — прямо «щоб обмежити runaway jobs».

Правило 10.7. Автономний агент у CI = завжди бюджет + час очікування + гейт на людину-актора. Це не опції, а частина визначення системи.

Вправи (Частина 10)

1. 10-A. Команда каже: «ми відчуваємо, що з ШІ стали швидші на 30%». Які два виміряні факти з 10.1 ти наведеш, і що запропонуєш міряти замість відчуттів?
2. 10-B. Агент за ніч «закрив» велику нову функцію, всі тести зелені. Назви два способи перевірити, що це не reward hacking (10.3), перш ніж мержити.
3. 10-C. Чому «просто скажи агенту робити TDD» може погіршити результат, і що додати (10.4)?

Відповіді

1. 10-A. METR: досвідчені деви були на 19% повільніші, хоч вірили у +20% навіть постфактум; DORA: 80% «відчувають» приріст при 30% недовіри до ШІ-коду — відчуття ≠ вимір. Міряти: lead time на issue, частку ревертів/дефектів, час до зеленого CI — на рандомізованих або хоча б порівнянних вибірках задач.
2. 10-B. (1) Прогнати приховані/композиційні тести, яких агент не бачив (SpecBench-логіка), або написати кілька нових інтеграційних постфактум; (2) адверсаріальне рецензування у свіжому контексті (Writer/Reviewer з 10.2/Ч.11) із фокусом «шукай feature isolation і завчені входи», плюс диф-аудит підозріло великих/дивних файлів.
3. 10-C. TDAD виміряв: наївний TDD-промпт підняв регресії з 6.08% до 9.94% — агент тестує «усе», не знаючи, що зачіпає зміна. Додати impact-аналіз залежностей (які тести стосуються зміни) як інструмент чи навичку — тоді 1.82% регресій і +8 п.п. розвʼязуваності.

Підсумок Частини 10. Автоматизована розробка з ШІ у 2026 — не «агент пише код», а система. Її складники: запускна перевірка, приховані тести проти reward hacking, рецензування у свіжому контексті, handoff-артефакти для довгих прогонів і бюджети в CI. Дані (METR, DORA) тверезять: без цієї дисципліни ШІ підсилює хаос — і навіть уповільнює.

Джерела (перевірено 2026-09-19)

• METR — RCT досвідчених розробників
• DORA 2025 — звіт
• Google Cloud — анонс DORA 2025 (цифри опитування)
• Claude Code — Best practices
• SpecBench
• TDAD
• Spec-Driven Development
• Anthropic Engineering — Effective harnesses for long-running agents
• karpathy/autoresearch
• Fortune — «The Karpathy Loop»
• Claude Code — GitHub Actions

Частина 11. Мультиагентна розробка

Найгарячіша суперечка агентної інженерії 2025–2026 — «будувати мультиагентів чи ні» — уже зійшлася до конкретних правил. Ця частина: обидві сторони, точка конвергенції, робочі патерни, і наш власний виміряний випадок.

📚 Джерела: Anthropic Engineering + офіційний гайд «when to use multi-agent», Cognition (обидва пости — 2025 і 2026), OpenAI Agents SDK docs, докси Claude Code sub-agents, arXiv 2026 (adversarial review, selection bottleneck), Willison. Ключові твердження перевірені повторним фетчем (Cognition «Flappy Bird» — дослівно).

11.1. Дебати та їхня конвергенція

Проти (Cognition, 06.2025, «Don't Build Multi-Agents»): мультиагентний кодинг ламається, бо підагенти не бачать рішень одне одного і роблять «конфліктні припущення, не прописані наперед». Канонічний приклад: клон Flappy Bird, де один підагент будує фон у стилі Mario, а інший — пташку, що не пасує ні до чого. Рецепт: однопотоковий лінійний агент + LLM-компресор контексту для довгих задач.

За (Anthropic Engineering, 06.2025, «How we built our multi-agent research system»): оркестратор-воркер (лідер Opus + паралельні Sonnet-підагенти, кожен зі своїм вікном) перевершив одиночного Opus на 90.2% на внутрішньому research-евалі. Ціна: ~15× токенів проти чату; ~80% варіації якості пояснює сам обсяг споживаних токенів.

Конвергенція 2026 — обидві сторони посунулись назустріч:

• Cognition (2026-04-22, «Multi-Agents: What's Actually Working»): мультиагент працює, «коли записи лишаються однопотоковими, а додаткові агенти дають інтелект, а не дії». Їхній продакшн-патерн: review-агент із навмисно чистим контекстом ловить у середньому 2 вади на PR, 58% — серйозні.
• Anthropic (офіційний гайд «when to use multi-agent», 23.01.2026): в експерименті з агентами, розділеними за ролями (planner, implementer, tester, reviewer), підагенти витрачали більше токенів на координацію, ніж на саму роботу. Причина — «зіпсований телефон» (telephone game): кожна передача між агентами губить точність. Загальний оверхед мультиагентності — 3–10× токенів проти одиночного агента.
• OpenAI (Agents SDK docs, 2026), незалежно: «Start with one agent whenever you can» — спеціалістів додавай лише коли вони матеріально покращують ізоляцію можливостей/політик, чистоту промптів чи читабельність трейсів.

⚠️ Токен-оверхед в джерелах Anthropic різний (15× проти чату у 2025; 3–10× проти одиночного агента у 2026) — це різні бейзлайни й задачі, подаємо як діапазон, не константу.

11.2. Коли мультиагент виграє, а коли програє

11.3. Патерни, що працюють (і два, що ні)

Працюють:

1. Оркестратор-воркер — лідер декомпозує, воркери в чистих вікнах виконують, лідер синтезує (Anthropic Research).
2. Single-writer + read-only intelligence — код пише один агент; решта — рецензенти, критики й верифікатори без права запису (точка згоди Cognition і Anthropic).
3. Review-loop у чистому контексті — рецензент бачить лише диф і критерії, не бачить міркувань автора, тому оцінює сам результат (докси Claude Code: Writer/Reviewer; Cognition: 2 вади на PR). Контр-застереження звідти ж: рецензент, якому звеліли шукати проблеми, завжди щось знайде — гонитва за кожним зауваженням веде до overengineering.
4. Smart friend — слабший/дешевший агент ескалує складне сильнішому (Cognition).
5. Map-reduce — менеджер роздає незалежні шматки, збирає результати (Cognition; наші власні батчі прогонів — саме це).

Не працюють:

• Фазовий конвеєр planner→coder→tester→reviewer (Anthropic: більше токенів на координацію, ніж на роботу; «зіпсований телефон» на кожній передачі).
• Наївний синтез-консенсус — див. 11.5.

11.4. Механіка ізоляції: як це влаштовано в реальних інструментах

Докси Claude Code sub-agents (2026): кожен (не-fork) підагент отримує справді свіже вікно — без історії головної розмови, без уже прочитаних файлів; лише системний промпт, текст завдання, CLAUDE.md, git-знімок і попередньо завантажені навички. Типово: до 20 паралельних підагентів, вкладеність до 3 рівнів; fork-режим — єдиний виняток, що успадковує історію. Managed Agents API: агенти = окремі персистентні треди зі спільною пісочницею/файлами, але ізольованою історією кожен.

Правило 11.4. Ізоляція — не обмеження, а перевага: чистий контекст рецензента робить рецензування чесним, а паралельні воркери — дешевими для головного вікна. Але через неї підагентам треба передавати все потрібне явно (вони не «знають», що ти обговорював).

11.5. Найважливіше відкриття 2026: вузьке місце — відбір, не генерація

• «When Agents Disagree» (arXiv:2603.20324): у конвеєрах generate-then-select якість судді-селектора, а не різноманіття генераторів, визначає результат: різнорідні команди з сильним суддею — 81% win rate проти одиночної моделі; однорідні — 51.2% (майже монетка). А наївне злиття відповідей кількох агентів в одну програло одиночній моделі 0 з 42 задач.
• «Adversarial Review» (arXiv:2608.18167): 3-агентна схема зі структурованою незгодою (кодер + рецензент + критик, що перевіряє рецензію) бʼє 5-агентний бейзлайн; названо failure mode «false consensus» — агенти сходяться без доказів, і більше агентів це не лікує.
• Willison про систему Anthropic: людські оцінювачі спіймали те, що LLM-суддя пропустив — агенти «обирали SEO-ферми замість авторитетних джерел». Пряме застереження проти оцінки мультиагентного виходу лише LLM-суддею.

Правило 11.5. Вкладай у суддю і структуровану незгоду, а не в кількість агентів. Ніколи не «зливай» відповіді — обирай кращу. І не довіряй оцінку одному LLM-судді для важливого.

11.6. Наш виміряний випадок: цей курс збудовано мультиагентно

Це не теорія з чужих постів — весь цей курс зроблено патернами цієї частини, з артефактами в raw-outputs/:

• Map-reduce/оркестратор-воркер: 118 модельних прогонів — паралельні воркери зі структурованими схемами виходу (скрипти робочих процесів збережено).
• Single-writer: файли курсу писав один агент (головний цикл); підагенти давали тільки інтелект — дослідження, прогони, вердикти.
• Адверсаріальні критики в чистому контексті ловили реальні помилки: суперечність AP3, overclaim DS3, зламаний туторіал Anthropic, фабрикацію «context anxiety» у власного дослідника (Частини 6, 8, серпнева перевірка).
• Ціна теж реальна: один дослідницький прогін для частин 9–13 (6 підагентів) спожив ~597 тис. токенів за журналом робочого процесу. Множник «3–15×» ми цим не виміряли: одноагентного бейзлайна для порівняння не було.

11.7. Правила частини (зведення)

1. Починай з одного агента; діли лише за ізоляцію, паралелізм чи чистоту трейсів (Anthropic+OpenAI+Cognition — рідкісний потрійний консенсус).
2. Пише один; решта читають — рецензування, критика й верифікація в чистих вікнах.
3. Фазовий конвеєр для кодингу — антипатерн; паралель — для read-heavy.
4. Суддя > кількість агентів; відбір > злиття; незгоду — структуруй.
5. Плануй 3–15× токенів — і питай, чи задача цього варта.

Вправи (Частина 11)

1. 11-A. Тобі треба за годину перевірити 40 мікросервісів на застарілі залежності. Один агент чи мультиагент? Який патерн і чому?
2. 11-B. Команда зробила «планувальника → кодера → тестувальника → рецензента» і скаржиться на якість. Що з цим не так за даними 2026 і як перебудувати?
3. 11-C. Ти зібрав 5 відповідей від 5 агентів і хочеш «обʼєднати найкраще з усіх». Чому це погана ідея і що зробити натомість?

Відповіді

1. 11-A. Мультиагент: класична read-heavy паралель без спільного змінного стану — map-reduce (оркестратор роздає по сервісах, воркери в чистих вікнах, зведення в кінці). Це наш власний робочий патерн батчів.
2. 11-B. Фазовий конвеєр — задокументований антипатерн (Anthropic: у розбитті за ролями підагенти витрачали більше токенів на координацію, ніж на роботу, а кожна передача губить контекст; приклад Flappy Bird у Cognition). Перебудова: один агент веде задачу від плану до коду (single-writer), а тестування й рецензування — окремі read-only агенти в чистих контекстах над його дифом.
3. 11-C. Наївний синтез програв одиночній моделі 0/42 (arXiv:2603.20324) і живить false consensus. Натомість: сильний суддя обирає одну найкращу відповідь (81% win rate), за потреби — структурована незгода (критик атакує вибір) перед фіналом.

Підсумок Частини 11. Суперечка «мультиагенти: так чи ні» закінчилася не перемогою сторони, а правилами: один пише — інші перевіряють; паралель — для читання, не для запису; сила — в судді, а не в натовпі; і все це коштує 3–15× — тож рахуй цінність задачі. Ми це не переказуємо — ми так збудували цей курс.

Джерела (перевірено 2026-09-19)

• Cognition — Don't Build Multi-Agents
• Cognition — Multi-Agents: What's Actually Working
• Anthropic Engineering — How we built our multi-agent research system
• Claude blog — When to use multi-agent systems
• OpenAI — Agents orchestration
• Claude Code — Subagents
• Anthropic — Managed Agents: multiagent orchestration
• When Agents Disagree (selection bottleneck)
• Adversarial Review
• Simon Willison про дослідницьку систему Anthropic

Частина 12. Керування контекстом агентів

Контекстне вікно — не безкоштовний ресурс, навіть коли воно 1M токенів. Ця частина — про виміряну деградацію («context rot»), чотири стратегії роботи з нею, серверні API-примітиви 2026 і економіку кешування.

📚 Джерела: Anthropic Engineering (context engineering, multi-agent, harnesses), емпірика — Chroma Context Rot (18 моделей), NoLiMa (ICML 2025), arXiv EMNLP 2025; офіційні API-докси (context editing, compaction, memory tool, prompt caching), докси Claude Code memory, контрапункт Cognition. Зібрано 2026-08-21, кожне твердження реально прочитане за URL.

12.1. Context rot — виміряний, а не відчутий

Три незалежні лінії доказів, що якість падає з ростом входу навіть у межах «підтримуваного» вікна:

• Chroma «Context Rot» (2025-07): 18 фронтирних моделей (Claude Opus/Sonnet/Haiku, GPT-4.1/4o/o3, Gemini 2.5, Qwen3) на контрольованих NIAH-варіантах при фіксованій складності задачі: «performance grows increasingly unreliable as input length grows». Найдивніше: перемішаний/незв'язний «стіг» давав кращі результати, ніж логічно зв'язний — у всіх 18 моделей; автори чесно кажуть, що пояснення немає.
• NoLiMa (arXiv:2502.05167, ICML 2025): якщо прибрати лексичний збіг між питанням і «голкою» (лишити тільки семантичний), 11 із 13 моделей із заявленими 128K+ падають нижче 50% свого short-context бейзлайну вже на 32K; GPT-4o: 99.3% → 69.7%. Reasoning-моделі теж деградують — «більше міркувань» цього не лікує.
• EMNLP 2025 Findings (arXiv:2510.05381): падіння 13.9–85% зі зростанням довжини навіть коли нерелевантні токени замінені пробілами/замасковані — отже, це не лише провал retrieval. Часткова милиця: «процитуй знайдені докази перед відповіддю» (+до 4% на RULER).

⚠️ Чесна межа даних: ці студії — на моделях 2025 року; реплікації на моделях 2026 року (Sonnet 5, Opus 5/5.5, Fable 5/5.1) ми не знайшли. Наскільки нове покоління помʼякшило context rot — відкрите питання (так і кажемо, а не вгадуємо).

Правило 12.1. Довге вікно ≠ дозвіл наливати все. Кожен токен у вікні має заробити своє місце.

12.2. Чотири стратегії (канон Anthropic Engineering, 2025-09-29)

1. Just-in-time retrieval — тримай у контексті легкі посилання (шляхи файлів, ID, запити), а вміст підтягуй інструментами в момент потреби; не преднавантажуй усе. Так працює Claude Code.
2. Compaction — біля межі вікна: підсумувати й реініціалізуватись, зберігаючи архітектурні рішення і невирішені вади, а не сирі виводи інструментів.
3. Структуровані нотатки / памʼять — знання живуть поза вікном у файлах і повертаються на вимогу. Приклад Anthropic: Claude грає в Pokémon тисячі кроків і сам веде нотатки — карти пройдених локацій і бойову стратегію.
4. Архітектури з підагентами — брудна підзадача йде в чисте вікно окремого агента, назад повертається дистилят на 1–2k токенів. (Контрапункт Cognition — див. Частину 11: для звʼязного кодингу ізоляція ріже спільні рішення.)

12.3. 2026: це вже примітиви API, а не хаки промпта

Найважливіший зсув року: керування контекстом переїхало на сервер.

Практичний патерн «multisession development» (докси + harness-пост 2025-11-26): initializer-сесія створює журнал прогресу, перелік функцій та init-скрипт; кожна наступна сесія читає й оновлює журнал перед завершенням; git — механізм відновлення. Це той самий патерн «зміни інженерів» із Частини 10.

12.4. Структуровані нотатки в реальному інструменті

Докси Claude Code (v2.1.2xx) — жива реалізація «нотаток» двох сортів:

• CLAUDE.md — пише людина; ієрархія scope'ів (managed/user/project/local), рекомендовано до 200 рядків на файл; переживає /compact (перечитується з диска) — на відміну від інструкцій, сказаних просто в розмові.
• Auto memory — пише сам Claude: ~/.claude/projects/<project>/memory/ з категоріями (user/feedback/project/reference) та індексом MEMORY.md (стеля 200 рядків / 25KB), який вантажиться щосесії; тіла тем — на вимогу (той самий just-in-time).

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

12.5. Економіка кешу: чому порядок у промпті = гроші

Офіційні докси prompt caching: читання кешу — 0.1× базової ціни входу (на Fable 5.1 і Mythos 5.1 — 0.025×, на Opus 5.5 — 0.05×); запис — 1.25× (5 хв TTL) або 2× (1 год). Але хіт вимагає байт-у-байт ідентичного префікса до breakpoint: один timestamp чи UUID на початку системного промпта = тихі 100% промахів. Змінені визначення інструментів інвалідовують весь ланцюг (tools → system → messages). Тому context-editing спроєктований обережно щодо кешу (clear_at_least існує саме щоб перезапис кешу окупався).

Правило 12.5. Стабільне — наперед (системний промпт, інструменти), змінне — в кінець. Це не стилістика, це 10× різниці в ціні входу.

12.6. Правила частини (зведення)

1. Кожен токен має заробити місце: релевантність > повнота (context rot виміряний трьома незалежними студіями).
2. Посилання в контексті, вміст — за вимогою (JIT).
3. Компакція — для розміру вікна; файлова памʼять — для істини, що мусить пережити компакцію; використовуй разом.
4. Брудні підзадачі — в чисті вікна підагентів, назад — дистилят (з поправкою Cognition для звʼязного кодингу).
5. Стабільний префікс = 10× дешевший вхід; volatile-контент нижче breakpoint.
6. Для довгих робіт: журнал прогресу + git як зовнішня памʼять «змін».

Вправи (Частина 12)

1. 12-A. Агент на 300-му ході погіршився: плутає давні рішення, «забуває» вимоги. Назви три механізми з цієї частини, які треба було закласти з початку.
2. 12-B. У системному промпті колеги перший рядок — Сьогодні: {datetime.now()}. Чому це дорого і як виправити?
3. 12-C. Чим відрізняються compaction і memory tool, і чому офіційна порада — використовувати їх разом?

Відповіді

1. 12-A. (1) Context editing / компакція, щоб старі tool-результати не витісняли важливе; (2) файловий журнал прогресу + нотатки рішень (переживають компакцію/ресети — патерн initializer→sessions); (3) підагенти для брудних підзадач, щоб сміття не потрапляло в головне вікно взагалі.
2. 12-B. Динамічний перший рядок ламає байт-ідентичність префікса → 0% кеш-хітів → вхід коштує ~10× дорожче можливого. Виправлення: волатильне (дату, ID) — після cache-breakpoint (в кінець системного промпта або в перше повідомлення), стабільне ядро — наперед.
3. 12-C. Compaction стискає вікно (сумаризує історію, щоб влізти далі), але сумарізація може загубити деталі; memory tool зберігає факти поза вікном назавжди і повертає на вимогу. Разом: компакція тримає розмір, памʼять — гарантує, що критичне (рішення, невирішені вади, стан функцій) переживе будь-яку сумаризацію чи ресет.

Підсумок Частини 12. У 2026 контекст — це бюджет, що деградує: виміряно на 18 моделях. Дисципліна: JIT-посилання замість преднавантаження, компакція для розміру, файли для істини, чисті вікна для бруду, стабільний префікс для економіки. І чесна прогалина: наскільки нове покоління моделей помʼякшило context rot — ще ніхто не переміряв.

Джерела (перевірено 2026-09-19)

• Anthropic Engineering — Effective context engineering
• Chroma — Context Rot
• NoLiMa (ICML 2025)
• Context Length Alone Hurts (EMNLP 2025 Findings)
• Anthropic — Context editing
• Anthropic — Compaction
• Anthropic — Memory tool
• Anthropic — Prompt caching
• Claude Code — Memory (CLAUDE.md, auto memory)

Частина 13. Локальні LLM для розробки

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

📚 Джерела: офіційні випуски й картки (OpenAI gpt-oss GitHub, Google ai.google.dev, Qwen HF, DeepSeek api-docs), докси llama.cpp і vLLM, hands-on Віллісона, arXiv про квантизацію. Зібрано 2026-08-21. Що ми свідомо викинули після адверсаріальної перевірки: заяву про нову відкриту модель Meta (непідтверджений домен джерела) і конкретні Qwen-бенчмарки з офіційної картки (не відтворені незалежно). Викинули й рейтинги «best local model» з агрегаторів: SEO-сайти не пройшли фільтр джерел.

13.1. Ландшафт відкритих моделей (перевірене ядро)

Розрив із хостед-фронтиром (консенсус джерел): суттєво звузився у 2025–2026, але не закрився — особливо на складних довгогоризонтних багатофайлових задачах. Водночас Віллісон (05.2026) пише, що ноутбукові моделі «while a lot weaker than the frontier, have started wildly outperforming expectations». Його приклад: Qwen3.6-35B-A3B (20.9 ГБ) на ноутбуці намалював пелікана на велосипеді краще за Claude Opus 4.7. Сам автор застерігає, що цей тест уже вичерпав себе як бенчмарк.

13.2. Стек запуску

• Споживчий: llama.cpp (двигун + формат GGUF) → Ollama і LM Studio як обгортки над ним.
• Серверний: vLLM — продакшн-throughput; квантизації AWQ/GPTQ/FP8/INT4/INT8/GGUF, але підтримка різко різниться за залізом (Marlin і bitsandbytes — лише NVIDIA; на AMD — лише GGUF і FP8; CPU-шлях мають AWQ і GPTQ на x86 та INT8 із llm-compressor, а GGUF у vLLM на CPU не працює — для CPU бери llama.cpp) — звіряй матрицю в доксах.
• Apple Silicon — першокласна платформа, не ніша: unified memory + MLX; Ollama отримав MLX-рушій для Apple Silicon (спершу як прев'ю), а MLX-кванти викладає спільнота: для Qwen3.8-27B mlx-community опублікувала їх 14.08.2026.

Реальність швидкості (hands-on Віллісона, 08.2026, M-серія Mac + 27B Q4_K_M): 15–30 tok/s базово (проти ~74 у порівнянної хостед-моделі); спекулятивне декодування додає ~72%. І показовий випадок про типові налаштування: reasoning-режим xhigh на простий SVG-промпт витратив 21 хвилину і 22 276 токенів на міркування проти 137 секунд без reasoning — «This is a hilarious default». Мораль: на локальних reasoning-моделях типовий effort перевіряй насамперед.

13.3. Квантизація: що кажуть інженерні доки і дослідження

• Драбина GGUF (README llama.cpp): від IQ1 до Q8_0/F16; втрати точності «minimized by a suitable imatrix file»; для мультимодальних — vision/projector лишай у bf16/q8 (там деградація помітніша). Канонічної «однієї правильної» кванти проєкт свідомо не призначає; Q4_K_M — робочий приклад.
• Два якісно різні режими деградації (arXiv:2604.19884, 2026): 4-bit — «signal degradation»: сигнал знань є, шум зростає — відновлюване; 2-bit — «computation collapse»: ламається сам обчислювальний процес (увага в усіх шарах перестає концентруватися; понад 30% входів гейта SwiGLU у FFN змінюють знак — виміряно на щільних 7–9B моделях: Llama-3.1-8B, Qwen3-8B, Mistral-7B, Gemma-2-9B), і training-free ремонт не працює.

Правило 13.3. Q4_K_M-клас — обґрунтований типовий вибір; 8-bit — коли є памʼять і потрібна якість; 2-bit — не «трохи гірше», а інший режим відмови.

13.4. Навіщо локальні, якщо фронтир сильніший

Драйвери, незалежні від сирої якості (консенсус джерел):

1. Суверенітет даних і комплаєнс — HIPAA, GDPR і EU AI Act. Акт застосовується з 2 серпня 2026 року з винятками: правила для високоризикових систем пакет «AI Omnibus» переніс на 2.12.2027 і 2.08.2028. Для регульованих індустрій «дані не покидають периметр» — вимога, а не смак.
2. Вартість на масі — класифікація чи екстракція на мільйонах елементів без per-token білінгу.
3. Латентність/офлайн — edge, повітряні зазори, CI без зовнішніх викликів.
4. Дослідження — повний контроль ваг, файнтюни, відтворюваність.

13.5. Чи переноситься наш головний висновок? (чесна відповідь: так, з поправкою)

Наше виміряне (Частини 5–6): «що менша модель, то важливіший промпт» — Haiku карала за слабкі промпти там, де Sonnet прощав.

• На локальні моделі це переноситься прямо: вони здебільшого менші або старших поколінь. Схемний режим у локальних стеках є (Ollama, llama.cpp), але він гарантує синтаксис, а не зміст. Тож наша драбина — few-shot формат, якорі першого символу, закриті набори міток, перевірка на виході — саме їхній інструментарій. Докси Anthropic формулюють той самий принцип («clear, explicit instructions… brilliant but new employee»).
• Поправка, яку показало дослідження: усередині фронтир-родини тренд зворотний — що новіша/сильніша модель, то менше агресивної явності треба (старі «CRITICAL: YOU MUST» на нових моделях overtrigger'ять). І окремий випадок: DeepSeek R1 офіційно радить уникати few-shot (деградує reasoning) — model-conditional правило з Частини 9.

Синтез 13.5. Вісь «розмір → явність» працює в межах покоління; вісь «покоління → менше тиску» працює впоперек. Для конкретної локальної моделі: почни з нашого Haiku-плейбука, потім звір картку моделі (особливо щодо few-shot і типових налаштувань reasoning) і зніми зайвий тиск, якщо модель сучасна.

13.6. Правила частини (зведення)

1. Локальний стек 2026: llama.cpp/GGUF (+Ollama/LM Studio) для десктопа, vLLM для сервера, Apple Silicon — повноправний громадянин.
2. Q4 — типовий вибір, Q8 — якість, 2-bit — небезпечна зона (інший режим відмови).
3. Перше, що перевіряєш на локальній reasoning-моделі — типовий effort (випадок «21 хвилина на SVG»).
4. Мотив локальності — суверенітет/маса/латентність, а не «наздогнали фронтир» (не наздогнали — на найважчому).
5. Промптинг локальних = наш Haiku-плейбук + картка конкретної моделі.

Вправи (Частина 13)

1. 13-A. Медична компанія (GDPR/HIPAA) хоче класифікацію звернень на своєму залізі: одна 24GB GPU. Запропонуй модельний клас, кванту, стек — і два прийоми промптингу з ядра курсу.
2. 13-B. Колега тішиться: «стиснув 70B у 2-bit — влазить у ноутбук!» Що йому показати з 13.3?
3. 13-C. Локальна reasoning-модель «висить» хвилинами на простих запитах. Перша гіпотеза і виправлення?

Відповіді

1. 13-A. Клас 20–31B (gpt-oss-20b / Gemma 4 26B-A4B чи 31B / Qwen-27B) у Q4_K_M через Ollama/llama.cpp (або vLLM, якщо потрібен throughput). Формат — вивід за JSON-схемою (Ollama: параметр format; llama.cpp: json_schema чи grammar). Поверх нього — few-shot із закритим набором міток + «output only the label» (наші 100%-надійні техніки) і перевірка значень: схема гарантує синтаксис, а не правильну мітку.
2. 13-B. arXiv:2604.19884: 2-bit — це не плавне «трохи гірше», а computation collapse (увага перестає концентруватися, понад 30% входів гейта SwiGLU змінюють знак), який не ремонтується без тренування. Краще менша модель у Q4, ніж велика у Q2.
3. 13-C. Типовий reasoning-effort виставлений у максимум (задокументований випадок: xhigh = 21 хв і 22k токенів на тривіальний SVG). Виправлення: знизити/вимкнути reasoning для простих задач у налаштуваннях запуску, лишити високий effort лише для складного.

Підсумок Частини 13. Локальні LLM у 2026 — зрілий інструмент зі своєю нішею: суверенітет, маса, латентність. На найважчих задачах вони чесно відстають. А наш власний плейбук стає для них інструкцією з експлуатації: усе, що курс виміряв на Haiku, вчить отримувати максимум від малих моделей.

Джерела (перевірено 2026-09-19)

• OpenAI gpt-oss
• Gemma 4 — картка моделі
• Gemma 3 — картка моделі
• Qwen3.8-27B
• DeepSeek V4 — анонс
• DeepSeek — журнал змін API
• Meta — Llama 4
• Simon Willison — Qwen 3.8 27B локально
• Simon Willison — огляд локальних моделей (05.2026)
• llama.cpp — quantize README
• vLLM — Quantization (матриця заліза)
• Signal Degradation → Computation Collapse
• Ollama — MLX на Apple Silicon
• Ollama — Structured outputs
• Єврокомісія — AI Act, графік застосування