Kasu:
- Võimalus teha vahet, kus tehisintellekt pakub tarkvaraarenduse elutsüklis tõelist kiirust ja kus jääb otsustus ja vastutus insenerile
- Võime rakendada kolmekihilist inseneridistsipliini, mis kontrollib iga koostamise, testimise ja ülevaatamise teel loodud koodi ja disaini.
- Harjutage konteksti tühjendamist, et kasutada tehisintellekti ilma konfidentsiaalset lähtekoodi, mandaate ja kliendiandmeid jagamata
Kui vaadata arvutiinseneri päeva, siis enamikus meeskondades on pilt sarnane: ärisoovist aru saamine, projekteerimine, koodi kirjutamine, kellegi teise koodi lugemine, silumine (programmi valesti töötamise põhjuste väljaselgitamine ja selle parandamine), testide kirjutamine, dokumentatsiooni koostamine, koodi ülevaatamine ja koosolekutel osalemine. Teisisõnu, aeg, mis on pühendatud tõelisele "inseneri otsusele", st sellele, kas lahendus on õige, ohutu ja jätkusuutlik, purustatakse korduva töö all. Siin tuleb mängu tehisintellekt (lühidalt AI; tarkvara, mis töötab teksti ja koodiga suure keelemudeliga). AI ei tee otsust teie eest; See valmistab teid ette otsuse tegemiseks, loob koodiskeleti, kitsendab vea ja paneb teie ette töödeldud mustandi. Kogu selle mooduli jooksul positsioneerime tehisintellekti mitte "automaatse programmeerijana", vaid distsiplineeritud paarisprogrammeerimispartnerina, kelle väljundit iga kord kompileeritakse, testitakse ja vaadatakse üle.
Selles esimeses tükis selgitame kolme asja: millistel tarkvaraarenduse elutsükli etappidel (etapid, mida tarkvara läbib ideest tootmiseni: analüüs, projekteerimine, kodeerimine, testimine, juurutamine, hooldus) lisab tehisintellekt tõelist väärtust; millised otsused peaksid jääma rangelt insenerile; ja milline on kontrollimise ja konfidentsiaalsuse põhimõte, mida peate seda tehes järgima. Kui see katus pole õigesti paigaldatud, võivad järgnevate seadmete tehnikad muutuda ohtlikuks; Kuna tarkvara viga jõuab korraga miljonite kasutajateni ja võib muutuda turvaauguks.
Mõisted: Hallutsinatsioonid: AI veenev väljamõeldis meetodi, raamatukogu, API või käitumise kohta, mida tegelikult ei eksisteeri. Kontekst: AI-le antud sisend (kood, veateade, nõue, piirangud). Kontrollimine: Väljundi kontrollimine sõltumatul viisil (koostamine, testimine, dokumenteerimine). Need kolm kontseptsiooni on kogu mooduli selgroog.
Millistes ettevõtetes on AI Accelerator, millistes ettevõtetes on see riskantne?
Tarkvaraga seotud töökohad on tulemuste osas kahesuunalised. Ühes otsas on pööratavad, madala riskiga ettevalmistustööd; Teises otsas on raskesti tagastatavad ülesanded, mis sisenevad tootmiskeskkonda ja võivad põhjustada andmete kadu, turvaauke või katkestusi. AI väärtus varieerub sõltuvalt sellest, kus te selles spektris asute.
äri tüüp
AI panus
Inseneri roll
Koodiskelett / katlaplaat
Korduva struktuuri kiire genereerimine
Loogika ja serva oleku juhtimine
silumine
Hüpotees ja võimalike põhjuste loetelu
Paljunemise ja algpõhjuse kinnitus
testide kirjutamine
Testi mustand ja stsenaariumi loomine
Sisukas kinnituse ja ulatuse kontroll
refaktoreerimine
Refaktoreerimise ettepanek
Käitumise säilitamine testimise kaudu
Dokumentatsioon
Esimene mustand ja struktuur
Koodide õigsuse kontroll
Arhitektuuri/turvalisuse otsus
Valikute loetelu ning plussid ja miinused
Lõplik otsus ja vastutus
Reegel on lihtne: tehisintellekti väljundi risk võrdub kahjuga, mis tekib, kui see väljund teeb vea. Muutuja nime vale väljapakkumine on kahjutu; Ebaõige autentimine (kontrollimine, et kasutaja on tõesti see, kes ta väidab end olevat) muudab kogu süsteemi haavatavaks. Nii et esimene küsimus, mida enne väljundi kasutamist küsida, on: "Mis juhtub, kui see on vale ja kes ja millal seda märkab?"
Ettevaatust: AI toodab sujuvat ja enesekindlat koodi. Sujuvus ei garanteeri täpsust. Keelemudel võib usaldusväärselt tekitada funktsiooni nime, mida tegelikult ei eksisteeri, vale parameetrijada või isegi ebaturvalise mustri. Tarkvaras see paberile ei jää; See kompileerib, töötab ja plahvatab tootmises.
Otsused, mis tuleks jätta insenerile
Mõned otsused ei tohiks kunagi olla täielikult automatiseeritud; sisaldab tehnilisi, juriidilisi ja eetilisi riske:
- Tootmise heakskiitmine: Koodi tootmisse vabastamine ja selle eest vastutamine.
- Turvalisus ja arhitektuur: kallid otsused, nagu autentimine, autoriseerimine, krüptimine ja andmemudel.
- Litsents ja autoriõigus: toodetud koodi kasutatavus kaubanduslikus tootes ja litsentsile vastavus.
- Töö konfidentsiaalsete andmetega: tehingud kliendiandmete, lähtekoodi saladuste ja identiteedi teabega.
Hoiatus: isegi kui AI ütleb "see kood on turvaline ja tootmiseks valmis", on selle aktsepteerimine ilma turvatesti, koodi ülevaatuse ja valideerimiseta reaalse koormuse all vastuvõetamatu. Ohutuskriitilises töös ei asenda tehisintellekti väljund kunagi pädeva inseneri kinnitust; Kõik otsuseni viivad väljundid peavad enne rakendamist olema sõltumatult kontrollitud ja heaks kiidetud volitatud inseneriga.
Kontrollimise distsipliin: kolmekihiline kontroll
Rakendage kolme juhtimiskihti, et kasutada tehisintellekti väljundit pigem vanemretsensendina kui pimesi. See on põhirefleks, mida kordame kogu mooduli jooksul.
- Kompileerimine ja staatiline kontrollimine: kas kood ka tegelikult kompileerib/töötab? Kas esineb tüübivigu, kasutamata muutujaid, olematuid API-sid? Mida ütleb staatilise analüüsi tööriist (tööriist, mis uurib koodi ilma seda käivitamata)?
- Sõltumatu reprodutseerimine (testimine): käivitage kood väikeste teadaolevate sisenditega ja vaadake, kas saate oodatud väljundi. Proovige servajuhtumeid (null, null, negatiivne, tohutu).
- Allika kinnitamine: iga API, teegi versioon ja keelefunktsioon, mida AI kasutab, tuleks ametlikust dokumentatsioonist kontrollida.
Kinnitusviip (muudab väljundi kontrollimise lihtsamaks): "Loetlege KÕIK välised teegid, meetodid ja keelefunktsioonid, mida oma koodis kasutate. Märkige iga versiooni puhul, millises versioonis see on saadaval, ja märkige see "peab olema kinnitatud dokumentatsioonist". Ärge tehke API-sid, milles te pole kindel; kui te pole kindel, kirjutage selgelt "pole kindel". Loetlege ka kõik aadressijuhtumid eraldi."
Kritiseerige oma koodiviipa: "Vaadake äsja kirjutatud koodi kriitiliselt, nagu vaneminsener, kes teid palkas. Andke konkreetsed elemendid nende kolme pealkirja alla: (1) loogika-/servajuhtumi vead, (2) turvariskid, (3) jõudluse või loetavuse probleemid. Kirjutage iga üksuse juurde "miks on probleem" ja "soovitatud lahendus". Ära leia probleemi, öelge, kui probleem pole. seda kaunistama."
Nõrk viip / Tugev viip
NÕRK:"Kirjutage mulle kasutaja autentimise funktsioon."(Tulemus: ebaselge, mis keeles, milline reegel, milline vea käitumine; üldine kood, sageli ebaturvaline või kontekstist väljas.)STRONG:"Kirjutage Python 3.11 meilikontrolli funktsioon. Sisend: string. Väljund: tõene, kui see on kehtiv, muidu vale. Reeglid: nõutav on tühi string väline teek, DONOT RUSE. Funktsiooni lisamise ploki all olev 5-prooviline test: kehtiv, tühi, ilma '@'ta, kahekordne '@', sisaldab ainult tühikuid.
Erinevus on kontekstis. Võimas viip; See sisaldab keelt, versiooni, sisend-väljundlepingut, piiranguid ja testi ootust. See üksainus distsipliin vähendab oluliselt hallutsinatsioonide ja ebaturvalise koodi riski.
Mini korpused
Juhtum 1 – väljamõeldud meetod. Arendaja kuuleb AI-lt, et kuupäevateegis on meetod nimega date.addBusinessDays(5) ja seda selgitatakse enesekindlalt. Dokumentatsiooni vaadates näeb ta, et sellist meetodit pole, õige tee on käsitsi silmus. Hallutsinatsioonid püütakse kinni enne selle tootmist 10-minutilise kontrolliga.
Juhtum 2 – serva oleku kadu. AI loob funktsiooni "arvuta keskmine"; See töötab, kui seda testitakse 1000 andmereaga. Kui aga loend on tühi, annab see nulliga jagamise vea. Kuna insener lisas tühja sisendi testi, näeb ja parandab ta vea enne selle käivitamist. Ühe serva seisukorra test hoiab ära tootmishäire kell 3 öösel.
Juhtum 3 – privaatsusrisk. Ekspert kleepib avalikku tööriista faili koos tegeliku andmebaasi ühenduse stringi ja API-võtmega. peab meeles asutuse poliitikat; See asendab saladused koodiga <REDACTED>, taandab koodi esinduslikuks näiteks ja küsib seda. Seega saab ta abi 5 minutiga, kuid tema isikuandmed ei tule välja.
Salakoodi ja isikuandmetega töötamise põhimõte
Tarkvara kõige tundlikum osa; lähtekoodi saladused, identiteedi teave (API võti, parool, luba) ja kliendi/isikuandmed. Põhiprintsiip: puhasta enne jagamist, küsi võimalusel esindusliku näitega vaid probleemi olemust.
Anonüümne viipade muster: "Järgmises funktsioonis on viga. Asendasin tegeliku äriloogika ja peidetud konstandid tüüpiliste väärtustega (API-võti, tabelinimed, väljanimed üldised). Probleem: saan sisendis X vea Y. Lihtsalt leidke selles esinduskoodis loogikaviga ja selgitage parandatud versiooni. [esinduskood]"
Nõuanne. Kui kahtlete, tehke see test: "Kas mu organisatsioon satuks hätta, kui ma selle avalikult foorumisse kirjutaksin?" Isegi kui vastus on ebaselge, puhastage see kõigepealt. Lähtestamine on alati odavam kui hiljem lekke tagaajamine.
Levinud vead
- Väljundi kasutamine ilma kompileerimise/testimiseta. "AI kirjutas" ei ole õigustus; Iga koodiosa kontrollitakse selle käivitamisega.
- Kontekstita taotluste esitamine. Kui keelt, versiooni, sisend-väljundit ja piiranguid pole antud, muutub kood üldiseks ja sageli ebaturvaliseks.
- Konfidentsiaalse teabe jagamine mõtlemata. API-võtit, parooli ja kliendiandmeid ei tohi vabastada ilma kustutamata.
- Ajab segamini täpne keel täpsusega. Mida enesekindlamalt AI räägib, seda ettevaatlikum peaksite olema; Enesekindel toon ei ole tõend.
- Otsuse delegeerimine tehisintellektile. Tootmise, turvalisuse ja arhitektuuri kasutuselevõtu otsus jääb insenerile; AI toodab ainult materjale.
Kokkuvõttes
AI kiirendab tarkvaratöö korduvaid ja aeganõudvaid osi: skeletikood, testide koostamine, vigade kitsendus, dokumenteerimine. Otsus ja vastutus jääb aga insenerile. Iga väljund peab läbima kolm juhtimiskihti (kompileerimine/staatiline, testimine, allikas). Kontekstiga viipade kirjutamine ja peidetud teabe kustutamine on kaks peamist harjumust, mida kordame selle mooduli igas üksuses. Kui kasutate tehisintellekti distsipliiniga, saate juurde kiirust; kui kasutate seda ilma distsipliinita, kannate vead ja haavatavused tootmisse.
Rakenduse ülesanne
Valige oma tööst või väljamõeldud projektist väike kodeerimisülesanne (nt valideerimisfunktsioon). Esmalt kirjutage nõrk viip ja hankige väljund. Seejärel rakendage selle seadme võimsat viipamustrit: lisage keel/versioon, sisend-väljund leping, piirangud ja testi ootus. Asetage kaks väljatrükki kõrvuti ja kirjutage erinevus. Seejärel koostage robustne väljund ja testige seda vähemalt kolme servajuhtumiga (null, null/negatiivne, ootamatu vorming) ja pange tähele, mida te millises testis leiate.
kontrollnimekiri
- [ ] Lisasin viipale keele, versiooni ja sisend-väljundlepingu.
- [ ] Kirjutasin "Ära mõtle välja, öelge mulle, kui te pole kindel" ja ulatuse piirangu.
- [ ] Kompileerisin/käitsin koodi, kontrollisin staatiliste hoiatuste olemasolu.
- [ ] Testisin vähemalt kolme servaga.
- [ ] Kontrollisin kasutatud API-sid ametlikust dokumentatsioonist.
- [ ] Kustutasin kõik salakoodid/mandaadid või kasutasin ettevõtte tööriista.
- [ ] Kinnitasin, et tootmisse laskmise ja turvalisuse otsus jääb inimese enda teha.