Design First, Then Build: A Better AI Dev Workflow

In 2025, most developers using AI coding assistants are still doing the same thing they did in 2023: opening a chat window, typing a problem, and iterating until something works. The tool has changed. The workflow has not.

According to McKinsey's State of AI in 2024, organizations are increasingly adopting structured approaches to AI implementation, moving beyond ad-hoc experimentation to more deliberate design and planning phases before deployment. That shift is happening at the organizational level. Individual developers are slower to catch up, and the gap shows in the quality of what they ship.

The core tension is this: prompt-first feels faster because you get output immediately. Design-first feels slower because you spend time before you type a single prompt. The question worth answering is which approach actually costs more time across the full arc of a build, from first idea to working code.

We've run both approaches across multiple automation builds at ForgeWorkflows. The results are not ambiguous.

The Prompt-First Approach

Prompt-first is the default. You have a problem. You describe it to an LLM. You get code. The code is wrong in three ways you didn't anticipate. You correct one. Two more surface. You iterate.

This loop is not inherently broken. For small, well-scoped tasks, it works fine. The problem appears when the task has hidden dependencies, edge cases that only become visible mid-build, or output requirements that the model interprets differently than you intended.

I made this mistake myself building an early version of a sprint analysis pipeline. I described what I wanted in a single prompt, got a working skeleton in minutes, and spent the next two days unwinding decisions the model made that I hadn't specified. The model chose a data structure I didn't want. It handled null values in a way that broke downstream steps. It wrote functions that worked in isolation but didn't compose. None of those problems were the model's fault. I hadn't told it what I actually needed, because I hadn't figured that out myself yet.

Prompt-first externalizes your thinking to the model before your thinking is complete. The model fills the gaps. It will always fill the gaps, and it will fill them with plausible defaults, not your defaults.

The Design-First Approach

Design-first inverts the sequence. Before you write a prompt, you write a spec. Not a formal document. A working document: inputs, outputs, constraints, edge cases, integration points. You answer the questions the model would otherwise answer for you.

The spec doesn't need to be long. For a moderately complex automation, a half-page of structured notes is enough. What matters is that you've made the decisions before the model makes them for you.

Once the spec exists, prompting changes character entirely. Instead of "build me a thing that does X," you're saying "here are the exact inputs, here are the exact outputs, here are the constraints, build the function that connects them." The model's job becomes translation, not design. Translation is something current LLMs do well. Design, especially design that accounts for your specific system's constraints, is something they do inconsistently.

There's a subtler benefit too. Writing the spec forces you to find the ambiguities before the model does. Every time you write "the system should handle errors gracefully" and then ask yourself what that actually means in your context, you're catching a future iteration loop before it starts.

Where Constraint Language Fits In

One thing the design-first approach surfaces that prompt-first often misses: the difference between a preference and a hard constraint.

I spent a week trying to get a classifier to output exactly 3 sentences. The prompt said "EXACTLY 3 sentences. Not 2, not 4. Three." It still wrote 4. The fix wasn't better instructions. It was stronger constraint language: "CRITICAL: This is a hard technical constraint enforced by automated validation. If you write 4, the output will be rejected. Count your sentences before outputting." LLMs don't treat polite instructions the same as system constraints. Every system prompt we write now uses emphatic constraint blocks for hard output requirements, because we learned that lesson the slow way.

Design-first is where you identify which requirements are hard constraints before you prompt. That distinction changes how you write the prompt, and it changes whether the model respects the requirement. If you haven't done the design work, you don't know which of your requirements are hard until the model violates one.

For more on how constraint language affects model behavior in production pipelines, our piece on token optimization and what we learned the hard way covers the mechanics in detail.

Prompt-first is the right call in specific situations. Exploratory work, where you genuinely don't know what you want yet, benefits from the model's ability to generate options quickly. Throwaway scripts, one-off data transformations, quick prototypes you'll discard: these don't justify a spec. The cost of iteration is low enough that prompt-first is efficient.

Design-first earns its overhead when the build has any of the following characteristics:

• Multiple integration points with existing systems
• Hard output requirements (format, length, schema, timing)
• Downstream consumers that will break on unexpected output
• A team that needs to maintain the code after you ship it
• A workflow that will run repeatedly in production

That last point matters more than it sounds. A workflow you run once can absorb iteration cost. A workflow that runs hundreds of times carries the cost of every design decision forward. Getting the design right before the first run is cheaper than correcting it after the hundredth.

This is exactly the kind of tradeoff we built the Jira Sprint Risk Analyzer around. Sprint risk analysis runs on a cadence. It feeds decisions that affect team planning. The output format has to be consistent enough that downstream consumers, whether that's a Slack notification, a dashboard, or a human reading a report, can rely on it. We designed the output schema before we wrote a single prompt, and we haven't had to change it since. The setup guide walks through how that design-first structure translates into the actual pipeline configuration.

One honest limitation: design-first requires that you know enough about the problem to spec it. If you're working in an unfamiliar domain, you may need a prompt-first exploration phase just to understand what the spec should contain. The two approaches aren't mutually exclusive. Use prompt-first to learn, then design-first to build.

Also worth naming: design-first doesn't eliminate iteration. It reduces the iteration that happens because of unclear requirements. You'll still iterate on implementation details. The difference is that you're iterating on how to build a thing you've already defined, not on what the thing should be.

If you're building pipelines where the reasoning layer makes decisions that affect downstream steps, the case for pre-execution design gets stronger. Our post on why AI agents need pre-execution guards covers what happens when those decisions go unchecked.

Start the spec with constraints, not capabilities. Every spec I've written that led to a clean first build started by listing what the output cannot be, not what it should be. Constraints are more precise than goals, and they're what the model needs to avoid filling gaps with its own defaults. Next time you open a design doc, write the constraint list first.

Build a reusable constraint block library before your next project. We now maintain a set of emphatic constraint templates for common hard requirements: exact output length, schema adherence, null handling, error format. Copying the right block into a new system prompt takes ten seconds. Writing it from scratch under deadline pressure produces weaker language. The library pays for itself on the second use.

Treat the design phase as a separate artifact, not a throwaway step. The spec you write before prompting is also the document that explains the pipeline to the next person who touches it. We've started committing design docs alongside code. The maintenance cost of a pipeline drops when the reasoning behind its constraints is written down somewhere other than the original developer's memory.