Содержание
Коротко
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 стал частью вашего фронтенд-пайплайна.