AI sustavi ne postaju korisni zato što mogu generirati tekst, pozivati alate ili zaključivati na temelju upita. Postaju korisni kada mogu naučiti dovoljno o softveru s kojim rade da donesu sigurnu i relevantnu odluku.

Zbog toga je vaša baza koda više od implementacije. Ona je učitelj AI-ja.

Za programere koji usvajaju asistente za kodiranje, agente, sustave za dohvaćanje informacija ili operativnu automatizaciju, važno pitanje nije jednostavno: „Koji model trebamo koristiti?“ Ono je: „Čemu naš softver uči sposoban sustav o tome kako se ovdje treba obavljati posao?“

Loše objašnjen sustav prisiljava AI da nagađa. Dobro projektiran sustav daje mu ograničenja, rječnik, primjere i povratne informacije. Razlika nije kozmetička. Ona određuje hoće li agent proizvesti koristan pull request, opasnu promjenu ili samouvjereno pogrešan odgovor.

Učinite namjeravani put vidljivim

Većina zrelih sustava sadrži pravila koja su očita samo ljudima koji ih održavaju godinama. Stariji inženjer može znati da prilagodba naplate mora proći kroz određenu uslugu, da se polje baze podataka namjerno može postaviti na null ili da pozadinski zadatak mora ostati idempotentan. AI ne može pouzdano zaključiti te činjenice samo iz naziva datoteka.

Počnite tako da preferirani put učinite lakšim za otkrivanje od slučajnog puta. Dobre granice pomažu i ljudima i modelima: jasno vlasništvo nad modulima, stabilna sučelja, usluge uskog opsega i eksplicitni nazivi domene.

Ako agent treba dodati značajku postavki računa, trebao bi moći pronaći prepoznatljiv put od obrade zahtjeva do validacije, poslovne logike, pohrane i testova. Ako svaka značajka izmišlja vlastiti put, agent će oponašati nedosljednost jer je nedosljednost ono čemu ga repozitorij uči.

Dokumentacija je ovdje važna, ali ne bi trebala postati druga, nepouzdana verzija koda. Koristite kratke dokumente za objašnjavanje odluka koje kod ne može jasno izraziti:

• koje usluge posjeduju određena poslovna pravila;
• koje integracije smiju unositi vanjske promjene;
• koji su podaci osjetljivi i kako se s njima mora postupati;
• koje su naredbe sigurne za lokalni razvoj i provjeru;
• koji su arhitektonski obrasci preferirani, zastarjeli ili zabranjeni.

Smjestite ove smjernice blizu mjesta rada. Sažet vodič za suradnike u korijenu repozitorija koristan je. Bilješka uz složen podsustav često je bolja. Cilj nije objasniti svaki redak; cilj je spriječiti uvjerljive, ali skupe nesporazume.

Pretvorite prešutno znanje u izvršivu povratnu informaciju

Najjači učitelj nije proza. To je povratna informacija koja se izvršava.

Testovi, linteri, provjere tipova, validacija sheme i CI pravila daju AI-ju način da otkrije odgovara li njegov rad sustavu. Također daju osobi koja pregledava njegov izlaz mnogo bolju početnu točku. Agent koji može pokrenuti ciljanu skupinu testova, uočiti neuspjeh i revidirati malu promjenu djeluje u krugu učenja. Agent koji može samo isporučiti zakrpu djeluje na temelju nagađanja.

To znači da automatizacija kvalitete treba biti osmišljena za dijagnostiku, a ne samo za provedbu pravila. Poruke o pogreškama trebaju navesti prekršeno pravilo. Testovi trebaju opisivati ponašanje terminima domene. Naredbe za izgradnju trebaju biti predvidljive i dokumentirane.

Na primjer, naziv testa poput rejects_refund_when_original_charge_is_settled poučava više od generičkog neuspjeha tvrdnje. Izravno prenosi poslovnu invarijantu sljedećem inženjeru ili agentu koji naiđe na kod.

Zadržite slojevitu provjeru. Brze provjere podržavaju čestu iteraciju, dok sporije integracijske provjere štite granice na kojima pretpostavke postaju skupe.

npm run lint
npm run typecheck
npm test -- billing/refunds
npm run test:integration

Točne naredbe razlikovat će se ovisno o tehnologijskom sklopu. Važno je da suradnik može prepoznati koje provjere treba pokrenuti za lokalnu promjenu, koje provjere zahtijevaju ovisnosti i koji neuspjesi trebaju zaustaviti implementaciju.

Oblikujte alate kao ugovore, a ne kao prečace

Agenti postaju značajno sposobniji kada mogu pregledavati stanje i poduzimati kontrolirane radnje. No svaki je alat također sučelje koje oblikuje ponašanje. Nejasan alat potiče nejasnu upotrebu.

Pretpostavimo da operativni agent treba istražiti neuspjele uvoze. Alat pod nazivom run_database_query potiče široko, nesigurno istraživanje. Alat poput get_import_failure_summary(import_id) ima manju površinu i jasniju svrhu. Može vratiti status, kategoriju pogreške, broj ponovnih pokušaja i sigurne sljedeće radnje bez otkrivanja nepovezanih podataka o korisnicima.

Dobro oblikovani AI alati dijele poznate kvalitete API-ja:

• ulazi su eksplicitni i validirani;
• izlazi imaju stabilnu, dokumentiranu strukturu;
• dopuštenja odražavaju rizik radnje;
• nuspojave se razlikuju od operacija samo za čitanje;
• pogreške objašnjavaju je li ponovni pokušaj prikladan.

Za radnje sa značajnim posljedicama namjerno uvedite dodatno trenje. Agent može sastaviti poruku korisniku, ali njezino slanje može zahtijevati odobrenje. Može pripremiti plan implementacije, ali izvršavanje u produkciji može zahtijevati zasebnu vjerodajnicu i zapis o promjeni. To nije priznanje da je AI jedinstveno rizičan; to je dobro oblikovanje sustava za svaku automatizaciju koja djeluje velikom brzinom.

Dajte agentima primjere dobre prosudbe

Primjeri koda podučavaju sintaksu. Zapisi odluka podučavaju prosudbu.

Kada sustav ima neočite kompromise, zabilježite obrazloženje u sažetom obliku. Objasnite zašto je ovisnost izolirana, zašto je tijek rada asinkron, zašto predmemorija može vratiti blago zastarjele podatke ili zašto se krajnja točka ne može automatski ponovno pokušati. To su pojedinosti koje bi AI inače mogao „poboljšati” i ukloniti.

Primjeri bi trebali uključivati putanje neuspjeha, a ne samo uspješne putanje. Što se treba dogoditi ako vanjski pružatelj usluge prekorači vrijeme odgovora? Ako se poruka u redu dostavi dvaput, što radnju čini sigurnom? Ako model vrati neispravno oblikovan strukturirani izlaz, pokušava li sustav ponovno, popravlja, eskalira ili staje?

Korisna implementacija često čini te izbore eksplicitnima:

if (response.status === 429) {
  return scheduleRetry(jobId);
}

if (!isValidResult(response.body)) {
  return markForReview(jobId);
}

return applyResult(response.body);

Ovaj je obrazac vrijedan jer razdvaja privremeni neuspjeh od neispravnog izlaza i od uspješno obavljenog rada. Precizna politika ovisi o domeni, ali dvosmislenost ne bi trebala.

Održavajte okruženje za učenje čistim

AI sustav čita poticaje ugrađene u vaš repozitorij. Mrtvi kod, zastarjela konfiguracija, duplicirani obrasci i trajno neuspješni testovi poučavaju pogrešnu lekciju. Proširuju prostor pretraživanja i čine slaba rješenja normalnima.

Ne trebate besprijekornu bazu koda prije uvođenja AI pomoći. Malo koji timovi je imaju. No trebali biste identificirati pouzdane putove i smanjiti dvosmislenost tamo gdje će agenti najčešće raditi. Označite generirane datoteke. Uklonite zastarjele primjere kada je izvedivo. Držite tajne izvan repozitorija i izvan upita. Tretirajte zapisnike, prijave i produkcijske podatke kao podatke s kontrolama pristupa, a ne kao slobodan kontekst za model.

Najvažnije je da izlaz agenta pregledavate kao predloženu promjenu stvarnog sustava, a ne kao čarobni odgovor. Provjerite pretpostavke, ponašanje na granicama, autorizaciju, opažljivost i mogućnosti vraćanja promjene. Model može ubrzati implementaciju; odgovornost ostaje na ljudima odgovornima za softver.

Softver koji gradite postaje kurikulum

Najbolja AI strategija često nije glamurozna: razjasnite vlasništvo, kodirajte invarijante, poboljšajte testove, suzite alate i dokumentirajte odluke ondje gdje su važne. Ta ulaganja također ubrzavaju ljude, što je koristan test jača li AI inicijativa organizaciju ili samo dodaje još jedan sloj novosti.

Svako sučelje, test, operativni priručnik i poruka o pogrešci podučava sustav kako sudjelovati u vašem radu. Pažljivo osmislite te lekcije. AI će i dalje griješiti, ali imat će mnogo bolju priliku činiti pogreške koje su vidljive, ograničene i ispravljive — te postati istinski koristan suradnik umjesto rječitog izvora neizvjesnosti.