You ask an AI to build a checkout page. The catalog and order services are reachable; the coupon service has not shipped yet.

The usual workaround is a handful of fake objects written straight into the components. The page demos nicely by the afternoon. When the real endpoint arrives, the field shapes, error branches, and request mechanics all get reworked — and the temporary data has a habit of spreading through the codebase where it is hardest to clean up.

Letting one missing dependency detach the frontend from the API contract is a debt that always comes due during integration.

If the contract is settled, the missing implementation should not stop the work.

Agree on the boundary first, then substitute the responses

In Powerduck, design the coupon validation endpoint with the assistant first: what the request needs, and how the service responds when a coupon is valid, expired, or inapplicable. Save the result as the local OpenAPI file.

The local mock server then serves the API straight from that specification, answering from examples or schema-derived responses. The frontend still sends genuine HTTP requests using the contracted paths, parameters, and data structures — only the target points at the local mock. The calling code ends up shaped like the final integration, so switching the base URL when the backend lands is a configuration change rather than a rewrite.

The mock joins the agent's toolchain

Through the dev MCP workflow, the assistant can start a local mock, inspect the requests it received, and stop it when the session ends. For the missing dependency, response overrides can script specific outcomes, including failures. A task can be phrased like this:

The coupon service is unavailable. Start the local mock from the current spec. First verify a valid coupon, then override the operation to return 503. Check that the page preserves the user's input and shows a retry prompt.

At that point the mock is doing more than filling a screen. The agent walks the application through an actual error branch, observes what the client sent to the dependency, and fixes the code against real results. The recorded requests answer questions screenshots cannot — whether the request body matched the contract, for example, rather than whether some label appeared on the page.

Bring the bad weather into development on purpose

Most interfaces behave on the happy path. The experience is decided by what happens when a dependency times out, rejects the request, or returns nothing. A contract-driven mock makes those cases routine to rehearse:

  • Return an empty result and check that the empty state points to a next action.
  • Return the contracted business error and check that the message keeps useful information.
  • Simulate a dependency failure and check that the loading state actually ends.

Each result gives the agent something concrete to fix in the interaction or the calling code. When the real service ships, the same contract and the same scenarios verify it again.

One spec shrinks the gap between temporary and real

This is the point of organizing design, mocking, MCP, and testing around one document. The structure produced while designing the API is exactly what the mock serves from; the agent writing calling code queries the same contract through MCP; and when the service goes live, verification runs against the real target with no translation step.

The mock has honest limits. It does not implement an order state machine, database constraints, or real payment behavior, and one successful mocked call proves nothing about production. What it does is pull the interface boundary and the important failure branches into development early, on the developer's own machine, without waiting for a shared test environment.

For AI-assisted work, that is the mock's real job: a controllable feedback environment where missing dependencies can be stood in for and the problems worth testing can be created on demand.