AI kodēšanas rīki un darbplūsmas integrācija

Ieguvumi:

• Iespēja kartēt redaktora pabeigšanu, tērzēšanas palīgu, CLI aģentu un CI automatizācijas kategorijas ar uzdevumiem
• Spēja pielāgot autonomijas līmeni atbilstoši riskam un CLI aģentiem piemērot disciplīnu “vispirms plāns”.
• Spēja pārveidot AI izmantošanu par komandas sistēmu, kuras pamatā ir apstiprināts rīks, verifikācijas vārti, caurspīdīgums un atbildība

Līdz šim esam iemācījušies izmantot AI atsevišķos uzdevumos (kodēšana, pārskatīšana, testēšana, atkļūdošana). Šajā pēdējā vienībā mēs apkopojām detaļas: dažādu AI kodēšanas rīku iepazīšana, īstā rīka pielāgošana pareizajam darbam un droša iegulšana ikdienas izstrādes plūsmā — no redaktora līdz versiju kontrolei, no CI/CD konveijera līdz komandas pārvaldībai. Mērķis ir pārvērst netīro ieradumu “ik pa laikam jautāt AI” konsekventā un pārbaudāmā darba sistēmā.

Mēs aptveram transportlīdzekļu tipus ar neitrālām kategorijām (konkrēti produktu nosaukumi ātri mainās; svarīgi ir tas, ko dara kategorija). Katrai kategorijai ir “sweet spot” un riska profils; Meistarība ir zināt, cik daudz autonomijas piešķirt kādam uzdevumam.

AI kodēšanas rīku kategorijas

1. Redaktora pabeigšana. Spraudņi, kas iesaka līnijas/blokus, kad rakstāt savā IDE (izstrādes vidē, kurā rakstāt kodu). Sweet spot: plūsmas ātrums, standarta kods. Risks: šaurs konteksts, ieteikuma pieņemšana bez domāšanas.

2. Tērzēšanas/sānu paneļa palīgs. IDE iegultais tērzēšanas interfeiss ar redzamību jūsu kodu bāzes daļā. Sweet spot: apraksts, faktors, testēšana, kļūdu analīze. Risks: tikai jūsu sniegtajā kontekstā, nepieciešama pārbaude.

3. CLI aģenti (aģentu rīki). Rīki, kas darbojas no komandrindas, var lasīt un modificēt vairākus failus, palaist komandas un izpildīt daudzpakāpju uzdevumus. Sweet spot: vairāku failu izmaiņas, atkārtoti uzdevumi, "pievienot šo īpašumu" tipa darbi. Risks: augsta autonomija = liela ietekme; Ja tas netiek atzīmēts, tas rada plašas un grūti pārbaudāmas izmaiņas.

4. Līnijas/automatizācijas integrācija. CI (nepārtrauktas integrācijas) robotprogrammatūras, kas automātiski pārskata komentārus par PR, iesaka testus vai veido izmaiņu žurnālus. Sweet spot: pirmais sietiņš bez noguruma, konsistence. Risks: troksnis, nepatiesa pārliecība.

Padoms: palielinoties autonomijai, jāpalielinās arī kontrolei. Tā kā redaktora pabeigšana ir neliela un tūlītēja, tā tiek viegli uzraudzīta; CLI aģenta vairāku failu modifikācijas ir jāpārbauda tāpat kā, ja ne rūpīgāk, nekā cilvēka PR.

Soli pa solim: AI iegulšana darbplūsmā

1. Kartējiet uzdevumu ar rīku. Neliels plūsmas papildinājums → pabeigšana; saprast/refaktorēt/pārbaudīt → tērzēt; vairāku failu, atkārtots darbs → CLI aģents; nepārtraukts pirmais filtrs → CI integrācija.
2. Izvēlieties autonomijas līmeni. Cik liela brīvība ir aģentam? Tikai lasāms ieteikums vai faila modifikācija + komandas izpilde? Pielāgojiet riskam.
3. Izkopt kontekstu. Pastāvīgi ieviest rīkā projekta noteikumus (stils, arhitektūra, "nedrīkst"); Izmantojiet projekta instrukciju failu, nevis skaidrojiet to atkal un atkal.
4. Saglabājiet verifikācijas vārtus. AI izmaiņas ir līdzīgas cilvēka izmaiņām: tās tiek apkopotas, testētas, pārskatītas un (ja tas ir svarīgi) ekspertu apstiprinājums. AI atvēršanas PR neapiet apstiprinājumu.
5. Izmēriet un noregulējiet. Skatieties, kas patiešām paātrina, kur palielinās korekcijas slogs; Izgrieziet lietojumus, kas nedarbojas.

Trīs mini futrāļi

1. gadījums — CLI aģents apstrādāja vairāku failu pārdēvēšanu. Viena komanda pārdēvēja koncepciju, kas sadalīta 60 failos. Viņi deva uzdevumu CLI aģentam, vispirms lūdza plānu, apstiprināja plānu, pēc tam veica izmaiņas un palaida visu testa komplektu. 3. aģents failā palaida garām malu lietu; Pārbaudes to noķēra, salaboja. Darbs, kas manuāli aizņēma aptuveni 3 stundas, tika paveikts 50 minūtēs ar uzraudzību.

2. gadījums — nekontrolēta autonomija radīja pretēju rezultātu. Cits izstrādātājs lika aģentam "uzlabot šo moduli" un izlaida to; Aģents modificēja 18 failus un pievienoja divas atkarības. Izmaiņas bija tik plašas, ka tās nevarēja pārskatīt un tās bija jāatsauc. Nodarbība: dodiet aģentiem šauru darbības jomu, skaidrus pieņemšanas kritērijus un disciplīnu, ka vispirms plāno-vēlāk dari.

3. gadījums — CI pārskatīšanas robots kļuva par pirmo filtru. Viena komanda izveidoja robotu, kas atstāj automātiskus AI pārskata komentārus par PR. Kad robotprogrammatūra konstatēja nulles pārbaudes izlaidumus un stila problēmas, recenzenti varēja veltīt savu laiku biznesa loģikai. Tomēr komanda skaidri norādīja, ka robots nesniedza “apstiprinājumu”: joprojām bija nepieciešams vismaz viens cilvēka apstiprinājums. Lai samazinātu troksni, viņi noregulēja laivu, atstājot tikai augstas/vidējas intensitātes troksni.

Četras kopējamas veidnes

CLI aģenta disciplīna "Plānot vispirms":

Uzdevums: {{clear, šaurs uzdevums}}Pieņemšanas kritēriji: {{izmērāms rezultāts}}Ierobežojums: strādājiet tikai ar {{šo direktoriju/failiem}}; pievienojot jaunu atkarību.Vispirms iesniedziet plānu BEZ IZMAIŅĀM: kuri faili, kas mainīsies, kādus testus palaist. Pagaidiet, kamēr es APSTIPRINĀšu plānu. Pēc tam lietojiet to soli pa solim, katrā solī veicot testus.

Projekta instrukciju fails (pastāvīgs rīku konteksts):

Pastāvīgi noteikumi AI rīkiem šajā projektā:- Valoda/versija: {{...}}. Stils: {{...}}.- Arhitektūras ierobežojums: {{piem. virziens starp slāņiem}}.- NEKAD: noslēpumu iegulšana, ražošanas datu izmantošana, {{aizliegtās bibliotēkas}}.- Katrai izmaiņai jābūt pārbaudāmai; Publiskā API paraksta maiņa BEZ jautāšanas. - Ja šaubāties, apstājieties un pajautājiet.

Uzdevumu rīka kartēšanas lēmums:

Es definēju šādu uzdevumu: {{uzdevums}}. Kādas klases rīkiem man tas jādara: (a) redaktora pabeigšana, (b) tērzēšanas palīgs, (c) CLI aģents, (d) CI automatizācija? Uzrakstiet savu pamatojumu, risku un ieteicamo autonomijas līmeni (tikai ieteikums / mainīt failu / palaist komanda).

CI pārskatīšanas robotu rīcības kodekss:

Atstājiet tikai AUGSTAS un VIDĒJAS smaguma konstatējumus kā komentārus PR pārskatā. Katrs atradums: kategorija, smaguma pakāpe, ieteiktā korekcija. Apkopojiet piezīmes stila izvēles līmenī atsevišķā kopsavilkuma komentārā. Jūs NEPIEKRIETAT; nepieciešams cilvēka apstiprinājums.

Vāja uzvedne / spēcīga uzvedne

Vāji: (CLI aģentam) "Padariet labāku maksājumu moduli."

Strong: (CLI aģentam) "Palaist tikai saskaņā ar src/payments/. Uzdevums: izvilkt rekursīvo validācijas loģiku no atmaksas() funkcijas vienā palīgā; uzvedība un paraksti nemainās. Vispirms uzrādiet plānu un gaidiet manu apstiprinājumu; pēc tam izpildiet un palaidiet testus/payments/ pakotni. Pievienojiet jaunu atkarību."

Spēcīgā versija sašaurina darbības jomu, nosaka pieņemšanas kritērijus un ierobežojumus un uzliek disciplīnu "vispirms plāns". Neskaidras prasības “darīt labāk” ir milzīgu un nekontrolējamu pārmaiņu galvenais iemesls.

transportlīdzekļa klase

Kas viņam padodas vislabāk

autonomija

pārbaudes svars

Redaktora pabeigšana

Neliels klipā ievietots papildinājums

zems

Gaisma (tūlītēja lasīšana)

tērzēšanas palīgs

Saprast, pārbaudīt, refaktorēt

vidējs

Vidēja (izejas verifikācija)

CLI aģents

Vairāku failu, rekursīvs

augsts

Smags (plāns + pilna atsauksme)

CI automatizācija

Nepārtraukts pirmais filtrs

vidējs

Vidēja (noteikums + cilvēka apstiprinājums)

Komandas pārvaldība: no individuālām prasmēm līdz koplietotai sistēmai

Laba AI izmantošana individuāli ir sākums; īstais briedums ir konsekventa sistēma komandas līmenī. Šī sistēma ir balstīta uz vairākiem pīlāriem: apstiprināto rīku saraksts (kurus rīkus var izmantot ar kādiem datiem — no 10. bloka), verifikācijas vārti (AI izmaiņas notiek caur tiem pašiem konstruēšanas/testēšanas/pārskatīšanas vārtiem — no 11. bloka), caurspīdīgums (norādījums, ka izmaiņas tiek darbinātas ar mākslīgo intelektu, nodrošina izsekojamību, ja nepieciešams), un atbildības skaidrība (persona, kas parakstās un ir atbildīga). Šī sistēma ierobežo risku, vienlaikus saglabājot ātrumu un nodrošina, ka jaunie komandas locekļi strādā ar tādu pašu disciplīnu.

Uzmanību! Jo augstāka ir rīka autonomija, jo īpaši CLI aģenti, kas var modificēt failus, palaist komandas, jo stingrāk ierobežo tā piekļuvi ražošanas videi, konfidenciāliem datiem un grūti atgriežamām darbībām. Saistiet destruktīvas komandas (pastāvīga dzēšana, izvietošana) ar cilvēka apstiprinājumu.

Biežas kļūdas

• Uzdevums-nozīmē nesaderība. Mēģina veikt vairāku failu darbu ar redaktora pabeigšanu vai nelielu pielikumu ar smago aģentu.
• Aģenta atbrīvošana. Aģenta uzdevumi, kas doti šaurā tvērumā un bez “pirmā plāna”, rada nepārbaudītas izmaiņas.
• AI verifikācijas vārtu atslābināšana. "AI paveica, ātri turpināsim" ir visbīstamākais izņēmums; Durvis visiem ir vienādas.
• Katru reizi konteksta ievadīšana manuāli. Projekta noteikumu neierakstīšana pastāvīgā instrukciju failā rada nekonsekvenci un dublēšanos.
• Kļūdains CI robota apstiprinājums cilvēka apstiprinājumam. Bots ir filtrs; Atbildīga cilvēka piekrišana ir obligāta.

Rezumējot

AI kodēšanas rīki iedalās četrās galvenajās kategorijās: redaktora pabeigšana, tērzēšanas palīgs, CLI aģenti un CI automatizācija. Meistarība ir uzdevuma saskaņošana ar pareizo rīku un pareizo autonomijas līmeni; Palielinoties autonomijai, palielinās arī kontrole. Piešķiriet rīkiem pastāvīgu projekta kontekstu, uzspiediet vairāku failu aģentiem disciplīnu “vispirms plāns” un nododiet AI izmaiņas caur tiem pašiem verifikācijas vārtiem, ko izmanto cilvēku izmaiņas. Individuāla prasme; Pārveidojiet to par komandas sistēmu, kuras pamatā ir apstiprināts rīku saraksts, verifikācijas vārti, caurspīdīgums un atbildības skaidrība. AI ir pilnīgs ātruma reizinātājs; Persona, kas paraksta un sniedz kontu, vienmēr ir kompetenta persona.

Lietojumprogrammas uzdevums

Uzskaitiet trīs reālus uzdevumus, ko veiksiet nākamnedēļ. Katram izmantojiet veidni “Uzdevuma un transportlīdzekļa saskaņošanas lēmums”, lai pamatotu, kuru transportlīdzekļa klasi un kādu autonomijas līmeni izvēlēsities. Pēc tam izpildiet šauru uzdevumu CLI aģentam (vai tērzēšanas asistentam) ar disciplīnu “vispirms plāns”: apstipriniet plānu, izpildiet to, palaidiet testus un pārskatiet izmaiņas kā cilvēku PR. Visbeidzot, izveidojiet savai komandai 5 punktu “AI lietošanas noteikumu” (apstiprināti rīki, datu noteikums, verifikācijas vārti, autonomijas ierobežojums, atbildība).

kontrolsaraksts

• [ ] Es varu atšķirt AI kodēšanas rīku kategorijas un katras no tām iecienītākās vietas.
• [ ] Es kartēju uzdevumu uz pareizo transportlīdzekļa klasi un atbilstošu autonomijas līmeni.
• [ ] Es piešķiru rīkiem pastāvīgu projekta kontekstu (instrukciju failu).
• [ ] CLI aģentiem piemēroju šauru darbības jomu un disciplīnu "vispirms plānoju".
• [ ] Es izlaižu AI izmaiņas caur tiem pašiem verifikācijas vārtiem, ko veic cilvēka izmaiņas.
• [ ] Es iestājos par apstiprinātu rīku, datu noteikumu, pārredzamības un atbildības sistēmu komandas līmenī.

Moduļa eksāmens

1. Ko patiesībā dara kodēšanas palīga pamatā esošais lielās valodas modelis, kad tas ražo kodu?

• A) Strukturāli prognozē visticamāko turpinājumu, pamatojoties uz doto kontekstu ✔
• B) garantē pareizu rezultātu, faktiski apkopojot un palaižot kodu
• C) Tā tiešraidē skenē kodu visā internetā un kopē visprecīzāko.
• D) Izprot koda loģiku kā cilvēks inženieris un saprot nodomu

Precizējums: LLM 'nesaprot' kodu kā cilvēks; Tas ģenerē visticamāko turpinājumu dotajam kontekstam, pamatojoties uz modeļiem, ko tā mācās no ļoti liela teksta un koda kopas. Tāpēc izvades kvalitāte ir tieši atkarīga no jūsu sniegtā konteksta un norādījumu kvalitātes, un katra izvade ir jāapstiprina.

2. Kā jūs to saucat, kad AI pārliecinoši izdomā neesošu funkciju vai bibliotēku, un kas ir vienīgais īstais pretlīdzeklis?

• A) To sauc par kompilācijas kļūdu; Pretlīdzeklis ir spēcīgāks aprīkojums
• B) To sauc par halucinācijām; Pretlīdzeklis ir pārbaudīt kodu un katru izmantoto API ✔
• C) To sauc par regresiju; Pretlīdzeklis ir modeļa restartēšana
• D) To sauc par konteksta pārplūdi; Pretlīdzeklis ir saīsināt uzvedni

Apraksts: To sauc par halucinācijām un izraisa vienu no dārgākajām programmatūras kļūdām. Vienīgais īstais pretlīdzeklis ir pārbaude: apstiprinājums, ka katra izmantotā funkcija, API un pakotne patiešām pastāv un ka kods darbojas. Modeļa pārliecinātais tonis neliecina par precizitāti.

3. Kura pieeja visvairāk uzlabo izvades kvalitāti un konsekvenci, ģenerējot kodu ar AI?

• A) Atbrīvojiet modeli, sakot "rakstiet šo man", nesniedzot nekādu kontekstu
• B) Uzrakstiet pēc iespējas garāko un smalkāko uzvedni
• C) Norādiet un sniedziet ievades/izvades līguma piemērus, malas gadījumus, versiju un stilu ✔
• D) ģenerētā koda apvienošana tieši, to neizlasot

Paskaidrojums: funkcijas ievades/izvades veidu (līgums), malu gadījumu, valodas/versijas un stila ierobežojumu noteikšana un modeļa piemēra noteikšana ļauj pāriet no prognozēšanas uz precizitāti. Bezkonteksta pieprasījumi “rakstiet man šo” rada kodu, kas katru reizi ir atšķirīgs un bieži apiet malas gadījumus.

4. Izpētot svešu kodu bāzi ar AI, funkcijas nosaukums var būt “validateAndSave”, bet AI īgvilkums var būt nepareizs. Kāda ir pareizā pieeja?

• A) Pilnīga uzticēšanās AI kopsavilkumam, jo nosaukums ir pats par sevi saprotams
• B) Funkcijas maiņa tieši, to neizlasot
• C) Izlemiet, tikai aplūkojot funkcijas nosaukumu
• D) Uztveriet mākslīgā intelekta aprakstu kā hipotēzi un pārbaudiet kritiskās prasības kodā rindu pa rindiņai ✔

Paskaidrojums: AI var aplūkot nosaukumu kodā un pateikt, kā tas izskatās, bet patiesībā loģika var būt citāda (vai pat pretēja). Tātad AI skaidrojums ir hipotēze; Kritiskās prasības, jo īpaši tās, kas saistītas ar drošību, autoritāti vai naudas plūsmu, ir vizuāli jāpārbauda attiecīgajās rindās.

5. Kāds ir lielākais apdraudējums, sakot: “AI izskatījās, tas ir skaidrs” AI koda pārskatīšanā?

• A) AI var radīt viltus negatīvus rezultātus; Īstas pieļautas kļūdas rada nepatiesu pārliecību ✔
• B) AI pārskatīšana ir pārāk lēna, tāpēc tiek tērēts laiks
• C) Komanda nesaprot, jo AI komentē tikai angļu valodā
• D) PR nesaplūst, jo AI vienmēr pārmērīgi interpretē

Paskaidrojums: AI rada gan viltus pozitīvus (apzīmējot problēmu tur, kur tās nav), gan viltus negatīvus (trūkst īstās kļūdas). Viltus negatīvi ir klusi; Visbīstamākās kļūdas ir tās, kuras apskatā nemaz nav minētas. Tātad AI ir pirmais filtrs, nevis apstiprinājums; Lēmumu par apvienošanu pieņem atbildīga persona.

6. Kāds ir vismānīgākais slazds, kas rodas, vienkārši iedodot AI kodu un izdrukājot testus?

• A) AI vienmēr raksta pārāk daudz testu un palielina kodu bāzi
• B) AI pārbauda pašreizējo (varbūt nepareizo) koda darbību kā “pareizu” un novērš kļūdu ✔
• C) AI automātiski izdzēš kodu, rakstot testus
• D) AI raksta testus ne tikai laimīgajam ceļam, bet vienmēr arī malas gadījumam

Paskaidrojums: AI mēdz aplūkot kodu un rakstīt apgalvojumus, kas pārbauda pašreizējo uzvedību. Ja kods ir nepareizs no paša sākuma, AI labo šo nepareizo darbību kā “pareizu”. Tāpēc testa gaidas ir jāraksta saskaņā ar nepieciešamo noteikumu (specifikāciju), nevis saskaņā ar pašreizējo koda izvadi.

7. Kas visvairāk nosaka hipotēžu precizitāti, atkļūdojot kļūdu ar AI?

• A) Cik pieklājīgi ir uzrakstīts aicinājums.
• B) Cik reizes jautājums tika uzdots vēlreiz
• C) Modelim sniegto pierādījumu kvalitāte: pilns kļūdas ziņojums, steka izsekošana, ievade un paredzamā darbība ✔
• D) Kādā krāsu motīvā ir rakstīts kods?

Paskaidrojums: AI neredz kļūdu tā, kā jūs redzat; Viņš zina tikai pierādījumus, ko jūs viņam sniedzat. Ņemot vērā pilnu kļūdas ziņojumu, steka izsekošanu, iedarbināšanas ievadi un paredzamo darbību, modelis uzskaita reālās iespējas; Ja nav pierādījumu, tas izdara minējumu (halucinācijas) un noved jūs uz nepareizā ceļa.

8. Kāds ir vissvarīgākais solis pirms ražošanas žurnālu nodošanas AI analīzei?

• A) Ielīmējiet baļķi tādu, kāds tas ir, aptverot visu dienu
• B) Vispirms konvertējiet žurnālu uz lielajiem burtiem
• C) Baļķu līniju sakārtošana alfabētiskā secībā
• D) Personas datu un noslēpumu maskēšana un tikai attiecīgā loga ierādīšana ✔

Apraksts: Neapstrādātas ražošanas žurnālos ir ietverts IP, e-pasts, sesijas ID, marķieris un dažreiz atklāts noslēpums. To ievietošana mākslīgā intelekta rīkā bez maskēšanas ir nopietns privātuma pārkāpums. Turklāt žurnāls jāfiltrē uz šauru laika logu; Bet pirmā nepieciešamība ir notīrīt sensitīvos datus.

9. Kā rīkoties, ja AI žurnāla analīzē saka, ka divi notikumi notikuši “vienlaikus” un vienu kā galveno cēloni paziņo?

• A) Korelācijas neņemšana vērā kā cēloņsakarība un apgalvojuma pārbaude ar metriku un kodu ✔
• B) Cēloņa pieņemšana par galīgu, jo AI nosaka laika attiecības
• C) Nekavējoties restartējiet pirmo apsūdzēto komponentu
• D) Žurnālu pilnīga dzēšana un atkārtota savākšana

Paskaidrojums: Visizplatītākā kļūda žurnāla analīzē ir sajaukšana ar cēloņsakarību. AI noteiktā laika attiecība ir pavediens, nevis pierādījums. Patiesai cēloņsakarībai ir nepieciešams laiks, mehānisms un, ja iespējams, atkārtojamība; Pretenzija ir jāapstiprina ar metriku un kodu.

10. Kāds ir neapstrīdams zelta likums, veicot pārstrukturēšanu ar AI, un kas to nodrošina?

• A) kodam jābūt īsākam; Līniju skaits to garantē
• B) Nav izmaiņu uzvedībā; testi, kas fiksē pašreizējo uzvedību, to nodrošina ✔
• C) kodā ir vairāk komentāru; AI to garantē
• D) visa faila pārrakstīšana uzreiz; aģents to garantē

Paskaidrojums: Refaktorēšana ir koda iekšējās struktūras uzlabošana, nemainot tā ārējo darbību; Zelta likums ir tāds, ka uzvedība paliek nemainīga. To nodrošina testēšana: testtīkls, kas fiksē pašreizējo uzvedību pirms tā maiņas, tiek iestatīts un palaists pēc katras darbības. Refaktorings bez testneta ir azartspēle.

11. Kāds ir dokumentācijas izstrādes slānis, ko AI nevar zināt un kuru izdomāt ir bīstami?

• A) Kā veikt instalēšanas darbības
• B) Funkcijas parametru saraksts
• C) „Kāpēc” dizaina lēmums tika pieņemts šādā veidā ✔
• D) Kādā valodā kods ir uzrakstīts?

Apraksts: AI var izvilkt no koda slāni “kas/kā” (ko funkcija dara, kā tā tiek iestatīta); bet tas nevar zināt slāni “kāpēc” (lēmuma pamatojums, robežvērtības iemesls). Izdomāts “iemesls” ir bīstamāks par attaisnojuma neesamību; Koda īpašniekam ir jāpievieno šis slānis.

12. Kā izstrādātājam būtu jārīkojas, ja viņš vēlas ielīmēt konfigurācijas failu, kas satur reāllaika API atslēgu, neapstiprinātā AI rīkā, vienlaikus novēršot steidzamu kļūdu?

• A) Lai nodrošinātu ātrumu, ielīmējiet failu tādu, kāds tas ir, un pēc tam izdzēsiet tērzēšanu
• B) Faila beigās pievienojiet "konfidenciālu" piezīmi un nosūtiet to
• C) Atstājiet atslēgu un mainiet tikai faila nosaukumu
• D) Noņemiet/maskējiet noslēpumus un sniedziet tikai nepieciešamo nejutīgo kontekstu ✔

Izpaušana: noslēpumus, personas datus un konfidenciālus īpašumus nekad nedrīkst ievadīt neapstiprinātos līdzekļos; Steidzamība neaptur šo sarkano līniju. Pareizā pieeja ir vispirms iegūt/maskēt noslēpumus un sniegt tikai nepieciešamo, nejutīgo kontekstu. Ja noslēpums joprojām noplūst, pirmais, kas jādara, ir nekavējoties pagriezt šo atslēgu.

13. AI ģenerēts kods iztur testēšanu un tiek palaists ražošanā. Vai tas pierāda, ka kods ir drošs?

• A) Nē; 'strādājošs' nenozīmē drošu, drošībai nepieciešams atsevišķs autentifikācijas slānis ✔
• B) Jā; Kods, kas iztur testu, pēc definīcijas ir drošs
• C) Jā; Palaižot to ražošanā, tiek novērstas visas ievainojamības
• D) Nē; bet drošībai ir nozīme tikai tad, ja kods ir lēns

Paskaidrojums: “Darbs” nav tas pats, kas “drošs”. Pat ja kodā ir ievainojamība, piemēram, SQL injekcija, tas var izturēt pārbaudi un darboties nevainojami; Ievainojamība tiek atklāta tikai tad, kad uzbrucējs to atrod. Tāpēc papildus precizitātei uz drošību orientēta pārskatīšana un skenēšana, piemēram, SAST, jāveic kā atsevišķs slānis.

14. Kāda ir drošākā disciplīna, dodot vairāku failu uzdevumu CLI aģentam (autonoms rīks, kas var modificēt failus un palaist komandas)?

• A) Sakot aģentam "uzlabojiet šo moduli" un dodot pilnīgu brīvību
• B) Šauras darbības jomas un pieņemšanas kritēriju piešķiršana, plāna pieprasīšana vispirms, tā apstiprināšana, tā ieviešana soli pa solim un testu veikšana ✔
• C) Tieši apvienot visas aģenta izmaiņas, tās nepārskatot
• D) nodrošināt aģentam neierobežotu piekļuvi ražošanas videi un konfidenciāliem datiem

Paskaidrojums: Palielinoties autonomijai, jāpalielinās arī kontrolei. Piešķirt aģentam šauru darbības jomu un skaidrus akceptēšanas kritērijus, vispirms pieprasot plānu bez izmaiņām, apstiprinot plānu, pēc tam liekot to ieviest soli pa solim un katrā solī veikt testus; Tas novērš izmaiņas, kas ir plašas, nepārskatāmas un kuras ir jāatceļ.

15. Kas ir atbildīgs par mākslīgā intelekta radītu kodu drošībai kritiskā programmatūrā (piemēram, maksājums vai autentifikācija)?

• A) Tā kā kods nāk no AI, tas atrodas transportlīdzekļa nodrošinātājā
• B) Ja mākslīgais intelekts ir pietiekami attīstīts, nevienam tā nav; nav nepieciešams pārbaudīt
• C) komanda/inženieris, kas pārbauda, apkopo un izplata kodu; AI neaizstāj piekrišanu ✔
• D) Tikai persona, kas raksta uzvedni, nevis tie, kas to pārskata

Apraksts: AI ir ātruma reizinātājs un projektu ģenerators; nevar uzņemties atbildību. Atbildība par jebkādām kļūdām, ievainojamībām vai pārkāpumiem, kas rodas no koda ražošanā, gulstas uz komandu, kas pārskata, apkopo un izplata šo kodu. Drošībai kritiskās jomās mākslīgā intelekta izvade nekādā gadījumā neaizstāj pārskatīšanu un apstiprinājumu, ko veic kvalificēts inženieris.