Відеобібліотека
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
У CI перед тестами теж потрібен крок встановлення браузерів. Підготовка runner має відтворювати локальні передумови явно; наявність залежності у `requirements.txt` не замінює цього кроку. Практично варто встановлювати лише ті браузери, які справді запускає pipeline. Це скорочує час і обсяг завантаження без нового шару конфігурації.
Щоб проєкт можна було клонувати й запустити на іншій машині, його прямі залежності фіксують у конфігурації на кшталт `requirements.txt`. Бібліотеки самі залежать від інших пакетів — це транзитивні залежності. Повний freeze може додати до файлу весь граф пакетів. Автор радить не зберігати зайвий шум без потреби: достатньо явно вказати основні залежності, наприклад Playwright і pytest, а їхні сумісні внутрішні пакети підтягнуться автоматично. Жорстко фіксувати весь граф варто тоді, коли відтворюваність або конфлікти версій справді стали проблемою. Інакше довгий список складніше підтримувати й аналізувати.
CLI економніше за довгу MCP-взаємодію для короткої перевірки. Але якщо дію треба повторювати — regression check, bug verification або scraping — краще один раз згенерувати й зберегти script. Агент, який щоразу імпровізує новий набір CLI-команд, створює різну поведінку й ускладнює debugging.
Замість ручної послідовності створення `venv`, активації та `pip install -r requirements.txt` проєкт переходить на `uv sync`. Залежності й метадані описуються у `pyproject.toml`, а `uv.lock` фіксує точні версії, включно з транзитивними залежностями. Для застосунку або тестового проєкту lock-файл варто комітити: це відтворює однаковий dependency graph локально та в CI й зменшує ризик конфліктів, коли різні бібліотеки вимагають несумісні версії спільної залежності.
[Дивитися з 42:15](https://www.youtube.com/watch?v=crzGm6nzfbU&t=2535s). Без чіткого плану той самий prompt може щоразу змінювати різні files, selectors, components або classes, особливо у великій codebase. Тому спочатку фіксують місце й межі зміни, а реалізацію запускають у новому контексті вже за погодженим планом. Для професійного розвитку корисні не декларації про AI, а власні case studies: як було поставлено задачу, які gates захистили якість, що перевірено й які обмеження лишилися. Найпростіший спосіб отримати такий досвід — зробити невеликий власний інструмент, який розв'язує реальну особисту проблему.