A coding agent returns a screen that looks close to what you wanted. Then you narrow the browser and discover a button disappearing off the right edge. Your next message might be “fix mobile” or “make this responsive.”

That leaves several decisions open. Can the agent replace the layout? Should it change the components? Which parts already work? What would count as a successful correction?

You can answer those questions without writing a specification for the entire application.

Here is an illustrative example using a hypothetical React pricing page.

At a desktop width, the page has three pricing cards and a comparison section. The existing components and color palette are acceptable. At 375 CSS pixels wide, part of the page extends beyond the viewport and the primary button is partly hidden.

The correction has a narrow goal: make the mobile layout usable while preserving the existing design choices.

Describe the failure you can reproduce

Before composing the prompt, reproduce the problem and describe what you can actually see. “The primary button extends past the right edge at 375 pixels” gives the agent somewhere to investigate. “The CSS is wrong” claims a cause you may not have checked.

If your agent can inspect the page, give it the route and the viewport size. If it cannot, attach a screenshot and describe the interaction. A screenshot can establish the visible symptom; it cannot establish which element caused it.

Write a correction with clear boundaries

Then separate the parts you want to keep from the thing you want changed. Here is a correction you could adapt:

The pricing page extends past the viewport at 375 CSS pixels wide. The primary button is partly off screen. Keep React, the existing component system, the current copy and the color palette. Preserve the desktop layout as far as the mobile fix allows. Find which element causes the page overflow, then fix the layout so the page fits at 320, 375 and 768 CSS pixels wide. Keep every plan and its primary action available. Cards can stack. If the comparison section needs horizontal scrolling, contain it within that section so it does not widen the whole page. Use the smallest change that resolves the cause. If a component boundary needs to change, explain why instead of replacing the screen wholesale. Check the result in the browser at those widths and at 1280 pixels. Run the existing relevant checks. Report what you verified, what changed and anything you could not test.

The viewport sizes are chosen for this example. Use widths that reproduce your own issue and cover the layouts you intend to support. They are checkpoints, not a claim that three sizes cover every device.

Notice that the prompt leaves implementation room. It does not prescribe a grid utility or assume the problem comes from the cards. A long label, a fixed width or another descendant could be involved. Let the investigation identify the cause.

It also distinguishes page overflow from a deliberately scrollable comparison section. That matters when a table needs more space than a phone can provide. You may want the table to scroll while the page itself stays within the viewport.

Avoid accepting a disappearing scrollbar as sufficient evidence. An agent could apply overflow-x: hidden and leave content clipped. MDN documents that hidden overflow clips content. Inspect the content and controls as well as the page boundary.

Check the result in the browser

After the correction, check the same failure again. At 375 pixels, can you read each plan and reach its primary action? At 320 pixels, does a long label remain readable? If the comparison section scrolls, can you reach its final column? At 1280 pixels, did the desktop arrangement or palette change unexpectedly?

Ask the agent for observed results at each width. “Responsive now” is a conclusion. A useful report identifies the route, dimensions, checks performed and remaining limitations. If browser tools are unavailable, it should say so. A passing build does not show that a button remains visible.

Narrow the next correction

If one problem remains, write the next correction around that observation:

The page now fits at 375 pixels, but the annual billing label overlaps the price at 320 pixels. Keep the overflow fix. Adjust that label and price layout, then recheck both widths and the desktop view.

Use wording like this only after observing that result. It preserves the progress you want to retain and gives the agent a smaller remaining problem. You can judge the next result against a specific interaction instead of asking whether the screen generally looks better.

I'm building Ahed to help compose prompts and suggest contextual follow ups. The demo and waitlist are live, and the demo shows Codex on Mac. Public app access is not available yet.