Skip to content
← All posts
context-engineering

True full-stack context engineering

The complete version: two monorepos, a Dockerized backend with a database, API, and Mailpit, and Chrome DevTools MCP watching both the UI and the API traffic. One system the agent sees end to end.

Full-stack context engineering cover
Published
Reading time
3 min read

I have written about the pieces separately: context engineering, a Dockerized backend, the MCP tools. This is the version where they all come together. “True” full-stack context engineering is when an AI agent can see and exercise every layer at once: the frontend code, the backend code, the running system, and the actual behavior across the boundary between them. Here is the whole picture.

Two monorepos, both in the agent’s hands

The frontend lives in one monorepo (the apps and the shared design system) and the backend in its own. The agent works with both open, so it is never guessing at the other side. When it changes a GraphQL query in the frontend, it can read the resolver that answers it. When it touches a resolver, it can see every frontend call site. Full-stack context starts with the agent actually holding both halves of the code, not one half and a mental model of the other.

Docker makes the system real, not imagined

Code is only half of context. The other half is a running system, and Docker is what makes that cheap and reproducible. docker compose up brings the backend online: PostgreSQL with a seed, the API, and Mailpit catching outbound email. Now the agent is not reasoning about what the code should do, it can run it: hit the API, watch a row appear in Postgres, confirm the email landed in Mailpit, all in an environment that behaves the same way every time.

Chrome DevTools MCP sees both sides at once

This is the piece that ties it together. With Chrome DevTools MCP, the agent drives a real browser and, crucially, sees both the frontend and the API from the same seat. It renders the UI, reads the console, and watches the network panel as requests fly to the Dockerized backend. So when it triggers a booking flow, it does not just check that a button worked. It sees the GraphQL request go out, the response come back, the component render, and then the confirmation email arrive over in Mailpit. Frontend and API, observed together, in one loop.

The loop, start to finish

Put it together and a single task closes cleanly. The agent reads the ticket, changes code in both monorepos, brings the stack up in Docker, drives the flow in a real browser, watches the request cross into the backend, verifies the database and the email, and confirms what actually rendered. Every layer is visible. Nothing is a black box it had to assume.

Why “true” full-stack matters

An agent with only the frontend guesses at the backend. An agent with only source guesses at runtime. Give it both codebases, a running Dockerized system, and eyes on the frontend and the API together, and the guessing mostly stops. That is the whole idea behind context engineering: the quality of what an agent produces is bounded by what it can see. Let it see everything, and full-stack work stops being a relay of assumptions and becomes one continuous, verifiable loop.