Većini softverskih timova ne treba još jedna značajka umjetne inteligencije koja izvršava zadatak na naredbu. Trebaju im sustavi koji mogu naučiti kako se posao doista obavlja.

Ta razlika zvuči maleno, ali mijenja sve. Umjetna inteligencija koja samo izvršava može generirati komponentu, sažeti tiket ili izraditi nacrt testa. Svakako korisno. No razvoj softvera nije red izoliranih upita. To je živi sustav konvencija, ograničenja, odluka, ovisnosti i kompromisa koji se s vremenom nakupljaju.

Oblikovati korisnu umjetnu inteligenciju za rad na softveru znači pomaknuti se od pristupa „recite joj što da radi” prema pristupu „pomozite joj da razumije kako ova organizacija radi, a zatim joj pružite ograničene načine za doprinos.”

Izvršavanje je lakši dio

Umjetna inteligencija usmjerena na izvršavanje izvrsna je kada je željeni rezultat jasan i lokaliziran. Zatražite od nje da pretvori strukturu podataka, objasni pogrešku, izradi nacrt dokumentacije ili napiše prvu verziju jediničnog testa. Zahtjev sadrži dovoljno konteksta da omogući razuman odgovor.

Ograničenja se pojavljuju kada ispravnost ovisi o informacijama izvan upita. Treba li novi API vratiti objekt pogreške ili baciti iznimku? Koristi li ovaj repozitorij renderiranje na poslužiteljskoj strani? Koja je polja sigurno zapisivati u zapisnike? Mora li migracija podržavati postupno uvođenje? Je li „mala” promjena korisničkog sučelja obuhvaćena ugovorom o pristupačnosti?

Ta pitanja nisu samo tehničke trivijalnosti. Ona predstavljaju naučeno organizacijsko znanje. U zrelom softveru najbolja implementacija rijetko je sintaktički najelegantniji odgovor. To je odgovor koji se uklapa u arhitekturu, poštuje operativnu stvarnost i olakšava život sljedećoj osobi koja ga mora promijeniti.

Što znači da sustav umjetne inteligencije uči

Učenje ne mora značiti ponovno treniranje modela pri svakom commitu. U praktičnim softverskim sustavima ono obično znači pružanje umjetnoj inteligenciji kontroliranog pristupa trajnom kontekstu i povratnim informacijama.

Taj kontekst može uključivati dokumentaciju repozitorija, zapise o arhitektonskim odlukama, standarde kodiranja, vlasništvo nad uslugama, priručnike za incidente, odobrene biblioteke, konvencije testiranja i nedavne rasprave o pull requestovima. Povratne informacije mogu dolaziti iz rezultata testova, statičke analize, pregleda koda, provjera implementacije ili od razvojnog inženjera koji izričito ispravlja pretpostavku.

Ključno dizajnersko pitanje nije: „Može li model vidjeti sve?” Ono je: „Koje mu informacije pomažu da donese bolju odluku za ovaj zadatak i kako tu odluku možemo provjeriti?”

Kontekst treba biti strukturiran, a ne samo ubačen

Česta je pogreška tretirati veliki kontekstni prozor kao zamjenu za dizajn sustava. Dodavanje više dokumenata može prikriti najrelevantnija pravila, uvesti zastarjele smjernice i otežati reviziju rezultata.

Bolji je pristup dohvaćati kontekst na temelju posla koji se obavlja. Pomoćniku za migraciju baze podataka mogu trebati vlasništvo nad shemom, konvencije migracije i zahtjevi za vraćanje na prethodno stanje. Pomoćniku za korisničko sučelje mogu trebati dizajnerski sustav, smjernice za pristupačnost i postojeći testovi komponente. Isti model može podržati oba zadatka, ali okolni sustav trebao bi pružiti različite dokaze.

• Stabilna načela: sigurnosni zahtjevi, arhitektonske granice i standardi kodiranja.
• Činjenice specifične za zadatak: pogođene datoteke, sučelja, tiketi i ograničenja implementacije.
• Svježi signali: trenutačni status testova, rezultati lintanja, stanje usluga i povratne informacije iz pregleda.

Razdvajanje tih slojeva olakšava utvrđivanje zašto je umjetna inteligencija dala preporuku i ažuriranje sustava kada se konvencija promijeni.

Pretvorite povratne informacije u bolje buduće ponašanje

Radni tijek učenja treba povratnu spregu, a ne samo gumb za odobravanje. Ako recenzent opetovano traži od umjetne inteligencije da izbjegava zastarjeli paket, dodajte to pravilo u izvor istine. Ako generirane promjene često ne obuhvaćaju integracijski test, poboljšajte predložak zadatka ili korak evaluacije. Ako umjetna inteligencija pogrešno utvrdi vlasništvo nad uslugom, popravite podatke o vlasništvu umjesto da se nadate kako će dulji upit to riješiti.

To je poznata inženjerska disciplina. Produkcijski sustavi poboljšavaju se kada neuspjesi postanu vidljivi, kategorizirani i riješeni na ispravnoj razini. Radni tijekovi omogućeni umjetnom inteligencijom zaslužuju isti tretman.

Na primjer, od agenta koji predlaže promjenu koda može se zahtijevati da prije uređivanja izradi kratak plan:

Cilj: dodati pravilo provjere za nazive računa
Pogođeno područje: API za stvaranje računa
Ograničenja: sačuvati postojeći format odgovora o pogrešci
Provjera: jedinični testovi, testovi API ugovora, statička analiza
Vraćanje na prethodno stanje: ukloniti put provjere iza zastavice značajke

Plan nije birokracija. Recenzentu daje nešto konkretno što može osporiti prije nego što se napravi opsežna promjena. Također rano otkriva nedostajući kontekst: možda ne postoji zastavica značajke ili API ugovor nije dokumentiran.

Agentima dajte ovlasti razmjerne mogućnosti poništavanja

Autonomija treba odgovarati cijeni pogreške. Agent obično može oblikovati kod, pripremiti nacrt ili otvoriti predloženu promjenu uz malo rizika. Ažuriranje produkcijskih podataka, izmjena kontrola pristupa ili implementacija infrastrukture zaslužuju znatno strože kontrole.

Timovi to često predstavljaju kao binarni izbor između potpuno autonomnih agenata i ručne upotrebe alata za razgovor. Korisniji je model gradijent ovlasti.

1. Čitati i objašnjavati informacije.
2. Izrađivati nacrte artefakata za ljudski pregled.
3. Raditi promjene u izoliranoj grani ili sandboxu.
4. Pokretati ograničene korake provjere.
5. Izvoditi poništive radnje uz izričite provjere pravila.
6. Eskalirati nepovratne radnje ili radnje velikog utjecaja odgovornoj osobi.

Na svakoj razini definirajte dopuštene alate, očekivane dokaze i uvjete za zaustavljanje. Agent koji ne može potvrditi preduvjet trebao bi sigurno ne uspjeti i objasniti što mu je potrebno. Tiho nagađanje unatoč nedostajućim dozvolama ili dvosmislenim zahtjevima nije inteligencija; to je operativni nedostatak.

Dizajnirajte za neslaganje, a ne samo za uspjeh

Kvalitetan rad na softveru uključuje neizvjesnost. Sposobna umjetna inteligencija trebala bi moći reći da su dva pristupa uvjerljiva, utvrditi kompromis i zatražiti odluku kada izbor utječe na ponašanje proizvoda ili rizik.

To je posebno važno kada su zahtjevi nepotpuni. Razmotrite uputu da se „uvoz učini bržim”. Ispravan sljedeći korak može biti profiliranje, provjera upita baze podataka, pregled ograničenja veličine datoteka ili pojašnjenje cilja izvedbe. Generiranje predmemorije zato što je predmemoriranje poznato može stvoriti pogreške sa zastarjelim podacima bez rješavanja uskog grla.

Dobri sustavi umjetne inteligencije čuvaju tu disciplinu. Razlikuju opažene činjenice od pretpostavki, povezuju preporuke s dokazima i ističu odluke koje pripadaju ljudima. Takvo ponašanje gradi povjerenje mnogo pouzdanije od samouvjerenog teksta.

Trajna prednost jest organizacijsko učenje

Stvarno obećanje umjetne inteligencije u dizajnu softvera nisu brži pritisci tipki. Ono je smanjivanje udaljenosti između onoga što je tim naučio i toga koliko se dosljedno to učenje primjenjuje.

Kada arhitektonske odluke, obrasci pregleda, operativne zaštitne mjere i ograničenja proizvoda ostanu zarobljeni u pojedinačnom pamćenju, svaki novi suradnik djelomično počinje od nule. Pažljivo dizajniran sustav umjetne inteligencije može to znanje učiniti lakšim za pronalaženje, primjenu i poboljšavanje — bez pretvaranja da se prosudba može automatizirati.

Izgradite umjetnu inteligenciju koja dobro izvršava zadatke, svakako. No izgradite i okolni model povratnih informacija, konteksta, provjere i ovlasti koji joj omogućuje da nauči kako vaš softver treba biti izrađen. Tu korisna automatizacija postaje pouzdan inženjerski partner.