Većina razgovora o programiranju uz pomoć AI-ja počinje upitom. Najbolji počinju bazom koda.

Model opće namjene može objasniti jezičnu značajku, izraditi nacrt funkcije ili predložiti migraciju. No ne razumije automatski zašto vaš tijek naplate neuspjelu uplatu tretira drukčije od otkazane pretplate, zašto korisnik s oznakom „aktivan” i dalje možda nema pravo na neku značajku ili koje brojke u izvještajima financije smatraju mjerodavnima. Ta su pravila često zapisana u tipovima, testovima, shemama baze podataka, konvencijama imenovanja i neprivlačnim komentarima o rubnim slučajevima.

Zato bi se kod trebao smatrati poslovnim mentorom AI-ja. Upit postavlja zadatak; repozitorij pruža rječnik, ograničenja i dokaze potrebne za sigurno obavljanje korisnog posla.

Poslovni kontekst već je skriven u tehničkim artefaktima

Timovi ponekad opisuju poslovno znanje kao nešto što postoji isključivo u dokumentaciji proizvoda ili u glavama iskusnih kolega. Ti su izvori važni, ali funkcionalni softver također sadržava znatan dio tog znanja.

Razmotrite uslugu koja odobrava pristup funkcionalnosti koja se plaća. Model od kojeg se zatraži da „doda provjeru prava pristupa” mogao bi proizvesti uvjerljiv uvjet na temelju statusa pretplate. Model kojemu se pokažu relevantni domenski tipovi, testovi pravila, obrađivači događaja i postojeće provjere autorizacije ima veću šansu prepoznati da pristup ovisi o nekoliko čimbenika: statusu računa, razdobljima odgode naplate, ograničenjima plana, zastavicama značajki i iznimkama na razini organizacije.

Razlika nije samo u većoj količini konteksta. To je razlika između generiranja koda koji izgleda razumno i predlaganja promjene koja odgovara operativnom modelu sustava.

Korisni poslovni signali u repozitoriju često uključuju:

• დომenske tipove i enume koji definiraju jezik proizvoda.
• Testove koji dokumentiraju očekivano ponašanje na granicama i u slučajevima neuspjeha.
• Ograničenja baze podataka i migracije koji otkrivaju što sustav smatra valjanim.
• API ugovore koji pokazuju obećanja dana klijentima i drugim uslugama.
• Polja za reviziju, nazive događaja i poruke o pogreškama koji otkrivaju operativne brige.
• Definicije konfiguracije i implementacije koje otkrivaju ovisnosti tijekom izvođenja.

Nijedan od tih artefakata sam za sebe nije savršen. Zajedno čine praktičan kurikulum za AI asistenta.

Dajte modelu ograničen put učenja

„Pročitaj cijeli repozitorij” rijetko je dobra uputa. Može stvoriti šum, izložiti nevažan materijal i otežati provjeru razmišljanja asistenta. Umjesto toga, sastavite kontekst oko određene odluke.

Pretpostavimo da tim treba dodati pravilo: računi u probnom razdoblju mogu izvoziti izvještaje samo kada administrator omogući tu mogućnost. Usmjereni paket konteksta mogao bi uključivati model računa, apstrakciju zastavice značajke, krajnju točku izvoza, povezane testove autorizacije i shemu API odgovora. Također bi trebao navesti što je nepoznato ili neodlučeno.

Ta je posljednja točka važna. AI sustavi imaju tendenciju dovršavati obrasce. Ako je poslovno pravilo nepotpuno, zatražite od modela da utvrdi odluke koje nedostaju, umjesto da ih tiho sam odabere.

Upotrijebite bazu koda za poučavanje utvrđenih pravila, a eksplicitna pitanja za otkrivanje pravila koja još nisu donesena.

Zatražite čitanje utemeljeno na dokazima prije nego što zatražite zakrpu

Produktivan tijek rada ima dvije faze. Najprije zatražite od asistenta da objasni trenutačno ponašanje i navede dostavljene artefakte. Zatim zatražite da predloži minimalnu promjenu. Time pretpostavke postaju vidljive prije nego što postanu detalji implementacije.

Na temelju samo dostavljenih datoteka:
1. Opišite trenutačno pravilo autorizacije izvoza.
2. Navedite svaki uvjet i dokaze za njega.
3. Utvrdite nejasnoće ili proturječne signale.
4. Predložite najmanju promjenu za novo pravilo računa u probnom razdoblju.
5. Navedite testove koji bi trebali proći, pasti ili biti dodani.

Ovaj zahtjev potiče razlikovanje koje je lako izgubiti u radu koji se brzo odvija: opaženo ponašanje nije isto što i namjeravana politika. Model može sažeti prvo; odgovorna osoba i dalje potvrđuje drugo.

Koristite testove kao razgovor o posljedicama

Testovi su posebno vrijedni jer poslovni jezik pretvaraju u izvršive primjere. Dobro imenovan test može objasniti više od odlomka općenite dokumentacije:

it("odbija izvoze tijekom probnog razdoblja dok administrator ne omogući izvoz", () => {
  const account = trialAccount({ exportsEnabled: false });
  expect(canExport(account, adminUser())).toBe(false);
});

Test ne odgovara na svako pitanje o politici. Ipak, uspostavlja konkretnu posljedicu. Kada od AI-ja tražite izmjenu ponašanja, dostavite susjedne testove i zatražite da nabroji zahvaćene slučajeve. Upravo se tu često pojavljuju skriveni zahtjevi: Što se događa kada usluga zastavica nije dostupna? Nastavlja li se već pokrenuti izvoz? Je li postavka ograničena na organizaciju, radni prostor ili pojedinog korisnika?

Za promjene sa značajnim rizikom zatražite od asistenta da prije implementacije izradi tablicu odluka. Kratku tablicu ulaza i očekivanih ishoda vlasnik proizvoda, recenzent ili voditelj podrške lakše će pregledati nego veliku zakrpu.

Gradite dohvaćanje oko značenja, a ne količine

Kako repozitoriji rastu, programer ne može ručno priložiti svaku relevantnu datoteku svakom zahtjevu. Tu pomažu dohvaćanje i alati, ali cilj nije maksimalan kontekst. Cilj je relevantan kontekst s jasnim podrijetlom.

Dobro dohvaćanje počinje jezikom proizvoda korištenim u zadatku: pojmovima kao što su „račun”, „radni prostor”, „odobrenje”, „zadržavanje” ili „pravo pristupa”. Potražite te pojmove, a zatim proširite pretragu kroz mjesta poziva, reference tipova, testove i sheme. Dajte prednost mjerodavnim definicijama pred dupliciranim pomoćnim funkcijama ili zastarjelim primjerima.

Korisni redoslijed odabira konteksta jest:

1. Pronađite domenski model i javni ugovor.
2. Pronađite točku odluke na kojoj se ponašanje provodi.
3. Pronađite testove za uobičajene, odbijene i pogrešne putanje.
4. Pronađite artefakte pohrane ili događaja koji ograničavaju promjenu.
5. Uključite samo operativnu konfiguraciju potrebnu za razumijevanje ponašanja implementacije.

Ako vaši AI alati mogu automatski priložiti kontekst repozitorija, uspostavite granice. Isključite tajne, vjerodajnice, podatke o korisnicima i nepovezane projekte. Kontrolu pristupa za AI kontekst tretirajte s istom pažnjom koja se primjenjuje na kontrolu izvornog koda i nadzor produkcije.

Učinite neizvjesnost eksplicitnim izlazom

Najkorisniji AI asistenti nisu oni koji uvijek zvuče sigurno. To su oni čiji izlaz čini provjeru učinkovitom.

Zatražite pretpostavke, granice pouzdanosti i alternative kada zadatak dotiče novac, dozvole, usklađenost, destruktivne radnje ili komunikaciju s korisnicima. Zatražite od modela da razlikuje činjenice pronađene u kodu od zaključaka koje je izveo. Zatim zahtijevajte uobičajene inženjerske kontrole: pregled, testove, statičku analizu gdje je primjenjiva te plan implementacije primjeren opsegu utjecaja.

Na primjer, promjena pravila naplate može se kompajlirati i proći jedinične testove, a ipak biti nesigurna za implementaciju ako mijenja povijesne zapise ili uzrokuje da ponovni pokušaji stvore dvostruke naplate. Asistenta treba potaknuti da provjeri idempotentnost, sigurnost migracije, ponašanje pri vraćanju i obradu neuspjeha — ne samo sretan put.

Pretvorite svaku promjenu u bolji nastavni materijal

Dugoročna prilika nije samo učiniti AI boljim u pisanju koda. Riječ je o tome da sustav svima bude lakši za razumijevanje.

Kada se pravilo razjasni, zapišite ga u test, tip, pravilo validacije ili sažet zapis odluke blizu koda koji ga provodi. Kada je terminologija zbunjujuća, poboljšajte nazive. Kada se dvije usluge ne slažu oko nekog pojma, riješite ugovor umjesto da asistenta učite objema neusklađenim verzijama.

S vremenom to stvara pozitivan krug: jasniji softver AI asistentima pruža bolje dokaze; bolje potpomognute promjene čine softver jasnijim. Upit ostaje važan, ali ne bi trebao nositi cjelokupan teret objašnjenja.

AI može generirati sintaksu u sekundama. Trajna prednost dolazi od poučavanja čemu ta sintaksa služi. Kada vaš kod jasno izražava poslovne potrebe, postaje više od implementacije: postaje mentor koji ljudima i strojevima pomaže donositi bolje odluke.