Câștiguri:
- Capacitatea de a distinge unde AI oferă viteză reală în ciclul de viață al dezvoltării software și unde decizia și responsabilitatea rămân în sarcina inginerului
- Abilitatea de a aplica o disciplină de inginerie cu trei straturi care verifică fiecare cod și design produs prin compilare, testare și revizuire.
- Obișnuiți-vă să curățați contextul pentru a utiliza inteligența artificială fără a partaja codul sursă confidențial, acreditările și datele clienților
Când te uiți la ziua unui inginer informatic, imaginea este similară în majoritatea echipelor: înțelegerea unei cereri de afaceri, proiectarea, scrierea codului, citirea codului altcuiva, depanarea (procesul de a afla de ce un program funcționează incorect și de a-l remedia), scrierea de teste, pregătirea documentației, revizuirea codului și participarea la întâlniri. Cu alte cuvinte, timpul dedicat adevăratei „judecăți inginerești”, adică dacă o soluție este corectă, sigură și durabilă, este strivit sub munca repetitivă. Aici intervine inteligența artificială (AI pe scurt; software care funcționează pe text și cod cu un model de limbaj mare). AI nu ia decizia pentru tine; Te pregătește pentru decizie, produce un schelet de cod, restrânge bug-ul și pune în fața ta o ciornă lucrată. Pe parcursul acestui modul, vom poziționa AI nu ca un „programator automat”, ci ca un partener disciplinat de programare a perechii a cărui rezultate este compilată, testată și revizuită de fiecare dată.
În această primă unitate, clarificăm trei lucruri: în ce etape ale ciclului de viață al dezvoltării software (etapele prin care trece un software de la idee la producție: analiză, proiectare, codificare, testare, implementare, întreținere) adaugă AI valoare reală; care decizii ar trebui să rămână strict la inginer; și care este disciplina de verificare și confidențialitate la care trebuie să aderați atunci când faceți acest lucru. Fără acest acoperiș instalat corect, tehnicile de pe unitățile ulterioare pot deveni periculoase; Pentru că o eroare în software ajunge la milioane de utilizatori în același timp și se poate transforma într-o vulnerabilitate de securitate.
Concepte: Halucinații: fabricarea convingătoare de către AI a unei metode, biblioteci, API sau comportament care nu există de fapt. Context: Intrarea pe care o dați AI (cod, mesaj de eroare, cerință, constrângeri). Verificare: Verificarea rezultatelor într-un mod independent (compilare, testare, documentare). Aceste trei concepte sunt coloana vertebrală a întregului modul.
În ce afaceri este AI Accelerator, în ce afaceri este riscant?
Joburile de software se încadrează pe un spectru dublu în ceea ce privește rezultatele. La un capăt sunt lucrări de pregătire reversibile, cu risc scăzut; La celălalt capăt, există sarcini greu de returnat care intră în mediul de producție și pot cauza pierderi de date, vulnerabilități de securitate sau întreruperi. Valoarea AI variază în funcție de locul în care vă aflați pe acest spectru.
tipul afacerii
Contribuția AI
Rolul inginerului
Cod schelet / boilerplate
Generarea rapidă a structurii repetitive
Control logic și starea marginilor
depanare
Ipoteza și lista cauzelor posibile
Reproducerea și confirmarea cauzei principale
teste de scriere
Testați schița și crearea scenariului
Afirmarea semnificativă și verificarea domeniului de aplicare
refactorizarea
Propunere de refactorizare
Menținerea comportamentului prin testare
Documentare
Prima schiță și structură
Verificarea corectitudinii față de cod
Decizie de arhitectură/securitate
Lista de opțiuni și argumente pro și contra
Decizie finală și responsabilitate
Regula este simplă: riscul unei ieșiri AI este egal cu daunele pe care le va suferi dacă acea ieșire face o eroare. Sugerarea incorectă a unui nume de variabilă este inofensivă; Autentificarea necorespunzătoare (verificarea faptului că utilizatorul este într-adevăr cine pretinde că este) face întregul sistem vulnerabil. Deci, prima întrebare pe care trebuie să o puneți înainte de a utiliza rezultatul este: „Ce se întâmplă dacă acest lucru este greșit și cine îl observă și când?”
Atenție: AI produce cod fluent și sigur. Fluența nu este o garanție a acurateții. Un model de limbaj poate produce în mod credibil un nume de funcție care nu există de fapt, o secvență de parametri incorectă sau chiar un model nesigur. În software, acest lucru nu rămâne pe hârtie; Compilează, rulează și explodează în producție.
Decizii care ar trebui lăsate la latitudinea inginerului
Unele decizii nu ar trebui niciodată să fie complet automatizate; prezintă riscuri tehnice, legale și etice:
- Aprobare pentru producție: lansarea unui cod în producție și responsabilitatea pentru aceasta.
- Securitate și arhitectură: decizii costisitoare, cum ar fi autentificarea, autorizarea, criptarea și modelul de date.
- Licență și drepturi de autor: Utilizabilitatea codului produs în produsul comercial și conformitatea cu licența.
- Lucrul cu date confidențiale: Tranzacții cu date despre clienți, secrete ale codului sursă și informații de identitate.
Avertisment: Chiar dacă AI spune „acest cod este sigur și gata pentru producție”, acceptarea acestui lucru fără testare de securitate, revizuirea codului și validarea sub încărcare reală este inacceptabilă. În munca critică pentru siguranță, ieșirea AI nu înlocuiește niciodată aprobarea unui inginer competent; Orice rezultat care conduce la o decizie trebuie să fie verificată și aprobată în mod independent de către inginerul autorizat înainte de implementare.
Disciplina de verificare: Control pe trei straturi
Aplicați trei straturi de control pentru a utiliza ieșirea AI ca un evaluator senior, mai degrabă decât orbește. Acesta este reflexul de bază pe care îl vom repeta pe tot parcursul modulului.
- Compilare și verificare statică: se compilează/se rulează codul? Există erori de tip, variabile neutilizate, API-uri inexistente? Ce spune instrumentul de analiză statică (instrumentul care examinează codul fără a-l rula)?
- Reproducere independentă (testare): Rulați codul cu intrări mici și cunoscute și vedeți dacă obțineți rezultatul așteptat. Încercați cazuri de margine (null, zero, negative, uge).
- Verificarea sursei: fiecare API, versiune de bibliotecă și caracteristică de limbă pe care AI le folosește ar trebui verificate din documentația oficială.
Solicitare de verificare (ușoară verificarea rezultatului): „Enumerați TOATE bibliotecile externe, metodele și caracteristicile de limbă pe care le utilizați în codul dvs.. Pentru fiecare dintre ele, indicați în ce versiune este disponibilă și etichetați-o „trebuie verificată din documentație”. Nu creați niciun API de care nu sunteți sigur; dacă nu sunteți sigur, scrieți clar „nu sunteți sigur”.
Criticați-vă propriul prompt de cod: „Uită-te critic la codul pe care tocmai l-ai scris, ca un inginer senior care te-a angajat. Dați elemente concrete sub aceste trei titluri: (1) erori logice/cazuri marginale, (2) riscuri de securitate, (3) probleme de performanță sau de lizibilitate. Pentru fiecare articol, scrieți „de ce este problema” și „remedierea sugerată”. ea.”
Solicitare slabă / Solicitare puternică
WEAK: „Scrieți-mi o funcție de autentificare a utilizatorului.” (Rezultat: neclar ce limbă, ce regulă, ce comportament de eroare; cod generic, adesea nesigur sau în afara contextului.) STRONG: „Scrieți o funcție de validare a e-mailului pentru Python 3.11. Intrare: șir. Ieșire: Adevărat dacă este valid, Fals în caz contrar. Reguli: Făcut; nu este suficient formatul RFC. UTILIZAȚI bibliotecă externă Un test cu 5 eșantioane sub blocul de anexare a funcției: valid, gol, fără „@”, dublu „@”, care conține doar spații.”
Diferența este în context. prompt puternic; Include limba, versiunea, contractul de intrare-ieșire, constrângeri și așteptările de testare. Această disciplină unică reduce foarte mult riscul de halucinații și cod nesigur.
Mini Carcase
Cazul 1 — Metoda artificială. Un dezvoltator aude de la AI că există o metodă numită date.addBusinessDays(5) într-o bibliotecă de date și este explicată într-un mod sigur. Privind documentația, el vede că nu există o astfel de metodă, modalitatea corectă este o buclă manuală. Halucinația este capturată înainte de a intra în producție cu o verificare de 10 minute.
Cazul 2 — Pierderea stării marginii. AI produce o funcție de „calculare medie”; Funcționează atunci când este testat cu 1.000 de rânduri de date. Cu toate acestea, când lista este goală, dă o eroare de împărțire la zero. Deoarece inginerul a adăugat testul de intrare gol, el vede și remediază eroarea înainte ca aceasta să fie activă. Un test de condiție cu o singură margine previne o alarmă de producție la ora 3 dimineața.
Cazul 3 – Risc de confidențialitate. Un expert este pe cale să lipească un fișier cu un șir real de conexiune la baza de date și o cheie API într-un instrument public. Își amintește politica instituției; Înlocuiește secretele cu <REDACTATE>, reduce codul la un exemplu reprezentativ și îl solicită. Astfel, primește ajutor în 5 minute, dar informațiile sale de identitate nu îi ies la iveală.
Principiul lucrului cu cod secret și informații de identitate
Cea mai sensibilă parte a software-ului; secrete codului sursă, informații de identitate (cheie API, parolă, token) și date despre clienți/personale. Principiu de bază: curățați înainte de a partaja, întrebați doar esența problemei cu un exemplu reprezentativ dacă este posibil.
Model de prompt anonimizat: „Există o eroare în următoarea funcție. Am înlocuit logica comercială reală și constantele ascunse cu valori reprezentative (cheie API, nume de tabel, nume de câmpuri generice). Problemă: Primesc eroarea Y în intrarea X. Găsiți doar eroarea logică în acest cod reprezentativ și explicați versiunea corectată. [codul reprezentativ]"
Sfat: Dacă aveți îndoieli, faceți acest test: „Organizația mea ar avea probleme dacă aș scrie asta public pe un forum?” Chiar dacă răspunsul este neclar, clarificați-l mai întâi. Resetarea este întotdeauna mai ieftină decât urmărirea scurgerii mai târziu.
Greșeli comune
- Folosind rezultatul fără compilare/testare. „AI a scris” nu este o justificare; Fiecare bucată de cod este verificată prin rularea acesteia.
- Efectuarea de cereri fără context. Dacă limba, versiunea, intrare-ieșire și constrângeri nu sunt date, codul devine generic și adesea nesigur.
- Partajarea de informații confidențiale fără a sta pe gânduri. Cheia API, parola și datele clienților nu ar trebui să fie eliberate fără a fi șterse.
- Confundând limbajul precis cu acuratețea. Cu cât AI vorbește mai încrezător, cu atât ar trebui să fii mai atent; Tonul încrezător nu este o dovadă.
- Delegarea deciziei către AI. Decizia de a pune în producție, securitate și arhitectură îi revine inginerului; AI produce doar materiale.
Pe scurt
AI accelerează părțile repetitive și consumatoare de timp ale muncii software: codul scheletului, redactarea testului, restrângerea erorilor, documentația. Cu toate acestea, decizia și responsabilitatea îi revin inginerului. Fiecare ieșire trebuie să treacă trei straturi de control (compilare/statică, testare, sursă). Scrierea prompturilor cu context și curățarea informațiilor ascunse sunt două obiceiuri cheie pe care le vom repeta în fiecare unitate a acestui modul. Când folosești AI cu disciplină, câștigi viteză; când îl folosiți fără disciplină, transportați erori și vulnerabilități în producție.
Sarcina de aplicare
Alegeți o mică sarcină de codificare din propria muncă sau dintr-un proiect imaginar (de exemplu, o funcție de validare). Mai întâi scrieți un prompt slab și obțineți rezultatul. Apoi aplicați modelul de prompt puternic de la această unitate: adăugați limba/versiunea, contractul de intrare-ieșire, constrângeri și așteptările de testare. Puneți cele două imprimări una lângă alta și scrieți diferența. Apoi compilați rezultatul robust și testați-l cu cel puțin trei cazuri marginale (null, zero/negativ, format neașteptat) și notați ce găsiți în ce test.
lista de verificare
- [ ] Am adăugat limbă, versiune și contract de intrare-ieșire la prompt.
- [ ] Am scris „Nu te inventa, spune-mi dacă nu ești sigur” și constrângerea domeniului.
- [ ] Am compilat/rulat codul, am verificat pentru avertismente statice.
- [ ] Am testat cu cel puțin trei carcase marginale.
- [ ] Am verificat API-urile utilizate din documentația oficială.
- [ ] Am șters orice cod/acreditări secrete sau am folosit instrument de întreprindere.
- [ ] Am confirmat că decizia de a pune în producție și de securitate rămâne a omului.