Kontroller mot slarvig AI-kod

Agenter skriver trovärdig kod snabbt, men ibland tar de genvägar som en noggrann ingenjör inte skulle ta: hoppar över ett test för att få grönt, ignorerar ett fel, lämnar kvar en stub, tystar en typkontroll eller skapar ett andra sätt att göra något som din kodbas redan gör. anti-slop-kontrollen letar efter sådant i varje ändring och skickar tillbaka ändringen till utvecklaragenten innan du får se den.

Den är en kontroll i din kvalitetspolicy, inte ett separat betyg. En ändring klarar kontrollen om den inte introducerar något blockerande.

Det här letar kontrollen efter#

Reglerna är grupperade i kategorier. Varje regel antingen blockerar, ger råd eller registrerar information.

• Tester – fokuserade eller överhoppade tester, borttagna tester, borttagna eller försvagade kontrollpåståenden, tester som inte kan misslyckas.
• Undertryckningar – nya avstängningar av lint-regler, ignorering av typfel och any typkonverteringar.
• Bygge och CI – teststeg som tagits bort eller neutraliserats, sänkta gränsvärden, ”godkänt utan tester”.
• Testunderlag – cachelagrade resultat som framställs som en testkörning, noll körda tester, en ofullständig körning som rapporteras som slutförd.
• Produktionskod – kvarlämnad felsökningskod, platshållare, mockdata, anteckningar till människor, testkod som levereras.
• Felhantering – ignorerade fel, reservlösningar som döljer fel, behörighetskontroller som släpper igenom vid fel.
• Kommentarer, Arkitektur, Beroenden, Ändringens omfattning, Säkerhet, Cachelagring och agentens spår – loggen över vad agenten gjorde, till exempel att redigera ett test direkt efter att det misslyckats.

Regelns sida i Kvalitet → Kontroller → Anti-slop visar vad regeln fångar upp och varför det spelar roll.

Bara det som ändringen introducerar blockerar#

De flesta kodbaser innehåller redan några av de här mönstren. Anti-slop delar in varje iakttagelse i en av tre grupper:

• Nya – tillkom i den här ändringen.
• Berörda – fanns redan, på en rad eller i en funktion som ändringen redigerar.
• Befintliga – på andra ställen i kodbasen.

Bara en ny iakttagelse från en blockerande regel gör att kontrollen misslyckas. Berörda och befintliga iakttagelser registreras så att du kan se din tekniska skuld, men de fördröjer aldrig orelaterat arbete. Att flytta kod räknas inte som att introducera den; att kopiera den gör det.

Lägg till i en policy#

Öppna en policy i Kvalitet → Policyer och välj Lägg till förinställning för anti-slop. Den lägger till fem förväntningar:

1. Tester bekräftar fortfarande att ändringen fungerar.
2. Inget ofärdigt eller testspecifikt levereras.
3. Ingen ny strukturell skuld.
4. Ändringen håller sig inom ramarna och följer kodbasens stil.
5. Nya beroenden är relevanta och välrenommerade.

Publicera policyn, så ingår kontrollen i nästa körning för varje anslutet projekt.

Välj ändringsdisciplin#

Disciplinen talar om för utvecklaragenten hur långt en ändring får gå:

• Kirurgisk – bara det specifikationen kräver; andra problem rapporteras, men åtgärdas inte.
• Balanserad (standard) – åtgärda också små problem på rader som ändringen ändå berör.
• Återställande – rensa också upp iakttagelser i funktioner som ändringen redigerar.

Agenten följer samma regler innan den skickar in ändringen: den får disciplinen och dina mönster i karantän i förväg, ser de snabba reglerna efter varje redigering och får en chans att åtgärda blockerande iakttagelser före QA.

Anpassa till din kodbas#

• Åsidosätt regler – stäng av en regel eller ändra den så att den ger råd i stället för att blockera i kontrollens inställningar.
• Regelpaket – egna mönster, förbjudna importer och beroenden, filstorleksgränser eller resultat från verktyg du redan använder (SARIF). Paketen är versionshanterade; en policy låser fast den version den använder.
• Karantän – mönster du inte längre vill att någon ska kopiera, vart och ett med en ergättning som ska användas i stället. Agenter får instruktioner att inte sprida dem, och nya kopior markeras.
• Repository-fil — .coroid/anti-slop.yml i repot kan lägga till regler och undanta genererade filer eller inhämtade beroenden. Den läses från ändringens bas, så en ändring kan inte försvaga sina egna regler. Redigering kräver godkännande.

Iakttagelser och undantag#

Iakttagelser visas under Kvalitet → Iakttagelser, filtrerade efter kontroll. Om du vill godta en iakttagelse kan du göra undantag för den med en motivering. Undantaget registreras för just den iakttagelsen. Agenter kan inte göra undantag för sina egna iakttagelser. Om en agent säger att ett test var felaktigt och ändrar det måste en granskare godkänna ändringen innan kontrollen godkänns.

Modellbedömda regler#

Två regler frågar en modell, en rad i taget: om en defensiv kontroll gäller något som koden som visas gör omöjligt, och om en kommentar motsäger koden intill. De ger bara råd, de blockerar aldrig. Aktivera modellbedömda regler är aktiverat för en ny kontroll, med en gräns för antal bedömningar per körning. Stäng av det i kontrollens inställningar.

Dina egna agenter#

Samma regler kan vägleda agenter som du kör själv:

• Ladda ner kodsnutt för AGENTS.md, under fliken Skuld i Kvalitet → Kontroller → Anti-slop, innehåller projektets ändringsdisciplin, mönster i karantän och viktigaste regler som ett avsnitt att klistra in i instruktionerna till dina agenter.
• Via MCP-servern Coroid anti_slop_rules beskriver din publicerade policy och anti_slop_scan skannar en gren i ett synkroniserat projekt, med skrivskydd.