Van Ontwerp naar Code met AI: Claude Code Verandert Alles
Er verschoof iets tijdens een recente workshop. Ik heb genoeg design reviews, sprint planningen en developer handoff-sessies bijgewoond om te weten wanneer een workflow-verandering cosmetisch is — en wanneer het structureel is. Dit was structureel.
Diane, CEO en mede-oprichter van The Design Project, had Cursor open aan de linkerkant, Figma aan de rechterkant, en Claude Code draaiend ertussenin. Ze typte een prompt — "redesign deze UI zoals een wereldklasse productontwerper dat zou doen" — en keek hoe de AI de hele codebase las, zijn plan schetste, één verduidelijkende vraag stelde, en vervolgens bestanden begon te wijzigen.
Geen handoff-document. Geen geannoteerd mockup. Geen Jira-ticket dat twee weken in de backlog van een developer lag. Gewoon een ontwerper die echte front-end code genereerde via een AI die de projectcontext begreep.
Ik bleef even bij dat beeld stilstaan. Want wat ik zag was geen productiviteitshack — het was de ontwerp-naar-ontwikkeling workflow die begon op te lossen. En ik denk dat de meeste productteams dat nog niet gevoeld hebben, maar dat komt nog.
Dit is wat ik meennam uit het bekijken van die sessie, gefilterd door mijn eigen ervaring met bouwen met Claude Code. Ik zal eerlijk zijn over waar deze workflow echt dingen verandert en waar de huidige beperkingen je zullen bijten als je niet oppast.
Er is een specifiek moment in het implementatiegedeelte dat mijn kijk op AI planning mode heeft veranderd. Houd dat in gedachten terwijl je leest.
De Oude Workflow Was Al aan het Breken Voordat AI Verscheen
Laat me de ontwerp-naar-ontwikkeling handoff beschrijven die de meeste teams kennen. Een ontwerper maakt mockups af in Figma. Ze annoteren spacing, lettergroottes, interactietoestanden, hover-gedrag. Ze plannen een handoff-meeting. De developer stelt vragen die de annotaties niet dekten. Er is heen-en-weer. Een sprint begint. De developer bouwt iets dat dichtbij komt — maar niet helemaal. Er is een review-cyclus. Meer heen-en-weer. Uiteindelijk wordt er iets geleverd dat 80% is van wat oorspronkelijk ontworpen was.
Klinkt bekend?
Het probleem zijn niet de mensen. Ontwerpers zijn goed in hun werk. Developers zijn goed in het hunne. Het probleem is de vertaallaag ertussen — de kloof waar intentie verloren gaat, aannames worden gemaakt en context verdampt tijdens de handoff. Zelfs met Zeplin, InVision of de developer mode van Figma verplaats je nog steeds een statische weergave van een ontwerp naar een medium dat dynamische, responsive, stateful code nodig heeft.
Wat Claude Code doet — en wat Diane duidelijk demonstreerde — is die vertaallaag laten samenvouwen.
Wanneer je Claude Code een ontwerpprompt geeft en het laat werken op een echte codebase, raadt het niet naar een implementatie vanuit een screenshot. Het leest de bestaande codestructuur, begrijpt de componenthiërarchie, weet wat er al is, en genereert wijzigingen die passen bij de bestaande architectuur. Dat is kwalitatief iets anders dan generieke codegeneratie.
Het onderscheid doet ertoe. Generieke codegenerators produceren code die er misschien goed uitziet maar niet bij je project past. Claude Code — werkend in context — produceert code die past bij wat je al hebt gebouwd.
Maar voordat we precies ingaan op hoe dit in de praktijk werkt, moet je de specifieke tool-stack begrijpen die Diane gebruikte en waarom elke keuze ertoe doet.
De Drie-Tool Stack Die Echt Samenwerkt
De workshop draaide om drie tools die in concert werkten. Ik heb alle drie onafhankelijk gebruikt. Ze gecombineerd zien in een bewuste workflow verduidelijkte waarom specifiek deze combinatie meer is dan de som der delen.
Cursor als startomgeving. Cursor is een code-editor gebouwd op VS Code, met AI-mogelijkheden ingebouwd op IDE-niveau in plaats van erop geschroefd als extensie. Voor ontwerpers die voor het eerst een codeeromgeving betreden, doet dit er enorm toe. De interface is vertrouwd genoeg om te navigeren, de terminal is toegankelijk zonder intimiderend te zijn, en het klonen van een repository is eenvoudig via de GUI.
Voor de workshop kloonde Diane Andrej Karpathy's LLM Council — een open-source project waarmee je meerdere AI-modellen tegelijk kunt bevragen, waarbij die modellen elkaars antwoorden beoordelen. De keuze van het project was slim. Het is een echte, productiekwaliteit codebase met een niet-triviale structuur, geen speelgoed-tutorial-app. Werken met iets echts is de enige manier om te testen of een workflow echt standhoudt.
Claude Code als intelligentielaag. Dit is het deel waar ik het meest om geef — en het deel waar ik de meeste directe ervaring heb om mee te vergelijken.
Claude Code genereert niet zomaar code vanuit een beschrijving. Het leest. Het begint met het scannen van de README, het begrijpen van de projectstructuur, het identificeren van dependencies, het controleren wat er al geïnstalleerd is. Op een verse repository handelt het de installatie van dependencies af, de omgevingsopzet, en krijgt het project draaiend voordat het een enkel ontwerpelement aanraakt.
Dat contextuele begrip is wat generieke codegenerators missen. Toen Diane Claude Code promptte om de LLM Council UI te herontwerpen, genereerde het geen nieuw component vanuit het niets met de verwachting dat zij het zou integreren. Het wijzigde de bestaande componenten, in de bestaande bestandsstructuur, met de bestaande styling-patronen — terwijl het de ontwerprichting toepaste die zij specificeerde.
Figma MCP voor bidirectionele synchronisatie. De Figma MCP (Multi-Component Plugin) is de brug tussen ontwerp en code die deze workflow bidirectioneel maakt. Nadat Claude Code UI-wijzigingen in code genereert, kunnen die wijzigingen terug naar Figma synchroniseren — zodat ontwerpers kunnen blijven verfijnen op de ontwerplag zonder handmatig opnieuw te tekenen wat gegenereerd was. Bewerkingen in Figma kunnen dan terugkomen in de codebase.
De eerlijke kanttekening hier: deze bidirectionele synchronisatie is oprecht indrukwekkend in concept en onvolmaakt in uitvoering op dit moment. Token-mapping, component-naamgevingsconventies en responsive gedrag vertalen niet perfect in beide richtingen. Diane's workshop bracht precies dit aan het licht — live troubleshooten, zichtbare beperkingen, een real-time demonstratie dat dit nog geen opgelost probleem is. Ik kom hier op terug in het Real Talk gedeelte.
Planning Mode — Het Deel Dat de Meeste Mensen Overslaan
Hier is het moment dat ik aan het begin noemde en dat veranderde hoe ik Claude Code gebruik.
Toen Diane Claude Code promptte om de UI te herontwerpen, vuurde ze niet simpelweg de prompt af en wachtte op code. Ze liet het eerst in planning mode draaien.
Planning mode is de fase van Claude Code waarin het schetst wat het van plan is te doen voordat het iets doet. Het leest de relevante bestanden, identificeert wat er moet veranderen, brengt de volgorde van wijzigingen in kaart, en — cruciaal — stelt verduidelijkende vragen als de prompt ruimte laat voor interpretatie.
Dit is niet iets kleins. De meeste developers die ik AI-codeertools heb zien gebruiken, gaan direct naar uitvoering. Ze vuren een prompt af, krijgen code, draaien het, zien dat het breekt, vuren een nieuwe prompt om het te fixen, en belanden in een heen-en-weer correctielus die meer tijd kost dan de code zelf schrijven.
Planning mode doorbreekt dat patroon. Wanneer de AI eerst zijn aanpak schetst, vang je misverstanden op planniveau — voordat er code veranderd is. "Ik ben van plan het Header-component aan te passen en een nieuw kleurenschema toe te voegen aan de Tailwind-config" is iets dat je in dertig seconden kunt evalueren en bijsturen. Ontdekken dat de AI het verkeerde component heeft aangepast achteraf kost je tien minuten debugging en rollback.
Vanuit de workshop-tijdlijn vond deze planning-dan-uitvoering sequentie plaats tussen minuut 15 en 20 — het segment waar deelnemers de meeste "aha"-momenten hadden. Kijken hoe de AI een verduidelijkende vraag stelde over het kleurenpalet voordat het CSS aanraakte, maakte de bedachtzaamheid zichtbaar op een manier die een eenvoudige voor/na-demo niet doet.
Mijn eigen ervaring komt hiermee overeen. Bij een recent project gebruikte ik de planning mode van Claude Code om een datatabel-component te herontwerpen. Het plan bracht aan het licht dat mijn prompt ambigu was over paginering — moest het nieuwe ontwerp server-side paginering behouden of overschakelen naar client-side? Vijf seconden om te verduidelijken. De resulterende code was correct bij de eerste poging. Zonder planning mode had ik code gekregen die één benadering aannam, het probleem ontdekt bij het testen, en tijd besteed aan het fixen.
Behandel planning mode als verplicht, niet optioneel. De extra negentig seconden die het aan het begin toevoegt, bespaart een veelvoud daarvan bij elke volgende stap.
De Workshop Workflow Stap voor Stap Doorlopen
Laat me de daadwerkelijke workflow reconstrueren die Diane demonstreerde, met het soort implementatiedetail dat nuttig is als je het wilt repliceren.
Stap 1: Kloon de repository naar Cursor.
# In Cursor's geïntegreerde terminal
git clone https://github.com/karpathy/llm-council.git
cd llm-council
Voor ontwerpers die nog nooit een terminal hebben gebruikt, maakt Cursor's GUI dit minder intimiderend. Je kunt ook Cursor's command palette gebruiken om te klonen — geen terminal nodig.
Stap 2: Laat Claude Code het project lezen en opzetten.
Open Claude Code en geef het context voordat je iets ontwerp-gerelateerds vraagt:
Lees het README.md bestand grondig. Begrijp de projectstructuur,
wat deze applicatie doet, en welke dependencies het nodig heeft.
Installeer vervolgens de dependencies en vertel me wat ik moet
instellen om dit lokaal te draaien.
Claude Code scant de README, identificeert de stack (in het geval van LLM Council, een Python-backend met een JavaScript-frontend), installeert dependencies via de opgegeven package manager, en signaleert eventuele ontbrekende configuratie — zoals omgevingsvariabelen.
Stap 3: Maak het .env-bestand aan.
LLM Council heeft, zoals de meeste echte projecten, API-keys nodig om te draaien. Claude Code vertelt je precies welke variabelen nodig zijn. Maak het .env-bestand aan in de project root:
# .env — commit dit bestand nooit
ANTHROPIC_API_KEY=jouw_key_hier
OPENAI_API_KEY=jouw_key_hier
Claude Code regelt het signaleren van wat nodig is. Jij levert de daadwerkelijke keys. Dit is de juiste taakverdeling — AI beheert de configuratievorm, jij beheert de geheimen.
Stap 4: Draai het project en verifieer dat het werkt.
# Start de backend
python app.py
# In een aparte terminal, start de frontend
npm run dev
Claude Code geeft je de exacte commando's op basis van wat het las uit de scripts van het project. Zodra de app lokaal draait en je de originele UI kunt zien, ben je klaar om te prompten voor ontwerpwijzigingen.
Stap 5: Prompt voor ontwerpwijzigingen met planning mode.
Dit is de cruciale stap. Structureer je ontwerpprompt om planning mode expliciet aan te roepen:
Voordat je wijzigingen aanbrengt, ga in planning mode. Ik wil
de UI van deze applicatie herontwerpen zoals een wereldklasse
productontwerper dat zou doen. De huidige UI is functioneel
maar visueel karig. Ik wil:
- Een donker, modern kleurenschema
- Verbeterde typografie-hiërarchie
- Betere spacing en visueel ritme
- Duidelijke visuele scheiding tussen modelreacties
Plan eerst je aanpak. Noem elk bestand dat je wilt wijzigen
en waarom. Stel me eventuele verduidelijkende vragen voordat
je begint.
Het antwoord van de AI is een overzicht — zoiets als: "Ik ben van plan App.css te wijzigen voor het globale kleurenschema, ModelResponse.jsx bij te werken voor de layout van de antwoordkaarten, de Tailwind-config aan te passen voor aangepaste spacing-waarden. Vraag: moet ik de bestaande componentstructuur behouden of een reorganisatie voorstellen?"
Je beantwoordt de vraag. Dan keur je het plan goed. Dan volgt de uitvoering.
Stap 6: Synchroniseer naar Figma met MCP.
Zodra de codewijzigingen live zijn en je tevreden bent met de richting, kun je met de Figma MCP-plugin die codewijzigingen naar een Figma-bestand trekken. In de praktijk genereert dit Figma-frames die benaderen wat de code rendert — nuttig om te delen met stakeholders of om door te gaan met design-iteratie in Figma.
Stap 7: Maak Figma-bewerkingen en push terug naar code.
Pixel-perfecte aanpassingen zijn vaak makkelijker in Figma dan in CSS. Maak die bewerkingen in Figma, gebruik dan de MCP om de wijzigingen terug te exporteren als codeaanpassingen. Claude Code kan die dan opnemen in de bestaande codebase.
Stap 8: Commit en push je wijzigingen.
# Stage je wijzigingen
git add -A
# Commit met een betekenisvol bericht
git commit -m "redesign: pas modern donker thema toe op LLM Council UI"
# Push naar je fork
git push origin main
Als je het project hebt geforkt om onafhankelijke wijzigingen te maken — wat Diane aanbeval — gaat deze push naar je persoonlijke fork op GitHub. Van daaruit heb je de optie om een pull request te openen naar het originele project als de wijzigingen het waard zijn om bij te dragen.
Als je die workflow mentaal hebt gevolgd, begrijp je al iets waar de meeste mensen drie pogingen voor nodig hebben: de AI ontwerpt niet voor jou. Het implementeert een richting die jij specificeert. De kwaliteit van wat je krijgt hangt bijna volledig af van de kwaliteit van hoe je prompt. Dat is precies waarom de planningsfase bestaat.
Nu het eerlijke deel.
Wat de Workshop Goed Deed aan de Beperkingen
Diane presenteerde dit niet als een opgeloste workflow. Dat is het deel dat ik het meest waardeerde aan de sessie.
De Figma MCP-integratie bracht echte beperkingen live op het scherm aan het licht. Inconsistenties in componentnaamgeving tussen de codebase en Figma betekenen dat wat in Figma geïmporteerd wordt niet altijd netjes mapt naar je bestaande design system-componenten. Tokenbeheer — design tokens voor kleur, spacing en typografie — synchroniseert nog niet betrouwbaar in beide richtingen. Je kunt een ruwe benadering krijgen van code naar Figma, maar "pixel-perfecte bidirectionele synchronisatie" is aspiratieve marketingtaal, geen accurate beschrijving van waar de tooling vandaag staat.
Het tokenprobleem is het meest frustrerend in de praktijk. Als je codebase een aangepaste Tailwind-config gebruikt met benoemde kleurtokens, en je Figma-bestand een bijpassend design system heeft, zou je verwachten dat de synchronisatie die namen behoudt. Dat doet het vaak niet. Je eindigt met hex-waarden in plaats van tokennamen, en component-overrides in plaats van component-instances. Dit handmatig fixen maakt veel van de tijdsbesparing ongedaan.
Mijn eerlijke mening: behandel Figma-naar-code en code-naar-Figma synchronisatie als een "dichtbij genoeg om door te gaan" stap, niet als een "precies accuraat" stap. Gebruik het om richting te communiceren en in de buurt te komen van het juiste ontwerp. Verwacht niet dat het nauwgezette design system-discipline vervangt.
De andere beperking die het benoemen waard is: het contextvenster van Claude Code. Bij grote codebases — tienduizenden regels verspreid over tientallen bestanden — kan Claude Code halverwege een sessie de projectcontext kwijtraken. De planningsfase verzacht dit enigszins, omdat het plan als anker fungeert. Maar bij zeer grote projecten merk je dat de AI suggesties doet die eerdere beslissingen in dezelfde sessie tegenspreken. Als dat gebeurt, brengt het herstellen van context met een samenvattingsprompt het meestal weer op de rails.
Geen van deze beperkingen maakt de workflow minder waardevol. Ze maken het een workflow die een ervaren hand nodig heeft om de gaten op te vangen — wat precies is wat Diane's sessie demonstreerde. Ze liep live tegen het MCP-probleem aan en handelde het af door uit te leggen wat er gebeurde en waarom. Dat is het juiste model: begrijp de grenzen van de tool, werk erbinnen, en laat de randgevallen je niet afleiden van wat de workflow goed doet.
Wat Dit Echt Verandert voor Productteams
De workshop besteedde zijn afsluitende Q&A aan een vraag die ik de meest interessante vind: wat gebeurt er met rollen wanneer dit mainstream wordt?
Diane's framing: de grenzen tussen Product Managers, ontwerpers en engineers vervagen. PM's prototypen direct. Ontwerpers schrijven — of genereren tenminste — code. Engineers blijven gefocust op engineering, maar betrekken zich eerder bij ontwerpbeslissingen en PRD's in het proces.
Ik heb dit zien beginnen in teams waar ik mee heb gewerkt, en ik zou wat nuance toevoegen.
De vervaging is echt. Maar het is niet uniform. Wat AI-tools zoals Claude Code mogelijk maken is dat specialisten verder kunnen stappen in aangrenzende gebieden zonder generalisten te worden. Een ontwerper zonder programmeerervaring kan nu een werkend prototype genereren, het evalueren in de browser, erop itereren, en iets delen dat dichter bij het eindresultaat ligt dan welk mockup dan ook. Dat maakt hen geen engineer. Het maakt hen iemand wiens ontwerpbeslissingen nu worden geïnformeerd door hoe draaiende code daadwerkelijk aanvoelt.
Het downstream-effect: design reviews veranderen. In plaats van een statisch mockup in Figma te reviewen en je voor te stellen hoe het voelt in de browser, review je iets waarmee je daadwerkelijk kunt interacteren. Feedback wordt specifieker, meer gefundeerd en meer uitvoerbaar. "Deze knop voelt klein aan op mobiel" vervangt "Ik weet niet zeker over deze knop" — omdat je op mobiel kunt testen vóór de review.
Voor engineers is de verandering subtieler maar even echt. Wanneer ontwerpers aankomen bij een handoff met werkende code in plaats van mockups, verschuift het engineering-gesprek van "kunnen we dit bouwen?" naar "hoe maken we dit productierijp?" Dat is een beter gesprek. Het slaat de vertaallaag volledig over.
De cross-functionele vaardigheid die essentieel wordt — en ik zou iedereen in productteams aanmoedigen dit te ontwikkelen — is weten hoe je moet prompten. Niet hoe je moet coderen. Niet hoe je moet ontwerpen. Hoe je intentie duidelijk genoeg verwoordt zodat een AI het nauwkeurig kan uitvoeren. Dat is een discipline. Het vergt oefening. De mensen die dit vroeg ontwikkelen zullen een betekenisvol voordeel hebben ten opzichte van degenen die AI-tools behandelen als magische dozen.
Mijn Resultaten Na Het Toepassen van Deze Workflow
Het weekend na het bekijken van deze workshop paste ik de ontwerp-naar-code workflow toe op een klantproject — een dashboard-applicatie die drie weken in ontwerp-limbo had gestaan omdat de ontwerper en developer het niet eens konden worden over de componentstructuur.
Ik kloonde de bestaande codebase naar Cursor, gaf Claude Code context over het project, en promptte het vervolgens om de dashboard-layout te genereren die de ontwerper had gemockt in Figma. Planning mode bracht een directe vraag aan het licht: moet de nieuwe layout de bestaande CSS module-structuur gebruiken of overschakelen naar Tailwind? Eén verduidelijking. Het plan werd bijgewerkt. De uitvoering begon.
Vijfenveertig minuten later had de developer een werkend prototype in de browser dat 85% van het Figma-mockup matchte. Niet pixel-perfect. Maar dichtbij genoeg dat het resterende reviewgesprek ging over specifieke aanpassingen in plaats van fundamentele afstemmingsvragen. We leverden de eerste versie twee dagen later.
Vergeleken met de sprint waar dit had liggen: drie weken vs. twee dagen.
De eerlijke versie: de 15% kloof had nog handmatige bewerking nodig. De Figma MCP-synchronisatie voegde ongeveer dertig minuten opschoning toe om het Figma-bestand bij te werken zodat het weerspiegelde wat daadwerkelijk in code stond. En de eerste poging van Claude Code op de datavisualisatie-componenten had een tweede prompt nodig om het responsive gedrag goed te krijgen op kleinere schermen. Niets daarvan was verrassend. Alles was sneller dan het alternatief.
Wat te meten als je dit probeert: tijd van ontwerpgoedkeuring tot werkend prototype (doel: minder dan 4 uur voor een enkele functie), aantal design review-cycli vóór developer handoff (doel: 1, niet 3), en hoe vaak de ontwerpintentie de handoff intact overleeft (volg meningsverschillen tussen ontwerpspec en geleverde functie — ze zouden moeten afnemen).
Eén Ding om te Doen Vóór Je Volgende Design Handoff
Kies één functie. Eén — niet je hele design system, niet een volledige pagina-herontwerp. Een enkel component of sectie dat in Figma zit te wachten op ontwikkeling.
Kloon je codebase naar Cursor. Open Claude Code. Geef het context over het project, en prompt het dan om het ontwerp te implementeren vanuit je Figma-beschrijving. Gebruik planning mode. Laat de AI zijn vragen stellen. Keur het plan goed. Kijk wat er gebeurt.
Je krijgt onvolmaakte output. Dat is prima. Het punt van deze oefening is niet om te leveren vanuit de eerste prompt. Het punt is om te zien hoe groot je huidige ontwerp-naar-ontwikkeling kloof werkelijk is, en om te voelen hoe het is om te itereren in code in plaats van mockups.
De teams die de beste producten gaan bouwen in de komende drie jaar zijn niet degenen met de meeste ontwerpers of de meeste developers. Het zijn degenen die erachter kwamen hoe ze ontwerp en ontwikkeling in één doorlopend, AI-versneld gesprek konden omzetten — met Claude Code ergens in het midden daarvan.
Het traditionele handoff-document heeft een goede tijd gehad. Zijn vervanger is er al.
🤝 Laten We Samenwerken
Op zoek naar het bouwen van AI-systemen, het automatiseren van workflows, of het opschalen van je technische infrastructuur? Ik help graag.
- 🔗 Fiverr (maatwerk builds & integraties): fiverr.com/s/EgxYmWD
- 🌐 Portfolio: mejba.me
- 🏢 Ramlit Limited (enterprise-oplossingen): ramlit.com
- 🎨 ColorPark (design & branding): colorpark.io
- 🛡 xCyberSecurity (beveiligingsdiensten): xcybersecurity.io
