Design-to-Code ersetzt kein Produkturteil

Auf X laufen gerade mehrere Diskussionen zusammen, die für Produktteams interessanter sind als der nächste Toolvergleich. Figma meldet starkes Wachstum. Gleichzeitig testen Leute Lovable, Bolt, v0 und Replit gegeneinander und zeigen, wie schnell aus einer Idee ein klickbarer Produktentwurf wird. Daneben steht die These, dass KI Design nicht ersetzt, sondern gutes Design wichtiger macht.

Das ist eine gute Debatte, weil sie den Hype an der richtigen Stelle berührt.

Design-to-Code ist real nützlich. Wer heute eine Produktidee, ein internes Tool oder einen neuen SaaS-Workflow skizzieren will, kann in Stunden sehen, was früher Tage oder Wochen brauchte. Man kann Varianten bauen, Flows ausprobieren, Stakeholdern etwas Konkretes zeigen und schneller lernen, welche Idee trägt.

Aber genau deshalb wird Produkturteil wichtiger, nicht unwichtiger.

Ein generierter Prototyp kann überzeugend aussehen, ohne dass das Produkt entschieden ist. Er kann einen guten ersten Eindruck machen, ohne dass die Architektur stimmt. Er kann einen Workflow simulieren, ohne dass echte Daten, Rechte, Fehlerfälle, Latenzen, Abhängigkeiten, Abrechnung, Support oder Betrieb sauber gedacht sind.

Für Gründer, CTOs, Product Owner und Mittelstandsteams ist das die eigentliche Frage: Wie nutzt man KI-Prototyping, ohne einen hübschen Entwurf mit einem belastbaren Produkt zu verwechseln?

Warum der X-Trend relevant ist

Die aktuelle Diskussion dreht sich oberflächlich um Tools. Welches System hält Designvorgaben besser ein? Welches driftet nach ein paar Iterationen ab? Welches erzeugt brauchbareren Code? Welches fühlt sich mehr nach Produktdesigner, welches mehr nach Codegenerator an?

Das sind berechtigte Fragen. Aber sie sind nicht die wichtigsten.

Die wichtigere Beobachtung ist: Die Kosten für den ersten sichtbaren Stand fallen massiv. Ein Founder kann eine Feature-Idee testen, bevor ein Team einen Sprint plant. Ein Product Owner kann eine Fachabteilung durch einen realistischeren Flow führen als mit statischen Wireframes. Ein CTO kann früher sehen, welche Teile einer Idee technisch riskant werden. Ein Vertriebsteam kann mit einem interaktiven Demo-Konzept lernen, ob Kunden das Problem überhaupt erkennen.

Das ist wertvoll.

Gleichzeitig entsteht eine neue Falle. Je besser ein Prototyp aussieht, desto leichter wird er intern wie ein fast fertiges Produkt behandelt. Die Sprache kippt schnell von “Das ist ein Experiment” zu “Können wir das nächste Woche live stellen?”

Manchmal ist die Antwort ja. Oft ist sie: nur, wenn wir jetzt bewusst umbauen.

Ein Prototyp beantwortet andere Fragen als ein Produkt

Ein guter KI-Prototyp beantwortet Fragen wie:

• Versteht ein Nutzer den Ablauf?
• Fühlt sich die Idee nützlich an?
• Welche Informationen müssen auf den Bildschirm?
• Wo ist der Flow zu kompliziert?
• Welche Varianten sollten wir vergleichen?
• Lohnt sich ein weiterer Invest?

Das sind Produktfragen. Sie sind wichtig, und KI kann hier enorm beschleunigen.

Ein Produktionssystem beantwortet andere Fragen:

• Welche Datenmodelle tragen den Prozess langfristig?
• Welche Berechtigungen gelten für welche Rollen?
• Wie werden Fehlerfälle sichtbar und korrigierbar?
• Welche Teile sind Kernlogik, welche nur Oberfläche?
• Wie testen wir kritische Pfade?
• Wie verhält sich das System bei Wachstum?
• Wie werden Integrationen, Logs, Monitoring und Betrieb organisiert?
• Was passiert, wenn ein externer Anbieter, ein Modell oder eine API ausfällt?

Diese Fragen verschwinden nicht, weil der erste Screen schneller gebaut wurde. Sie werden nur früher sichtbar.

Das ist der produktive Umgang mit Design-to-Code: nicht als Abkürzung um Architektur herum, sondern als schnelleres Werkzeug, um die richtigen Architekturfragen zu finden.

Design bleibt ein Produktvorteil

Die Figma-Diskussion auf X ist deshalb interessant. Viele hatten erwartet, dass KI Design entwertet. Die Realität sieht differenzierter aus. Wenn jeder schneller Oberflächen erzeugen kann, wird die Frage “Welche Oberfläche ist richtig?” wichtiger.

Gutes Design ist nicht Dekoration. Es ist Produktdenken in sichtbarer Form.

Es entscheidet, welche Information Priorität bekommt. Welche Aktion naheliegt. Wo ein Nutzer Vertrauen braucht. Wo Komplexität versteckt werden darf und wo sie sichtbar sein muss. Welche Sprache ein Produkt spricht. Wie Fehlermeldungen wirken. Welche Zustände fehlen. Ob ein Workflow für echte Menschen funktioniert oder nur in einer Demo.

KI-Tools können Varianten erzeugen. Sie können Layouts ausspucken. Sie können Komponenten zusammensetzen. Sie können sogar überraschend gute erste Entscheidungen treffen.

Aber sie kennen nicht automatisch den Geschäftsprozess, die Kundenrealität, die internen Zwänge, die regulatorische Lage oder die Differenzierung des Produkts.

Das gilt besonders im deutschen Markt. Viele Produkte sind nicht nur schöne SaaS-Dashboards. Sie hängen an Fachprozessen, Rollen, Datenqualität, Legacy-Systemen, Datenschutz, Betriebsvereinbarungen, Supportwegen und langfristiger Wartbarkeit. Ein generierter Screen ist dort nur der Anfang.

Der gefährliche Moment: Wenn der Prototyp gut genug aussieht

Der riskanteste Zustand ist nicht ein schlechter Prototyp. Den erkennt jeder.

Riskant ist ein Prototyp, der gut genug aussieht, um Entscheidungsträger zu überzeugen, aber noch nicht gut genug gebaut ist, um echte Last, echte Daten und echte Verantwortung zu tragen.

Dann entstehen typische Probleme:

• Die Datenstruktur folgt der Oberfläche statt dem Geschäftsmodell.
• Komponenten werden dupliziert, weil jede Iteration lokal optimiert.
• Edge Cases werden später teuer, weil sie im Demo-Flow nicht sichtbar waren.
• Sicherheit und Rollenmodelle werden nachträglich aufgeklebt.
• Der Code funktioniert, ist aber schwer zu testen und schwer zu ändern.
• Die Marke wirkt inkonsistent, weil Designentscheidungen nicht systematisiert wurden.
• Das Team diskutiert über Pixel, obwohl die Produktentscheidung noch offen ist.

Das ist kein Argument gegen Lovable, Bolt, v0, Replit oder ähnliche Tools. Im Gegenteil: Die Tools sind nützlich genug, dass Teams einen besseren Umgang damit brauchen.

Die Frage ist nicht “KI oder klassische Entwicklung?” Die Frage ist: An welcher Stelle im Produktprozess ist KI-Prototyping stark, und ab welcher Stelle braucht das System eine bewusstere technische und produktseitige Struktur?

Was ein guter Handoff enthalten sollte

Der Handoff von einem KI-Prototyp in ein ernsthaftes Produkt sollte nicht nur aus Code bestehen. Code ist nur ein Teil der Übergabe.

Ein guter Handoff beschreibt:

• Welche Nutzerprobleme der Prototyp validiert hat.
• Welche Annahmen noch offen sind.
• Welche Screens und Flows übernommen werden sollen.
• Welche Designentscheidungen absichtlich sind.
• Welche Teile nur Demo-Material sind.
• Welche Datenmodelle gebraucht werden.
• Welche Integrationen real sind und welche simuliert wurden.
• Welche Rollen, Rechte und Sicherheitsgrenzen gelten.
• Welche Qualitätsanforderungen für Performance, Barrierefreiheit, Datenschutz und Betrieb gelten.
• Welche Teile neu gebaut, refaktoriert oder bewusst verworfen werden.

Das klingt schwerer als “Wir nehmen einfach den generierten Code”. In der Praxis ist es oft günstiger.

Denn ohne diesen Handoff zahlt das Team später mit Missverständnissen. Entwickler müssen erraten, welche Teile wichtig sind. Designer müssen erklären, warum eine scheinbar kleine Abweichung den Flow kaputt macht. Product Owner verlieren den Überblick, welche Annahmen validiert wurden und welche nur hübsch aussehen. CTOs übernehmen technische Schulden, ohne dass es je eine bewusste Entscheidung gab.

Ein strukturierter Handoff schützt Geschwindigkeit. Er bremst sie nicht.

Welche Teile darf man behalten?

Eine praktische Frage lautet: Muss man generierten Code immer wegwerfen?

Nein. Aber man sollte ihn nicht ungeprüft zur Produktbasis erklären.

Es gibt grob drei Kategorien.

Erstens: Teile, die man behalten kann. Das sind oft einfache UI-Komponenten, Layout-Ideen, Textvarianten, kleinere Interaktionen oder interne Tools mit begrenztem Risiko. Auch hier sollten Stil, Accessibility, Tests und Wartbarkeit geprüft werden.

Zweitens: Teile, die als Spezifikation dienen. Das ist häufig der wertvollste Bereich. Der Prototyp zeigt, was gebaut werden soll, aber die Implementierung wird sauber in die bestehende Architektur übersetzt. Daten, APIs, Zustände, Fehlerfälle und Berechtigungen werden bewusst modelliert.

Drittens: Teile, die weg müssen. Dazu gehören wackelige Authentifizierung, improvisierte Datenmodelle, duplizierte Logik, unsichere Integrationen, schlecht testbare Kernprozesse oder Code, der nur durch Zufall funktioniert.

Diese Unterscheidung braucht Erfahrung. Sie ist aber genau der Punkt, an dem KI-gestützte Entwicklung professionell wird. Nicht alles neu schreiben. Nicht alles blind übernehmen. Sondern entscheiden, was Wert hat.

Produkturteil ist die knappe Ressource

Wenn Implementierung schneller wird, verschiebt sich die knappe Ressource.

Früher scheiterten viele Ideen daran, dass der erste sichtbare Stand zu teuer war. Heute scheitern sie eher daran, dass zu viele sichtbare Stände entstehen und niemand klar entscheidet, welcher davon ein tragfähiges Produkt werden soll.

Produkturteil bedeutet hier:

• Das richtige Problem vom interessanten Demo-Effekt zu trennen.
• Nutzerfeedback von interner Begeisterung zu unterscheiden.
• Designqualität nicht mit Oberflächenpolitur zu verwechseln.
• Technische Machbarkeit nicht mit Wartbarkeit gleichzusetzen.
• Früh zu entscheiden, welche Architekturgrenzen nötig sind.
• Zu wissen, wann Geschwindigkeit hilft und wann sie Schulden versteckt.

Das ist genau die Arbeit, die seriöse Produktteams leisten müssen. KI nimmt sie nicht weg. Sie macht sie sichtbarer.

Für McDougall Digital ist das ein sehr natürlicher Arbeitsbereich. Wir nutzen KI, weil sie Produktentwicklung beschleunigen kann. Aber wir behandeln sie nicht als Ersatz für Architektur, Produktverantwortung oder saubere Lieferung. Gerade bei ernsthaften Produkten ist der wertvolle Teil oft nicht der erste generierte Stand, sondern die Übersetzung von einem guten Prototyp in ein System, das ein Unternehmen tragen kann.

Ein vernünftiger Prozess

Ein pragmatischer Ablauf sieht so aus:

Zuerst wird der Prototyp bewusst als Lernwerkzeug gebaut. Er darf schnell sein. Er darf unfertig sein. Er darf Annahmen sichtbar machen. Wichtig ist nur, dass alle wissen: Das ist noch nicht die Produktbasis.

Dann werden die Erkenntnisse gesichert. Welche Flows funktionieren? Welche Nutzerfragen wurden beantwortet? Welche Designentscheidungen sind stark? Wo ist der Prototyp irreführend?

Danach kommt der Architekturcheck. Welche Domänenobjekte gibt es? Welche Integrationen? Welche Rollen? Welche Daten? Welche Risiken? Welche Teile gehören ins Designsystem, welche in Backend-Services, welche in Operations?

Erst dann sollte entschieden werden, welche Codebestandteile übernommen werden. Manchmal ist das viel. Manchmal fast nichts. Beides kann richtig sein.

Zum Schluss wird aus dem Prototyp ein Produktplan: technische Schritte, Risiken, Tests, Verantwortlichkeiten und ein realistischer Weg in Betrieb und Wartung.

Das ist kein schwergewichtiger Enterprise-Prozess. Es ist einfach der Unterschied zwischen schneller Demo und belastbarer Lieferung.

Wie wir helfen können

Wenn Sie bereits mit Lovable, Bolt, v0, Replit, Cursor oder ähnlichen Tools experimentieren, ist der nächste sinnvolle Schritt nicht zwingend “mehr Prompts”. Oft ist der bessere Schritt eine ehrliche Bewertung:

• Was ist an diesem Prototyp produktseitig wirklich validiert?
• Welche Designentscheidungen sollten wir behalten?
• Welche Teile sind technisch riskant?
• Welche Architektur braucht das Produkt, wenn es ernst wird?
• Welche KI-generierten Bestandteile sind brauchbar, und welche sollten neu gebaut werden?

McDougall Digital hilft genau an dieser Stelle: zwischen schneller KI-Exploration und ernsthafter Softwarelieferung. Wir können Prototypen prüfen, Produktannahmen schärfen, Architekturgrenzen definieren, Frontend- und Backend-Entscheidungen ordnen und den Weg von der Demo zum wartbaren Produkt planen.

Design-to-Code ist ein starkes Werkzeug. Aber das Ziel ist nicht, schneller mehr Code zu erzeugen.

Das Ziel ist, schneller zu einem besseren Produkt zu kommen.