Autor: Kwame Boateng
Kodiranje uz pomoć veštačke inteligencije često se opisuje kao brža verzija programiranja u paru. To poređenje je sada preusko. Kada agent može da pregleda repozitorijum, izmeni više datoteka, pokrene alate, generiše pregled i otvori zahtev za povlačenje, osnovni problem saradnje više nije samo „Može li da napiše kod?“ Već glasi: „Mogu li ljudi da vide, pregledaju, odobre i kasnije rekonstruišu šta se dogodilo?“
Zato je najvažniji pomak u dizajnu timova za razvoj softvera uz pomoć agenata možda prelazak sa privatnih upita na vidljive radne prostore. Slack Code se, na primer, opisuje kao kombinacija projektnih kanala sa agentima za kodiranje, revizijom razlika u kodu, pregledima HTML-a uživo, tokovima povratnih informacija i odobravanja, automatskim arhiviranjem i dnevnicima revizije. GitHub-ova aplikacija Copilot takođe je dodala okno „Moj rad“ za organizovanje problema i zahteva za povlačenje kroz više projekata. Ove funkcije ukazuju na praktično načelo: rad agenta treba manje da liči na neproziran odgovor, a više na skup izmena koji prolazi kroz kontrolisani proizvodni proces.
Čet nije evidencija rada
Razgovor sa agentom može biti koristan za istraživanje ideje, ali je slab sistem evidencije. Važni detalji mogu ostati zatrpani u dugoj niti: koje su datoteke izmenjene, koje su komande pokrenute, koje je pretpostavke agent napravio, šta je recenzent odbio i da li se konačni rezultat razlikuje od prvog predloga.
Trajni radni prostor omogućava pregled tih detalja. Trebalo bi da poveže zahtev sa konkretnim repozitorijumom ili projektom, sačuva plan agenta, prikaže radnje alata i izmene datoteka, poveže testove i preglede i zabeleži ko je odobrio rezultat. Tačan interfejs može da varira — alat za praćenje problema, zahtev za povlačenje, kanal za saradnju ili konzola agenta — ali informacije bi trebalo da ostanu dostupne i nakon završetka sesije.
Ovo je važno iz uobičajenih inženjerskih razloga, a ne samo zbog usklađenosti sa propisima. Ako se greška pojavi dve nedelje kasnije, timu je potrebno više od konačne razlike. Možda će morati da zna prvobitni zahtev, generisani plan, dokaze iz testiranja, komentare recenzenta i da li je čovek izričito prihvatio rizičan kompromis. Trajna evidencija skraćuje tu istragu.
Pet slojeva vidljivog rada
Timovi koji uvode agente za kodiranje mogu svaku izmenu posmatrati kao mali, pregledni predmet. Posebno je korisno pet slojeva:
- Namera: problem, kriterijumi prihvatanja, ograničenja i traženi obim.
- Plan: predloženi pristup agenta pre nego što izmeni datoteke. Kod netrivijalnog zadatka, ovo je kontrolna tačka za odobrenje, a ne ukras.
- Razlika: tačne dopune, brisanja, izmene zavisnosti, izmene konfiguracije i generisana sredstva.
- Dokazi: rezultati testova, izlaz lintera, bezbednosne provere, snimci ekrana i pregled uživo ili pregled koji može da se postavi, gde je to relevantno.
- Evidencija odluka: komentari recenzenta, zahtevane izmene, odobrenje, odbijanje, vraćanje na prethodno stanje ili naknadni rad.
Poenta nije u tome da se svaka izmena primorava da prolazi kroz glomazni odbor. Pravopisna greška i izmena toka plaćanja ne bi trebalo da imaju identične kontrole. Poenta je da nivo pažnje bude srazmeran mogućem uticaju.
Odobrenja treba povezati sa radnjama
„Čovek u petlji“ je previše neodređeno da bi predstavljalo korisnu kontrolu. Osoba može da odobri plan, a da ne vidi konačnu razliku, ili da odobri izmenu koda, a da ne primeti da je agent takođe izmenio datoteku za postavljanje. Bolji tokovi rada jasno navode šta odobrenje dozvoljava.
Na primer, tim može agentu automatski dozvoliti da čita repozitorijum i pokreće lokalne testove, zahtevati odobrenje pre pisanja izvan određene grane i zahtevati posebno odobrenje pre spajanja ili postavljanja. Agent može predložiti migraciju baze podataka, ali mu može biti zabranjeno da je izvrši u produkciji. Predloženi pristup Ujedinjenih Arapskih Emirata klasifikovanju zadataka koje agenti mogu da dovrše nasuprot onima koje mogu samo da preporuče odražava ovaj širi obrazac: autonomiju treba dodeljivati po zadatku, a ne podrazumevati je na globalnom nivou.
Odobrenja takođe moraju imati obim i rok važenja. Odobrenje za „ažuriranje teksta početne stranice“ ne bi trebalo nečujno da ovlasti dodavanje novog analitičkog paketa. Plan odobren juče ne bi danas automatski trebalo da obuhvati materijalno izmenjenu razliku. Interfejs bi trebalo da učini te granice vidljivim.
Pregledi pretvaraju reviziju u inspekciju
Pregled koda je često lakši kada ljudi mogu da pregledaju rezultat umesto da ga zaključuju iz izvornih datoteka. HTML pregled uživo može da otkrije neispravan razmak, nedostajuća stanja, nedostupne kontrole ili nenamernu izmenu navigacije koju bi recenzent mogao da previdi u tekstualnoj razlici.
Pregledi nisu dokaz ispravnosti. Trebalo bi da stoje uz testove i pregled izvornog koda, a ne da ih zamene. Ali oni stvaraju zajednički predmet za diskusiju: recenzent može da ukaže na konkretan ekran, stanje ili interakciju i ostavi povratnu informaciju povezanu sa predloženom izmenom.
Ovo je naročito vredno kada su u pregled uključeni i nestručnjaci. Menadžer proizvoda možda neće moći da proceni izmenu okvira, ali može biti prava osoba da potvrdi da tok rada odgovara zahtevu. Dizajner može da potvrdi vizuelnu regresiju. Stručnjak za bezbednost može da se usredsredi na dozvole i rukovanje podacima. Radni prostor uz pomoć agenta može svako pitanje da usmeri osobi koja je u najboljoj poziciji da na njega odgovori.
Razlikama je potreban kontekst, ne samo boja
Poznata razlika u crvenoj i zelenoj boji i dalje je ključna, ali izmene koje generiše agent mogu biti dovoljno široke da preopterete recenzenta. Timovi bi trebalo da traže od agenata da komitove ili grupe izmena održavaju uskim, da objasne zašto je svaka značajna datoteka izmenjena i da generisane ili dobavljačke datoteke označe zasebno.
Korisna pitanja za pregled obuhvataju:
- Koje ponašanje vidljivo korisniku se promenilo?
- Koje datoteke su izmenjene isključivo radi podrške implementaciji?
- Koje je pretpostavke agent napravio o postojećem ponašanju?
- Koji testovi su dodati, izmenjeni ili nisu pokrenuti?
- Da li bi ova izmena mogla da utiče na dozvole, zadržavanje podataka, naplatu ili spoljne API-je?
Ova pitanja pretvaraju pregled iz neodređenog zahteva „pogledaj ovo“ u ponovljivo ispitivanje. Ona takođe pomažu da se otkrije čest način greške: naizgled uverljiva funkcionalnost praćena nepotpunim ažuriranjem testova ili slučajnom izmenom konfiguracije.
Arhivirajte obrazloženje koje je važno
Očuvanje svakog tokena iz svakog razgovora sa modelom nije samo po sebi korisno. Duge istorije mogu biti skupe za čuvanje i teške za pretraživanje, dok istraživanja o sažimanju konteksta upozoravaju da sažeci mogu izgubiti važne informacije. Zato bi praktičan revizorski trag trebalo da čuva artefakte relevantne za donošenje odluka, umesto da neselektivno sačuva sve.
U najmanju ruku, zadržite zahtev, odobreni plan, konačni diff, rezultate alata i testova, referencu za pregled ili postavljanje, odluke pregledalaca i svaki odobreni izuzetak. Ako je agent koristio spoljne izvore ili preuzeo interne dokumente, zabeležite relevantne reference na izvore i trenutak u kojem su uticali na izmenu. Za rad visokog rizika može biti opravdano zadržati kompletnu evidenciju interakcije i izvršavanja.
Učinite zapise očigledno zaštićenim od neovlašćenih izmena tamo gde to zahteva nivo rizika i definišite pravila zadržavanja pre nego što nastupi kriza. Revizorski trag koji nestane kada se kanal arhivira — ili koji ne može da razlikuje izmenjeni rezultat od prvobitnog — neće podržati ozbiljnu istragu.
Šta se ovim menja za karijere u softveru
Veština koja se pojavljuje nije samo pisanje boljih upita. Reč je o osmišljavanju rada koji druga osoba može da pregleda i kojem može da veruje. Programeri će morati da se osećaju sigurno pri definisanju kriterijuma prihvatanja, razlaganju zadataka, pregledu diffova velikih razmera, izradi smislenih testova i odlučivanju o tome gde agent mora da stane i postavi pitanje.
Stručnjaci za proizvode i dizajn imaće veću ulogu u pregledanju pregleda i razjašnjavanju namere. QA inženjeri mogu pomoći u definisanju kontrolnih tačaka za odobrenje i slučajeva greške. Menadžeri inženjeringa moraće da mere protok rada bez nagrađivanja preuzimanja nevidljivih rizika. Tehnički pisci i stručnjaci za operacije mogu doprineti tako što će odluke, izuzetke i operativna uputstva učiniti trajnim.
Jedna korisna vežba jeste da uzmete rutinsku funkcionalnost i mapirate njen lanac dokaza: zahtev, plan, granu, diff, testove, pregled, odobrenje, izdanje i vraćanje na prethodnu verziju. Zatim se zapitajte gde bi budući član tima bio primoran da nagađa. Svako nagađanje je kandidat za bolje radno okruženje, jasniju dozvolu ili trajniji zapis.
Jednostavno operativno pravilo
Omogućite agentima da se brzo kreću unutar vidljivog prostora iz kojeg se promene mogu poništiti. Obezbedite im definisano radno okruženje, ograničite osetljive radnje, zahtevajte odobrenje na značajnim granicama, priložite dokaze uz izmenu i sačuvajte konačnu odluku. Cilj nije usporiti automatizaciju dok ne počne da liči na ručno programiranje. Cilj je učiniti brzinu kompatibilnom sa odgovornošću.
U razvoju potpomognutom agentima, najbolji saradnik nije sistem koji samostalno proizvede najviše koda. To je sistem čiji rad može da se razume, preispita, odobri, poništi i iz kojeg se može učiti.
