23 jul 2025·8 min
Hoe AI lay-out en intentie leest om ontwerpen om te zetten in UI-code
Leer hoe AI lay-out, hiërarchie en gebruikersintentie uit ontwerpen afleidt en UI-code genereert—plus beperkingen, beste praktijken en reviewtips.
Leer hoe AI lay-out, hiërarchie en gebruikersintentie uit ontwerpen afleidt en UI-code genereert—plus beperkingen, beste praktijken en reviewtips.
“Design to code” AI zet een visueel ontwerpidee—meestal een Figma-frame of een screenshot—om in uitvoerbare UI-code. Het doel is geen “perfecte code”, maar een bruikbare eerste versie die structuur, styling en basisgedrag vastlegt zodat een mens het kan verfijnen.
In de kern mappt het systeem wat het kan waarnemen naar hoe UI’s gewoonlijk zijn opgebouwd.
AI kan veelvoorkomende patronen afleiden: een rij pictogrammen is waarschijnlijk een toolbar; een gestapelde label + input is waarschijnlijk een formulierveld; consistente styling wijst op een herbruikbaar component. Het kan ook responsief gedrag raden op basis van constraints en spacing.
Maar je moet meestal specificeren wat pixels niet kunnen garanderen: echte componentnamen, design tokens (kleuren/typografie), statussen (hover/disabled/error), breakpoints, dataregels en daadwerkelijke interacties (validatie, navigatiedoelen, analytics).
Zie de output als een startpunt. Verwacht dat je structuur controleert, ad-hoc stijlen vervangt door tokens, afstemt op je componentbibliotheek en iteratief verbetert. “Design to code” versnelt het werk—het automatiseert niet het oordeel van ontwerpers en engineers.
AI kan geen productregels afleiden uit een “mooie scherm”. Het werkt met het bewijs dat je levert—sommige inputs beschrijven pixels, andere beschrijven structuur. Dat verschil bepaalt vaak of je schone UI-code krijgt of kwetsbare absolute positionering.
Een screenshot is de zuinigste input: het bevat kleuren en vormen, maar geen expliciete feiten over wat een knop is versus een label, wat herbruikbaar is of hoe de lay-out zich moet aanpassen.
Alleen op pixels moet AI grenzen raden (waar eindigt het ene element en begint het andere), tekststijlen, spacingregels en zelfs of een “kaart” één component is of meerdere losse stukken. Het kan ook geen constraints afleiden—dus responsief gedrag is grotendeels giswerk.
Wanneer AI toegang heeft tot het ontwerpbestand (of een export die structuur bewaart), krijgt het cruciale metadata: frames, groepen, laagnamen, Auto Layout-instellingen, constraints en tekst-/stijldefinities.
Hier wordt lay-out meer dan geometrie. Bijvoorbeeld, een Figma-frame met Auto Layout communiceert intentie zoals “stapel deze items verticaal met 16px gap” veel beter dan een screenshot. Consistente laagnamen helpen ook bij het mappen van elementen naar UI-rollen (bijv. “Primary Button”, “Nav Item”, “Input/Error”).
Een aangesloten designsystem vermindert giswerk. Tokens (kleuren, spacing, typografie) laten AI code genereren die verwijst naar een gedeelde bron in plaats van hard-coded waarden. Gepubliceerde componenten (knoppen, velden, modals) leveren kant-en-klare bouwstenen en duidelijkere grenzen voor hergebruik.
Zelfs kleine conventies—zoals variantnamen (Button/Primary, Button/Secondary) en semantische tokens (text/primary in plaats van #111111)—verbeteren componentmapping.
Specificaties voegen het “waarom” achter de UI toe: hover-gedrag, loading- en emptystates, validatieregels, toetsenbordgedrag en foutmeldingen.
Zonder dit genereert AI vaak een statische snapshot. Met zulke specs kan de output interactiehooks, state-handling en realistischere component-API's bevatten—dichter bij iets wat een team kan uitrollen en onderhouden.
Design-to-code tools nemen een scherm niet waar zoals een mens; ze proberen elke laag uit te leggen als lay-outregels: rijen, kolommen, containers en spacing. Hoe duidelijker die regels zijn, hoe minder de output leunt op kwetsbare positionering.
De meeste modellen zoeken naar herhaalde uitlijning en gelijke marges. Als meerdere elementen dezelfde linkerzijde, baseline of middellijn delen, ziet AI ze vaak als een kolom of gridtrack. Consistente spacing (bijv. 8/16/24px-patronen) wijst erop dat lay-out kan worden uitgedrukt met stack gaps, grid gutters of getokeniseerde spacing.
Wanneer spacing licht varieert (15px hier, 17px daar), concludeert AI mogelijk dat de lay-out “handmatig” is en valt het terug op absolute coördinaten om pixel-perfect te blijven.
AI zoekt ook naar visuele “omhulling”: achtergronden, borders, schaduwen en padding-achtige ruimtes die op een container wijzen. Een kaart met achtergrond en interne padding is een duidelijk signaal voor een ouder-element met kinderen.
Daarvandaan mappt het vaak structuur naar primitieve elementen zoals:
Schone groepering in het ontwerpbestand helpt ouders van siblings te onderscheiden.
Als het ontwerp constraints bevat (pinning, hugging, fill) gebruikt AI die om te beslissen wat uitrekt en wat vast blijft. “Fill”-elementen worden typisch flexibele breedtes (bijv. flex: 1), terwijl “hug” naar content-gemeten elementen mapt.
Absolute positionering verschijnt meestal wanneer het model relaties niet zeker kan uitdrukken met flow-lay-outs—vaak door inconsistente spacing, overlappende lagen of verkeerd uitgelijnde elementen. Het kan er op één scherm goed uitzien maar breekt responsiveness en tekstresizing.
Het gebruik van een kleine spacing-schaal en uitlijning op een duidelijk grid vergroot de kans dat AI schone flex/grid-code genereert in plaats van coördinaten. Consistentie is niet alleen esthetiek—het is een machine-leesbaar patroon.
AI “begrijpt” hiërarchie niet; het leidt belangrijkheid af uit patronen die dat meestal signaleren. Hoe duidelijker je ontwerp die signalen communiceert, hoe waarschijnlijker het is dat de gegenereerde UI je intentie volgt.
Typografie is een van de sterkste aanwijzingen. Grotere tekst, vetring, hoger contrast en royale regelhoogte duiden meestal op hogere prioriteit.
Bijvoorbeeld, een 32px vetgedrukte titel boven een 16px gewone alinea is een duidelijk “kop + body”-patroon. Het wordt problematisch als stijlen vervagen—bijv. twee tekstblokken verschillen maar 1–2px of gebruiken hetzelfde gewicht met verschillende kleuren. Dan kan AI beide als platte tekst labelen of het verkeerde kopniveau kiezen.
Hiërarchie wordt ook afgeleid uit ruimtelijke relaties. Elementen die dichter bij elkaar staan, uitgelijnd zijn en gescheiden door witruimte van andere inhoud worden als groep gezien.
Gemeenschappelijke achtergronden (kaarten, panelen, getinte secties) werken als visuele haakjes: AI interpreteert ze vaak als containers zoals een section, aside of een component-wrapper. Oneven padding of inconsistente spacing kan per ongeluk verkeerde groepering veroorzaken—bijv. een knop die aan de verkeerde kaart vastzit.
Herhaalde patronen—identieke kaarten, lijstitems, rijen of formulierregels—zijn sterke aanwijzingen voor een herbruikbaar component. Zelfs kleine verschillen (icoonmaat, hoekradius, tekststijl) kunnen AI ertoe brengen meerdere één-opsie-versies te genereren in plaats van één component met varianten.
Knoppen communiceren intentie via grootte, vulling, contrast en positie. Een gevulde knop met sterk contrast wordt meestal als primaire actie behandeld; outlined of tekstknoppen worden secundair. Als twee acties gelijk benadrukt lijken, kan AI verkeerd raden welke “primair” is.
Uiteindelijk probeert AI hiërarchie naar semantiek te vertalen: headings (h1–h6), gegroepeerde regio’s (section) en betekenisvolle clusters (zoals “productdetails” vs “koopacties”). Duidelijke typografische stappen en consistente groepering maken deze vertaling veel betrouwbaarder.
Modellen voorspellen intentie door wat ze zien te matchen met patronen geleerd uit veel UI’s: bekende vormen, labels, iconografie en plaatsingsconventies.
Bepaalde opstellingen suggereren sterk specifieke componenten. Een horizontale strook bovenaan met een logo links en tekstitems rechts is waarschijnlijk een navigatiebalk. Een rij gelijkbreedte-items met één gemarkeerde vaak mapt naar tabs. Herhaalde vakken met afbeelding, titel en korte tekst lezen als kaarten. Dichte grids met uitgelijnde koppen en rijen worden vaak tabellen.
Die gissingen zijn belangrijk omdat ze de structuur beïnvloeden: een “tab” impliceert geselecteerde staat en toetsenbordnavigatie, terwijl een “rij met knoppen” dat mogelijk niet doet.
AI zoekt naar aanwijzingen die typisch interactie aangeven:
Van daaruit kent het gedrag toe: klikken, menu openen, navigeren, submitten, uitklappen/inklappen. Hoe meer het ontwerp interactieve elementen onderscheidt van statische, hoe nauwkeuriger de output.
Als het ontwerp meerdere varianten toont—hover, active/selected, disabled, error, loading—kan AI ze mappen naar stateful componenten (bijv. disabled knoppen, validatieberichten, skeleton loaders). Wanneer statussen niet expliciet zijn, kan AI ze weglaten.
Ambiguïteit is gebruikelijk: is een kaart klikbaar of informatief? Is een chevron decoratief of een disclosure-control? In die gevallen verduidelijk via naamgeving, annotaties of aparte frames die de interactie tonen.
Zodra AI een plausibele lezing van de lay-out heeft, is de volgende stap vertalen van “hoe het eruitziet” naar “wat het is”: semantische HTML, herbruikbare componenten en consistente styling.
De meeste tools mappen ontwerplagen en groepen naar een DOM-boom: frames worden containers, tekstlagen worden koppen/paragraphen en herhaalde items worden lijsten of grids.
Wanneer intentie duidelijk is, kan AI betere semantiek toekennen—bijv. een topbar wordt een \u003cheader\u003e, een logo en links worden een \u003cnav\u003e, en een klikbare kaart wordt een \u003ca\u003e of \u003cbutton\u003e. ARIA-rollen kunnen soms worden afgeleid (zoals role="dialog" voor een modal), maar alleen als het patroon eenduidig is; anders is veiliger output plain HTML plus TODO’s voor toegankelijkheidsreview.
Om te voorkomen dat er één enorme file ontstaat, probeert AI de UI in primitieve delen te knippen:
Veelvoorkomende signalen voor een “component” zijn herhaling, consistente padding/typografie en een gegroepeerd klikbaar gebied. Faalmodi zijn over-fragmentatie (te veel kleine componenten) of onder-fragmentatie (alles eenmalig hardcoded).
De generator kiest meestal één aanpak op basis van de target stack of standaarden:
Hoge-kwaliteit output leunt op design tokens—kleuren, spacing, radius, schaduwen—zodat de code consistent blijft als het ontwerp evolueert. Een strikte pixel-match levert vaak one-off waarden (bijv. 13px gaps, bijna-identieke grijzen) die er op het eerste gezicht goed uitzien maar moeilijk te onderhouden zijn.
Een praktische balans is: behoud hiërarchie en spacing-ritme, en normaliseer daarna naar tokens en componenten die je kunt hergebruiken (en refactor verder in de reviewstap—zie /blog/how-to-review-and-refactor-generated-ui-code).
Ontwerpbestanden lijken vaak “af” omdat ze getekend zijn op een paar vaste frames (zoals 1440 en 375). Code kan dat niet aannemen. Een design-to-code tool moet beslissen hoe de UI zich gedraagt tussen breedtes, met behulp van aanwijzingen en defaults.
Als je meerdere versies van hetzelfde scherm hebt (desktop/tablet/mobile) en de structuur consistent is, kan AI ze uitlijnen en afleiden waar lay-outregels veranderen. Zonder varianten valt het meestal terug op gangbare breakpoints en behandelt het framegrootte als de “basis”, wat tot ongemakkelijke sprongen kan leiden.
AI zoekt naar patronen: herhaalde kaarten in een grid, gelijke spacing en uitlijning. Daaruit kan het besluiten dat een 3-koloms grid 2 kolommen wordt en dan 1. Het worstelt wanneer het ontwerp op handmatige nudges vertrouwt—elementen die er uitgelijnd uitzien maar niet consistent zijn—omdat het niet kan bepalen of dat opzettelijk was.
De meeste ontwerpen gebruiken korte, nette copy. Producten in het echt niet. AI-gegeneerde UI-code zet vaak vaste breedtes/hoogtes of trunkates te agressief.
Een snelle sanity-check is testen met:\n\n- 2–3× langere titels (Duits-achtige samenstellingen, officiële namen)\n- meerregelige knoppen en foutmeldingen\n- grotere tekstgroottes (OS-toegankelijkheidsinstellingen)
AI kan de pixelechte crop uit het ontwerp behouden, maar responsieve UI’s hebben regels nodig: behoud aspect ratio, kies hoe bij te snijden en wanneer afbeeldingen moeten schalen versus van plaats veranderen. Als het ontwerp dit niet specificeert, verwacht dan “fill”-gedrag dat belangrijke delen wegknipt.
Voordat je de output vertrouwt, bekijk het op zeer smalle breedtes, zeer grote monitors en tussenliggende maten. Als iets overlapt, knipt of onleesbaar wordt, is het probleem meestal ontbrekende lay-outintentie—niet “slechte code”—en is het een signaal om duidelijkere constraints in het ontwerp toe te voegen.
AI kan pixels verrassend goed naar UI-code omzetten, maar toegankelijkheid is vaak waar “ziet er goed uit” afwijkt van “werkt voor iedereen”. Omdat veel vereisten niet zichtbaar zijn in een statisch frame, heeft het model expliciete signalen nodig.
Sommige toegankelijkheidsvriendelijke keuzes zijn visueel zichtbaar en AI kan die vaak naar betere HTML mappen:\n\n- Contrast en nadruk: grote, vetgedrukte tekst wordt vaak koppen; hoog-contrast knoppen worden primaire acties.\n- Labels naast inputs: een tekstlabel direct boven of links van een veld wordt vaak als label geïnterpreteerd.\n- Focusvolgorde-hints: een nette links-naar-rechts, boven-naar-beneden layout kan een redelijke DOM-volgorde produceren.
Andere vereisten zijn niet betrouwbaar zichtbaar:\n\n- Toetsenbordflow en traps: modals, menu’s en custom widgets hebben expliciet focusbeheer nodig.\n- Zinvollabels: “Email” in een placeholder is niet hetzelfde als een toegankelijk label; intentie zoals “Search products” vs. “Search site” kan onduidelijk zijn.\n- State-aankondigingen: fouten, loading en dynamische updates hebben ARIA-patronen nodig die niet uit uiterlijk blijken.
Verwacht hiaten zoals ontbrekende label/for-verbindingen, onjuiste kopniveaus, klikbare divs zonder toetsenbordondersteuning, zwakke focusstijlen en iconen zonder tekstalternatieven.
h1 → h2 → h3).\n- Landmarks bestaan (header, nav, main, footer) en zijn niet gedupliceerd.\n- Afbeeldingen/iconen hebben passende alt (of alt="" wanneer decoratief).\n- Zichtbare focusstijlen zijn aanwezig en voldoen aan contrastbehoeften.\n- Inputs hebben gekoppelde labels en duidelijke foutmeldingen.Voeg een korte spec toe bij modals, drawers, complexe formulieren, custom selects, drag-and-drop of alles met niet-triviale statussen. Zelfs een paar aanwijzingen zoals “trap focus in modal”, “Esc sluit” en “announce inline errors” kunnen de gegenereerde UI-code sterk verbeteren.
AI kan UI-code produceren die op het eerste gezicht dichtbij lijkt, maar kleine interpretatiefouten lopen snel op. De meeste issues komen voort uit “redelijke gissingen” wanneer het ontwerp regels niet duidelijk vastlegt.
Een veelgehoorde klacht is mismatchende spacing: knoppen voelen net niet goed, secties ademen te veel of kaarten lijken krap. Dit gebeurt wanneer padding over vergelijkbare elementen inconsistent is, of wanneer Auto Layout/constraints gemengd zijn met handmatige aanpassingen. Het model kan een patroon aannemen (bijv. “16px overal”) en uitzonderingen overschrijven—of juist accidentele uitzonderingen behouden.
Gegenereerde markup heeft vaak te veel wrapper-elementen. Elke veronderstelde visuele groepering wordt een extra \u003cdiv\u003e. Het resultaat is moeilijker te stylen, lastiger te debuggen en soms trager te renderen. Je merkt het wanneer een simpele kaart vijf geneste containers heeft alleen om een icoon en titel uit te lijnen.
AI kan componenten te fijnmazig opsplitsen (elk label wordt zijn eigen component) of te monolithisch (een heel scherm wordt één component). De oorzaak is onduidelijke grenzen: als herhaalde patronen niet identiek zijn, kan het model geen gedeelde component extraheren.
Typografie “drift” ontstaat omdat ontwerptekststijlen niet netjes naar code mappen. Subtiele verschillen in regelhoogte, letterspacing of gewicht gaan verloren en font-fallbacks kunnen metrics veranderen tussen omgevingen. Daarom kan een kop die in Figma paste in code ineens wrappen.
Als hover, focus, error, loading of empty states niet in het ontwerp voorkomen, verzint AI ze zelden. De UI kan er statisch goed uitzien maar faalt zodra gebruikers interactie hebben.
AI-codegenerators “zien” je ontwerp niet zoals een mens—ze lezen een gestructureerd bestand vol lagen, constraints, stijlen en componentinstanties. Hoe schoner die structuur, hoe minder het model hoeft te raden (en hoe minder rommelige divs je later hoeft op te ruimen).
Laagnamen zijn een van de sterkste signalen voor intentie en componentmapping. Gebruik consistente, beschrijvende patronen die overeenkomen met hoe je UI bouwt:
Button/Primary, Button/Secondary\n- Card/Product, Card/Article\n- Form/Input/Text, Form/CheckboxVermijd namen als “Rectangle 12” of “Group 5”—dat duwt AI naar generieke wrappers in plaats van herbruikbare componenten.
Handmatige positionering wordt vaak absolute coördinaten in code. Als je flex/grid-output wilt, moet je ontwerp zich als flex/grid gedragen:
Als het ontwerp goed reageert binnen het ontwerptool, is de gegenereerde UI veel waarschijnlijker standaard responsief.
One-off kleuren, lettergroottes en spacingwaarden stimuleren one-off CSS. Doe in plaats daarvan:
Dit verbetert consistentie en maakt refactoren naar een designsystem later makkelijker.
AI kan niet afleiden wat het niet vindt. Voeg sleutelvarianten toe zoals hover/pressed/disabled, foutstatussen voor inputs, loading-states en empty-states.
Wanneer gedrag ertoe doet, annoteer het kort: “opent modal”, “server-gevalideerd”, “toont toast bij succes”. Eén regel bij een component kan foutieve interactiecode voorkomen.
Als je een teamworkflow standaardiseert, leg deze conventies vast in een lichte checklist en verwijs er intern naar (bijv. /blog/design-to-code-checklist).
AI-gegeneerde UI-code is het best te behandelen als een eerste versie: het bespaart uren, maar heeft meestal een menselijke pass nodig om zeker te zijn dat de UI goed werkt, onderhoudbaar blijft en aan productnormen voldoet.
Begin met het lezen van de markup alsof je een screenreader bent.
\u003ch1\u003e, gevolgd door logische \u003ch2\u003e/\u003ch3\u003e).\n- Bevestig lijsten: echte lijsten (\u003cul\u003e/\u003col\u003e) en geen gestapelde \u003cdiv\u003es.\n- Inspecteer formulieren: elke input moet een label hebben en fout-/hulptr Tekst moet gekoppeld zijn.\n- Zorg dat interactieve elementen correct zijn: buttons voor acties, links voor navigatie.Als semantiek verkeerd is, redt CSS de toegankelijkheid of bruikbaarheid niet.
Veel generators vertrouwen op absolute positionering of diep geneste wrappers om de screenshot te matchen. Dat breekt meestal wanneer content verandert.
Geef de voorkeur aan flex/grid-regels boven coördinaten en reduceer nesting totdat elke wrapper een duidelijke reden heeft (lay-outgroepering, spacing of componentgrens). Zie je veel style={{ left, top, width, height }}-patronen, schrijf dat gebied dan als eerste opnieuw.
Zoek naar herhalende UI-patronen (kaarten, invoerrijen, nav-items) en maak er herbruikbare componenten van. Vervang daarna hard-coded waarden door tokens: spacing, radius, typografie en kleuren. Als je team al token-richtlijnen heeft, stem daarop af; anders begin met een minimale set en breid gecontroleerd uit (zie /blog/design-tokens).
Je hebt geen zware testsuite nodig om waarde te halen.
Generators raden intentie. Leg eventuele aanpassingen vast (interactieregels, breakpoints, component-mapping beslissingen) zodat de volgende generatiepass—or de volgende ontwikkelaar—ze niet per ongeluk terugdraait.
AI “design to code” werkt het best wanneer je het als versneller ziet, niet als autopiloot. De snelste teams kiezen een workflow die past bij de volwassenheid van hun designsystem en het risiconiveau van het scherm dat ze bouwen.
1) AI-assistent binnen designtools (bijv. Figma-plugins): Goed om dicht bij het bronbestand te blijven. Je krijgt snelle scaffolding terwijl ontwerpers itereren, en het is makkelijker om namen, componenten en tokens in het bestand uitgelijnd te houden.
2) Externe converters (upload/export → code): Handig voor een herhaalbare pijplijn over veel bestanden of teams. Het kan sneller zijn voor bulkconversie, maar je besteedt vaak meer tijd aan het opschonen van structuur en het aansluiten van interacties.
In de praktijk combineren teams vaak design-to-code met een breder “spec to shipped app”-proces. Platforms zoals Koder.ai nemen hetzelfde principe—intent omzetten in implementatie—en breiden het uit voorbij UI-scaffolding: je kunt features beschrijven in chat, React-frontends genereren met Go/PostgreSQL-backends (en Flutter voor mobiel), daarna itereren met planningsmodus, snapshots, rollback en broncode-export wanneer het tijd is te integreren met een bestaande repo.
AI blinkt uit bij:
Wees terughoudend bij:
Behandel elke generatie als een concept: review de output, noteer terugkerende problemen (naamgeving, ontbrekende statussen, verkeerde semantiek) en verbeter je prompt/spec en ontwerpconventies. Na een paar ronden verbetert de kwaliteit meer dan je verwacht.
Voer een kleine pilot uit en beoordeel resultaten op: trouw aan lay-out, componenthergebruik, responsiviteit, basis toegankelijkheid en refactortijd. Als je tooling-opties vergelijkt, check /pricing.
Het is een AI-geassisteerde vertaling van een visuele UI (Figma-frame, ontwerpexport of screenshot) naar uitvoerbare UI-code. Het doel is een degelijk eerste concept—lay-out, stylingritme en basisstructuur—zodat een ontwikkelaar het kan refactoren naar tokens, componenten en productiekwaliteit semantiek.
Het vertaalt doorgaans:
Pixels bevatten niet alles. Je moet meestal specificeren of aanleveren:
Een screenshot is de magerste input: het heeft kleur en geometrie maar geen expliciete structuur (lagen, constraints, componenten). Verwacht meer radenwerk, meer absolute positionering en minder herbruikbare code.
Een Figma/Sketch-bestand of gestructureerde export geeft frames, laagnamen, Auto Layout, constraints en stijlen—signalen die helpen schonere flex/grid lay-outs en nauwkeurigere componentgrenzen te maken.
AI zoekt herhaalde uitlijning en consistente tussenruimtes om de UI als flex/grid-regels uit te drukken. Als het een duidelijk spacingritme vindt (zoals 8/16/24), kan het stabiele stacks en grids genereren.
Als de tussenruimtes inconsistent zijn of elementen licht misaligned, valt het model vaak terug op absolute coördinaten om het exacte uiterlijk te bewaren—ten koste van responsiviteit.
Het zoekt naar visuele “inkapseling” signalen:
Schone groepering en consistente structuur in het ontwerptool (frames, Auto Layout) maken ouder/kind-relaties veel eenvoudiger om in code te reproduceren.
Absolute positionering verschijnt wanneer relaties vaag zijn—overlappen, inconsistente spacing, handmatige aanpassingen of onduidelijke groepering. Het kan er goed uitzien op één schermgrootte maar breekt vaak bij:
Als je flexibele output wilt, laat het ontwerp zich gedragen als flex/grid via Auto Layout en constraints.
Het leidt hiërarchie af uit visuele aanwijzingen:
Als stijlen slechts 1–2px verschillen of hiërarchiestappen onduidelijk zijn, kan het de verkeerde kopniveaus kiezen of koppen als gewone tekst behandelen.
AI raadt interactiviteit aan op basis van UI-affordances:
Als een “kaart” klikbaar of informatief kan zijn, annoteer of toon een variant; anders kan het model de verkeerde gedragingen koppelen of ze weglaten.
Doe een snelle, gestructureerde controle:
Behandel de output als scaffolding en documenteer aannames zodat toekomstige generaties ze niet per ongeluk terugdraaien.