At give en AI-agent feedback på en brugerflade betyder som regel skærmbilleder, kruseduller og en lang chatbesked. Med Redline, vores open source-overlay, peger man i stedet på den kørende app, samler en bunke noter uden at miste flowet og giver agenten alt, hvad den skal bruge for at finde koden.
Hver uge holder vi en kort retro om, hvordan vi arbejder, og der er ét spørgsmål, der altid dukker op: hvad har vi brugt tid på i denne uge, som burde have været automatiseret for længst?
I en periode blev vi ved med at nå frem til det samme svar, både på vores egne præsentationer og på kundeprojekterne: at give en agent feedback på en brugerflade, den selv havde bygget. Ikke selve rettelserne, for dem klarede agenten på få sekunder. Men alt det, der skulle til for at fortælle den, hvad den skulle rette.
Ingen havde besluttet, at det var sådan, vi gav feedback. Det var bare blevet jobbet.
”Knappen øverst til højre, ved siden af den blå”
Lyt til, hvordan folk i dag beskriver ændringer i en brugerflade, både til agenter og til hinanden. “Knappen øverst til højre, ved siden af den blå.” “Det andet kort, overskriften er for stor.” “På indstillingssiden, under kontakten, er der et mærkeligt mellemrum.” Bagefter følger et skærmbillede, med eller uden pile, og et håb om, at modtageren kan regne ud, hvilken af de fire blå knapper man mente.
Sådan bliver det meste feedback på brugerflader stadig givet. Det fungerer mellem mennesker, fordi den anden kan spørge. Med en agent betyder det, at agenten læser beskrivelsen, kører grep efter ordet “Save”, finder det elleve steder og vælger ét af dem.
Agenterne var blevet så hurtige, at det langsomme ikke længere var selve ændringen. Det var at forklare den.
Ved de små ting tog det længere tid at skrive instruktionen end at lave rettelsen. Man bruger halvtreds ord på at beskrive en ændring på fem, eller man giver op og åbner filen selv. Ved de større ting gik det den anden vej: et layout, der føltes forkert, fik et skærmbillede med pile og en halv roman vedhæftet, og agenten måtte alligevel gætte på, hvilken komponent vi mente.
Begge dele skyldes det samme. Vi oversatte noget, vi kunne se, til ord, så agenten kunne oversætte ordene tilbage til noget, den kunne finde.
Prisen for kontekstskift
Det, der generede mig mest, var ikke tastearbejdet. Det var alt det frem og tilbage.
Her er, hvad ét fund rent faktisk kostede. Jeg ser noget i appen. Åbner klippeværktøjet, markerer området, beskærer det og tegner en pil. Skifter til agentchatten, indsætter billedet og skriver et afsnit om, hvad og hvor. Skifter tilbage til browseren. Finder ud af, hvor jeg var, og det er tit sværere, end det lyder: den dropdown, jeg havde åben, er klappet sammen, dialogboksen er væk, og det filter, jeg havde sat op for at genskabe problemet, er nulstillet.
Så det næste fund og den samme runde igen. Browser, klippeværktøj, chat, browser. Ti fund er tredive skift.
Og hvert skift foregår i hovedet, ikke kun på skærmen. I appen er man en bruger, der klikker rundt og lægger mærke til, hvad der føles forkert. I chatten er man en udvikler, der skal regne ud, hvilken komponent det er, og hvordan man beskriver den. Efter et par runder tester man ikke rigtig længere, man skriver tickets, og de små ting holder man op med at melde, fordi hver af dem koster et skærmbillede og et afsnit.
Kald agenten over til skrivebordet
Hvis det var en kollega, der havde bygget siden, ville intet af det her ske. Man ville kalde vedkommende over til skrivebordet, pege på skærmen og sige “den her, lige dér, skru lidt ned for den”. Så ser kollegaen det samme som én selv. Overstået på ti sekunder.
Jeg vil gerne arbejde med agenter på samme måde, som jeg arbejder med kolleger, så vi byggede et værktøj til det: Redline, et overlay, man åbner i den kørende app med Alt+Shift+R.
Redlines tre tilstande svarer til det, man ville gøre ved skrivebordet:
- At pege er Comment. Klik på et element, og skriv, hvad der skal ændres.
- “Lav det om til det her” er Text. Klik på en tekst, og skriv den om på stedet. Hvis teksten står statisk i kildekoden, kan Redline skrive den direkte ind i filen, og det løser problemet med de halvtreds ord til en ændring på fem.
- Serviettegningen er Sketch. Tegn bokse, pile eller streger på frihånd, og skriv tekst oven på siden. Det er til de ændringer, der er lettere at tegne end at beskrive.
Hver note kan få en label: Bug, UX, Idea, Copy eller en, man selv har lavet. Det lyder som en lille ting. Men det er forskellen på “det her virker ikke” og “jeg vil gerne have, at det her føles anderledes”, og det er præcis den skelnen, der forsvinder, når man lige skyder en chatbesked af sted. Agenten læser labelen før alt andet i noten.
Alt det, man aldrig ville skrive
Kollegaen ved skrivebordet hører ikke bare ordene, men ser også skærmen, vinduesstørrelsen og fejlmeddelelsen i hjørnet. En note, der er hæftet på et element, har den samme kontekst med sig, og meget af den ville man aldrig selv komme i tanke om at skrive:
- kildefilen og linjenummeret og den kæde af komponenter, elementet sidder i
- URL’en, en CSS-selektor og test-id’et
- viewporten, lyst eller mørkt tema og de seneste fejl i konsollen
- et skærmbillede, hvor elementet er markeret
Redline gemmer hver note som markdown i en .redline/-mappe ved siden af koden, så for agenten ser en note sådan her ud (forkortet: den fulde note har også en maskinlæsbar blok med resten af konteksten):
### [ ] UX · Comment · `button` "Next" · src/components/LoginForm.tsx:48
Make this full-width on mobile only.
Agenten skal ikke gætte på, hvilken “Next”-knap jeg mente, eller om det kun gælder i mørkt tema på en telefonskærm. Det står i noten.
Ingen skriver en afhandling til sin kollega om en knap. Man peger på den.
Saml noterne og kør videre
Anden halvdel af samtalen ved skrivebordet er, at kollegaen vender tilbage. Den del klarer Redline også. Agenten krydser hver note af og skriver et kort svar, og svarene dukker op i overlayet, hæftet på det element, de hører til.
Den største forandring for mig har været rytmen. Jeg stopper ikke længere efter hvert fund for at skrive en besked. Jeg klikker mig gennem appen, som en bruger ville gøre, og sætter noter, hvor noget er galt. Når jeg har en håndfuld, skriver jeg /redline til agenten og går direkte tilbage til appen.
Agenten arbejder sig igennem bunken i baggrunden, mens jeg bliver ved med at teste og sætte noter. Vores frontends genindlæses live, når filerne ændrer sig, så jeg ser rettelserne dukke op på siden, mens jeg stadig er på den, og den næste bunke er allerede på vej. Kontekstskiftet er væk: jeg har appen foran mig hele tiden, og agenten får hvert eneste fund med fuld kontekst og kan også se, at tre af dem handler om den samme komponent.
Ikke kun på egen maskine
Standardopsætningen er lokal: egen dev-server, egen .redline/-mappe, egen agent. Det er dér, de fleste udviklere vil starte, og det er den udgave, man kan installere på to minutter.
Men det behøver ikke at stoppe dér. Noterne skal ikke nødvendigvis ligge i repoet. Redline kommunikerer med et notelager via en lille, dokumenteret protokol, så det samme overlay kan:
- dele noter i et team under udviklingen. Repoet indeholder en hub, en eksempelserver, der giver hver person et token og agenten et MCP-endpoint pr. projekt. Så kan flere personer gennemgå den samme app fra hver sin dev-server.
- køre på et udrullet site, så andre kan gennemgå det. Redaktører, kunder og QA giver feedback på staging eller i produktion, bag sitets eget login, og noterne når frem til udviklerne og deres agenter. Ingen andre ser overlayet.
- sende noterne til de systemer, man allerede har. Et ticketsystem, et CMS eller det feedbackværktøj, der er i brug i forvejen.
Det er med de to sidste, det bliver interessant på rigtige projekter. En del af det, vi laver sammen med vores kunder, er at koble Redline på en eksisterende platform, så feedback fra redaktører og kunder havner dér, hvor teamet allerede arbejder, og ikke i endnu et værktøj. Det kræver mere end den lokale opsætning, og det afhænger meget af, hvad der allerede er på plads.
Og når man ikke har koden
Vi er også ved at bygge AnnotateTheWeb, som snart er klar. Værktøjet tager den samme idé og dropper integrationen helt. Man peger på et hvilket som helst site, også et, man ikke selv ejer, uden at installere noget i kodebasen. Derfor er det næsten gnidningsfrit at komme i gang.
De to værktøjer passer til forskellige situationer. Uden dev-serveren er der hverken kildefil, linjenummer eller komponentkæde i noten, så agenten får siden, elementet og det, man har skrevet, og finder selv koden, hvilket nutidens agenter er gode til. Til gengæld kan man gå i gang på et hvilket som helst site på få sekunder. Redline er til de situationer, hvor man ejer koden og vil give agenten den præcise linje; AnnotateTheWeb er til alt det andet.
Prøv det
Redline er gratis og open source under MIT-licensen:
npm install -D @umage.ai/redline
npx redline initDerefter tilføjer man Redline som plugin i dev-serveren. Det virker med React, Vue, Svelte, Solid, Preact og Astro på Vite, med Next.js 15+ og med Angular 17+, og pakker til ASP.NET Core, Blazor og Optimizely er på vej. Som standard kører det kun på dev-serveren, så intet ryger med i produktion, medmindre man selv slår det til. redline init installerer en vejledning til den kodningsagent, man bruger (Claude Code, Codex, Cursor, Copilot, Gemini CLI og andre), og med en valgfri MCP-server kan agenter læse og lukke noter via værktøjskald. Opsætningen til hvert framework står på produktsiden og på GitHub.
Og fortæl os, hvad I synes. Det er et feedbackværktøj, så det ville være underligt ikke at spørge jer. Fejl, idéer og forslag hører hjemme i GitHub issues, og da det er open source, er pull requests lige så velkomne.
Retrospørgsmålet, som det hele startede med, hænger stadig på vores tavle: hvor arbejder vi stadig, som om AI ikke eksisterer? For feedback på brugerflader var svaret: hver gang vi beskrev noget, vi kunne have peget på.
Peg i stedet.