När din utvecklingsmiljö ändrar sig själv

Samma prompt, samma projekt, två Claude-modeller, men bara den ena använder sina agenter. Förklaringen visade sig vara en enda rad. En rad som ingen av oss någonsin installerat.

I en tidigare artikel skrev vi om hur utvecklarrollen förändras med agentisk kodning. En sak som inte förändras: värdet av det du redan kan. Felsökning, testning, verifiering – den erfarenheten är minst lika användbar när det som beter sig oväntat inte är din kod, utan verktyget som skriver den. Här är ett praktiskt exempel att ta med sig på resan mot att bli en agentisk kodare.

Ett mysterium i produktionsmiljön

Vi bygger en stor del av vårt arbetsflöde i Claude Code: specialiserade agenter som granskar loggar, letar efter kodmönster och sammanställer status inför release. En dag slutade en session använda dem. Assistenten gjorde allt själv, långsammare och sämre.

I stället för att rycka på axlarna ("AI:n har en dålig dag") felsökte vi det som vilken regression som helst:

Kontrollerat A/B-test

Samma prompt, samma katalog, olika modeller. Beteendet följde modellen, inte sessionen, inte versionen av verktyget, inte anslutningssättet.

Hypoteser uteslöts en i taget

Med körningar som gick att upprepa.

Rotorsaken var en fjärrkonfigurerad komponent

Sessioner som kör Claude Opus 5 — men ingen annan modell — får en extra rad i systemprompten: delegera inte till agenter "om inte användaren bett om det". Raden kommer inte från den installerade programvaran, utan aktiveras på distans av en konfigurationsflagga (tengu_heron_brook) som Anthropic styr. Den syns varken i inställningar, dokumentation eller ändringslogg. Vi har bidragit med våra mätningar till den öppna felrapporten hos Anthropic.

Beroenden som ändras utan versionering

Det här fallet pekar på något större än en enskild bugg. I klassisk utveckling är beroenden förutsägbara: ett ramverk ändrar inte subtilt beteende utan en versionsbump, en ändringslogg och en medveten uppgradering. Det är så självklart att vi sällan tänker på det.

En AI-assistent i utvecklarflödet är ett beroende av en annan sort. Själva modellen är låst till sin version, men lagren runt omkring, som systemprompter och verktygsintegration, kan konfigureras om på distans av leverantören. Ingen ny binär laddas ner, inget versionsnummer tickar upp, ingen ändringslogg publiceras. Det var precis vad som hände här: ändringen var i sig helt deterministisk och enkel att återskapa när vi väl hittat den. Problemet var att den var osynlig, odokumenterad, oversionerad och aktiverad utan att någonting installerats.

Agentisk utveckling rymmer alltså två sorters godtycklighet. Modellens: svaren är probabilistiska, samma prompt kan ge olika resultat. Och toolingens: leverantören kan konfigurera om beteendet på distans, utan förvarning. Källorna är olika, men effekten är densamma: beteendet ändras utan att du ändrat något. Och de förstärker varandra – modellens naturliga brus gör toolingens tysta ändringar svårare att upptäcka. Just därför räcker inte magkänsla; det krävs baslinjer och mätning för att alls se att något hänt.

Det gör inte agentisk utveckling omöjlig, men det gör den till en ingenjörsdisciplin. Och den goda nyheten: det är en disciplin utvecklare redan behärskar. Mäta, testa, versionshantera. Vi behöver bara rikta den mot ett nytt objekt: verktygskedjans beteende.

Tre lärdomar

➔ AI-verktygen är en del av produktionsmiljön

När beteendet ändras förtjänar det samma metodik som all annan felsökning: reproducera, isolera variabler, hitta rotorsaken. "Modellen är väl sådan" är sällan hela svaret.

➔ Explicit slår implicit

Instruktioner som fanns nedskrivna i projektet överlevde den här typen av begränsningar; det som bara "brukade hända" gjorde det inte. Skriv ner arbetsflödena i projektfiler, inte i huvudet.

➔ Behandla modellen som ett beroende, för det är den

Konkret innebär det:

Lås modellversioner där leverantören erbjuder det.
Bygg en liten svit beteendetester: kanoniska uppgifter som körs vid varje modellbyte och verifierar att agenter anropas, att format håller och att kvaliteten inte försämras. Regressionstester för arbetsflödet, inte bara koden.
Etablera baslinjer: agentanrop, tokenförbrukning, tid per uppgift. Drift ska vara mätbar, inte en magkänsla.
Kör kanariesessioner: låt en person arbeta med en ny modellversion innan hela teamet byter.

Din erfarenhet är en tillgång, inte bagage

Om du är utvecklare och känner dig osäker inför agentisk kodning: det här fallet visar varför du har ett försprång. Reproducerbarhet, isolering av variabler, mätning före magkänsla — allt du lärt dig av att felsöka system i produktion gäller fortfarande. Skillnaden är att objektet du verifierar har flyttat en abstraktionsnivå upp: från koden, till verktyget och arbetsflödet som producerar den.

Verktygen är nya. Disciplinen är din sedan länge. Ta med den.