Trecerea testelor furnizate este un obiectiv limitat

O buclă de generare a codului care primește sarcina de a trece un set fix de teste caută o implementare care satisface acele teste. Reușita spune ceva precis despre obiectivul dat. Nu stabilește că testele exprimă comportamentul dorit sau că implementarea este acceptabilă și în afara exemplelor furnizate.

Experimentul demonstrativ publicat de David Winterbottom pe 6 octombrie 2024 arată clar această limită. Testele sunt trimise unui model lingvistic, codul generat este rulat, iar erorile cer o nouă versiune, într-un număr limitat de încercări. Autorul prezintă și un exemplu intenționat contradictoriu care ajunge la o soluție absurdă, dar acceptată de teste. Simon Willison a discutat demonstrația pe 13 octombrie, în săptămâna istorică analizată aici. Articolul retrospectiv din noiembrie 2026 examinează mecanismul, fără concluzii despre productivitatea generală a programatorilor. Experimentul nu a fost reprodus pentru acest articol.

Stabiliți ce are voie să urmărească bucla

Specificația relevantă are cel puțin două părți: comportamentul observabil și restricțiile asupra implementării. Testele pot exprima exemple din prima parte. A doua poate rămâne în mare parte implicită. O funcție care recunoaște câteva intrări din teste poate satisface exemplele fără să implementeze regula pe care un cititor a dedus-o din sarcină.

Această posibilitate nu cere intenție răuvoitoare și nici o teorie despre motivele modelului. Procesul primește o condiție de oprire și informații despre greșeli. Dacă oprirea depinde de trecerea testelor, un program care profită de o omisiune poate îndeplini condiția. Etichetele de ingeniozitate sau necinste adaugă puțin diagnosticului tehnic: regula de acceptare permitea rezultatul.

Înainte de rulare, scrieți comportamentul care trebuie să se păstreze dincolo de exemplele vizibile. Includeți intrările nevalide acolo unde contează și restricțiile privind starea, accesul extern sau cazurile speciale. Dacă cerințele se contrazic, rezolvați contradicția înainte să cereți buclei o cale surprinzătoare de a le satisface.

Exemplul lui Winterbottom este util tocmai fiindcă este extrem în mod deliberat. Arată nepotrivirea dintre verificările furnizate și înțelegerea obișnuită a operațiunii dorite. Nu măsoară o rată reprezentativă de eroare a asistenților de programare și nu dovedește că orice cod generat se va comporta astfel.

Protejați instrumentul de măsurare

Setul fix de teste trebuie să rămână fix pe durata încercării evaluate. Dacă generatorul poate slăbi o verificare, modifica programul de rulare sau înlocui rezultatul așteptat, sensul reușitei s-a schimbat. Protejarea fișierelor de test este necesară, dar examinați și alte moduri în care codul generat ar putea influența mediul de testare.

Limitați modificările permise la un volum care poate fi examinat. Schimbările în încărcarea dependențelor, variabilele de mediu sau pregătirea comună pot modifica testele fără să atingă fișierul lor. Rulați codul numai cu permisiunile necesare sarcinii. Un test trecut nu autorizează folosirea acreditărilor sau accesul la servicii fără legătură cu activitatea.

Înregistrați versiunea examinată și verificările executate. Raportul unei versiuni anterioare nu dovedește acceptarea unei modificări ulterioare. Dacă încercarea nu se încheie sau un instrument se oprește înainte de teste, evaluarea este incompletă. Tratarea lipsei rezultatului ca reușită ar anula scopul verificării obiective.

Limitați numărul încercărilor și resursele folosite. Generarea repetată poate consuma timp fără să lămurească o cerință contradictorie. O regulă utilă de oprire include întoarcerea la persoana care răspunde de specificație. Încercarea nereușită poate astfel arăta o regulă lipsă, în loc să ceară doar o nouă presupunere.

Păstrați dovezi pe care bucla nu le-a văzut

Cazurile nevăzute pot ajuta la deosebirea regulii dorite de simpla potrivire cu exemplele. Pregătiți-le din aceeași specificație înainte să examinați comportamentul programului. Includeți limite relevante pentru sarcină, fără probleme fără legătură adăugate după apariția unui răspuns care nu vă place.

Un set păstrat separat, numit holdout, rămâne nevăzut numai cât timp procesul de generare nu îl poate folosi. După ce erorile sale sunt trimise modelului pentru alte încercări, el devine parte a obiectivului vizibil. Poate ajuta la îmbunătățirea implementării, însă acceptarea ulterioară trebuie să recunoască schimbarea dovezilor. Refolosirea nelimitată a acelorași cazuri nu păstrează independența verificării.

Și aceste cazuri moștenesc limitele specificației. Un al doilea set cu răspunsuri așteptate greșite verifică mai amplu aceeași regulă greșită. Examinarea umană trebuie să stabilească de ce comportamentul așteptat este corect, pe lângă verificarea rezultatului produs de cod. Dacă există o relație care trebuie să rămână valabilă între intrări și rezultate, ea poate completa exemplele fără pretenția unei dovezi exhaustive.

Într-un exemplu de conversie a datelor, acceptarea ar putea cere păstrarea unor câmpuri și respingerea înregistrărilor greșit formate. Un caz vizibil poate arăta structura cerută; cazurile independente pot verifica absența câmpurilor și valorile de la limită. Este un scenariu de evaluare propus, nu cod scris sau testat de AL+. Scopul lui este să arate ce trebuie definit înainte de rularea buclei.

Examinarea codului rămâne necesară

Cel mai puternic contraargument este că transformările mici, definite precis, pot fi potrivite pentru o asemenea buclă. Dacă domeniul este restrâns, comportamentul așteptat este clar și codul se citește ușor, bucla poate fi o metodă rezonabilă de căutare. Un sistem amplu de evaluare pentru fiecare sarcină mică ar risipi efort.

Răspunsul potrivit este acceptarea proporțională cu sarcina. Examinați dacă implementarea exprimă direct regula sau doar reproduce exemplele. Verificați restricțiile pe care testele nu le pot stabili ușor. Pentru o funcție mică fără efecte externe pot ajunge citirea codului și câteva cazuri relevante. O schimbare care atinge date persistente sau permisiuni cere dovezi potrivite consecințelor.

Definiți concret calitatea implementării. Următorul responsabil poate înțelege și modifica regula? Există stare ascunsă care influențează rezultatele? Sunt dependențele justificate? Cerința de „cod curat” este prea vagă pentru a repara un obiectiv care permite comportamentul greșit.

Compararea modelelor urmărește care dintre ele rezolvă mai bine anumite sarcini dintr-un proiect. Aici întrebarea este mai restrânsă: ce certifică exact succesul unei anumite bucle? Pentru o modificare software la comandă, definiți limita acceptării înainte de rulare. Reușita la teste poate fi o dovadă valoroasă când îi este clar domeniul; firma are în continuare nevoie de o decizie justificată că implementarea îndeplinește sarcina dorită.