Bei der KI-gestützten Softwareentwicklung habe ich inzwischen viele Teile meines Arbeitsablaufs ziemlich gut strukturiert. Größere Ideen entstehen zunächst mit ChatGPT, werden dort durch Fragen, Gegenfragen und Entscheidungen ausgearbeitet und anschließend als belastbare Spezifikation an Codex übergeben. Codex arbeitet näher am Repository, zerlegt umfangreichere Vorhaben gegebenenfalls in Aufgaben für Agenda und übernimmt danach einen erheblichen Teil der eigentlichen technischen Umsetzung. Was mir in diesem Prozess lange gefehlt hat, war eine ebenso klare Lösung für die Benutzeroberfläche, denn gerade dort wurde meine ansonsten recht strukturierte Vorgehensweise schnell wieder erstaunlich improvisiert.
Natürlich kann ich Codex eine Oberfläche vollständig in Text beschreiben. Ich kann festlegen, welche Bereiche auf einer Seite erscheinen sollen, welche Funktionen benötigt werden, welche Elemente zusammengehören und wie sich die Anwendung verhalten muss. Sobald es aber um Abstände, Größenverhältnisse, Gruppierung, visuelle Hierarchie oder die genaue Anordnung mehrerer Elemente geht, wird Sprache zu einem ziemlich umständlichen Transportmittel. Was ich in wenigen Sekunden auf einer Oberfläche erkenne, benötigt in Text schnell mehrere Absätze, und wenn die erste Umsetzung meiner Vorstellung nur ungefähr entspricht, beginnt eine Schleife aus Beschreibung, Umsetzung, Korrektur und erneuter Beschreibung.
Genau diese Lücke möchte ich mit Penpot schließen. Nicht, weil ich plötzlich hauptsächlich Designer werden möchte, sondern weil sich ein visuelles Problem aus meiner Sicht besser in einem visuellen Werkzeug beschreiben lässt. Über die MCP-Anbindung kann Codex auf Penpot zugreifen und den dort entstandenen Entwurf in die technische Umsetzung einbeziehen, ohne dass ich jede visuelle Entscheidung vorher wieder in natürliche Sprache übersetzen muss.
Mein bisheriger Workflow war beim UI-Design unnötig indirekt
ChatGPT und Codex übernehmen bei mir bewusst unterschiedliche Rollen. ChatGPT eignet sich hervorragend dafür, fachliche Anforderungen zu hinterfragen und gemeinsam mit mir zu klären, was eine Funktion eigentlich leisten soll, während Codex anschließend den vorhandenen Code analysiert und daraus eine passende technische Umsetzung entwickelt. Für Geschäftslogik, Architektur und viele Backend-Themen funktioniert diese Trennung sehr gut, weil sich das gewünschte Verhalten vergleichsweise präzise beschreiben lässt.
Bei Benutzeroberflächen ist das schwieriger. Natürlich kann ich auch dort Anforderungen formulieren, aber eine Oberfläche besteht eben nicht nur aus Funktionen. Sie lebt von räumlichen Beziehungen, visueller Gewichtung und der Frage, welche Information ein Nutzer zuerst wahrnimmt. Wenn ich Codex erkläre, dass ein Bereich „etwas kompakter“ werden soll, während die wichtigste Aktion stärker hervorgehoben werden muss und zwei andere Elemente enger zusammengehören sollen, ist diese Beschreibung deutlich ungenauer als ein konkreter Entwurf.
Genau an dieser Stelle entsteht unnötiger Aufwand. Codex liefert eine technisch funktionierende Oberfläche, ich sehe sofort, was visuell noch nicht passt, muss diese Beobachtung aber wieder in Text zurückübersetzen. Anschließend versucht Codex, diesen Text erneut in Layout umzusetzen. Das funktioniert, ist aber weder besonders elegant noch besonders sparsam im Umgang mit Zeit und Tokens.
Penpot ergänzt den Prozess an der richtigen Stelle
Meine größeren Softwarethemen beginnen weiterhin in ChatGPT, denn dort möchte ich zuerst verstehen, welches Problem gelöst werden soll, welche Funktionen erforderlich sind und welche fachlichen Entscheidungen getroffen werden müssen. Penpot ersetzt diese Konzeptphase deshalb nicht, sondern ergänzt sie anschließend um eine Ebene, die bisher in meinem Prozess gefehlt hat.
Wenn fachlich klar ist, was eine Oberfläche leisten soll, kann ich in Penpot konkretisieren, wie diese Funktionen angeordnet, gruppiert und visuell gewichtet werden. Daraus ergibt sich für mich inzwischen eine deutlich sauberere Prozesskette:
Idee → fachliches Konzept in ChatGPT → UI-Entwurf in Penpot → technische Umsetzung mit Codex
Diese Trennung gefällt mir vor allem deshalb, weil jedes Werkzeug dort eingesetzt wird, wo seine Stärken liegen. ChatGPT arbeitet mit Anforderungen und Zusammenhängen, Penpot mit visuellen Strukturen und Codex mit dem tatsächlichen Code. Anstatt ein einziges System zu zwingen, jede Phase gleichermaßen gut abzudecken, entstehen klarere Übergaben zwischen spezialisierten Werkzeugen.
Die Penpot-Anbindung ist nicht rasend schnell, aber schnell genug
Die Geschwindigkeit der MCP-Anbindung ist dabei durchaus ein Punkt, den man erwähnen muss. Ich würde sie nicht als rasend bezeichnen. Manche Schritte benötigen spürbar Zeit, und wenn ich ausschließlich die Reaktionsgeschwindigkeit eines einzelnen Aufrufs betrachte, ist das langsamer als eine rein textbasierte Anweisung an Codex.
Für mich ist das trotzdem kein echter Nachteil, weil der relevante Maßstab nicht die Dauer eines einzelnen Schritts ist, sondern der gesamte Weg von meiner Vorstellung bis zu einer brauchbaren Oberfläche. Wenn ich zehn oder zwanzig Sekunden länger auf die Verarbeitung eines Penpot-Entwurfs warte, dafür aber mehrere Runden aus Beschreibung, Missverständnis, Korrektur und erneuter Umsetzung vermeide, ist die Gesamtbilanz für mich klar positiv.
Noch deutlicher wird dieser Effekt beim Tokenverbrauch. Ein Layout enthält sehr viele Informationen, die sich visuell unmittelbar erkennen lassen, aber sprachlich erstaunlich ausführlich beschrieben werden müssen. Ein Penpot-Entwurf transportiert diese Struktur wesentlich kompakter und eindeutiger. Dadurch sinkt nicht nur die Zahl der Rückfragen, sondern auch die Menge an Text, die Codex überhaupt verarbeiten muss, um dieselbe Vorstellung zu rekonstruieren.
Die etwas längere Reaktionszeit der Anbindung wird für mich deshalb durch Zeit- und Tokenersparnis an anderer Stelle deutlich überkompensiert.
Reaktionsgeschwindigkeit ist nicht dasselbe wie Prozessgeschwindigkeit
Das ist für mich inzwischen ein grundsätzlich interessanter Punkt. Ein Werkzeug kann in jedem einzelnen Schritt etwas langsamer reagieren und trotzdem den gesamten Prozess beschleunigen, wenn es dafür weniger Fehlversuche, Rückfragen und Korrekturen erzeugt.
Bei Penpot sehe ich genau diesen Effekt. Der zusätzliche Designschritt verlängert zunächst die Strecke bis zum ersten Stück Code, reduziert aber gleichzeitig die Wahrscheinlichkeit, dass ich anschließend mehrfach strukturelle Änderungen an einer bereits umgesetzten Oberfläche durchführen lassen muss.
Damit ähnelt Penpot in gewisser Weise meinen ausführlicheren Spezifikationen. Auch dort investiere ich bewusst mehr Zeit vor der Implementierung, weil sich Unklarheiten in dieser Phase wesentlich günstiger korrigieren lassen als später im fertigen Code. Die zusätzliche Vorbereitung ist kein Selbstzweck, sondern soll die nachgelagerte Umsetzung zielgerichteter machen.
Bei UI-Design funktioniert dasselbe Prinzip nur mit einem anderen Artefakt: Statt einer textlichen Spezifikation entsteht ein visueller Bezugspunkt.
Das Design wird zu einem eigenständigen Artefakt
Dieser Punkt ist für mich wichtiger, als er zunächst klingt. Solange die Oberfläche direkt im Code entsteht, sind Design und Implementierung sehr eng miteinander verbunden. Eine visuelle Entscheidung wird sofort zu einer technischen Entscheidung, und umgekehrt beeinflusst die vorhandene Komponentenstruktur schnell das Aussehen der Anwendung.
Mit Penpot entsteht dazwischen eine klarere Grenze. Das Design beschreibt, wie die Oberfläche aufgebaut sein soll, ohne bereits festzulegen, wie Codex dieses Ergebnis technisch in Blazor umsetzt. Damit kann ich das visuelle Ziel unabhängig vom konkreten Code beurteilen und verändern.
Das passt sehr gut zu meiner allgemeinen Haltung zur Softwarearchitektur. Ich möchte Ziele und Grenzen möglichst klar beschreiben, Codex innerhalb dieser Grenzen aber weiterhin technische Freiheit lassen. Penpot überträgt dieses Prinzip auf die Oberfläche: Die visuelle Struktur kann verbindlich sein, ohne dass ich dadurch jede einzelne Blazor-Komponente vorgeben muss.
Für Blazor ist diese Trennung besonders interessant
Bei Blazor ist die Gefahr ziemlich groß, eine Benutzeroberfläche aus den vorhandenen technischen Komponenten heraus zu denken. Wenn bereits Tabellen, Dialoge, Formulare und Layoutkomponenten existieren, ist es sehr bequem, neue Funktionen so zu gestalten, dass möglichst viel davon direkt wiederverwendet werden kann.
Technisch ist Wiederverwendung sinnvoll, sie darf aber nicht automatisch bestimmen, wie eine Oberfläche für den Nutzer aussehen muss. Eine bestehende Komponente ist kein Argument dafür, dass ein neuer Ablauf zwangsläufig genau dieselbe visuelle Struktur erhalten sollte.
Mit Penpot kann ich zuerst festlegen, wie die Oberfläche aus Nutzersicht funktionieren soll, und erst danach prüfen, wie sich dieser Entwurf sinnvoll in vorhandene oder neue Blazor-Komponenten übersetzen lässt. Weil Codex die technische Umsetzung schneller erzeugen kann, ist eine neue oder angepasste Komponente heute außerdem weniger abschreckend als früher, als jede zusätzliche technische Struktur direkt deutlich mehr eigene Entwicklungszeit bedeutet hätte.
Git Worktrees bringen die Parallelisierung auf eine weitere Ebene
Richtig interessant wird diese Arbeitsweise für mich allerdings erst in Verbindung mit Git Worktrees. Ich arbeite bereits mit mehreren KI-Arbeitssträngen parallel, und mit Agenda soll diese Parallelisierung langfristig noch stärker werden. Sobald mehrere Codex-Aufgaben gleichzeitig am selben Repository arbeiten, brauche ich eine saubere technische Trennung der jeweiligen Arbeitsstände.
Git Worktrees passen dafür sehr gut. Anstatt mehrere Aufgaben im selben Checkout bearbeiten zu lassen, kann jede freigegebene Aufgabe einen eigenen Worktree erhalten. Codex arbeitet dann in einem separaten Arbeitsverzeichnis mit einem eigenen Branch, kann dort Dateien verändern, Builds starten und Tests ausführen, ohne dass eine zweite parallele Aufgabe unmittelbar denselben Arbeitsstand durcheinanderbringt.
Für UI-Arbeit eröffnet das interessante Möglichkeiten. Ein Penpot-Entwurf kann die gemeinsame visuelle Grundlage darstellen, während mehrere technische Aufgaben unabhängig voneinander daraus umgesetzt werden. Eine Aufgabe könnte beispielsweise die grundlegende Seitenstruktur aufbauen, eine andere wiederverwendbare Komponenten vorbereiten und eine dritte einen bestimmten Funktionsbereich implementieren, sofern die fachlichen und technischen Abhängigkeiten eine solche Trennung tatsächlich erlauben.
Die Worktrees sorgen dabei nicht für inhaltliche Unabhängigkeit, aber sie schaffen eine saubere technische Isolation.
Worktrees lösen nicht das eigentliche Konfliktproblem
Das ist mir wichtig, weil Git Worktrees leicht den Eindruck vermitteln könnten, parallele Entwicklung sei damit automatisch gelöst. Wenn zwei Aufgaben dieselbe zentrale Komponente verändern müssen, entstehen die fachlichen oder architektonischen Konflikte spätestens beim Zusammenführen trotzdem.
Genau deshalb beschäftige ich mich bereits mit logischen Arbeitsbereichen und der Koordination paralleler Codex-Arbeiten. Agenda müsste langfristig erkennen, welche Aufgaben sich tatsächlich unabhängig voneinander bearbeiten lassen und welche gemeinsame Komponenten beanspruchen.
Worktrees bilden für mich also eine technische Ebene dieses Konzepts. Sie verhindern, dass mehrere Agenten unkontrolliert im selben Arbeitsverzeichnis Änderungen vornehmen, ersetzen aber nicht die übergeordnete Orchestrierung.
Gerade die Kombination gefällt mir: Agenda entscheidet beziehungsweise verwaltet, welche Arbeiten gleichzeitig laufen dürfen, Git Worktrees schaffen dafür getrennte Arbeitsstände, und Codex kann innerhalb dieser Arbeitsstände weitgehend autonom arbeiten.
Penpot passt erstaunlich gut in diese parallele Struktur
Penpot bekommt dadurch eine weitere Funktion. Es ist nicht nur eine bessere Möglichkeit, Codex eine einzelne Oberfläche zu erklären, sondern kann zur gemeinsamen Designgrundlage für mehrere parallele Aufgaben werden.
Das Design selbst bleibt zentral sichtbar, während die technische Umsetzung in mehreren Worktrees stattfinden kann. Dadurch lassen sich Änderungen besser aufteilen, ohne dass jede Aufgabe ihre eigene Vorstellung davon entwickelt, wie die Oberfläche aussehen soll.
Gerade bei größeren Anwendungen halte ich das für wertvoll. Wenn mehrere Bereiche derselben Anwendung parallel entstehen, ist visuelle Konsistenz schnell gefährdet. Ein gemeinsamer Entwurf reduziert dieses Risiko, weil die einzelnen Codex-Aufgaben nicht jeweils aus ihren eigenen Textbeschreibungen unterschiedliche Interpretationen ableiten müssen.
Damit wird Penpot indirekt auch zu einem Instrument für Konsistenz.
Noch interessanter wird es bei späterer Zusammenarbeit mit anderen Menschen
Heute arbeite ich allein, deshalb gibt es aktuell niemanden, an den ich die Designarbeit tatsächlich delegieren könnte. Trotzdem möchte ich meinen Prozess nicht so bauen, dass er nur funktioniert, solange wirklich jede Aufgabe durch mich selbst läuft.
Penpot schafft dafür eine ausgesprochen interessante Schnittstelle. Sollte später jemand mit mir zusammenarbeiten, könnte diese Person UI- und Designarbeit übernehmen, ohne zwangsläufig tief in Blazor, Repository-Struktur oder meine gesamte technische Architektur einsteigen zu müssen.
Ein zukünftiges Teammitglied könnte sich beispielsweise auf Bedienkonzept, Layout, visuelle Hierarchie oder responsive Varianten konzentrieren und den Entwurf direkt in Penpot pflegen. Codex übernimmt anschließend die technische Übersetzung in die Anwendung, während ich weiterhin die übergeordneten fachlichen und architektonischen Entscheidungen kontrolliere.
Damit würde Designarbeit erstmals sauber aus meinem unmittelbaren technischen Arbeitsprozess herauslösbar.
Die Auslagerung wäre damit nicht nur personell, sondern strukturell vorbereitet
Dieser Punkt ist für mich besonders wichtig. Wenn ich irgendwann Arbeit an eine weitere Person abgebe, möchte ich nicht erst dann überlegen müssen, wie diese Zusammenarbeit überhaupt funktionieren soll.
Ein klarer Penpot-Prozess schafft schon heute eine definierte Übergabestelle. Das Design existiert unabhängig vom Code, Änderungen lassen sich nachvollziehen und Codex besitzt über MCP einen direkten Weg, diese Informationen in der Umsetzung zu verwenden.
Dadurch kann menschliche Zusammenarbeit später an einer Stelle in den Prozess einsteigen, die fachlich sinnvoll abgegrenzt ist. Jemand müsste nicht meinen gesamten Entwicklungsworkflow übernehmen, sondern könnte einen klar definierten Bereich bearbeiten, dessen Ergebnis anschließend wieder automatisiert in die technische Kette einfließt.
Gerade für einen Einzelunternehmer ist das interessant, weil sich damit spätere Zusammenarbeit vorbereiten lässt, ohne heute bereits eine Organisation zu simulieren, die es noch gar nicht gibt.
Penpot schafft damit eine gemeinsame Sprache zwischen unterschiedlichen Rollen
Ein Entwickler betrachtet eine Oberfläche anders als jemand, der sich stärker mit Design oder Benutzerführung beschäftigt. Der eine denkt schnell in Komponenten, Zuständen und technischen Abhängigkeiten, der andere möglicherweise stärker in Abläufen, Hierarchien und visueller Verständlichkeit.
Ein Designwerkzeug schafft zwischen diesen Perspektiven einen gemeinsamen Bezugspunkt. Statt lange darüber zu diskutieren, was mit „etwas kompakter“ oder „deutlich stärker hervorgehoben“ gemeint ist, kann die Änderung direkt sichtbar gemacht werden.
Für Codex gilt dasselbe Prinzip. Je weniger Interpretation bei der Übergabe erforderlich ist, desto klarer wird die Aufgabe.
Das bedeutet nicht, dass Penpot jede Kommunikation ersetzt. Fachliches Verhalten, Datenquellen, dynamische Zustände und technische Einschränkungen müssen weiterhin beschrieben werden. Aber die visuelle Ebene muss nicht mehr vollständig durch Sprache transportiert werden.
Ein gutes Penpot-Design ist trotzdem noch keine gute Anwendung
Bei aller Begeisterung für den saubereren Prozess möchte ich einen Punkt ausdrücklich nicht übersehen: Penpot kann mir helfen, ein Design eindeutig zu beschreiben, aber es garantiert nicht, dass dieses Design tatsächlich gut ist.
Mein Oma-Test bleibt deshalb genauso relevant wie vorher. Eine Oberfläche muss für die vorgesehene Zielgruppe verständlich sein, sinnvolle Prioritäten setzen und auch in Fehler- oder Leerzuständen nachvollziehbar bleiben.
Ein visuell sehr sauberer Entwurf kann trotzdem einen schlechten Bedienablauf besitzen. Ebenso kann ein technisch perfekt umgesetztes Penpot-Design am eigentlichen Problem des Nutzers vorbeigehen.
Deshalb bleiben Konzept, Benutzerführung, Design und technische Umsetzung getrennte Qualitätsstufen. Penpot verbessert für mich hauptsächlich die Übergabe zwischen diesen Stufen.
Änderungen müssen langfristig in beide Richtungen funktionieren
Ein weiterer Punkt, den ich noch praktisch erproben muss, betrifft spätere Änderungen. Eine Oberfläche ist selten nach dem ersten Entwurf endgültig abgeschlossen. Neue Funktionen kommen hinzu, bestehende Abläufe verändern sich und manchmal zeigt erst die tatsächliche Nutzung, dass ein Element anders angeordnet werden sollte.
Dann darf Penpot nicht zu einer Dokumentation werden, die nach der ersten Umsetzung langsam vom echten Code abweicht.
Langfristig brauche ich deshalb einen klaren Änderungsprozess. Wenn das Design angepasst wird, muss Codex erkennen können, welche Teile der bestehenden Blazor-Implementierung davon betroffen sind. Umgekehrt sollte eine technisch notwendige Abweichung vom Entwurf nicht einfach still im Code entstehen, sondern wieder in die Designentscheidung zurückfließen.
Genau an dieser Stelle wird sich zeigen, wie belastbar die Integration wirklich ist.
Penpot wird damit zu mehr als einem Designprogramm
Auf meinem Weg zu agentischen Systemen versuche ich immer stärker, unterschiedliche Werkzeuge mit klaren Rollen in einen gemeinsamen Prozess einzubauen. Penpot passt überraschend gut in dieses Modell, weil es eine bislang schlecht abgedeckte Informationsart übernimmt: visuelle Produktentscheidungen.
ChatGPT hilft mir, fachliche Entscheidungen zu entwickeln. Penpot bildet daraus die Benutzeroberfläche ab. Codex verarbeitet beides und erzeugt technische Änderungen. Git Worktrees schaffen getrennte Arbeitsräume für parallele Umsetzungen, während Agenda langfristig koordinieren soll, welche Arbeiten gleichzeitig laufen dürfen und welche Abhängigkeiten bestehen.
Damit entsteht Schritt für Schritt ein Workflow, in dem nicht ein einzelnes KI-System alles können muss, sondern mehrere spezialisierte Werkzeuge ihre Stärken miteinander verbinden.
Für mich ist die Bilanz schon jetzt positiv
Die Penpot-Anbindung ist nicht spektakulär schnell, und ich werde sicherlich noch Stellen finden, an denen der Prozess verbessert werden muss. Trotzdem überwiegen für mich schon heute die Vorteile, weil die etwas längere Wartezeit bei einzelnen Zugriffen durch weniger textbasierte Erklärungen, weniger Korrekturschleifen und einen geringeren Tokenverbrauch mehr als ausgeglichen wird.
Noch wichtiger ist allerdings die strukturelle Wirkung. Das UI-Design wird zu einem eigenständigen Artefakt, Codex bekommt eine klarere Grundlage für die Umsetzung, parallele Aufgaben lassen sich mit Worktrees sauberer voneinander trennen und der Designprozess wäre später sogar an andere Menschen delegierbar, ohne dass diese dafür zwangsläufig denselben technischen Zugang zum Projekt benötigen.
Damit schließt Penpot für mich nicht nur eine Lücke beim Erstellen schönerer Oberflächen. Es fügt meinem gesamten Entwicklungsprozess eine neue, klar definierte Ebene hinzu, die sowohl Automatisierung als auch Parallelisierung und spätere Zusammenarbeit erleichtert.
Wenn sich dieser Ansatz in den nächsten Projekten bewährt, könnte genau das der Punkt sein, an dem UI-Design für mich aufhört, ein etwas improvisierter Sonderfall der KI-Entwicklung zu sein, und zu einem ganz normalen Bestandteil derselben Prozesskette wird.