Як працюють AI-агенти, як ставити їм задачі і скільки це коштує

1. Про курс

Цей блок — вступ до всього курсу: хто його веде, як побудовані дев'ять занять, як здаються завдання і як рахуються бали й бейджі. Тут же — результати вхідного опитування і план першого заняття. Якщо ви пропустили С1, почніть звідси: правила здачі, перевірки і бейджів однакові для всіх завдань курсу.

#Як працюють AI-агенти, як ставити їм задачі і скільки це коштує

Слайд 2

С1 — перше з дев'яти занять курсу «AI-агенти в роботі QA та BA». Воно відбулося 23 вересня 2026 року і тривало дві години онлайн. На цьому занятті нічого не треба встановлювати і не треба програмувати: мета — зрозуміти, як працює агент і як ставити йому задачі.

За дві години заняття відповідає на три запитання:

• чим агент відрізняється від звичайного чату;
• як поставити задачу так, щоб результат можна було перевірити;
• де побачити ціну цієї задачі.

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

#Вʼячеслав Колдовський

Слайд 3

Курс веде Вʼячеслав Колдовський, Ph.D., понад 20 років в IT. Він засновник Dev AI Consulting — компанії, яка впроваджує AI-агентів у роботу команд (dev-ai.dev).

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

Демонстрації на заняттях зроблені в Claude Code. Вам не потрібен саме цей інструмент: практику ви робите у своєму. Підходи, які розбирає курс, однакові в будь-якому агенті, а завдання С1 можна виконати навіть у звичайному чаті в браузері. Підійде чат, чат із завантаженим файлом або агент — встановлювати нічого не треба.

#9 занять: 6 спільних + 3 вашої групи

Слайд 4

Курс складається з дев'яти занять. Перші шість — спільні: вони проходять щосереди, QA і BA вчаться разом. Після них кожна група йде своїм треком — ще три заняття раз на два тижні.

Перше заняття — фундамент для всіх наступних: агент, задача, перевірка, ціна. С3 — перше заняття, де агент працює з трекером і базою знань через MCP. Яке місце це займає серед способів роботи з AI, показує драбина режимів у розділі «Чат і агент».

#Заняття — воркшоп. Завдання — merge request

Слайд 5

Кожне заняття — воркшоп з однаковим ритмом:

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

Кожне завдання має три рівні:

• L1 — 10 балів, оцінка «виконано / не виконано», природною мовою: L1 завжди можна зробити без програмування.
• L2 — ще +10, глибше і ширше, поверх L1.
• L3 — ще +10, для тих, хто хоче виклику.

Рівень ви обираєте самі і для кожного завдання окремо: цього тижня можна зробити L1, наступного — L2.

Роботу здаєте як merge request на gitlab.com до 23:59 вівторка перед наступним заняттям. У середу зранку роботи перевіряють AI-рев'юер і тренер, а на занятті — розбір. Для першого завдання це вівторок 29.09, 23:59; розбір — у середу 30.09 на С2. Знати git заздалегідь не треба: перше завдання крок за кроком проводить через здачу у браузері.

#Максимум — 440 балів

Слайд 6

Максимум за курс — 440 балів. Вони складаються з двох частин:

Одне завдання дає до 30 балів: L1 — 10, L2 — ще 10, L3 — ще 10. Завдань вісім: шість після спільних занять (С1–С6) і два після занять вашої групи (QA1–QA2 або BA1–BA2). QA3 і BA3 — підсумкові заняття, завдання після них немає. Звідси 8 × 30 = 240.

Фінальний проєкт видають на С6, 28.10, подання — до 14.12. Проєкт прийнято, якщо він набрав щонайменше 120 з 200 балів і виконано обов'язкові умови. Рубрику оцінювання ви отримаєте разом із завданням проєкту.

Разом 240 + 200 = 440.

#Practitioner — без програмування

Слайд 7

На курсі два бейджі:

Головна думка: вищий бейдж, Practitioner, досяжний без жодного рядка коду. Рахунок простий:

• вісім завдань на рівні L1 — 8 × 10 = 80 балів;
• прийнятий фінальний проєкт — щонайменше 120 балів;
• разом 80 + 120 = 200, рівно поріг Practitioner.

Для Foundation досить семи завдань на L1 — це 70 балів.

Якщо хочете мати запас на випадок завалу на роботі, кілька разів зробіть не лише L1, а й L2.

Рейтинг ведеться окремо для QA і BA: таблиці лідерів публікуються в чаті когорти. П'ять найкращих робіт кожного завдання відзначають на розборі.

#Часто, але неглибоко

Слайд 8

Перед курсом учасники заповнили вхідне опитування: відповіли 60 з 71. Ось агреговані результати:

Ці цифри складаються в одну історію — «часто, але неглибоко». AI користуються майже всі і часто, але основний режим сьогодні — чат: «вставив текст → отримав відповідь». Курс — про наступний крок. І саме ці три прогалини закриває перше заняття: що таке агент, як поставити йому задачу і скільки вона коштує.

Найчастіша рутина, яку назвали в опитуванні, — робота з текстом: ТЗ, вимоги, тест-кейси, протоколи. Саме на тексті і працює перше заняття.

Джерело: вхідне опитування когорти, вересень 2026, 60 відповідей з 71. У конспекті, як і на слайді, лише агреговані дані, без імен. Опитування не впливає ні на бали, ні на бейджі.

#2 години: від чату до ціни задачі

Слайд 9

План першого заняття. Хвилини орієнтовні, головне — порядок блоків:

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

Останні пів години — завдання С1. У кожного учасника свій варіант, а тренер наживо виконує завдання на демо-варіанті — від промпту до merge request. Покроково цей шлях розписано на сторінці «Демо: як виконати і здати завдання», а готові промпти — у шпаргалці С1.

Заняття мало дві домовленості:

• питання — у чат одразу, тренер відповідає в паузах між блоками;
• демо — наживо, і помилки агента — частина програми, а не збій.

Слайди, демо і шпаргалки зібрано на сайті курсу. До слайдів можна повертатися під час виконання завдання.

2. Чат і агент

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

#Чат відповідає. Агент виконує задачу.

Слайд 10

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

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

Далі в розділі:

• як виглядає робота в кожному з двох режимів;
• з чого складається агент;
• на якій «сходинці» роботи з AI ви зараз;
• демонстрація: одна задача спершу в чаті, потім в агенті, з підрахунком, скільки це коштувало;
• висновок — коли досить чату, а коли потрібен агент.

#Чат чекає на вас. Агент крутить цикл

Слайд 11

На слайді — дві схеми роботи.

Чат — цикл крутите ви:

1. Вставили текст — ви копіюєте документ.
2. Отримали відповідь — далі знову ви.

Агент — цикл крутить він:

1. Ціль — ви формулюєте.
2. Читає файли — сам знаходить.
3. Діє — пише, створює.
4. Перевіряє — звіряє з ціллю.
5. Повторює — доки не готово.

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

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

На схемі агента підсвічена перша сходинка — «Ціль». Це ваша частина роботи: від того, як сформульовано ціль, залежить, що агент читатиме, що робитиме і з чим звірятиме результат. Як формулювати ціль, розбирає блок «Промпт». Друга ваша частина — перевірити те, що агент повернув; про це блок «Перевірка».

#Агент = модель + харнес

Слайд 12

Проста формула на весь курс: агент — це модель плюс харнес (англ. harness).

Модель пише текст. Це «мозок», який ми орендуємо: Claude, GPT, Gemini. Та сама модель може стояти і за чатом, і за агентом.

Харнес — усе навколо моделі: що агент бачить, що може робити і чого не можна. У нього чотири складові:

Саме харнес, а не модель, відрізняє чат від агента. Чат з тією самою моделлю не має доступу до теки проєкту і не крутить цикл сам — тому він і чекає на вас.

Claude Code, Codex, Gemini CLI — це різні харнеси. Тому навички, набуті в одному, переносяться в інший: ви вчитеся ставити ціль, давати доступ до потрібних файлів і задавати межі, а не натискати кнопки конкретного продукту.

Правила (файл AGENTS.md) — тема заняття С5. Поки що досить знати, що вони існують: через правила агенту заздалегідь задають дозволи і межі, тобто що йому можна робити, а чого не можна.

#П'ять сходинок: від чату до агента з доступом

Слайд 13

Способи роботи з AI можна розкласти на п'ять сходинок:

Сходинка 1 — там, де за вхідним опитуванням основний режим більшості когорти: чат «вставив → отримав». На сходинці 2 файли вже є в розмові, але вирішуєте, які саме, все одно ви. Перелом стається на сходинці 4: агент сам читає теку проєкту, діє і перевіряє результат. Саме її показує демо першого заняття. Сходинка 5 — заняття С3, де агент через MCP працює ще й з трекером і базою знань: задачами, сторінками, посиланнями.

Важливо: це драбина не інструментів, а способів роботи. Ті самі підходи працюють у Claude Code, Codex і Gemini CLI. Тому курс вчить підходів, а не кнопок: ціль, контекст, перевірка і ціна однакові в різних агентах.

#Одна задача: чат проти агента

Слайд 14

Демо 1 порівнює сходинку 1 і сходинку 4 на одній задачі:

Знайди проблеми у правилах платного зберігання

Матеріал — файл materials/demo/storage-spec.md у навчальному репозиторії gitlab.com/koldovsky/ai-qa-ba-c1. Це модельна специфікація вигаданого сервісу доставки: шість правил платного зберігання посилки (З1–З6) і таблиця текстів інтерфейсу.

Крок 1 — чат. Текст специфікації вставляють у вікно чату і ставлять задачу. У відповіді дивляться, скільки в ній знахідок і чи є номери пунктів.

Крок 2 — агент. Той самий запит, але зі шляхом до файлу й обмеженням:

Знайди проблеми у правилах платного зберігання в materials/demo/storage-spec.md. Інші теки не відкривай.

Задум цього кроку: агент сам відкриває файл у репозиторії й посилається на пункти З1–З6, а не на «десь у тексті». Шлях і заборона тут обов'язкові: без них агент може відкрити інші матеріали репозиторію. Це перший практичний урок: агенту прямо кажуть, з чим працювати і куди не ходити.

Відповіді порівнюють за трьома питаннями:

Після спроби звірте обидві відповіді з проблемними місцями, які є в матеріалі:

• зсув 6-го платного дня після продовження (З2 ↔ З3);
• від якої дати рахувати 14 днів до повернення (З4);
• текст «Безкоштовне зберігання закінчується завтра» на 4-й день хибний після продовження і для поштоматів, де безкоштовно лише 3 доби (З6);
• що, якщо на картці немає коштів у момент видачі (З5).

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

#Коли досить чату, а коли потрібен агент

Слайд 15

Висновок з демо залежить від задачі:

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

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

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

Для завдання С1 підходить і чат, і агент: важливі промпт, перевірка і токен-звіт, а не інструмент.

Наступний блок — про контекст. Агент бачить лише те, що прочитав; що саме він бачить і чому «забуває», пояснює розділ «Контекст».

3. Контекст

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

#Контекст — це робоча пам'ять моделі

Слайд 16

Модель не пам'ятає вас і вашу розмову так, як пам'ятає колега. Вона бачить лише те, що зараз лежить у її робочій пам'яті — у контекстному вікні. І це місце обмежене: чого зараз немає у вікні, того для моделі не існує.

Можливо, ви вже стикалися з таким: чат на двадцятому повідомленні раптом «забуває», про що ви домовлялися на початку. Наприклад, ви просили відповідати таблицею і працювати лише з одним документом, а згодом модель повертається до вільного тексту або починає спиратися на щось стороннє. Це не збій і не «лінь» моделі, а прямий наслідок того, як влаштоване контекстне вікно. Саме це розбирають три наступні слайди.

У блоці чотири теми:

• контекстне вікно — що в ньому лежить і чому місця в ньому обмаль;
• чому агент «забуває» — що відбувається, коли вікно переповнюється;
• нова сесія — чому нову задачу краще починати з чистого вікна;
• одна задача — практичне правило, яке підсумовує блок.

Ці теми однаково стосуються і чату в браузері, і агента на кшталт Claude Code.

#Усе, що модель бачить за раз

Слайд 17

Модель не «пам'ятає» розмову між відповідями. Щоразу, коли потрібна нова відповідь, інструмент (чат чи агент) подає їй усе вікно заново: інструкції, файли, всю історію повідомлень. Схема на слайді показує, з чого складається це вікно:

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

Три картки під схемою підсумовують механіку:

• Що всередині. Усе разом: повідомлення, відповіді, файли, інструкції. Нова сесія — порожнє вікно, крім того, що інструмент підкладе сам.
• Коли переповнилось. Інструмент стискає старе в короткий переказ або просто відкидає. Часто — мовчки.
• Що бачите ви. Агент «забуває» домовленість з початку розмови або впевнено заповнює прогалину здогадкою. Він не бреше: він справді цього вже не бачить.

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

У Claude Code вікно можна побачити командою /context, яка показує його розбивку за категоріями. На занятті її порівнюють у двох станах: у сесії, що лишилася після першого демо (слайд 14), і в новій сесії після /clear. На що дивитися: навіть у порожній сесії частину місця вже займають системні інструкції й інструменти, а в сесії першого демо до них додаються прочитаний файл і вся розмова. Це та сама картина, що на схемі.

#Що це означає для вашої роботи

Слайд 18

З того, як працює вікно, випливають чотири робочі звички.

1. Нова задача — нова сесія. Хвіст попередньої розмови не допомагає, а плутає: модель тягне з нього старі припущення. Типова пастка — один чат на тиждень, у якому і вимоги до однієї функції, і тест-кейси до іншої. Модель починає змішувати правила різних функцій. Нова задача — нова сесія: це дешевше за будь-яке «забудь, що я казав раніше».
2. Потрібний документ, а не «все підряд». Не «ось уся тека з вимогами», а одна специфікація, з якою ви працюєте зараз. Зайве не лише займає місце і відволікає, а й дає моделі матеріал для хибних зв'язків.
3. Довгий діалог дорожчає і гіршає. Кожна нова відповідь знову «читає» всю історію: більше токенів і більше шуму. Тому кожне наступне повідомлення дорожче за попереднє. Детально про гроші — у блоці про токени (слайд 31); тут досить запам'ятати, що довгий чат і дорожчий, і гірший.
4. Важливе — на початку і наприкінці. У довгому тексті модель гірше помічає середину. Тому задачу ставте на початку, а ключові вимоги повторіть ще раз наприкінці промпту. Наприклад, якщо ви вставляєте в промпт довгу специфікацію, то «склади чек-лист перевірок» варто написати перед нею, а головний критерій, скажімо «кожна перевірка — з посиланням на пункт», повторити вже після тексту специфікації.

Тим, хто працюватиме в Claude Code, допоможуть дві команди:

/clear    — почати з чистого вікна
/context  — подивитися, що в ньому

У чаті аналог /clear — «Новий чат».

#Одна задача. Одна сесія. Один результат.

Слайд 19

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

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

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

Як це виглядає на демо-матеріалі заняття: одна задача — знайти неоднозначності в специфікації платного зберігання посилки storage-spec.md; одна сесія — нова, у якій є лише цей файл; один результат — таблиця, де кожна знахідка посилається на пункт З1–З6. Саме так побудовано демо в наступному блоці (слайд 22).

Третій крок, «результат, який можна перевірити», — тема блоку про перевірку (слайд 26). Відповідь, де кожне твердження має посилання на пункт джерела, можна звірити пункт за пунктом. Відповідь без посилань доводиться перевіряти навмання.

4. Як поставити задачу

Цей блок — про промпт як постановку задачі: з яких п'яти частин вона складається, чим структурований промпт відрізняється від запиту «як вийде» у задачах BA і QA і які два прийоми економлять ітерації. Для QA та BA тут багато знайомого: хороший промпт влаштований так само, як хороша постановка задачі в команді, з критеріями приймання включно. Наприкінці — шаблон, який можна скопіювати і використати в практичному завданні С1.

#Промпт — це постановка задачі новому колезі

Слайд 20

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

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

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

Хороша постановка складається з п'яти частин:

• роль;
• вхідні дані;
• задача;
• критерії приймання;
• формат відповіді.

Кожну з них розібрано на наступному слайді.

#П'ять частин постановки задачі

Слайд 21

Приклади взято з демо-специфікації «Платне зберігання посилки» (materials/demo/storage-spec.md у репозиторії практики: правила З1–З6 і тексти інтерфейсу). На ній побудовано й демо на наступних слайдах.

Що дає кожна частина:

• Роль задає точку зору і рівень деталізації: аналітик шукає неоднозначності, тестувальник — перевірки.
• Вхідні дані кажуть, що саме модель має прочитати, і що працювати треба лише з цим, а не «з загальних знань».
• Задача — одна дія, один результат. «Проаналізуй» — не задача; «знайди суперечності між пунктами» — задача.
• Критерії приймання — найзнайоміша для вас частина: це ті самі acceptance criteria, тільки для відповіді AI. Найкорисніший критерій — «кожне твердження з посиланням на пункт»: він робить відповідь перевірюваною.
• Формат потрібен, щоб результат можна було одразу перевірити і вставити у звіт чи трекер.

Порядок частин не догма; важливо, щоб були всі п'ять. Саме ці п'ять частин треба позначити у промпті у звіті С1.

#BA: «як вийде» проти структурованого

Слайд 22

Тут порівнюються два запити до тієї самої демо-специфікації. Перший — так, як ми зазвичай пишемо:

Зроби аналіз цього документа.
[вставлено storage-spec.md]

Другий — ті самі п'ять частин із попереднього слайда:

Роль: ти — бізнес-аналітик; готуєш вимоги для розробки і тестування.
Вхідні дані: специфікація «Платне зберігання посилки» нижче — пункти З1–З6 і тексти інтерфейсу. Працюй лише з нею.
Задача: знайди неоднозначності, суперечності й прогалини в правилах.
Критерії приймання:
- кожна знахідка посилається на пункт З1–З6 або текст інтерфейсу;
- нічого не додавай від себе;
- окремо — чого в документі бракує для розробки.
Формат: таблиця «пункт · що не так · питання до автора», до 10 рядків.

Картка «Типово у відповіді» на слайді — узагальнена ілюстрація, а не запис конкретної сесії. На перший запит типово приходить переказ правил своїми словами і загальні поради на кшталт «варто додати сповіщення», без жодного посилання на пункт: перевіряти нема за що вхопитися. Структурований запит просить таблицю, де кожен рядок прив'язаний до пункту, тож її можна звірити з документом. Та сама модель, той самий документ — різниця лише в постановці.

У демо цей промпт запускають у Claude Code в новій сесії (/clear), як радить блок про контекст. Для агента «нижче» замінюють шляхом до файлу і забороною: «materials/demo/storage-spec.md. Інші теки не відкривай.» Так агент працює лише з потрібним документом. Короткий запит без структури до цієї самої специфікації — у першому демо заняття (слайд 14).

На що дивитися у відповіді на структурований промпт: серед знахідок, найімовірніше, будуть з якого дня нараховується плата після продовження (З2 ↔ З3), від чого рахувати 14 днів (З4) і що буде, якщо на картці бракує коштів (З5). Чого модель не знайшла, те стане матеріалом для блоку про перевірку.

#QA: «як вийде» проти структурованого

Слайд 23

Та сама структура, але інша роль і інша задача. Запит «як вийде»:

Напиши тест-кейси.
[вставлено storage-spec.md]

Структурований запит:

Роль: ти — QA-інженер; готуєш перевірки нової функції перед релізом.
Вхідні дані: специфікація «Платне зберігання посилки» нижче — пункти З1–З6 і тексти інтерфейсу. Працюй лише з нею.
Задача: склади чек-лист перевірок.
Критерії приймання:
- три групи: позитивні · негативні · межові (перший і останній день кожного строку);
- кожна перевірка посилається на пункт З1–З6;
- якщо правило неоднозначне — не вгадуй, винеси в «Питання».
Формат: таблиця «№ · група · перевірка · очікуваний результат · пункт»; під нею — «Питання».

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

Зверніть увагу на третій критерій. Він прямо дозволяє моделі сказати «тут незрозуміло» замість вигадувати очікуваний результат. Для QA це найцінніший рядок промпту.

У демо цей промпт запускають у Claude Code так само, як для BA: нова сесія (/clear), замість «нижче» — шлях materials/demo/storage-spec.md і фраза «Інші теки не відкривай». Після відповіді можна подивитися витрату сесії (/cost) або заповнення вікна (/context); детально про це — у блоці про токени (слайд 35).

На що дивитися у відповіді:

• три групи перевірок: позитивні, негативні, межові;
• серед межових — дні 5 і 6, день 14, 3 доби в поштоматі;
• посилання на пункти в кожній перевірці;
• у «Питаннях» — щонайменше З2 ↔ З3 (з якого дня плата після продовження) або відлік 14 днів у З4.

Відповідь на структурований QA-промпт далі розбирають чотирма вердиктами в блоці про перевірку (слайд 28).

#Два прийоми, що економлять ітерації

Слайд 24

1. Спершу — питання. Додайте в кінець промпту:

Перш ніж відповідати, постав мені до 5 уточнювальних питань. Відповідай після моїх відповідей.

Модель покаже, де їй бракує даних, замість того щоб заповнити прогалину сама. Прийом особливо корисний для BA: модель ставить ті самі питання, які поставив би розробник чи тестувальник, і ви бачите прогалини у своїй постановці ще до того, як отримаєте відповідь. Якщо питання очевидні — відповідайте коротко. Якщо ні — це сигнал, що задача ще не сформульована.

2. Уточнюйте конкретно. Коли відповідь не влаштовує, назвіть, що саме не так і яким має бути результат.

Так не варто:

Перепиши. · Не те. · Зроби краще.

Так краще:

Рядки 3 і 7 без посилання на пункт — додай посилання.
Прибери перевірку про SMS: у специфікації її немає.

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

#Шаблон — скопіюйте собі

Слайд 25

Роль: ти — [QA-інженер / бізнес-аналітик], [для кого результат].
Вхідні дані: [документ нижче / файл]. Працюй лише з ними.
Задача: [одна дія і один результат].
Критерії приймання:
- кожне твердження посилається на пункт джерела;
- чого немає в джерелі — не додавай, винеси в «Питання»;
- [ваш критерій: покриття, обсяг, мова].
Формат відповіді: [таблиця з колонками … / список, до N рядків].
Перш ніж відповідати, постав до 5 уточнювальних питань.

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

• квадратні дужки — замінити, решту лишити;
• останній рядок — за бажанням;
• нова задача — нова сесія з цим шаблоном;
• той самий каркас — у звіті С1, розділ 2.

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

У практиці С1 (рівень L1) у звіті треба навести промпт і позначити в ньому ці п'ять частин. Шаблон звіту — файл templates/c1-report.md у репозиторії практики gitlab.com/koldovsky/ai-qa-ba-c1. Готові промпти для QA і BA є також у шпаргалці С1. Детально про здачу — у блоці про практику (слайд 37).

5. Перевірка результату

Цей блок про те, як відрізнити правильну відповідь AI від переконливої. Для QA та BA це не нова навичка, а ваша щоденна робота: звіряти твердження з джерелом, шукати пропущене і ставити питання авторові вимог. AI лише додає ще одного «автора», чий текст теж треба перевіряти, і дає кілька прийомів, які роблять цю перевірку швидшою.

#Модель ніколи не звучить невпевнено

Слайд 26

Головна думка блоку: впевнений тон — це стиль відповіді, а не ознака правильності. Модель однаково впевнено формулює і правду, і вигадку. У неї немає інтонації сумніву, на яку ми звикли зважати в розмові з людьми: колега, який не впевнений, зазвичай каже «здається» чи «треба уточнити». Модель такого сигналу не дає. Тому відчуття «звучить переконливо» нічого не означає. Правильність доводите ви, і лише одним способом — звіркою з джерелом.

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

У блоці чотири теми, і вони йдуть саме в такому порядку:

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

Усі приклади далі — на демо-матеріалі storage-spec.md (правила платного зберігання посилки З1–З6 і тексти інтерфейсу), тому ви зможете повторити перевірку самі, відкривши файл materials/demo/storage-spec.md у навчальному репозиторії gitlab.com/koldovsky/ai-qa-ba-c1.

#Вигадує впевнено — пропускає тихо

Слайд 27

Ліворуч на слайді — фрагмент демо-специфікації:

З1. 5 календарних днів безкоштовно з дня прибуття.
З2. З 6-го дня — 10 грн за кожну добу.
З3. Одне безкоштовне продовження на 3 дні в застосунку.
З6. Поштомати: 3 доби, продовження недоступне.
Картка посилки, 4-й день:
«Безкоштовне зберігання закінчується завтра»

Праворуч — відповідь AI. Це ілюстрація, складена з типових помилок, а не запис конкретної сесії:

Правила зберігання посилки:
1. Перші 5 днів — безкоштовно.
2. За добу до завершення отримувач отримує SMS-сповіщення.
   ↑ вигадано: у специфікації лише текст у картці
3. Продовження на 3 дні доступне для будь-якої посилки.
   ↑ пропущено З6: у поштоматах продовження немає

Тут видно два різні види помилок.

• Вигадане. Модель додає правдоподібне. SMS-сповіщення звучать як «звичайна практика», тому око їх пропускає. Але у специфікації є лише текст у картці посилки — жодних сповіщень.
• Пропущене. Модель не врахувала пункт, який є, — З6 про поштомати. Це небезпечніше: пропуск не видно, поки ви читаєте відповідь. Його видно, лише коли читаєте джерело.

Звідси техніка перевірки. Питання не «чи переконлива відповідь», а два інші: чи кожне твердження має опору в джерелі і чи кожен пункт джерела врахований у відповіді. Перше ловить вигадане, друге — пропущене.

Цю техніку зручно відпрацювати на відповіді з QA-демо попереднього блоку (слайд 23): відповідь читають поруч зі специфікацією і шукають твердження без посилання на пункт або пункт, якого у відповіді немає. Часте місце плутанини в цьому матеріалі — текст «закінчується завтра»: він хибний після продовження і для поштоматів. Якщо ж помилок не знайшлося, це теж результат перевірки — але його треба встановити пункт за пунктом, а не на око.

#Чотири вердикти для кожного твердження

Слайд 28

Кожне твердження відповіді отримує один із чотирьох вердиктів:

Що означає кожен вердикт:

• Вірно — у джерелі є пункт, і він каже те саме. Вердикт «вірно» теж доводиться пунктом, а не відчуттям.
• Вигадано — у джерелі цього немає.
• Пропущено — у джерелі є, а у відповіді немає або відповідь цьому суперечить.
• Проблема в матеріалі — AI може дослівно повторити З2, але З2 і З3 разом не дають відповіді, з якого дня платити після продовження. Помилки AI тут немає: неоднозначність сидить у самій специфікації.

Для QA і BA останній вердикт найцінніший. Саме такі знахідки ви приносите на рев'ю вимог. У демо-специфікації подібних місць кілька: крім пари З2 ↔ З3, це відлік 14 днів у З4 і текст «закінчується завтра», хибний після продовження і для поштоматів.

Це ті самі вердикти, що в розділі 4 звіту С1: там потрібна перевірка щонайменше трьох пунктів. На занятті вердикти показують наживо: беруть 3–4 твердження з відповіді QA-демо, для кожного відкривають storage-spec.md, знаходять пункт і називають вердикт уголос. Так само працюйте і над своїм звітом: твердження, пункт джерела, вердикт.

#Як перевіряти швидше

Слайд 29

Перевірка пункт за пунктом забирає час. Чотири прийоми допомагають його скоротити.

1. Посилання на пункт. Твердження без пункту — перше під підозрою. Це найдешевший прийом: одна фраза в критеріях приймання, і кожне твердження стає перевірюваним за секунди. Цей рядок уже є в шаблоні промпту з попереднього блоку (слайд 25).

Після кожного твердження вкажи пункт: З1–З6.

2. Окремо — чого немає в джерелі. Хай модель сама позначить, що додала від себе. Вона не завжди чесно заповнить такий список, але часто сама підсвітить вигадане. Це підказка, а не гарантія.

Окремим списком: що ти додав від себе і чого в документі немає.

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

Ось специфікація і відповідь. Знайди твердження без опори в специфікації.

4. Фінальний рецензент — ви. Усі три прийоми лише звужують пошук. Вердикт ставить людина, яка відкрила джерело: відкрили пункт, звірили, записали один із чотирьох вердиктів — вірно, вигадано, пропущено, проблема в матеріалі.

На практиці прийоми 1 і 2 — це рядки в критеріях приймання того самого промпту: їх додають одразу, коли ставите задачу. Прийом 3 — окремий крок після відповіді: нова сесія, у якій є лише джерело і відповідь. А крок 4 не пропускається ніколи.

#Перевірка — валюта довіри

Слайд 30

Навіщо все це? Бо довіра в команді працює як рахунок.

Колеги довіряють не AI, а вам. Команда приймає ваш результат не тому, що його зробив AI, а тому, що ви за ним стоїте. Кожен перевірений результат — внесок на рахунок. Кожна вигадка, що пройшла далі за вас, — зняття з рахунку, і дороге.

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

У практиці С1 саме це і є рівень L1. У звіті потрібна перевірка щонайменше з трьох пунктів із вердиктами «вірно / вигадано / пропущено / проблема в матеріалі». Це ваш перший внесок на рахунок. Детально про завдання — на слайді 37 і в репозиторії gitlab.com/koldovsky/ai-qa-ba-c1; повний приклад перевірки на демо-варіанті — на сторінці демо.

І відповідь, і її перевірка мають ціну. Про неї — наступний блок, про токени.

6. Токени і вартість

Кожна відповідь AI має ціну, навіть коли ви не бачите рахунку. Цей блок пояснює, з чого складається ця ціна, чому в агента вона росте швидше, ніж у чаті, які звички її роздувають і де подивитися реальні цифри. Для QA та BA це практичне питання: від вартості залежать ліміти, час і якість роботи з довгими документами, а токен-звіт є частиною завдань курсу.

#Кожна відповідь має ціну

Слайд 31

Ціна є навіть тоді, коли ви її не бачите. Якщо ви працюєте з чатом за підпискою, окремого рахунку за кожну відповідь немає. Але витрата нікуди не зникає, вона просто схована в інших місцях:

• у лімітах, які раптом закінчуються;
• у часі — зокрема в довгих відповідях;
• у місці в контексті: розмова, яка розрослася, забиває робочу пам'ять моделі (про це був блок про контекст, слайд 16).

На слайді — результат вхідного опитування групи: 57% тих, хто відповів, не знають, де подивитися витрату токенів (вхідне опитування, 60 відповідей із 71). Тобто більше половини тих, хто відповів, поки не бачать, скільки коштує їхня робота з AI. Наступні п'ять слайдів це виправляють: що таке токен, чому в агента рахунок росте швидше, які чотири звички найчастіше спалюють токени, де побачити витрату в різних інструментах і як це виглядає на реальній задачі.

Уміння бачити вартість — одна з трьох навичок, яких навчає завдання С1 і на яких стоїть увесь курс, поряд із постановкою задачі та перевіркою результату. У звіті до завдання є окремий розділ — токен-звіт, тож знання з цього блоку знадобляться вже цього тижня.

#Токен — одиниця рахунку

Слайд 32

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

Токени бувають двох видів:

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

Окремо про мову. Кирилиця зазвичай займає більше токенів, ніж англійський текст того самого змісту. Наскільки більше — залежить від моделі, тому жодного універсального коефіцієнта тут немає. Перевірте на своєму тексті: як це зробити, показано далі, на слайді «Де побачити витрату» (слайд 35).

#Агент перечитує все на кожному кроці

Слайд 33

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

крок 1:  [задача + файл]
крок 2:  [задача + файл] [крок 1]
крок 3:  [задача + файл] [крок 1] [крок 2]
крок 4:  [задача + файл] [крок 1] [крок 2] [крок 3]

Звідси два наслідки.

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

Чесне уточнення: інструменти кешують повторений контекст, тому перечитування дешевше за новий текст, але не безкоштовне. А вікно контексту все одно заповнюється.

Точних цифр на схемі навмисно немає: реальні цифри знімали наживо в демо 2 (далі в цьому блоці), а цифри записаних прогонів на демо-варіанті домашки — у розділі 5 «Токен-звіт» на сторінці демо.

#Чотири звички, які спалюють токени

Слайд 34

Як це виглядає в роботі QA та BA:

• 01. «Вставлю всю специфікацію на сто сторінок, щоб написати тест-кейси до одного розділу». Дайте розділ.
• 02. Один чат з понеділка на всі задачі тижня. Кожне нове питання тягне за собою весь тиждень.
• 03. «Перепиши» замість «виправ пункти 3 і 5». Ви платите за весь текст знову і ризикуєте зіпсувати те, що вже було добре.
• 04. Переформулювати один абзац листа — це задача для чату. Розібрати теку з десятьма документами — для агента.

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

#Де побачити витрату

Слайд 35

Токенайзер, який використовуємо в курсі: platform.openai.com/tokenizer. Він рахує токени для моделей OpenAI, тож для інших інструментів це оцінка — так і пишіть у звіті. Різні моделі рахують трохи по-різному, але для порівняння і навчання оцінки досить.

Що саме показує /cost, залежить від вашого тарифу. Якщо суми там немає, /context усе одно покаже, скільки токенів зараз у контексті.

Токен-звіт — частина завдань С1, С3 і С5. У ньому три речі: вхід, вихід і звідки взято цифри (наприклад, «Claude Code, /cost» або «оцінка, токенайзер»). Тож звичка, яку ви набуваєте сьогодні, знадобиться ще двічі. Приклад заповненого токен-звіту є на сторінці демо, а команди зібрано в шпаргалці С1.

#Демо 2: скільки коштує одна задача

Слайд 36

Мета демо — побачити реальні цифри в агенті й зрозуміти, звідки береться вхід. Агент Claude Code у новій сесії отримує структурований промпт до демо-специфікації:

Роль: ти — аналітик, який рецензує специфікацію.
Вхідні дані: лише файл storage-spec.md.
Задача: знайди суперечності, неоднозначності й пропуски в правилах З1–З6 і текстах інтерфейсу.
Критерії приймання: кожна проблема — з номером правила; нічого поза файлом; не впевнений — так і напиши.
Формат: таблиця «правило · проблема · питання до автора».

Що вимірюють:

«Наживо» — цифри знімають під час заняття. Колонка чату заповнюється під час демо домашнього завдання (слайд 40): там токени оцінюють токенайзером.

Як іде демо і на що дивитися:

• До промпту — /context на початку сесії. Вікно вже частково заповнене системними інструкціями й інструментами, хоча ви ще нічого не написали.
• Під час роботи — що саме агент читає. Після відповіді — /cost: вхід, вихід і час.
• Звірка з джерелом. Чи помітив агент, що після продовження неясно, чи зсувається 6-й день (З2 ↔ З3); від чого рахувати 14 днів (З4); що текст «закінчується завтра» хибний після продовження і для поштоматів (З3, З6); що буде, якщо на картці немає коштів (З5).
• Висновок. Вхід агента в рази більший за ваш промпт — це ціна інструментів. Для простої текстової задачі чату досить; агент потрібен, коли треба працювати з файлами й системами.

Той самий промпт у другому агенті з його командою статистики (у Gemini CLI — /stats) — це рівень L3 вашого завдання. Реальні цифри записаних прогонів на демо-варіанті домашки — у розділі 5 «Токен-звіт» на сторінці демо.

7. Завдання С1

Цей блок — про практичне завдання першого заняття. Воно навмисно просте: одна робоча річ, зроблена з AI, на якій ви тренуєте три навички дня — поставити задачу, перевірити результат і побачити, скільки він коштував. Нижче — що саме зробити, як знайти свій варіант, з чого складається звіт, як здати роботу через браузер і як її перевірятимуть.

#Завдання С1: одна робоча задача з AI

Слайд 37

У кожного учасника — свій варіант: окрема функція вигаданого сервісу доставки «Пакунок». Кроки для всіх однакові, а пастки в матеріалах різні.

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

Умови, які варто запам'ятати:

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

#Ваш варіант — за першою літерою прізвища

Слайд 38

Номер варіанту визначає перша літера вашого прізвища українською — так, як прізвище записане в списку учасників курсу. Знайдіть себе в таблиці й запам'ятайте номер.

Файли варіантів — у README репозиторію gitlab.com/koldovsky/ai-qa-ba-c1, таблиця «Ваш варіант». QA беруть qa-spec.md — специфікацію функції, BA — ba-request.md, лист-запит від замовника. Щоб вставити документ у чат, відкрийте файл на gitlab.com і натисніть кнопку Copy file contents над текстом.

Якщо прізвище в списку курсу записане інакше, ніж ви звикли, беріть літеру зі списку курсу. Сумніваєтеся — напишіть у чат когорти.

#L1 обов'язковий, L2 і L3 — зверху

Слайд 39

Завдання має три рівні. Обов'язковий лише перший, другий і третій — за бажанням, вони додають бали.

L1 зараховується як «виконано / не виконано»: виконали умови — отримуєте всі 10 балів, без оцінки «наскільки гарно». На L2 ту саму задачу виконують двічі — з коротким промптом «як вийде» і зі структурованим — і порівнюють якість відповідей і токени. На L3 той самий структурований промпт запускають у двох різних інструментах або режимах, наприклад у чаті й в агенті. Кожен прогін робіть у новій розмові, щоб попередня відповідь не впливала на наступну.

Звіт L1 — файл submissions/<username>/c1.md за шаблоном templates/c1-report.md, з вашими прізвищем, ім'ям і номером свого варіанту. У звіті п'ять частин:

1. Інструмент і промпт — промпт повністю, без змін.
2. Відповідь AI.
3. Перевірка — щонайменше три пункти, і кожен закінчується одним із чотирьох висновків: вірно, вигадано, пропущено або проблема в матеріалі (що означає кожен, пояснено на слайді 28).
4. Токен-звіт — вхід, вихід і як виміряно: цифри з інструмента або оцінка токенайзером, і звідки їх узято.
5. Висновок своїми словами.

#Живе демо: завдання від промпту до merge request

Слайд 40

На занятті тренер один раз проходить увесь шлях завдання на демо-варіанті «Зміна адреси доставки» (роль QA, файл materials/demo/change-address/qa-spec.md) — від відкриття матеріалу до створеного merge request. Мета — щоб ви побачили всі кроки разом і потім повторили їх на своєму варіанті. Тому результат у демо не «ідеальний», а звичайний — такий, який вийде і у вас.

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

На кроці перевірки варто шукати три речі: суперечність у самій специфікації (у демо-матеріалі це «не більше двох змін» проти «ще 2 рази»; якщо AI її помітив, висновок — «проблема в матеріалі, AI знайшов»), вигадку AI і хоча б одне «вірно» з посиланням на пункт. У записаному прогоні на сторінці демо вигадка — перевірка, за якою дата «не оновлюється одразу»: такого правила в специфікації немає. Рядки перевірки корисно одразу записувати в нотатку, щоб потім лише вставити їх у звіт.

У звіті демо заповнюються прізвище та ім'я (за ними зараховуються бали, і звіт публічний), варіант «демо», роль і рядки перевірки; решта частин заповнюється так само, як у прикладі звіту на сторінці демо. Merge request у демо має назву «С1 · koldovsky · демо».

Той самий шлях покроково, з записаними відповідями AI, — на сторінці Демо: як виконати і здати (QA, BA, L2, токени, кроки здачі). Шаблони промптів QA і BA та що вписати на кожному кроці GitLab — у Шпаргалці С1.

#Здача — лише браузер, шість кроків

Слайд 41

Роботу здають як merge request на gitlab.com, і для цього досить браузера. Git не потрібен.

Крок 0 робиться один раз, до першого коміту: він приховує вашу пошту в комітах. Без нього адресу видно в публічній історії репозиторію.

Найчастіше помиляються у двох місцях. Перше — назва файлу: у ній має бути ваш username на gitlab.com, а косі риски в назві самі створять теки. Друге — ціль merge request: праворуч від стрілки має бути koldovsky/ai-qa-ba-c1 і гілка main, а не ваша копія. У назві merge request вкажіть номер свого варіанту. Форк не перейменовуйте.

Виправити щось до строку можна в тому самому merge request: відредагуйте файл у своїй копії, у гілці c1, і зробіть коміт у ту саму гілку — merge request оновиться сам. Хто вміє працювати з git, може здати через clone і push.

Покроково, з назвами кнопок, — у Шпаргалці С1 і в README репозиторію.

#Хто перевіряє — і як виглядає відгук

Слайд 42

Що відбувається після того, як ви натиснули Create merge request, — три речі, які варто знати.

1. Що і хто. AI-рев'юер звіряє кожен звіт з умовами L1–L3. Частину робіт додатково переглядає тренер.
2. Що ви отримаєте. Коментар у вашому merge request з конкретними порадами: що вже добре і що покращити. Балів у коментарі немає.
3. Якщо не згодні. Напишіть коментар у своєму merge request — тренер розгляне його особисто.

Відгук з'являється після строку — у середу, 30.09, зранку, перед розбором на С2. До строку ви виправляєте роботу самі, за шпаргалкою і демо, у тому самому merge request. Бали йдуть у рейтинг курсу, а не в коментар. П'ять найкращих робіт кожного завдання відзначать на розборі.

#Перш ніж почати: публічно і вчасно

Слайд 43

Репозиторій завдання публічний, і це не формальність. Звідси три правила:

• лише матеріали курсу — без корпоративних даних, паролів, імен колег і внутрішніх посилань; жодних робочих документів «для кращого прикладу»;
• у звіті — ваші прізвище та ім'я, як у списку курсу: за ними зараховуються бали, і їх видно публічно; при цьому профіль gitlab.com, зокрема username, може бути нейтральним, а пошту в комітах треба приховати (крок 0);
• ваш merge request і коментарі до нього бачить будь-хто в інтернеті — пишіть їх з огляду на це.

На завдання — шість днів. Строк не переноситься: у середу зранку перевірка, і вже на С2 — розбір, поки тема свіжа. Так буде і далі: кожне домашнє завдання здається до 23:59 у вівторок перед наступним заняттям і розбирається на цьому занятті.

Питання щодо завдання ставте в Telegram-чат когорти, гілки QA і BA.

8. Підсумок

Останній блок заняття: що зробити ще до наступної зустрічі, п'ять головних думок С1, де шукати матеріали і короткі відповіді на типові питання. Першу дію з нього — акаунт на gitlab.com — варто виконати ще в день заняття: без акаунта першу роботу не здати.

#До С2: акаунт gitlab.com — уже сьогодні

Слайд 44

На сьогодні лише одна дія: створіть акаунт на gitlab.com. Це окремий сервіс, не корпоративний GitLab. Одразу після реєстрації зайдіть у профіль і оберіть Commit email → Use a private email: репозиторій завдання публічний, і без цього адресу вашої пошти видно в історії комітів. Ім'я в профілі можна вказати нейтральне.

Буває, що gitlab.com не відкривається з робочого комп'ютера. Якщо так, напишіть у чат когорти. Краще дізнатися про це сьогодні, ніж увечері 29 вересня, перед самим строком.

Вступний пакет з агентом надійде окремо, до С3. Для завдання С1 нічого встановлювати не треба, тож зараз нічого й не встановлюйте.

Тема С2 — від вимог до acceptance criteria, UAT і тест-кейсів, і сьогоднішній структурований промпт знадобиться там одразу.

#П'ять речей, які забираєте

Слайд 45

Кожен пункт — один блок заняття: що таке агент, контекст, промпт, перевірка, вартість. Якщо якась думка здається неочевидною, поверніться до слайдів її блоку.

Команди в п'ятому пункті — це способи побачити витрату в агентах: /cost і /context у Claude Code, /stats у Gemini CLI. Якщо ваш інструмент цифр не показує, оцініть токени токенайзером.

Кожну з цих думок ви застосуєте в завданні С1, а три останні видно прямо у звіті: промпт із п'яти частин, перевірка з чотирма висновками і токен-звіт.

#Ресурси

Слайд 46

Усе, що потрібно після заняття, зібрано за трьома посиланнями.

Слайди цього заняття — на сайті курсу. Звідти ж ведуть дві сторінки, які знадобляться для завдання:

• Демо: як виконати і здати — увесь шлях на демо-варіанті з записаними відповідями AI: промпт, перевірка, токен-звіт, L2 і здача;
• Шпаргалка С1 — шаблони промптів QA і BA, таблиця перевірки і що вписати на кожному кроці GitLab.

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

Головне місце для питань між заняттями — Telegram-чат когорти, гілки QA і BA.

#Питання

Слайд 47

Заняття завершується однією думкою, яка об'єднує всі п'ять блоків.

Після цього — час для питань. Ось типові питання і короткі відповіді на них.

Чи можна робити завдання в робочому AI-інструменті? Так, підходить будь-який AI-інструмент, але лише з матеріалами курсу. Робочих документів і даних у запитах до AI та у звіті бути не повинно.

Мій чат не показує токени. Що писати в токен-звіті? Скористайтеся токенайзером: окремо вставте промпт і відповідь і позначте цифри як «оцінка». Для завдання цього досить.

gitlab.com не відкривається. Напишіть у чат когорти — бажано в день заняття, а не перед строком.

Ще два питання, відповіді на які є на сторінці демо і в шпаргалці:

Хочу зробити і QA, і BA. Можна, це корисна практика. Але здається одна роль — та, яку ви вказуєте у звіті. Оберіть ту, що ближча до вашої роботи.

Коміт уже зроблено, а пошту не приховано. Напишіть у чат когорти.

Питання, на які не вистачило часу на занятті, ставте в чат когорти — відповідь буде там.