Зміст
Коротко
AI-асистенти швидко видають React/Next-компоненти, тести та форми. Код проходить lint і збірку, але ламається на реальному кліку: порожні стани, граничні кейси, race в ефектах. Стаття на Dev.to пропонує Docker + e2e як єдиний контур перевірки до мерджу.
Що сталося
Автор описує типовий розрив: локально «зелений» PR, на staging користувач не може надіслати форму або бачить порожній список. Причина — дрібні runtime-деталі, які генератор не гарантує.
Рішення — не «більше unit-тестів на моках», а той самий образ для app і для Playwright/Cypress: однакові залежності браузера, Node, системні бібліотеки в CI й у колеги.
Чому це важливо
| Проблема AI-коду | Що дає Docker в CI |
|---|---|
| «У мене працює» | Однакове середовище у всіх |
| Пропущений empty state | E2E клікає як користувач |
| Крихкі інтеграції | Сервіс app + runner у compose |
| Швидкі ітерації без дисципліни | Gate перед merge: compose up → tests |
Для команд, які вже використовують Cursor/Claude для UI, це спосіб не прискорювати лише написання, а й поломки.
На практиці
- docker-compose: сервіс
web(збірка застосунку) +e2e(Playwright/Cypress зdepends_on). - Сценарії — happy path + порожні дані + помилка API (mock або test double).
- У PR — job
docker compose run e2e, артефакти скріншотів при падінні. - Не замінює review — але відсікає «очевидно не працює в браузері».
Навіть без повного e2e корисний мінімум: docker compose up --build перед пушем, щоб зловити «забутий env» і native deps.
Підсумок
Docker тут не про деплой заради моди, а про відтворювану пісочницю для коду, який пише і людина, і модель. Має сенс взяти ідею compose-зв’язки app + browser tests, якщо AI став частиною вашого фронтенд-пайплайну.