Wie ein Frontend-Ingenieur den neuen Workflow zwischen Produkt und Engineering im KI-Zeitalter erlebt
Eine Zahl, die keinen Sinn ergeben sollte
12 Tage. Zwei Personen: eine Produktdesignerin und ein Frontend-Ingenieur. Ein kompletter Neuaufbau der Plattform.
Kein Prototyp. Kein MVP. Ein vollstaendiger Ersatz einer Produktionsanwendung, der in einem einzigen PR gipfelte, der 26.000 Zeilen Legacy-Code loeschte. Jede Seite, jede Route, jede Interaktion -- von Grund auf neu gebaut und an echte Nutzer ausgeliefert.
In jedem traditionellen Produktentwicklungs-Workflow waere dieser Zeitrahmen absurd. Ein Projekt dieses Umfangs wuerde normalerweise Monate dauern: Wochen der Design-Exploration in Figma, Runden von Stakeholder-Reviews, eine Uebergabezeremonie, Sprint-Planung und dann das zaehe Abarbeiten der pixelgenauen Umsetzung. Was hier passierte, war grundlegend anders. Nicht weil wir haerter gearbeitet haben, sondern weil sich die Art unserer Zusammenarbeit veraendert hat.
Das ist die Geschichte, wie wir die Zero-Plattform bei VM0 ausgeliefert haben -- und was sie mich ueber die Zukunft der Zusammenarbeit zwischen Produkt und Engineering gelehrt hat.
Der alte Flaschenhals
Jeder Frontend-Ingenieur kennt die traditionelle Pipeline:
- Designer erstellt Mockups in Figma
- Design-Review, Iteration, Freigabe
- Annotierte Spezifikationen mit Abstaenden, Farben, Breakpoints
- Ingenieur uebersetzt visuelle Specs in Code
- Hin und Her: "Kannst du das 4px nach links verschieben?"
- Schliesslich die API-Anbindung
- Integrationstests, noch mehr Hin und Her
Der Flaschenhals lag nie in einem einzelnen Schritt. Er lag in den Luecken zwischen den Schritten: dem Warten, dem Uebersetzungsverlust, dem Kontextwechsel. Das mentale Modell einer Interaktion, das ein Designer hat, kommt -- einmal in einen statischen Figma-Frame abgeflacht und mit Redlines annotiert -- bereits degradiert auf dem Schreibtisch des Ingenieurs an. Der Ingenieur baut eine Version dessen nach, was sich der Designer vorgestellt hat, aber es ist unvermeidlich eine verlustbehaftete Kopie.
Wir hatten uns so sehr an diese Reibung gewoehnt, dass wir sie nicht mehr wahrnahmen. Es war einfach "so laeuft das eben."
Das Experiment: Was waere, wenn die Designerin Code ausliefert?
Am 5. Maerz 2026 eroeffnete Ming, unsere Produktdesignerin, PR #3685: feat(platform): add zero app with shell, pages and polish. Er fuegte 4.146 Zeilen funktionierenden React-Code hinzu.
Keine Figma-Datei. Kein Design-Token-Export. Eine laufende Anwendung.
Der PR enthielt eine komplette App-Shell: Sidebar-Navigation, Routing-Struktur, Seitenskelette fuer Chat, Schedule, Activity, Teamverwaltung und Einstellungen -- alles mit unserem Design-System gestylt, alles im Browser gerendert. Die Daten waren gemockt, aber die UI war echt. Man konnte npm run dev ausfuehren und sich durch jede Seite klicken.
Ming hat diesen Code nicht im traditionellen Sinne von Grund auf geschrieben. Sie nutzte KI-Coding-Tools (zuerst Cursor, spaeter Claude Code), um ihre Design-Vision direkt in React-Komponenten zu uebersetzen. Die KI uebernahm die mechanische Uebersetzung (JSX-Struktur, CSS-Eigenschaften, Komponenten-Komposition), waehrend Ming die visuellen und interaktiven Entscheidungen traf, die keine KI treffen kann: den Rhythmus des Layouts, die Informationshierarchie, das Gefuehl der Uebergaenge.
In den naechsten vier Tagen folgten drei weitere PRs:
| Datum | PR | Was Ming auslieferte |
|---|---|---|
| 5. Maerz | #3685 | App-Shell, Sidebar, alle Seitenskelette (+4.146 Zeilen) |
| 6. Maerz | #3825 | Schedule-Seiten, UI-Polish (+2.650 Zeilen) |
| 9. Maerz | #3993 | Onboarding-Flow, Slack-Konfigurationsdialog (+1.146 Zeilen) |
| 9. Maerz | #4050 | About-Seite, schwebende Navigationskarte |
Bis zum 9. Maerz existierte die gesamte Frontend-Oberflaeche unserer neuen Plattform als laufender Code. Jede Seite, die man spaeter in der Produktion sehen wuerde, war bereits in einer Entwicklungsumgebung klickbar. Sie tat nur noch nichts Echtes.
Da kam ich ins Spiel.
Meine neue Aufgabe: Die Seele einsetzen
Als ich am 9. Maerz die Codebase oeffnete, stand ich nicht vor der ueblichen Herausforderung, ein flaches Design in Code zu uebersetzen. Der Code war bereits da. Meine Aufgabe war es, jeden Mock durch Realitaet zu ersetzen -- jede schoen gestaltete Oberflaeche mit dem lebendigen, atmenden Backend darunter zu verbinden.
Das veraenderte meine Arbeit grundlegend. Statt ueber Pixel nachzudenken, dachte ich ueber Datenfluesse nach. Statt zu fragen "Stimmt das mit dem Mockup ueberein?" fragte ich "Welchen API-Call braucht diese Seite, und was passiert, wenn er fehlschlaegt?"
So sah meine erste Woche aus:
Tag 1 (9. Maerz): Auth und Org-Wechsel. Ich verband Mings Shell mit der Clerk-Authentifizierung, fuegte Cross-Domain-Redirects hinzu und brachte den Org-Switcher dazu, tatsaechlich Orgs zu wechseln. Zwei PRs, beide am selben Tag gemerged.
Tag 2 (10. Maerz): Connectors und Schedule. Ich ersetzte das gemockte Connector-Grid durch echte API-Daten, verband den Schedule-Tab mit tatsaechlichen Cron-Jobs und schloss den Instructions-Editor ans Backend an. Vier PRs.
Tag 3 (11. Maerz): Der grosse Verdrahtungstag. Die Team-Seite bekam echte Subagent-Daten (+3.271 Zeilen). Die Activity-Seite bekam echte Logs. Und das Kronjuwel: Die Chat-Seite wurde mit der tatsaechlichen Agent-Run-Pipeline verbunden, wobei ~1.200 Zeilen Demo-Code durch ein funktionierendes KI-Konversationsinterface ersetzt wurden. Am selben Tag fuehrte ich FeatureSwitchKey.Zero ein -- ein Feature Flag, das uns ermoeglichte, alte und neue Plattform parallel zu betreiben.
Tag 4-5 (12.-13. Maerz): Dateianhänge, Session-Management, Multi-Agent-Chat, Settings-Persistenz. Jede Seite, die Ming gebaut hatte, verrichtete jetzt echte Arbeit.
Der Rhythmus war fast musikalisch. Jeden Morgen waehlte ich eine Seite aus Mings Geruest, studierte die Komponentenstruktur, identifizierte welche Daten sie erwartete, baute die API-Integration, behandelte die Fehlerzustaende und pushte. Am Nachmittag war eine weitere Seite lebendig.
Der Feature Switch: Parallelwelten
Das FeatureSwitchKey.Zero Feature Flag verdient eine eigene Erwaehnung, denn es ist das, was diese Migration sicher statt waghalsig machte.
Ab dem 11. Maerz lief unsere Produktions-App mit zwei kompletten UIs parallel. Nutzer im alten System sahen die alten Routen. Interne Tester im neuen System sahen Zero. Jede Seite, die ich verdrahtete, konnte im Produktionskontext getestet werden, ohne den Workflow eines einzigen Nutzers zu gefaehrden.
Das ist nicht revolutionaer. Feature Flags sind gaengige Praxis. Aber die Kombination von Feature Flags mit dem Design-as-Code-Workflow schuf etwas Besonderes: Wir konnten die gesamte UX der neuen Plattform validieren (weil Ming eine komplette, durchklickbare UI gebaut hatte), waehrend wir jede Seite progressiv funktionsfaehig machten (weil ich sie eine nach der anderen verdrahtete). Zu jedem Zeitpunkt haetten wir, falls etwas schiefging, den Schalter zuruecklegen koennen.
Nichts ging schief.
Tag 12: Der grosse Umschalter
Am 17. Maerz eroeffnete ich PR #5095: refactor: remove all non-zero platform pages and feature flag.
Der Diff: +456 Zeilen, -26.041 Zeilen.
Vorher: die alte VM0-Plattform. Tabellen, Run-IDs und rohe Session-Daten.
Nachher: das neue Zero. Ein KI-Arbeitsbereich mit angepinnten Agents und Use-Case-Karten.
In einem einzigen Merge wurde jede Legacy-Route geloescht. Das Feature Flag wurde entfernt. Zero war keine Option mehr -- es war der einzige Modus. Ein Follow-up-PR (#5155) entfernte das /zero-URL-Praefix vollstaendig: Was vorher /zero/chat gewesen war, wurde einfach zu /chat.
Warum fuehlte ich mich sicher, diesen Schnitt zu machen? Weil:
- Jede Seite mindestens 5 Tage unter dem Feature Flag gelaufen war
- Jede API-Integration gegen Produktionsdaten getestet worden war
- Das alte und neue System dasselbe Backend teilten. Dies war ein Frontend-Tausch, keine Datenmigration
- Wir echte Nutzer auf dem neuen System hatten, die durchgehend Feedback gaben
Die 26.000 Zeilen wurden nicht mit Angst geloescht. Sie wurden mit Erleichterung geloescht.
Das Muster wiederholt sich
Was mich am meisten ueberraschte, war nicht die Migration selbst. Es war, dass der Workflow, den wir entdeckt hatten, zu unserem Standardmodus fuer jedes folgende Feature wurde. Ming baut die UI-Shell mit KI-Unterstuetzung, ich verdrahte die Logik und erweitere die Architektur. Dasselbe Design-as-Code-Muster, im Feature-Massstab:
Berechtigungssystem (19. Maerz → 7. April)
Ming lieferte PR #5467, eine Berechtigungs-Drawer-UI mit Sheet-Komponenten und Toggle-Controls. Drei Commits, saubere UI.
Ich fuegte 13 Commits zum selben PR hinzu: Datenbankmigration fuer firewall_access_requests, API-Endpoints, Integrationstests, Lint-Fixes. Dann ueber die naechsten zwei Wochen 10+ Follow-up-PRs, die die komplette Berechtigungsschicht aufbauten: Redesign der Genehmigungskarte, Slack-Benachrichtigungen fuer Zugriffsanfragen, CLI-doctor-Befehle zur Diagnose von Berechtigungsproblemen und schliesslich die Umbenennung des gesamten Konzepts von "Firewall" zu "Permission" in der gesamten Codebase.
Mings Drawer war der Samen. Das Berechtigungssystem war der Baum.
Schedule-System (23. Maerz → 13. April)
Ming entwarf die Schedule-Detail-Route und die Kalender-UX (#6155). Drei Commits sauberer UI-Arbeit.
Ich fuegte 14 Commits hinzu: Beschreibungsbearbeitung mit Auto-Generierung, Slack-Channel-Auswahl fuer Benachrichtigungen, Bestaetigungsdialoge fuer ungespeicherte Aenderungen, Vereinheitlichung von Kalender-/Listenansicht und umfassende Tests. Dann 15+ Follow-up-PRs, die es zu einem vollstaendigen System fuer wiederkehrende Aufgaben mit Ausfuehrungsverlauf, Zeitzonenbehandlung und Cron-Expression-Unterstuetzung ausbauten.
Telegram-Integration (27. April → 28. April)
Zu diesem Zeitpunkt war das Muster so eingespielt, dass wir eine komplette Plattform-Integration in 48 Stunden auslieferten. Ming baute die Settings-UI (#11196) und den Onboarding-Flow (#11399). Ich baute die Multi-Bot-API, Nachrichten senden/empfangen, Datei-Upload/-Download, Rich-Message-Kontext, Ably-Echtzeit-Updates und E2E-Tests. Am naechsten Tag war es fuer alle Nutzer freigeschaltet.
Wo KI ins Spiel kommt
Ich moechte die Rolle der KI hier praezise beschreiben, denn es ist leicht, sie entweder zu ueber- oder zu untertreiben.
KI ermoeglichte der Designerin zu coden. Ming ist Produktdesignerin, keine Software-Ingenieurin. Sie denkt in Layouts, Hierarchien und Interaktionen -- nicht in React Hooks und TypeScript-Generics. KI-Tools (Cursor, dann Claude Code) ueberbrueckten diese Luecke, indem sie die mechanische Uebersetzung von Design-Absicht in funktionierenden Code uebernahmen. Ming dirigierte; die KI tippte. Das Ergebnis war Code, den eine Designerin verfasst hatte, auf dem aber ein Ingenieur aufbauen konnte.
KI beschleunigte den Review-Zyklus. Bei kollaborativen PRs reviewte mein KI-Agent Mings Code, klassifizierte Issues nach Prioritaet (P0/P1/P2) und pushte Fix-Commits direkt. PR #5060 durchlief fuenf Review-Runden in 38 Minuten. PR #5467 absolvierte drei Runden in 20 Minuten. Das ist kein "KI ersetzt Code-Review". Ich habe immer noch jede Aenderung gelesen. Aber die mechanische Arbeit, Lint-Probleme, fehlende Typen und Test-Luecken zu identifizieren, war automatisiert.
KI traf nicht die Design-Entscheidungen. Die Informationsarchitektur jeder Seite, die Interaktionsmuster, die visuelle Hierarchie: Das kam aus Mings Produktinstinkt, gespeist aus User Research und Domaenenwissen. KI kann eine Einstellungsseite generieren, aber sie kann nicht entscheiden, was ein Toggle sein sollte und was ein Dropdown, oder wann ein Bestaetigungsdialog berechtigt ist und wann er stoert.
KI traf nicht die Architektur-Entscheidungen. Die Entscheidung, ein Feature Flag fuer paralleles Deployment zu nutzen, die API-Layer-Trennungsstrategie, die Entscheidung, Seiten inkrementell statt auf einmal zu verdrahten: Das waren Engineering-Urteilsentscheidungen. KI half mir, den Code schneller zu schreiben, aber die Reihenfolge und das Risikomanagement waren menschlich.
Die ehrliche Zusammenfassung: KI eliminierte die Uebersetzungsschicht zwischen Design und Engineering. Sie ersetzte keine der beiden Disziplinen; sie entfernte die Luecke zwischen ihnen.
Was sich an meiner Rolle veraendert hat
Nachdem ich drei Monate in diesem Workflow gelebt habe, sehe ich meine Rolle als Frontend-Ingenieur anders.
Ich bin kein visueller Uebersetzer mehr. Die Tage, an denen man eine Figma-Datei erhaelt und Stunden damit verbringt, Abstandswerte abzugleichen, sind vorbei. Nicht weil ich schneller darin bin, sondern weil es nicht mehr mein Job ist. Die Absicht des Designers kommt als Code an, nicht als Bild von Code.
Ich bin ein Architektur-Erweiterer. Mein primaerer Wert liegt darin, eine funktionierende UI-Oberflaeche zu nehmen und die unsichtbare Infrastruktur darunter aufzubauen: API-Integrationen, Datenvalidierung, Fehlerbehandlung, Berechtigungspruefungen, Echtzeit-Updates, Tests. Das Verhaeltnis bei den meisten kollaborativen PRs erzaehlt die Geschichte: Ming traegt 3 Commits UI bei, ich trage 13 Commits fuer alles andere bei.
Ich bin ein Qualitaets-Gatekeeper. Mit KI-gestuetzten Review-Zyklen kann ich die Codequalitaet ueber eine viel groessere Flaeche aufrechterhalten als zuvor. Das automatisierte Review faengt die mechanischen Probleme ab; ich konzentriere mich auf architektonische Belange, Grenzfaelle und darauf sicherzustellen, dass das Feature tatsaechlich End-to-End funktioniert.
Ich bin ein Delivery-Stratege. Feature Flags, inkrementelles Verdrahten, parallele Deployments: Die Reihenfolge, wie ein Feature vom Code in die Produktion gelangt, ist jetzt ein Kernbestandteil meiner Arbeit, kein nachtraeglicher Gedanke.
Die Zahlen
Drei Monate. Zwei Personen. Durchgehend KI-unterstuetzt.
- 914 gemergte PRs (679 von mir, 235 von Ming)
- 12 Tage vom ersten Geruest bis zum vollstaendigen Plattform-Ersatz
- 48 Stunden fuer eine komplette Telegram-Integration (unser schnellstes Feature)
- 26.000 Zeilen in einem einzigen selbstbewussten Merge geloescht
- 88% meiner PRs und 66% von Mings tragen KI-Co-Autorschaft
Das sind keine Hustle-Metriken. Niemand von uns hat am Wochenende gearbeitet oder Nachtschichten eingelegt. Die Geschwindigkeit kommt aus der Eliminierung der Totzeit: der Uebergabe-Meetings, der Spec-Missverstaendnisse, des "Kannst du das 4px verschieben"-Hin-und-Hers. Wenn Design-Absicht direkt in Code fliesst und Engineering diesen Code vor Ort erweitert, gibt es einfach weniger Verschwendung.
Was das fuer Teams bedeutet
Ich behaupte nicht, dass jedes Team so arbeiten sollte. Dieser Workflow entstand aus unserem spezifischen Kontext: ein kleines Team, die Gelegenheit eines Greenfield-Neuaufbaus und fruehzeitiger Zugang zu leistungsfaehigen KI-Coding-Tools. Eure Erfahrungen koennen abweichen.
Aber ich glaube, der zugrundeliegende Wandel ist universell: Die Grenze zwischen Design und Engineering loest sich auf, und KI ist das Loesungsmittel. Je besser KI-Tools darin werden, Absichten in Code zu uebersetzen, desto mehr Designer werden Code direkt ausliefern. Wenn das passiert, werden Ingenieure weniger Zeit mit Uebersetzung verbringen und mehr mit Architektur, Qualitaet und Delivery.
Der Job des Frontend-Ingenieurs verschwindet nicht. Er veraendert seine Form. Und ehrlich? Die neue Form ist interessanter.
Yuma ist Frontend-Ingenieur bei VM0, wo er die Plattform baut, die Zero antreibt -- ein KI-Agent-Betriebssystem. Er hat mehr Legacy-Code massengeloescht, als ihm lieb ist.