Izstrādātājs lūdz asistentam funkciju, kas pārbauda, vai lietotājs drīkst lejupielādēt atskaiti. Kods kompilējas. Laimīgās ceļa pārbaude ir veiksmīga. Pieprasījums pēc pieprasījuma izskatās kārtīgs. Divas nedēļas vēlāk kolēģis pamana, ka funkcija pārbauda, vai lietotājs ir pierakstījies, bet nekad nepārbauda, vai atskaite pieder viņam.
Šis ir ilustratīvs scenārijs, nevis dokumentēts incidents. Tas apraksta plaisu, kas jāaizpilda ar mākslīgā intelekta ģenerēta koda pārskatīšanas apmācību: ģenerēts kods, kas iztur pamata pārbaudi, joprojām var saturēt autorizācijas vai vienlaicības kļūdu, un personai, kas to pārskata, tas ir jāatrod un jāpaskaidro, kāpēc tas ir svarīgi.
Šī rokasgrāmata ir paredzēta inženiertehnisko uzdevumu vadītājiem un inženiertehniskajiem vadītājiem. Tajā ir aprakstīts, kā aprakstīt veiktspējas problēmu, diagnosticēt nepilnības, sagatavot dizainu un praktizēt to, kā strādāt ar gadījumu un novērtēt, vai prasmes tiek izmantotas reālās pārskatīšanās. Tā ir par dizaina apmācību. Katrs defekts, tests un pārskatīšanas noteikums jūsu programmā ir jāapstiprina vecākajiem inženieriem un jūsu drošības komandai.
Kas ir mākslīgā intelekta ģenerēta koda pārskatīšanas apmācība?
Mākslīgā intelekta ģenerēta koda pārskatīšanas apmācība māca izstrādātājiem skaidri norādīt asistentam atbildes, pēc tam novērtēt un auditēt atbildes: vai tās ir pareizas, vai tās ir drošas, vai tās darbojas vienlaicīgas slodzes apstākļos, vai tās ir pietiekami efektīvas? Tas nav kurss par konkrētu rīku. Tas apmāca pārskatīšanas ieradumu, kas paliek nemainīgs, mainoties rīkam.
Īsi fakti
| jautājums | Īsā atbilde |
|---|---|
| Kāds ir uzdevums? | Veiciet ģenerētā koda auditu un pamatojiet katru risku ar testu. |
| Kādu rezultātu tu iegūsti? | Pārbaudes kvalitāte un tas, vai tika konstatēti attiecīgie defekti. |
| Vai pietiek ar viktorīnu par drošas kodēšanas noteikumiem? | Nē. Tas apstiprina priekšnosacījumus, bet ne to, vai izstrādātājs var pamanīt kodā kļūdu, kas šķiet ticama. |
| Kas apstiprina saturu? | Inženiertehniskais vadītājs un jūsu drošības komanda. |
| Ko nevar labot ar treniņiem? | Pārskatīšanas laiks, instrumenti, neskaidras īpašumtiesības un spiediens uz ātru apvienošanos. |
| Kā tu zini, ka tas nostrādāja? | Jauns, neredzēts koda vingrinājums, kas tiek vērtēts pēc saskaņotiem kritērijiem, ar turpmāku novērtējumu pēc reālām atsauksmēm. |
1. Aprakstiet veiktspējas problēmu
Sāciet ar uzdevumu: auditējiet ģenerēto kodu un pamatojiet riskus ar testiem. Auditēšana ir lasīšana ar aizdomām. Pamatošana ir aizdomu pārvēršana pierādījumā, parasti testā, kas neiztur rezultātu, vai reprodukcijā, kas parāda trūkumu.
Pētījums liecina, kāpēc tas ir jāapstrādā apzināti. GitHub Copilot pētījumā Pīrss un viņa kolēģi ģenerēja 1,689 programmas 89 scenārijos, kas tika izvēlēti zināmiem vājumu veidiem, un atklāja, ka aptuveni 40 procenti no tām bija neaizsargātas (Pīrss un kolēģi, 2021. gads). Tas bija agrīns rīks un specifisks scenāriju kopums, tāpēc neuztveriet šo skaitli kā rādītāju mūsdienu asistentiem. Atsevišķā lietotāju pētījumā dalībniekiem tika lūgts rakstīt kodu ar un bez mākslīgā intelekta asistenta. Tie, kuriem bija asistents, rakstīja ievērojami mazāk droša koda un biežāk uzskatīja, ka viņu kods ir drošs (Perijs un kolēģi, 2023. gads). Tajā pašā pētījumā tika atklāts, ka dalībnieki, kuri mazāk uzticējās asistentam un vairāk iesaistījās viņa uzvednēs, radīja mazāk ievainojamību.
Seko divas mācības par apmācību izstrādi. Ticamam rezultātam ir nepieciešams aktīvs recenzents. Un pārliecība nav pierādījums, tāpēc vingrinājumā ir jāpieprasa pārbaude, nevis viedoklis.
Uzrakstiet veiktspējas aprakstu vienā teikumā un palūdziet inženierijas vadītājam to pārbaudīt: "Ņemot vērā ģenerētās izmaiņas, izstrādātājs uzskaita drošības, vienlaicības un efektivitātes riskus, ko viņš saskata, un katram no tiem apraksta vai uzraksta testu, kas to parādītu."
2. Diagnosticējiet mācīšanās un konteksta nepilnības
Pirms jebkādu uzdevumu veidojat, salīdziniet to ar to, ko jūsu pašreizējā programma praktizē un novērtē. Trīs jautājumi parasti atšķir apmācības nepilnības no kaut kā cita:
- Vai pašreizējā praksē tiek izmantots reālais uzdevums? Ja apmācība aptver uzvednes rakstīšanu, bet nekad nelūdz izstrādātājiem pārskatīt rezultātu, neviens nav praktizējis auditēšanu. Ja novērtējums ir tests ar atbilžu variantiem par drošas kodēšanas noteikumiem, tas mēra atcerēšanos.
- Kāda ir kognitīvā prasība? Blūma pārskatītajā taksonomijā koda drošības novērtēšana un tā pierādīšanas testa izvēle atrodas analīzes un novērtēšanas līmeņos, bet labākas uzvednes vai labojuma izstrāde sasniedz izveides līmeni. Aktivitāšu saskaņošana ar šiem līmeņiem ir aplūkota mūsu ceļvedī par mācību aktivitāšu saskaņošana ar Blūma taksonomiju.
- Vai kaut kas cits, nevis prasmes, traucē? Pārbaudiet pārskatīšanas laiku, rīkus un īpašumtiesības. Ja recenzentiem ir piecas minūtes katram pieprasījumam, apmācība neradīs auditu. Ja nav statiskās analīzes vai testēšanas komplekta, izstrādātājs var atrast risku, bet nepamatot to. Ziņojiet par iemesliem, kas nav saistīti ar apmācību, personām, kuras tos var novērst.
3. Dizaina sagatavošana un prakse
Kad esat noskaidrojis, kuras nepilnības apmācība var novērst, piešķiriet katram posmam atšķirīgu uzdevumu.
Sagatavošana. Pārbaudiet priekšnosacījumus, veicot īsu diagnostiku: biežāk sastopamās vājo vietu kategorijas, ar kurām saskaras jūsu testu komplekts, kā ir strukturēti jūsu testi, pārskatīšanas kontrolsaraksts, ko izmanto jūsu komanda. Šim posmam ir piemērota pašmācība. Atgādināšanas pārbaude apstiprina tikai priekšnosacījumus.
Prakse. Izmantojiet audita vingrinājumus, kas veidoti no reālistiski ģenerēta koda. Katram no tiem pievienojiet nelielu skaitu dažāda veida defektu, piemēram, trūkstošu īpašumtiesību pārbaudi, sacensību starp diviem pieprasījumiem un neefektīvu ciklu, kā arī kodu, kas ir labs. Izstrādātājs pārskata, nosauc katru risku, norāda tā nopietnību un piedāvā testu, kas to parādītu. Lūdziet pamatojumu, nevis rindu numuru sarakstu.
Atsauksmes. Saistiet to ar lēmumiem, nevis kopējo rezultātu. "Jūs atzīmējāt ciklu, bet ne sacensības koplietotajā skaitītājā, un jūsu tests to nebūtu notvēris, jo tas palaiž pieprasījumus pa vienam" ir noderīgāk nekā "Atrasti 2 no 3".
Tiešraides ievade vai asinhrona pārskatīšana? Tiešraides ievade sniedz vislielāko vērtību, ja risks ir neskaidrs un izstrādātāji mācās, dzirdot vecākā inženiera skaidrojumu, kāpēc viņi bloķētu apvienošanu. Asinhrona pārskatīšana ir pietiekama, lai salīdzinātu izstrādātāja atklājumus ar anotētu eksperta pārskatu. Daudzas komandas izmanto abus: vispirms patstāvīgu sagatavošanos, pēc tam vadītu sesiju par sarežģītiem gadījumiem.
4. Izstrādājiet reālistisku piemēru
Ilustratīvi. Inženiertehniskajam vadītājam pirms lietošanas ir jāapstiprina gadījums un atbildes kritēriji.
Lieta. Ģenerēts galapunkts atgriež klienta rēķinu pēc rēķina ID. Tas pārbauda, vai zvanītājam ir derīga sesija, izmanto parametrizētu vaicājumu un iztur pamata testu. Tā pati funkcija palielina koplietoto lejupielāžu skaitītāju bez bloķēšanas.
Uzdevums. Izstrādātājs norāda katru risku, ko viņš saskata, sarindo tos un apraksta testu, kas katru pamatotu.
Pirmais mēģinājums. "Izskatās labi. Vaicājums ir parametrizēts, un tests ir sekmīgs." Izstrādātājs ir uzskatījis sekmīgo testu par pierādījumu un nav jautājis, ko tests neaptver.
Atsauksmes un mēģinājums vēlreiz. Recenzents lūdz izstrādātājam nosaukt, ko sesijas pārbaude pierāda un ko nepierāda. Atkārtotajā mēģinājumā viņam tiek lūgts apsvērt divus dažādus klientus un divus vienlaicīgus pieprasījumus.
Spēcīgāks mēģinājums. "Sesijas pārbaude pierāda, kurš zvana, nevis to, ka rēķins ir viņa. Es uzrakstītu testu, kurā klients A pieprasa klienta B rēķina ID un sagaida atteikumu. Skaitītājs tiek palielināts bez sinhronizācijas, tāpēc divi pieprasījumi vienlaikus varētu zaudēt atjauninājumu. Es palaistu vienlaicīgu testu un salīdzinātu skaitītāju. Pats vaicājums ir parametrizēts, tāpēc es tur netērētu laiku." Ievērojiet, ka šī atbilde sarindo riskus un saista katru ar testu.
Kāpēc katra atbilde ir aizstāvama vai nepilnīga. Vērtējiet katru pēc apstiprinātiem kritērijiem, nevis pēc recenzenta vēlmēm. Pirmais mēģinājums seko ieradumam, bet izlaiž pierādījumus. Spēcīgākais mēģinājums ir specifisks, prioritārs un pārbaudāms.
5. Novērtējiet spējas un plānojiet nodošanu
Spēju pierādījums ir jauna vingrinājuma izpilde, ko students vēl nav redzējis. Rezultātu pārbaudes kvalitāte un attiecīgo defektu identificēšana. Vienkāršā rubrikā katram kritērijam tiek izmantota skala no 0 līdz 2:
| Kritērijs | Novērojami pierādījumi |
|---|---|
| Uzdevuma izpilde | Auditē ģenerēto kodu un reģistrē katra atraduma pamatojumu. |
| Pamatojums | Izskaidro ierobežojumus, alternatīvas un to, kas joprojām ir neskaidrs, kā arī sarindo riskus. |
| Robežas | Ievēro komandas pārskatīšanas noteikumus un ziņo drošības speciālistam, ja risks pārsniedz viņa kompetenci. |
Enkuri: 0 nav vai netiek atbalstīti, 1 ir daļēji ar būtiskiem izlaidumiem un 2 ir pilnīgi un pamatoti atbilstoši saskaņotajiem kritērijiem. Atsevišķi definējiet kritiskas kļūdas, piemēram, koda apstiprināšanu ar neaizsargātu piekļuves ceļu, lai kopējais vērtējums nevarētu to slēpt. Šī rubrika ir priekšlikums, nevis apstiprināts gatavības standarts: pielāgojiet to kopā ar inženierijas vadītāju un izmēģiniet to. Mūsu ceļvedis interaktīvas prakses izstrāde ar noderīgu atgriezenisko saiti parāda, kā rakstīt atsauksmes, kas saistītas ar lēmumiem.
Apdomīgi plānojiet pārsūtīšanu. Pēc vingrinājuma katram izstrādātājam piešķiriet īstu pieprasījumu (pull request), kas ietver ģenerētu kodu, un kopīgi pārskatiet viņu atklājumus vai arī veiciet īsu retrospektīvu par nesenu pārskatu, kurā kaut kas netika pamanīts.
Kur palīdz interaktīva piegāde
Interaktīvie formāti palīdz, ja ikvienam ir jāapņemas, pirms tiekas ar grupu. Tiešraides sesijā vadītājs var parādīt ģenerētu fragmentu, lūgt katram izstrādātājam ierakstīt redzamos riskus un testu, ko viņš rakstītu, un pēc tam atklāt izkliedi pirms diskusijas. To pašu vingrinājumu var veikt patstāvīgi, lai sagatavotos. AhaSlides atbalsta interaktīvu mācīšanos un pāreju starp tiešraides un patstāvīgu mācīšanu. Tas ir prezentāciju un mācību rīks, nevis vieta koda palaišanai, tāpēc veiciet koda vingrinājumus savā vidē. Pārbaudiet jebkuru konkrētu autorēšanas, atsauksmju vai atskaišu veidošanas funkciju, uz kuru plānojat paļauties savā darbplūsmā. Lai iegūtu norādījumus par formātu izvēli, skatiet mūsu rakstu par Kad izmantot adaptīvo, interaktīvo un tiešo mācīšanos.
Izmēriet izmaiņas
Iepriekš izlemiet, kas parādītu, ka izstrādātāji spēj veikt uzdevumu. Salīdziniet verifikācijas kvalitāti un defektu identificēšanu neredzamā uzdevumā ar sākotnējo līmeni. Definējiet, kas ir iekļauts, saucēju un laiku. Ja rezultāti uzlabojas, pirms apmācības ieskaitīšanas pārbaudiet, kas vēl ir mainījies tajā pašā laika posmā, piemēram, jauns statiskās analīzes noteikums, pārskatīts pārskatīšanas kontrolsaraksts vai asistenta maiņa.
Ierobežojumi, kas var palikt
- Pārskatīšanas laiks. Revīzija aizņem ilgāku laiku nekā ātra pārskatīšana, un termiņi spiež ātrāk veikt ātru pārskatīšanu.
- Instrumentu izgatavošana. Bez testa instalācijas vai skenēšanas cauruļvadā risku ir grūti pamatot.
- Instrumentu maiņa. Asistenti mainās ātri, tāpēc vingrinājumus veidojiet par atsauksmju sniegšanas paradumu, nevis par vienu produktu.
- Lietas pārklājums. Vienā vingrinājumā ir parādīti daži defektu veidi. Punktu skaits neraksturo izstrādātāja spriedumu kopumā.
- Pārskaitījums. Uzstāšanās darbnīcā nav tas pats, kas uzstāšanās saspringtā recenziju rindā.
Nosauciet tos sponsoriem jau laikus un plānojiet atsevišķus labojumus. Apmācība uzlabo to, ko izstrādātājs var atrast un pierādīt. Tā nerada laiku vai rīkus.
Biežāk uzdotie jautājumi
Kas ir mākslīgā intelekta ģenerēta koda pārskatīšanas apmācība?
Tas māca izstrādātājiem vadīt, novērtēt un auditēt mākslīgā intelekta asistenta izveidoto kodu, atrodot drošības, vienlaicības un efektivitātes problēmas un katru no tām pamatojot ar testu.
Vai ģenerētais kods ir mazāk drošs nekā cilvēka kods?
Pētījumi norāda uz risku, taču rezultāti ir atkarīgi no rīka, uzdevuma un pētījuma dizaina. Vienā lietotāju pētījumā tika atklāts, ka dalībnieki ar asistentu rakstīja mazāk drošu kodu un jutās par to pārliecinātāki, kas ir iemesls, lai apmācītu pārskatīšanas ieradumu.
Kā jūs novērtējat, vai izstrādātāji var auditēt ģenerēto kodu?
Dodiet jaunu koda uzdevumu un novērtējiet pārbaudes kvalitāti un defektu identificēšanu atbilstoši saskaņotajiem kritērijiem. Viktorīna par drošas kodēšanas noteikumiem apstiprina tikai priekšnosacījumus.
Vai apmācībai ir nepieciešama koda smilškaste?
Tev ir nepieciešama vieta, kur veikt vingrinājumus, kas parasti ir tava vide. Pirms paļausies uz jebkuru izmantoto rīku, pārliecinies, ka tas atbilst tavam vajadzībām.
Kur sākt
Izvēlieties vienu atkārtotu ģenerēto izmaiņu veidu savā koda bāzē. Uzrakstiet veiktspējas pārskatu, palūdziet inženierijas vadītājam apstiprināt sākotnēji paredzētos defektus un testus, kas tos parādītu, un izveidojiet trīs kritēriju rubriku ar skalu no 0 līdz 2 un kritisko kļūdu sarakstu. Pirms ieviešanas izmēģiniet to nelielā grupā.
Lai uzzinātu, kā audita uzdevumu varētu veikt tiešsaistē ar savu komandu un pēc tam atkārtoti izmantot patstāvīgi, izpētiet AhaSlides.
