Hva er datamaskinbruk, og hvorfor er det viktig? Datamaskinbruk er en enkel idé med vidtrekkende konsekvenser: I stedet for å be modeller svare på spørsmål ber vi dem bruke programvare – navigere på nettsteder, fylle ut skjemaer, klikke seg gjennom arbeidsflyter og fullføre oppgaver autonomt fra start til slutt.
Dette åpner for en stor gruppe praktiske oppgaver som i dag er spredt på tvers av grensesnitt, for eksempel komplette bestillinger, betaling i nettbutikker, reiseplanlegging i flere trinn og administrative arbeidsflyter uten et godt API-alternativ. Dette er ikke nye problemer. Det nye er at de nå kan løses med modeller for generell bruk.
Nyere systemer fra Anthropic og OpenAI har vist frem agenter som ikke bare handler, men også resonnerer om tilstand, retter opp feil og lager oppgavespesifikke løsninger underveis. Dette gjør nettleseren til et generelt kjøremiljø for agenter, men reiser samtidig et viktig designspørsmål: Hvor mye av dette miljøet bør vi eksponere for modellen?
Tidlige systemer løste dette ved å pakke inn nettleseren i et fast sett med trygge, forhåndsdefinerte handlinger. Som vi skal argumentere for i dette innlegget, er denne tilnærmingen i ferd med å nå grensene sine.
Når man bygger nettleseragenter, er det naturlig å tenke at man ikke bør stole for mye på modellen.
Derfor pakker vi inn nettleseren. Vi tilbyr forhåndsdefinerte verktøy som click, type, scroll, select og read_text. Vi forenkler Document Object Model (DOM). Vi reduserer handlingsrommet. Vi prøver å gjøre atferden forståelig og kontrollerbar gjennom abstraksjoner vi selv utformer.
Dette er et fornuftig utgangspunkt. Men det er også i stadig større grad feil arkitektur på lang sikt.
Etter hvert som banebrytende modeller blir bedre, er begrensningen ikke lenger bare at modellen mangler verktøy. Problemet er at vi tvinger den til å arbeide gjennom abstraksjoner som fjerner for mye av det underliggende systemet. Vi presser et rotete og dynamisk miljø inn i et fast handlingsgrensesnitt, og ber deretter modellen prestere godt til tross for dette informasjonstapet.
Dette kompromisset blir stadig mindre attraktivt.
Endringen vi har utforsket, er enkel å beskrive, men har betydelige konsekvenser. I stedet for å behandle agenten som en velger av forhåndsdefinerte handlinger behandler vi den som en programgenerator som opererer i et begrenset kjøremiljø.
Modellene har blitt svært gode og trenger ikke lenger de abstrakte sikkerhetsrekkverkene dine – de trenger hele handlingsrommet for å utforme, utføre og forbedre oppgaven til de når målet.
Dette innlegget handler om denne overgangen – fra nettleserautomatisering med mange abstraksjoner til begrenset datamaskinbruk – og om hva som endres når systemer utformes på denne måten.
Problemet er ikke at faste handlingsgrensesnitt er prinsipielt feil. Problemet er at nettet ikke spiller på lag med dem.
Moderne grensesnitt er bygd med React, Vue og Angular, med asynkrone tilstandsoppdateringer, syntetiske hendelsessystemer og innebygde tredjepartsmoduler som kjører i iframes fra andre opprinnelser og har egne livssykluser. En innpakning som sier «skriv i dette inndatafeltet», fungerer bare hvis siden deler din definisjon av det å skrive. Det gjør mange sider ikke. Hvis en verdi angis direkte, omgås ofte rammeverkets endringsregistrering fullstendig. Feltet ser utfylt ut. Valideringen utløses aldri. Skjemaet fungerer fortsatt ikke.
Dette kan du lappe på. Du kan legge til særtilfeller for React-felt, utløse blur-hendelser etter fokus og vente til nettverket er inaktivt før du leser tilstanden. Hver enkelt rettelse fungerer lokalt. Til sammen hoper de seg opp til et system som blir stadig vanskeligere å vedlikeholde og stadig mer tilpasset nettstedene du allerede har møtt.
Det dypere problemet er at du bygger antakelser om hvordan interaksjoner skal fungere inn i abstraksjonslaget, for så å oppdage at nettet bygger på andre antakelser.
Tenk deg et betalingsskjema fra Stripe eller Adyen som er innebygd i en iframe fra en annen opprinnelse. Innpakningen din får ikke direkte tilgang til det fordi det ligger på en annen opprinnelse. Verktøyet read_text kan ikke observere den interne tilstanden. Verktøyet type får ikke tilgang til inndatafeltene. Her møter en agent basert på innpakninger veggen. Abstraksjonen ble utformet for hoveddokumentet. Selve oppgaven befinner seg et sted abstraksjonen ikke kan se.
En lignende uoverensstemmelse oppstår i mindre åpenbare prosesser. En nedtrekksliste som styres av et rammeverk, reagerer kanskje ikke på direkte klikk i det hele tatt, fordi det synlige elementet ikke er den egentlige kontrollen. Det kan være nødvendig med en serie tastaturhendelser for å utløse den underliggende tilstandsendringen. Utenfra ser brukergrensesnittet klikkbart ut. Abstraksjonen sier «klikk». Ingenting skjer.
Eller tenk deg en modal prosess i flere trinn, der oppdateringene i den synlige DOM-en henger etter endringene i den interne tilstanden. Riktig neste handling avhenger av en tilstandsendring som ennå ikke gjenspeiles i elementene innpakningen kan se. En agent basert på innpakninger handler da for tidlig eller leser en utdatert tilstand, fordi den arbeider ut fra et ufullstendig bilde av systemet.
I hvert av tilfellene skjuler abstraksjonen signalene agenten faktisk trenger.
En modell som opererer på et lavere nivå – inspiserer den aktive DOM-en, resonnerer om rammegrenser og genererer interaksjonssekvensen for akkurat denne flaten – kan håndtere slike situasjoner. Det betyr ikke at modellen i seg selv er smartere. Den har bare tilgang til informasjonen som ble fjernet.
Endringen vi har arbeidet mot, er enkel å beskrive: I stedet for å be modellen velge blant forhåndsdefinerte handlinger gir vi den en kjøringsflate på et lavere nivå, og begrenser flaten gjennom regler i kjøremiljøet fremfor gjennom abstraksjonsdesign.
Dette designvalget springer ut av en bredere utvikling i bransjen, der man i økende grad foretrekker primitive verktøy på lavere nivå. Slike verktøy utnytter agentens iboende evne til å korrigere seg under kjøring og produsere kode av høy kvalitet, i stedet for å bruke robuste, hardkodede spesialverktøy som svekker modellens evne til å tilpasse seg ulike miljøer.
Se bare på hvordan Claude Code har blitt et førstevalg i verktøykassen til mange utviklere, og på bransjens bredere dreining mot terminalbaserte agenter. Claude Codes største fordel er ikke selve modellen, men rammeverket på lavere nivå. Når modellen får færre, mer modulære verktøy på lavere nivå – altså terminalen – blir den bedre til å kalle verktøy. Hovedårsaken er at agenten kan resonnere og lage egne skript for den aktuelle oppgaven, i stedet for å forsøke å bruke generaliserte verktøy som fyller opp kontekstvinduet.
For nettleserautomatisering betyr dette i praksis at modellen kan inspisere sidens aktive tilstand direkte, navigere mellom rammer og lage skreddersydd interaksjonskode for det aktuelle grensesnittet, i stedet for å tilordne alt til et fast sett med forhåndsbygde handlinger.
Modellen opptrer mindre som en velger og mer som en utvikler under kjøring. Den inspiserer den gjeldende tilstanden, resonnerer om grensesnittet og genererer interaksjonslogikken for akkurat denne situasjonen. Den kan bygge sekvenser i flere trinn, tilpasse seg uvanlige prosesser og validere resultater før den fortsetter. Når en handling mislykkes, ser modellen den underliggende feilen og korrigerer seg selv. Dette er kraftigere og mer risikabelt – men også langt nærmere problemets faktiske natur.
Det er viktig å understreke at systemet ikke blir mindre disiplinert når abstraksjonslaget fjernes. Disiplinen flyttes bare.
Arbeid som tidligere lå i utformingen av innpakninger og håndteringen av særtilfeller, flyttes til tre steder: prompten (som blir en form for operativ opplæring), kjøremiljøet (som håndhever grenser for blant annet navigasjonsomfang, sensitive handlinger og nye forsøk) og evalueringslaget (som ikke bare vurderer om oppgaven lyktes, men også om de mellomliggende trinnene var riktige). Færre skjøre abstraksjoner. Sterkere systemer rundt modellen.
Én følge av denne endringen er at produktkoden ofte blir enklere, samtidig som systemet som helhet blir mer kapabelt. I stedet for å kode interaksjonsmønstre som gjenbrukbare innpakninger genererer agenten atferd under kjøring. Du vedlikeholder et lite sett med kraftige primitiver og et begrenset kjøremiljø, fremfor en stadig voksende samling av spesialverktøy og logikk for særtilfeller.
Dette endrer også hvordan systemet generaliserer. En agent basert på innpakninger generaliserer godt til oppgaver som ligner dem innpakningene du allerede har bygd, er laget for. En agent i et begrenset kjøremiljø generaliserer til oppgaver med samme kjørelag, selv når det synlige grensesnittet er annerledes.
Interaksjon med for eksempel et søkeskjema, en bestillingsprosess eller en innstillingsside kan se helt forskjellig ut i brukergrensesnittet. Men under overflaten deler de de samme mønstrene: lese tilstand, utløse hendelser, validere resultater og håndtere asynkrone oppdateringer. Et system som opererer på dette nivået, kan lettere overføre kunnskap mellom oppgaver.
Den gjenbrukbare komponenten er ikke handlingslisten. Det er modellens evne til å inspisere tilstand, handle trygt og kontrollere resultatene.
Den tydeligste lærdommen fra dette arbeidet er at pålitelighet ikke kommer av å gi modellen flere hjelpefunksjoner. Ofte kommer den av å gi modellen færre og kraftigere primitiver, og begrense dem på de riktige måtene. Overassistanse bygger inn antakelser om hvordan en oppgave skal løses. Begrensninger definerer trygge rammer og lar modellen finne bedre lokale løsninger.
En kraftigere kjøringsflate krever også en skarpere sikkerhetsmodell. Når agenten ikke lenger er begrenset til et lite sett med forhåndsdefinerte handlinger, opererer den i praksis direkte på ekte programvare. Det endrer risikoprofilen umiddelbart.
Utformingen må ta hensyn til fire forhold:
Dataeksponering. Når agenten samhandler med ekte grensesnitt, vil den ofte møte sensitiv informasjon. Det krever en disiplinert tilnærming til maskering og tilgangskontroll. Data bør bare vises når det er nødvendig for kjøringen, og logger og spor må håndteres varsomt, slik at observerbarheten ikke blir den mest sensitive delen av systemet.
Kjøringsomfang. En kraftig agent bør ikke kunne operere fritt. I praksis betyr dette å begrense hvor den kan navigere, hvilke domener den har tilgang til, og hvilke systemer den kan samhandle med. Begrensningene bør håndheves i kjøremiljøet, ikke bare være konvensjoner i prompten.
Tillit til omgivelsene. Moderne grensesnitt kan inneholde instruksjoner, innhold eller prosesser som er villedende eller aktivt fiendtlige. Promptinjeksjon via innhold på nettsider er en reell angrepsflate. Systemet trenger et tydelig instruksjonshierarki, valideringskontroller og stoppbetingelser for å hindre agenten i å følge utilsiktede anvisninger.
Spekter av autonomi. Ikke alle handlinger bør være fullstendig autonome. I mange produksjonsmiljøer er det viktig å behandle autonomi som et spekter. Systemet kan ha stor handlefrihet når det utforsker og utfører oppgaver, men samtidig kreve godkjenning for bestemte handlingskategorier.
Det underliggende prinsippet er enkelt: Når modellen får mer makt, må systemet rundt den bli sterkere. Autonomi uten retningslinjer er ikke produksjonsklart.
Vi sluttet å spørre: Hvilke nettleserhandlinger bør vi gjøre tilgjengelige?
Vi begynte å spørre: Hvordan kan vi gi modellen et komplett handlingsrom – og hvordan kan vi samtidig utforme regler for kjøremiljøet som gjør det trygt?
Dette nye perspektivet endrer hva du legger vekt på. Handlingstaksonomier og fullstendige innpakninger blir mindre viktige. Regler for kjøremiljøet, observerbarhet og evaluering av hvert trinn blir viktigere. Modellens kapasitet og systemdesign kan ikke erstatte hverandre. Etter hvert som modellene blir bedre, blir systemets arbeid viktigere, ikke mindre viktig.
Nettleseragenter som fungerer i demonstrasjoner, lykkes ofte fordi oppgaven er avgrenset og miljøet samarbeidsvillig. Produksjonssystemer krever noe annet: begrenset kjøring, instrumentert atferd og evaluering som kan skille et riktig resultat fra et heldig resultat.
Mindre utforming av innpakninger. Mer systemutvikling.
Og selv om vi har konsentrert oss om nettleseragenter, peker dette mot en bredere forståelse av datamaskinbruk som en systemdisiplin.