Chatbot može objasniti kako refaktorirati uslugu plaćanja. AI agent može pregledati repozitorij, izvršiti promjenu u povezanim datotekama, pokrenuti skup testova, protumačiti neuspjeh, prilagoditi svoj pristup i pripremiti zakrpu spremnu za pregled. Upravo tu razlika razgovor o AI-ju u softverskom radu čini mnogo zanimljivijim.

Korisno pitanje više nije može li model generirati kôd. Mnogi mogu. Praktično je pitanje može li sustav ograničeni dio posla pomaknuti prema provjerenom ishodu bez potajnog stvaranja novog rizika.

Što AI sustav čini agentom?

Agent nije samo sučelje za razgovor s duljim promptom. To je model koji djeluje u petlji: prima cilj, opaža relevantno stanje, odabire radnju, procjenjuje rezultat i nastavlja dok ne dosegne uvjet za zaustavljanje ili ne zatreba pomoć.

Za rad s kôdom te radnje mogu uključivati čitanje datoteka, pretraživanje simbola, uređivanje manjeg skupa datoteka, pokretanje testova, provjeru formatiranja ili otvaranje zahtjeva za povlačenje. Važna nije autonomija radi nje same. Važna je sposobnost korištenja povratnih informacija iz stvarnog razvojnog okruženja.

Pomoćnik za generiranje kôda koji predloži funkciju na temelju zalijepljene poruke o pogrešci koristan je. Agent koji pokrene test koji ne prolazi, prati put poziva, predloži minimalnu ispravku i izvijesti točno što je provjerio može biti koristan na drugačiji, operativniji način.

Ciklus isporuke važniji je od demonstracije

Impresivne demonstracije često počinju jasnim zahtjevom, a završavaju kôdom koji djeluje uvjerljivo. Produkcijski rad počinje usred procesa: s nepotpunim zahtjevima, nepoznatim konvencijama, zastarjelim testovima, razlikama u okruženju i ovisnostima zbog kojih je lokalni popravak nesiguran.

Sposoban agent za programiranje treba ograničen ciklus isporuke:

• Razumjeti zadatak: utvrditi namjeravano ponašanje, opseg i kriterije prihvaćanja.
• Ispitati kontekst: pronaći relevantni kôd, testove, konfiguraciju i projektne konvencije.
• Planirati malu promjenu: dati prednost najužoj promjeni koja može ispuniti zahtjev.
• Djelovati putem odobrenih alata: uređivati, testirati, lintati, graditi ili upitivati samo sustave za koje ima ovlaštenje.
• Provjeriti rezultat: koristiti automatizirane provjere i izvijestiti što je prošlo, nije prošlo ili ostaje neizvjesno.
• Primjereno eskalirati: zaustaviti se kada zadatak zahtijeva odluku o proizvodu, povlašteni pristup ili rizičnu širu promjenu.

Ova petlja pretvara model iz izvora isječaka u sudionika softverskog procesa. Također olakšava procjenu njegova rada. Zakrpa s jasnim sažetkom, fokusiranim diffom i izričitom provjerom znatno je vrjednija od samouvjerenog odgovora bez dokaza.

Počnite s radom koji ima jasne granice

Najbolji početni slučajevi uporabe repetitivni su ili dobro specificirani zadaci s brzom povratnom informacijom. To mogu biti dodavanje testova oko postojećeg ponašanja, ažuriranje klijenta nakon dokumentirane promjene API-ja, rješavanje usko ograničenog lint problema ili izvođenje mehaničke migracije koju mogu provjeriti prevoditelj i skup testova.

Primjerice, agent kojem je zadano da doda validaciju krajnjoj točki ne bi smio odmah prepisati sloj kontrolera. Trebao bi pronaći rutu, pregledati postojeće obrasce validacije, dodati najmanju dosljednu promjenu i pokrenuti relevantne testove. Ako testovi ne postoje, trebao bi to reći umjesto da odsutnost povratne informacije smatra dokazom ispravnosti.

Mali zadaci nisu samo sigurniji. Oni tim uče što agent doista može učiniti u njihovu okruženju: koliko dobro slijedi lokalne konvencije, jesu li njegove dozvole za alate dovoljne i gdje njegove pretpostavke najčešće ne uspijevaju.

Dajte agentu definiciju dovršenosti

Nejasni zahtjevi potiču opsežne promjene. „Poboljšaj autentikaciju” tema je za dizajnersku raspravu. „Odbij istekle tokene prije učitavanja korisničkog zapisa, zadrži trenutačni oblik odgovora i dodaj pokrivenost za istekli token” izvršiva je jedinica rada.

Korisni sažetak zadatka uključuje očekivano ponašanje, relevantna ograničenja, dopuštene datoteke ili sustave kada je to prikladno te provjere koje bi trebale proći. Cilj nije napisati skriptu za svaki pritisak tipke. Cilj je učiniti uspjeh vidljivim.

Cilj: Dodajte obavezno ime za prikaz pri stvaranju računa.

Ograničenja:
- Sačuvajte postojeće konvencije odgovora o pogrešci.
- Ne mijenjajte shemu baze podataka.
- Dodajte fokusirane testove za nedostajuća i valjana imena za prikaz.

Dovršeno kada:
- Relevantni testovi prolaze.
- Provjere formatiranja prolaze.
- Sažetak promjene navodi izmijenjene datoteke i izvršenu provjeru.

Autonomiji trebaju zaštitne ograde, a ne slijepo povjerenje

Agenti mogu griješiti brzinom stroja. Zato su dozvole i pravila za zaustavljanje dio dizajna proizvoda, a ne naknadna misao. Agent koji može čitati izvorni kôd i pokretati testove ima vrlo drukčiji profil rizika od onoga koji može mijenjati produkcijsku infrastrukturu, rotirati vjerodajnice ili spojiti vlastite promjene.

Koristite pristup s najmanjim ovlastima. Odvojite okruženja. Zahtijevajte pregled za promjene koje utječu na sigurnost, podatke, naplatu, komunikaciju s korisnicima ili implementaciju. Čuvajte zapise radnji alata i izlaza naredbi kako bi čovjek mogao rekonstruirati što se dogodilo.

Također je mudro razlikovati reverzibilne i nepovratne radnje. Uređivanje grane obično je moguće oporaviti. Brisanje podataka ili objavljivanje izdanja možda nije. Agent bi trebao moći predložiti potonje, a da ga ne može automatski izvršiti.

Agent kojem se najviše može vjerovati nije onaj koji tvrdi da je siguran. To je onaj koji neizvjesnost učini vidljivom dovoljno rano da osoba može donijeti ispravnu odluku.

Provjera je središte odgovornog usvajanja

Generirani kôd treba tretirati kao svaki drugi doprinos: pregledati diff, provjeriti rubne slučajeve i pokrenuti relevantne provjere. Razlika je u tome što agent često može sudjelovati i u toj petlji provjere.

Testovi, provjere tipova, linteri, izgradnje i pregledi implementacije daju agentu objektivne signale. No provjere koje prolaze nisu cijela priča. Skup testova može propustiti granicu autorizacije, neispitani put migracije ili zahtjev koji nikada nije zapisan. Ljudski pregled ostaje nužan ondje gdje su važni kontekst i prosudba.

Timovi postižu bolje rezultate kada od agenata traže da objasne svoje dokaze. Snažno dovršenje navodi koji su testovi pokrenuti, što se promijenilo i koje su pretpostavke donesene. Slabo dovršenje kaže samo da je zadatak dovršen.

Dizajnirajte za suradnju, a ne za zamjenu

Trajna vrijednost agenata za programiranje vjerojatno neće biti u tome da eliminiraju inženjersku prosudbu. Njihova je vrijednost u tome što smanjuju trenje između namjere i provjerene prve implementacije.

To može osloboditi programere da više vremena posvete dizajnu sustava, kompromisima proizvoda, pouzdanosti, sigurnosti i mentoriranju. Također može pomoći ambicioznim nestručnjacima da jasno opisani tijek rada pretvore u prototip, pod uvjetom da razumiju ograničenja proizvedenoga i uključe odgovarajući pregled prije uporabe u stvarnom svijetu.

Organizacije koje će imati najviše koristi neće biti one koje svaki zadatak predaju autonomnom sustavu. To će biti one koje izgrade dobre petlje povratnih informacija, održavaju zdrave testove i dokumentaciju, jasno definiraju vlasništvo i agentima daju posao koji odgovara njihovim dokazima.

Isporuka kôda je disciplina

Izvan chatbota, AI agenti predstavljaju prijelaz s odgovaranja na pitanja na izvršavanje ograničenog rada. Taj prijelaz ima značenje samo kada sustav može opažati stvarnost, unositi odgovorne promjene i dokazati dovoljno svojega rezultata da zasluži povjerenje.

Počnite malim koracima. Mjerite kvalitetu, a ne samo brzinu. Zadržite ljude odgovornima za odluke sa stvarnim posljedicama. Kada je agent ugrađen u discipliniranu inženjersku petlju, može postati nešto korisnije od pametnog razgovornog alata: pouzdan način da se dobro definiran rad pomakne od namjere do testiranog kôda.