Відеобібліотека
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Візьміть один feature flow і перевірте його через frontend, API та persistence boundaries. Зафіксуйте contract для time fields, кількість backend/provider calls, authorization states і system-level regression risks.
Короткий risk-based review із конкретними evidence та переліком перевірок, яких бракує.
Поточний Playwright Codegen намагається вибрати resilient locator, пріоритезуючи role, text і test id, та уточнює locator, якщо match не унікальний. Generated result усе одно потребує review.
4. Playwright плагіни та codegen →Перевірка видимості, тексту або значення, яку Codegen додає через Inspector; вона залишається чернеткою до review і test run.
4. Playwright плагіни та codegen →Pull Request представляє запропоновані зміни з branch і дає команді місце для diff, review, checks та рішення про merge.
2. Git Workflow у PyCharm/IntelliJ →Pinned tests перевіряють однакову структуру тем і запуск усіх scripts. Це корисний contract/smoke приклад до system-review теми, але не system test продукту: browser, API, database і deployed environment відсутні. Код не скопійовано через відсутність LICENSE.
Vibe coding, склад команди та нова роль тестувальника → Першоджерело ↗Пройти короткий flow через Codegen або CLI.
Зберегти generated draft у test file.
Адаптувати locators і data setup до наявного project contract.
Запустити test і переглянути trace.
Зафіксувати, що саме AI зекономив і що вимагало manual review.
Один repeatable green test із trace та короткою оцінкою saved time.
[Дивитися з 15:00](https://www.youtube.com/watch?v=jAl2Qf8Zlyg&t=900s). Паралельні coding agents збільшують output, але потребують більше review. Engineer має одночасно думати про race conditions, ризики, completeness ticket-а, API/data contracts і місце transformation logic. Простий приклад — dates: backend може повернути timestamp, local date або значення з timezone; без єдиного контракту різні screens покажуть різні результати.
Практичний flow: людина вручну проходить сценарій через Playwright Codegen, передає згенерований код моделі, просить рознести його по наявних page objects, запускає тест і дає trace для наступного review. Генерація відбувається малими порціями, а людина контролює data setup, reuse та фактичний user journey. Для складного enterprise flow з inventory, credit limits, third-party integrations і stateful users автономний agent без domain context не буде надійним.
У діалозі Commit перший рядок повідомлення має стисло пояснювати завершену зміну. Нижче можна додати деталі, необхідні для майбутнього пошуку й code review. Ідентифікатор задачі в повідомленні або назві гілки допомагає простежити контекст. Перед комітом IDE може виконати Reformat Code та Optimize Imports. Ці операції потрібно переглянути так само, як ручні зміни: автоматичне форматування не є гарантією коректності.
Змінна `hello_world: str` демонструє рядковий тип. Python здатен вивести тип із правої частини, але annotation робить намір видимим у code review та допомагає IDE з автодоповненням. Для швидкого експерименту значення виводиться через `print()`. IDE postfix templates і шорткати скорочують набір коду, але результат залишається звичайним Python-викликом.
Для OTP можна зарезервувати test identity і детермінований code; для rate limits — окреме правило для CI traffic. Автор допускає такий bypass навіть на production, хоча прямо зазначає, що цього бажано не робити. Редакційне security-застереження: на production безпечніше виконувати smoke через звичайний захист або спеціально спроєктований найменш привілейований test path. Будь-який production bypass header чи hardcoded OTP стає критичним секретом: його витік фактично вимикає захист, тому потрібні ротація, журналювання, вузький scope і окремий security review.
Перед commit треба переглянути кожен changed file і переконатися, що до нього потрапили лише навмисні зміни. Commit message коротко описує зміст. IDE може запустити reformat code, optimize imports і code analysis; ці перевірки допомагають знайти технічні проблеми, але не замінюють ручного diff review.
[Дивитися з 10:20](https://www.youtube.com/watch?v=reaHS8_pZbU&t=620s). Стабільного інженера часто цінують вище за «rockstar», який коротко дає надрезультат, але має підвищений ризик burnout. Якщо automation або AI скоротили виконання задачі, час можна вкласти в навчання, сім’ю, відпочинок чи власний small product, а не автоматично збільшувати обсяг sprint commitment. Окремий варіант — локальний analyzer для test failures, artifacts або code review, який бере контрольований фрагмент logs/code, формує summary і допомагає знайти напрямок виправлення. Такий інструмент має залишатися в дозволеній trust boundary. Дві повні зайнятості автор згадує лише як короткостроковий спосіб заробітку й не радить його як тривалий режим через навантаження та ризик вигорання.
Перед кожним commit потрібно відкрити список змінених файлів і переглянути конкретні рядки. Досвід не усуває ризик випадково додати пароль, token, локальну конфігурацію, тимчасовий коментар або сторонню зміну. `.gitignore` зменшує ризик, але не замінює перегляд staged diff. Корисна послідовність: перевірити `git status`, додати лише потрібні файли, переглянути staged diff, створити вузький commit і ще раз перевірити гілку перед push. Коментарі в коді оцінюються за користю; назви функцій, змінних і локаторів мають пояснювати намір без зайвого шуму.
Зміни для окремого завдання виконуються в новій branch, створеній від актуальної основної гілки. При створенні варто одразу checkout на неї, після чого перевірити поточну branch перед commit. Це ізолює роботу та спрощує подальший review.
Prompt має описувати конкретні ознаки, які треба знайти: змішані absolute/relative imports, відсутні type hints, невикористаний код, naming conventions, кеші Python. Рольова фраза на кшталт «працюй як інженер із десятьма роками досвіду» не замінює технічних критеріїв. Згенерований план обов’язково перечитується. У прикладі корисними знахідками є відсутній тип `Page`, зайві імпорти, непослідовні приватні поля та незаігнорований `__pycache__`, але частина запропонованих змін є спірною або зайвою. Спочатку важливо отримати корисний робочий тест; узгодженість структури виправляється окремим контрольованим рефакторингом.