Jag satt en kväll och tittade på när GPT-6 Astra använde min dator. Jag sa vad som skulle ske på skärmen, den tittade, den flyttade markören, den klickade. Det fungerade.

Min första reaktion var inte att det var imponerande. Den var att det var slöseri.

Sedan läste jag vad andra skrev om samma sak, och där var reaktionen den motsatta. Det var den stora saken, beviset på att något hade tagit ett steg. Det är den skillnaden den här texten handlar om — för jag tror inte att de som blev imponerade såg fel. De såg samma sak som jag. De mätte den mot något annat.

Det som demonstreras är att en modell kan använda ett gränssnitt byggt för människor. Det är en imponerande teknisk prestation, och det är samtidigt ett dåligt sätt att arbeta. Båda sakerna är sanna samtidigt, och det är därför förvirringen uppstår. Prestationen mäts mot vad modeller klarade i fjol, och mot den måttstocken är den stor. Arbetssättet borde mätas mot hur samma modell arbetar när den får rätt kanal, och mot den måttstocken är den liten.

Men det går inte att se förrän man vet vad den andra kanalen ger. Så jag börjar där.

Så arbetar en agent när den får

Ge en agent ett mål och en form den kan arbeta i, och du får något som inte har någon riktig motsvarighet i mänskligt arbete.

Den arbetar parallellt. Trettio filer är inte trettio saker att hålla i huvudet, det är en enda kontext. Den arbetar uthålligt: samma kontroll på fyrahundra poster utförs på post fyrahundra precis som på post ett, utan den uppmärksamhetsdrift som gör att en människa hittar tre fel av fem på eftermiddagen. Den arbetar exakt — en jämförelse mot ett värde är en jämförelse mot ett värde, inte ett ögonkast. Och den arbetar i maskinhastighet, vilket är den minst intressanta av egenskaperna men den som alla nämner först.

Framför allt kan den backa. Att göra om ett steg kostar nästan ingenting, vilket betyder att den kan pröva sig fram på ett sätt som är oekonomiskt för en människa. Det är den egenskapen som gör att man kan ge den ett mål i stället för en instruktion.

Lägg ihop det och du får en arbetsform med en helt annan kostnadskurva än vår. Det som är dyrt för en människa — repetition, uthållighet, exakthet över volym, att göra om — är billigt för agenten. Det som är dyrt för agenten, omdömet om vad som är värt att göra och förmågan att se när ett svar ser rätt ut men är fel, är det vi är kvar för.

Det är den arbetsformen som är värd något. Det är också den man ger bort.

Ett gränssnitt är en kanal byggd för en muspekare

Ett grafiskt användargränssnitt är inte funktionen. Det är funktionen paketerad för en särskild mottagare.

Vi glömmer det, för vi är mottagaren. En knapp är en operation som fått en form, en placering och en färg därför att en människa ska hitta den på under en sekund. En meny är en beslutsträdstruktur som vikts ihop så att den ryms i korttidsminnet. Ett hovertillstånd finns därför att en hand kan sväva. Spatial layout, ikonografi, gruppering, gråtoner för det inaktiva — allt det är kompression, och kompressionen är optimerad för mänsklig perception. Inget annat.

Under gränssnittet ligger hela tiden den uppackade formen. Filen. Kommandot. API-anropet. Den formen är inte en förenkling av gränssnittet; det är tvärtom gränssnittet som är en översättning av den. Att låta en agent arbeta genom skärmen är att låta den läsa ett fotografi av kalkylbladet i stället för kalkylbladet.

Men det avgörande är inte att formatet är ett annat. Det avgörande är att formatet är seriellt. Ett gränssnitt är byggt för en operatör med en muspekare — någon som kan göra en sak i taget och behöver se resultatet innan nästa. Och varje egenskap i förra avsnittet går förlorad i den kanalen, en efter en.

Parallelliteten först: en muspekare är per definition en. Trettio filer blir trettio sekventiella öppningar. Uthålligheten sedan: varje steg kräver en ny skärmläsning, och varje skärmläsning är ett tillfälle att tolka fel — inte för att modellen är slarvig, utan för att slutledning ur pixlar är osäkrare än en läsning av ett värde. Exaktheten går samma väg. Och att backa, som var nästan gratis, blir plötsligt dyrt, för tillståndet ligger nu i ett gränssnitt som inte har någon ångraknapp för det agenten just gjorde.

Kvar blir hastigheten, och den blir sämre än en människas.

Det viktiga är att det här inte är omognad. Det är lätt att läsa demonstrationen som ett tidigt stadium — långsam nu, snabb sedan. Men flaskhalsen sitter inte i modellen. Den sitter i kanalen. En dubbelt så snabb modell klickar dubbelt så fort genom samma nyckelhål, och nyckelhålet är fortfarande dimensionerat för en hand. Man kan göra adaptern bättre. Man kan inte göra den till något annat än en adapter.

Invändningen är alltså inte att tekniken är dålig. Den är att man betalar för en agent och använder den som en praktikant med en mus.

Varför det ändå är det som visas upp

Och ändå är det den formen som demonstreras, och förklaringen är banal.

Man kan se den. En agent som klickar sig genom ett gränssnitt gör något begripligt. Vi känner igen varje steg, vi ser markören röra sig mot fältet vi själva hade valt, vi ser den tveka, vi ser den lyckas. Vi har en inre modell av vad det kostar att göra samma sak för hand, och den modellen fylls automatiskt med mening.

Det effektiva arbetet ser inte ut som något alls. Ett mål formuleras, ett kommando körs, ett resultat finns. Det finns ingen markör att följa med blicken och ingenting som håller intresset i trettio sekunder.

Så uppstår en skevhet. Den synliga varianten vinner uppmärksamhet, den användbara vinner arbete, och det är inte samma marknad. Uppmärksamhet styr vad som demonstreras på scener, vad som klipps till trettio sekunder, vad investerare tror att tekniken är, och till sist vad en driftschef föreställer sig när någon säger "AI-agent". Det är inget nytt i industrin. Vi har haft trettio år av samma sak med visualiseringstavlor: den tavla som ser bäst ut på ett studiebesök är sällan den som ändrar flest beslut.

Jag har alltså ingen invändning mot att någon blir imponerad. Jag har en invändning mot kriteriet. Frågan "klarade den det?" har ett svar som med tiden alltid blir ja, och som därför slutar bära information. Frågan som bär är enkel att ställa och obekväm att svara på: jämfört med vad?

Ordningen är inte estetisk

Och där kommer jag från annat håll än de flesta som skriver om agentarkitektur.

Det första lean frågar om ett arbetsmoment är inte hur det ska göras snabbare. Det är om det ska finnas. Eliminera, sedan förenkla, sedan — först då — mekanisera. Ordningen är inte en preferens. Den är en försvarsmekanism mot ett bestämt fel: att göra ett onödigt moment permanent genom att bygga infrastruktur runt det.

För det är vad automatisering gör. Ett manuellt slöseri är irriterande, synligt och billigt att avskaffa; någon klagar på det varje vecka. Ett automatiserat slöseri klagar ingen på. Det gör inte ont längre. Det har en ägare, en driftbudget, ett schema och en historik, och att ta bort det är nu ett projekt i stället för ett beslut. Momentet har gått från att vara en kostnad till att vara en tillgång i någons balansräkning. Det är därför förenklingen måste komma före mekaniseringen — inte för att den är finare, utan för att fönstret stängs.

Trappan har tre steg, och AI är det sista. Först förenkla: skala arbetet till det som faktiskt tillför värde, stabilisera processen, få rutinen att sitta. Sedan automatisera: mekanisera det repetitiva när det väl är stabilt — sensorer som mäter, skript som registrerar, spärrar som hindrar fel. Automation gör en stabil process snabbare. Den gör aldrig en instabil process stabil. Och sist, sist, släppa in en modell — där mönster och bedömning betyder något och där de data den behöver redan finns, rena, därför att de två föregående stegen byggdes först.

Varje steg förtjänar nästa. Hoppar man över ett får man en modell tränad på ett processkaos, och det enda den lär sig är att producera mer av det. Sedan får modellen skulden, fast den gör precis vad den lärde sig. Kaoset fanns före modellen. Modellen har bara förstärkt det.

Computer use automatiserar det mänskliga gränssnittet. Men det mänskliga gränssnittet är självt en nödlösning. Det finns därför att en människa var tvungen att komma åt funktionen och pixlar var den enda kanal vi hade. Det är inte processen. Det är processens förpackning för en viss operatör. När vi bygger en agent som klickar i den förpackningen har vi tagit ett moment som existerade av mänskliga skäl och gjort det permanent av tekniska.

Det är att hoppa över de två första stegen och applicera det tredje på en process ingen har förenklat. Man frågar aldrig om klickvägen behövde finnas. Man frågar bara om modellen klarar den.

Och det är där de två sakerna möts. Automatiserar man en klickväg får den ett schema, en ägare och en driftbudget — och därmed ett försvar. Slöseriet blir inte bara kvar. Det blir infrastruktur, och infrastruktur avskaffar man inte, den förvaltar man.

Där det inte finns någon väg in

Och så motbilden, som är minst lika viktig, för utan den är resten en käpphäst.

Computer use är rätt när det inte finns någon annan väg in. Inte "när det är bekvämare". När det inte finns.

Den situationen är inte marginell i tillverkning. Den är normaltillståndet. Ett MES som inte har någon export utöver den rapport någon en gång beställde. En PLC-leverantörs proprietära verktyg där data finns men bara innanför deras eget fönster. En maskins HMI som visar tio parametrar i realtid och skickar noll av dem vidare. En webbtjänst utan API, eller med ett API som kostar mer än problemet. Ett system vars leverantör gått i konkurs och vars integration ingen längre kan beställa.

I alla de fallen är den uppackade formen inte tillgänglig. Den finns — den ligger där, tre lager ner — men den är inlåst bakom ett gränssnitt som är den enda dörren. Då är en agent som läser skärmen inte en omväg. Då är den bron över det som inte går att brygga, och den kan vara det enda som gör en analys möjlig utan ett integrationsprojekt på sex månader.

Skillnaden mellan de två fallen är enkel att formulera och obekväm att svara på: finns det ett annat sätt in? Om ja, är gränssnittsvägen ett val — och nästan alltid ett sämre. Om nej, är den den enda vägen, och då är frågan inte längre vilken arkitektur som är vackrast utan om bron bär.

Vad jag själv kör

Jag har mer skäl än de flesta att vara ärlig här, för mitt eget arbete är evidens åt båda hållen.

Tre saker jag byggt fungerar dagligen: en publiceringspipeline för den här sajten, ett minnessystem som håller kontext mellan sessioner och maskiner, och analysarbete på produktionsdata. Alla tre drivs likadant. Jag formulerar ett mål, jag ger nödvändig kontext, och arbetet utförs mot filer, mot kommandon, mot API:er.

Det konkreta syns tydligast i den första. En utgåva rör ett trettiotal filer i tre språkversioner, och allt ska stämma internt: samma artiklar i alla tre flöden, samma datum, inga oöversatta rubriker som ligger kvar, ingen länk som pekar på gårdagens fil. Det är precis den sortens kontroll som en människa gör slarvigt vid elva på kvällen och som en agent utför identiskt på fil ett och fil trettio. Den öppnar dem inte en i taget för att titta på dem. Den har dem.

Analysarbetet fungerar likadant. Samma kontroll på varje rad i en mätserie, och när något ser fel ut kan den backa och köra om med en annan avgränsning utan att det kostar en eftermiddag. Det är inte snabbhet som är poängen där. Det är att man vågar pröva en tredje och en fjärde hypotes, eftersom det inte längre är dyrt att ha fel.

Inget av det hade fungerat via skärmklick. Inte "hade varit långsammare" — hade inte fungerat.

Och sedan finns undantaget, och det är exakt det undantag motbilden beskriver: det enda stället i hela min uppsättning där en modell faktiskt styr ett gränssnitt är webbläsaren i ett nattjobb. Skälet är inte principiellt. Det finns inget API. Källan har inget annat sätt in, och det jag behöver därifrån är värt bron. Det är också den enda komponent som går sönder regelbundet — ett nattjobb som klickar sig genom ett gränssnitt kommer förr eller senare att träffa på en dialogruta som inte fanns i går, och sedan står det still tills någon vaknar.

Jag har lärt mig läsa det som en signal snarare än ett problem. När jag märker att jag håller på att sätta en modell framför en skärm brukar det betyda något om systemet på andra sidan — att det saknar en väg in som borde ha funnits. Ibland är den slutsatsen mer värd än de data jag var ute efter.

Frågan är inte den vi ställer

Jag tror inte att computer use försvinner, och jag tror inte att det bör göra det. Det finns för mycket inlåst funktion i världen för att en generell adapter ska bli onödig, och i tillverkningsindustrin särskilt.

Men det är en adapter. Den är svaret på ett format, inte på en uppgift. Och att den ser ut som arbete — att den är den enda AI-arbetsform en människa kan följa med blicken och känna igen — gör den varken mer kapabel eller mindre kostsam.

Det jag såg den kvällen var en modell som gjorde något svårt på ett sätt som gjorde det svårare än det behövde vara. Det är ingen anklagelse mot modellen. Den gjorde precis det jag bad om, och den gjorde det bra. Det var uppgiften som var fel ställd, och det var jag som ställde den.

Den intressanta frågan om en demonstration är inte om modellen klarar det.

Den är om det är så det ska göras.