Design-first agentic development

The gap between "what you described" and "what the agent built" closes fastest when there is a design step before any code runs. Most agentic workflows skip that step. Here is what it costs and how to add it back.

The default loop

Most agentic coding workflows go prompt → implement. You describe what you want in words, the agent starts writing code, and if the result is off you describe the correction. The agent iterates.

This works well for self-contained logic tasks: add a field to a form, write a service that parses a JSON response, fix a type error. The desired output is easy to specify precisely in words, and the cost of being slightly wrong is low.

It breaks down for anything with a strong visual or structural component. Describing a layout in words is inherently lossy. "A sidebar with a filter panel on the left and a results grid on the right, with a sticky header" maps to dozens of subtly different implementations. The agent picks one. If it is not what you meant, you describe the difference. The agent adjusts. Three rounds in, you have spent an hour of implementation time to converge on something you could have sketched in five minutes.

What happens when you skip design

The rework problem is visible: you end up refactoring code that works but implements the wrong thing. Less visible is the compounding effect. A wrong layout decision in the first agent pass often propagates into component structure, naming, and state management. Fixing the visual also means unwinding the architecture that was built around it.

A second pattern: the agent builds exactly what you said, not what you meant. These are different. What you say is a specification; what you mean is shaped by context you haven't written down - how this screen fits next to the others, what the user is trying to accomplish, which interaction pattern your product already uses. That context is visible to you; it is not visible to the agent reading a prompt.

The effect compounds across parallel agents. If you are running three implementation agents and each made a slightly different assumption about a shared component, you find the inconsistency at review time, not at design time. Catching it earlier, before code runs, is what stage boundaries are for.

What developers do instead

The common workarounds each capture part of the solution.

Write a detailed text spec before prompting. Kiro's spec.md, GitHub Spec Kit, and BMAD's planning phase all front-load the specification work before implementation starts. This helps a lot with logic and architecture. For visual work, a text description of a layout is still a lossy encoding of a visual intent - a numbered list of components does not convey the spatial relationships and interaction patterns a visual would. The spec helps; the visual gap remains. Spec-driven development covers where this approach holds up and where it falls short.

Paste a screenshot or Figma export. Give the agent an image of what you want. This closes the visual communication gap significantly, and modern vision-capable models read layout from images reasonably well. The downside: the design lives outside the agent's workflow. You annotate in Figma, export, paste. Changes to the design don't propagate automatically. The agent has no structured way to ask a clarifying question about the visual. The design and the implementation live in separate systems.

Use a code-native design shortcut. Cursor's Design Mode lets you describe a UI visually and have the agent translate it to code. Superset's browser design feature points an agent at a screenshot to generate a component. These are faster than typing a description, but they are translation tools, not design stages. There is no review step between "this is the visual input" and "implementation starts." If the translation misses the intent, you find out in code.

Iterate directly in code. For experienced developers with a fast feedback loop, iterating in code is sometimes the most efficient path. This works when the gap between intent and implementation is small and the blast radius of being wrong is contained. It stops working when the component is large, the behavior is complex, or the design has downstream dependencies.

What a design-first approach changes

The discipline is straightforward: the agent produces a design artifact before any code runs, and implementation does not start until you have reviewed and approved it.

What counts as a design artifact depends on the type of work.

For UI work, a useful artifact is an annotated visual - a screenshot or mockup with annotations marking each component, its behavior, and any open decisions. This is legible to the human reviewer in a way that code is not. You can see at a glance whether the layout matches your intent. You can reject and revise at the annotation layer before a line of code is written.

For logic and architecture work, a useful artifact is a structured spec - the agent's explicit plan for how it will implement the feature: what it will build, what it will leave out, and where the integration points are. Reviewing a plan is cheaper than reviewing a PR.

The gate is what makes the discipline work. Review is only valuable if implementation waits. The whole-session cost of "agent implements the wrong thing" is paid up front in a ten-minute design review, not in hindsight across three implementation cycles.

Why the gate keeps getting skipped

The path of least resistance in most agentic tools is direct implementation. The agent has a prompt. The most natural next step is to act on it. Adding a design step requires you to interrupt the natural loop - stop the agent, produce an artifact, review it, approve it, then resume.

Without tooling that enforces the gate, the interruption requires willpower. Willpower is spent unevenly. For small tasks you skip the review. For larger tasks you mean to review but the agent starts writing and you engage with the code instead of the design. By the time you want to step back, you are already reviewing a PR.

The answer is not more willpower. It is making the gate automatic - the implementation stage cannot start until the design stage has an approved output.

defract's design stage

defract runs a dedicated visual design stage before implementation. The design agent produces an annotated layout on top of your reference screenshot - each component labeled, behaviors noted, open decisions flagged. You review the annotation in the app before the implementation stage unlocks. If the design is wrong, you reject it and describe the correction at the design layer, not the code layer. The approved design artifact lives in the task, so if you return to the feature three weeks later, the rationale is there alongside the implementation and the review output.

This is one approach to enforcing the gate. The broader principle applies at any tooling level: producing a design artifact before implementation starts, and reviewing it before code runs, catches the most expensive class of agent errors at the cheapest point in the development cycle. For a wider map of which agentic coding patterns hold up across different scales of parallelism and task complexity, which agentic coding patterns actually scale covers where each approach fits.