Jeg er tæt på at kalde bullshit på hele bølgen af loops og grafer. Jeg kan bare ikke helt. Og det er det interessante.
For noget af det virker faktisk. Jeg har bygget outer loops, inner loops og softwarefabrikker både med og uden mennesker i loopet, og nogle af dem kører rigtig godt. Samtidig kan jeg finde huller i næsten alt, hvad der bliver postet om emnet.
Det er svært at gennemskue på LinkedIn, X og Reddit. Man er næsten nødt til selv at bygge noget og se, hvor det knækker.
Så jeg gik tilbage og målte mine egne loops.
Loopet er den nemme del
Et loop er nemt at beskrive: Prøv, mål, ret og gentag.
Det svære ord er mål.
Inden for softwaretest taler man om et orakel: Det, der kan afgøre, om et resultat er rigtigt eller forkert. En test kan være sådan et orakel. Den er ligeglad med, hvem der kører den, hvilken prompt der blev brugt, og hvor gerne jeg vil have den til at bestå.
Et agent-loop kan kun køre videre uden mig, hvis det har noget i den stil at måle efter.
Det kan jeg se direkte i mine egne data. Med en kørsel mener jeg her arbejdet mellem to prompts fra et menneske.
I det snapshot, jeg analyserede, var der 1.233 kørsler, hvor agenten ændrede backend-kode. Her kørte den testkommandoer 1.017 gange. I 576 kørsler, hvor den ændrede UI-kode, skete det 16 gange.
Ingen har besluttet, at forskellen skulle være sådan. Det er bare et udtryk for, hvad agenten havde mulighed for at kontrollere.
Jeg kan se det samme mønster i vores end-to-end-tests: De tager 110 skærmbilleder, men ingen af billederne bliver vurderet automatisk. Der er hverken visuel sammenligning eller kontrol af fx kontrast. Maskinen tager flittigt billeder. Den kigger bare aldrig på dem.
Så jeg byggede alligevel et loop til design
Hvis man ikke har et fast kriterium, kan man forsøge at erstatte det med en dommer. Det gjorde jeg.
Mit /aesthetic-fanout foreslår flere designretninger på én gang. Derefter vælger en LLM-dommer den mest karakteristiske. Designstationen på mit samlebånd beskrev processen sådan:
This station has four phases in strict order:
strategic brief → aesthetic lock → operational intake → scaffold.
Reordering produces a generic site.
Generisk output var altså noget, processen aktivt skulle undgå. Senere i forløbet tilføjede jeg også kontrol af tilgængelighed, desktop, mobil og browserkonsol.
Der kom syv landingssider ud af det. Alle stationer gav grønt lys.
Bilag A: Rapporten siger succes. Det gør billedet ikke.
agent-inbox-v5 fik en Plan 9-inspireret stil med vinduer, paneler og faner. Den var omhyggeligt bygget, men sidens vigtigste felt var næsten tomt: Teksten “type an agent address. press enter.” efterfulgt af cirka 400 pixels ingenting.
Alligevel stod der i leverancens egen billedtekst:
Full-page screenshot at 1440×900, signature move triggered
(transcript + JSON envelope visible in hero pane)
Agenten skrev med andre ord sin egen succesrapport. Resten af siden blev vist fint, men præcis den sektion, hvor det valgte designgreb skulle bevise sit værd, var tom. Intet kontrolpunkt sammenlignede rapporten med billedet.
Bilag B: Tre pladsholdere i §7
idealab blev til en retssagsmappe. Der var sagsnummer og “EYES ONLY” i toppen, paragrafnumre og teksten “IN RE: [REDACTED] / EXHIBIT A”. Den primære knap hed File a petition.
Sektionen §7 — TESTIMONIALS bestod af tre rækker med teksten TESTIMONY PENDING. Det var ikke dårlige kundeudtalelser. Det var pladsholdertekst, inklusive en ødelagt tekststreng.
Et menneske ville stoppe ved den første række. Loopet fortsatte forbi alle tre, gennem kritikken af tilgængelighed, desktop og mobil, og meldte grønt.
Loopet skiftede kostume, ikke skelet
Det næste overraskede mig endnu mere.
Alle syv sider havde den samme grundstruktur — også de to, der kørte helt af sporet:
hero → hvad gør produktet → sådan virker det i tre trin → bevis → pris → FAQ → CTA
consent-service-v5 kaldte de tre trin I. ASKING / II. DECIDING / III. RECEIVING. agent-inbox-v5 viste dem i et :how-it-works-panel. Selv idealab, som var det mest ekstreme forslag, havde stadig kundeudtalelser og en FAQ. De hed bare §7 og §8.
Processen skulle undgå generiske resultater. Den lavede flere kandidater og havde en dommer til at vælge mellem dem. Den varierede typografi, farver og ordvalg, men informationsarkitekturen var den samme, som en skabelongenerator kunne have lavet i 2010. Når den endelig ændrede selve indholdet, blev resultatet dårligere.
Det var ikke et loop, der skabte en ny struktur. Det var et loop, der skiftede tøj.
Det første udkast er kun en sjettedel af arbejdet
Jeg målte også, hvor meget af arbejdet der ligger i den første generering.
For de 438 UI-filer, jeg kunne følge fra oprettelsen, stod den første skrivning kun for 15,5 procent af alle de ændringer, filerne senere fik. Resten var iteration.
Mange filer blev ganske vist skrevet én gang og aldrig ændret igen. Men arbejdet samlede sig i de vigtige filer: De fem procent mest ændrede filer stod for halvdelen af alle efterfølgende ændringer. Her var medianen 20 forskellige prompts fra et menneske per fil.
ChatProvider.tsx blev for eksempel ændret 127 gange gennem 37 prompts over otte dage.
Det var 37 gange, hvor jeg så resultatet og vurderede, hvilken retning vi skulle gå.
Det er ikke kun et UI-fænomen. For filer med programlogik udgjorde den første skrivning 21,4 procent. Både UI-kode og programlogik begynder som et stillads. Forskellen er, om der bagefter findes et orakel, der kan afgøre, hvornår loopet er færdigt.
En score løser ikke problemet
Jeg mener ikke, at smag er umulig at bedømme med en model. En LLM-dommer kan sagtens hjælpe med at sammenligne forslag og pege på problemer.
Men en vurdering er ikke nødvendigvis stabil nok til at fungere som stopklods i et autonomt loop. Den samme model gav den samme fil både 64 og 72 point. I et andet forbedringsloop gik scoren fra 64 til 64 og derefter ned til 60.
En dommer kan være god nok til at rangere en bunke forslag. Det betyder ikke, at den kan afgøre, hvornår siden er færdig.
En test siger nej. En dommer siger: “Jeg foretrækker den her.”
Det er ikke et argument imod loops
Loops kan køre langt på egen hånd, når de har et godt orakel. Det er derfor, de ofte fungerer så godt til backend, migreringer og andre opgaver med tests, typetjek eller tydelige tal som mål.
UX er anderledes. Jeg har set mange overbevisende demonstrationer af UX-loops, men jeg har endnu ikke set et, der stabilt fungerer som et automatisk kontrolpunkt for kvalitet. Mit eget gør heller ikke.
I mit repo ligger fire planlagte kontrolpunkter stadig med enabled: false. De agenter, der skulle kritisere designet, kunne læse kode og søge i filer, men de havde ingen browser. De kunne læse sidens kode. De kunne ikke se siden.
Rettelsen kom heller ikke fra loopet. agent-inbox-v6 ser rigtig ud igen, fordi et menneske så v5, ændrede prompten og begyndte forfra.
Måske er mennesket ikke bare en midlertidig flaskehals, som endnu ikke er blevet automatiseret væk. I kreativt arbejde er mennesket måske selve oraklet.
Så mit spørgsmål er oprigtigt:
Hvordan bygger man et valideringsloop for godt UX? Hvad er evalueringskriteriet?
Mit eget kriterium var “mest karakteristisk”. Loopet opfyldte det. Resultatet var en retssagsmappe med pladsholdertekst i §7.