Jeg satt en kveld og så på mens GPT-6 Astra brukte datamaskinen min. Jeg sa hva som skulle skje på skjermen, den så, den flyttet markøren, den klikket. Det virket.

Min første reaksjon var ikke at det var imponerende. Den var at det var sløsing.

Så leste jeg hva andre skrev om det samme, og der var reaksjonen den motsatte. Det var den store saken, beviset på at noe hadde tatt et steg. Det er den forskjellen denne teksten handler om — for jeg tror ikke de som ble imponert så feil. De så det samme som jeg. De målte det mot noe annet.

Det som demonstreres, er at en modell kan bruke et grensesnitt bygd for mennesker. Det er en imponerende teknisk bragd, og det er samtidig en dårlig måte å arbeide på. Begge deler er sanne samtidig, og det er derfor forvirringen oppstår. Bragden måles mot hva modeller klarte i fjor, og mot den målestokken er den stor. Arbeidsmåten burde måles mot hvordan den samme modellen arbeider når den får rett kanal, og mot den målestokken er den liten.

Men det er ikke mulig å se før man vet hva den andre kanalen gir. Så jeg begynner der.

Slik arbeider en agent når den får

Gi en agent et mål og en form den kan arbeide i, og du får noe som ikke har noen egentlig motsvarighet i menneskelig arbeid.

Den arbeider parallelt. Tretti filer er ikke tretti ting å holde i hodet, det er én enkelt kontekst. Den arbeider utholdende: den samme kontrollen på post fire hundre utføres akkurat som på post én, uten den oppmerksomhetsdriften som gjør at et menneske finner tre feil av fem utover ettermiddagen. Den arbeider nøyaktig — en sammenligning mot en verdi er en sammenligning mot en verdi, ikke et blikk. Og den arbeider i maskinhastighet, som er den minst interessante av egenskapene og den alle nevner først.

Framfor alt kan den gå tilbake. Å gjøre om et steg koster nesten ingenting, noe som betyr at den kan prøve seg fram på en måte som er uøkonomisk for et menneske. Det er den egenskapen som gjør at man kan gi den et mål i stedet for en instruks.

Legg det sammen, og du får en arbeidsform med en helt annen kostnadskurve enn vår. Det som er dyrt for et menneske — repetisjon, utholdenhet, nøyaktighet over volum, å gjøre om — er billig for agenten. Det som er dyrt for agenten, vurderingen av hva som er verdt å gjøre og evnen til å se når et svar ser riktig ut, men er feil, er det vi fortsatt er her for.

Det er den arbeidsformen som er verdt noe. Det er også den man gir fra seg.

Et grensesnitt er en kanal bygd for en musepeker

Et grafisk brukergrensesnitt er ikke funksjonen. Det er funksjonen pakket for en bestemt mottaker.

Vi glemmer det, for vi er mottakeren. En knapp er en operasjon som har fått en form, en plassering og en farge fordi et menneske skal finne den på under et sekund. En meny er en beslutningstrestruktur som er brettet sammen så den får plass i korttidsminnet. En hovertilstand finnes fordi en hånd kan sveve. Romlig utforming, ikonografi, gruppering, gråtoner for det inaktive — alt sammen er komprimering, og komprimeringen er optimert for menneskelig persepsjon. Ingenting annet.

Under grensesnittet ligger hele tiden den upakkede formen. Filen. Kommandoen. API-kallet. Den formen er ikke en forenkling av grensesnittet; det er tvert imot grensesnittet som er en oversettelse av den. Å la en agent arbeide gjennom skjermen er å la den lese et fotografi av regnearket i stedet for regnearket.

Men det avgjørende er ikke at formatet er et annet. Det avgjørende er at formatet er serielt. Et grensesnitt er bygd for en operatør med en musepeker — noen som kan gjøre én ting av gangen og trenger å se resultatet før den neste. Og hver eneste egenskap fra forrige avsnitt går tapt i den kanalen, én etter én.

Parallelliteten først: en musepeker er per definisjon én. Tretti filer blir tretti sekvensielle åpninger. Utholdenheten deretter: hvert steg krever en ny skjermlesing, og hver skjermlesing er en anledning til å tolke feil — ikke fordi modellen er slurvete, men fordi slutninger ut fra piksler er mer usikre enn en avlesning av en verdi. Nøyaktigheten går samme vei. Og det å gå tilbake, som var nesten gratis, blir plutselig dyrt, fordi tilstanden nå ligger i et grensesnitt som ikke har noen angreknapp for det agenten nettopp gjorde.

Igjen står hastigheten, og den blir dårligere enn et menneskes.

Det viktige er at dette ikke er umodenhet. Det er lett å lese demonstrasjonen som et tidlig stadium — langsom nå, rask siden. Men flaskehalsen sitter ikke i modellen. Den sitter i kanalen. En dobbelt så rask modell klikker dobbelt så fort gjennom det samme nøkkelhullet, og nøkkelhullet er fremdeles dimensjonert for en hånd. Man kan gjøre adapteren bedre. Man kan ikke gjøre den til noe annet enn en adapter.

Innvendingen er altså ikke at teknologien er dårlig. Den er at man betaler for en agent og bruker den som en praktikant med en mus.

Hvorfor det likevel er det som vises fram

Og likevel er det den formen som demonstreres, og forklaringen er banal.

Man kan se den. En agent som klikker seg gjennom et grensesnitt, gjør noe forståelig. Vi kjenner igjen hvert steg, vi ser markøren bevege seg mot feltet vi selv ville ha valgt, vi ser den nøle, vi ser den lykkes. Vi har en indre modell av hva det koster å gjøre det samme for hånd, og den modellen fylles automatisk med mening.

Det effektive arbeidet ser ikke ut som noe i det hele tatt. Et mål formuleres, en kommando kjøres, et resultat finnes. Det finnes ingen markør å følge med blikket og ingenting som holder på interessen i tretti sekunder.

Slik oppstår en skjevhet. Den synlige varianten vinner oppmerksomhet, den nyttige vinner arbeidet, og det er ikke det samme markedet. Oppmerksomhet styrer hva som demonstreres på scener, hva som klippes til tretti sekunder, hva investorer tror teknologien er, og til slutt hva en driftssjef ser for seg når noen sier "AI-agent". Det er ikke noe nytt i industrien. Vi har hatt tretti år av det samme med visualiseringstavler: den tavla som ser best ut under et bedriftsbesøk, er sjelden den som endrer flest beslutninger.

Jeg har altså ingen innvending mot at noen blir imponert. Jeg har en innvending mot kriteriet. Spørsmålet "klarte den det?" har et svar som med tiden alltid blir ja, og som derfor slutter å bære informasjon. Spørsmålet som bærer, er lett å stille og ubehagelig å svare på: sammenlignet med hva?

Rekkefølgen er ingen smakssak

Og her kommer jeg fra en annen kant enn de fleste som skriver om agentarkitektur.

Det første lean spør om et arbeidstrinn, er ikke hvordan det skal gjøres raskere. Det er om det skal finnes. Eliminere, så forenkle, så — først da — mekanisere. Rekkefølgen er ikke en preferanse. Den er en forsvarsmekanisme mot én bestemt feil: å gjøre et unødvendig trinn permanent ved å bygge infrastruktur rundt det.

For det er det automatisering gjør. Manuell sløsing er irriterende, synlig og billig å avskaffe; noen klager på det hver uke. Automatisert sløsing klager ingen på. Det gjør ikke vondt lenger. Det har en eier, et driftsbudsjett, en plan og en historikk, og å fjerne det er nå et prosjekt i stedet for en beslutning. Trinnet har gått fra å være en kostnad til å være en eiendel i noens balanse. Det er derfor forenklingen må komme før mekaniseringen — ikke fordi den er finere, men fordi vinduet lukker seg.

Trappen har tre trinn, og AI er det siste. Først forenkle: skrelle arbeidet ned til det som faktisk tilfører verdi, stabilisere prosessen, få rutinen til å sitte. Så automatisere: mekanisere det repetitive når det først er stabilt — sensorer som måler, skript som registrerer, sperrer som hindrer feil. Automatisering gjør en stabil prosess raskere. Den gjør aldri en ustabil prosess stabil. Og sist, sist, slippe inn en modell — der mønster og vurdering betyr noe, og der de dataene den trenger allerede finnes, rene, fordi de to foregående trinnene ble bygd først.

Hvert trinn fortjener det neste. Hopper man over ett, får man en modell trent på et prosesskaos, og det eneste den lærer, er å produsere mer av det. Så får modellen skylden, selv om den gjør nøyaktig det den lærte. Kaoset fantes før modellen. Modellen har bare forsterket det.

Computer use automatiserer det menneskelige grensesnittet. Men det menneskelige grensesnittet er selv en nødløsning. Det finnes fordi et menneske måtte nå funksjonen, og piksler var den eneste kanalen vi hadde. Det er ikke prosessen. Det er prosessens innpakning for en bestemt operatør. Når vi bygger en agent som klikker i den innpakningen, har vi tatt et trinn som fantes av menneskelige grunner, og gjort det permanent av tekniske.

Det er å hoppe over de to første trinnene og anvende det tredje på en prosess ingen har forenklet. Man spør aldri om klikkveien måtte finnes. Man spør bare om modellen klarer den.

Og det er der de to tingene møtes. Automatiserer man en klikkvei, får den en plan, en eier og et driftsbudsjett — og dermed et forsvar. Sløsingen blir ikke bare værende. Den blir infrastruktur, og infrastruktur avskaffer man ikke, den forvalter man.

Der det ikke finnes noen vei inn

Og så motbildet, som er minst like viktig, for uten det er resten en kjepphest.

Computer use er riktig når det ikke finnes noen annen vei inn. Ikke "når det er mer bekvemt". Når det ikke finnes.

Den situasjonen er ikke marginal i industrien. Den er normaltilstanden. Et MES uten eksport utover den ene rapporten noen en gang bestilte. En PLS-leverandørs proprietære verktøy der dataene finnes, men bare innenfor deres eget vindu. En maskins HMI som viser ti parametere i sanntid og sender null av dem videre. En webtjeneste uten API, eller med et API som koster mer enn problemet. Et system der leverandøren har gått konkurs, og der integrasjonen ingen lenger kan bestille.

I alle disse tilfellene er den upakkede formen ikke tilgjengelig. Den finnes — den ligger der, tre lag ned — men den er låst bak et grensesnitt som er den eneste døra. Da er en agent som leser skjermen ikke en omvei. Da er den brua over det som ikke lar seg bygge bru over, og den kan være det eneste som gjør en analyse mulig uten et integrasjonsprosjekt på seks måneder.

Forskjellen mellom de to tilfellene er lett å formulere og ubehagelig å svare på: finnes det en annen vei inn? Hvis ja, er grensesnittveien et valg — og nesten alltid et dårligere. Hvis nei, er den den eneste veien, og da er spørsmålet ikke lenger hvilken arkitektur som er vakrest, men om brua bærer.

Hva jeg selv kjører

Jeg har mer grunn enn de fleste til å være ærlig her, for mitt eget arbeid er bevis i begge retninger.

Tre ting jeg har bygd, fungerer daglig: en publiseringsflyt for dette nettstedet, et minnesystem som holder kontekst mellom økter og maskiner, og analysearbeid på produksjonsdata. Alle tre drives likt. Jeg formulerer et mål, jeg gir nødvendig kontekst, og arbeidet utføres mot filer, mot kommandoer, mot API-er.

Det konkrete synes tydeligst i den første. En utgave berører rundt tretti filer i tre språkversjoner, og alt skal stemme internt: de samme artiklene i alle tre strømmene, de samme datoene, ingen uoversatte overskrifter som blir liggende, ingen lenke som peker på gårsdagens fil. Det er nettopp den typen kontroll et menneske gjør slurvete klokka elleve om kvelden, og som en agent utfører identisk på fil én og fil tretti. Den åpner dem ikke én av gangen for å se på dem. Den har dem.

Analysearbeidet fungerer likedan. Den samme kontrollen på hver rad i en måleserie, og når noe ser feil ut, kan den gå tilbake og kjøre om med en annen avgrensning uten at det koster en ettermiddag. Det er ikke hastighet som er poenget der. Det er at man våger å prøve en tredje og en fjerde hypotese, fordi det ikke lenger er dyrt å ta feil.

Ingenting av det ville ha fungert via skjermklikk. Ikke "ville ha vært langsommere" — ville ikke ha fungert.

Og så finnes unntaket, og det er nøyaktig det unntaket motbildet beskriver: det eneste stedet i hele oppsettet mitt der en modell faktisk styrer et grensesnitt, er nettleseren i en nattjobb. Grunnen er ikke prinsipiell. Det finnes ikke noe API. Kilden har ingen annen vei inn, og det jeg trenger derfra, er verdt brua. Det er også den eneste komponenten som går i stykker jevnlig — en nattjobb som klikker seg gjennom et grensesnitt, vil før eller siden møte en dialogboks som ikke fantes i går, og så står den stille til noen våkner.

Jeg har lært å lese det som et signal snarere enn et problem. Når jeg merker at jeg holder på å sette en modell foran en skjerm, betyr det som regel noe om systemet på den andre siden — at det mangler en vei inn som burde ha vært der. Iblant er den slutningen mer verdt enn dataene jeg var ute etter.

Spørsmålet er ikke det vi stiller

Jeg tror ikke computer use forsvinner, og jeg tror ikke det bør gjøre det. Det finnes for mye innelåst funksjon i verden til at en generell adapter skal bli unødvendig, og i industrien særlig.

Men det er en adapter. Den er svaret på et format, ikke på en oppgave. Og at den ser ut som arbeid — at den er den eneste AI-arbeidsformen et menneske kan følge med blikket og kjenne igjen — gjør den verken mer kapabel eller mindre kostbar.

Det jeg så den kvelden, var en modell som gjorde noe vanskelig på en måte som gjorde det vanskeligere enn det trengte å være. Det er ingen anklage mot modellen. Den gjorde nøyaktig det jeg ba om, og den gjorde det bra. Det var oppgaven som var feil stilt, og det var jeg som stilte den.

Det interessante spørsmålet om en demonstrasjon er ikke om modellen klarer det.

Det er om det er slik det skal gjøres.