Egy fejlesztő egy asszisztenstől kér egy függvényt, amely ellenőrzi, hogy a felhasználó letölthet-e egy jelentést. A kód lefordul. A happy-path teszt sikeres. A pull request rendezettnek tűnik. Két héttel később egy kolléga észreveszi, hogy a függvény ellenőrzi, hogy a felhasználó be van-e jelentkezve, de soha nem ellenőrzi, hogy a jelentés hozzá tartozik-e.
Ez egy szemléltető forgatókönyv, nem egy dokumentált incidens. Azt a hiányosságot írja le, amelyet a mesterséges intelligencia által generált kódfelülvizsgálati képzésnek kell betöltenie: az alapvető ellenőrzésen átmenő generált kód továbbra is tartalmazhat jogosultsági vagy párhuzamossági hibát, és az azt felülvizsgáló személynek meg kell találnia ezt, és el kell mondania, hogy miért fontos.
Ez az útmutató mérnöki támogatási vezetők és mérnöki menedzserek számára készült. Kitér arra, hogyan kell leírni a teljesítményproblémát, diagnosztizálni a hiányosságokat, a tervezés előkészítését és gyakorlatát, hogyan kell egy esetet feldolgozni, és hogyan kell értékelni, hogy a készségek átvihetők-e a valódi felülvizsgálatokba. A tervezés betanításáról szól. A programban szereplő minden hibát, tesztet és felülvizsgálati szabályt a vezető mérnököknek és a biztonsági csapatnak kell validálnia.
Mi az a mesterséges intelligencia által generált kódáttekintési képzés?
A mesterséges intelligencia által generált kódátvizsgálási képzés megtanítja a fejlesztőket arra, hogy világosan utasítsák az asszisztenst, majd értékeljék és auditálják a visszajelzéseket: helyesek-e, biztonságosak-e, egyidejű terhelés alatt is viselkednek-e, elég hatékonyak-e? Ez nem egy adott eszközről szóló kurzus. Egy olyan áttekintési szokást képez, amely akkor is változatlan marad, amikor az eszköz megváltozik.
Gyors tények
| Kérdés | Rövid válasz |
|---|---|
| Mi a feladat? | Auditáld a generált kódot, és támaszd alá minden kockázatot egy teszttel. |
| Mit érsz el? | Az ellenőrzés minősége és hogy találtak-e releváns hibákat. |
| Elég egy kvíz a biztonságos kódolási szabályokról? | Nem. Megerősíti az előfeltételeket, de nem azt, hogy egy fejlesztő képes-e észrevenni egy valószínűnek tűnő hibát a kódban. |
| Ki ellenőrzi a tartalmat? | Egy műszaki vezető és a biztonsági csapatod. |
| Mit nem old meg a tréning? | Felülvizsgálati idő, eszközök, nem egyértelmű tulajdonjogok és a gyors egyesülésre irányuló nyomás. |
| Honnan tudod, hogy működött? | Egy új, nem látott kódgyakorlat, amelyet egyeztetett kritériumok alapján pontoznak, és valós értékelések alapján folytatnak nyomon követést. |
1. Írd le a teljesítményproblémát
Kezdjük a feladattal: auditáljuk a generált kódot, és tesztekkel támasztjuk alá a kockázatokat. Az auditálás gyanakvással való olvasást jelent. Az alátámasztás a gyanú bizonyítékká alakítását jelenti, általában egy sikertelen teszttel vagy egy olyan reprodukcióval, amely bemutatja a hibát.
A kutatás arra utal, hogy miért van szükség ennek tudatos gyakorlására. A GitHub Copilot egyik tanulmányában Pearce és kollégái 1,689 programot generáltak 89 ismert gyengeségtípusra kiválasztott forgatókönyv alapján, és azt találták, hogy ezek körülbelül 40 százaléka sebezhető volt (Pearce és munkatársai, 2021). Ez egy korai eszköz volt, és egy specifikus forgatókönyv-készletet tartalmazott, ezért ne tekintsük az adatot a mai asszisztensek arányának. Egy külön felhasználói tanulmányban a résztvevőket arra kérték, hogy MI-asszisztenssel és anélkül írjanak kódot. Azok, akik rendelkeztek az asszisztenssel, lényegesen kevesebb biztonságos kódot írtak, és nagyobb valószínűséggel hitték úgy, hogy a kódjuk biztonságos (Perry és munkatársai, 2023Ugyanez a tanulmány megállapította, hogy azok a résztvevők, akik kevésbé bíztak az asszisztensben, és jobban reagáltak az utasításaira, kevesebb sebezhetőséget mutattak.
Két tanulság következik a betanítási tervezéshez. A hihető kimenethez aktív felülvizsgálóra van szükség. A magabiztosság pedig nem bizonyíték, ezért a gyakorlatnak a tesztre kell rákérdeznie, nem a véleményre.
Írd le a teljesítménynyilatkozatot egy mondatban, és kérd meg egy mérnököt, hogy ellenőrizze: „Egy generált módosítás esetén a fejlesztő felsorolja a biztonsági, párhuzamossági és hatékonysági kockázatokat, amelyeket lát, és mindegyikhez leír vagy ír egy tesztet, amely ezt bemutatja.”
2. A tanulási és kontextuális hiányosságok diagnosztizálása
Mielőtt bármit is felépítenél, hasonlítsd össze a feladatot azzal, amit a jelenlegi programod gyakorol és értékel. Három kérdés általában megkülönböztet egy képzési hiányosságot valami mástól:
- A jelenlegi gyakorlat a valódi feladatot használja? Ha a képzés a gyorsírást is magában foglalja, de soha nem kérik a fejlesztőket a kimenet ellenőrzésére, akkor senki sem gyakorolta az auditálást. Ha az értékelés egy feleletválasztós teszt a biztonságos kódolási szabályokról, akkor a felidézést méri.
- Mi a kognitív igény? Bloom átdolgozott taxonómiájában a kód biztonságosságának megítélése és az azt bizonyító teszt kiválasztása az elemzés és értékelés szintjén található, míg egy jobb prompt vagy egy javítás megtervezése eléri a létrehozás szintjét. A tevékenységek ezen szintekhez való illesztését az útmutatónk tárgyalja. tanulási tevékenységek Bloom taxonómiájához való illesztése.
- Vajon a képességen kívül valami más is akadályozza? Ellenőrizd az átvizsgálási időt, az eszközöket és a tulajdonjogot. Ha az átnézőknek öt percük van kérésenként, akkor a betanítás nem eredményez auditot. Ha nincs statikus elemzés vagy tesztkábelezés a folyamatban, a fejlesztő találhat kockázatot, de nem tudja alátámasztani azt. A nem betanításból eredő okokat jelentsd azoknak, akik kijavíthatják azokat.
3. Tervezés előkészítése és gyakorlása
Miután megtudta, mely hiányosságokat tudja a képzés pótolni, adjon minden szakasznak külön feladatot.
Készítmény. Egy rövid diagnosztikával ellenőrizd az előfeltételeket: a tesztvermeddel kapcsolatos gyakori gyengeségek kategóriái, a tesztek strukturálása, a csapatod által használt ellenőrzőlista. Az önálló tempójú tanulás alkalmas erre a szakaszra. Az előfeltételek ellenőrzése csak az előfeltételek teljesülését erősíti meg.
Gyakorlat. Használj realisztikus generált kódból épített auditgyakorlatokat. Mindegyikben adj meg néhány, különböző típusú hibát, például hiányzó tulajdonos-ellenőrzést, két kérés közötti versenyfutást és egy nem hatékony ciklust, plusz néhány jó kódot. A fejlesztő áttekinti, megnevezi az egyes kockázatokat, megállapítja azok súlyosságát, és javaslatot tesz a tesztre, amely kimutatná azokat. Indoklást kérj, ne sorszámok listáját.
Visszacsatolás. Döntésekhez kösd, ne pedig egy összpontszámhoz. A „Megjelölted a ciklust, de a versenyt nem a megosztott számlálón, és a teszted nem kapta volna el, mert egyszerre csak egy kérést futtat” válasz hasznosabb, mint a „3-ból 2 megtalálva”.
Élő bemenet vagy aszinkron értékelés? Az élő visszajelzés akkor ad a legtöbb értéket, ha egy kockázat nem egyértelmű, és a fejlesztők abból tanulnak, hogy egy vezető mérnök elmagyarázza, miért blokkolnák az egyesítést. Az aszinkron felülvizsgálat elegendő ahhoz, hogy a fejlesztő megállapításait összehasonlítsuk egy jegyzetekkel ellátott szakértői felülvizsgálattal. Sok csapat mindkettőt alkalmazza: először az önálló ütemű felkészülést, majd egy facilitált ülést a nehéz eseteken.
4. Dolgozz ki egy valós példát
Szemléltető példa. A mérnöki vezetőnek használat előtt validálnia kell az esetet és a válaszkritériumokat.
Az eset. Egy generált végpont a számla azonosítója alapján adja vissza az ügyfél számláját. Ellenőrzi, hogy a hívó érvényes munkamenettel rendelkezik-e, paraméteres lekérdezést használ, és átmegy az alapteszten. Ugyanez a függvény egy megosztott letöltési számlálót is növel zárolás nélkül.
A feladat. A fejlesztő felsorolja az általa látott kockázatokat, rangsorolja azokat, és leírja az egyes kockázatokat alátámasztó tesztet.
Első próbálkozás. „Jól néz ki. A lekérdezés paraméterezett és a teszt sikeres.” A fejlesztő a sikeres tesztet bizonyítékként kezelte, és nem kérdezte meg, hogy mit nem fed le a teszt.
Visszajelzés és újrapróbálás. A felülvizsgáló megkéri a fejlesztőt, hogy nevezze meg, mit bizonyít a munkamenet-ellenőrzés, és mit nem. Az újrapróbálkozás során két különböző ügyfelet és két egyidejű kérést kell figyelembe vennie.
Egy erősebb próbálkozás. „A munkamenet-ellenőrzés azt bizonyítja, hogy ki hívja a hívót, nem azt, hogy a számla az övé. Írnék egy tesztet, ahol A ügyfél lekéri B ügyfél számlaazonosítóját, és elutasításra számít. A számláló szinkronizálás nélkül növekszik, így két egyszerre érkező kérés esetén elveszhet a frissítés. Egyidejű tesztet futtatnék, és összehasonlítanám a számlálót. Maga a lekérdezés paraméterezett, így nem töltenék ott az időt.” Figyeljük meg, hogy ez a válasz rangsorolja a kockázatokat, és mindegyiket egy teszthez köti.
Miért védhető vagy hiányos az egyes válaszok? Mindegyiket jóváhagyott kritériumok alapján ítéld meg, ne a bíráló preferenciái alapján. Az első próbálkozás egy szokást követ, de kihagyja a bizonyítékokat. Az erősebb próbálkozás specifikus, rangsorolt és tesztelhető.
5. Képességfelmérés és a terv átadása
A képesség bizonyítéka egy új, a tanuló által még nem látott gyakorlat teljesítménye. A pontszám ellenőrzésének minősége és a releváns hibák azonosítása. Egy egyszerű értékelőlap kritériumonként 0-tól 2-ig terjedő skálát használ:
| Kritérium | Megfigyelhető bizonyítékok |
|---|---|
| Feladat végrehajtása | Ellenőrzi a generált kódot, és rögzíti az egyes megállapítások mögött álló bizonyítékokat. |
| Érvelés | Elmagyarázza a korlátokat, az alternatívákat és a bizonytalanságokat, valamint rangsorolja a kockázatokat. |
| Határok | Követi a csapat felülvizsgálati szabályait, és biztonsági szakemberhez továbbítja az ügyet, ha a kockázat meghaladja a hatáskörét. |
Horgonyok: 0 hiányzik vagy nem támogatott, 1 részleges, releváns hiányosságokkal, és 2 teljes és a megállapodás szerinti kritériumok alapján indokolt. A kritikus hibákat külön kell meghatározni, például a nem védett hozzáférési útvonallal rendelkező kód jóváhagyásakor, hogy az összesített pontszám ne rejtsen el egyet. Ez a rubrika egy javaslat, nem pedig egy validált készültségi szabvány: adaptálja egy mérnöki vezetővel, és tesztelje. Útmutatónk a következőhöz: interaktív gyakorlatok tervezése hasznos visszajelzésekkel bemutatja, hogyan kell döntésekhez kapcsolódó visszajelzést írni.
Tervezd meg tudatosan az átadást. A gyakorlat után párosíts minden fejlesztőt egy valódi pull requesttel, amely tartalmazza a generált kódot, és tekintsétek át együtt az eredményeiket, vagy készítsetek egy rövid retrospektív elemzést egy nemrégiben elvégzett, kihagyott áttekintésről.
Ahol az interaktív közvetítés segít
Az interaktív formátumok segítenek, ahol mindenkinek el kell köteleznie magát, mielőtt találkozik a csoporttal. Egy élő ülésen a facilitátor megmutathat egy generált kódrészletet, megkérheti az egyes fejlesztőket, hogy írják be a látott kockázatokat és a tesztet, amelyet megírnának, majd a megbeszélés előtt felfedheti a tesztterjedelmet. Ugyanez a gyakorlat önálló tempóban is elvégezhető a felkészülés érdekében. AhaSlides támogatja az interaktív tanulást és az élő, valamint az önálló tempójú előadásmód közötti váltást. Ez egy prezentációs és tanulási eszköz, nem pedig kód futtatására szolgáló hely, ezért a kódgyakorlatokat a saját környezetedben futtasd. Ellenőrizd azokat a konkrét szerzői, visszajelzési vagy jelentéskészítési funkciókat, amelyekre a saját munkafolyamatodban támaszkodni tervezel. A formátumok kiválasztásával kapcsolatos útmutatásért lásd a cikkünket a ... témában. Mikor alkalmazzunk adaptív, interaktív és élő tanulást?.
Mérd meg, mi változott
Előre döntsd el, mi mutatná meg, hogy a fejlesztők képesek elvégezni a feladatot. Hasonlítsd össze egy nem látott gyakorlat ellenőrzési minőségét és hibaazonosítását egy alapértékkel. Határozd meg, hogy kik vesznek részt, a nevezőt és az időzítést. Ha az eredmények javulnak, ellenőrizd, hogy mi változott még ugyanebben az időszakban, például új statikus elemzési szabály, felülvizsgált ellenőrzőlista vagy asszisztensváltás, mielőtt jóváírnád a képzést.
Maradhatnak korlátok
- Felülvizsgálati idő. Egy audit tovább tart, mint egy átfutásos ellenőrzés, és a határidők a túlfutás felé tolják el az időt.
- Szerszámozás. Tesztkábelezés vagy a csővezetékben lévő szkennelés nélkül a kockázat nehezen megalapozható.
- Eszközök cseréje. Az asszisztensek gyorsan változnak, ezért a gyakorlatokat a véleményezési szokásokról, ne egyetlen termékről végezd.
- Eseti lefedettség. Az egyik gyakorlat néhány hibatípust mutat be. A pontszám nem általánosságban írja le a fejlesztő ítélőképességét.
- Átadása. Egy workshopon nyújtott teljesítmény nem ugyanaz, mint egy zsúfolt összefoglaló sorban.
Nevezd meg ezeket a szponzoroknak időben, és tervezz külön javításokat. A képzés javítja azt, amit a fejlesztő megtalálhat és bizonyíthat. Nem teremti meg az időt vagy az eszközöket.
Gyakran Ismételt Kérdések
Mi az a mesterséges intelligencia által generált kódáttekintési képzés?
Megtanítja a fejlesztőket egy MI-asszisztens által létrehozott kód promptolására, értékelésére és auditálására, biztonsági, párhuzamossági és hatékonysági problémák felkutatására, és mindegyiket teszttel alátámasztására.
A generált kód kevésbé biztonságos, mint az emberi kód?
A tanulmányok kockázatot mutatnak, de az eredmények az eszköztől, a feladattól és a tanulmány felépítésétől függenek. Egy felhasználói tanulmány szerint az asszisztenssel rendelkező résztvevők kevésbé biztonságos kódot írtak, és magabiztosabbnak érezték magukat vele kapcsolatban, ami indokolja az ellenőrzési szokás képzését.
Hogyan értékeled, hogy a fejlesztők képesek-e auditálni a generált kódot?
Adj egy új kódfeladatot, és pontozd az ellenőrzés minőségét és a hibák azonosítását a megállapodott kritériumok alapján. A biztonságos kódolási szabályokról szóló kvíz csak az előfeltételeket erősíti meg.
Szükséged van egy kódtesztkörnyezetre a betanításhoz?
Szükséged van egy helyre a gyakorlatok elvégzéséhez, ami általában a saját környezeted. Mielőtt bármilyen eszközre támaszkodnál, ellenőrizd, hogy az általad használt eszköz támogatja-e az igényeidet.
Hol kezdjem
Válassz ki egy ismétlődő típusú generált változást a kódbázisodban. Írd meg a teljesítménynyilatkozatot, kérd meg egy mérnököt, hogy validálja a feltételezett hibákat és a azokat mutató teszteket, majd készíts egy háromkritériumú rubrikát 0-tól 2-ig terjedő skálával és a kritikus hibák listájával. Mielőtt bevezetnéd, teszteld egy kis csoporttal.
Ha szeretné megtudni, hogyan futtatható le egy audit a saját csapatával, és hogyan használható fel később önálló ütemben, tekintse meg a következő részt: AhaSlides.
