Organizacijos struktūra ir pokyčių valdymas: saugus autonominių koduotojų diegimas

Įvadas

Autonominiai kodavimo agentai yra programinės įrangos įrankiai, kurie gali tikrinti kodų bazę, suprasti problemą, planuoti pakeitimą, redaguoti failus, vykdyti testus ir atidaryti pakeitimų užklausą (pull request) žmogaus peržiūrai. Kai kurie taip pat gali veikti pagal tvarkaraštį, reaguoti į saugyklos įvykius, klasifikuoti problemas, atnaujinti priklausomybes arba tvarkyti dokumentaciją.

Šis gebėjimas keičia ne tik kūrėjo darbo vietą. Jis keičia kas atlieka programinės įrangos darbą, kaip darbas paskiriamas, kaip peržiūrimas kodas, ką matuoja vadovai ir kur yra atskaitomybė.

Saugiausios organizacijos nepradeda klausdamos: „Kaip greitai galime leisti agentui rašyti produkcinį kodą?“ Jos klausia:

Kurį darbą saugu deleguoti?
Kokius įrodymus turi pateikti agentas?
Kas yra atsakingas už rezultatą?
Kokių leidimų reikia agentui?
Kaip organizacija gali sustabdyti arba atšaukti jo veiksmus?
Kaip kūrėjai išmoks naujo darbo eigos, nesijausdami grėsmės?

Iki šiol gauti įrodymai palaiko atsargų, nuo konteksto priklausantį požiūrį. 2025 m. „Model Evaluation and Threat Research“ organizacijos atliktas atsitiktinis tyrimas parodė, kad 16 patyrusių atvirojo kodo kūrėjų užtruko 19 procentų ilgiau, o ne trumpiau, kai naudojo 2025 m. pradžios dirbtinio intelekto kodavimo įrankius žinomose saugyklose. Kiti lauko eksperimentai pranešė apie produktyvumo padidėjimą skirtingose aplinkose. Pamoka nėra ta, kad kodavimo agentai yra neveiksmingi. Tai reiškia, kad įrankio galimybės, užduoties tipas, kūrėjo patirtis, kodų bazės kokybė ir organizacijos darbo eiga – visa tai yra svarbu. (metr.org) [Source 2]

2025 m. „DevOps Research and Assessment“ ataskaita pasiekia panašią organizacinę išvadą: dirbtinis intelektas veikia kaip stiprintuvas. Jis stiprina organizacijas, turinčias aiškias darbo eigas, patikimas platformas, gerą testavimą ir stiprias grįžtamojo ryšio sistemas. Jis taip pat išryškina silpnus procesus, prastą dokumentaciją, nestabilius prioritetus ir neaiškią nuosavybę. (dora.dev) [Source 1]

Šis straipsnis pristato praktinį veiklos modelį, kaip saugiai diegti kodavimo agentus naudojant bandomąsias komandas, kompetencijos centrą ir federacinį valdymą.

Ką iš tikrųjų keičia autonominiai kodavimo agentai

Tradiciniai kodavimo asistentai teikia pasiūlymus, kol kūrėjas rašo kodą. Autonomiškesni agentai gali atlikti veiksmų seką:

Perskaityti problemos ar užduoties aprašymą.
Patikrinti susijusius failus ir dokumentaciją.
Sudaryti įgyvendinimo planą.
Modifikuoti kelis failus.
Vykdyti testus, „linters“ ir saugumo patikrinimus.
Paaiškinti pakeitimus.
Atidaryti arba atnaujinti pakeitimų užklausą.
Atsakyti į peržiūros komentarus.
Kartoti ciklą, kol darbas atitiks apibrėžtas sąlygas.

Pavyzdžiui, GitHub Copilot debesies agentas gali tirti saugyklą, atlikti kodo pakeitimus ir sukurti pakeitimų užklausą peržiūrai. Jo automatizavimas gali veikti pagal tvarkaraštį arba reaguodamas į problemas ir pakeitimų užklausas. GitHub taip pat dokumentuoja valdiklius, skirtus įrankių ribojimui, agentų sesijų peržiūrai, automatizavimo išjungimui ir žmogaus peržiūros reikalavimui prieš sujungimą. (docs.github.com)

Tai sukuria keturis organizacinius pokyčius:

Nuo kodo rašymo prie kodo nukreipimo ir vertinimo.
Nuo individualių užduočių prie užduočių eilių, kurias agentai gali apdoroti nuolat.
Nuo periodinės priežiūros prie nuolatinės priežiūros.
Nuo numanomo kūrėjo sprendimo prie aiškios politikos, testų, instrukcijų ir patvirtinimo taisyklių.

Kodavimo agentai yra naudingiausi organizacijoms, kurios jau turi:

Pirminį kodą versijų valdymo sistemoje.
Veikiantį pakeitimų užklausų procesą.
Automatizuotus testus.
Aiškų paslaugų ir failų nuosavybės nustatymą.
Atkartojamas kūrimo aplinkas.
Pasiryžimą matuoti rezultatus, o ne pasikliauti entuziazmu.

Jos mažiau tinka kaip pirmas žingsnis organizacijoms, neturinčioms patikimo testavimo, nedokumentuotų sistemų, neaiškios nuosavybės ar kultūros, kuri kiekvieną naują įrankį traktuoja kaip privalomą.

Pagrindinis dizaino principas: valdykite darbo eigą, o ne tik modelį

Kodavimo agentas yra tik dalis didesnės sistemos. Saugiam diegimui reikalingi valdikliai, apimantys:

Identitetas: Kuris asmuo ar paslaugos paskyra inicijavo užduotį?
Įgaliojimai: Ką agentas gali skaityti, keisti ar vykdyti?
Įrodymai: Kokie testai, patikrinimai ir paaiškinimai turi lydėti pakeitimą?
Peržiūra: Kas turi tai patvirtinti?
Diegimas: Kaip palaipsniui pakeitimas gali pasiekti vartotojus?
Stebimumas: Ar administratoriai gali atkurti, kas nutiko?
Atkūrimas: Ar pakeitimas, agentas ar funkcija gali būti greitai sustabdyta?

Nacionalinis standartų ir technologijų institutas (National Institute of Standards and Technology) rekomenduoja atsižvelgti į patikimumą viso dirbtinio intelekto gyvavimo ciklo metu, įskaitant projektavimą, kūrimą, diegimą, naudojimą, testavimą ir vertinimą. Kodavimo agentų atveju tai reiškia, kad rizikos valdymas negali būti atidėtas iki pirmo incidento. (nist.gov)

Naudinga vidinė taisyklė yra:

Agentas gali siūlyti, paruošti, testuoti ir paaiškinti pakeitimą. Žmogaus organizacija išlieka atsakinga už sprendimą, kas patenka į produkciją.

Ši taisyklė gali tapti lankstesnė pasiekus aukštesnį brandos lygį, tačiau tik tada, kai organizacija turi tvirtus įrodymus, ribotus leidimus, patikimą atšaukimą ir aiškiai apibrėžtas sustabdymo sąlygas.

Trys veikiantys organizaciniai modeliai

1. Bandomosios komandos

Bandomoji komanda yra maža komanda, kuri naudoja kodavimo agentus realiam darbui apibrėžtą laikotarpį. Tai nėra demonstracinis projektas, naudojantis dirbtines užduotis. Komanda turėtų dirbti su realia saugykla, realiomis problemomis ir realiais pristatymo apribojimais.

Stipri bandomoji komanda apima:

Keturi iki aštuonių kūrėjų su skirtinga patirtimi.
Inžinerijos vadovas.
Produkto ar verslo atstovas.
Saugumo ar kokybės atstovas.
Asmuo, susipažinęs su diegimu ir operacijomis.
Bent vienas asmuo, skeptiškai ar atsargiai vertinantis technologiją.

GitHub rekomenduoja, kad bandomieji projektai apimtų realų darbą, skirtingų įgūdžių lygių derinį ir įvairias komandas bei darbo eigas. Taip pat rekomenduojama apibrėžti sėkmės kriterijus, nustatyti biudžetą ir vykdyti bandomąjį projektą pakankamai ilgai, kad būtų surinkti prasmingi duomenys. Naudojimo pagrindu veikiančioms agentų funkcijoms „GitHub“ siūlo planuoti bent vieną visą atsiskaitymo ciklą, dažniausiai keturias–šešias savaites. (docs.github.com) [Source 6]

Geriausi naudojimo atvejai

Bandomosios komandos ypač gerai tinka:

Vienetinių ir integracinių testų rašymui.
Dokumentacijos atnaujinimui.
Smulkių klaidų taisymui.
Refaktorizavimui su gera testų aprėptimi.
Priklausomybių atnaujinimui.
Žurnalų, stebėjimo ir konfigūracijos patobulinimams.
Pakeitimų užklausų aprašymų rengimui.
Pasikartojančių problemų darbo pavertimui standartinėmis darbo eigomis.

Ko bandomasis projektas neturėtų daryti

Venkite pradėti nuo:

Autentifikavimo ir autorizavimo pakeitimų.
Mokėjimo logikos.
Negrįžtamų duomenų bazės migracijų.
Saugos požiūriu kritinės programinės įrangos.
Didelių tarpusavio paslaugų pertvarkymų.
Produkcijos prieigos neribotam agentui.
Individualaus darbuotojo produktyvumo vertinimo.

Bandomojo projekto užbaigimo kriterijai

Prieš pradedant bandomąjį projektą, apibrėžkite rašytinį „vykdyti“, „pristabdyti“ ir „nevykdyti“ sprendimą:

Vykdyti, jei:

Kokybė išlieka stabili arba pagerėja.
Saugumo pažeidimai materialiai nedidėja.
Peržiūrintieji gali suprasti pakeitimus.
Kūrėjai praneša, kad darbo eiga yra naudinga.
Agento išlaidos neviršija patvirtintos ribos.
Komanda gali sustabdyti arba atšaukti agento veiklą.

Pristabdyti, jei:

Pakeitimų užklausų peržiūros laikas smarkiai padidėja.
Agentas nuolat daro tos pačios klasės klaidas.
Botų sukurtas darbas užgožia prižiūrėtojus.
Kūrėjai jaučia spaudimą naudoti įrankį be mokymų.
Organizacija negali paaiškinti, ką agentas pakeitė.

Nevykdyti, jei:

Agentas apeina reikiamus patvirtinimus.
Jautrūs duomenys atskleidžiami.
Įvedami kritiniai pažeidžiamumai.
Agento negalima patikimai suvaldyti.
Verslo atvejis priklauso tik nuo optimistinių nuomonių, o ne nuo pamatuotų rezultatų.

2. Kompetencijos centro modelis

Kompetencijos centras teikia bendrus standartus, mokymus, įrankius, vertinimą ir palaikymą. Jis neturėtų tapti centriniu komanda, kuri tvirtina kiekvieną eksperimentą ar rašo kiekvieną agento darbo eigą.

Dabartinės „Microsoft“ agentų diegimo gairės aprašo veiksmingą Kompetencijos centrą kaip mažą, tarpfunkcinę grupę, teikiančią įgalinimą, standartus, valdymą ir mastelį. Rekomenduojama pereiti nuo aktyvios centralizuotos komandos ankstyvojoje brandos stadijoje prie lengvesnės ekosistemos ir bendruomenės vaidmens, kai vietinės komandos tampa pajėgios. (learn.microsoft.com) [Source 4]

Kodavimo agentų Kompetencijos centras galėtų apimti:

Inžinerijos produktyvumo vadovas.
Saugumo inžinierius.
Platformos ar kūrėjo patirties inžinierius.
Programinės įrangos kokybės atstovas.
Pokyčių valdymo ar mokymosi specialistas.
Produkto ar verslo atstovas.
Prireikus, teisės, privatumo ar atitikties patarėjas.

Kompetencijos centro atsakomybės

Kompetencijos centras turėtų būti atsakingas už:

Patvirtintus ir draudžiamus naudojimo atvejus.
Agentų užduočių rizikos klasifikavimą.
Standartines saugyklos instrukcijas.
Pakeitimų užklausų ir šakų apsaugos politiką.
Testavimo ir skenavimo reikalavimus.
Agento tapatybės ir prieigos modelius.
Mokymo medžiagą.
Vertinimo duomenų rinkinius ir testavimo saugyklas.
Išlaidų kontrolę.
Audito ir incidentų procedūras.
Daugkartinio naudojimo nurodymų, šablonų ir darbo eigų biblioteką.
Praktikų bendruomenę ir čempionų tinklą.

Jis neturėtų būti atsakingas už kiekvieną vietinį įgyvendinimo sprendimą. Jo tikslas yra padaryti saugų elgesį lengvą, pakartojamą ir matomą.

3. Federacinis valdymas

Federacinis valdymas sujungia centrinę bazę su vietinės komandos nuosavybe.

Centrinė organizacija nustato minimalius reikalavimus:

Jokių tiesioginių sujungimų į apsaugotas šakas.
Reikalaujamos pakeitimų užklausos.
Reikalingi testai ir saugumo patikrinimai.
Žmogaus arba kodo savininko patvirtinimas jautrioms sritims.
Mažiausios privilegijos prieiga.
Žurnalų įrašymas ir priskyrimas.
Apibrėžtos atšaukimo procedūros.
Patvirtinti modeliai, įrankiai ir duomenų tvarkymo taisyklės.

Vietinės komandos sprendžia:

Kurias užduotis verta automatizuoti.
Kaip turėtų būti rašomos saugyklos instrukcijos.
Kokie domenui specifiniai testai yra reikalingi.
Kurie inžinieriai veikia kaip vietiniai čempionai.
Kaip įrankis integruojamas į komandos planavimo ir peržiūros procesą.

„Microsoft“ aprašo panašų platformos atsakomybių ir darbo krūvio atsakomybių atskyrimą: platformos komanda teikia saugų pagrindą ir valdymą, o darbo krūvio komandos yra atsakingos už domenui specifinę vertę ir gyvavimo ciklo sprendimus. (learn.microsoft.com) [Source 5]

Šis modelis dažniausiai yra geriausia ilgalaikė struktūra didelėms organizacijoms, nes jis padeda išvengti dviejų dažnų nesėkmių:

Centralizuota kliūtis: Kiekvienas eksperimentas laukia vieno komiteto.
Nevaldomas plitimas: Kiekviena komanda išranda savo įrankius, leidimus, peržiūros taisykles ir duomenų praktiką.

Rekomenduojama eiga

Daugeliui organizacijų stipriausia seka yra:

Pradėkite nuo vienos ar dviejų bandomųjų komandų.
Iš žmonių, dalyvavusių tuose bandomuosiuose projektuose, suformuokite nedidelį Kompetencijos centrą.
Pereikite prie federacinio valdymo, kai daugiau komandų priima darbo eigą.
Išlaikykite centrinę kontrolę virš tapatybės, saugumo, vertinimo ir produkcijos prieigos.
Išlaikykite vietinę kontrolę virš domenų naudojimo atvejų ir kasdienių praktikų.

Pokyčių valdymas: pasitikėjimo kūrimas, nesukeliant pasipriešinimo

Pradėkite nuo pasitikėjimo sutarties

Kūrėjų nepasitenkinimas dažnai kyla dėl netikrumo, o ne dėl pasipriešinimo technologijai. Žmonės nori žinoti, ar įrankis bus naudojamas jiems padėti, juos stebėti, pakeisti ar vertinti.

„Google“ tyrimai apie kūrėjų pasitikėjimą rekomenduoja penkias praktines strategijas:

Paskelbti aiškią priimtino naudojimo politiką.
Stiprinti kodo peržiūrą ir automatizuotą testavimą.
Suteikti kūrėjams galimybių susipažinti.
Skatinti naudojimą, neprievartaujant.
Paaiškinti, kaip kūrėjų vaidmenys gali evoliucionuoti, peržengiant pasikartojantį darbą. (dora.dev) [Source 3]

Praktinėje pasitikėjimo sutartyje turėtų būti nurodyta:

Tikslas: pagerinti pristatymo kokybę, sumažinti pasikartojantį darbą arba padidinti mokymosi gebėjimus.
Kas leidžiama: saugių ir naudingų užduočių pavyzdžiai.
Kas draudžiama: jautrių duomenų tvarkymas, neribota prieiga prie produkcijos ir neperžiūrėti sujungimai.
Kas yra atsakingas: asmuo ir komanda, atsakinga už pakeitimą, išlieka atsakinga, net jei jį parašė agentas.
Kaip naudojama telemetrija: Diegimo duomenys turėtų pagerinti įgalinimą, o ne tapti supaprastinta darbuotojų reitingavimo sistema.
Kas neįvyks: Jokių paslėptų diegimų, jokių automatinių pakeitimų pažadų ir jokių individualių kvotų agento naudojimui.
Kaip žmonės gali nesutikti: Matomas kanalas problemoms pranešti arba prašyti sustabdymo.

Mokykite žmones pagal atsakomybę

Mokymai neturėtų būti viena bendra dviejų valandų demonstracija. Jie turėtų būti paremti vaidmenimis.

Ne koduotojams ir produktų komandoms

Mokykite žmones, kaip:

Rašyti aiškias problemas.
Apibūdinti norimą elgesį paprasta kalba.
Apibrėžti priėmimo kriterijus.
Nustatyti jautrius ar didelės rizikos reikalavimus.
Peržiūrėti demonstraciją ar testo rezultatą.
Paprašyti agento paaiškinti pakeitimą, nereikalaujant perskaityti kiekvienos kodo eilutės.

Tai daro kodavimo agentus naudingais žmonėms, kurie supranta verslo problemą, bet nerašo programinės įrangos.

Kūrėjams

Mokykite:

Kaip suteikti agentui naudingą kontekstą.
Kaip paprašyti plano prieš įgyvendinimą.
Kaip patikrinti skirtumą (diff).
Kaip patikrinti testus, o ne pasitikėti agento santrauka.
Kaip patikrinti priklausomybes, paslaptis, leidimus ir klaidų tvarkymą.
Kaip atpažinti nurodymų injekciją ir nepatikimą saugyklos turinį.
Kaip sustabdyti agentą, kuris cikliškai kartojasi arba atlieka nesusijusius pakeitimus.

„Google“ tyrimai parodė, kad pasitikėjimas didėja, kai kūrėjai susipažįsta su įrankiu, ypač kalbomis ir aplinkomis, kurias jie jau supranta. (dora.dev) [Source 3]

Peržiūrintiesiems

Mokykite peržiūrinčiuosius sutelkti dėmesį į:

Ar pakeitimas išsprendžia nurodytą problemą.
Ar testai apima svarbų elgesį.
Ar pakeitimas sukelia saugumo ar privatumo riziką.
Ar dizainas atitinka esamą architektūrą.
Ar agentas pakeitė daugiau nei būtina.
Ar pakeitimų užklausa yra pakankamai maža, kad ją būtų galima patikimai peržiūrėti.

Inžinerijos vadovams

Mokykite vadovus matuoti:

Pristatymo kokybę.
Peržiūros krūvį.
Perdirbimą.
Vykdymo laiką.
Kūrėjo pasitikėjimą.
Incidentų dažnumą.
Priežiūros atsilikimą.
Klientų rezultatus.

Nenaudokite kodo eilučių skaičiaus kaip pagrindinio produktyvumo tikslo. GitHub apibūdina kodo eilučių metriką kaip orientacinę ir rekomenduoja kartu atsižvelgti į diegimą, priėmimą, pakeitimų užklausos gyvavimo ciklo matavimus ir kokybinį grįžtamąjį ryšį. (docs.github.com)

Saugumo ir operacijų komandoms

Mokykite:

Agento tapatybės ir prieigos kontrolę.
Įrankių leidimų sąrašus.
Nurodymų injekcijos rizikas.
Paslapčių valdymą.
Audito žurnalus.
Kanarinių diegimų.
Avarinių išjungimų.
Atšaukimo ir incidentų reagavimo.

Naudokite čempionus, nekuriant neapmokamų palaikymo vaidmenų

Čempionas yra patikimas komandos narys, kuris eksperimentuoja su įrankiu, dalijasi praktinėmis gairėmis, padeda kolegoms ir teikia grįžtamąjį ryšį Kompetencijos centrui.

„Microsoft“ diegimo gairės rekomenduoja suteikti čempionams mokymus, pripažinimą, prieigą prie ekspertų ir teisę dalyvauti formuojant standartus. Čempionai neturėtų tapti tiesiog neapmokamu pagalbos centru. Jų laikas ir atsakomybės turėtų būti suderintos su vadovais. (learn.microsoft.com)

Naudinga čempionų programa apima:

Mėnesinius bendruomenės susitikimus.
Bendrą diskusijų kanalą.
Konsultacijų valandas.
Trumpas demonstracijas, naudojant realų darbą.
Sėkmingų ir nesėkmingų pavyzdžių biblioteką.
Pripažinimą už mokymą ir grįžtamąjį ryšį.
Aiškų eskalavimo kelią saugumo ir platformos komandoms.

Bendravimas etapais

Praktinė komunikacijos seka yra:

Prieš bandomąjį projektą

Paaiškinkite sprendžiamą problemą.
Nurodykite, kas patenka į apimtį ir kas ne.
Paskelbkite pasitikėjimo sutartį.
Paaiškinkite, kaip bus matuojama sėkmė.
Pakvieskite skeptiškų klausimų.

Bandomojo projekto metu

Dalinkitės savaitine pažanga.
Skelbkite nesėkmes ir pergales.
Praneškite apie peržiūros krūvį, kokybės išvadas, išlaidas ir kūrėjų nuotaikas.
Koreguokite darbo eigą pagal įrodymus.

Po bandomojo projekto

Paskelbkite sprendimą: plėsti, sustabdyti ar nutraukti.
Paaiškinkite, kas pasikeitė procese.
Pasidalinkite daugkartinio naudojimo praktikomis.
Nurodykite, kas išlieka žmogaus kontroliuojama.
Suteikite kūrėjams aiškią kitą galimybę dalyvauti.

Naudinga žinutė yra:

Kodavimo agentai gali rengti ir testuoti pakeitimus, tačiau žmonės išlieka atsakingi už tikslą, peržiūrą, riziką ir produkcijos rezultatus. Autonomiją plėsime tik tada, kai įrodymai parodys, kad kokybė, saugumas ir kūrėjų patirtis išlieka sveika.

Praktinis kodavimo agentų brandos modelis

Brandumas turėtų būti grindžiamas įrodymais ir kontrole, o ne įsigytų licencijų skaičiumi.

Etapas	Galimybė	Žmogaus vaidmuo	Reikalingi valdikliai
0 etapas: Kontroliuojamas tyrimas	Smėlio dėžės eksperimentai, dokumentacija, testų generavimas	Žmogus atlieka visus reikšmingus kodo pakeitimus	Jokių jautrių duomenų, izoliuotos saugyklos, pagrindinė politika
1 etapas: Asistuojamas kodavimas	Pasiūlymai, paaiškinimai, kodo užbaigimas, testų rengimas	Žmogus priima arba atmeta kiekvieną reikšmingą pasiūlymą	Kūrėjo peržiūra, saugių duomenų taisyklės, įprastas testavimas
2 etapas: Agento asistuojami pakeitimai	Agentas sukuria planą, redaguoja šaką ir vykdo patikrinimus	Žmogus patvirtina planą ir peržiūri visą skirtumą	Šakos apsauga, riboti įrankiai, saugyklos instrukcijos
3 etapas: Pusiau autonominės pakeitimų užklausos	Agentas savarankiškai įgyvendina gerai apibrėžtą problemą ir atidaro pakeitimų užklausą	Žmogus peržiūri ketinimą, dizainą, testus ir saugumą prieš sujungimą	Reikalingi patvirtinimai, kodo savininkai, automatizuoti patikrinimai, audito žurnalai
4 etapas: Nuolatinės priežiūros botai	Agentas veikia pagal tvarkaraštį arba įvykį, kad atnaujintų priklausomybes, dokumentaciją, testus ar pasikartojančią konfigūraciją	Žmonės rūšiuoja ir patvirtina ribotus pakeitimus	Siauras užduoties apimtis, įrankių leidimų sąrašai, biudžeto ribos, eilių ribos, sustabdymo mygtukas
5 etapas: Ribotas autonominis taisymas	Agentas gali imtis iš anksto apibrėžtų korekcinių veiksmų griežtai kontroliuojamose situacijose	Žmonės nustato politiką, stebi rezultatus ir tvarko naujus atvejus	Sauso paleidimo režimas, laipsniškas autorizavimas, grandinės pertraukikliai, kanarinis diegimas, automatinis atšaukimas

5 etapas turėtų būti traktuojamas kaip išimtis, o ne numanomas tikslas. „Google“ svetainės patikimumo inžinerijos (Site Reliability Engineering) gairės aprašo laipsnišką autonomiją: sistemos pereina nuo asistuojamos analizės prie žmogaus patvirtinto veiksmo, o po to prie riboto autonominio veiksmo tik tada, kai yra tvirtesni įrodymai ir kontrolė. Jis pabrėžia mažiausią privilegiją, pertrūkimą, sauso paleidimo palaikymą, rizikos vertinimą ir nuolatinį vertinimą. (goo.gle) [Source 9]

Kriterijai, pagal kuriuos pereinama tarp etapų

Komanda turėtų pereiti į kitą etapą tik tada, kai gali parodyti:

Stabilų ar gerėjantį defektų rodiklį.
Nepriimtinai nepadidėjusių saugumo pažeidimų.
Valdomą peržiūros krūvį.
Aiškų agento priskyrimą.
Patikimus testavimo ir diegimo signalus.
Išbandytą atšaukimą.
Kūrėjus, kurie supranta darbo eigą ir ja pasitiki.
Dokumentuotą užduočių sąrašą, kurių agentas neturi atlikti.

Nuolatinės priežiūros botai nusipelno ypatingo atsargumo

Priežiūros darbai atrodo mažai rizikingi, tačiau jie gali sukurti didelius pakeitimų kiekius. Pavyzdžiai:

Priklausomybių atnaujinimai.
Dokumentacijos sinchronizavimas.
Testų taisymas.
Statinės analizės taisymas.
Konfigūracijos atnaujinimai.
Problemų žymėjimas ir rūšiavimas.
Pasenusio kodo pašalinimas.

Esami įrankiai, tokie kaip Dependabot, demonstruoja naudingą modelį: automatizuotos sistemos teikia pakeitimų užklausas, tačiau testai ir priėmimo procesai vis tiek turėtų būti vykdomi prieš sujungimą. Automatinis sujungimas turėtų būti apribotas iki aiškiai apibrėžtų, mažos rizikos atvejų su privalomais būsenos patikrinimais. (docs.github.com)

Kalbos modeliais pagrįstiems priežiūros botams pridėkite:

Maksimalus atidarytų botų pakeitimų užklausų skaičius.
Maksimalus pakartotinių bandymų skaičius vienai užduočiai.
Maksimalus dienos biudžetas.
Automatinis pasenusio ar dubliuojančio darbo uždarymas.
Reikalingas žmogus-savininkas.
Taisyklė, kad botas neturi modifikuoti savo paties leidimų ar darbo eigos apibrėžimų.

Autonominio kodavimo diegimo rizikos registras

Rizikos registras turėtų būti sukurtas prieš bandomąjį projektą ir peržiūrimas priimant kiekvieną plėtros sprendimą.

Rizika	Ankstyvasis įspėjamasis ženklas	Prevencinės priemonės	Atsakymo savininkas
Pažeidžiamas kodas	Saugumo pažeidimai agento sukurtuose pakeitimuose arba pasikartojantys nesaugūs modeliai	Automatizuotas testavimas, kodo skenavimas, priklausomybių patikrinimas, paslapčių skenavimas, saugumo peržiūra	Saugumas ir inžinerija
Nurodymų injekcija	Problema, komentaras ar saugyklos failas nurodo agentui ignoruoti apsaugos priemones arba atskleisti duomenis	Traukite saugyklos tekstą kaip nepatikimą įvestį, ribokite įrankius, izoliuokite kredencialus, peržiūrėkite agento instrukcijas	Saugumas
Jautrių duomenų atskleidimas	Paslaptys, klientų informacija ar vidiniai kredencialai pasirodo nurodymuose arba žurnaluose	Duomenų klasifikavimas, patvirtintos aplinkos, paslapčių valdymas, prieigos minimizavimas	Privatumas ir saugumas
Neautorizuotas sujungimas	Agento sukurtas pakeitimas apeina patvirtinimą arba šakos apsaugą	Apsaugotos šakos, reikalingos peržiūros, kodo savininkai, užblokuoti priverstiniai įkėlimai, audito žurnalai	Saugyklos savininkas
Architektūros nuokrypis	Daugelis lokaliai teisingų pakeitimų daro sistemą nenuoseklią	Dizaino peržiūra didelio poveikio pakeitimams, saugyklos instrukcijos, nurodyti domenų savininkai	Architektūros savininkas
Klaidingas pasitikėjimas testais	Testai praeina, bet produkcijos elgesys arba vartotojo patirtis pablogėja	Nepriklausoma peržiūra, sutarties testai, integracijos testai, kanarinių versijų išleidimas, produkcijos stebėjimas	Kokybė ir operacijos
Peržiūros perkrova	Botų pakeitimų užklausos kaupiasi greičiau, nei žmonės gali jas įvertinti	Siauros užduočių apimtys, eilių ribos, grupavimas, prioritetų taisyklės, automatinis pauzė	Inžinerijos vadovas
Nevaldomos išlaidos	Žetonų, skaičiavimo ar darbo eigos naudojimas viršija prognozes	Biudžetai vienam agentui, naudojimo įspėjimai, griežti sustojimai, patvirtinti modeliai, riboti tvarkaraščiai	Platforma ir finansai
Įgūdžių erozija	Kūrėjai negali paaiškinti pakeitimų ar spręsti problemų be agento	Reikalauti paaiškinimo, porinio mokymosi, rotacijos per rankinį darbą, mokymų	Inžinerijos vadovybė
Vaidmenų nerimas ir nepasitenkinimas	Tylus nenaudojimas, pasipriešinimas, gandai ar staigus moralės praradimas	Skaidrus bendravimas, savanoriškas ankstyvas naudojimas, mokymų laikas, vaidmenų pertvarkymas, jokių supaprastintų kvotų	Pokyčių valdymas
Modelio ar įrankio nuokrypis	Anksčiau patikima užduotis pradeda duoti skirtingus rezultatus	Versijų vertinimai, pakopiniai atnaujinimai, bandomasis naujų modelių diegimas atskirai, konfigūracijos atšaukimas	Kompetencijos centras
Agento ciklas ar nenumatytas veiksmas	Kartotiniai redagavimai, per didelis įrankių naudojimas arba nesusiję failų pakeitimai	Maksimalus veikimo laikas, įrankių leidimų sąrašai, grandinės pertraukikliai, sauso paleidimo režimas, žmogaus įsikišimas	Platformos savininkas

GitHub’s current documentation identifies several of these risks directly, including unvalidated code, sensitive information access, prompt injection, loss of administrative visibility, and automations operating without a person initiating each task. Its documented mitigations include branch restrictions, required human review, workflow approval, session logs, and limited tools. (docs.github.com) [Source 8]

The Open Worldwide Application Security Project’s 2026 guidance on agentic security and governance also reflects the need for threat modeling and governance specifically designed for systems that can act, not merely generate text. (genai.owasp.org) [Source 11]

Atšaukimo gairės

Atšaukimo gairės turėtų būti parašytos paprasta kalba ir išbandytos prieš leidžiant autonominiam agentui kurti pakeitimus, skirtus produkcijai.

Gairės 1: Agento suvaldymas

Naudokite tai, kai agentas elgiasi netikėtai, nutekina informaciją, sukuria per daug darbo arba pažeidžia savo užduoties ribas.

Išjunkite paveiktą agentą, automatizavimą arba modelio politiką.
Sustabdykite suplanuotus ir įvykiais inicijuotus paleidimus.
Atšaukite arba sustabdykite agento kredencialus.
Neleiskite kurti naujų pakeitimų užklausų.
Išsaugokite sesijos žurnalus, nurodymus, skirtumus ir audito įrašus.
Nustatykite visas saugyklas ir šakas, kurias palietė agentas.
Praneškite paveiktiems prižiūrėtojams ir saugumo personalui.
Atidarykite incidento peržiūrą.
Neįjunkite agento iš naujo, kol nebus suprastas gedimo režimas ir kontrolės spraga.

GitHub teikia valdiklius automatizavimui išjungti ir agentų sesijoms peržiūrėti. Jis taip pat registruoja agentų sukurtus įrašus ir audito įvykius, o tai palaiko tokį suvaldymo procesą. (docs.github.com) [Source 12]

Gairės 2: Saugumo neatitinkančio kodo pakeitimo atšaukimas

Naudokite tai, kai agento kodas jau sujungtas.

Paskelbkite incidentą ir nustatykite paskutinę žinomą gerą versiją.
Sustabdykite tolesnį diegimą.
Atšaukite pakeitimų užklausą arba įdiekite ankstesnę žinomą gerą versiją.
Naudokite kanarinių diegimą arba ribotą diegimą, jei pats atšaukimas yra rizikingas.
Patikrinkite paslaugų lygio rodiklius, klaidų dažnį, saugumo signalus ir klientų poveikį.
Išsaugokite originalų pakeitimą tyrimui.
Nustatykite, ar problema kilo dėl agento, užduoties aprašymo, trūkstamų testų, peržiūros gedimo ar diegimo proceso.
Pridėkite regresijos testą arba apsaugos priemonę prieš atidarant užduotį iš naujo.

GitHub pakeitimų užklausų darbo eiga gali sukurti naują pakeitimų užklausą, kuri atšaukia sujungtą pakeitimų užklausą. Produkcijos sistemoms kanarinis diegimas yra papildoma kontrolės priemonė, nes ji apriboja vartotojų, kurie susiduria su pakeitimu, skaičių, kol pakeitimas nebus toliau reklamuojamas. (docs.github.com)

Gairės 3: Rizikingo diegimo sustabdymas

Produkcijai skirtiems pakeitimams:

Naudokite pakopinį diegimą, o ne tiesioginį pasaulinį išleidimą.
Apibrėžkite automatines sustabdymo sąlygas prieš diegimą.
Stebėkite klaidas, delsą, prieinamumą, saugumo įspėjimus ir verslo rezultatus.
Palaikykite avarinio sustabdymo mechanizmą.
Grįžkite prie anksčiau patvirtinto išleidimo, kai viršijamos ribos.

Kibernetinio saugumo ir infrastruktūros saugumo agentūra (Cybersecurity and Infrastructure Security Agency) rekomenduoja kanarinius diegimus, kontroliuojamą diegimą, stebėseną plėtros metu ir avarinio sustabdymo mechanizmą. „Google“ svetainės patikimumo inžinerijos gairės taip pat rekomenduoja kanarinį diegimą kaip būdą atskleisti tik nedidelę eismo dalį, patvirtinant pakeitimą. (cisa.gov) [Source 10]

Gairės 4: Diegimo etapo atšaukimas

Kartais kodas yra saugus, bet veiklos modelis nėra paruoštas. Jei peržiūros krūvis, kūrėjų nusivylimas ar priežiūros triukšmas tampa pernelyg didelis:

Sustabdykite plėtrą.
Grąžinkite komandas į ankstesnį brandos etapą.
Pirmiausia išjunkite didžiausios autonomijos funkcijas.
Palikite mažos rizikos asistuojamą kodavimą prieinamą, jei jis išlieka naudingas.
Ištaisykite dokumentaciją, testus, leidimus ar mokymus.
Iš naujo paleiskite bandomąjį projektą su siauresnėmis užduočių ribomis.

Atšaukimas nėra programos nesėkmė. Tai ženklas, kad organizacija naudoja kontroliuojamą eksperimentavimą, o ne traktuoja diegimą kaip negrįžtamą.

Devyniasdešimties dienų diegimo planas

1–10 dienos: Nustatyti pradinę padėtį

Sukurkite vieno puslapio chartiją, kurioje būtų:

Verslo problema.
Bandomoji saugykla ar paslauga.
Įtrauktos užduotys.
Neįtrauktos užduotys.
Komandos nariai.
Agento leidimai.
Būtinos peržiūros.
Būtini testai ir skenavimai.
Išlaidų lubos.
Sėkmės metrika.
Sustabdymo sąlygos.
Atšaukimo savininkas.

Prieš įjungiant agentą, išmatuokite pradinę padėtį:

Pakeitimų užklausos ciklo laikas.
Peržiūros laikas.
Perdirbimas.
Defektų rodiklis.
Saugumo pažeidimai.
Diegimo dažnumas.
Pakeitimų nesėkmių rodiklis.
Kūrėjo pasitikėjimas.
Priežiūros atsilikimas.

11–45 dienos: Vykdyti bandomąjį projektą

Naudokite realų darbą. Kiekvieną savaitę atlikite trumpą peržiūrą, apimančią:

Ką agentas padarė.
Ką žmonės turėjo ištaisyti.
Kurios užduotys buvo tinkamos.
Kurios užduotys buvo netikėtai sunkios.
Ar padidėjo peržiūros pastangos.
Ar komanda supranta pakeitimus.
Ar išlaidos atitinka lūkesčius.

Į komandos retrospektyvą pridėkite vieną klausimą:

Kur kodavimo agentas šią savaitę sumažino pastangas, o kur sukūrė daugiau darbo?

GitHub rekomenduoja derinti naudojimo duomenis su apklausomis, retrospektyvomis, palaikymo tendencijomis ir kitais kokybiniais atsiliepimais, o ne pasikliauti vienu diegimo skaičiumi. (docs.github.com)

46–75 dienos: Sukurti veiklos modelį

Naudokite bandomojo projekto dalyvius, kad sukurtumėte pradinį Kompetencijos centrą.

Paskelbti:

Priimtino naudojimo politika.
Rizikos klasifikavimo gairės.
Saugyklos instrukcijų šablonas.
Pakeitimų užklausos kontrolinis sąrašas.
Agento prieigos standartas.
Saugumo peržiūros kontrolinis sąrašas.
Mokymų kelias.
Atšaukimo gairės.
Patvirtintos metrikos.
Čempionų programa.

76–90 dienos: Plėsti atsargiai

Pridėkite komandas bangomis, ne visas iš karto.

Kiekvienai bangai:

Patvirtinkite, kad saugykloje yra reikalingi testai ir nuosavybė.
Patvirtinkite šakų apsaugos ir kodo savininko taisykles.
Apmokykite komandą.
Paskirkite čempioną.
Apibrėžkite leistinas užduočių kategorijas.
Nustatykite biudžetą ir peržiūros pajėgumus.
Išmatuokite kokybę ir kūrėjo patirtį.
Nuspręskite, ar tęsti, sustabdyti, ar susiaurinti apimtį.

Pirmas kitas žingsnis

Geriausias pirmas veiksmas nėra daugiau licencijų pirkimas. Tai yra šešiasdešimties minučių autonomijos dizaino seminaro su viena inžinerijos komanda, vienu produkto atstovu, vienu saugumo ar kokybės atstovu ir vienu platformos atstovu suplanavimas.

Seminaro metu pasirinkite:

Vieną saugyklą.
Vieną mažos rizikos užduoties kategoriją.
Vieną žmogaus patvirtinimo taisyklę.
Vieną išmatuojamą rezultatą.
Vieną sustabdymo sąlygą.
Vieną atšaukimo savininką.

Tinkama pirmoji užduotis galėtų būti:

„Kiekvieną savaitę tikrinkite priklausomybės įspėjimus ir atidarykite pakeitimų užklausą patvirtintiems pataisymo lygio atnaujinimams. Nekeiskite programos logikos, diegimo konfigūracijos, autentifikavimo ar darbo eigos leidimų. Paleiskite visą testų rinkinį ir saugumo patikrinimus. Sustabdykite po trijų nesėkmingų bandymų arba kai yra penkios atviros priežiūros pakeitimų užklausos.“

Ši maža darbo eiga moko organizaciją, kaip apibrėžti apimtį, leidimus, įrodymus, peržiūrą ir atkūrimą. Šios pamokos yra vertingesnės už efektingą demonstraciją.

Išvada

Saugus autonominių kodavimo agentų diegimas visų pirma yra organizacijos dizaino problema.

Stipriausias modelis paprastai yra:

Bandomosios komandos mokytis iš realaus darbo.
Kompetencijos centras, teikiantis bendrus standartus, mokymus, vertinimus ir apsaugos priemones.
Federacinis valdymas, leidžiantis vietinėms komandoms greitai veikti saugioje centrinėje riboje.
Brandos kelias, kuris progresuoja nuo asistuojamo kodavimo iki agento sukurtų pakeitimų užklausų ir tik tada iki nuolatinių priežiūros botų.
Rizikos registras ir atšaukimo gairės, kurie parašomi prieš išplečiant autonomiją.
Pokyčių valdymo programa, sukurta remiantis pasitikėjimu, skaidrumu, savanorišku mokymusi, vaidmenų aiškumu ir išmatuojamais rezultatais.

Tikslas nėra pašalinti žmones iš programinės įrangos kūrimo. Tikslas yra nukreipti žmogaus dėmesį į architektūrą, produkto vertinimą, saugumą, patikimumą, vartotojo patirtį ir geresnių sistemų kūrimą.

Autonomija turi būti užsitarnaujama įrodymais. Kai organizacija gali paaiškinti, ką jos agentams leidžiama daryti, įrodyti, kad jų darbas yra tikrinamas, ir juos sustabdyti be dramos, kodavimo agentai tampa jėgos daugikliu, o ne chaoso šaltiniu.