Subagents
Описує current Codex subagent workflows, trigger rules, agent threads, token cost і безпечніші read-heavy patterns.
Як налаштувати мультиагентне середовище → Першоджерело ↗Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Java з переходом на потрібну секунду.
Терміни, нюанси та джерела
Перевірити, чи потрібен Cucumber
Візьміть один existing E2E scenario і назвіть його реальних readers.
Перепишіть його technology-neutral Given/When/Then із observable outcome.
Якщо reader і discovery loop відсутні, порівняйте maintenance cost із direct automated test.
Один scenario, список readers і аргументоване рішення залишити або прибрати Cucumber layer.
Вибір cloud і local models
Порівняння провайдерів у відео субʼєктивне й привʼязане до тодішніх тарифів. Практичний критерій — якість на реальних coding tasks, доступний context window, latency та загальна вартість. Локальна модель на laptop споживає багато GPU/RAM, має менший корисний context і повільнішу відповідь; для персональної нерегулярної роботи cloud provider часто дешевший за час і hardware cost.
Devices, screen sizes і long-term delivery cost
Покриття має враховувати різні screen sizes, OS versions і representative devices, але не перетворюватися на cartesian product кожного scenario з кожним device. Cross-platform допомагає швидко отримати market feedback, але native plugins і diverging teams збільшують maintenance cost. Тест strategy має врахувати цей ceiling заздалегідь.
Базова формула економії часу
Автоматизація окуповується через повторні запуски. Для кожного сценарію потрібно оцінити час ручного виконання та час автоматизованого прогону. Розробка автотесту — окрема інвестиція, але кожен наступний запуск уже створює вимірювану економію. Базова формула для одного запуску: ```text економія = час ручного прогону − час автоматизованого прогону ``` Для періоду: ```text сукупна економія = економія одного запуску × кількість запусків ``` Якщо історичні test runs неякісні — наприклад, частину кейсів відмічали пройденими після поверхневої перевірки, — не варто видавати їх за точні дані. Можна почати з експертної оцінки середнього часу, явно позначивши її як наближену, а надалі збирати чистішу статистику.
Антипатерн: Cucumber живе тільки в automation
Типовий невдалий варіант: manual test cases уже містять steps, але автоматизатор повторно перекладає їх у Gherkin, а потім створює step definitions. Одна дія існує як feature text, regex/parameterized step і code implementation. Різні автори формулюють однакові steps по-різному, тому повторне використання швидко руйнується. Management може вимагати кількість automated scenarios або «читабельний для business report», але потім не відкривати ці reports. У такій ситуації Cucumber не забезпечує BDD: він лише додає maintenance cost команді automation. Ознака справжнього BDD — scenarios використовуються для спільних рішень, а не лежать наприкінці pipeline.
Де solo/fullstack підхід починає ламатися
[Дивитися з 12:00](https://www.youtube.com/watch?v=jAl2Qf8Zlyg&t=720s). Зі зростанням system з’являються multiple services, authorization for external clients, складні database relations і third-party calls. Generated implementation може непомітно створити N+1 queries, дублювати requests або багато разів викликати зовнішній provider заради одного UI response. Локально feature працює, але її operational cost і latency стають неприйнятними на реальному traffic.
Delivery пришвидшується, а testing cost зростає
[Дивитися з 24:00](https://www.youtube.com/watch?v=jAl2Qf8Zlyg&t=1440s). AI скорочує час написання feature, але developer витрачає дедалі більше часу на ручне підтвердження, regression і перевірку side effects. Навіть автор із досвідом architecture та automation пропускає defects після багатьох iterations. Тому композиція «один developer + один tester» може бути економічно й операційно сильнішою, ніж developer, який сам генерує, review-ить і повністю тестує весь продукт.
Models-only generation і API product thinking
Після проблем з full client відео показує простіший варіант: generate models, а transport залишити під контролем test code. Це зберігає schema checking без складного generated client runtime. Актуальна specification також робить API придатним для external consumers. Це не лише testing concern, а product capability: onboarding, SDK generation і integration cost.
Full client чи models-only: ціна володіння
Фінальний вибір залежить від company culture і delivery pipeline. Full generated client зменшує manual code, але вимагає generator upgrades, artifact publication, versioning і failure recovery. Models-only часто дає кращий баланс для test project: schema types генеруються, request/response handling залишається explicit. Повний client варто додавати, коли його maintenance cost нижчий за duplicated manual clients.