Subagents
Описує current Codex subagent workflows, trigger rules, agent threads, token cost і безпечніші read-heavy patterns.
Як налаштувати мультиагентне середовище → Першоджерело ↗Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Терміни, нюанси та джерела
Перевірити, чи потрібен 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.
Чому зберігати лише failed traces
Trace для кожного успішного тесту швидко збільшує обсяг CI artifacts. Простий варіант «зберігати все» допустимий для малого набору з коротким retention, але кращий контракт — залишати ZIP лише коли тест упав. Артефакт має жити достатньо, щоб інженер устиг провести root-cause analysis. Retention і upload налаштовуються на рівні CI; сама fixture відповідає лише за локальне створення файлу.
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-ить і повністю тестує весь продукт.