Moćan AI ne spašava nejasne zahtjeve

AI može brzo pisati kod. Ne može umjesto nas razjasniti nejasne softverske zahtjeve.

Razvoj softvera nikada nije bio samo pisanje koda. Kod je vidljivi rezultat mnogo važnijeg procesa: razumijevanja problema, ljudi koji koriste proizvod, poslovnih pravila, ograničenja sistema i posljedica koje svaka promjena može imati na ostatak proizvoda.

Pojava AI alata i velikih jezičkih modela nije promijenila tu činjenicu. Samo ju je učinila još očiglednijom.

AI danas može veoma brzo generisati klase, API endpointove, migracije baze podataka, testove, komponente korisničkog interfejsa i cijele module. Ipak, kvalitet tog koda zavisi od konteksta koji damo modelu. AI može ubrzati implementaciju. Ne može pouzdano nadoknaditi slabo razumijevanje proizvoda.

AI može veoma brzo napraviti pogrešnu stvar.

To nije produktivnost. To je tehnički dug koji stiže ranije.

Rečenica iz ticketa nije softverski zahtjev

Uzmimo ovakav zahtjev:

"Korisnik treba moći otkazati narudžbu."

Na prvi pogled djeluje jednostavno. Dodamo nekoliko provjera, jedan API poziv, promjenu statusa i dugme na korisničkom interfejsu.

Stvarni zahtjev počinje kada pitamo šta "otkazati" zaista znači:

• Do kada je otkazivanje moguće?
• Šta se dešava ako je plaćanje već izvršeno?
• Da li sistem automatski pokreće povrat novca?
• Šta ako je dio narudžbe već poslan?
• Da li se rezervisana količina proizvoda vraća na stanje?
• Ko obavještava skladište?
• Može li prodavac odbiti otkazivanje?
• Kako bilježimo promjenu u auditu?
• Da li iskorišteni kupon ponovo postaje dostupan?
• Koje statuse drugi sistemi očekuju?

Jedna kratka korisnička potreba brzo postaje skup poslovnih pravila, stanja, integracija i dogovora između različitih dijelova sistema.

Bez tih odgovora AI će vjerovatno generisati kod koji izgleda ispravno. Struktura može biti uredna. Nazivi metoda mogu biti dobri. Možda će napisati i nekoliko testova. Ipak, kod može potpuno zanemariti finansijske procese, stanje zaliha, postojeće integracije ili ponašanje drugih dijelova proizvoda.

Ispravna sintaksa ne znači da smo napravili pravi proizvod.

Dokumentacija daje AI-ju potreban kontekst

Timovi često posmatraju dokumentaciju kao nešto što se piše nakon implementacije. U praksi, najkorisnija dokumentacija nastaje prije koda jer nas njeno pisanje tjera da promislimo promjenu.

Dokument ne mora biti dug ni formalan. Njegov posao je da smanji broj različitih tumačenja istog zahtjeva. Koristan dokument treba odgovoriti na pitanja kao što su:

• Koji problem rješavamo?
• Za koga ga rješavamo?
• Koja poslovna pravila važe?
• Šta sistem smije uraditi, a šta mora odbiti?
• Koji postojeći procesi se mijenjaju?
• Koji sistemi, moduli i timovi će osjetiti promjenu?
• Koje smo odluke donijeli i zašto?
• Koje rubne slučajeve i greške očekujemo?

Kada takav kontekst postoji, on postaje dobar ulaz i za AI model.

LLM ne razumije naš proizvod samo zato što smo mu poslali dio repozitorija. Ne zna zašto je neko prije dvije godine dodao određeni status. Ne vidi koji eksterni sistem zavisi od jednog polja niti zašto privremeno rješenje danas podržava kritičan poslovni proces.

Model zna samo ono što stavimo u njegov kontekst. Ako je kontekst nepotpun, zastario ili kontradiktoran, rezultat će imati iste probleme. AI ne uklanja nejasnoću. Pretvara je u kod.

UML dijagram treba objasniti rizične dijelove

UML i drugi vizuelni modeli imaju lošu reputaciju u nekim timovima jer su se nekada koristili za previše formalne dokumentacije. Problem nije bio u dijagramu, već u crtanju dijagrama koji nikome nije trebao.

Koristan dijagram je sažeto objašnjenje načina na koji sistem radi:

• Sequence dijagram pokazuje ko pokreće operaciju, kojim redoslijedom servisi komuniciraju, gdje mogu nastati greške i ko je odgovoran za oporavak.
• State dijagram pokazuje dozvoljene prelaze između stanja. Na primjer, smije li narudžba preći iz SHIPPED u CANCELLED ili mora postojati poseban proces povrata?
• Component dijagram pokazuje granice sistema i zavisnosti među modulima.
• Activity dijagram objašnjava poslovni proces koji je teško pratiti kroz nekoliko ticketa.
• Domain model daje timu zajedničko značenje važnih pojmova. "Korisnik", "kupac", "vlasnik računa", "pretplatnik" i "platilac" možda zvuče slično, ali u stvarnom proizvodu mogu biti sasvim različite uloge.

Ovi modeli pomažu AI-ju jer tekst često ostavlja prostor za nagađanje. Dijagram može jasno prikazati interakcije, vlasništvo i dozvoljene tokove.

Ne treba nam dijagram za svaku klasu. Treba nam tamo gdje pogrešna pretpostavka može izazvati skupu grešku.

Pitajte šta će se još promijeniti

Prije nego što izaberemo način implementacije, treba postaviti šire pitanje:

Šta će se još promijeniti ako ovo napravimo?

Stvarni proizvod je mreža povezanih ponašanja. Nova funkcionalnost rijetko ostane unutar jednog ekrana ili servisa. Može uticati na postojeće korisničke tokove, autorizaciju, naplatu, izvještavanje, analitiku, obavještenja, audit, performanse, sigurnost i integracije.

Zbog toga je analiza uticaja važna. Novi zahtjev mora raditi sa starim pravilima i postojećim funkcionalnostima, uključujući kombinacije koje je lako propustiti kada provjeravamo samo idealan tok.

Na primjer, dodavanje porodične pretplate nije samo kreiranje nove vrste paketa. Tim mora razmotriti i:

• odnos vlasnika pretplate i ostalih članova
• prava pristupa i upravljanje ulogama
• promjenu ili otkazivanje paketa
• uklanjanje člana koji i dalje ima podatke ili sadržaj
• pravila naplate
• ograničenje broja članova
• privatnost među članovima
• migraciju postojećih individualnih korisnika
• promotivne kodove
• analitiku i finansijsko izvještavanje

AI može predložiti scenarije, napraviti matricu testova i implementirati pravila kada ih jasno definišemo. Neko i dalje mora razumjeti proizvod dovoljno dobro da primijeti koja pitanja nedostaju.

Ta odgovornost i dalje pripada inženjeru.

Komunikacijski ugovori nose poslovno značenje

Moduli i servisi u distribuiranom sistemu ne dijele samo podatke. Dijele i očekivanja.

API specifikacija, schema događaja, format poruke, pravila verzionisanja, idempotentnost, timeout, retry ponašanje i način prijavljivanja greške čine ugovor između komponenti.

Servis može promijeniti značenje polja bez promjene njegovog naziva. Tehnički oblik i dalje odgovara, ali je poslovni ugovor već prekršen.

Zamislimo da događaj OrderCancelled na početku znači da je cijela narudžba otkazana. Kasnije jedan servis počne slati isti događaj i za djelimična otkazivanja. Svaki postojeći consumer sada može donijeti pogrešnu odluku iako događaj i dalje prolazi schema validaciju.

Nije dovoljno dokumentovati samo oblik poruke. Dobar ugovor treba objasniti:

• kada komunikacija počinje
• ko je vlasnik podatka
• šta svako polje znači
• koje garancije isporuke važe
• da li je operacija idempotentna
• koje greške primalac treba očekivati
• kako se ugovor mijenja bez prekidanja postojećih korisnika
• šta se dešava kada jedna strana nije dostupna

Jasni ugovori omogućavaju AI-ju da pouzdanije generiše klijente, validaciju, adaptere, testove kompatibilnosti i servisni kod. Kada je ugovor nejasan, model popunjava praznine pretpostavkama. Te pretpostavke mogu izgledati sasvim razumno sve dok ne stignu u produkciju.

AI ubrzava proces koji već imamo

Ako tim dobro razumije domen, piše jasne zahtjeve, održava dokumentaciju i poznaje granice sistema, AI može uštedjeti mnogo vremena. Može preuzeti repetitivan posao i ostaviti inženjerima više vremena za odluke koje traže ljudsku procjenu.

Ako isti tim ima nejasne zahtjeve, kontradiktorna pravila i slabu sliku postojećeg sistema, AI će brže proizvesti pogrešan kod i otežati kasnije uklanjanje tih problema.

Moćniji model ne popravlja loš kontekst sam od sebe. Može napisati uvjerljiviji kod, predložiti uredniju arhitekturu i sigurnije obrazložiti odgovor. Taj odgovor i dalje može počivati na pogrešnoj pretpostavci.

Dobar prompt za razvoj softvera zavisi od posla koji uradimo prije prompta:

• razumijevanja korisnika i poslovnog problema
• preciznog pisanja zahtjeva
• modeliranja domena
• zapisivanja pravila i odluka
• provjere uticaja promjene na cijeli sistem
• definisanja granica odgovornosti
• pisanja jasnih komunikacijskih ugovora
• davanja primjera očekivanog i odbijenog ponašanja

Prompt ne može zamijeniti dizajn softvera. Ako je prompt dobar, to je obično zato što je dizajn već promišljen.

Inženjeri se približavaju odlukama o proizvodu

Kako AI bude preuzimao veći dio implementacije, vrijednost inženjera će manje zavisiti od količine ručno napisanog koda. Teže i korisnije vještine biće:

• razumijevanje stvarnog korisničkog problema
• prepoznavanje skrivenih pretpostavki
• povezivanje poslovnih potreba i tehničkih ograničenja
• predviđanje posljedica promjene
• definisanje jasnih granica sistema
• dizajniranje stabilnih ugovora
• provjera da li implementacija odgovara proizvodu
• razmišljanje nekoliko koraka unaprijed

Tehničko znanje ovdje postaje važnije, ne manje važno. Treba nam dovoljno dubine da pregledamo generisani kod, primijetimo loše apstrakcije, pronađemo sigurnosne i performansne probleme i razumijemo posljedice prije nego što ih korisnici pronađu umjesto nas.

Možda ćemo trošiti manje vremena na prevođenje gotove odluke u kod. Trošićemo više vremena na provjeru da li je ta odluka dobra.

Jasno razmišljanje i dalje dolazi prvo

Snaga AI modela manje je važna od toga koliko dobro razumijemo ono što pravimo.

Moramo razumjeti zahtjev i razlog iza njega. Moramo znati kako funkcionalnost utiče na ostatak proizvoda, kako radi sa starim pravilima, koje interakcije uvodi i koje ugovore mora poštovati.

To je bio posao dobrog softverskog inženjerstva prije LLM-ova i ostaće njegov posao kada ovi alati postanu sasvim uobičajeni. AI može smanjiti vrijeme koje trošimo na repetitivne dijelove implementacije. Tako dobijamo više vremena za razumijevanje problema, oblikovanje proizvoda, arhitektonske odluke i dugoročne posljedice svojih izbora.

AI neće ukloniti potrebu da razmišljamo. Možda će nam konačno dati dovoljno vremena da se razmišljanju više posvetimo.

Možda je "Software Product Engineer" ipak bolji naziv za ovaj posao.