Buggtriage med Claude Code med en upprepbar loop: reproducera, minimera, identifiera troliga orsaker, lägg till ett regressionstest och leverera en snäv fix med kontroller.
Buggar känns slumpmässiga när varje rapport blir ett enstaka mysterium. Du petar i koden, provar några idéer och hoppas att problemet försvinner. Ibland gör det det, men du lär dig inte mycket och samma problem dyker upp igen i en annan form.
Buggtriage är motsatsen. Det är ett snabbt sätt att minska osäkerhet. Målet är inte att fixa allt omedelbart. Målet är att omvandla ett vagt klagomål till ett tydligt, testbart påstående och sedan göra den minsta förändringen som bevisar att påståendet är falskt.
Därför spelar loopen roll: reproducera, minimera, identifiera troliga orsaker med evidens, lägg till ett regressionstest, implementera en snäv fix och validera. Varje steg tar bort en specifik typ av gissning. Hoppa över steg och du betalar ofta för det senare med större fixes, sidoeffekter eller “fixade” buggar som aldrig egentligen var fixade.
Här är ett realistiskt exempel. En användare säger: “Spara-knappen gör ibland ingenting.” Utan en loop kanske du rotar i UI-koden och ändrar timing, state eller nätverksanrop. Med en loop gör du först “ibland” till “varje gång, under dessa exakta förhållanden”, till exempel: “Efter att ha redigerat en titel och sedan snabbt bytt flik förblir Spara inaktiverad.” Den meningen är redan framsteg.
Claude Code kan påskynda tankearbetet: att omvandla rapporter till precisa hypoteser, föreslå var man ska titta och föreslå ett minimalt test som bör misslyckas. Det är särskilt hjälpsamt för att skanna kod, loggar och senaste diffs för att snabbt generera plausibla förklaringar.
Du måste fortfarande verifiera vad som betyder något. Bekräfta att buggen är verklig i din miljö. Föredra bevis (loggar, traces, fallande tester) framför en välformulerad berättelse. Håll fixen så liten som möjligt, bevisa den med ett regressionstest och validera med tydliga kontroller så att du inte byter ut en bugg mot en annan.
Vinsten är en liten, säker fix du kan förklara, försvara och hålla fri från regression.
Bra fixes börjar med en ren arbetsyta och ett enda, klart problemformulär. Innan du frågar Claude något, plocka en rapport och skriv om den som:
”När jag gör X förväntar jag mig Y, men jag får Z.”
Om du inte kan skriva den meningen har du ännu ingen bugg. Du har ett mysterium.
Samla det grundläggande direkt så du inte behöver loopa tillbaka. Dessa detaljer gör förslag testbara istället för vaga: appversion eller commit (och om det är lokalt, staging eller produktion), miljödetaljer (OS, webbläsare/enhet, feature-flaggor, region), exakta inputs (formfält, API-payload, användaråtgärder), vem som ser det (alla, en roll, ett konto/tenant) och vad “förväntat” betyder (text, UI-tillstånd, statuskod, affärsregel).
Bevara sedan bevisen medan de är färska. En enda tidsstämpel kan spara timmar. Fånga loggar kring händelsen (klient och server om möjligt), en skärmdump eller kort inspelning, request- eller trace-ID:n, exakta tidsstämplar (med tidszon) och det minsta datautdrag som triggar problemet.
Exempel: en Koder.ai-genererad React-app visar “Payment succeeded” men ordern förblir “Pending.” Notera användarroll, exakt order-ID, API-svars-body och serverloggar för det request-ID:t. Nu kan du be Claude att fokusera på ett flöde istället för vagt prat.
Sätt slutligen en stoppregel. Bestäm vad som räknas som åtgärdat innan du börjar koda: ett specifikt test som passerar, ett UI-tillstånd som ändras, ett fel som inte längre syns i loggarna, plus en kort valideringschecklista du kör varje gång. Det hindrar dig från att “fixa” symptomet och släppa ut en ny bugg.
En rörig buggrapport blandar ofta fakta, gissningar och frustration. Innan du ber om hjälp, konvertera den till en knivskarp fråga Claude kan svara på med evidens.
Börja med en enradig sammanfattning som namnger funktionen och felet. Bra: “Att spara ett utkast tar ibland bort titeln på mobil.” Inte bra: “Utkast är trasiga.” Den meningen blir ankaret för hela triagetråden.
Separera sedan vad du såg från vad du förväntade dig. Håll det tråkigt och konkret: exakta knappar du klickade på, meddelandet på skärmen, loggrad, tidsstämpel, enhet, webbläsare, branch, commit. Om du inte har dem än, skriv det.
En enkel struktur du kan klistra in:
Om detaljer saknas, fråga dem som ja/nej-frågor så folk kan svara snabbt: Händer det på ett färskt konto? Bara på mobil? Endast efter en refresh? Började det efter senaste releasen? Kan du reproducera i inkognito?
Claude är också användbar som en “rapportsanering.” Klistra in originalrapporten (inklusive text kopierad från skärmdumpar, loggar och chattutdrag) och be:
”Skriv om detta som en strukturerad checklista. Flagga motsägelser. Lista de fem viktigaste saknade fakta som ja/nej-frågor. Gissa inte orsaker ännu.”
Om en kollega säger “Det fallerar slumpmässigt”, tryck vidare mot något testbart: “Faller 2/10 gånger på iPhone 14, iOS 17.2, när man trycker Spara två gånger snabbt.” Nu kan du reproducera det med avsikt.
Om du inte kan få buggen att hända på begäran är varje nästa steg gissning.
Börja med att reproducera i den minsta miljön som fortfarande visar problemet: en lokal dev-build, en minimal branch, ett litet dataset och så få tjänster igång som möjligt.
Skriv ner exakta steg så någon annan kan följa dem utan att fråga. Gör det copy-paste-vänligt: kommandon, ID:n och exempelpayloads ska inkluderas exakt som använd.
Ett enkelt fångsttemplate:
Frekvens ändrar din strategi. “Alltid”-buggar är utmärkta för snabb iteration. “Ibland”-buggar pekar ofta på timing, caching, race conditions eller dold state.
När du har reproduktionsanteckningar, be Claude om snabba sonder som minskar osäkerhet utan att skriva om appen. Bra sonder är små: en riktad loggrad runt felgränsen (inputs, outputs, nyckelstate), en debug-flagga för en komponent, ett sätt att tvinga deterministiskt beteende (fixad seed, fixad tid, en worker), ett litet seed-dataset som triggar problemet, eller en enstaka request/response att spela upp.
Exempel: ett signup-flöde fallerar “ibland.” Claude kan föreslå att logga genererat user ID, e-postnormaliseringsresultat och unique constraint-fel, och sedan köra samma payload 10 gånger. Om felet bara händer vid första körningen efter deploy är det en stark ledtråd att kolla migrationer, cache-warmup eller saknad seed-data.
En bra reproduktion är användbar. En minimal reproduktion är kraftfull. Den gör buggen snabbare att förstå, enklare att debugga och mindre benägen att “fixas” av misstag.
Strippa bort allt som inte krävs. Om buggen dyker upp efter ett långt UI-flöde, hitta den kortaste vägen som fortfarande triggar den. Ta bort valfria skärmar, feature-flaggor och irrelevanta integrationer tills buggen antingen försvinner (du tog bort något väsentligt) eller består (du hittade brus).
Krymp sedan datan. Om buggen kräver en stor payload, prova den minsta payload som fortfarande bryter. Om den kräver en lista på 500 objekt, se om 5 fallerar, sedan 2, sedan 1. Ta bort fält ett i taget. Målet är så få rörliga delar som möjligt som fortfarande reproducerar buggen.
En praktisk metod är “ta bort hälften och testa igen”:
Exempel: en checkout-sida kraschar “ibland” när en kupong appliceras. Du upptäcker att det bara händer när kundvagnen har minst en rabatterad vara, kupongen innehåller gemener och leverans är satt till “upphämtning.” Det är ditt minimala fall: en rabatterad vara, en gemen kupong, en upphämtningsmetod.
När minimalfallet är klart, be Claude om att göra det till ett litet reproduktionsstomme: ett minimalt test som anropar den felande funktionen med minsta inputs, ett kort skript som träffar ett endpoint med reducerad payload, eller ett litet UI-test som besöker en rutt och gör en åtgärd.
När du kan reproducera problemet och har ett litet testcase, sluta gissa. Målet är att landa på en kort lista av plausibla orsaker och sedan bevisa eller förkasta var och en.
En användbar regel är att hålla det till tre hypoteser. Om du har fler är ditt testcase troligen fortfarande för stort eller dina observationer för vaga.
Översätt vad du ser till var det kan hända. Ett UI-symptom är inte alltid ett UI-fel.
Exempel: en React-sida visar en “Saved”-toast men posten saknas senare. Det kan peka på (1) UI-state, (2) API-beteende eller (3) databas-skrivvägen.
Be Claude förklara troliga felmodi på enkel svenska, och fråga sedan vilken bevisning som skulle bekräfta varje en. Målet är att förvandla “kanske” till “kolla detta exakta.”
Tre vanliga hypoteser och vad som bevisar dem:
Håll dina anteckningar tighta: symptom, hypotes, evidens, dom. När en hypotes matchar fakta kan du låsa in ett regressionstest och endast fixa vad som är nödvändigt.
Ett bra regressionstest är din säkerhetssele. Det bevisar att buggen finns och berättar när du verkligen fixat den.
Börja med att välja det minsta testet som matchar det verkliga felet. Om buggen bara uppstår när flera delar samverkar kan ett enhetstest missa det.
Använd unit-test när en enskild funktion returnerar fel. Använd integrationstest när gränssnittet mellan delar är problemet (API-handler plus DB, eller UI plus state). Använd end-to-end endast när buggen beror på hela användarflödet.
Innan du ber Claude skriva något, formulera det minimerade fallet som ett strikt förväntat beteende. Exempel: “När användaren sparar en tom titel ska API:t returnera 400 med meddelandet ‘title required’.” Nu har testet ett tydligt mål.
Be sedan Claude utforma ett fallande test först. Håll setup minimal och kopiera bara den data som triggar buggen. Namnge testet efter vad användaren upplever, inte den interna funktionen.
Gör en snabb granskning själv:
När testet fallerar av rätt anledning är du redo att implementera en snäv fix med förtroende.
När du har ett litet repro och ett fallande regressionstest, stå emot frestelsen att “städa upp.” Målet är att stoppa buggen med minsta ändring som får testet att passera av rätt anledning.
En bra snäv fix ändrar så liten yta som möjligt. Om felet finns i en funktion, fixa den funktionen, inte hela modulen. Om en gränskontroll saknas, lägg kontrollen vid gränsen, inte i hela kedjan.
Om du använder Claude för hjälp, be om två fixalternativ och jämför dem för omfattning och risk. Exempel: om ett React-form kraschar när ett fält är tomt kan du få:
Alternativ A är oftast triagevalet: mindre, lättare att granska och mindre risk att något annat bryts.
För att hålla fixen snäv, rör så få filer som möjligt, föredra lokala fixes framför refaktorer, lägg till guards/valideringar där det dåliga värdet kommer in och gör beteendeförändringen explicit med ett klart före/efter. Lämna kommentarer bara när anledningen inte är uppenbar.
Konrekt exempel: ett Go-API endpoint panikar när en valfri query-param saknas. Den snäva fixen är att hantera tom sträng vid handler-gränsen (parse med default eller returnera 400 med tydligt meddelande). Undvik att ändra delad parsing-utility om inte regressionstestet bevisar att felet ligger i den delade koden.
Efter ändringen, kör det fallande testet och ett par intilliggande tester. Om din fix kräver att många orelaterade tester uppdateras är det en signal att ändringen är för bred.
Validering fångar små, lätta att missa problem: en fix som passerar ett test men bryter en närliggande väg, ändrar ett felmeddelande eller lägger till en långsam query.
Kör först det regressionsprov du lade till. Om det passerar, kör närmaste grannar: tester i samma fil, samma modul och allt som täcker samma inputs. Buggar gömmer sig ofta i delade helpers, parsing, gränskontroller eller caching, så relevanta fel brukar visa sig nära.
Gör sedan en snabb manuell kontroll med ursprungliga repro-steg. Håll det kort och specifikt: samma miljö, samma data, samma klick- eller API-sekvens. Om rapporten var vag, testa det exakta scenario du använde för att reproducera.
Om du vill ha hjälp att hålla fokus, be Claude om en kort valideringsplan baserad på din ändring och det fallande scenariot. Dela vilken fil du ändrade, vilket beteende du avsåg och vad som plausibelt kan påverkas. De bästa planerna är korta och genomförbara: 5–8 kontroller du kan göra på några minuter, var och en med klart pass/fail.
Slutligen, dokumentera vad du validerade i PR:en eller i anteckningar: vilka tester du körde, vilka manuella steg du provade och eventuella begränsningar (t.ex. “testade inte mobil”). Det gör fixen enklare att lita på och enklare att återbesöka senare.
Det snabbaste sättet att slösa tid är att acceptera en “fix” innan du kan reproducera problemet på begäran. Om du inte kan få det att falla på begäran vet du inte vad som faktiskt förbättrats.
En praktisk regel: be inte om fixes förrän du kan beskriva en repeterbar setup (exakta steg, inputs, miljö och vad som är “fel”). Om rapporten är vag, spendera de första minuterna på att omvandla den till en checklista du kan köra två gånger och få samma resultat.
Fixar utan reproducerbart fall. Kräv ett minimalt “faller varje gång”-skript eller uppsättning steg. Om det bara fallerar “ibland”, samla timing, datastorlek, flaggor och loggar tills det slutar vara slumpmässigt.
Minimera för tidigt. Om du strimlar fallet innan du bekräftat originalfelet kan signalen försvinna. Lås först baseline-repro, krymp sedan en ändring i taget.
Låta Claude gissa. Claude kan föreslå sannolika orsaker, men du behöver fortfarande evidens. Be om 2–3 hypoteser och exakt vilka observationer som skulle bekräfta eller avfärda var och en (en loggrad, ett breakpoint, ett query-resultat).
Regressionstester som passerar av fel anledning. Ett test kan “passera” eftersom det aldrig når den felande vägen. Se till att det fallerar före fixen och att det fallerar med väntat meddelande eller assertion.
Behandla symptom istället för triggern. Om du lägger till en null-check men verkliga problemet är “det här värdet ska aldrig vara null” kan du dölja en djupare bugg. Föredra att fixa villkoret som skapar det dåliga state:t.
Kör nya regressionstestet och ursprungliga repro-steg före och efter din ändring. Om en checkout-bugg bara händer när en kampanjkod appliceras efter ändrad leveransmetod, behåll den fulla sekvensen som din “sanning”, även om ditt minimerade test är mindre.
Om din validering bygger på “det ser bra ut nu”, lägg till en konkret kontroll (en loggrad, en metric eller ett specifikt output) så nästa person snabbt kan verifiera det.
När tiden är knapp slår en liten, repeterbar loop heroisk debugging.
Skriv slutgiltigt beslut i några rader så nästa person (ofta framtida du) kan lita på det. Ett användbart format är: “Rotorsak: X. Trigger: Y. Fix: Z. Varför säker: W. Vad vi inte ändrade: Q.”
Nästa steg: automatisera det du kan (ett sparat repro-skript, ett standardtestkommando, en mall för rotorsaksanteckningar).
Om du bygger appar med Koder.ai (koder.ai), kan Planning Mode hjälpa dig att skissera ändringen innan du rör koden, och snapshots/rollback gör det enklare att experimentera säkert medan du jobbar igenom en knepig repro. När fixen är validerad kan du exportera källkoden eller distribuera och hosta den uppdaterade appen, även med en anpassad domän om det behövs.
Buggtriage är vanan att omvandla en vag rapport till ett klart, testbart påstående och sedan göra den minsta förändringen som bevisar att påståendet inte längre gäller.
Det handlar mindre om att “fixa allt” och mer om att minska osäkerhet steg för steg: reproducera, minimera, formulera evidensbaserade hypoteser, lägga till ett regressionstest, fixa snävt, validera.
För att varje steg tar bort en annan sorts gissning:
Skriv om det som: “När jag gör X förväntar jag mig Y, men jag får Z.”
Samla sedan precis så mycket kontext att det blir testbart:
Börja med att bekräfta att du kan reproducera det i den minsta miljön som fortfarande visar problemet (ofta lokal dev med ett litet dataset).
Om det är “ibland”, försök göra det deterministiskt genom att kontrollera variabler:
Rör dig inte vidare förrän du kan få det att falla på begäran; annars gissar du bara.
Minimering betyder att ta bort allt som inte krävs samtidigt som buggen består.
En praktisk metod är “ta bort hälften och testa igen”:
Krymp både steg (kortare användarflöde) och data (mindre payload, färre fält/punkter) tills du har det minsta repeterbara triggern.
Använd Claude Code för att snabba upp analysen, inte som en ersättning för verifiering.
Bra förfrågningar ser ut som:
Sedan validerar du: reproducera lokalt, kolla loggar/traces och bekräfta att testet fallerar av rätt anledning.
Håll det till tre. Fler än så betyder ofta att ditt repro fortfarande är för stort eller att dina observationer är vaga.
För varje hypotes skriv:
Välj minsta testnivå som matchar felet:
Ett bra regressionstest:
Gör den minsta förändringen som får det felande regressionstestet att passera.
Tumme-råd:
Om din fix tvingar många icke-relaterade testuppdateringar är den troligen för bred.
Använd en kort checklista som du kan köra snabbt:
Skriv ner vad du körde och vad du inte testade så resultatet blir trovärdigt.
Det tvingar fram framsteg och förhindrar ändlösa “kanske det är X”-debuggar.
