Kontroller mot slarvig AI-kod

Agenter skriver trovärdig kod snabbt, och en del av den tar genvägar som en noggrann utvecklare inte skulle ta: ett test hoppas över för att få grönt, ett fel sväljs, en stub lämnas kvar, en typkontroll tystas eller ett andra sätt införs 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 ser den.

Det är en kontroll i din kvalitetspolicy, inte ett separat resultat. En ändring klarar kontrollen när den inte tillför något blockerande.

Det här letar kontrollen efter#

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

• Tester — fokuserade eller överhoppade tester, borttagna tester, borttagna eller försvagade påståenden, tester som inte kan misslyckas.
• Undertryckningar — nya lint-undantag, typundantag och any -castningar.
• Bygg och CI — borttagna eller neutraliserade teststeg, sänkta tröskelvärden, ”godkänt utan tester”, GitHub Actions som inte är låsta till en commit.
• Testbevis — cachade resultat som utges för att vara en körning, noll körda tester, en delvis körning som rapporteras som slutförd.
• Produktionskod — kvarlämnad felsökningskod, platshållare, testdata, anteckningar till människor, testkod som levereras.
• Felhantering — sväljda fel, reservlösningar som döljer fel, behörighetskontroller som tillåter åtkomst vid fel.
• Beroenden — paket som inte finns eller rapporteras som skadliga, nypaket med namn som liknar populära paket, paket som kör kod vid installation, manifest som ändrats utan motsvarande lockfile.
• Säkerhet — hemligheter i kod, avstängda TLS-kontroller, borttagna behörighetskontroller, nedladdade skript som körs direkt från nätverket.
• Kommentarer, Arkitektur, Ändringens omfattning, Cachning och agentens spår — loggen över vad agenten gjorde, till exempel att redigera ett test precis efter att det misslyckats.

Varje regel i Anti-slop-regler, som öppnas från raden Anti-slop under Kvalitetskontroll, visar vad regeln matchar, varför det spelar roll och vad den gör i organisationens standardinställningar eller i ett projekt.

Det är bara sådant som ändringen tillför som blockerar#

De flesta repo innehåller redan en del av de här mönstren. Anti-slop delar in varje träff i en av tre grupper:

• Tillkommet — nytt i den här ändringen.
• Berört — fanns redan på en rad eller i en funktion som ändringen redigerar.
• Befintligt — någon annanstans i repot.

Bara en tillkommen träff av en blockerande regel gör att kontrollen misslyckas. Berörda och befintliga träffar registreras så att du kan följa din tekniska skuld i Mjukvarufabrik, under Skuld, och skapa en uppgift för att åtgärda träffarna för en regel där. De fördröjer aldrig orelaterat arbete. Att flytta kod räknas inte som att tillföra den; att kopiera den gör det.

Veckovis städning av teknisk skuld#

Befintlig skuld blockerar inte, men den behöver inte finnas kvar. Öppna ett projekt i Kvalitetskontroll, expandera Anti-slop och slå på Veckovis städning av teknisk skuld. En gång i veckan söker Coroid igenom projektets standardbranch och skapar små städuppgifter för den skuld som hittas, några filer åt gången. Antalet öppna städuppgifter begränsas till det antal som Öppna uppgifter åt gången anger (två som standard), så städningen tränger aldrig undan arbetet som människor har bett om. Varje ändring har alternativet Ångra.

Städningen ställs in per projekt. Schemat visas i Mjukvarufabrik och anger att Kvalitetskontroll hanterar det; ändra det här, inte där.

Nytta arbetet erbjöd tidigare mallen ”Veckovis städning av teknisk skuld”. Ett schema som du skapade med den fortsätter att köras och visas med namn under reglaget. Pausa det i Mjukvarufabrik om skuldstädningen ersätter det.

Slå på funktionen#

I Kvalitetskontroll, välj organisationens standardinställning eller ett projekt och slå på Anti-slop. Det lägger till fem förväntningar:

1. Tester fortsätter att verifiera ändringen.
2. Inget ofärdigt eller enbart avsett för tester levereras.
3. Ingen ny strukturell skuld.
4. Ändringen håller sig inom omfattningen och följer kodbasens stil.
5. Nya beroenden är verkliga och välrenommerade.

Ändringen börjar gälla direkt: nästa körning för projektet, eller för varje projekt som följer standardinställningen, omfattar kontrollen. Inställningarna på raden väljer ändringsdisciplin, vilka grupper som blockerar och vilka regler som bedöms. Om du stänger av funktionen sparas inställningarna till nästa gång du slår på den.

Välj ändringsdisciplin#

Disciplinen anger hur långt en ändring får sträcka sig:

• 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 — städa också upp träffar i funktioner som ändringen redigerar.

Agenten följer samma regler innan den skickar in ändringen: den får disciplinen och dina karantänmönster i förväg, ser de snabba reglerna efter varje redigering och får ett försök att åtgärda blockerande träffar före QA.

Anpassa till din kodbas#

• Åsidosättningar av regler — öppna en regel i Anti-slop-regler för att låta den blockera, ge råd, endast rapportera eller stoppa, för organisationens standardinställning eller ett projekt.
• Regelpaket — dina egna mönster, förbjudna importer och beroenden, gränser för filstorlek eller resultat från verktyg du redan kör (SARIF). Varje gång du sparar skapas en ny version, och en kontroll behåller den version som valts.
• Karantän — mönster som du inte längre vill ska kopieras, vart och ett med en ersättning att använda i stället. Agenterna får instruktioner att inte sprida dem, och nya kopior markeras.
• Uteslutna sökvägar — under Kvalitetskontroll → Anti-slop anger du de genererade eller leverantörshanterade filer som anti-slop-kontrollen inte läser, ett mönster per rad (dist/**, vendor/**). Använd detta för incheckade byggresultat: om en ändrad fil är större än skannerns gräns på 512 KiB och en regel behöver läsa den blir kontrollerna otillgängliga.
• Repository-fil — .coroid/anti-slop.yml i repot kan lägga till regler och utesluta generated/, vendor/, node_modules/ och __generated__/ kataloger. Filen läses från ändringens bas, så en ändring kan inte försvaga sina egna regler, och ändringar i filen måste godkännas.
• Lockfiles och översättningskataloger — anti-slop räknar deras ändringar men läser dem inte. Kataloger är de filer som .coroid/i18n.json anger vid ändringens bas; kontrollen Globalisering läser dem. En egen regel som namnger dem läser dem ändå.

Nya beroenden#

Modeller föreslår ibland paket som inte finns, ofta en trovärdig blandning av två verkliga namn. Angripare registrerar sådana namn på npm och PyPI så att deras kod körs vid nästa installation. Attacken kallas slopsquatting. Cloud Security Alliance beskriver det: nästan ett av fem av de 2,23 miljoner kodexemplen i den forskning som organisationen hänvisar till namngav minst ett paket som inte fanns.

Anti-slop slår upp varje beroende som en ändring lägger till i package.json, en kravfil eller pyproject.toml:

• Blockerar — ett paket som inte finns i sitt offentliga register, eller ett som OSV rapporterar som skadligt. Ändringen skickas tillbaka till utvecklaragenten innan du får se den.
• Ger råd — ett paket som publicerades för mindre än 30 dagar sedan, ett med väldigt få nedladdningar, ett vars namn skiljer sig med en eller två bokstäver från ett populärt paket, eller ett npm-paket som kör kod vid installation. Ett PyPI-paket med en version som rapporterats som skadlig ger också råd, eftersom Coroid inte vet vilken version ett krav installerar.

Om det inte går att nå ett register står det i resultatet, och kontrollen fattar beslut om de paket den kunde slå upp. Ändringen hålls inte tillbaka.

Vilka namn Coroid slår upp#

När ett namn slås upp skickas det till ett offentligt register, så en ägare eller administratör väljer vilka namn som får lämna Coroid, under Kvalitetskontroll → Anti-slop → Kontrollera nya beroenden. Valet gäller alla projekt i organisationen.

• Offentliga npm och PyPI, om inte repot anger ett annat register — alla nya beroenden slås upp, utom när .npmrc, en kravfil, pip.conf, uv.toml, en Pipfile eller inställningar för Python-verktyg, intill manifestet eller i en mapp ovanför det, anger ett annat register eller index. Om du väljer det ombeds du bekräfta att inget privat register har konfigurerats utanför dina repon, till exempel i användar- eller CI-inställningar. Bekräftelsen registreras med datum och vem som gjorde den. Scoped npm-paket (@scope/name) slås bara upp när .npmrc anger det offentliga registret för deras scope.
• Bara när repot anger det offentliga registret — standardinställningen. Ett paket slås bara upp när .npmrc anger registry=https://registry.npmjs.org/, dess kravfil har exakt en --index-url https://pypi.org/simple rad, eller ett Poetry-beroende använder en källa som pekar på pypi.org. De flesta repon gör inget av detta, så de flesta nya beroenden kontrolleras inte.
• Av — inga namn slås upp, och påhittade paket upptäcks inte.

Bara namnen på nya beroenden lämnar Coroid. De skickas till registry.npmjs.org och pypi.org, till api.npmjs.org för nedladdningsstatistik från npm och till api.osv.dev (med npm-versionen) för rapporter om skadliga paket. Din kod skickas aldrig. Resultaten sparas i upp till ett dygn, så samma namn slås inte upp igen för varje ändring.

Iakttagelser och godkännande#

En uppgifts iakttagelser visas i avsnittet Kvalitet i Mjukvarufabrik. När utvecklaragenten har åtgärdat blockerande iakttagelser innan ändringen gått vidare till granskning, visas först Fångades upp av anti-slop före granskning, reglerna som fångades upp och, under Visa var och när, filen och raden för varje iakttagelse samt kontrollen som hittade den. I Mjukvarufabrik visar avsnittet Skuldantalet genvägar som fångats upp före granskning under de senaste 30 dagarna. Ägare och administratörer ser också vilka projekt som ännu inte kontrollerar efter dem, med Aktivera anti-slop.

Om du vill godkänna en iakttagelse anger du en orsak och ett utgångsdatum. Godkännandet registreras för just den iakttagelsen. Agenter kan inte godkänna sina egna iakttagelser. När en agent säger att ett test är felaktigt och ändrar det måste en granskare godkänna ändringen innan kontrollen godkänns.

Bedömningsregler#

Två regler frågar en modell, en rad i taget: om det finns en defensiv kontroll för något som koden som visas gör omöjligt, och om en kommentar motsäger koden intill. De ger bara råd, aldrig blockeringar. Aktivera bedömningsregler är aktiverat för en ny kontroll, med en gräns för antalet beslut per körning. Du kan inaktivera det i kontrollens inställningar.

Dina egna agenter#

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

• Ladda ned kodsnutt för AGENTS.md, under Anti-slop -inställningarna för ett projekt i Kvalitetskontroll, ger projektets riktlinjer för ändringar, karantän och topregler som ett avsnitt att klistra in i instruktionerna till dina agenter.
• Via Coroid MCP-servern anti_slop_rules beskriver den publicerade policyn och anti_slop_scan söker igenom en gren i ett synkroniserat projekt i skrivskyddat läge.