Коли рекрутер натискає "створити задачу" в панелі merged, кандидат не отримує готовий ТЗ одразу. Він отримує його лише після того, як чотири Bedrock-агенти прочитали репо замовника, склали чернетку, відкалібрували її під рівень кандидата і, нарешті, перечитали весь текст ще раз — очима самого кандидата. Останній агент зʼявився в квітні 2026-го і називається Verifier.
Ось як це влаштовано всередині і чому ми пішли саме цим шляхом.
Чому не "один виклик Claude"
Перша версія генератора задач виглядала очевидно: беремо URL репо, відправляємо Claude з промптом "склади задачу для мідл-розробника", приймаємо результат. Працювало в 60% випадків. У 40% задача була або надто легка/важка, або посилалась на файли, яких у репо немає, або мала rubric без жодного auto-measurable критерію, або просто була неоднозначною (кандидат не розумів, що саме треба зробити).
Ми спробували товстіші промпти. Стало краще на 5–7 процентних пунктів. Це було недостатньо: один ТЗ у бета-періоді з "make the code better" — і ціла команда замовника витрачає день на розбір апеляції.
Тоді ми переписали це як пайплайн.
Чотири агенти, кожен зі своєю роллю
Repo → [Scout] → [Composer] → [Calibrator] → [Verifier] → ТЗ кандидату
↑_____________revisions loop (до 3 ітерацій)____|
1. Scout (Claude Haiku 4.5)
Scout сканує репо паралельно (до 10 воркерів), знаходить "поверхні" — реальні точки застосування роботи: baги, прогалини в тестах, рефактори, feature-gaps, concurrency issues, data-model рішення. Для кожної повертає kind, path, summary, fit_levels, score 0–100.
Haiku 4.5 тут — бо це читання, класифікація і винесення в структуру. Для цього не треба Opus.
2. Composer (Claude Opus 4.7)
Composer бере 15 найкращих поверхонь від Scout і обирає одну — ту, що найкраще лягає на рівень кандидата. Потім складає два артефакти: task.yaml (схема задачі — level, time_limit_min, description_md, seeds, rubric з вагами, які мають давати 100) і ASSIGNMENT.md (інструкції для кандидата українською).
Тут уже потрібен Opus: Composer робить вибір і написання, а не читання. Якість драфту визначає усе, що буде далі.
3. Calibrator (Claude Opus 4.7)
Calibrator — це двоетапна перевірка:
- Детерміністичний schema-стейдж валідує YAML: чи ваги rubric сумуються в 100, чи 3–5 seeds, чи рівень відповідає цільовому, чи всі поля в межах. Ці помилки ловляться без моделі.
- LLM-стейдж перевіряє когерентність: task.yaml vs ASSIGNMENT.md, anti-cheat (чи не вирішується задача одним промптом до AI), scope vs time_limit, rubric vs description.
Якщо Calibrator знаходить помилки — вони повертаються в Composer як revisionNotes, і той складає нову чернетку, тримаючись того самого seed, але виправляючи список зауважень.
4. Verifier (Claude Opus 4.7) — новий
Calibrator ловить внутрішню несуперечливість. Verifier ловить несправедливість для кандидата.
Він читає той самий task.yaml + ASSIGNMENT.md уже post-Calibrator, але зі зовсім іншим фокусом:
- Чи зрозуміє задачу кандидат цього рівня без уточнень? Чи немає "make it better" / "optimize" без конкретики?
- Чи кожен seed справді реалізує інший підхід, описаний у description, а не косметичне переіменування?
- Чи існують файли/модулі, на які посилається ASSIGNMENT.md? (Verifier знає list мов і кількість файлів з Scout.)
- Чи rubric criteria можна оцінити обʼєктивно?
source: auto— тільки там, де справді можна CI-виміряти? - Чи
time_limit_minузгоджений з реальним обсягом? - Scope leak: чи не вимагається щось поза level (architecture для junior) або поза стеком?
- Чи прописано кандидату, як запускати, тестувати, здавати, і що таке "готово"?
Якщо знайдено issues — вони йдуть Composer як revisionNotes, і цикл Composer → Calibrator → Verifier повторюється. До трьох ітерацій. Якщо Verifier не сказав "ошибок нет" за 3 рази — задача падає з detailed error, і HR отримує fallback-шаблон (ніхто не чекає, поки "AI згенерує ідеально").
Чому саме Opus 4.7
Три з чотирьох агентів (Composer, Calibrator, Verifier) працюють на Claude Opus 4.7 — найновішій моделі Bedrock-серії Opus. Це не маркетингове узгодження з релізом Anthropic: ми порівняли 4.6 і 4.7 на калібрувальному сеті з 120 задач, розмічених двома staff-інженерами.
Різниця була не в 1–2 пунктах, а в характері помилок:
- Opus 4.6 інколи "коректно" пропускав ТЗ з rubric, де всі критерії були
source: llm— без жодного автоматично вимірюваного. Verifier на 4.6 не вважав це проблемою. - Opus 4.7 ці випадки ловить. Припущення: краща калібровка на довгих структурованих output — Verifier має тримати в голові task.yaml + ASSIGNMENT.md + meta одночасно.
Haiku 4.5 залишається на Scout, бо там треба не судження, а класифікація по 11 SurfaceKind — і Haiku тут на рівні з Opus при 10x нижчій латентності.
Що це дає кандидату (і HR)
- Менше апеляцій "задача нефер". За три тижні з Verifier у проді — нуль випадків, де кандидат оскаржив саму постановку ТЗ (до Verifier — 1 на ~50 задач).
- Зрозуміла мова. ASSIGNMENT.md не має "зроби краще" — Verifier вимагає конкретики.
- Гряблі rubric. Кожен критерій має спостережуваний сигнал. Ніхто не ставить 0 за "code idiomaticity" без прикладу.
- Калібровані seeds. Три seeds дійсно означають три різні шляхи вирішення, а не копії з різними іменами.
Що залишилось відкритим
Verifier ловить проблеми ТЗ. Виконання ТЗ кандидатом оцінює окремий пайплайн — LLM-суддя з трьох етапів (нормалізація → per-criterion → агрегація, теж на Opus 4.7). Про нього — окрема стаття: "Рубрика як артефакт".
Для нас ідеал — замкнути петлю між двома пайплайнами: щоб Verifier-генератор і LLM-суддя-грейдер калібрувалися одне об одного на загальному сеті. Це наступні 3 місяці.
Технічні деталі для любителів деталей
- Усі чотири агенти — в одному npm-пакеті
@merged/task-composer, без черг: Server Action блокується на 60–90 секунд. - Bedrock-реджн:
eu-central-1(Франкфурт) — дані не виходять за межі ЄС. - Бюджет токенів: ~180k на Scout/Composer-чанк, 8192 max output для Composer, 2048 для Calibrator/Verifier.
- Retry на 429/5xx з jitter-exponential backoff (3 спроби).
- Env-змінні для моделей:
BEDROCK_SCOUT_MODEL_ID,BEDROCK_COMPOSER_MODEL_ID,BEDROCK_CALIBRATOR_MODEL_ID,BEDROCK_VERIFIER_MODEL_ID— будь-який можна перевизначити у staging/dev.
Якщо цікаво, як це живе в коді — дивіться packages/task-composer/src у репо merged (публічним буде разом з launch-wave Q2 2026).