Contents
In brief
AI assistants ship React/Next components, tests, and forms quickly. Code passes lint and build, then fails on a real click: empty states, edge cases, races in effects. A Dev.to article proposes Docker + e2e as one verification loop before merge.
What happened
The author describes a common gap: a green PR locally, but on staging the user cannot submit a form or sees an empty list. The cause is small runtime details generators do not guarantee.
The fix is not “more unit tests on mocks” but the same image for the app and for Playwright/Cypress: matching browser deps, Node, and system libraries in CI and on a teammate’s machine.
Why it matters
| AI-code problem | What Docker gives in CI |
|---|---|
| “Works on my machine” | Same environment for everyone |
| Missed empty state | E2E clicks like a user |
| Fragile integrations | App + runner services in compose |
| Fast iteration without discipline | Gate before merge: compose up → tests |
For teams already using Cursor/Claude for UI, this avoids speeding up only writing, but also breakage.
In practice
- docker-compose:
webservice (app build) +e2e(Playwright/Cypress withdepends_on). - Scenarios — happy path, empty data, API error (mock or test double).
- In PR — job
docker compose run e2e, screenshot artifacts on failure. - Does not replace review — but filters “obviously broken in the browser.”
Even without full e2e, run docker compose up --build before push to catch missing env and native deps.
Takeaway
Docker here is not deploy hype but a reproducible sandbox for code written by humans and models alike. Adopt the app + browser-tests compose pattern if AI is part of your frontend pipeline.