Tutorial 4 Prompting and Reviewing uk

Урок 4 · Промптинг і рев'ю

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

← Назад: Урок 3 Ваше перше завдання для агента · Далі: Урок 5 Локалізація

---

Промптте як провідний, а не як рядок пошуку

Агент — це швидкий, буквальний, завзятий junior-інженер. Ведіть його так, як вели б доброго:

• Заявляйте мету і обмеження. «Додай endorse» — слабко. «Додай endorse за патерном connect, лише генератор із seed, з тестами, бар'єр лишається зеленим» — сильно. Обмеження — це те, як ви отримуєте придатний код.
• Вказуйте на приклади. «Дотримуйся патерну, який використовує renderConnect» б'є абзац опису. Наявний код — найкраща специфікація.
• Просіть план перед правками на всьому нетривіальному. Дешево перенаправити план; дорого розплутувати десять відредагованих файлів.
• Одне завдання на промпт. Зв'язка «додай endorse, ще відрефактори генератор, ще онови README» виробляє заплутаний diff, який важко перевіряти.
• Дайте йому тестовий бар'єр. «Запусти npm test і не вважай зробленим, доки не зелено» перетворює агента на щось, що перевіряє власну роботу.

Перевіряйте diff щоразу

Швидкість — увесь сенс агента, але непрочитана швидкість — це те, як викочують баги. Побудуйте швидкий, стабільний рефлекс рев'ю:

1. Область: чи змінив він лише те, що мав? Непов'язані зсунуті рядки — тривожний сигнал.
2. Патерни: чи збігається з навколишнім кодом, без нових залежностей і без I/O усередині src/?
3. Правила проєкту: для цього репозиторію це лише генератор із seed (grep diff на Math.random), видимий користувачеві текст у мовних бандлах (не захардкожений), і рядки карток ніколи не перевищують ширину, до якої розкладка добиває відступами.
4. Доступність: чи виживає новий вивід під --accessible? Запустіть lockedin --accessible <your command> й перевірте, що це читається як чистий простий текст — жодні нові декоративні гліфи не прослизають повз a11yFilter.
5. Тести: чи є новий тест, і чи впав би він реально, якби функція зламалася? Запитайте: «Який рядок я б змінив, щоб цей новий тест впав?»
6. Запустіть це: npm test, потім запустіть команду й подивіться на вивід.

Не обов'язково розуміти кожен символ — але ви зобов'язані розуміти кожне рішення. Якщо ви не можете пояснити зміну, попросіть агента пояснити її, перш ніж приймати.

Ітеруйте, коли не зелено

Червоний бар'єр — нормальний крок, а не провал. Виправлення — це точний зворотний зв'язок:

«npm test падає з: [paste the exact error]. Тест ширини renderEndorse очікує, що кожен рядок картки ≤ 60 видимих стовпців. Виправ це, не послаблюючи тест.»

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

Зберігайте темп між сесіями

Справжня робота охоплює більше одного заходу. Дві звички тримають агента ефективним із часом:

• Пам'ять / угоди. Якщо ваш агент підтримує довготривалу пам'ять чи файл інструкцій проєкту, запишіть там правила, яких він має завжди дотримуватися (наприклад, «уся випадковість має використовувати pick/shuffle», «запускай npm test перед оголошенням готовності»). Ви заявляєте угоду один раз замість кожного промпту.
• Нотатка про передачу. Цей репозиторій тримає короткий, очищений документ статусу в docs/HANDOFF.md: що за проєкт, як побудований, як тестується і що далі. Коли ви повертаєтеся (чи передаєте колезі — чи іншому агентові), ця нотатка відновлює контекст за секунди. Попросіть свого агента підтримувати її в актуальності як частину зміни.

Огорожі, які варто тримати

• Бар'єр не обговорюється. Зелені тести перш ніж щось викотиться. Саме це дає змогу рухатися швидко і довіряти виводу.
• Ви — відповідальний рев'юер. Агент пише; ви вирішуєте. Прийняти diff — означає поручитися за нього.
• Маленькі, перевірювані кроки б'ють один гігантський стрибок. Кожна прийнята зміна має лишати застосунок робочим.

---

✅ Спробуйте зі своїм агентом

1. Напишіть однодабзацну специфікацію для команди mentor («роздає непрохані поради»), включно з обмеженнями, і змусьте агента побудувати її тести-спершу — план, тести, код, бар'єр — перевіряючи на кожному кроці.
2. Попросіть агента оновити docs/HANDOFF.md, щоб згадати нову команду.
3. Навмисно зламайте щось (наприклад, видаліть запис пулу), запустіть npm test, і потренуйтеся згодовувати агентові точний збій для виправлення.

---

Куди йти далі

• Пробіжіться справжнім кодом у src/lockedin.js — ви тепер знаєте його форму.
• Прочитайте docs/HANDOFF.md для власних нотаток проєкту про статус і архітектуру.
• Насолодіться жартами в Довіднику команд.

Це весь посібник. Ви тепер вмієте скеровувати ШІ-агента будувати й змінювати справжнє ПЗ за тестовим бар'єром — на найсамовпевненішому прикладі, який лише можна уявити. Погоджуєтеся? 👇