Experimenterandet med AI-agenter fortsätter. Och i takt med att jag lär mig mer vill jag också använda dem till mer. I andra vågskålen ligger riskerna för att de gör fel eller faktiskt orsakar skada. Här är tre principer jag använder mig av nu för att försöka minimera riskerna till en nivå som fortfarande låter mig testa.
För mig handlar användningen av AI-agenter om att hitta tillit till dem på tre olika nivåer:
Det enklaste steget – eller åtminstone det som jag känner igen sedan tidigare – handlar om tillit till programmet i sig självt: Gör det vad det utger sig för att göra och inget annat? Är det bara en AI-agent eller är det i själva verket en trojansk häst som kommer att kryptera min hårddisk i en ransomware-attack eller göra den till en del av ett botnät?
Det här hanteras genom en mix av källkritik och verktyg. Jag installerar bara program från företag eller personer jag litar på och ser till att jag laddar ner mjukvaran från rätt ställe.
Och när jag kör dem direkt i min dator, där de får tillgång till stora delar av det som finns på hårddisken, är Little Snitch med och övervakar vad de hittar på på nätet. Little Snitch är en utmärkt brandvägg för MacOS som jag använt i många år. Den håller koll på vilka servrar programmen i datorn försöker komma åt, visar tydliga varningsrutor när ett program försöker sig på något nytt och låter mig bestämma om det är okej eller inte.
Men AI-agenterna kör jag just nu inte direkt i MacOS. Det som skiljer dem från traditionell mjukvara är att de inte bara kommer att följa utvecklarnas instruktioner. Hela anledningen till hypen kring AI-agenter är ju att de får en språkmodell som “hjärna” som fattar beslut utifrån de instruktioner som användaren skriver i sina prompter.
Det innebär att den kan hitta på dumma saker även om det inte varit utvecklarnas intentioner. Den kan till exempel få för sig att skriva ett kommando som raderar hårddisken eller bli lurad av en prompt injection i en text den läser på nätet och försöka skicka mina lösenord till en server någonstans på nätet. (Bruce Schneier skrev bra om just den utmaningen i höstas, Agentic AI’s OODA Loop Problem.)
Så hur hantera det här? Just nu gör jag ett par saker:
Och självklart kan virtualisering användas även för att hantera den första nivån, tillit till programvaran i sig själv: Är du osäker, kör den i en simulerad dator istället för din riktiga.
En sak som jag inte testat än, men som nog är ett kommande steg, är en hybrid mellan att köra agenten direkt i MacOS och i en virtualiserad maskin. Jag har sett lösningar som ser till att agentens kommandon körs i en så kallad sandlåda, medan agenten själv finns i datorns faktiska operativsystem. Det blir ett sätt att i realtid begränsa vad agenten kan göra, men samtidigt ge den tillgång till information som bara finns på “värddatorns” hårddisk. På det här sättet kan man exempelvis ge agenten access att läsa dokument, men inte ändra i dem eller skapa nya.
I sista steget finns tilliten till det agenten lämnar ifrån sig. För vissa av uppgifterna de får hjälpa mig med – som feedback på texterna jag skriver – handlar det om samma förhållningssätt som när jag jobbar direkt med ChatGPT, Claude eller Gemini: Att vara vaksam på hallucinationer och faktafel i det jag får tillbaka.
Det som är lurigare, särskilt för en icke-utvecklare som jag, är motsvarande hallucinationsrisk när agenten och jag jobbar med programkod. De kod-projekt som Pi och Claude Code hjälper mig med är mycket mer avancerade än att jag själv fullt ut förstår hur koden fungerar. Finns det allvarliga buggar som kommer få min dator att krascha? Har agenten valt att använda tredjeparts-bibliotek som innehåller malware eller öppnar min kod för intrång?
Bug-problematiken går än så länge, med de lite mindre projekt jag har igång, bra att hantera med hjälp av språkmodellerna själva. Den största delen av koden låter jag lite enklare modeller skriva, och sen får de mest kraftfulla, som Anthropics Opus, då och då titta igenom koden, förklara för mig hur den fungerar och komma med förslag på förbättringar. Sen blir det en ny vända med de enklare modellerna som får ta sig an förslagen innan en ny vända kod-koll. Och så vidare.
Risken för sårbarheter i tredjeparts-bibliotek hanteras delvis på samma sätt, med att jag ber Opus kolla om de bibliotek som används är okej. Men Opus och Gemini har också skrivit några kortare script som bland annat jämför de bibliotek som används i den genererade koden med kända sårbarheter i OSV.dev. I Pi har jag en skill (en “specialprompt”) som triggas automatiskt varje gång agenten vill lägga till ett nytt bibliotek och som gör säkerhetskollen innan det läggs till i min kod.
Det här är det mindset och de förhållningssätt jag landat i för tillfället. Men AI-agenterna är nya, både för mig och för alla andra. Principerna ovan ska dessutom omsättas i praktiken. Och här verkar vad som är best practices förändras i snabb takt, med nya verktyg och metoder på löpande band.
Så jag är nyfiken. Vilka luckor finns i mitt förhållningssätt på en generell nivå? Och vilka praktiska lösningar använder du?
Och apropå AI-agenter:
”The asymmetry is the scaffold signal: on 69 exercises, the model is demonstrably capable of producing a passing solution, and the scaffold does not reach that solution. The inverse cell, where Aider succeeds and little-coder fails, is about six times smaller.”
Intressant jämförelse av ramverk för AI-agenter istället för jämförelse av underliggande språkmodell: Om en liten modell styrs av ett ramverk som är anpassat för den, snarare än för en kraftfullare modell, ökar prestandan rejält.
Trevlig söndag!
/Anders