Autocomplete löser inte buggar

Klockan är 09:14 på en tisdag. Sentry larmar: TypeError: Cannot read property 'url' of undefined. 340 användare påverkade. Felet ligger i profilvyn.

Vad händer nu?

Någon ser notisen i Slack. Någon öppnar Sentry och läser stack tracet. Någon går till GitHub och letar efter vilka commits som rörde den filen senast. Någon öppnar repot lokalt, byter branch, kör upp miljön. Någon skriver tre rader kod. Någon öppnar en PR. Någon skriver ett ärende i ClickUp så att det går att följa upp.

Oftast är det samma person. Och av de fyra timmarna som den genomsnittliga buggen tar att lösa gick kanske fem minuter åt till att faktiskt skriva fixen.

Resten var transport.

Problemet är inte att skriva koden

De senaste årens AI-verktyg har blivit extremt bra på en sak: att föreslå kod när du redan sitter i editorn, redan har rätt fil öppen, redan vet vad som är fel.

Det är ett verkligt värde. Men lägg märke till hur många "redan" som krävs innan det blir användbart.

Kodförslag hjälper dig i det sista steget. De hjälper dig inte med felsökningen, inte med att hitta rätt fil, inte med att förstå vilken commit som introducerade regressionen, inte med att köra testsviten och inte med att paketera resultatet så att en kollega kan granska det.

Med andra ord: de hjälper dig med de fem minuterna. Inte med de fyra timmarna.

Det är därför utvecklare fortfarande lägger ungefär 30 procent av sin vecka på buggrapporter trots att varje editor numera har en AI-assistent inbyggd. Flaskhalsen flyttade aldrig. Den satt aldrig i tangentbordet.

Flaskhalsen är kontextväxlingen

Varje steg i kedjan ovan är ett verktygsbyte. Sentry, GitHub, terminalen, ClickUp, tillbaka till Sentry för att verifiera. Varje byte kostar fokus, och fokus är det dyraste ett ingenjörsteam har.

Det värsta är inte tiden i sig. Det värsta är att avbrottet är oplanerat. En bugg kommer in mitt i ett djupt arbetspass, och den som tar den tappar en halvdag som egentligen var avsatt för något annat.

Du kan inte schemalägga bort det. Du kan bara flytta arbetet någon annanstans.

Vad som händer när en agent äger hela kedjan

Metis börjar inte i editorn. Den börjar vid triggern.

Ett fel dyker upp i Sentry. En uppgift taggas i ClickUp. Ett cron-schema går igång. En annan agent lämnar över. Oavsett vilket startar samma kedja:

Den läser felet. Stack trace, påverkade användare, vilken miljö, hur ofta det inträffar.

Den läser din kod. Inte en generisk uppfattning om hur React brukar se ut — ditt repo, dina filer, dina senaste commits. Den jämför när felet började uppstå med vad som faktiskt ändrades, och landar i en grundorsak snarare än en gissning.

Den skriver fixen. I en isolerad miljö, och sedan kör den dina riktiga tester. Inte för att intyga att koden är vacker, utan för att visa att inget annat gick sönder.

Den öppnar en PR. Med ändringen, en förklaring av vad som var fel och varför, samt testresultaten.

Från larm till öppen pull request: 45 sekunder.

Men siffran är inte poängen. Poängen är att ingen i teamet behövde byta kontext för att komma dit.

Pull requesten är gränsen — med flit

Det hade varit tekniskt enklare att låta agenten merga själv. Vi har valt att inte göra det, och det är ett medvetet designbeslut snarare än en begränsning vi inte kommit runt än.

En pull request är den punkt där maskinarbete blir mänskligt beslut. Den är granskningsbar, kommenterbar och möjlig att stänga. Den lämnar spår. Den tvingar fram ett ja från någon som bär ansvaret.

Tänk på Metis som din mest kapabla juniorutvecklare: snabb, outtröttlig, läser kodbasen noggrannare än de flesta — och lämnar alltid ifrån sig arbetet för granskning innan det går vidare.

Därför lägger agenten också ned arbete på att förklara sig. En PR som bara innehåller en diff flyttar bara problemet: nu måste någon annan räkna ut vad som hände. En PR som förklarar grundorsaken gör teamet lite bättre på kodbasen varje gång.

Det är också varför agenternas behörigheter är avsiktligt smala. De läser kod och öppnar pull requests. De kommer inte åt hemligheter, de driftsätter ingenting och de rör aldrig produktion. Autonomi utan räckvidd är en betydligt tryggare sak att ha i sin stack.

Buggar är bara det första arbetsflödet

Buggfixning är en bra startpunkt eftersom problemet är tydligt avgränsat: det finns en trigger, ett mätbart resultat och ett naturligt överlämningsögonblick.

Men mönstret är allmänt. Något händer → en agent läser kontexten → agenten utför arbetet → en människa godkänner.

Det mönstret passar betydligt fler saker än buggar. Beroendeuppdateringar. Rutinmässiga refaktoreringar. Triagering av inkommande ärenden. QA-körningar inför release. Allt som är repetitivt, kontextberoende och tråkigt nog att skjutas upp till på fredag.

Därför är Metis byggt som en agentplattform och inte som ett buggfixarverktyg. Du kopplar agenter till dina repon, ansluter dina verktyg, bestämmer vad som triggar dem och låter dem jobba. Allt från adminpanelen, utan kod.

Integrationerna fungerar likadant. Sentry, GitHub och ClickUp finns inbyggt, Linear och Jira är på väg — och vilket annat verktyg som helst kopplas in via MCP och plockas upp direkt av agenten. Ingen egen limkod, inga väntetider på att vi ska bygga just din koppling.

Och agenterna glömmer inte. Ge feedback en gång på namnkonventioner, kodstandarder eller hur ni vill att en PR ska se ut, så sitter det kvar till nästa gång.

Det vi egentligen bygger

Mycket av samtalet om AI och kod handlar om huruvida modellerna kan skriva bra kod. Det är fel fråga vid det här laget. De kan.

Den intressanta frågan är vem som bär arbetet mellan problem och lösning — all den där transporten mellan verktyg, flikar och sammanhang som ingen någonsin skrev in i en sprintplanering men som ändå äter upp en tredjedel av veckan.

Vi tycker att den delen ska vara automatiserad, och att människor ska vara kvar där omdömet behövs: i granskningen, i arkitekturen, i besluten om vad som ska byggas härnäst.

Nästa gång Sentry larmar klockan 09:14 behöver ingen byta kontext. Pull requesten ligger redan där när ni öppnar datorn.

Metis är i tidig tillgång. Få tidig tillgång och låt oss ta nästa bugg.