Рівневі очікування та guardrails

1. Capstone не можна міряти однією лінійкою

Коли студент чує слова «Junior, Middle, Senior», мозок дуже любить звести все до примітивної шкали: маленький проєкт, середній, величезний. Зручно і шкідливо. У capstone важливий не розмір, а тип доказу, який ви приносите на захист. Рівні розходяться не за принципом «більше кнопок — вищий рівень», а за тим, що саме ви маєте показати.

Якщо намагатися оцінювати всіх однією лінійкою, картина вийде дивною. Junior бере migration slice, тому що «звучить серйозно», тоне в сумісності залежностей і планах відкату та до демо не доживає. Senior робить симпатичний екран без ризиків, валідації та компромісів — формально працює, а володіння процесом не розкрито. Річ не в тому, що один гірший. Доводити їм потрібно різне.

Ось корисна коротка таблиця, яку варто тримати в голові весь блок:

Зверніть увагу: ніде немає пункту «написати побільше коду». Головний герой capstone — ваш процес роботи, а не те, що результат виник із туману після нічного діалогу з Claude.

2. Рівневі очікування: різні фокуси оцінювання

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

Тому правильніше думати не «Junior — маленький capstone, Senior — великий», а інакше: Junior доводить завершеність, Middle — керованість, Senior — контрольовану складність. Це важливо ще й тому, що знімає зайву театральність: зображати Senior заради враження не потрібно. Скромний, але чесно доведений проєкт із хорошим verification trail сильніший за напівзруйнований «суперапп», який на словах уміє все, а на демо відкриває головну сторінку і загадково обіцяє масштабуватися.

3. Junior: завершений core flow важливіший за амбіції

Для Junior capstone має виглядати не як міністартап, а як один зрозумілий, завершений, перевірюваний сценарій. Ключове слово тут — завершений. Не «майже працює», не «тут руками підправити JSON — і буде красиво», не «потім додам обробку помилок». Core flow проходиться від початку до кінця й переповідається за пару речень: оператор бачить список заявок на скасування підписки, відкриває картку, підтверджує дію, отримує статус. Цього достатньо, якщо є SPEC.md, базовий README, проста smoke-перевірка і пояснення, де допомагав Claude, а що ви перевіряли самі.

Ось так може виглядати фрагмент хорошого Junior SPEC.md:

# Фрагмент SPEC.md

Проблема: оператору незручно вручну скасовувати тестову підписку
Core flow: відкрити клієнта → натиснути «Скасувати» → підтвердити дію
Smoke check: скасування тестової підписки проходить без помилки
Не входить: ролі, email-сповіщення, повернення платежу, деплой

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

Для Junior особливо важливо запамʼятати просте правило: відсутність advanced mechanisms — не слабкість. Не використовуєте MCP, hooks, власних агентів і plugin-архітектуру — нормально, доки workflow дисциплінований. Іноді найкращий інженерний вчинок на Junior — чесно відмовитися від красивої непотрібної складності. Напередодні дедлайну це виглядає не так ефектно, зате зріло.

4. Middle: проєкт стає не більшим, а прозорішим

На Middle-рівні capstone не обовʼязково раптом роздувається втричі. Відмінність не в кількості екранів, а в тому, що стає видимим сам процес розробки. Junior доводить «я вмію завершити», Middle — «я вмію вести інженерну задачу по кроках і не втрачати контроль».

Це означає, що від вас уже очікують не просто робочий сценарій, а структуру руху до нього: розбиття на задачі, «спочатку план, потім код», невеликі коміти, перевірки, читання diff, оновлення документації, demo scenario. Claude Code тут — уже не лише «помічник написати код», а й інструмент для дослідження, чернеток документації, ревʼю та перевірки гіпотез.

Наприклад, один і той самий сценарій скасування підписки на Middle-рівні може супроводжуватися приземленим, але сильним планом:

## План реалізації

1. Описати поточний сценарій і критерії приймання
2. Додати екран підтвердження скасування
3. Додати smoke- або regression-перевірку
4. Перевірити diff і оновити README

Або навіть так, в історії комітів:

feat: додати екран підтвердження скасування підписки
test: додати smoke-сценарій скасування
docs: оновити README і DEMO.md

На вигляд це не космічні технології. Але саме такі речі відокремлюють «у мене вийшло» від «я вмію інженерно провести задачу від ідеї до демонстрації».

На Middle-рівні особливо часто спрацьовує кумедна пастка. Студент думає: «Щоб показати ріст, треба більше фіч», — і додає другий потік, третій екран, четверту інтеграцію. Ріст показується інакше: через traceability і керованість. Простіший проєкт, але з ясним SPEC.md, зрозумілим backlog, невеликими комітами, checks, demo path і виразним README — сильніший за хаотичний «багатий» продукт, який не відтворити з холодного старту. Middle — момент, коли capstone із «просто штуки, яка працює» стає добре розказаною інженерною історією.

5. Senior: складність лише разом із доказами

На Senior-рівні справді можна брати важчі формати: legacy modernization, migration slice, DevOps automation, team workflow design. Але разом із рівнем приходить важливе правило: складність не заборонена, але за неї треба платити доказами. Це означає, що формула «зробив складну штуку — значить молодець» не працює.

Якщо ви торкаєтеся legacy-зони — потрібні дослідження з опорою на evidence, RISK_MAP.md і розуміння межі змін. Migration slice — потрібні не лише план оновити залежності, а й логіка валідації, мислення про сумісність, шлях відкату. Team workflow design — сила не в словах «plugin», «policy», «agents», а в наявності owner, README, change log, меж використання і поясненні, навіщо цей toolkit потрібен команді.

Фрагмент Senior-артефакта може виглядати ось так:

## Ризик

Security-конфіг зачіпається міграцією

## Перевірки
- логін
- refresh-сесія
- скасування підписки авторизованим користувачем

## Відкат
повернутися на останній зелений тег і вимкнути migration branch

Зверніть увагу: тут мало пафосу, багато нудної дорослої акуратності. Сила Senior-рівня виглядає саме так — не як феєрверк, а як здатність пояснити, чому вибрано цей шлях, а не красивий, але небезпечний rewrite. Тут багато хто намагається вразити гучними словами: «DevOps automation з AI agents і governance» звучить красиво, але без відтворюваного сценарію, артефактів і пояснення, хто що перевіряє і як проєкт відкочується, це лишається гарною вивіскою.

Якщо говорити зовсім коротко, Senior-проєкт хороший не кількістю складних слів, а тим, що в ньому складність утримана в рамках. Важлива не здатність сказати «так» великій ідеї, а здатність вчасно сказати «ні» зайвій складності, яку не підтверджує evidence.

6. Scope guardrails: обмеження, що рятують capstone

Слово guardrails можна перекласти по-людськи як «обмежувачі» або «захисні рейки». Звучить не надто романтично, але працює чудово: потрібні вони, щоб capstone не зʼїхав у кювет на середині курсу з гордим гаслом «затим ідея була амбітна». Головна думка тут проста: у capstone майже завжди небезпечніше додати зайве, ніж прибрати. Кожне «ще маленьке покращення» тягне за собою нові перевірки, сценарії, unknowns і шанси зламати демо.

Дуже корисно тримати в голові ось таку схему:

flowchart TD
    A[Ідея capstone] --> B{Є один core flow?}
    B -- Ні --> C[Звузити scope]
    B -- Так --> D{Відповідає вашому рівню?}
    D -- Ні --> E[Спрощити формат або ідею]
    D -- Так --> F{Потрібні advanced mechanisms?}
    F -- Ні --> G[Не додавати їх заради краси]
    F -- Так --> H[Записати, яку проблему вони розв’язують]
    G --> I[Зафіксувати в SPEC.md]
    H --> I

Ця схема спеціально нудна — як і вся дисципліна guardrails. Але саме вона рятує більше capstone-проєктів, ніж будь-яка мотиваційна промова. Найчастіші guardrails виглядають так:

## Не входить у проєкт

- production deployment
- реальний платіжний провайдер
- мультитенантність
- push-сповіщення
- адміністративна панель

Багатьом студентам спочатку здається, що такий блок — визнання слабкості. Насправді це виглядає як інженерна зрілість. Будувати весь світ ви не зобовʼязані — ви зобовʼязані чесно обмежити світ проєкту до розміру, який зможете захистити.

Є кілька особливо підступних пасток. Перша — обіцянка «production-ready»: для навчального capstone це розмиває межі й відкриває безкінечний список — а де observability, деплой, безпека, план відновлення? Чесніше: «прототип, готовий до демо, з відтворюваним core flow і зрозумілими обмеженнями». Друга — складні інтеграції з авторизацією та оплатою «для реалізму»: реалізм закінчується там, де починається налагодження конфігів замість підготовки демо. Третя — advanced mechanisms заради краси: якщо agent, hook, plugin, MCP або складна автоматизація не розвʼязують конкретну проблему проєкту, вони засмічують capstone.

Простіше кажучи, якщо ви не можете в одному реченні відповісти на питання «навіщо тут цей механізм?», його, найімовірніше, не має бути.

7. Приміряємо ідею до свого рівня

Після всієї цієї теорії хочеться чогось дуже практичного: способу швидко зрозуміти, ваш це scope чи вже ні. Тут допомагає маленький шаблон самоперевірки — якщо він не заповнюється чесно й спокійно, значить, ідея ще занадто розпливчаста. Спробуйте дивитися на проєкт так:

# Перевірка ідеї capstone

Мій рівень:
Формат:
Який один сценарій я покажу на демо:
Що в проєкт точно не входить:
Які 2–3 перевірки я реально зможу показати:
Де Claude допоможе:
Що я перевірятиму вручну:

Якщо на рядку про сценарій ви починаєте писати пів сторінки — core flow не знайдено. Рядок «Що не входить» порожній — scope не затиснуто. На рядку про перевірки починається нервовий кашель і погляд у стелю — verification-частина не продумана. А «Де Claude допоможе» звучить як «ну… взагалі всюди» — проєкт поки що занадто туманний.

Якщо цей шаблон заповнюється спокійно — у вас уже є результат цієї лекції: вибраний формат, один core flow і список того, що в проєкт точно не входить. Далі саме це й переїде в SPEC.md, а не туманне «хочу зробити щось корисне з AI».

Дуже добрий знак зрілої ідеї — коли ви можете пояснити її спокійно, без спецефектів: «Я Middle, беру Feature in existing codebase. На демо покажу скасування підписки з підтвердженням, smoke-перевірку і відтворюваний README. Не роблю деплой, не чіпаю реальні платежі і не додаю агентів, тому що вони не розвʼязують конкретну проблему проєкту». Не блокбастер. Зате проєкт, який реально можна довести і захистити.

І ось у цей момент capstone перестає бути лячним туманом зі слів «фінальний проєкт» і стає нормальною інженерною задачею з розумними межами. А це одна з найкорисніших навичок у розробці: уміти не тільки будувати, а й не будувати зайвого.