Vom Design zum Code mit KI: Claude Code Verändert Alles

Vom Design zum Code mit KI: Claude Code Verändert Alles

In einem kürzlichen Workshop hat sich etwas verschoben. Ich war bei genug Design-Reviews, Sprint-Planungen und Developer-Handoff-Sessions dabei, um zu wissen, wann eine Workflow-Änderung kosmetisch ist — und wann sie strukturell ist. Dies war strukturell.

Diane, CEO und Mitgründerin von The Design Project, hatte Cursor links offen, Figma rechts, und Claude Code lief dazwischen. Sie tippte einen Prompt — "redesigne diese UI so, wie es ein Weltklasse-Produktdesigner tun würde" — und beobachtete, wie die KI die gesamte Codebase las, ihren Plan skizzierte, eine klärende Frage stellte und dann begann, Dateien zu ändern.

Kein Handoff-Dokument. Kein annotiertes Mockup. Kein Jira-Ticket, das zwei Wochen im Backlog eines Developers lag. Einfach eine Designerin, die echten Front-End-Code über eine KI generierte, die den Projektkontext verstand.

Ich verweilte eine Weile bei diesem Bild. Denn was ich beobachtete, war kein Produktivitätshack — es war der Design-to-Development-Workflow, der begann sich aufzulösen. Und ich denke, die meisten Produktteams haben das noch nicht gespürt, aber es wird kommen.

Hier ist, was ich aus der Beobachtung dieser Session mitgenommen habe, gefiltert durch meine eigene Erfahrung beim Bauen mit Claude Code. Ich werde ehrlich sein, wo dieser Workflow wirklich Dinge verändert und wo die aktuellen Einschränkungen zuschlagen, wenn man nicht aufpasst.

Es gibt einen bestimmten Moment im Implementierungsabschnitt, der meine Sicht auf den AI Planning Mode verändert hat. Behalte das im Hinterkopf beim Lesen.

Der Alte Workflow War Schon am Zerbrechen, Bevor KI Auftauchte

Lass mich den Design-to-Development-Handoff beschreiben, den die meisten Teams kennen. Ein Designer stellt Mockups in Figma fertig. Sie annotieren Abstände, Schriftgrößen, Interaktionszustände, Hover-Verhalten. Sie planen ein Handoff-Meeting. Der Developer stellt Fragen, die die Annotationen nicht abgedeckt haben. Es gibt ein Hin und Her. Ein Sprint beginnt. Der Developer baut etwas, das nah dran ist — aber nicht ganz. Es gibt einen Review-Zyklus. Mehr Hin und Her. Schließlich wird etwas ausgeliefert, das 80% dessen ist, was ursprünglich entworfen wurde.

Klingt vertraut?

Das Problem sind nicht die Menschen. Designer sind gut in ihrem Job. Developer sind gut in ihrem. Das Problem ist die Übersetzungsschicht dazwischen — die Lücke, in der Absicht verloren geht, Annahmen getroffen werden und Kontext während des Handoffs verdampft. Selbst mit Zeplin, InVision oder Figmas Developer Mode bewegt man immer noch eine statische Darstellung eines Designs in ein Medium, das dynamischen, responsiven, zustandsbehafteten Code benötigt.

Was Claude Code macht — und was Diane klar demonstrierte — ist, diese Übersetzungsschicht zum Einsturz zu bringen.

Wenn man Claude Code einen Design-Prompt gibt und es auf einer tatsächlichen Codebase arbeiten lässt, rät es nicht bei der Implementierung anhand eines Screenshots. Es liest die bestehende Code-Struktur, versteht die Komponentenhierarchie, weiß was bereits da ist, und generiert Änderungen, die zur bestehenden Architektur passen. Das ist qualitativ etwas anderes als generische Code-Generierung.

Die Unterscheidung ist wichtig. Generische Code-Generatoren produzieren Code, der richtig aussehen mag, aber nicht zu deinem Projekt passt. Claude Code — im Kontext arbeitend — produziert Code, der zu dem passt, was du bereits gebaut hast.

Aber bevor wir genau darauf eingehen, wie das in der Praxis funktioniert, musst du den spezifischen Tool-Stack verstehen, den Diane verwendet hat, und warum jede Wahl wichtig ist.

Der Drei-Tool-Stack, der Wirklich Zusammenarbeitet

Der Workshop drehte sich um drei Tools, die im Zusammenspiel arbeiteten. Ich habe alle drei unabhängig verwendet. Sie in einem bewussten Workflow kombiniert zu sehen, verdeutlichte, warum speziell diese Kombination mehr ist als die Summe ihrer Teile.

Cursor als Startumgebung. Cursor ist ein Code-Editor, der auf VS Code aufbaut, mit KI-Fähigkeiten, die auf IDE-Ebene eingebaut sind, anstatt als Erweiterung angeschraubt zu werden. Für Designer, die zum ersten Mal eine Coding-Umgebung betreten, ist das enorm wichtig. Die Oberfläche ist vertraut genug zum Navigieren, das Terminal ist zugänglich ohne einschüchternd zu sein, und das Klonen eines Repositories ist unkompliziert über die GUI.

Für den Workshop klonte Diane Andrej Karpathys LLM Council — ein Open-Source-Projekt, mit dem man mehrere KI-Modelle gleichzeitig abfragen kann, wobei diese Modelle die Antworten der anderen bewerten. Die Projektwahl war klug. Es ist eine echte Codebase in Produktionsqualität mit einer nicht-trivialen Struktur, keine Spielzeug-Tutorial-App. Mit etwas Echtem zu arbeiten ist der einzige Weg zu testen, ob ein Workflow wirklich standhält.

Claude Code als Intelligenzschicht. Das ist der Teil, der mich am meisten interessiert — und der Teil, wo ich die meiste direkte Erfahrung zum Vergleichen habe.

Claude Code generiert nicht einfach Code aus einer Beschreibung. Es liest. Es beginnt damit, die README zu scannen, die Projektstruktur zu verstehen, Dependencies zu identifizieren und zu prüfen, was bereits installiert ist. Bei einem frischen Repository kümmert es sich um die Installation von Dependencies, das Umgebungs-Setup und bringt das Projekt zum Laufen, bevor es ein einziges Design-Element anfasst.

Dieses kontextuelle Verständnis ist das, was generische Code-Generatoren vermissen. Als Diane Claude Code promptete, die LLM Council UI neu zu gestalten, generierte es keine neue Komponente von Grund auf und erwartete, dass sie es integriert. Es modifizierte die bestehenden Komponenten, in der bestehenden Dateistruktur, unter Verwendung der bestehenden Styling-Muster — während es die von ihr spezifizierte Design-Richtung anwendete.

Figma MCP für bidirektionale Synchronisation. Das Figma MCP (Multi-Component Plugin) ist die Brücke zwischen Design und Code, die diesen Workflow bidirektional macht. Nachdem Claude Code UI-Änderungen im Code generiert, können diese Änderungen zurück nach Figma synchronisiert werden — sodass Designer auf der Design-Ebene weiter verfeinern können, ohne manuell nachzuzeichnen, was generiert wurde. In Figma vorgenommene Bearbeitungen können dann in die Codebase zurückkommen.

Der ehrliche Vorbehalt hier: Diese bidirektionale Synchronisation ist in Konzept wirklich beeindruckend und in der Ausführung momentan unvollkommen. Token-Mapping, Komponentenbenennungskonventionen und responsives Verhalten übersetzen sich in keiner Richtung perfekt. Dianes Workshop brachte genau dies ans Licht — Live-Troubleshooting, sichtbare Einschränkungen, eine Echtzeit-Demonstration, dass dies noch kein gelöstes Problem ist. Ich komme darauf im Real-Talk-Abschnitt zurück.

Planning Mode — Der Teil, den die Meisten Überspringen

Hier ist der Moment, den ich am Anfang erwähnte und der verändert hat, wie ich Claude Code benutze.

Als Diane Claude Code promptete, die UI neu zu gestalten, feuerte sie nicht einfach den Prompt ab und wartete auf Code. Sie ließ es zuerst im Planning Mode laufen.

Planning Mode ist die Phase von Claude Code, in der es skizziert, was es zu tun beabsichtigt, bevor es irgendetwas tut. Es liest die relevanten Dateien, identifiziert was sich ändern muss, plant die Reihenfolge der Änderungen und — entscheidend — stellt klärende Fragen, wenn der Prompt Raum für Interpretation lässt.

Das ist keine Kleinigkeit. Die meisten Developer, die ich bei der Nutzung von KI-Coding-Tools beobachtet habe, springen direkt zur Ausführung. Sie feuern einen Prompt ab, bekommen Code, führen ihn aus, sehen dass er bricht, feuern einen weiteren Prompt zum Fixen und landen in einer Hin-und-Her-Korrekturschleife, die mehr Zeit frisst als den Code selbst zu schreiben.

Planning Mode durchbricht dieses Muster. Wenn die KI zuerst ihren Ansatz skizziert, fängt man Missverständnisse auf Plan-Ebene ab — bevor Code geändert wird. "Ich plane, die Header-Komponente zu modifizieren und ein neues Farbschema zur Tailwind-Konfiguration hinzuzufügen" ist etwas, das man in dreißig Sekunden bewerten und umlenken kann. Zu entdecken, dass die KI die falsche Komponente modifiziert hat, kostet nachträglich zehn Minuten Debugging und Rollback.

Aus dem Workshop-Zeitplan fand diese Planning-dann-Ausführung-Sequenz zwischen Minute 15 und 20 statt — das Segment, in dem die Teilnehmer die meisten "Aha"-Momente hatten. Zu beobachten, wie die KI eine klärende Frage zum Farbpalette stellte, bevor sie CSS anfasste, machte die Bedachtsamkeit auf eine Weise sichtbar, die eine einfache Vorher/Nachher-Demo nicht leistet.

Meine eigene Erfahrung stimmt damit überein. Bei einem kürzlichen Projekt nutzte ich Claude Codes Planning Mode, um eine Datentabellen-Komponente neu zu gestalten. Der Plan deckte auf, dass mein Prompt bezüglich Paginierung mehrdeutig war — sollte das neue Design serverseitige Paginierung beibehalten oder auf clientseitige umsteigen? Fünf Sekunden zur Klärung. Der resultierende Code war beim ersten Durchlauf korrekt. Ohne Planning Mode hätte ich Code bekommen, der einen Ansatz angenommen hätte, das Problem beim Testen entdeckt und Zeit mit Fixen verbracht.

Behandle Planning Mode als Pflicht, nicht als Option. Die zusätzlichen neunzig Sekunden am Anfang sparen ein Vielfaches davon bei jedem folgenden Schritt.

Den Workshop-Workflow Schritt für Schritt Durchgehen

Lass mich den tatsächlichen Workflow rekonstruieren, den Diane demonstrierte, mit der Art von Implementierungsdetail, das nützlich ist, wenn du es replizieren möchtest.

Schritt 1: Klone das Repository in Cursor.

# In Cursors integriertem Terminal
git clone https://github.com/karpathy/llm-council.git
cd llm-council

Für Designer, die noch nie ein Terminal benutzt haben, macht Cursors GUI dies weniger einschüchternd. Du kannst auch Cursors Command Palette zum Klonen verwenden — kein Terminal erforderlich.

Schritt 2: Lass Claude Code das Projekt lesen und einrichten.

Öffne Claude Code und gib ihm Kontext, bevor du etwas Design-bezogenes fragst:

Lies die README.md-Datei gründlich. Verstehe die Projektstruktur,
was diese Anwendung tut und welche Dependencies sie braucht. Installiere
dann die Dependencies und sage mir, was ich einrichten muss, um das
lokal auszuführen.

Claude Code wird die README scannen, den Stack identifizieren (im Fall von LLM Council ein Python-Backend mit einem JavaScript-Frontend), Dependencies über den angegebenen Package Manager installieren und fehlende Konfiguration aufzeigen — wie Umgebungsvariablen.

Schritt 3: Erstelle die .env-Datei.

LLM Council braucht, wie die meisten echten Projekte, API-Keys zum Laufen. Claude Code sagt dir genau, welche Variablen benötigt werden. Erstelle die .env-Datei im Projekt-Root:

# .env — diese Datei niemals committen
ANTHROPIC_API_KEY=dein_key_hier
OPENAI_API_KEY=dein_key_hier

Claude Code kümmert sich darum zu signalisieren, was benötigt wird. Du lieferst die tatsächlichen Keys. Das ist die richtige Arbeitsteilung — KI verwaltet die Konfigurationsform, du verwaltest die Geheimnisse.

Schritt 4: Starte das Projekt und verifiziere, dass es funktioniert.

# Starte das Backend
python app.py

# In einem separaten Terminal, starte das Frontend
npm run dev

Claude Code gibt dir die genauen Befehle basierend auf dem, was es aus den Scripts des Projekts gelesen hat. Sobald die App lokal läuft und du die originale UI sehen kannst, bist du bereit für Design-Änderungen zu prompten.

Schritt 5: Prompte für Design-Änderungen mit Planning Mode.

Das ist der entscheidende Schritt. Strukturiere deinen Design-Prompt, um Planning Mode explizit aufzurufen:

Bevor du Änderungen vornimmst, gehe in den Planning Mode. Ich möchte
die UI dieser Anwendung neu gestalten, wie es ein Weltklasse-
Produktdesigner tun würde. Die aktuelle UI ist funktional aber
visuell karg. Ich möchte:
- Ein dunkles, modernes Farbschema
- Verbesserte Typografie-Hierarchie
- Bessere Abstände und visuellen Rhythmus
- Klare visuelle Trennung zwischen Modellantworten

Plane zuerst deinen Ansatz. Liste jede Datei auf, die du ändern
willst und warum. Stelle mir klärende Fragen, bevor du beginnst.

Die Antwort der KI wird ein Überblick sein — etwa: "Ich plane, App.css für das globale Farbschema zu ändern, ModelResponse.jsx für das Antwortkarten-Layout zu aktualisieren, die Tailwind-Config für benutzerdefinierte Spacing-Werte anzupassen. Frage: Soll ich die bestehende Komponentenstruktur beibehalten oder eine Reorganisation vorschlagen?"

Du beantwortest die Frage. Dann genehmigst du den Plan. Dann erfolgt die Ausführung.

Schritt 6: Synchronisiere mit Figma über MCP.

Sobald die Code-Änderungen live sind und du mit der Richtung zufrieden bist, ermöglicht das Figma MCP-Plugin, diese Code-Änderungen in eine Figma-Datei zu ziehen. In der Praxis generiert dies Figma-Frames, die approximieren, was der Code rendert — nützlich zum Teilen mit Stakeholdern oder zur Fortsetzung der Design-Iteration in Figma.

Schritt 7: Nimm Figma-Bearbeitungen vor und pushe zurück zum Code.

Pixel-perfekte Anpassungen sind oft in Figma einfacher als in CSS. Nimm diese Bearbeitungen in Figma vor, dann nutze das MCP, um die Änderungen als Code-Modifikationen zurück zu exportieren. Claude Code kann diese dann in die bestehende Codebase einarbeiten.

Schritt 8: Committe und pushe deine Änderungen.

# Stage deine Änderungen
git add -A

# Committe mit einer aussagekräftigen Nachricht
git commit -m "redesign: wende modernes dunkles Theme auf LLM Council UI an"

# Pushe zu deinem Fork
git push origin main

Wenn du das Projekt geforkt hast, um unabhängige Änderungen zu machen — was Diane empfahl — geht dieser Push an deinen persönlichen Fork auf GitHub. Von dort hast du die Möglichkeit, einen Pull Request an das Originalprojekt zu öffnen, wenn die Änderungen es wert sind, beigetragen zu werden.

Wenn du diesen Workflow mental durchgegangen bist, verstehst du bereits etwas, wofür die meisten Leute drei Anläufe brauchen: Die KI designt nicht für dich. Sie implementiert eine Richtung, die du spezifizierst. Die Qualität dessen, was du bekommst, hängt fast vollständig von der Qualität ab, wie du promptest. Genau deshalb existiert die Planungsphase.

Jetzt der ehrliche Teil.

Was der Workshop Richtig Über die Einschränkungen Machte

Diane präsentierte dies nicht als gelösten Workflow. Das ist der Teil, den ich an der Session am meisten schätzte.

Die Figma MCP-Integration brachte echte Einschränkungen live auf dem Bildschirm ans Licht. Inkonsistenzen bei der Komponentenbenennung zwischen Codebase und Figma bedeuten, dass das, was in Figma importiert wird, nicht immer sauber auf deine bestehenden Design-System-Komponenten mappt. Token-Management — Design-Tokens für Farbe, Abstände und Typografie — synchronisiert sich in keiner Richtung zuverlässig. Du kannst eine grobe Annäherung von Code nach Figma bekommen, aber "pixel-perfekte bidirektionale Synchronisation" ist aspirative Marketingsprache, keine genaue Beschreibung, wo das Tooling heute steht.

Das Token-Problem ist das, was ich in der Praxis am frustrierendsten finde. Wenn deine Codebase eine benutzerdefinierte Tailwind-Config mit benannten Farb-Tokens verwendet und deine Figma-Datei ein passendes Design-System hat, würdest du erwarten, dass die Synchronisation diese Namen beibehält. Das tut sie oft nicht. Du landest bei Hex-Werten statt Token-Namen und Komponenten-Overrides statt Komponenten-Instanzen. Das manuell zu beheben macht einen Großteil der Zeitersparnis zunichte.

Meine ehrliche Einschätzung: Behandle Figma-zu-Code und Code-zu-Figma Synchronisation als einen "nah genug um weiterzumachen"-Schritt, nicht als einen "präzise akkurat"-Schritt. Nutze es, um Richtung zu kommunizieren und in die Nähe des richtigen Designs zu kommen. Erwarte nicht, dass es gewissenhafte Design-System-Disziplin ersetzt.

Die andere Einschränkung, die es wert ist, benannt zu werden: Claude Codes Kontextfenster. Bei großen Codebases — Zehntausende Zeilen über Dutzende von Dateien verteilt — kann Claude Code mitten in einer Session den Projektkontext verlieren. Die Planungsphase mildert dies etwas ab, weil der Plan als Anker fungiert. Aber bei sehr großen Projekten wirst du bemerken, dass die KI Vorschläge macht, die früheren Entscheidungen in derselben Session widersprechen. Wenn das passiert, bringt das Wiederherstellen des Kontexts mit einem Zusammenfassungsprompt es normalerweise wieder auf Kurs.

Keine dieser Einschränkungen macht den Workflow weniger wertvoll. Sie machen ihn zu einem Workflow, der eine erfahrene Hand braucht, um die Lücken aufzufangen — was genau das ist, was Dianes Session demonstrierte. Sie lief live in das MCP-Problem und handhabte es, indem sie erklärte, was passierte und warum. Das ist das richtige Modell: Verstehe die Grenzen des Tools, arbeite innerhalb dieser Grenzen und lass dich von Randfällen nicht ablenken von dem, was der Workflow gut macht.

Was Dies Tatsächlich für Produktteams Ändert

Der Workshop widmete seine abschließende Q&A einer Frage, die ich für die interessanteste halte: Was passiert mit Rollen, wenn dies Mainstream wird?

Dianes Framing: Die Grenzen zwischen Product Managern, Designern und Engineers verschwimmen. PMs prototypen direkt. Designer schreiben — oder generieren zumindest — Code. Engineers bleiben auf Engineering fokussiert, aber engagieren sich früher im Prozess bei Design-Entscheidungen und PRDs.

Ich habe gesehen, wie das in Teams beginnt, mit denen ich gearbeitet habe, und ich würde etwas Nuance hinzufügen.

Das Verschwimmen ist real. Aber es ist nicht einheitlich. Was KI-Tools wie Claude Code ermöglichen, ist, dass Spezialisten weiter in angrenzende Gebiete vordringen können, ohne zu Generalisten zu werden. Ein Designer ohne Coding-Hintergrund kann jetzt einen funktionierenden Prototyp generieren, ihn im Browser evaluieren, daran iterieren und etwas teilen, das näher am Endergebnis ist als jedes Mockup. Das macht sie nicht zum Engineer. Es macht sie zu jemandem, dessen Design-Entscheidungen jetzt davon informiert sind, wie sich laufender Code tatsächlich anfühlt.

Der Downstream-Effekt: Design-Reviews ändern sich. Anstatt ein statisches Mockup in Figma zu reviewen und sich vorzustellen, wie es sich im Browser anfühlt, reviewt man etwas, mit dem man tatsächlich interagieren kann. Feedback wird spezifischer, fundierter und umsetzbarer. "Dieser Button fühlt sich auf Mobil zu klein an" ersetzt "Ich bin mir bei diesem Button nicht sicher" — weil man vor dem Review auf Mobil testen kann.

Für Engineers ist die Veränderung subtiler, aber genauso real. Wenn Designer beim Handoff mit funktionierendem Code statt Mockups ankommen, verschiebt sich das Engineering-Gespräch von "Können wir das bauen?" zu "Wie machen wir das produktionsreif?" Das ist ein besseres Gespräch. Es überspringt die Übersetzungsschicht komplett.

Die cross-funktionale Fähigkeit, die essentiell wird — und ich würde jeden in Produktteams ermutigen, diese zu entwickeln — ist zu wissen, wie man promptet. Nicht wie man codet. Nicht wie man designt. Wie man Absicht klar genug artikuliert, damit eine KI sie akkurat ausführen kann. Das ist eine Disziplin. Es erfordert Übung. Die Menschen, die dies früh entwickeln, werden einen bedeutenden Vorteil gegenüber denen haben, die KI-Tools als Zauberkästen behandeln.

Meine Ergebnisse Nach der Anwendung Dieses Workflows

Am Wochenende nach dem Anschauen dieses Workshops wendete ich den Design-zu-Code-Workflow auf ein Kundenprojekt an — eine Dashboard-Anwendung, die drei Wochen im Design-Limbo gesteckt hatte, weil Designer und Developer sich nicht auf die Komponentenstruktur einigen konnten.

Ich klonte die bestehende Codebase in Cursor, gab Claude Code Kontext über das Projekt und promptete es dann, das Dashboard-Layout zu generieren, das der Designer in Figma gemockt hatte. Planning Mode brachte eine sofortige Frage hervor: Sollte das neue Layout die bestehende CSS-Modul-Struktur verwenden oder auf Tailwind umsteigen? Eine Klärung. Der Plan wurde aktualisiert. Die Ausführung begann.

Fünfundvierzig Minuten später hatte der Developer einen funktionierenden Prototyp im Browser, der 85% des Figma-Mockups entsprach. Nicht pixel-perfekt. Aber nah genug, dass das restliche Review-Gespräch über spezifische Anpassungen ging statt über fundamentale Abstimmungsfragen. Wir lieferten die erste Version zwei Tage später aus.

Verglichen mit dem Sprint, in dem das gelegen hatte: drei Wochen vs. zwei Tage.

Die ehrliche Version: Die 15%-Lücke brauchte noch Handarbeit. Die Figma MCP-Synchronisation fügte etwa dreißig Minuten Aufräumarbeit hinzu, um die Figma-Datei zu aktualisieren, damit sie widerspiegelte, was tatsächlich im Code war. Und Claude Codes erster Durchlauf bei den Datenvisualisierungs-Komponenten brauchte einen zweiten Prompt, um das responsive Verhalten auf kleineren Bildschirmen richtig hinzubekommen. Nichts davon war überraschend. Alles war schneller als die Alternative.

Was zu messen ist, wenn du dies versuchst: Zeit von der Design-Genehmigung bis zum funktionierenden Prototyp (Ziel: unter 4 Stunden für ein einzelnes Feature), Anzahl der Design-Review-Zyklen vor Developer-Handoff (Ziel: 1, nicht 3), und wie oft die Design-Absicht den Handoff intakt übersteht (verfolge Meinungsverschiedenheiten zwischen Design-Spec und ausgeliefertem Feature — sie sollten abnehmen).

Eine Sache, die du vor Deinem Nächsten Design-Handoff Tun Solltest

Wähle ein Feature. Eines — nicht dein gesamtes Design-System, nicht ein komplettes Seiten-Redesign. Eine einzelne Komponente oder Sektion, die in Figma auf Entwicklung wartet.

Klone deine Codebase in Cursor. Öffne Claude Code. Gib ihm Kontext über das Projekt und prompte es dann, das Design aus deiner Figma-Beschreibung zu implementieren. Nutze Planning Mode. Lass die KI ihre Fragen stellen. Genehmige den Plan. Beobachte, was passiert.

Du wirst unvollkommenen Output bekommen. Das ist in Ordnung. Der Sinn dieser Übung ist nicht, beim ersten Prompt auszuliefern. Der Sinn ist zu sehen, wie groß deine aktuelle Design-zu-Entwicklung-Lücke tatsächlich ist, und zu spüren, wie es sich anfühlt, im Code zu iterieren statt in Mockups.

Die Teams, die in den nächsten drei Jahren die besten Produkte bauen werden, sind nicht die mit den meisten Designern oder den meisten Developern. Es sind die, die herausgefunden haben, wie man Design und Entwicklung zu einem einzigen, kontinuierlichen, KI-beschleunigten Gespräch macht — mit Claude Code irgendwo in der Mitte.

Das traditionelle Handoff-Dokument hatte einen guten Lauf. Sein Ersatz ist bereits hier.

🤝 Lass Uns Zusammenarbeiten

Du möchtest KI-Systeme bauen, Workflows automatisieren oder deine technische Infrastruktur skalieren? Ich helfe gerne.

• 🔗 Fiverr (Maßanfertigungen & Integrationen): fiverr.com/s/EgxYmWD
• 🌐 Portfolio: mejba.me
• 🏢 Ramlit Limited (Enterprise-Lösungen): ramlit.com
• 🎨 ColorPark (Design & Branding): colorpark.io
• 🛡 xCyberSecurity (Sicherheitsdienste): xcybersecurity.io