Gevinster:
- Evne til å bruke AI som et innledende gjennomgangsfilter med kategorier og alvorlighetsmerker
- Evne til å filtrere funn med menneskelig sinn for å bekrefte/false positive/anvende
- Evne til å håndheve krav til menneskelig godkjenning på forretningsregler, arkitektur og sikkerhetskritiske beslutninger
Kodegjennomgang er når en endring skrevet av en utvikler blir vurdert av noen andre før den slås sammen. God anmeldelse; Den fanger opp feil tidlig, deler informasjon og holder kodebasen konsistent. Men anmeldelser er slitsomme, utsatt for distraksjon og blir overfladiske under tidspress. Kunstig intelligens er en todelt assistent her: den lar deg både forhåndsrense din egen kode som du sender inn for vurdering og å undersøke andres PR (pull request) med et skarpere øye.
Det kritiske skillet er dette: AI øker hastigheten og forbedrer gjennomgangen, men den kan ikke overta ansvaret for godkjenning. Setningen "AI så, det er rent" er ikke en påtegning. Den endelige "sammenslåings"-beslutningen er opp til en ingeniør som kjenner koden og konteksten.
Hva AI er bra og dårlig om i gjennomgang
Bra for: Nullsjekkfeil, ressurslekkasjer (fil/lenke forblir åpen), ufangede unntak, åpenbart feil forhold (>= i stedet for >), forslag til nytt navn, lesbarhet, manglende kant-case, enkle sikkerhetslukter (som SQL-strengsammenkobling), gjenkjenning av duplikatkode.
Svakheter: Dype feil som bryter forretningsregelen din, men som krever kontekst og timing, for eksempel syntaktisk korrekt logikk, arkitektonisk samsvar, reelle flaskehalser i ytelse, samtidighetsfeil. AI produserer også falske positiver (ta feil av noe som faktisk ikke er et problem med et problem) og falske negativer (mangler den virkelige feilen). Derfor er produksjonen en "forsiktighetsliste", ikke en endelig dom.
Forsiktig: Bare fordi AI sier "ingen problem", beviser ikke at koden er riktig. Falske negativer er tause; De farligste feilene er de som aldri er nevnt i anmeldelsen.
Systematiske gjennomgangstrinn
- Gi konteksten. Legg til formålet med endringen, det relevante problemet og akseptkriteriene, hvis noen, i ledeteksten. Formålsløs gjennomgang produserer formålsløs tolkning.
- Del det ned i kategorier. Be modellen klassifisere funnene som "feil/sikkerhet/ytelse/lesbarhet/stil"; slik at du skiller det kritiske fra støyen.
- Be om en alvorlighetsetikett. Gi hvert funn en "høy/middels/lav" vurdering og ta med "årsak" og "anbefalt korreksjon."
- Filtrer det med dine egne øyne. Vurder hvert funn: er det ekte (verifiser), er det en falsk positiv (skriv begrunnelse), mangler det noe (legg til din egen kunnskap).
- Bekreft kritiske stier manuelt. Les og utfør ruter som involverer penger, identitet, autorisasjon og sletting av data selv uten å stole på AI.
Tre minivesker
Tilfelle 1 - Taus nullfeil fanget. Ett team hadde forhåndsvurdering av AI en 380-linjers PR. Modellen flagget en måte et eksternt tjenestesvar kunne være null, men det ble ikke kontrollert for dette i koden. Den menneskelige anmelderen bekreftet denne banen og la til en nullsjekk; En lignende feil forårsaket et 2-timers produksjonsavbrudd i forrige kvartal.
Tilfelle 2 — Falsk positiv eliminering. AI-en flagget et "mulig ytelsesproblem" i en loop. Anmelderen avsluttet dette som en falsk positiv, vel vitende om at løkken bare fungerer med maksimalt 5 elementer (den går over en enum). Modellen, som ikke kjente sammenhengen, advarte; Personen som kjente konteksten tok den riktige avgjørelsen.
Tilfelle 3 – AI savnet forretningsregelfeil. Mens en rabattkonto bør være maksimalt 30 % i henhold til kampanjeregelen, tillot koden 50 %. AI har aldri lagt merke til denne syntaktisk perfekte logiske feilen; fordi han ikke kjente regelen. Feilen ble fanget i anmeldelsen av produktets eier som kjente akseptkriteriene. Leksjon: validering av forretningsregler er en menneskelig jobb.
Fire kopierbare maler
Formålsorientert, kategorisert anmeldelse:
Rolle: Nøyaktig kodeanmelder. Formål med endring: {{purpose / issue}}Se gjennom denne diff. Oppgi funn i disse kategoriene: [Bug] [Sikkerhet][Ytelse] [Lesbarhet] [Stil]. For hvert funn: fil:rad, alvorlighetsgrad (høy/middels/lav), årsak, anbefalt rettelse. Merk "mulig" hvis du ikke er sikker. Du kjenner ikke forretningsreglene; Spør meg om steder som krever regler.{{diff}}
Slik forbereder du deg på å se din egen kode:
Se gjennom denne endringen før du åpner en PR. Se etter: manglende null/feilsjekk, ressurslekkasje, kantsak, hemmelig, uprøvd gren. List opp funnene i prioritert rekkefølge; foreslå korrigering 1 linje for hver.{{code}}
Kantsaksjakt:
List inn innganger og situasjoner der denne funksjonen kan gå i stykker: tom, null, for stor, negativ, samtidig samtale, nettverksfeil, delvise data. For hvert tilfelle, skriv forventet oppførsel og hva gjeldende kode vil gjøre.{{function}}
Sikkerhetsduftskanning (forhåndskontroll):
Se etter vanlige sikkerhetslukter i denne koden: SQL/kommando-sammenkobling, uvalidert inndata, uforanderlig innebygd hemmelighet, usikker deserialisering, mangel på rettighetskontroll. Skill funnene inn i "sikker / sannsynlig / kunnskap". Dette er en foreløpig screening; Det er ikke en endelig kjennelse.{{code}}
Svak forespørsel / Sterk forespørsel
Svak: "Er det en feil i denne PR?"
Sterkt: "Formål: legg til kupongrabatt til handlekurvens totalsum (rabatten må ikke være mer enn 30 % — du kan ikke bekrefte denne regelen selv, bare fortell meg om koden pålegger en øvre grense). Undersøk diff; gi funn etter kategori + alvorlighetsgrad + foreslått korreksjon, merk 'mulig' hvis du er usikker. [diff]"
Den sterke versjonen viser tydelig intensjonen, forretningsregelen og grensen til AI; Dermed kommer nyttige funn og området ukjent for modellen forblir klart.
Finne type
AI-pålitelighet
manns rolle
Null-/feilkontroll mangler
høy
Bekreft og bruk
Lesbarhet/stil
høy
Velg etter preferanse
Enkel sikkerhetslukt
medium
Fullfør, skann med kjøretøy
Overholdelse av forretningsregler
lav
Det er helt menneskelig.
Samtidighet/arkitektur
lav
Ekspertvurdering er nødvendig
AI Review er ikke en erstatning for Human Review
Plasser AI-gjennomgang som et "første filter": et billig, raskt, utrettelig foreløpig pass. Dette filteret frigjør den menneskelige anmelderens oppmerksomhet fra uviktige detaljer (et mellomrom, et navn) og dirigerer det til steder som virkelig krever ettertanke – forretningsregelen, arkitekturen, sikkerhetsresultatet. Men sammenslåingsgodkjenning er signaturen til en ansvarlig person i teamet. Uavhengig gjennomgang av minst én kompetent ingeniør er obligatorisk for sikkerhetskritiske endringer.
Tips: Les listen over funn som AI produserer som en "ting å sjekke" i stedet for en "å gjøre". Enten verifiser og bruk hvert element eller skriv ned i én setning hvorfor du bestod det; dette sporet gjør gjennomgangen reviderbar.
Vanlige feil
- Det betyr "AI så, det er rent". Dette er en falsk følelse av selvtillit på grunn av falske negativer.
- Ikke gi kontekst. Uten formål og akseptkriterier produserer modellen kun overfladiske stiltolkninger.
- Bruker blindt falske positiver. Å fikse hver advarsel fra modellen kan knekke kjørekoden.
- Spør modellen om forretningsregelen. Modellen kjenner ikke regelen; Det er opp til mennesket å verifisere det.
- Ikke diskriminer vold. Å legge et kritisk sikkerhetsfunn og et navneforslag i samme pose overskygger det som er viktig.
Oppsummert
AI er et utrettelig første filter i kodegjennomgang: det fanger opp null-/feilfeil, kantsaker og enkel sikkerhet lukter godt; men det er svakt på kontekstkrevende feil som forretningsregel, arkitektur og samtidighet, og produserer både falske positive og falske negative. Be om funn etter kategori og alvorlighetsgrad, filtrer hver med menneskelig intelligens, kontroller manuelt kritiske veier. Godkjenning er alltid signaturen til en ansvarlig ingeniør.
Søknadsoppgave
Velg en ekte eller nylig PR/diff. Først, få AI til å vurdere den med malen "objektivt orientert kategorigjennomgang". Sett funnene i en tabell og avgjør for hver enkelt: sann (jeg bekreftet), falsk positiv (her er resonnementet mitt), eller skal implementeres. Ta deretter en omvisning selv og prøv å finne minst én ting (spesielt en forretningsregel eller edge case) som AI mangler og skriv det ned.
sjekkliste
- [ ] Jeg bruker AI-gjennomgang som et første filter, ikke en godkjenning.
- [ ] Jeg legger til formålet og akseptkriteriene i gjennomgangsforespørselen.
- [ ] Jeg skiller funnene fra støyen etter kategori og ønsker dem sterkt.
- [ ] Jeg filtrerer bevisst hvert funn for å bekrefte/false positivt/anvende.
- [ ] Som menneske sjekker jeg forretningsregler og arkitektonisk samsvar.
- [ ] Jeg krever godkjenning fra en kvalifisert ingeniør for sikkerhetskritiske endringer.