En grön testsvit är inte en granskning
Tester kontrollerar fallen någon tänkte på. En agent som ändrar beteende kan lämna alla befintliga tester gröna, eftersom de bara fäste det gamla beteendet löst eller för att inget täckte vägen. Grönt bevisar att ändringen körs, inte att den är rätt.
Samma sak gäller en prydlig sammanfattning. Agentens beskrivning av vad den gjorde är ett påstående från samma system som gjorde ändringen. Läs diffen, inte följesedeln, och behandla testerna som en signal bland flera.
Börja från ett rent, återställbart läge
Före den första prompten: committa eller stasha arbetet, skapa en branch och vet exakt hur du kommer tillbaka. En kodagent med terminalåtkomst kan köra migreringar, skriva om konfiguration och radera filer; en återställbar startpunkt gör en olycka till en olägenhet.
Rör uppgiften något reglerat eller konfidentiellt, använd en engångskopia av projektet och ett samtal utan hemligheter. Leverantörens villkor och datadokumentation avgör vad som lämnar din dator — läs dem i stället för att anta gränsen.
Läs diffen i den ordning det gör ont
En stor genererad ändring granskas bäst i en medveten ordning i stället för uppifrån och ned.
- Ingångar: rutter, handlers, behörigheter och allt som ändrar vem som når vad.
- Data: schema, migreringar, serialisering och frågor, särskilt allt som raderar eller skriver över.
- Konfiguration: miljövariabler, byggsteg, CI och distributionsinställningar.
- Resten: namngivning, struktur, duplicering och de kosmetiska ändringarna som får en diff att se större ut.
Läs sedan testerna som lades till och fråga vad de inte täcker. En agent som skrev både kod och test kan skriva in samma missförstånd två gånger.
Beroenden, hemligheter och raderna ingen läser
Nya beroenden är den tystaste risken i en genererad patch: ett bekant paketnamn, en version från ingenstans, en lockfil som skrivits om helt. Kontrollera vad som lades till, varför, och om projektet redan hade något som gjorde jobbet.
Scanna efter inloggningsuppgifter, tokens och interna URL:er som inte hör i en commit, och kontrollera att loggningen inte plötsligt skriver ut kunddata. Det är just raderna man skummar, och dem en agent inte har skäl att vara försiktig med: den optimerar för uppgiften, inte för din hotmodell.
När du bör slänga det
Är diffen större än uppgiften, kan du inte förklara ett block utan att gissa, eller löser ändringen symptomet i stället för orsaken, radera branchen. Att börja om med en snävare begäran kostar mindre än att underhålla kod ingen förstår.
Samma regel gäller din prompt: checklistan i vår Manus-guide och strukturråden i vår Prompt Cowboy-guide förkortar båda diffen. Börja med vår översikt av Freebuff för själva produkten, och hur vi hanterar hänvisningslänkar står i vår affiliate-deklaration.
Vanliga frågor
Bör jag låta den köra kommandon i min terminal?+
Terminalåtkomst är det som gör en kodagent användbar och riskabel, och leverantören bestämmer hur behörigheter fungerar. Börja på en engångskopia eller en tillfällig branch, följ de första körningarna noga och håll inloggningsuppgifter utom räckhåll; ett kommando som bara läser filer är en annan begäran än en som deployar.
Räcker en gratis kodagent för riktigt arbete?+
För mekaniskt arbete du kan granska, ja. Gratis är en affärsmodell, inte en kvalitetsgaranti: leverantören finansierar den med reklam och kan ändra modeller, gränser eller funktioner. Det avgörande är om du kan läsa och testa det den producerade, inte priset.
Måste jag berätta att koden skrevs av en agent?+
Följ reglerna för teamet, repot och licensen, och svara ärligt om du tillfrågas. Professionellt är det som räknas att en människa granskat ändringen och står för den; risken är en genererad patch som ingen läst, inte verktyget som skrev den.
Källor och vidare läsning
Leverantörens officiella dokumentation, granskad 2026-10-26. Villkoren kan ändras; kontrollera versionen för ditt land.