Razvoj vođen specifikacijom za AI projekte

AI znatno olakšava brzo stvaranje koda. Jednako tako olakšava i brzo stvaranje pogrešnog koda. Zato je razvoj vođen specifikacijom u projektima uz pomoć AI-ja važniji, a ne manje važan.

Kad tim razvija bez jasne specifikacije, proizvod s vremenom odluta od svoje svrhe. Kad u tome pomaže AI, to se može dogoditi u jednom poslijepodnevu. Kod se može kompajlirati, sučelje može izgledati uredno, a testovi mogu prolaziti. Proizvod i dalje može biti pogrešan.

Zašto AI mijenja profil rizika

AI ubrzava tempo interpretacije. Jedan upit može proizvesti arhitekturu, tekst, validaciju, imenovanje i korisnički tok. To je korisno, ali opasno kada izvor istine nije dovoljno jasan.

U praksi AI često optimizira ono što je u tom trenutku najvidljivije:

• posljednji upit
• najbližu datoteku
• najlakši implementacijski put
• najgeneričniji poznati obrazac

Ništa od toga samo po sebi ne znači ispravnu proizvodnu odluku.

To su korisne prečice za generiranje. Ali nisu zamjena za proizvodnu prosudbu.

Što radi dobra specifikacija

Dobra specifikacija obavlja barem četiri zadatka:

• definira svrhu
• postavlja granice
• određuje standard pregleda
• služi kao memorija tima

Prvo, definira svrhu. Tim može procijeniti podržava li neka značajka stvarni proizvod ili samo dodaje izlaz.

Drugo, definira granice. Pojašnjava što je u opsegu, što je izvan opsega, što je opcionalno i što mora raditi čak i kada opcionalni sustavi zakažu.

Treće, definira standard pregleda. Umjesto da se pita samo radi li promjena tehnički, recenzenti mogu pitati odgovara li ona namjeravanom tijeku rada i proizvodnim obvezama.

Četvrto, djeluje kao memorija. AI sustavi sami po sebi ne drže stabilnu institucionalnu memoriju. Specifikacija u repozitoriju to čini.

To je u projektu Let Books vrlo jasno. AGENTS.md više puta naglašava da ručni tijek mora raditi i bez plaćenih AI usluga te da fizički primjerci knjiga nisu isto što i bibliografski zapisi. To nisu tehničke sitnice nego proizvodne granice.

To nisu implementacijski detalji. To su proizvodne granice. Ako AI pomoćnik generira tok koji blokira ručni unos ili spaja podatke o fizičkom primjerku s metapodacima izdanja, problem nije stil. Problem je proizvodno odstupanje.

Zašto dokumentacija ne smije čekati

Ako je dokumentacija zastarjela ili nejasna, različiti ljudi i različiti alati iz istog repozitorija zaključit će da postoje različiti proizvodi. Jedan će slijediti demo, drugi stari README, treći najbližu datoteku.

Bez ažurne dokumentacije:

• upiti postaju nedosljedni
• pregled postaje subjektivan
• demoi počinju slučajno redefinirati proizvod
• budući suradnici nasljeđuju ponašanje ne znajući je li bilo namjerno

Zato dokumentacija nije samo naknadno objašnjenje. Ona je dio operativnog sustava projekta. U ovom repozitoriju README.md opisuje trenutačno stanje, AGENTS.md proizvodnu namjeru, AGENTS-Implementation.md taktička pravila, a docs/ pravila objave i evidencije.

Uloga demoa

Demo je koristan jer pokazuje što postoji i otkriva probleme u korisničkom toku. Ali ne bi smio tiho postati proizvodna specifikacija.

Pravila repozitorija već razlikuju kanonične specifikacije i dokumentaciju od statusa implementacije. Ako demo otkrije bolji tijek, treba ažurirati specifikaciju i dokumentaciju, a ne dopustiti da demo sam po sebi pobijedi.

Ako demo otkrije bolji tijek rada, odgovor nije pustiti da demo tiho pobijedi. Odgovor je ažurirati specifikaciju, dokumentaciju i standard pregleda kako bi taj bolji tijek postao namjeran.

Markdown, testovi i CI čine lanac

U razvoju vođenom specifikacijom ove razine ne stoje svaka za sebe.

• Markdown pohranjuje namjeru u pregledljivom obliku.
• Dokumentacija objašnjava kako je treba tumačiti.
• Testovi provjeravaju izvršiva očekivanja.
• Pravila validacije hvataju strukturno odstupanje.
• CI redovito provodi pravila.

Zajedno stvaraju proizvodnu memoriju koja preživljava brzinu razvoja.

Svaka je razina sama po sebi nepotpuna. Zajedno stvaraju proizvodnu memoriju koja preživljava brzinu, iteraciju i promjene tima.

Što to znači za timove koji koriste AI

Timovi koji dobro koriste AI ne uklanjaju proces. Oni proces pomiču bliže izvoru generiranja.

To obično znači:

• da prije implementacije pišu jasnije proizvodne specifikacije
• da održavaju izričite implementacijske smjernice
• da ažuriraju dokumentaciju kada se ponašanje proizvoda promijeni
• da demo uspoređuju sa specifikacijama umjesto da pretpostavljaju podudarnost
• da postupno dodaju pravila validacije kako usklađenost ne bi ovisila samo o ljudskom pamćenju

Ovo nije protiv AI-ja. Ovako AI postaje pouzdan.

Trajna lekcija

AI može brzo proizvesti kod, sadržaj i sučelja. Sam po sebi ne može jamčiti da svi ti izlazi još uvijek opisuju isti proizvod.

Razvoj vođen specifikacijom način je da tim spriječi da se brzina pretvori u odstupanje.

U projektima uz pomoć AI-ja specifikacija nije papirologija nakon činjenice. Ona je granica, memorija i standard pregleda koji brzo isporučivanje čine vjerodostojnim.

Povezano štivo

• ../../wiki/spec-driven-development.md
• ../../wiki/validation-layers.md
• ai-as-an-oracle.md
• spec-driven-development-in-let-books.md