Pitajte tim šta bi poneo iz zgrade koja gori i sedamdeset godina je odgovor bio isti — izvorni kod. Izgubiti ga značilo je izgubiti sve nakupljene odluke kompanije, hiljade sitnih procena zbog kojih sistem pristaje uz posao. Taj odgovor se tiho menja. Kada agenti mogu da regenerišu ispravnu implementaciju iz preciznog iskaza o tome šta sistem mora da radi, kod prestaje da bude porodično srebro. Iskaz to postaje. Praksu koja sledi kada ovo shvatite ozbiljno zovemo intent-driven development: disciplinu u kojoj namera — a ne kod — postaje artefakt koji vaš tim piše, revidira, verzioniše i poseduje.
Tvrdnja iz naslova traži trenutnu ogradu. “Pisanje koda postaje opcija” ne znači da niko ne čita kod, niti da generisani kod nije važan, niti da je inženjerska veština zastarela. Znači nešto uže i zanimljivije: za sve širu klasu poslova, ručno kucanje implementacije je sada izbor, a ne nužnost — i timovi bi trebalo svesno da odluče gde taj izbor i dalje prave, umesto da ga po navici prave svuda.
Namera nije stvar osećaja
Reč “namera” poziva na zloupotrebu. Zvuči kao nešto što se zadovoljava izjavom o misiji i jednim mood board-om. U praksi, namera koja može da vodi razvoj jeste skup proverljivih tvrdnji o ponašanju — tvrdnji koje mašina ili kolega mogu da provere nad sistemom i odgovore prolazi ili pada. “Kupci treba da imaju gladak checkout” je osećaj. “Kupac koji se vraća završava checkout u tri koraka; neuspela naplata čuva korpu i objašnjava grešku na jeziku kupca; dvostruka naplata nije moguća čak ni ako se dugme za potvrdu klikne dvaput” jeste namera. Razlika je u proverljivosti, i ta razlika je zapravo sve.
Namera se slaže u tri sloja. Na vrhu je namera proizvoda: koji ishod sistem postoji da proizvede, za koga i mereno čime. Ispod nje žive invarijante sistema: svojstva koja moraju da važe bez obzira na implementaciju — novac se ne gubi, audit trag se samo dopisuje, lični podaci ostaju unutar granice, brisanja su povratna. Na dnu su testovi prihvatanja i evali: izvršni oblik, sloj koji pipeline zaista može da pokrene. Svaki sloj opravdava onaj ispod sebe; svaki sloj ispod čini onaj iznad proverljivim. Tim koji održava sva tri može da preda implementaciju agentu onako kako investitor predaje gradnju izvođaču — po projektu, a ne po pridevima.
Ako vam to zvuči kao bliski rođak pisanja ugovora za AI agente, i jeste. Spec-driven development je disciplina na nivou zadatka: jedan posao, jedan ugovor, jedna petlja verifikacije. Intent-driven development je ono što kodna baza postane kada se ta disciplina akumulira — kada nakupljeni ugovori, invarijante i evali postanu stvarni opis sistema, a svaka konkretna implementacija samo njegova trenutna kompilacija.
Kod kao rezultat build-a
Praktična posledica je pomak u tome šta znači “izvor”. U kompajliranom jeziku niko ne krpi binarni fajl; menja se izvor i radi rebuild. Intent-driven timovi počinju da tretiraju implementacioni kod na isti način: kada ponašanje mora da se promeni, prva izmena sleće u sloj namere — novi test prihvatanja, promenjena invarijanta, izoštrena tvrdnja o proizvodu — a implementacija se regeneriše ili prerađuje da bi je zadovoljila. Kod ostaje čitljiv, revidiran i noseći. Menja se njegov status: on je izveden, a ono iz čega je izveden je ono oko čega se raspravljate.
I revizija u skladu s tim menja metu. Čitati tri hiljade generisanih linija brzinom čitanja je predstava; recenzent odobrava ono što zapravo ne može da drži u glavi. Revizija diff-a namere je izvodljiva: koje novo ponašanje je obećano, koje invarijante su dirnute, da li novi testovi zaista prikivaju to obećanje i ima li u diff-u implementacije ičega što namera ne objašnjava? Pažnja senior inženjera se pomera nivo naviše — sa “da li je ova petlja ispravna” na “da li je ovo pravo obećanje i da li se sprovodi”. To nije degradacija inženjerske procene. To je inženjerska procena primenjena tamo gde se sada najviše isplati.
Kod je izveden. Namera je izvor. Timovi koji raspravljaju o izvoru isporučuju brže od timova koji raspravljaju o kompilaciji.
Gde ručno pisan kod i dalje pobeđuje
Poštenje oko granice čuva ovo od pretvaranja u ideologiju. Neki kod i dalje treba pisati rukom, i kategorije su dosledne. Vrelo jezgro — mehanizam za cene, algoritam za uparivanje, model rizika — gde svaka grana otelotvoruje poslovnu odluku i gde je razumevanje tog koda samo po sebi vrednost. Nov algoritamski rad, gde nameru nije moguće iskazati preciznije od implementacije, jer je otkrivanje implementacije upravo taj posao. Granice kritične po bezbednost — autentikacija, kriptografija, iniciranje plaćanja — gde dubina revizije znači više od brzine izrade i gde želite ljudski potpis na svakoj liniji. I sam sloj namere: testovi, invarijante, evali i šeme zaslužuju ljudsko autorstvo upravo zato što se sve ostalo proverava prema njima.
Korisno pitanje za bilo koji posao nije “može li agent ovo da napiše?” — sve češće može — nego “šta gubimo ako to ne napiše čovek?”. Tamo gde je odgovor “ništa, pod uslovom da se namera sprovodi”, generisanje je racionalan podrazumevani izbor. Tamo gde je odgovor “razumevanje onoga od čega zarađujemo”, kucajte sami.
Kako ovo truli
Trulež namere je prvi način otkazivanja. Sloj namere je izvor istine samo dok se održava kao izvorni kod. Čim tim počne da krpi ponašanje direktno — hotfix ovde, brza ručna izmena onde — bez vraćanja te promene u testove i invarijante, namera počinje da opisuje sistem koji više ne postoji. Onda sledeća regeneracija, verno kompajlirana iz zastarele namere, briše nedokumentovane ispravke. Pravilo koje to sprečava isto je ono koje drži šeme poštenim: promene ponašanja prvo sleću kao promene namere, u istom pull request-u, ili ne sleću.
Regenerisanje bez ponovne verifikacije je drugi. Regeneracija nije idempotentna: dva prolaza nad istom namerom daju različit kod sa različitim uzgrednim ponašanjem, a sve što sloj namere ne prikiva slobodno je da se promeni. Timovi se opeku kada pretpostave da jučerašnji zeleni pipeline jemči za današnju regeneraciju. Ne jemči. Svaka regeneracija je nova implementacija i zaslužuje pun prolaz verifikacije — testovi, evali, provere invarijanti — svaki put. Ako je to preskupo za pokretanje po regeneraciji, rešenje je učiniti verifikaciju jeftinijom, a ne ređom.
Tretirati generisani kod kao potrošni kada je nosećijeste treći i najsuptilniji. Tim usvoji “kod je samo rezultat build-a” i prestane da ga čita — bez revizije, bez profilisanja, bez operativne bliskosti. Onda incident stigne u dva ujutru, a ljudi na dežurstvu debaguju sistem koji niko nikada nije pročitao, vođeni samo namerom koju je trebalo da zadovolji. Izvedeno ne znači zanemarljivo. Produkcijski kod traži operativno vlasništvo bez obzira na to ko ga je otkucao; sloj namere vam govori šta sistem treba da radi, ali odgovor na incident se i dalje odvija u onome što on zaista radi. Timovi koji ovo dobro rešavaju imenuju vlasnika za svaku generisanu komponentu isto kao i za ručno pisanu — nekoga ko ju je pročitao, profilisao i ume da se probije kroz nju pod pritiskom.
Pragmatičan put usvajanja
Ništa od ovoga ne traži revoluciju, a timovi koji je pokušaju obično proizvedu manifest i nikakvu promenu. Put koji radi je inkrementalan. Počnite tako što ćete nameru učiniti eksplicitnom za sistem koji već imate: zapišite invarijante za koje verujete da važe, pretvorite nepisano znanje u testove prihvatanja i budite pošteni tamo gde se testovi i sistem ne slažu. Taj korak se isplati čak i ako nijedan agent nikada ne dodirne kodnu bazu — to je jednostavno dokumentacija i pokrivenost testovima koju ste ionako dugovali sami sebi.
Zatim izaberite jednu ograničenu, dobro shvaćenu komponentu i provucite punu petlju kroz nju: namera napisana i revidirana, implementacija generisana prema njoj, verifikacija mehanička, ljudska revizija usmerena na diff namere. Merite pošteno — vreme ciklusa, stopu defekata, utrošak na reviziju — u odnosu na ručno pisanu osnovu. Širite se duž granica na kojima petlja pobeđuje; kucajte i dalje tamo gde ne pobeđuje. Za nekoliko kvartala kodna baza se sama razvrsta u ručno pisano jezgro sa generisanom periferijom, a oskudna seniorska pažnja tima se koncentriše na sloj na kome se akumulira: na precizno i proverljivo odlučivanje o tome šta softver mora da radi.
Industrija je ovde već bila. Niko ne žali za ručnim pisanjem asemblera; sposobnost smo zadržali, a naviku odbacili, jer je izvor na višem nivou plus pouzdan kompajler prosto bio bolja pogodba. Namera plus agenti plus verifikacija se uobličavaju u istu takvu pogodbu, jedan nivo više. Pisanje koda postaje opcija. Znati tačno šta kod mora da radi — i umeti to dokazati — postaje posao.