Ju längre jag kommit i utvecklingen av Hivemind, min skräddarsydda RSS-läsare, desto tydligare har det jag resonerat om tidigare under våren blivit. Både kraften i bring your own agent och de säkerhetsmässiga utmaningarna som de tar med sig.
Hivemind är med god marginal den bästa RSS-läsaren jag har använt. Styrkan ligger i det namnet spelar på, att den analyserar innehållet i alla de flöden jag prenumererar på och ge mig en samlad bild av hur snacket går i mitt hörn av internet.
Men ni får lita på mitt ord. Hivemind är nämligen en skräddarsydd lösning som bara finns på min server, med mig som enda användare.
Ju längre jag kommit i utvecklingen, desto tydligare har det jag resonerat om tidigare under våren blivit. Både kraften i bring your own agent och de säkerhetsmässiga utmaningarna som de tar med sig.
Mjukvara med en enda användare #
Jag har alltid gillat mer nischade program från små indie-utvecklare, av två skäl. Programmen är ofta mer fokuserade på att göra en eller ett par saker riktigt bra, istället för att ha en uppsjö med funktioner för att så många som möjligt ska kunna hitta något de gillar. Det innebär i sin tur att man som användare i programmets faktiska målgrupp ofta har möjlighet att få se sina förslag till förbättringar realiserade.
Tack vare Pi och Claude Code går det här nu att ta till sin extrem: Mjukvara med en användarkrets som består av en enda person, utvecklad av och för mig. Allt i Hivemind är anpassat till hur jag vill ha det. Gränssnittets utseende, kopplingen till andra tjänster, hur innehållsanalyserna görs och presenteras.
Och i takt med att bygget fortskrider har sättet som jag jobbar med agenterna förändrats. Allt mer planeringsarbete för att hamna rätt från början. Oftast med de mest kraftfulla modellerna, som sedan får skriva tydliga instruktioner till de enklare, billigare. Med tanke på varthän token-begränsningarna är på väg känns det här åtminstone för stunden som det effektivaste sättet att göra: Planera och kodgranska på abonnemanget, betala bulken av kodskrivandet med API-nycklar där kostnaden är per miljoner förbrukade tokens.
Och så var det riskerna #
Men att ha baxat Hivemind till något användbart, som faktiskt ersatt den RSS-läsare jag använde tidigare, har inte varit friktionsfritt – och framför allt inte utan sin beskärda del av säkerhetsproblem. På vägen har jag/agenterna bland annat läckt lösenord, installerat ett två år gammalt och övergivet funktionsbibliotek med stora säkerhetshål och på grund av otydliga resonemang varit på väg att öppna upp hemmaservern på vid gavel vilket tog stora delar av Kristi himmelfärds dag att komma till rätta med. Varje felsteg en chans att lära, tänker jag, och successivt har agenterna bland annat fått tydligare instruktioner om hur de ska välja kodbibliotek samtidigt som jag ser till att vara mer aktiv i varje beslut när ett nytt blir en del av Hivemind.
Som Claude Opus svarade i en av chattarna när det gamla funktionsbiblioteket skulle bytas ut:
So no, I don't think supply chain is your primary concern. Your primary concern is that you're the sole human reviewer of a codebase where most of the code-writing happens at a confidence level that doesn't match the writer's reliability. Tests are how you turn that confidence into something checkable.
Hur hitta den organisatoriska balansen? #
Det här läget – å ena sidan stor potential, å andra sidan stora säkerhetsmässiga utmaningar – kommer att ställa stora krav på ledarskapet i organisationer. I praktiken har de fallgropar jag och agenterna snubblat ner i inte orsakat någon faktisk skada. Agenterna har till exempel egna lösenord, så när de läckt har det varit en enkel sak att byta dem. De kör dessutom på separat hårdvara, utan tillgång till de datorer där jag har saker jag är rädd om. Där det började bli läskigt på riktigt var hålen som var på väg att öppnas i hemmaservern, men den är redan från start bakom några andra säkerhetslösningar så även det hade nog i praktiken inte spelat någon roll.
Men hur ska det här hanteras på organisatorisk nivå, i ett företag eller en offentlig verksamhet? I AI Sweden Podcast hade jag nyligen Greg Kennedy som gäst, Chief Strategy Officer and Director for AI Operations på SickKids i Toronto, ett av världens främsta barnsjukhus. I avsnittet berättar han xatt de analyserat nätverkstrafiken och kunnat konstatera att personalen både använder de verktyg ledningen köpt in men också en uppsjö andra: Av de tio populäraste var en majoritet inte bland de som ledningen officiellt hade bestämt att personalen ska ha tillgång till. Slutsatsen ledningen drog var att deras ansvar att se till att personalen på ett säkert sätt har tillgång till de bästa AI-verktygen och att de får den fortbildning de behöver. Målsättningen är att minska riskerna på ett sätt som skapar förutsättningar för fortsatt experimenterande, vilket är nödvändigt för att hitta rätt sätt att använda tekniken på sjukhuset.
Vilka verktyg behövs? #
För att den här utvecklingen och användningen av agenter ska landa bra kommer det krävas en kombination av mänsklig förståelse och omdöme och verktyg och andra tekniska lösningar som gör möjligheterna med stora språkmodeller tillgängliga på ett sätt som tar ner riskerna för klavertramp till en acceptabel nivå.
Vi har idag ett spann av verktyg som bygger på språkmodeller som sträcker sig från AI-agenter med full tillgång till hela datorn i ena änden till begränsade chattinterface i webbläsaren i den andra. Agentplattformar som n8n och Googles Workspace Studio är exempel på mellanting som finns lite närmare webbgränssnitten på den skalan.
Men det jag lärt mig under de senaste veckorna är att det finns en hel del att hämta mycket närmare agenterna också. Semgrep och Trivy är två exempel på lösningar som läser igenom kod i jakt på säkerhetsluckor, lösenord som inte borde finnas där och annat. De skannar nu kontinuerligt igenom koden som Pi och Claude Code skriver och varnar då och då när saker är på väg att gå fel.
Inget av det jag skriver ovan är nyheter för en utvecklare. Min poäng är att vi andra också behöver förstå det här, och välja verktyg och arbetssätt därefter. Och komplettera med ny kunskap.