Відеобібліотека
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
У відео згадано «Codex за $20» і дорожчі плани Claude.
Станом на 2026-07-31 $20/month — ціна ChatGPT Plus, а не окремого Codex plan. OpenAI Pro має tiers $100/$200; Claude Pro у США — $20/month, Claude Max — $100/$200. ChatGPT subscriptions і API billing є окремими продуктами; регіональні ціни, податки й limits можуть відрізнятися.
Перевірено 2026-07-31 за офіційними сторінками OpenAI та Anthropic.
Playwright MCP, CLI, Codegen та AI в розробці →Free plan, trial та enterprise мають різні можливості: ліміти створення проєктів, доступні кнопки й повідомлення. Це окремі вимоги рольової моделі, тому їх варто перевіряти окремими тестами. Наприклад, free-plan тест підтверджує відповідну позначку тарифу та обмеження створення проєкту, а enterprise-тест — доступність повного сценарію. Розгалуження між цими очікуваннями в одному тесті приховує дефект, якщо середовище випадково відкрило не ту роль.
Перший варіант дублює Enterprise state й через стандартний модуль `json` очищає cookie `Company ID`. Пошук проходить масив cookies, змінює лише елемент із потрібним `name` і записує окремий файл. Цей підхід є оптимізацією для конкретного застосунку, а не універсальним правилом Playwright. Якщо backend session або інший state також прив’язаний до tenant, безпечніше реально перемкнути проєкт у браузері й зберегти отриманий context.
Для великої міграції план доцільно зберегти в окремому Markdown-файлі й виконувати по одному пункту в нових сесіях. Це зменшує ризик, що модель втратить початкові обмеження у довгому контексті або спробує змінити забагато файлів за один раз. Стабільні правила проєкту — структура, команди, naming, бібліотеки та перевірки — корисно тримати у спільному інструкційному файлі на кшталт `AGENTS.md`. Тимчасовий migration plan можна не комітити, якщо він потрібен лише для локальної роботи.
Fixture може завантажувати заздалегідь підготовлений Playwright `storageState` з потрібними cookies та `companyId`. Тоді free-plan і enterprise suites стартують одразу у своїх контрольованих контекстах і не залежать від випадкового вибору компанії. Та сама модель працює не лише для тарифів: у медичному продукті це можуть бути doctor і patient, а всередині ролі — додаткові рівні доступу. Спільний end-to-end сценарій між ролями залишається окремим тестом, бо має іншу бізнес-мету.
Tooltip із назвою тарифу з’являється після hover, тому тест спочатку знаходить стабільний label, виконує hover і лише потім перевіряє текст підписки. DOM/attribute breakpoints допомагають зрозуміти, який компонент створює анімацію. Повторювані елементи Enterprise і Free додаються в page object, а тест перевіряє стан до та після `select_company`. Це формує observable contract, на який можна спертися під час оптимізації авторизації.
[Дивитися з 08:00](https://www.youtube.com/watch?v=jAl2Qf8Zlyg&t=480s). Досвідчений engineer із точним plan може реалізувати frontend, backend і частину deployment pipeline, використовуючи готову design system та API contract. Frontend має знати, який resource і endpoint запросити; backend — який response повернути; shared components і design tokens дають повторюваний UI. AI допомагає заповнити реалізацію, але не визначає самостійно правильні boundaries і product behavior.
Ефект AI-інструментів можна оцінювати тією ж моделлю на рівні окремої активності. Якщо якісний тест-план за шаблоном вручну займав близько чотирьох годин, а з AI — 30 хвилин, різницю множать на кількість створених тест-планів. Так можна вимірювати підготовку тест-кейсів, баг-репортів, коментарів, тікетів та інших повторюваних артефактів. Важливо не підміняти цим загальну delivery-метрику: локальна економія показує ефективність конкретної операції, а не автоматично доводить прискорення всього SDLC.
[Дивитися з 14:25](https://www.youtube.com/watch?v=reaHS8_pZbU&t=865s). Якщо estimate нав’язано ззовні, команда не повинна регулярно рятувати його unpaid overtime: тоді management бачить лише формально виконаний plan і не отримує evidence, що estimation process зламаний. Потрібно фіксувати фактичний effort, невідомі залежності, скорочений testing scope та carry-over, а на retrospective вимагати участі виконавців в оцінюванні. Сильніша позиція виникає, коли кілька інженерів незалежно описують ту саму проблему фактами. Спочатку питання піднімають із tech lead/engineering lead, потім — на retro або з manager, якщо прямий канал не працює. Повідомлення має бути не «ми не хочемо встигати», а «за такого scope й available capacity безпечний результат потребує X; до deadline можемо завершити Y, решту переносимо або свідомо приймаємо перелічені ризики». У відео також звучить ідея зробити недооцінку видимою через накопичення нестабільних tests і technical debt. Навмисно ламати quality gate не варто: це створює product risk і послаблює аргументацію команди. Правильний еквівалент — не приховувати незавершену роботу, явно документувати deferred checks/debt, не позначати неперевірене як done і вимагати product decision про scope, deadline або quality.
`free_project_context` відкриває context із Free state, а тест одразу перевіряє Free UI без login та ручного switch. Перший запуск виявляє проблему: fixture залежить від того, що інший тест уже створив файл авторизації. Тести не повинні залежати від порядку. Якщо state існує — він завантажується; якщо ні — fixture виконує login, перемикає проєкт, перевіряє Free plan і зберігає state сама.
[Дивитися з 42:15](https://www.youtube.com/watch?v=crzGm6nzfbU&t=2535s). Без чіткого плану той самий prompt може щоразу змінювати різні files, selectors, components або classes, особливо у великій codebase. Тому спочатку фіксують місце й межі зміни, а реалізацію запускають у новому контексті вже за погодженим планом. Для професійного розвитку корисні не декларації про AI, а власні case studies: як було поставлено задачу, які gates захистили якість, що перевірено й які обмеження лишилися. Найпростіший спосіб отримати такий досвід — зробити невеликий власний інструмент, який розв'язує реальну особисту проблему.