Design-to-code does not replace product judgement

Several conversations on X are converging in a useful way right now. Figma is showing strong growth. People are testing Lovable, Bolt, v0 and Replit against the same product brief and comparing how well each tool preserves design intent. At the same time, the broader claim that AI makes design less valuable is starting to look too simple.

That is a good debate because it touches the hype at the right point.

Design-to-code is genuinely useful. If you want to explore a product idea, an internal tool or a new SaaS workflow, you can now see something concrete in hours instead of days or weeks. You can test variants, walk stakeholders through a flow, make abstract ideas visible and learn faster.

But that makes product judgement more important, not less.

A generated prototype can look convincing before the product decision is sound. It can create a strong first impression without having the right architecture. It can simulate a workflow without dealing with real data, permissions, errors, latency, integrations, billing, support or operations.

For founders, CTOs, product owners and German mid-sized teams, this is the practical question: how do you use AI prototyping without mistaking a persuasive prototype for a reliable product?

Why the X trend matters

The current discussion looks like a tool comparison on the surface. Which system follows the brief better? Which one drifts after a few iterations? Which one produces cleaner code? Which one feels more like a product designer and which one feels more like a code generator?

Those questions are fair. They are not the most important ones.

The more important observation is that the cost of the first visible version is collapsing. A founder can test a feature idea before a team plans a sprint. A product owner can show a department a more realistic workflow than static wireframes. A CTO can spot technical risk earlier. A sales team can use an interactive demo concept to learn whether customers even recognise the problem.

That is valuable.

It also creates a new trap. The better the prototype looks, the easier it is for an organisation to treat it as almost finished. The language quickly shifts from “this is an experiment” to “can we launch this next week?”

Sometimes the answer is yes. Often the answer is: only if we now rebuild deliberately.

A prototype answers different questions from a product

A strong AI prototype answers questions like:

• Does the user understand the flow?
• Does the idea feel useful?
• Which information needs to be on the screen?
• Where is the workflow too complicated?
• Which variants should we compare?
• Is this worth another round of investment?

Those are product questions. They matter, and AI can accelerate them enormously.

A production system answers different questions:

• Which data model will support the process over time?
• Which permissions apply to which roles?
• How are errors surfaced and corrected?
• Which parts are core logic and which parts are only interface?
• How do we test the critical paths?
• How does the system behave as usage grows?
• How are integrations, logs, monitoring and operations handled?
• What happens if a vendor, model or API fails?

Those questions do not disappear because the first screen was built faster. They appear earlier.

That is the productive way to think about design-to-code: not as a shortcut around architecture, but as a faster way to discover the right architecture questions.

Design remains a product advantage

This is why the Figma conversation is interesting. Many people expected AI to devalue design. The reality is more nuanced. If everyone can generate interfaces faster, the question “which interface is right?” becomes more important.

Good design is not decoration. It is product thinking made visible.

It decides which information gets priority. Which action feels natural. Where a user needs trust. Where complexity can be hidden and where it must be exposed. Which language the product speaks. How errors feel. Which states are missing. Whether a workflow works for real people or only in a demo.

AI tools can generate variants. They can produce layouts. They can assemble components. They can even make surprisingly good first decisions.

But they do not automatically understand the business process, the customer reality, the internal constraints, the regulatory setting or the product’s differentiation.

That is especially true in the German market. Many products are not just attractive SaaS dashboards. They sit inside specialist processes, roles, data quality issues, legacy systems, privacy requirements, works council constraints, support paths and long-term maintenance obligations. A generated screen is only the beginning.

The dangerous moment: when the prototype looks good enough

The riskiest prototype is not the bad one. Everyone recognises that.

The risky prototype is the one that looks good enough to convince decision-makers, but is not yet built well enough to carry real load, real data and real responsibility.

That is where common problems appear:

• The data structure follows the interface instead of the business model.
• Components are duplicated because every iteration optimises locally.
• Edge cases become expensive later because they were invisible in the demo flow.
• Security and role models are added after the fact.
• The code works, but is hard to test and hard to change.
• The brand feels inconsistent because design decisions were never systematised.
• The team argues about pixels while the product decision is still open.

This is not an argument against Lovable, Bolt, v0, Replit or similar tools. The opposite is true: the tools are useful enough that teams need a more professional way to use them.

The question is not “AI or traditional development?” The question is: where in the product process is AI prototyping strong, and where does the system need a more deliberate technical and product structure?

What a good handoff should include

The handoff from an AI prototype into a serious product should not be only code. Code is just one part of the transfer.

A useful handoff explains:

• Which user problems the prototype validated.
• Which assumptions are still open.
• Which screens and flows should be preserved.
• Which design decisions are intentional.
• Which parts are only demo material.
• Which data models are needed.
• Which integrations are real and which were simulated.
• Which roles, permissions and security boundaries apply.
• Which quality requirements matter for performance, accessibility, privacy and operations.
• Which parts should be kept, refactored, rebuilt or discarded.

This sounds slower than “we will just use the generated code.” In practice, it is often cheaper.

Without that handoff, the team pays later through confusion. Developers have to guess which parts matter. Designers have to explain why a seemingly small change breaks the flow. Product owners lose track of which assumptions were validated and which merely looked nice. CTOs inherit technical debt that was never an explicit decision.

A structured handoff protects speed. It does not kill it.

Which parts can you keep?

A practical question is whether generated code always has to be thrown away.

No. But it should not be promoted to product foundation without review.

There are roughly three categories.

First: parts you can keep. These are often simple UI components, layout ideas, copy variants, small interactions or limited-risk internal tools. Even then, style, accessibility, tests and maintainability should be checked.

Second: parts that should become specification. This is often the most valuable category. The prototype shows what should be built, but the implementation is translated cleanly into the existing architecture. Data, APIs, states, errors and permissions are modelled deliberately.

Third: parts that should go. This includes weak authentication, improvised data models, duplicated logic, unsafe integrations, hard-to-test core workflows or code that works mainly by accident.

That distinction requires experience. It is also where AI-supported development becomes professional. Do not rewrite everything by default. Do not blindly keep everything either. Decide what has value.

Product judgement is the scarce resource

When implementation gets faster, the scarce resource shifts.

In the past, many ideas failed because the first visible version was too expensive. Now they are more likely to fail because too many visible versions exist and nobody clearly decides which one should become a durable product.

Product judgement means:

• Separating the real problem from the interesting demo effect.
• Distinguishing user feedback from internal excitement.
• Not confusing design quality with surface polish.
• Not treating technical feasibility as maintainability.
• Deciding early which architecture boundaries are needed.
• Knowing when speed helps and when it hides debt.

That is the work serious product teams still have to do. AI does not remove it. It makes it more visible.

For McDougall Digital, this is a natural place to work. We use AI because it can accelerate product development. But we do not treat it as a replacement for architecture, product responsibility or careful delivery. In serious products, the valuable part is often not the first generated version. It is the translation from a good prototype into a system the business can actually rely on.

A sensible process

A pragmatic process looks like this.

First, build the prototype deliberately as a learning tool. It can be fast. It can be rough. It can expose assumptions. The important thing is that everyone understands it is not yet the product foundation.

Then capture the learning. Which flows worked? Which user questions were answered? Which design decisions are strong? Where is the prototype misleading?

Next comes the architecture check. Which domain objects exist? Which integrations? Which roles? Which data? Which risks? Which parts belong in the design system, which in backend services and which in operations?

Only then should the team decide which generated code to keep. Sometimes that is a lot. Sometimes it is almost nothing. Both can be correct.

Finally, turn the prototype into a product plan: technical steps, risks, tests, responsibilities and a realistic path into operation and maintenance.

This is not a heavyweight enterprise process. It is simply the difference between a fast demo and reliable delivery.

How we can help

If you are already experimenting with Lovable, Bolt, v0, Replit, Cursor or similar tools, the next useful step is not always “more prompts.” Often the better step is an honest assessment:

• What did this prototype actually validate?
• Which design decisions should we preserve?
• Which parts are technically risky?
• Which architecture does the product need if it becomes serious?
• Which AI-generated parts are usable, and which should be rebuilt?

McDougall Digital helps at exactly this point: between fast AI exploration and serious software delivery. We can review prototypes, sharpen product assumptions, define architecture boundaries, organise frontend and backend decisions, and plan the path from demo to maintainable product.

Design-to-code is a powerful tool. But the goal is not to generate more code faster.

The goal is to get to a better product faster.