Bedrock Guardrails kodui: DI programuotojui reikia saugos diržo
·
Bedrock Guardrails kodui iš pirmo žvilgsnio skamba kaip dar viena DI naujiena. Bet man čia įdomiausias labai žemiškas klausimas: ką žmogui ar komandai reikės daryti kitaip jau šią savaitę?
AWS aprašė, kaip Amazon Bedrock Guardrails taikyti kodo generavimo darbo eigoms. Čia tema paprasta: kai DI rašo kodą, vien greičio neužtenka. Reikia saugos diržo.
Atvirai? DI naujienų dabar tiek, kad smegenys kartais nori paspausti „unsubscribe“ visam internetui. Bet kai žiūri ne į triukšmą, o į darbą, kai kurios temos lieka ant stalo.
KAS NUTIKO
Straipsnis kalba apie guardrails konfigūravimą DI kodavimo asistentams: kaip valdyti rizikingą turinį, planuoti pajėgumus, mažinti klaidingus blokavimus ir neleisti asistentui peržengti organizacijos ribų.
Programuotojai jau priprato, kad DI gali parašyti funkciją, testą ar paaiškinti klaidą. Bet gera diena su DI kodu baigiasi ne tada, kai atsakymas atrodo gražiai. Ji baigiasi tada, kai kodas pereina review, testus ir saugumo patikrą.
KODĖL TAI SVARBU
Bedrock Guardrails kodui svarbūs todėl, kad kodo generavimas turi kitokią klaidos kainą nei tekstas. Blogas sakinys erzina. Blogas kodo pasiūlymas gali atidaryti pažeidžiamumą, nutekinti paslaptį arba sugadinti produkciją.
DI jau seniai nebėra vien tekstų generatorius. Jis jungiasi prie dokumentų, duomenų bazių, sveikatos įrašų, klientų kanalų, prekybos sistemų ir vidinių procesų. O ten klaidos kainuoja daugiau nei vienas negražus sakinys.
KĄ TAI REIŠKIA VERSLUI
Verslui tai reiškia, kad DI kodavimo politika turi būti techninė, ne tik dokumentas stalčiuje. Komandos turi aiškiai žinoti, ką DI gali generuoti, ko negali ir kur žmogaus peržiūra privaloma.
- blokuoti paslapčių ir jautrių duomenų įkėlimą
- tikrinti kodo saugumo rizikas
- atskirti pagalbinį kodą nuo produkcinio
- matuoti klaidingus blokavimus ir juos taisyti
Pirmas praktinis žingsnis – įtraukti DI sugeneruotą kodą į tą patį review procesą kaip žmogaus kodą. Be nuolaidų. Nes produkcijai nesvarbu, kas parašė klaidą.
KUR PASISLĖPUSI RIZIKA
Rizika – guardrails paversti tik gražiu compliance žodžiu. Jei jie blokuoja per daug, komanda juos apeis. Jei per mažai, turėsite tylų pavojų.
Blogiausia DI klaida dažnai ateina gražiai. Ramiai. Su mandagiu tonu ir pasitikėjimu savimi. Todėl čia reikia ne tik entuziazmo, bet ir tikrinimo įpročio.
KĄ PASIDARYTI ŠIĄ SAVAITĘ
Peržiūrėkite vieną DI kodavimo įrankį komandoje ir atsakykite: ar jis mato paslaptis, ar turi ribas, ar jo pasiūlymai tikrinami automatizuotai?
Šaltinis: Amazon Web Services.
DUK
Kas yra Bedrock Guardrails?
Tai AWS saugumo ir valdymo funkcijos, kurios padeda riboti nepageidaujamą DI elgesį.
Kodėl jos svarbios kodui?
Nes DI kodo klaidos gali sukurti saugumo, privatumo ar produkcijos rizikas.
Nuo ko pradėti?
Nuo aiškių taisyklių dėl paslapčių, kodo review ir automatinės saugumo patikros.
Jei norite DI naudoti praktiškai, pradėkite nuo vieno proceso, ne nuo visos įmonės pertvarkymo. Susirašykite, kur dingsta laikas, kur atsiranda klaidos ir kur žmogaus peržiūra būtina. Daugiau praktinių DI taikymo pavyzdžių rasite MasterSprint.
