1. Capstone оцінюють за rubric, а не за відчуттям
Коли студент уперше чує слово rubric, у голові інколи виникає щось лячне й трохи бюрократичне: ніби зараз прийде людина з обличчям податкового інспектора й перевірить, чи достатньо у вас духовної близькості з README.md. Насправді все простіше: rubric потрібна, щоб оцінка не залежала від враження й настрою. Ментор не чує драматичну музику, під яку ви лагодили баг о другій ночі. Він бачить артефакти.
До цього моменту у вас уже є дві опори: зібраний submission package і зрозумілий defense narrative. Rubric не будує поверх них третю систему — вона читає ті самі README.md, SPEC.md, DEMO.md, EVIDENCE.md і ту саму розповідь очима reviewer.
flowchart LR
A[Результат] --> E[Довіра до capstone]
B[Процес] --> E
C[Якість] --> E
D[AI-native workflow] --> E
Найзручніше дивитися на rubric не як на довгий страшний список, а як на чотири великі блоки: результат, процес, якість і AI-native спосіб роботи. Усередині них — ті самі 11 напрямів оцінювання з плану курсу.
| Блок оцінювання | Що всередині | На що реально дивиться ментор | Які артефакти це показують |
|---|---|---|---|
| Результат | робочий результат, зрозумілість демо, готовність для портфоліо | Чи працює core flow, чи можна швидко зрозуміти цінність проєкту, чи годиться він як proof-of-work | DEMO.md, відео, README, скриншоти, жива демонстрація |
| Процес | дисципліна scope, якість task spec, дисципліна Git/diff, traceability | Чи керували ви задачею як інженер, а не як людина в режимі «ой, воно саме виросло» | SPEC.md, EVIDENCE.md, commits, diff, PR walkthrough |
| Якість | тести/перевірки, документація, усвідомлення ризиків | Чи є докази коректності, чи вмієте ви бачити межі та ризики | тести, smoke checks, README.md, limitations, verification notes |
| AI-native workflow | використання Claude Code, доречність важливіша за кількість | Чи використовували ви Claude Code усвідомлено й доречно, а не як декоративний феєрверк | CLAUDE.md, notes про skills/agents, review notes, evidence щодо використання AI |
Тут є тонкий, але дуже важливий момент. Rubric відповідає не на «чи сподобався проєкт», а на «чи можна довіряти цьому результату та людині, яка його зробила?». Маленький проєкт із сильною traceability бʼє великий і ефектний, який розвалюється на першому ж «а як ви це перевіряли?».
Тому working result — лише один шар. Демо спрацювало, але немає SPEC.md, evidence щодо перевірок, пояснення ролі Claude Code, усе тримається на «ну в мене запускалося» — оцінка буде слабшою. Інженерія — не конкурс фокусів: важливий не кролик із капелюха, а розуміння, чому він не вибухне під час наступного запуску.
2. Обовʼязковий мінімум для будь-якого захисту
Інколи студенти сприймають rubric як систему, де обовʼязково треба «добирати фішки»: два агенти, один hook, три скриншоти — майже комбо. Але в захисту є нижня межа — must-have мінімум, нижче якого capstone виглядає не як інженерний проєкт, а як надія, замаскована під репозиторій.
| Що має бути | Навіщо це потрібно | Що ламається, якщо цього немає |
|---|---|---|
| Робочий core flow | Показує, що проєкт не лише задумано, а й доведено до результату | Захист перетворюється на розповідь про прекрасні наміри |
| Зрозумілий README і setup | Дозволяє зовнішній людині запустити проєкт без телепатії | Виникає класичне “works on my machine” |
| SPEC.md і видимий scope | Показують, що задача була поставлена усвідомлено | Проєкт здається хаотичним і випадково розростеним |
| Evidence щодо tests/checks | Доказують, що результат перевіряли, а не просто він сподобався автору | Будь-який баг на демо виглядає як системна проблема |
| Чесні limitations | Показують інженерну зрілість і розуміння меж | Обмеження знайде ментор, і ефект буде гіршим |
| Ясне пояснення ролі Claude Code | Показує вашу відповідальність за процес | Виникає питання: «це зробили ви чи просто увімкнули генератор?» |
| Відсутність секретів і приватних даних | Це базова професійна гігієна | Навіть сильний capstone отримує неприємний червоний прапорець |
Добра новина в тому, що цей мінімум вимагає не «суперпроєкту», а зібраності. Відтворюваний MVP із ясним core flow, виразним README.md, збереженим SPEC.md, базовими перевірками й чесними обмеженнями вже стоїть на міцній землі. Не на хмарочосі з маркетингових обіцянок, зате не по коліна в болоті.
Ось так може виглядати цілком нормальний фрагмент evidence для capstone рівня MVP:
## Перевірка
- Core flow: тикет → класифікація → чорновик відповіді → ручне підтвердження
- Команда перевірки: `pytest -q`
- Smoke check: high-value refund не йде без підтвердження
- Limitations: мультимовність і CRM-інтеграція поза поточним scope
Цей фрагмент добрий не довжиною: після нього в перевіряча менше білих плям — видно, що саме працює, чим це перевірено і чого ви свідомо не обіцяєте. Із цього збирається довіра.
Корисно памʼятати й ще одну річ: must-have мінімум однаково важливий для всіх рівнів. Junior не скаже «я новачок, мені можна без evidence», Senior — «у мене складний проєкт, мені README.md не потрібен». Різниця між рівнями не в наявності артефактів, а в їхній глибині.
3. Одні критерії, три рівні: Junior, Middle, Senior
Тут зʼявляється частина, яку студенти особливо люблять недооцінювати: раз rubric одна, значить і всіх міряють однією лінійкою. Але курс улаштовано акуратніше. Осі оцінювання однакові, а глибина очікувань різна.
| Напрям | Junior | Middle | Senior |
|---|---|---|---|
| Результат | Є робочий core flow і зрозуміле демо | Є відтворюване демо та більш явний walkthrough | Є повний захист з акцентом на архітектуру, ризики або governance, якщо формат цього вимагає |
| Процес | Видно, що був task spec і дисципліна щодо scope | Видно мислення issue-to-PR, commits і traceability | Видно управління ризиками, decision points, інколи policy або migration logic |
| Якість | Є smoke checks і базова перевірка | Є серйозніші tests/checks, інколи CI evidence | Є зріла verification-логіка, мислення щодо rollback або characterization evidence, якщо це релевантно |
| AI-native workflow | Зрозуміло, де допоміг Claude і що перевіряли вручну | Є осмислене застосування Claude в аналізі, коді, review, документації | Є не лише використання, а інколи й проєктування workflow-шару: agents, policy, team assets |
Найважливіший висновок із цієї таблиці такий: Senior не зобовʼязаний бути «більшим», він зобовʼязаний бути глибшим. Junior не програє через відсутність migration slice або team policy. Акуратний MVP не сварять за відсутність compatibility matrix — сварять за розпливчастий scope, неперевірний результат, нечітке використання Claude Code і проєкт, який тримається на «але ідея була класна».
Тут дуже допомагає памʼятати про capstone-формат. Порівнювати Support Inbox MVP і Migration slice — це як сперечатися, хто кращий, викрутка чи мікрохвильовка. Обидва корисні в різних задачах. Тому advanced-частини rubric привʼязані до формату: MVP — user value, demo scenario та scope discipline; migration slice — compatibility, rollback і validation evidence; team workflow design — policy, governance та package maturity.
Якщо це правило забути, починається кумедна, але сумна картина: студент із хорошим MVP ліпить псевдоміграційні нотатки «для солідності», а студент із migration capstone додає зайвий UI «для красивої морди». Сильна робота — не максимум усього підряд, а влучання в очікування свого рівня та формату.
4. AI-native workflow: доречність важливіша за зоопарк
Найхитріша ділянка. На словах усі погоджуються з правилом доречність важливіша за кількість, а на практиці рука тягнеться написати: «використовував 3 агентів, 2 hooks, MCP, custom skill і ще одну штуку, яка має гарну назву, але вже ніхто не памʼятає навіщо». Для ментора це не зрілість, а AI-зоопарк.
Сильний AI-native workflow — це не перелік механізмів Claude Code, а пояснення, яку конкретну інженерну проблему кожен із них вирішував. Іноді відповідь — «жодну, тому я їх і не використовував». І це, між іншим, чудова відповідь.
Порівняйте два варіанти опису.
Поганий варіант
Використовував 2 hooks, 3 agents, MCP server і custom plugin.
Claude дуже допоміг у розробці.
Хороший варіант
Використовував `issue-analysis` skill для уточнення критеріїв приймання.
Запускав reviewer-agent у read-only режимі перед демонстрацією diff.
Після цього вручну перевірив зміни й прогнав smoke check.
Hooks і MCP не підключав: для цього capstone вони не давали додаткової цінності.
У другому варіанті одразу видно: ви керували інструментами, а не вони вами. Rubric хоче не «вау, скільки увімкнено», а «я розумію, навіщо це потрібно й чому щось не знадобилося».
Ще корисніше дивитися на advanced credit крізь призму формату capstone.
| Формат capstone | Що особливо підсилює оцінку |
|---|---|
| Feature in existing codebase | issue-to-PR trail, добрий diff, checks, відтворюваний walkthrough |
| AI-native MVP | user/JTBD, чіткий release slice, переконливий demo scenario |
| Legacy modernization | characterization tests, маленькі безпечні кроки refactor, збереження поведінки |
| Migration slice | compatibility matrix, rollback plan, validation evidence |
| DevOps automation | відтворюваність pipeline, логи, bounded automation, явні межі ризику |
| Team workflow design | policy, package maturity, plugin/skill architecture, governance |
Ця таблиця дуже добре лікує від зайвого героїзму. У вас Support Inbox MVP — допоможуть користувацький сценарій, SPEC.md, чесні checks і роль Claude Code, а не насильно вирощений migration appendix. У вас migration slice — ніхто не чекає посадкової сторінки з трьома градієнтами; чекають evidence, rollback, parity, розуміння ризиків.
Інколи найвищий бал дає не «ще один інструмент», а рядок у EVIDENCE.md, де видно, що ви свідомо зупинилися: «агента на write не переводив, тому що задача зачіпала критичний модуль». Це говорить про зрілість сильніше за пʼять заяв про «активне використання AI».
5. Самостійний прогін rubric перед захистом
Найкорисніша звичка в цьому модулі — перестати ставитися до оцінювання як до сюрпризу. Поки ви в режимі «сподіваюся, ментору сподобається», захист — лотерея. Відкрийте rubric, чесно зіставте її зі своїми артефактами — і захист стане звичайною інженерною перевіркою. Хвилювання залишиться, містика зникне.
Самоперевірку зручно вести не в числах, а в простих статусах: strong, medium, weak. Це людський формат. Без ілюзії точності, зате одразу видно, де проєкт міцний, а де крихкий.
Ось мінімальний шаблон, з якого можна почати:
| Напрямок | Статус | Evidence |
|-------------------|--------|----------|
| working result | strong | `DEMO.md`, відео, smoke check |
| task spec quality | medium | `SPEC.md` є, критерії приймання можна звузити |
| tests/checks | weak | є лише smoke, немає regression test |
| Claude usage | strong | `EVIDENCE.md`, review notes, ручна перевірка diff |
Уся хитрість у третій колонці. Статус без evidence — це просто настрій. Ставите strong — покажіть артефакт. Ставите weak — зате знаєте, де саме слабке місце. Уже половина користі.
Дуже часто після такого self-check розкривається корисна правда: working result strong, а tests/checks — medium, тому що є лише smoke; або Claude usage weak-medium, тому що в EVIDENCE.md усе загальними словами — «Claude допомагав із кодом». Ментор це теж побачить. Краще познайомитися з цією думкою вдома, за чаєм, ніж на захисті.
І ще один дорослий висновок: слабкий рядок в одному базовому напрямі часто важливіший за кілька красивих advanced-фішок. Weak reproducibility не врятує зайвий agent, vague task spec не виправить акуратний hook. Rubric не дає замазати фундамент красивою мішурою.
Коли ви чесно проганяєте capstone через цю матрицю, проєкт не стає гіршим — він стає видимим. Замість нервового «раптом оцінять не те» зʼявляється карта: де результат сильний, де процес зібраний, де якість підтверджено, а де AI-native workflow треба пояснити точніше. Один із найкорисніших навичок фінального блоку курсу.
Саме тому self-check робіть до зовнішнього review. Якщо рядок тримається лише на відчутті, mentor побачить ту саму дірку зовні. Краще прийти на review зі зрозумілою картою: де capstone уже strong, де medium, а де потрібне доопрацювання або чесне обмеження.
ПЕРЕЙДІТЬ В ПОВНУ ВЕРСІЮ