AI-koodaustyökalut ja työnkulun integrointi

Voitot:

• Kyky kartoittaa editorin valmistuminen, chat-avustaja, CLI-agentti ja CI-automaatiokategoriat tehtäviin
• Kyky säätää autonomiatasoa riskin mukaan ja soveltaa 'suunnitelma ensin' -kuria CLI-agentteihin
• Kyky muuttaa tekoälyn käyttö tiimijärjestelmäksi, joka perustuu validoituun työkaluun, vahvistusporttiin, läpinäkyvyyteen ja vastuullisuuteen

Tähän mennessä olemme oppineet käyttämään tekoälyä yksittäisissä tehtävissä (koodaus, tarkastelu, testaus, virheenkorjaus). Tässä viimeisessä osiossa kokosimme osat yhteen: tutustumme erilaisiin tekoälykoodaustyökaluihin, sovitamme oikean työkalun oikeaan työhön ja upotamme ne turvallisesti päivittäiseen kehityskulkuusi – editorista versionhallintaan, CI/CD-putkistosta tiimin hallintaan. Tavoitteena on muuttaa sotkuinen "kysy tekoälyltä aina silloin tällöin" -tapa johdonmukaiseksi ja tarkastettavaksi toimivaksi järjestelmäksi.

Katamme ajoneuvotyypit neutraaleilla luokilla (tuotteen nimet muuttuvat nopeasti, sillä on merkitystä, mitä luokka tekee). Jokaisella luokalla on "sweet spot" ja riskiprofiili; Mestaruus on tietää, kuinka paljon itsenäisyyttä antaa millekin tehtävälle.

AI-koodaustyökalujen luokat

1. Editorin sisäinen valmistuminen. Laajennukset, jotka ehdottavat rivejä/lohkoja kirjoittaessasi IDE:hen (kehitysympäristöön, johon kirjoitat koodia). Sweet spot: in-stream-nopeus, vakiokoodi. Riski: kapea konteksti, ehdotuksen hyväksyminen ajattelematta.

2. Chat/sivupaneelin avustaja. Chat-käyttöliittymä, joka on upotettu IDE:hen, ja näkyy osassa koodikantaasi. Sweet spot: kuvaus, uudelleentekijä, testaus, virheanalyysi. Riski: rajoitettu antamaasi kontekstiin, vaatii vahvistusta.

3. CLI-agentit (agenttityökalut). Komentoriviltä suoritettavat työkalut voivat lukea ja muokata useita tiedostoja, suorittaa komentoja ja suorittaa monivaiheisia tehtäviä yksinään. Sweet spot: usean tiedoston muutokset, toistuvat tehtävät, "lisää tämä ominaisuus" -tyyppiset työt. Riski: suuri autonomia = suuri vaikutus; Jos se jätetään valitsematta, se tuottaa laajoja ja vaikeasti tarkistettavia muutoksia.

4. Linja-/automaatiointegraatio. CI (Continuous Integration) -botit, jotka jättävät automaattisia tarkistuskommentteja PR:ihin, ehdottavat testejä tai tuottavat muutoslokeja. Sweet spot: ensimmäinen siivilä ilman väsymystä, koostumus. Riski: melu, väärä luottamus.

Vihje: Kun autonomia lisääntyy, hallinnan pitäisi myös lisääntyä. Koska editorin valmistuminen on pientä ja välitöntä, sitä valvotaan kevyesti; CLI-agentin usean tiedoston muokkaus tulee tutkia aivan kuten, ellei tarkemmin, kuin ihmisen PR.

Askel askeleelta: Tekoälyn upottaminen työnkulkuun

1. Yhdistä tehtävä työkaluun. Pieni in-stream-lisäys → valmistuminen; ymmärtää/refaktoroi/testaa → chat; monitiedostoinen, toistuva työ → CLI-agentti; jatkuva ensimmäinen suodatin → CI-integrointi.
2. Valitse autonomian taso. Kuinka paljon vapautta agentilla on? Vain luku -ehdotus tai tiedoston muokkaus + komennon suoritus? Säädä riskiä.
3. Kasvata kontekstia. Ota pysyvästi käyttöön projektisäännöt (tyyli, arkkitehtuuri, "ei saa") työkaluun; Käytä projektin ohjetiedostoa sen sijaan, että selität sitä yhä uudelleen ja uudelleen.
4. Säilytä varmistusportit. Tekoälymuutos on kuin ihmisen muutos: se käy läpi kokoamisen, testauksen, arvioinnin ja (jos kriittinen) asiantuntijoiden hyväksynnän. Tekoälyn avaus PR ei ohita hyväksyntää.
5. Mittaa ja säädä. Katso, mikä todella kiihtyy, missä korjaustaakka kasvaa; Karsi pois käytöstä, joka ei toimi.

Kolme minikoteloa

Tapaus 1 – CLI-agentti käsitteli usean tiedoston uudelleennimeämisen. Yksi tiimi nimesi uudelleen konseptin, joka jakautuu 60 tiedostoon. He antoivat tehtävän CLI-agentille, pyysivät ensin suunnitelmaa, hyväksyivät suunnitelman, tekivät sitten muutoksen ja suorittivat koko testisarjan. Agentilta 3 puuttui reunatapaus tiedostosta; Testit havaitsivat sen, korjasivat sen. Noin 3 tuntia käsin kestänyt työ tehtiin 50 minuutissa ohjattuna.

Tapaus 2 – Tarkkailematon autonomia koitui päinvastaiseksi. Toinen kehittäjä käski agenttia "parantaa tätä moduulia" ja julkaisi sen; Agentti muokkasi 18 tiedostoa ja lisäsi kaksi riippuvuutta. Muutos oli niin laaja, että sitä ei voitu tarkistaa ja se oli peruutettava. Oppitunti: anna agenteille kapea toiminta-ala, selkeät hyväksymiskriteerit ja ensin suunnittele-myöhemmin tee -kuri.

Tapaus 3 – CI-tarkistusbotista tuli ensimmäinen suodatin. Yksi tiimi rakensi botin, joka jättää PR:ille automaattisia tekoälyarvosteluja. Kun robotti havaitsi nollatarkistuksen puutteita ja tyyliongelmia, arvioijat pystyivät omistamaan aikansa liiketoimintalogiikkaan. Tiimi teki kuitenkin selväksi, että botti ei antanut "hyväksyntää": ainakin yksi ihmisen hyväksyntä vaadittiin silti. Melun vähentämiseksi he virittivät veneen jättämään vain korkean/keskitehoisen melun.

Neljä kopioitavaa mallia

"Suunnittele ensin" kurinalaisuus CLI-agentille:

Tehtävä: {{selkeä, kapea tehtävä}}Hyväksymisehdot: {{mitattavissa oleva tulos}}Rajoite: työskentele vain {{seuraavassa hakemistossa/tiedostoissa}}; uuden riippuvuuden lisääminen. Esitä ensin suunnitelma ILMAN MUUTOSTA: mitkä tiedostot, mikä muuttuu, mitkä testit suoritetaan. Odota, että HYVÄKSYN suunnitelman. Käytä sitten sitä vaihe vaiheelta ja suorita testit jokaisessa vaiheessa.

Projektin ohjetiedosto (pysyvä konteksti työkaluille):

Pysyvät säännöt tämän projektin tekoälytyökaluille:- Kieli/versio: {{...}}. Tyyli: {{...}}.- Arkkitehtoninen rajoitus: {{esim. suunta kerrosten välillä}}.- EI KOSKAAN: salaisuuksien upottaminen, tuotantotietojen käyttö, {{kielletyt kirjastot}}.- Jokaisen muutoksen on oltava testattavissa; Julkisen API-allekirjoituksen muuttaminen ILMAN kysymistä. - Jos olet epävarma, pysähdy ja kysy.

Tehtävätyökalun kartoituspäätös:

Määritän seuraavan tehtävän: {{tehtävä}}. Minkä luokan työkaluilla minun pitäisi tehdä tämä: (a) editorin viimeistely, (b) chat-avustaja, (c) CLI-agentti, (d) CI-automaatio? Kirjoita perustelut, riskit ja suositeltu autonomiataso (vain ehdotus / muuta tiedostoa / suorita komento).

CI-tarkistusbotin käytännesäännöt:

Jätä PR-arvioinnissa kommentteiksi vain KORKEA- ja KESKIPALAISIA vakavia löydöksiä. Jokainen löydös: luokka, vakavuus, korjausehdotus. Kerää muistiinpanot tyyliasetustasolla erilliseksi yhteenvetokommentiksi. ET HYVÄKSY; vaaditaan ihmisen hyväksyntä.

Heikko kehote / Vahva kehote

Heikko: (CLI-agentille) "Tee maksumoduulista parempi."

Vahva: (CLI-agentille) "Aja vain alla src/payments/. Tehtävä: Pura rekursiivinen vahvistuslogiikka refund()-funktiosta yhdeksi avustajaksi; käyttäytyminen ja allekirjoitukset eivät muutu. Esittele ensin suunnitelma ja odota hyväksyntääni; suorita ja suorita sitten testit/maksut/paketti. Lisää uusi riippuvuus."

Vahva versio kaventaa soveltamisalaa, asettaa hyväksymiskriteerit ja rajoitukset ja asettaa "suunnitelma ensin" kurinalaisuuden. Epämääräiset "tehdä paremmin" -vaatimukset ovat suurien ja hallitsemattomien muutosten perimmäinen syy.

ajoneuvoluokka

Mitä hän on paras

autonomia

tarkastuspaino

Toimittajan valmistuminen

Pieni in-stream-lisäys

alhainen

Kevyt (välitön luku)

chat-avustaja

Ymmärrä, testaa, refaktoroi

keskikokoinen

Keskitaso (tuotannon vahvistus)

CLI-agentti

Monitiedostoinen, rekursiivinen

korkea

Raskas (suunnitelma + täydellinen arvostelu)

CI-automaatio

Jatkuva ensimmäinen suodatin

keskikokoinen

Keskitaso (sääntö + ihmisen hyväksyntä)

Joukkueen hallinta: Yksilöllisistä taidoista jaettuun järjestelmään

Tekoälyn hyvä käyttäminen yksilöllisesti on alku; todellinen kypsyys on johdonmukainen järjestelmä tiimitasolla. Tämä järjestelmä perustuu useisiin pilareihin: luettelo hyväksytyistä työkaluista (mitä työkaluja voidaan käyttää millä tiedoilla - yksiköstä 10), varmistusportit (AI-muutos kulkee samojen rakennus-/testaus-/tarkistusporttien kautta - yksiköstä 11), läpinäkyvyys (tekoälypohjainen muutos mahdollistaa jäljitettävyyden tarvittaessa) ja vastuun selkeys (henkilö, joka allekirjoittaa ja on vastuussa). Tämä viitekehys rajoittaa riskejä säilyttäen samalla nopeuden ja varmistaa, että uudet tiimin jäsenet työskentelevät samalla kurinalaisuudesta.

Varoitus: Mitä suurempi työkalun autonomia on – varsinkin CLI-agentit, jotka voivat muokata tiedostoja ja suorittaa komentoja – sitä tiukemmin rajoittaa sen pääsyä tuotantoympäristöön, luottamuksellisiin tietoihin ja vaikeasti palautettaviin toimiin. Sido tuhoavat komennot (pysyvä poisto, käyttöönotto) ihmisen hyväksyntään.

Yleisiä virheitä

• Tehtävä tarkoittaa yhteensopimattomuutta. Yritetään tehdä usean tiedoston työ editorin valmiiksi tai pienellä liitteellä raskaalla agentilla.
• Agentin vapauttaminen. Agenttitehtävät, jotka annetaan kapealla laajuudella ja ilman "suunnitelma ensin", tuottavat tutkimattomia muutoksia.
• Tekoälyn vahvistusporttien löysääminen. "Tekoäly teki sen, jatketaan nopeasti" on vaarallisin poikkeus; Ovet ovat kaikille samat.
• Kontekstin antaminen manuaalisesti joka kerta. Projektisääntöjen kirjoittamatta jättäminen pysyvään ohjetiedostoon aiheuttaa epäjohdonmukaisuutta ja päällekkäisyyttä.
• CI-botin hyväksyntä ihmisen hyväksynnällä. Botti on suodatin; Vastuullinen ihmisen hyväksyntä on pakollinen.

Yhteenvetona

AI-koodaustyökalut jakautuvat neljään pääluokkaan: editorin viimeistely, chat-avustaja, CLI-agentit ja CI-automaatio. Mestaruus on sovittaa tehtävä oikeaan työkaluun ja oikeaan autonomiatasoon. Kun autonomia lisääntyy, myös valvonta lisääntyy. Anna työkaluille pysyvä projektikonteksti, aseta "suunnitelma ensin" -kuri monitiedostoagenteille ja siirrä tekoälymuutos samojen vahvistusporttien kautta kuin ihmisen muutos. Yksilöllinen taito; Muunna se tiimijärjestelmäksi, joka perustuu hyväksyttyyn työkaluluetteloon, varmistusportteihin, läpinäkyvyyteen ja vastuun selkeyteen. AI on päästä päähän -nopeuskerroin; Tilin allekirjoittaja ja antaja on aina pätevä henkilö.

Sovellustehtävä

Listaa kolme todellista tehtävää, jotka teet ensi viikolla. Käytä "tehtävän ja ajoneuvon yhteensopivuuspäätös" -mallia jokaisen kohdalla perustellaksesi, minkä ajoneuvoluokan ja minkä tason autonomia valitset. Suorita sitten suppea tehtävä CLI-agentille (tai chat-avustajalle) "suunnitelma ensin" -periaatteella: hyväksy suunnitelma, pane se täytäntöön, suorita testit ja tarkista muutos kuin ihmisen PR. Laadi lopuksi tiimillesi 5-pisteinen "AI-käyttösääntö" (hyväksytyt työkalut, tietosääntö, vahvistusportti, autonomiaraja, vastuullisuus).

tarkistuslista

• [ ] Pystyn erottamaan tekoälyn koodaustyökalukategorian ja kunkin suosikkipisteen.
• [ ] Kartoitan tehtävän oikeaan ajoneuvoluokkaan ja sopivaan autonomiatasoon.
• [ ] Annan työkaluille pysyvän projektikontekstin (ohjetiedoston).
• [ ] Käytän suppeaa soveltamisalaa ja "suunnitelma ensin" kurinalaisuutta CLI-agenteille.
• [ ] Välitän tekoälymuutokset samojen vahvistusporttien kautta kuin ihmisen muutokset.
• [ ] Kannatan validoitua työkalua, tietosääntöä, läpinäkyvyyttä ja vastuullisuutta koskevia puitteita tiimitasolla.

Moduulin tentti

1. Mitä koodausavustajan taustalla oleva suuri kielimalli itse asiassa tekee, kun se tuottaa koodia?

• A) Ennustaa kuviollisesti todennäköisimmän jatkon annetun kontekstin perusteella ✔
• B) Takaa oikean tuloksen kääntämällä ja suorittamalla koodin
• C) Se skannaa koodin kaikkialla Internetissä suorana ja kopioi tarkimman koodin.
• D) Ymmärtää koodin logiikan ihmisinsinöörin tavoin ja ymmärtää tarkoituksen

Selvennys: LLM ei "ymmärrä" koodia kuin ihminen; Se luo todennäköisimmän jatkon annettuun kontekstiin perustuen kuvioihin, jotka se oppii erittäin suuresta teksti- ja koodijoukosta. Siksi tulosteen laatu riippuu suoraan antamasi kontekstin ja ohjeiden laadusta, ja jokainen tulos on validoitava.

2. Millä nimellä kutsut sitä, kun tekoäly keksii vakuuttavasti olemattoman funktion tai kirjaston, ja mikä on ainoa todellinen vastalääke?

• A) Tätä kutsutaan käännösvirheeksi; Vastalääke on vahvempi varuste
• B) Tätä kutsutaan hallusinaatioksi; Vastalääke on tarkistaa koodi ja jokainen käytetty API ✔
• C) Tätä kutsutaan regressioksi; Vastalääke on käynnistää malli uudelleen
• D) Tätä kutsutaan kontekstin ylivuodoksi; Vastalääke on lyhentää kehotetta

Kuvaus: Tätä kutsutaan hallusinaatioksi ja se aiheuttaa yhden ohjelmiston kalleimmista virheistä. Ainoa todellinen vastalääke on todentaminen: sen varmistaminen, että jokainen käytetty toiminto, API ja paketti ovat todella olemassa ja että koodi toimii. Mallin itsevarma sävy ei ole todiste tarkkuudesta.

3. Mikä lähestymistapa parantaa eniten tulosteen laatua ja johdonmukaisuutta luotaessa koodia tekoälyllä?

• A) Mallin vapauttaminen sanomalla "kirjoita tämä minulle" antamatta mitään kontekstia
• B) Kirjoita mahdollisimman pitkä ja upea kehote
• C) Määritä ja anna esimerkkejä syöttö-/tulostussopimuksista, reunatapauksista, versioista ja tyylistä ✔
• D) Luodun koodin yhdistäminen suoraan lukematta sitä

Selitys: Määrittämällä funktion syöttö/tulostustyypit (sopimus), reunatapaukset, kieli-/versio- ja tyylirajoitukset ja antamalla esimerkin mallista, voidaan siirtyä ennusteesta tarkkuuteen. Kontekstittomat "kirjoita minulle tämä" -pyynnöt tuottavat koodia, joka on joka kerta erilainen ja ohittaa usein reunatapaukset.

4. Kun tutkitaan ulkomaista koodikantaa tekoälyn avulla, funktion nimi voi olla "validateAndSave", mutta AI-tiivistelmä voi olla virheellinen. Mikä on oikea lähestymistapa?

• A) Täysi luottamus tekoälyyhteenvetoon, koska nimi on itsestään selvä
• B) Toiminnon muuttaminen suoraan lukematta sitä
• C) Päättäminen vain katsomalla funktion nimeä
• D) Käsittele tekoälyn kuvausta hypoteesina ja tarkista kriittiset väitteet koodissa rivi riviltä ✔

Selitys: AI voi katsoa koodissa olevaa nimeä ja kertoa sinulle "miltä se näyttää tekevän", mutta todellisuudessa logiikka voi olla erilainen (tai jopa päinvastainen). Joten tekoälyn selitys on hypoteesi; Kriittiset väitteet, erityisesti ne, jotka liittyvät turvallisuuteen, valtuuksiin tai rahavirtaan, tulee tarkistaa asianmukaisilla riveillä.

5. Mikä on suurin vaara, kun sanotaan "AI katsoin, se on selvää" tekoälyavusteisessa koodintarkistuksessa?

• A) AI voi tuottaa vääriä negatiivisia tuloksia; Todelliset ohitetut virheet luovat väärää luottamusta ✔
• B) AI-tarkistus on liian hidas, joten se vie aikaa
• C) Tiimi ei ymmärrä, koska tekoäly kommentoi vain englanniksi
• D) PR ei lähenty, koska tekoäly tulkitsee aina liikaa

Selitys: Tekoäly tuottaa sekä vääriä positiivisia (merkitsee ongelman siellä missä sitä ei ole) että vääriä negatiivisia (todellinen virhe puuttuu). Väärät negatiivit ovat hiljaa; Vaarallisimmat virheet ovat ne, joita ei mainita katsauksessa ollenkaan. Joten tekoäly on ensimmäinen suodatin, ei hyväksyntä; Päätös sulautumisesta kuuluu tilivelvolliselle.

6. Mikä on salakavalin ansa, joka tapahtuu, kun annat tekoälylle koodin ja tulostat testit?

• A) AI kirjoittaa aina liikaa testejä ja turvottaa koodikantaa
• B) AI testaa koodin nykyisen (ehkä väärän) käyttäytymisen "oikeaksi" ja korjaa virheen ✔
• C) AI poistaa koodin automaattisesti kirjoittaessaan testejä
• D) AI kirjoittaa testejä ei vain onnelliselle tielle, vaan aina reunatapaukselle

Selitys: AI pyrkii katsomaan koodia ja kirjoittamaan väitteitä, jotka testaavat nykyistä käyttäytymistä. Jos koodi on alusta alkaen väärä, tekoäly korjaa tämän väärän toiminnan "oikeaksi". Siksi testin odotukset tulee kirjoittaa vaaditun säännön (spesifikaatio) mukaan, ei koodin nykyisen lähdön mukaan.

7. Mikä ratkaisee eniten hypoteesien tarkkuuden, kun virheenkorjaus tehdään tekoälyllä?

• A) Kuinka kohteliaasti kehote on kirjoitettu.
• B) Kuinka monta kertaa kysymys esitettiin uudelleen
• C) Mallille toimitetun todisteen laatu: täydellinen virheilmoitus, pinon jäljitys, syöttö ja odotettu käyttäytyminen ✔
• D) Millä väriteemalla koodi on kirjoitettu?

Selitys: AI ei näe virhettä samalla tavalla kuin sinä; Hän tietää vain todisteet, jotka annat hänelle. Kun otetaan huomioon täydellinen virheilmoitus, pinojäljitys, liipaisusyöttö ja odotettu käyttäytyminen, malli luettelee todelliset mahdollisuudet; Jos todisteita ei ole, se tekee arvauksen (hallusinaatiot) ja johtaa sinut väärälle tielle.

8. Mikä on kriittisin vaihe ennen tuotantolokien antamista tekoälylle analysoitavaksi?

• A) Liitä loki sellaisenaan, kattaa koko päivän
• B) Muunna loki ensin isoiksi kirjaimiksi
• C) Järjestä lokirivit aakkosjärjestykseen
• D) Henkilötietojen ja salaisuuksien peittäminen ja vain asiaankuuluvan ikkunan antaminen ✔

Kuvaus: Raakatuotantolokit sisältävät IP-osoitteen, sähköpostin, istuntotunnuksen, tunnuksen ja joskus avoimen salaisuuden. Niiden kiinnittäminen tekoälytyökaluun peittämättä niitä on vakava tietosuojaloukkaus. Lisäksi loki tulee suodattaa kapeaan aikaikkunaan; Mutta ensimmäinen tarve on puhdistaa arkaluonteiset tiedot.

9. Mitä pitäisi tehdä, jos tekoäly sanoo, että kaksi tapahtumaa tapahtui "samanaikaisesti" log-analyysissä ja ilmoittaa yhden perimmäiseksi syyksi?

• A) Korrelaation huomioimatta jättäminen kausaliteettina ja väitteen tarkistaminen mittareilla ja koodilla ✔
• B) Syyn hyväksyminen lopulliseksi, koska tekoäly muodostaa aikasuhteen
• C) Käynnistä välittömästi uudelleen ensimmäinen syytetty komponentti
• D) Poista lokit kokonaan ja kerää ne uudelleen

Selitys: Lokianalyysin yleisin sudenkuoppa on korrelaation ja syy-yhteyden sekoittaminen. Tekoälyn luoma aikasuhde on vihje, ei todiste. Todellinen syy-yhteys vaatii ajoitusta, mekanismia ja, jos mahdollista, toistettavuutta; Vaatimus on vahvistettava mittareilla ja koodilla.

10. Mikä on ei-neuvoteltavissa oleva kultainen sääntö tekoälyllä tapahtuvassa uudelleenjärjestelyssä ja mikä sen turvaa?

• A) Koodin tulee olla lyhyempi; Rivien määrä takaa tämän
• B) Ei muutosta käyttäytymisessä; nykyisen käyttäytymisen tallentavat testit varmistavat tämän ✔
• C) Koodi sisältää enemmän kommentteja; AI takaa tämän
• D) Koko tiedoston uudelleenkirjoittaminen kerralla; välittäjä takaa tämän

Selitys: Refaktorointi parantaa koodin sisäistä rakennetta muuttamatta sen ulkoista toimintaa; Kultainen sääntö on, että käyttäytyminen pysyy vakiona. Tämä varmistaa testauksen: testiverkko, joka tallentaa nykyisen toiminnan ennen sen muuttamista, määritetään ja suoritetaan jokaisen vaiheen jälkeen. Refaktorointi ilman testiverkkoa on uhkapeliä.

11. Mikä on se kerros dokumentaation tuotannossa, jota tekoäly ei voi tietää ja jonka keksiminen on vaarallista?

• A) Kuinka suorittaa asennusvaiheet
• B) Funktion parametriluettelo
• C) Perustelu "miksi" suunnittelupäätös tehtiin tällä tavalla ✔
• D) Millä kielellä koodi on kirjoitettu?

Kuvaus: AI voi poimia "mitä/miten" -kerroksen (mitä toiminto tekee, miten se asetetaan) koodista; mutta se ei voi tietää "miksi"-kerrosta (päätöksen suunnitteluperusteita, raja-arvon syytä). Keksitty "syy" on vaarallisempi kuin perusteeton; Koodin omistajan on lisättävä tämä kerros.

12. Mitä kehittäjän tulee tehdä, jos hän haluaa liittää elävän API-avaimen sisältävän määritystiedoston ei-hyväksyttyyn tekoälytyökaluun, kun hän ratkaisee kiireellisen virheen?

• A) Nopeuttaaksesi liitä tiedosto sellaisenaan ja poista sitten keskustelu
• B) Lisää "luottamuksellinen" huomautus tiedoston loppuun ja lähetä se
• C) Jätä avain ja muuta vain tiedoston nimi
• D) Poista/naamio salaisuudet ja anna vain tarvittava ei-arkaluonteinen konteksti ✔

Tietojen paljastaminen: Salaisuuksia, henkilötietoja ja luottamuksellisia resursseja ei saa koskaan viedä luvattomasti; Kiireellisyys ei keskeytä tätä punaista viivaa. Oikea lähestymistapa on poimia/naamioida ensin salaisuudet ja antaa vain tarvittava, ei-arkaluonteinen konteksti. Jos salaisuus edelleen vuotaa, ensimmäinen asia on kääntää avainta välittömästi.

13. Tekoälyn luoma koodi läpäisee testin ja toimii tuotannossa. Todistaako tämä, että koodi on turvallinen?

• A) Ei; 'toimiva' ei tarkoita turvallista, turvallisuus vaatii erillisen todennuskerroksen ✔
• B) Kyllä; Testin läpäisevä koodi on määritelmän mukaan turvallinen
• C) Kyllä; Sen suorittaminen tuotannossa poistaa kaikki haavoittuvuudet
• D) Ei; mutta tietoturvalla on väliä vain, jos koodi on hidas

Selvennys: "Työskentely" ei ole sama asia kuin "turvallinen". Vaikka koodi sisältää haavoittuvuuden, kuten SQL-injektion, se voi läpäistä testauksen ja toimia sujuvasti. Haavoittuvuus paljastuu vasta, kun hyökkääjä löytää sen. Siksi tarkkuuden lisäksi turvallisuussuuntautunut tarkistus ja tarkistukset, kuten SAST, tulisi suorittaa erillisenä kerroksena.

14. Mikä on turvallisin kurinalaisuus, kun monitiedostotehtävä annetaan CLI-agentille (itsenäinen työkalu, joka voi muokata tiedostoja ja suorittaa komentoja)?

• A) Kerro agentille "paranna tätä moduulia" ja anna täysi vapaus
• B) Suppean laajuuden ja hyväksymiskriteerien antaminen, suunnitelman pyytäminen ensin, sen hyväksyminen, vaiheittainen toteuttaminen ja testien suorittaminen ✔
• C) Yhdistä suoraan kaikki agentin muutokset tarkistamatta niitä
• D) Antaa agentille rajoittamaton pääsy tuotantoympäristöön ja luottamuksellisiin tietoihin

Selitys: Kun autonomia lisääntyy, myös hallinnan pitäisi lisääntyä. Agentille annetaan kapea toiminta-alue ja selkeät hyväksymiskriteerit, pyydetään ensin suunnitelma ilman muutoksia, hyväksytään suunnitelma, sitten se toteutetaan vaihe vaiheelta ja testataan jokaisessa vaiheessa; Se estää muutokset, jotka ovat laajoja, tarkistamattomia ja jotka on peruutettava.

15. Kenellä on vastuu, joka johtuu tekoälyn luomasta koodista tietoturvakriittisissä ohjelmistoissa (esim. maksu tai todennus)?

• A) Koska koodi tulee tekoälyltä, se on ajoneuvon toimittajassa
• B) Jos tekoäly on riittävän kehittynyt, kukaan ei ole sitä tehnyt; ei tarvitse tarkistaa
• C) tiimi/insinööri, joka tutkii, kokoaa ja jakaa koodin; Tekoäly ei korvaa suostumusta ✔
• D) Vain kehotteen kirjoittaja, eivät sen tarkistajat

Kuvaus: AI on nopeuden kertoja ja suunnitelmageneraattori; ei voi ottaa vastuuta. Vastuu kaikista tuotannossa olevasta koodista johtuvista virheistä, haavoittuvuuksista tai rikkomuksista on tiimillä, joka tarkistaa, kokoaa ja jakelee koodia. Turvallisuuden kannalta kriittisillä alueilla tekoälytulostus ei missään olosuhteissa korvaa pätevän insinöörin suorittamaa tarkistusta ja hyväksyntää.