Deschide un repository la șase luni după lansarea unei funcționalități și poți reconstrui multe. Poți urmări arhitectura, inspecta schema, citi testele și vedea exact ce linii s-au schimbat.
Ceea ce, de obicei, nu poți reconstrui este conversația care a făcut necesare acele linii.
Codul nu îți va spune că există o regulă de validare pentru că un client trimite exporturi malformate. Nu îți va explica faptul că o politică neobișnuită de reîncercare previne tranzacțiile duplicate într-un sistem downstream. Nu îți va arăta că interfața mai curată a fost respinsă după un test de accesibilitate sau că o graniță între servicii reflectă o restricție contractuală, nu o preferință de inginerie.
Git este excelent la păstrarea istoricului codului. Păstrează intenția doar atunci când o echipă o notează în mod deliberat și o menține conectată la implementare.
Acest decalaj a făcut întotdeauna parte din ingineria software. Instrumentele AI pentru programare îl fac mai vizibil. Un sistem poate citi fiecare fișier dintr-un repository, poate urmări fiecare simbol și poate genera un patch convingător din punct de vedere tehnic, rezolvând totuși problema greșită.
Problema nu este că acest cod induce în eroare. Codul răspunde la o întrebare mai îngustă.
Cinci straturi ale adevărului în inginerie
Cele mai importante schimbări software depind de cinci straturi diferite de dovezi.
- Intenție — Ce rezultat cere utilizatorul, clientul sau businessul? Acesta poate exista într-o specificație, un tichet, o conversație cu suportul sau o notă de ședință.
- Constrângeri — Ce nu trebuie să se strice? Promisiunile de compatibilitate, granițele de securitate, reglementările, contractele, bugetele și termenele-limită se află adesea în afara repository-ului.
- Implementare — Cum funcționează sistemul astăzi? Codul, testele, schemele, dependențele și configurația de deployment oferă acest strat.
- Dovezi din runtime — Ce se întâmplă în sistemul real? Logurile, trace-urile, metricile, datele din producție și rapoartele de incidente pot contrazice presupuneri care par rezonabile în cod.
- Istoricul deciziilor — De ce a fost aleasă abordarea actuală? Pull request-urile, discuțiile de design, alternativele respinse și incidentele anterioare conțin răspunsul.
Repository-ul este cel mai puternic în al treilea strat. Conține părți din celelalte, dar rareori suficient cât să le reprezinte complet.
Acest lucru contează pentru că eșecurile software apar adesea la granițele dintre straturi. Implementarea corespunde unei specificații depășite. Remedierea satisface tichetul, dar încalcă o constrângere operațională. Testele trec pentru că ele codifică presupunerile de ieri. Codul este consecvent în interiorul său, în timp ce datele din producție urmează un tipar pe care nimeni nu l-a documentat.
Un patch corect la nivel local poate fi totuși schimbarea greșită.
La ce nu poate răspunde singur repository-ul
Imaginați-vă un utilizator care editează un document, apoi caută propoziția actualizată, doar ca în rezultate să vadă versiunea veche. „Faceți ca căutarea să se actualizeze imediat” pare o cerință clară. Repository-ul dezvăluie mai multe puncte posibile de pornire, dar nu poate defini singur soluția corectă.
| Întrebare | Sursă probabilă |
|---|---|
| Care versiune a documentului este cea de referință? | Documentul sursă și istoricul reviziilor |
| Unde mai persistă textul vechi? | Loguri de sincronizare, output-ul extragerii, indexul de căutare sau cache-ul |
| Ce înseamnă „imediat” pentru acest produs? | Promisiunea produsului sau obiectivul de serviciu |
| S-au schimbat permisiunile documentului odată cu conținutul? | Permisiunile sursei și istoricul de audit |
| Rezultatul învechit este limitat la un singur utilizator, o singură sursă sau o singură regiune? | Urmele cererilor și metricile din producție |
Codul de căutare poate explica modul în care sunt returnate rezultatele. Nu vă poate spune dacă defectul real este o întârziere de sincronizare, o extragere învechită, invalidarea cache-ului, propagarea permisiunilor sau o așteptare pe care produsul nu a definit-o niciodată.
Această distincție devine și mai importantă în sistemele mature. Un câmp care pare învechit poate deservi în continuare un client legacy. Un serviciu care pare duplicat poate separa date cu cerințe diferite de permisiuni. O verificare aparent excesivă poate fi singura urmă la nivel de cod a unui incident din producție pe care echipa actuală nu l-a văzut niciodată.
Eliminarea complexității este valoroasă. Eliminarea istoriei deghizate în complexitate este costisitoare.
Mai mult context poate duce totuși la răspunsul greșit
Soluția evidentă este să îi oferi AI-ului mai mult material: întregul repository, fiecare tichet, fiecare document, fiecare mesaj și fiecare log.
Asta creează acces, nu înțelegere.
Sursele pot fi învechite, contradictorii, speculative sau scrise pentru audiențe diferite. O sesiune de brainstorming nu ar trebui să aibă prioritate față de o specificație aprobată. O cerință veche de șase luni nu ar trebui să anuleze în tăcere decizia de produs de ieri. Un log din producție ar trebui corelat cu release-ul, mediul și traseul de cod care l-au generat. O solicitare a unui client nu ar trebui tratată ca o cerință universală fără a-i verifica domeniul de aplicare.
Prin urmare, un sistem de context serios are nevoie de mai mult decât retrieval. Are nevoie de o modalitate de a raționa despre:
- Autoritate: Cărei surse îi este permis să definească cerința?
- Actualitate: Ce informație este curentă și ce a fost înlocuit?
- Proveniență: De unde provine fiecare afirmație, constrângere sau concluzie?
- Relații: Ce problemă, release, client, set de date și traseu de cod aparțin împreună?
- Permisiuni: Ce surse pot fi folosite pentru această sarcină și arătate acestei persoane?
Contextul nu este o grămadă de tokeni. Este un graf cu timp, autoritate și limite.
Mai mult context ar trebui să producă mai multe dovezi, nu mai multă încredere fără dovezi.
Unitatea reală de lucru este schimbarea
Editorii și instrumentele de programare sunt organizate în jurul fișierelor, pentru că fișierele sunt ceea ce modificăm. Echipele de inginerie sunt organizate în jurul schimbărilor.
O schimbare începe cu un motiv. Devine o cerință, atinge codul și datele, trece prin review, ajunge în producție și creează noi dovezi. Dacă aceste etape rămân deconectate, fiecare sarcină viitoare începe cu încă o rundă de arheologie.
Un sistem AI care lucrează pe software real ar trebui să urmeze acest ciclu de viață.
Înainte de implementare, ar trebui să identifice cererea, constrângerile relevante și orice surse aflate în conflict. Ar trebui să știe dacă repară un defect, schimbă comportamentul așteptat sau introduce un nou contract.
În timpul implementării, ar trebui să conecteze fiecare alegere semnificativă la dovezi. De ce acest modul? De ce această strategie de migrare? De ce să fie păstrată această ramură? Explicația ar trebui să supraviețuiască dincolo de conversația care a produs codul.
După implementare, ar trebui să atașeze la schimbare rezultatele verificării, deciziile de revizuire și constrângerile nou descoperite. Altfel, următoarea persoană — sau următoarea sesiune AI — va trebui să le redescopere.
Aceasta este diferența dintre un instrument care poate edita un repository și un sistem care poate participa la activitatea de inginerie.
AI ar trebui să reducă reconstrucția, nu să elimine discernământul
Un context mai bun este uneori prezentat ca o cale către dezvoltarea autonomă de software. Valoarea imediată este mai puțin spectaculoasă și mai utilă: reducerea costului de a reconstrui realitatea înainte de a face o schimbare.
AI poate aduce cerința inițială lângă codul relevant. Poate scoate la iveală incidentul care explică o măsură de protecție neobișnuită. Poate lega un indicator aflat în degradare de lansarea care l-a schimbat. Poate arăta că două surse autoritare sunt în dezacord înainte să înceapă implementarea.
Aceste capabilități nu elimină discernământul inginereasc. Îl fac mai bine informat.
O persoană tot trebuie să decidă ce compromis este acceptabil, dacă o cerință este completă și cât risc poate suporta o lansare. Sistemul ar trebui să facă dovezile vizibile și raționamentul inspectabil. Nu ar trebui să ascundă incertitudinea în spatele unui patch bine finisat.
Standardul nu este „poate genera cod?”
Standardul este „poate explica de ce aceasta este schimbarea potrivită acum?”
De la conștientizarea repository-ului la conștientizarea muncii
Asistenții de programare au devenit utili mai întâi prin faptul că înțelegeau fișierul din fața dezvoltatorului. Conștientizarea repository-ului a fost următorul pas major: găsirea codului înrudit, urmărirea simbolurilor și aplicarea schimbărilor la nivelul întregului proiect.
Următorul pas este conștientizarea muncii din jurul repository-ului.
Asta înseamnă conectarea codului la specificația care l-a cerut, la conversația care l-a clarificat, la dovezile din producție care l-au pus sub semnul întrebării și la decizia care ar trebui reținută după aceea. Înseamnă, de asemenea, excluderea contextului care este irelevant, depășit sau în afara permisiunilor utilizatorului.
În timp ce construim Dvina, aceasta este una dintre ideile la care revenim mereu. Munca nu se desfășoară într-un singur fișier, o singură aplicație sau o singură conversație. Sensul trăiește în conexiunile dintre ele și în felul în care aceste conexiuni se schimbă în timp.
Repository-ul rămâne esențial. Este sursa executabilă de adevăr pentru comportamentul sistemului. Pur și simplu nu este sursa completă de adevăr pentru intenția produsului, realitatea operațională sau memoria organizațională.
Întreaga poveste schimbă ceea ce se construiește
Având doar codul, întrebarea firească este:
Ce schimbare se potrivește acestui sistem?
Cu contextul mai larg, întrebarea devine:
Ce schimbare se potrivește acestui sistem, acestei cerințe, acestui istoric și acestui moment?
Acea a doua întrebare surprinde constrângerile înainte ca ele să se transforme în regresii. Le oferă reviewerilor raționamentul din spatele implementării. Îi ajută pe noii membri ai echipei să înțeleagă de ce sistemul arată așa cum arată. Îi oferă AI-ului un rol bine ancorat: nu un oracol în editor, ci un participant care poate reuni dovezi din întregul proces de lucru.
Repo-ul tău nu a fost niciodată întreaga poveste.
Oportunitatea este să construim sisteme care pot citi și restul ei — și să-și arate munca.
