Otvorite repozitorij šest mjeseci nakon što je funkcionalnost isporučena i možete rekonstruirati mnogo toga. Možete pratiti arhitekturu, pregledati shemu, pročitati testove i vidjeti točno koje su se linije promijenile.
Ono što obično ne možete rekonstruirati jest razgovor zbog kojeg su te linije postale nužne.
Kod vam neće reći da pravilo validacije postoji zato što jedan korisnik šalje neispravne izvoze. Neće objasniti da neobična politika ponovnih pokušaja sprječava duplicirane transakcije u nizvodnom sustavu. Neće pokazati da je čišće sučelje odbačeno nakon testa pristupačnosti ili da granica između servisa odražava ugovorno ograničenje, a ne inženjersku preferenciju.
Git je izvrstan u očuvanju povijesti koda. Namjeru čuva samo kada je tim namjerno zapiše i održi povezanom s implementacijom.
Taj je jaz oduvijek bio dio softverskog inženjerstva. AI alati za kodiranje čine ga vidljivijim. Sustav može pročitati svaku datoteku u repozitoriju, pratiti svaki simbol i generirati tehnički uvjerljiv patch, a da pritom i dalje rješava pogrešan problem.
Problem nije u tome što kod dovodi u zabludu. Kod odgovara na uže pitanje.
Pet slojeva inženjerske istine
Većina smislenih promjena u softveru ovisi o pet različitih slojeva dokaza.
- Namjera — Koji ishod traži korisnik, klijent ili poslovanje? To može biti zapisano u specifikaciji, ticketu, razgovoru s podrškom ili bilješci sa sastanka.
- Ograničenja — Što se ne smije pokvariti? Obećanja kompatibilnosti, sigurnosne granice, regulative, ugovori, budžeti i rokovi često se nalaze izvan repozitorija.
- Implementacija — Kako sustav danas radi? Kod, testovi, sheme, ovisnosti i konfiguracija implementacije pružaju ovaj sloj.
- Dokazi iz rada sustava — Što se događa u stvarnom sustavu? Logovi, traceovi, metrike, produkcijski podaci i izvještaji o incidentima mogu proturječiti pretpostavkama koje u kodu izgledaju razumno.
- Povijest odluka — Zašto je odabran trenutačni pristup? Pull requestovi, rasprave o dizajnu, odbačene alternative i prethodni incidenti sadrže odgovor.
Repozitorij je najsnažniji u trećem sloju. Sadrži dijelove ostalih, ali rijetko dovoljno da ih u potpunosti predstavi.
To je važno zato što se kvarovi u softveru često pojavljuju na granicama između slojeva. Implementacija odgovara zastarjeloj specifikaciji. Ispravak zadovoljava ticket, ali krši operativno ograničenje. Testovi prolaze zato što kodiraju jučerašnje pretpostavke. Kod je interno dosljedan, dok produkcijski podaci slijede obrazac koji nitko nije dokumentirao.
Lokalno ispravan patch i dalje može biti pogrešna promjena.
Na što repozitorij sam po sebi ne može odgovoriti
Zamislite korisnika koji uredi dokument, a zatim pretraži ažuriranu rečenicu, ali u rezultatima i dalje vidi staru verziju. „Neka se pretraživanje ažurira odmah” zvuči kao jasan zahtjev. Repozitorij otkriva nekoliko mogućih mjesta od kojih se može krenuti, ali sam po sebi ne može odrediti ispravno rješenje.
| Pitanje | Vjerojatan izvor |
|---|---|
| Koja je verzija dokumenta mjerodavna? | Izvorni dokument i povijest revizija |
| Gdje se stari tekst još zadržava? | Sinkronizacijski zapisnici, izlaz ekstrakcije, indeks pretraživanja ili predmemorija |
| Što „odmah” znači za ovaj proizvod? | Obećanje proizvoda ili cilj razine usluge |
| Jesu li se dozvole dokumenta promijenile zajedno s njegovim sadržajem? | Izvorne dozvole i povijest revizije |
| Je li zastarjeli rezultat ograničen na jednog korisnika, izvor ili regiju? | Tragovi zahtjeva i produkcijske metrike |
Kod za pretraživanje može objasniti kako se rezultati vraćaju. Ne može vam reći je li stvarni problem kašnjenje sinkronizacije, zastarjela ekstrakcija, poništavanje predmemorije, propagacija dozvola ili očekivanje koje proizvod nikada nije definirao.
Ta razlika postaje još važnija u zrelim sustavima. Polje koje izgleda zastarjelo možda i dalje podržava naslijeđenog klijenta. Servis koji izgleda kao duplikat možda razdvaja podatke s različitim zahtjevima za dozvole. Provjera koja se naizgled čini pretjeranom možda je jedini trag u kodu o produkcijskom incidentu koji trenutačni tim nikada nije vidio.
Uklanjanje složenosti je vrijedno. Uklanjanje povijesti prerušene u složenost skupo je.
Više konteksta i dalje može dovesti do pogrešnog odgovora
Očito rješenje jest dati AI-ju više materijala: cijeli repozitorij, svaki ticket, svaki dokument, svaku poruku i svaki zapisnik.
To stvara pristup, a ne razumijevanje.
Izvori mogu biti zastarjeli, proturječni, spekulativni ili pisani za različite publike. Brainstorming ne bi smio imati veću težinu od odobrene specifikacije. Zahtjev star šest mjeseci ne bi smio tiho nadjačati jučerašnju odluku o proizvodu. Produkcijski zapisnik treba biti povezan s izdanjem, okruženjem i putanjom koda koji su ga proizveli. Zahtjev korisnika ne bi se smio tretirati kao univerzalan zahtjev bez provjere opsega.
Ozbiljan sustav konteksta zato treba više od samog dohvaćanja. Treba način za promišljanje o sljedećem:
- Mjerodavnost: Koji izvor smije definirati zahtjev?
- Aktualnost: Koja je informacija trenutačna i što je u međuvremenu zamijenjeno?
- Podrijetlo: Odakle potječe svaka tvrdnja, ograničenje ili zaključak?
- Odnosi: Koji issue, izdanje, korisnik, skup podataka i putanja koda pripadaju zajedno?
- Dozvole: Koji se izvori smiju koristiti za ovaj zadatak i prikazati ovoj osobi?
Kontekst nije hrpa tokena. To je graf s vremenom, mjerodavnošću i granicama.
Više konteksta trebalo bi proizvesti više dokaza, a ne više samopouzdanja bez dokaza.
Stvarna jedinica rada je promjena
Uređivači i alati za kodiranje organizirani su oko datoteka jer su datoteke ono što mijenjamo. Inženjerski timovi organizirani su oko promjena.
Promjena počinje razlogom. Postaje zahtjev, dotiče kod i podatke, prolazi kroz pregled, dolazi u produkciju i stvara nove dokaze. Ako te faze ostanu nepovezane, svaki budući zadatak počinje novim krugom arheologije.
AI sustav koji radi na stvarnom softveru trebao bi pratiti taj životni ciklus.
Prije implementacije, trebao bi prepoznati zahtjev, relevantna ograničenja i sve proturječne izvore. Trebao bi znati ispravlja li kvar, mijenja očekivano ponašanje ili uvodi novi ugovor.
Tijekom implementacije, trebao bi povezati svaki smisleni izbor s dokazima. Zašto ovaj modul? Zašto ova strategija migracije? Zašto zadržati ovu granu? Objašnjenje bi trebalo nadživjeti chat u kojem je kod nastao.
Nakon implementacije, uz promjenu bi trebao priložiti rezultate provjere, odluke donesene tijekom pregleda i novootkrivena ograničenja. U suprotnom će ih sljedeća osoba — ili sljedeća AI sesija — morati ponovno otkrivati.
To je razlika između alata koji može uređivati repozitorij i sustava koji može sudjelovati u inženjerskom radu.
AI bi trebao smanjiti potrebu za rekonstrukcijom, a ne ukloniti prosudbu
Bolji kontekst ponekad se prikazuje kao put prema autonomnom razvoju softvera. Njegova neposredna vrijednost manje je dramatična, ali korisnija: smanjenje troška rekonstrukcije stvarnog stanja prije nego što se napravi promjena.
AI može dovesti izvorni zahtjev uz relevantan kod. Može iznijeti na vidjelo incident koji objašnjava neuobičajenu zaštitnu mjeru. Može povezati metriku koja podbacuje s izdanjem koje ju je promijenilo. Može pokazati da se dva autoritativna izvora ne slažu prije nego što implementacija uopće počne.
Te mogućnosti ne uklanjaju inženjersku prosudbu. One je čine bolje informiranom.
Osoba i dalje mora odlučiti koji je kompromis prihvatljiv, je li zahtjev potpun i koliki rizik izdanje može nositi. Sustav bi trebao učiniti dokaze vidljivima, a zaključivanje provjerljivim. Ne bi smio skrivati neizvjesnost iza uglađene zakrpe.
Mjerilo nije „može li generirati kod?”
Mjerilo je „može li objasniti zašto je ovo sada prava promjena?”
Od svijesti o repozitoriju do svijesti o radu
Asistenti za kodiranje prvi su put postali korisni kada su razumjeli datoteku pred developerom. Svijest o repozitoriju bila je sljedeći veliki korak: pronalaženje povezanog koda, praćenje simbola i primjena promjena kroz cijeli projekt.
Sljedeći je korak svijest o radu oko repozitorija.
To znači povezati kod sa specifikacijom koja ga je zatražila, razgovorom koji ga je razjasnio, produkcijskim dokazima koji su ga doveli u pitanje i odlukom koju bi poslije trebalo zapamtiti. To također znači isključiti kontekst koji je nerelevantan, zastario ili izvan korisnikovih ovlasti.
Dok gradimo Dvina, to je jedna od ideja kojoj se stalno vraćamo. Rad se ne odvija unutar jedne datoteke, aplikacije ili razgovora. Značenje živi u vezama među njima i u tome kako se te veze mijenjaju tijekom vremena.
Repozitorij ostaje ključan. On je izvršni izvor istine o ponašanju sustava. Jednostavno nije potpun izvor istine o namjeri proizvoda, operativnoj stvarnosti ili organizacijskom pamćenju.
Cijela priča mijenja ono što se gradi
Kad imate samo kod, prirodno je pitanje:
Koja promjena odgovara ovom sustavu?
Uz širi kontekst, pitanje postaje:
Koja promjena odgovara ovom sustavu, ovom zahtjevu, ovoj povijesti i ovom trenutku?
To drugo pitanje otkriva ograničenja prije nego što se pretvore u regresije. Recenzentima daje obrazloženje implementacije. Pomaže novim članovima tima razumjeti zašto sustav izgleda upravo tako. AI-ju daje utemeljenu ulogu: ne kao proročištu unutar editora, nego kao sudioniku koji može povezati dokaze kroz cijeli rad.
Vaš repozitorij nikada nije bio cijela priča.
Prilika je u tome da izgradimo sustave koji mogu pročitati i sve ostalo — i pokazati svoj rad.
