# AI kodgranskning: gratis kontroll av din diff före PR

URL: https://codebasechat.com/sv/tools/ai-kodgranskning
Type: tool
Locale: sv
Published: 2026-11-04
Updated: 2026-11-05

---

> Klistra in en git diff eller ett kodstycke och få en poäng av 100 samt radnumrerade fynd: hemligheter, osäker SQL, tomma catch-block, debugrester och stora ändringar. Körs i din webbläsare.

## Kontrollera din diff innan granskaren gör det

Klistra in en git diff eller ett kodstycke. Det här gratis verktyget för AI kodgranskning flaggar hemligheter, osäker SQL, svalda fel, kvarlämnad debugkod och för stora ändringar i din webbläsare, och ger pull requesten en poäng av 100.

## Kontroll av diff före granskning

Klistra in en unified diff eller valfri kod. Endast tillagda rader kontrolleras när en diff upptäcks. Ingenting du klistrar in lämnar din webbläsare.

*[Interactive widget — see the live page for the full experience]*

## Vad kontrollen tittar på och vad den ignorerar

### Endast tillagda rader

Om du klistrar in en unified diff läser kontrollen hunk-huvudena, räknar radnummer i den nya filen och granskar bara de rader du lagt till. Borttagna rader och oförändrad kontext ger aldrig ett fynd, så du får ingen skuld för gammal kod.

### Viktad poäng efter allvarlighetsgrad

Tretton regler delas in i tre nivåer. Hög kostar 15 poäng: hårdkodade hemligheter, eval, strängbyggd SQL och avstängd TLS-kontroll. Medel kostar 7: svalda undantag, fokuserade tester, innerHTML och en diff på 400 rader. Låg kostar 2: TODO, debugutskrifter och utkommenterad kod. Varje regel räknas högst tre gånger.

### Kontroll av storlek och tester

Över 200 tillagda rader får du en uppmaning att dela upp ändringen, över 400 en tydligare sådan. Det följer SmartBear-studien av Cisco, där granskningskvaliteten sjunker när en granskare får fler än 200 till 400 rader åt gången. En diff med fler än 50 tillagda rader utan testfil flaggas också.

## Från inklistring till en ren pull request på fyra steg

1. **Klistra in din diff** — Kör git diff main...HEAD, eller git diff --staged innan du committar, och klistra in utdata. Ett vanligt kodstycke fungerar också, men du förlorar filnamn och identifiering av testfiler.
2. **Läs de högt prioriterade fynden först** — Röda rader är de som en granskare stannar vid. En hårdkodad nyckel i en commit finns kvar i historiken även om du tar bort raden, så byt ut den i stället för att bara ta bort den.
3. **Åtgärda eller motivera resten** — Varje fynd kommer med en fix på en rad. Om en flagga är falskt positiv, skriv det i PR-beskrivningen. Då slipper granskaren samma fråga.
4. **Kopiera checklistan** — Kopieringsknappen gör om fynden till en markdown-checklista som du kan klistra in i PR-texten, så granskaren ser vad du redan har fångat.

*Varför en förkontroll*

## De första trettio sekunderna av en granskning ska inte gå åt till console.log

Öppnar du en pull request från en kollega känner du igen rutinen. Du scrollar igenom diffen och ser en kvarglömd debugutskrift, en TODO utan ärende, ett hoppat över test och ett catch-block som sväljer felet. Inget av det kräver en människa. Det kräver en checklista som körs innan förfrågan skickas.

Det är det gap verktyget fyller. En granskares uppmärksamhet är begränsad: SmartBear-studien av Cisco-granskningar visade att felupptäckten håller när man granskar 200 till 400 rader på 60 till 90 minuter, och sjunker därefter. Varje minut som går åt till mekaniska fynd är en minut som saknas för frågorna bara en människa kan besvara: är det rätt ansats, passar det arkitekturen, kommer det att vara begripligt om sex månader.

Det ersätter inte en granskare, och låtsas inte heller att göra det. Det tar bort de billiga invändningarna så att den mänskliga granskningen kan börja vid det intressanta.

- Fångar de mekaniska fynden innan granskningsbegäran skickas
- Ger varje fynd ett radnummer hämtat från diffens hunk-huvuden
- Körs lokalt, så det är säkert att klistra in proprietär kod

## Frågor om kontrollen

### Är detta en AI-kodgranskare eller en linter?

Varken eller, strikt sett. Det är en regelbaserad förkontroll. Ingen modell läser din kod och inget genereras. Tretton mönsterregler söker igenom de tillagda raderna efter sådant en granskare reagerar på under de första trettio sekunderna: hemligheter, osäker strängbyggd SQL, svalda undantag och kvarlämnad debugutdata. Vi märker det ärligt, eftersom en AI-kodgranskare som gissar är sämre än en checklista som inte gissar.

### Lämnar min kod min webbläsare?

Nej. Kontrollerna körs i JavaScript på den här sidan. Det sker ingen uppladdning, inget API-anrop och inget konto krävs. Det enda som registreras är en anonym händelse om att verktyget användes, utan något innehåll från textrutan.

### Var kommer reglerna om 200 till 400 rader och testfiler ifrån?

Storleksgränsen följer SmartBear-studien av Cisco-granskningsdata, som rekommenderar att man granskar högst 200 till 400 rader åt gången. Regeln om små ändringar följer Googles offentliga riktlinjer för små CL:er. Regeln om saknade tester är vår egen: en diff med fler än 50 tillagda rader utan testfil flaggas, eftersom det är en fråga granskare ändå brukar ställa.

### Hur beräknas poängen?

Den börjar på 100. Varje fynd drar av poäng efter allvarlighetsgrad: 15 för hög, 7 för medel och 2 för låg. Varje regel räknas högst tre gånger, så en bullrig regel kan inte nollställa poängen. Det är en konvention för att ordna arbetet, inte ett mått på kodkvalitet. En poäng på 100 betyder att ingen regel slog till, inte att koden är korrekt.

### Vad missar den?

Allt som kräver förståelse: fel affärslogik, race conditions, en dålig abstraktion, ett API som inte åldras väl. Regex-regler ger också falska positiva, till exempel en testfixtur som innehåller ett fejkat lösenord. Behandla varje fynd som en fråga att besvara, inte som ett domslut.

### Vilka språk fungerar den med?

Reglerna är textmönster, så de fungerar på JavaScript, TypeScript, Python, Java, Go och de flesta C-liknande språk. Vissa regler är språkspecifika: bar except är Python, System.out.println är Java och InsecureSkipVerify är Go. Klistra in en unified git diff så kommer radnumren från hunk-huvudena.

### Är den gratis?

Ja, utan registrering. Om du vill ha svar om resten av ditt repo medan du granskar, till exempel vem som anropar en funktion eller var ett konfigurationsvärde läses, är det till det codebasechat finns.

## Granska med hela repot i sikte

En diff visar vad som ändrats, inte vad den berör. codebasechat besvarar frågor om din kodbas på vanligt språk, så att du kan kontrollera vem som anropar den ändrade funktionen innan du godkänner.

*Call to action: Prova codebasechat gratis*


## FAQ

### Är detta en AI-kodgranskare eller en linter?

Varken eller, strikt sett. Det är en regelbaserad förkontroll. Ingen modell läser din kod och inget genereras. Tretton mönsterregler söker igenom de tillagda raderna efter sådant en granskare reagerar på under de första trettio sekunderna: hemligheter, osäker strängbyggd SQL, svalda undantag och kvarlämnad debugutdata. Vi märker det ärligt, eftersom en AI-kodgranskare som gissar är sämre än en checklista som inte gissar.

### Lämnar min kod min webbläsare?

Nej. Kontrollerna körs i JavaScript på den här sidan. Det sker ingen uppladdning, inget API-anrop och inget konto krävs. Det enda som registreras är en anonym händelse om att verktyget användes, utan något innehåll från textrutan.

### Var kommer reglerna om 200 till 400 rader och testfiler ifrån?

Storleksgränsen följer SmartBear-studien av Cisco-granskningsdata, som rekommenderar att man granskar högst 200 till 400 rader åt gången. Regeln om små ändringar följer Googles offentliga riktlinjer för små CL:er. Regeln om saknade tester är vår egen: en diff med fler än 50 tillagda rader utan testfil flaggas, eftersom det är en fråga granskare ändå brukar ställa.

### Hur beräknas poängen?

Den börjar på 100. Varje fynd drar av poäng efter allvarlighetsgrad: 15 för hög, 7 för medel och 2 för låg. Varje regel räknas högst tre gånger, så en bullrig regel kan inte nollställa poängen. Det är en konvention för att ordna arbetet, inte ett mått på kodkvalitet. En poäng på 100 betyder att ingen regel slog till, inte att koden är korrekt.

### Vad missar den?

Allt som kräver förståelse: fel affärslogik, race conditions, en dålig abstraktion, ett API som inte åldras väl. Regex-regler ger också falska positiva, till exempel en testfixtur som innehåller ett fejkat lösenord. Behandla varje fynd som en fråga att besvara, inte som ett domslut.

### Vilka språk fungerar den med?

Reglerna är textmönster, så de fungerar på JavaScript, TypeScript, Python, Java, Go och de flesta C-liknande språk. Vissa regler är språkspecifika: bar except är Python, System.out.println är Java och InsecureSkipVerify är Go. Klistra in en unified git diff så kommer radnumren från hunk-huvudena.

### Är den gratis?

Ja, utan registrering. Om du vill ha svar om resten av ditt repo medan du granskar, till exempel vem som anropar en funktion eller var ett konfigurationsvärde läses, är det till det codebasechat finns.