En udvikler beder en assistent om en funktion, der kontrollerer, om en bruger må downloade en rapport. Koden kompileres. Happy-path-testen består. Pull-anmodningen ser pæn ud. To uger senere bemærker en kollega, at funktionen kontrollerer, at brugeren er logget ind, men aldrig kontrollerer, at rapporten tilhører dem.
Dette er et illustrativt scenarie, ikke en dokumenteret hændelse. Det beskriver det hul, som AI-genereret kodegennemgangstræning skal lukke: genereret kode, der består en grundlæggende kontrol, kan stadig indeholde en autorisations- eller samtidighedsfejl, og den person, der gennemgår den, skal finde den og forklare, hvorfor den er vigtig.
Denne vejledning er til tekniske supportledere og tekniske ledere. Den dækker, hvordan man beskriver performanceproblemet, diagnosticerer hullerne, forbereder designet og praktiserer det, arbejder med en case og vurderer, om færdighederne kan overføres til reelle evalueringer. Den handler om træning af design. Enhver fejl, test og evalueringsregel i dit program bør valideres af ledende ingeniører og dit sikkerhedsteam.
Hvad er træning i AI-genereret kodegennemgang?
AI-genereret kodegennemgangstræning lærer udviklere at give en assistent tydelige instruktioner og derefter evaluere og revidere, hvad der kommer tilbage: er det korrekt, er det sikkert, opfører det sig under samtidig belastning, er det effektivt nok? Det er ikke et kursus i et bestemt værktøj. Det træner en gennemgangsvane, der forbliver den samme, når værktøjet ændres.
hurtige fakta
| Spørgsmål | Kort svar |
|---|---|
| Hvad er opgaven? | Revider genereret kode og underbygg hver risiko med en test. |
| Hvad scorer du? | Verifikationskvalitet og om de relevante mangler blev fundet. |
| Er en quiz om regler for sikker kodning nok? | Nej. Det bekræfter forudsætninger, men ikke om en udvikler kan finde en fejl i koden, der ser plausibel ud. |
| Hvem validerer indholdet? | En teknisk leder og dit sikkerhedsteam. |
| Hvad kan træning ikke løse? | Gennemgang af tid, værktøjer, uklart ejerskab og pres for at fusionere hurtigt. |
| Hvordan ved du, at det virkede? | En ny, uset kodeøvelse, scoret ud fra aftalte kriterier, med opfølgning på rigtige anmeldelser. |
1. Beskriv ydeevneproblemet
Start med opgaven: Revisionsgenereret kode og underbygg risici med tests. Revision er at læse med mistanke. Underbyggelse er at forvandle en mistanke til bevis, normalt en test, der fejler, eller en gengivelse, der viser fejlen.
Forskningen antyder, hvorfor dette kræver bevidst øvelse. I en undersøgelse af GitHub Copilot genererede Pearce og kolleger 1,689 programmer på tværs af 89 scenarier valgt ud fra kendte svaghedstyper og fandt, at omkring 40 procent af dem var sårbare (Pearce og kolleger, 2021). Det var et tidligt værktøj og et specifikt sæt af scenarier, så behandl ikke tallet som en rate for nutidens assistenter. En separat brugerundersøgelse bad deltagerne om at skrive kode med og uden en AI-assistent. Dem med assistenten skrev betydeligt mindre sikker kode og var mere tilbøjelige til at tro, at deres kode var sikker (Perry og kolleger, 2023Den samme undersøgelse viste, at deltagere, der stolede mindre på assistenten og engagerede sig mere i deres prompts, udviste færre sårbarheder.
To lektioner følger i forbindelse med træningsdesign. Plausibelt output kræver en aktiv korrekturlæser. Og tillid er ikke bevis, så øvelsen skal bede om testen, ikke meningen.
Skriv præstationserklæringen i én sætning, og få en teknisk leder til at kontrollere den: "Givet en genereret ændring oplister udvikleren de sikkerheds-, samtidigheds- og effektivitetsrisici, de ser, og for hver enkelt beskriver eller skriver en test, der ville vise det."
2. Diagnosticer lærings- og kontekstmanglerne
Før du bygger noget, skal du sammenligne opgaven med det, dit nuværende program praktiserer og vurderer. Tre spørgsmål adskiller normalt et træningsgab fra noget andet:
- Bruger nuværende praksis den virkelige opgave? Hvis træningen dækker prompt skrivning, men aldrig beder udviklere om at gennemgå outputtet, har ingen øvet sig i revision. Hvis evaluering er en multiple-choice-test om sikre kodningsregler, måler den genkendelse.
- Hvad er den kognitive efterspørgsel? I Blooms reviderede taksonomi når vurderingen af, om kode er sikker, og valget af den test, der beviser, at den ligger på analyse- og evalueringsniveauerne, samt design af en bedre prompt eller en løsning, til oprettelsesniveauet. Matching af aktiviteter til disse niveauer er dækket i vores guide til Matching af læringsaktiviteter til Blooms taksonomi.
- Er der noget andet end færdigheder, der kommer i vejen? Kontrollér gennemgangstid, værktøjer og ejerskab. Hvis korrekturlæsere har fem minutter pr. pull request, vil ingen træning resultere i en revision. Hvis der ikke er nogen statisk analyse eller testharness i pipelinen, kan en udvikler finde en risiko, men ikke underbygge den. Rapportér årsager, der ikke er relateret til træning, til de personer, der kan udbedre dem.
3. Designforberedelse og -praksis
Når du ved, hvilke huller træning kan lukke, så giv hvert trin en specifik opgave.
Forberedelse. Tjek forudsætningerne med en kort diagnosticering: de almindelige svaghedskategorier, som din stak står over for, hvordan dine tests er struktureret, og den tjekliste, dit team bruger. Selvstudium i eget tempo er egnet til dette trin. En genkaldelseskontrol bekræfter kun forudsætningerne.
Øve sig. Brug revisionsøvelser bygget ud fra realistisk genereret kode. Forsyn hver øvelse med et lille antal defekter af forskellig art, såsom en manglende ejerskabskontrol, et kapløb mellem to anmodninger og et ineffektivt loop, plus noget kode, der er fin. Udvikleren gennemgår, navngiver hver risiko, siger, hvor alvorlig den er, og foreslår den test, der ville vise den. Bed om begrundelse, ikke en liste over linjenumre.
Feedback. Forbind det med beslutninger i stedet for en samlet score. "Du markerede løkken, men ikke løbet på den delte tæller, og din test ville ikke have fanget den, fordi den kører anmodninger én ad gangen" er mere nyttigt end "2 ud af 3 fundet".
Live input eller asynkron gennemgang? Live input tilføjer mest værdi, når en risiko er tvetydig, og udviklere lærer af at høre en senioringeniør forklare, hvorfor de ville blokere sammenlægningen. Asynkron gennemgang er nok til at sammenligne en udviklers resultater med en kommenteret ekspertgennemgang. Mange teams bruger begge dele: forberedelse i eget tempo først, derefter en faciliteret session om de vanskelige cases.
4. Arbejd dig igennem et realistisk eksempel
Illustrativt. En teknisk leder bør validere casen og svarkriterierne før brug.
Sagen. Et genereret slutpunkt returnerer en kundes faktura efter faktura-ID. Det kontrollerer, at den, der ringer op, har en gyldig session, bruger en parametriseret forespørgsel og består den grundlæggende test. Den samme funktion øger en delt downloadtæller uden en lås.
Opgaven. Udvikleren angiver hver risiko, de ser, rangerer dem og beskriver den test, der ville underbygge hver enkelt.
Et første forsøg. "Ser fint ud. Forespørgslen er parametriseret, og testen består." Udvikleren har behandlet den beståede test som bevis og har ikke spurgt om, hvad testen ikke dækker.
Feedback og forsøg igen. Kontrolløren beder udvikleren om at nævne, hvad sessionstestet beviser, og hvad det ikke gør. I genforsøget bedes de overveje to forskellige kunder og to samtidige anmodninger.
Et stærkere forsøg. "Sessionstjekket beviser, hvem der ringer, ikke at fakturaen er deres. Jeg ville skrive en test, hvor kunde A anmoder om kunde B's faktura-ID og forventer en afvisning. Tælleren øges uden synkronisering, så to anmodninger på én gang kan miste en opdatering. Jeg ville køre en samtidig test og sammenligne antallet. Selve forespørgslen er parametriseret, så jeg ville ikke bruge tid der." Bemærk, at dette svar rangerer risiciene og forbinder hver enkelt med en test.
Hvorfor hvert svar er forsvarligt eller ufuldstændigt. Bedøm hver enkelt ud fra godkendte kriterier, ikke ud fra en anmelders præference. Det første forsøg følger en vane, men udelader beviserne. Det stærkeste forsøg er specifikt, prioriteret og testbart.
5. Vurder kapacitet og planoverførsel
Bevis for evner er præstation i en ny øvelse, som eleven ikke har set. Kvaliteten af scoreverifikation og identifikation af relevante defekter. En simpel rubrik bruger en skala fra 0 til 2 pr. kriterium:
| Kriterium | Observerbare beviser |
|---|---|
| Opgaveudførelse | Reviderer den genererede kode og registrerer beviserne bag hvert fund. |
| Ræsonnement | Forklarer begrænsningerne, alternativerne og det, der forbliver usikkert, og rangerer risiciene. |
| Grænser | Følger teamets gennemgangsregler og eskalerer til en sikkerhedsspecialist, når risikoen ligger uden for deres ansvarsområde. |
Ankre: 0 er fraværende eller ikke understøttet, 1 er delvis med relevante udeladelser, og 2 er fuldstændig og begrundet i forhold til de aftalte kriterier. Definer kritiske fejl separat, såsom godkendelse af kode med en ubeskyttet adgangssti, så en samlet score ikke kan skjule en. Denne rubrik er et forslag, ikke en valideret parathedsstandard: tilpas den med en teknisk leder og afprøv den. Vores guide til design af interaktiv praksis med nyttig feedback viser, hvordan man skriver feedback, der knytter sig til beslutninger.
Planlæg overførslen bevidst. Efter øvelsen, par hver udvikler med en rigtig pull request, der inkluderer genereret kode, og gennemgå deres resultater sammen, eller kør en kort retrospektiv på en nylig gennemgang, der overså noget.
Hvor interaktiv levering hjælper
Interaktive formater hjælper, hvor alle bør forpligte sig, før de ser gruppen. I en live-session kan en facilitator vise et genereret kodestykke, bede hver udvikler om at skrive de risici, de ser, og den test, de ville skrive, og derefter afsløre spredningen før diskussionen. Den samme øvelse kan køres i eget tempo som forberedelse. AhaSlides understøtter interaktiv læring og skift mellem live og selvstudier. Det er et præsentations- og læringsværktøj, ikke et sted at køre kode, så kør kodeøvelserne i dit eget miljø. Sammenlign eventuelle specifikke forfatter-, feedback- eller rapporteringsfunktioner, du planlægger at bruge, med din egen arbejdsgang. For vejledning i valg af formater, se vores artikel om Hvornår skal man bruge adaptiv, interaktiv og live læring.
Mål hvad der har ændret sig
Beslut på forhånd, hvad der viser, at udviklerne kan udføre opgaven. Sammenlign verifikationskvalitet og fejlidentifikation på en uset øvelse med en baseline. Definer, hvem der er inkluderet, nævneren og timingen. Hvis resultaterne forbedres, skal du kontrollere, hvad der ellers har ændret sig i samme periode, såsom en ny statisk analyseregel, en revideret tjekliste eller et skift af assistent, før du krediterer træningen.
Begrænsninger, der kan forblive
- Gennemgangstid. En revision tager længere tid end en skim, og deadlines rykker sig mod skim.
- Værktøj. Uden en testledning eller scanning i pipelinen er en risiko svær at underbygge.
- Skift af værktøj. Assistenter skifter hurtigt, så hold øvelserne om evalueringsvanen, ikke ét produkt.
- Sagsdækning. En øvelse viser et par defekttyper. En score beskriver ikke en udviklers vurdering generelt.
- Overførsel. En præstation i en workshop er ikke det samme som en præstation i en travl kø for evalueringer.
Nævn disse for sponsorer tidligt og planlæg separate løsninger. Træning forbedrer, hvad en udvikler kan finde og bevise. Det skaber ikke tiden eller værktøjerne.
Ofte stillede spørgsmål
Hvad er træning i AI-genereret kodegennemgang?
Det lærer udviklere at prompte, evaluere og revidere kode produceret af en AI-assistent, finde sikkerheds-, samtidigheds- og effektivitetsproblemer og understøtte hvert problem med en test.
Er genereret kode mindre sikker end menneskelig kode?
Studier peger på risiko, men resultaterne afhænger af værktøjet, opgaven og studiedesignet. En brugerundersøgelse viste, at deltagere med en assistent skrev mindre sikker kode og følte sig mere trygge ved det, hvilket er en grund til at træne gennemgangsvanen.
Hvordan vurderer du, om udviklere kan revidere genereret kode?
Giv en ny kodeøvelse og score verifikationskvalitet og defektidentifikation i forhold til aftalte kriterier. En quiz om sikre kodningsregler bekræfter kun forudsætningerne.
Har du brug for en kodesandkasse til træningen?
Du har brug for et sted at udføre øvelserne, hvilket normalt er dit eget miljø. Kontroller, at ethvert værktøj, du bruger, understøtter det, du har brug for, før du stoler på det.
Hvor skal man begynde
Vælg én tilbagevendende type genereret ændring i din kodebase. Skriv performance statement, få en engineering manager til at validere de seedede defekter og de tests, der ville vise dem, og udarbejd en rubrik med tre kriterier med en skala fra 0 til 2 og en liste over kritiske fejl. Afprøv det med en lille gruppe, før du ruller det ud.
For at se, hvordan en revisionsøvelse kan køre live med dit eget team og genbruges i dit eget tempo bagefter, kan du udforske AhaSlides.
