Softverski timovi ne dodaju jednostavno još jedan alat u svoj tijek rada. Dobivaju novu vrstu kapaciteta: AI agente koji mogu pregledati bazu koda, izraditi nacrt promjene, pokrenuti test, sažeti neuspjeh i vratiti posao na pregled. Važan pomak nije u tome što agent može proizvesti kod. Već u tome što netko mora odlučiti koji je posao vrijedan delegiranja, koji se dokazi računaju kao dovršenost i kada automatizacija mora stati.

Ta osoba sve češće postaje orkestrator. Za programere, tehničke voditelje i ambiciozne stručnjake, orkestriranje AI agenata moglo bi postati jednako temeljno kao koordiniranje usluga, pregledavanje pull requestova ili dizajniranje API-ja. To je praktična izvršna uloga, a ne nejasan sloj upravljanja.

Od promptanja do usmjeravanja sustava

Jedan prompt je zahtjev. Orkestracija je tijek rada s granicama, ulazima, kontrolnim točkama i odgovornim ishodom.

Razmotrite zahtjev za dodavanje revizijskog zapisa administrativnoj radnji. Sposoban agent mogao bi pronaći relevantne krajnje točke, predložiti promjenu sheme, izmijeniti aplikacijski kod i napisati testove. No ne bi smio samostalno odlučiti o politici zadržavanja, izložiti osjetljiva polja ili spojiti nepregledanu migraciju. To su odluke o proizvodu, sigurnosti i operacijama.

Orkestrator dijeli posao na promišljene faze:

1. Definirajte korisnički i operativni ishod.
2. Navedite relevantna ograničenja, kao što su klasifikacija podataka, postojeće konvencije i pravila implementacije.
3. Delegirajte ograničene zadatke s vidljivim rezultatima.
4. Pregledajte dokaze iz testova, diffova, zapisnika i provjera koje obavljaju ljudi.
5. Upravljajte neizvjesnošću, eskalacijom i odlukama o izdanju.

To nalikuje dobrom inženjerskom vodstvu jer to i jest dobro inženjersko vodstvo. AI mijenja brzinu i opseg izvršavanja; ne uklanja potrebu za prosudbom.

Dodijelite agentima uske zadatke i izričite ugovore

Agenti najbolje rade kada njihov zadatak ima jasan opseg i definiciju dovršenosti. “Poboljšajte naš tijek autentikacije” potiče široke pretpostavke. “Pratite put zahtjeva za poništavanje lozinke, utvrdite gdje se provodi ograničavanje brzine i prijavite relevantne datoteke bez njihova mijenjanja” daje korisnu istragu.

Za implementacijske zadatke navedite ugovor u uvjetima koji se mogu provjeriti. Uključite što se smije promijeniti, što se ne smije promijeniti, kako će se uspjeh provjeriti i kada agent treba zastati.

Zadatak: Dodajte provjeru valjanosti za polje imena za prikaz.

Opseg:
- Promijenite samo obrađivač ažuriranja profila i njegove testove.
- Sačuvajte postojeće oblike API odgovora.
- Ne mijenjajte shemu baze podataka ni zajedničke pomoćne programe za provjeru valjanosti.

Kriteriji prihvaćanja:
- Odbijte prazna imena nakon uklanjanja razmaka.
- Prihvatite postojeća valjana imena.
- Dodajte usmjerene testove za oba slučaja.
- Pokrenite relevantnu naredbu za testiranje i prijavite rezultat.

Zaustavite se i pitajte ako se na trenutačno ponašanje oslanja druga krajnja točka.

Ovo nije birokracija. Sprječava agenta da vjerojatno tumačenje smatra ovlaštenjem. Ista disciplina olakšava i predaje među ljudima: drugi inženjer može razumjeti namjeru bez rekonstruiranja iz transkripta chata.

Koristite razlaganje za stvaranje pouzdanog zamaha

Veliki zahtjevi često miješaju istraživanje, dizajn, implementaciju, testiranje i implementaciju u produkciju. Traženje od jednog agenta da obavi sve to može prikriti slabe pretpostavke do kasno u procesu. Umjesto toga, stvorite slijed u kojem svaki korak smanjuje neizvjesnost za sljedeći.

Praktičan obrazac isporuke

• Istražite: Mapirajte relevantne putove koda, ovisnosti i postojeće konvencije.
• Planirajte: Pretvorite nalaze u mali plan implementacije s rizicima i otvorenim pitanjima.
• Implementirajte: Napravite ograničenu promjenu prema odobrenom planu.
• Provjerite: Najprije pokrenite usmjerene testove, zatim šire provjere primjerene promjeni.
• Pregledajte: Ispitajte diff radi ispravnosti, održivosti, sigurnosti i nenamjernog proširenja opsega.
• Objavite: Koristite uobičajene kontrole implementacije, nadzora i planiranje vraćanja na prethodno stanje.

Različiti agenti mogu pomoći u različitim fazama, ali paralelizam treba zaslužiti. Dva agenta mogu neovisno pregledati bazu koda ili usporediti mogućnosti implementacije. Ne bi trebali oboje mijenjati isto područje osim ako postoji jasan plan integracije. Brže sukobljene promjene i dalje su sukobljene promjene.

Neka provjera bude središte tijeka rada

Najopasniji izlaz agenta nije očito loš kod. To je rad uvjerljivog izgleda koji nije smisleno provjeren. Tečna objašnjenja mogu stvoriti povjerenje bez stvaranja dokaza.

Gradite tijekove rada oko provjera koje je teško glumiti: automatiziranih testova, statičke analize, provjera tipova, validacije migracija, pregleda implementacije i ciljanih ručnih testova. Tražite od agenata da prijave izvršene naredbe, izlaze relevantne za uspjeh ili neuspjeh, promijenjene datoteke i pretpostavke koje su iznijeli. Zatim pregledajte rezultat, umjesto da samo prihvatite sažetak.

Provjera treba odgovarati riziku. Promjena teksta može zahtijevati vizualnu potvrdu. Promjena naplate može zahtijevati pokrivenost testovima za slučajeve neuspjeha, ponašanje idempotentnosti i mogućnost revizije. Migracija baze podataka može zahtijevati strategiju vraćanja na prethodno stanje i plan za podatke koji su već u produkciji. Agent može pomoći pripremiti te dokaze, ali odgovornost za odluku da su dokazi dovoljni ostaje na čovjeku.

Dizajnirajte za neuspjeh prije nego što se dogodi

Tijekovi rada s agentima ne uspijevaju na uobičajene načine: kontekst je nepotpun, repozitorij sadržava iznenađujuće konvencije, testno okruženje nije dostupno ili je zahtjev u sukobu s postojećim ponašanjem. Zreo sustav ne zahtijeva da agent improvizira kroz svaku prepreku. Definira putove eskalacije.

Korisni uvjeti za zaustavljanje uključuju zahtjeve za novim vjerodajnicama, pristup produkciji, destruktivne naredbe, dvosmislene odluke o politici, neočekivane promjene sheme, neuspješne testove izvan navedenog opsega i svaku radnju koja bi mogla izložiti podatke kupaca. U tim trenucima ispravan izlaz je sažeto pitanje s potkrepljujućim dokazima, a ne herojsko nagađanje.

I ponavljanja zaslužuju oprez. Ponovno pokretanje zadatka analize može biti bezopasno. Ponovno pokretanje zadatka koji šalje e-poštu, stvara plaćanje ili mijenja infrastrukturu može duplicirati vanjski učinak. Radnje s nuspojavama tretirajte kao izričite operacije s identifikatorima, potvrdom i, gdje je moguće, idempotentnim ponašanjem.

Vještine koje su najvažnije

Orkestriranje agenata nagrađuje tehničku tečnost, ali ne samo tehničku tečnost. Najuspješniji praktičari mogu oblikovati problem, razlikovati činjenice od pretpostavki, prepoznati kada je zahtjev nedovoljno specificiran i jasno komunicirati odluke kroz proizvod, dizajn, sigurnost i operacije.

Oni također razumiju sustav ispod agenta: upravljanje izvornim kodom, strategiju testiranja, CI cjevovode, dozvole, tajne, nadzor i kontrole implementacije. Agent može ubrzati rad unutar tih sustava. Ne može sigurno zamijeniti zaključivanje koje ih povezuje.

Korisna je navika sačuvati kontekst odluke blizu rada. Zabilježite zašto ograničenje postoji, koje su alternative odbačene i koji rizik ostaje. To štiti sljedećeg ljudskog recenzenta i sljedećeg agenta od ponavljanja stare pogreške s novim samopouzdanjem.

Nova poluga je odgovorno usmjeravanje

AI agenti mogu iznimno brzo pretvoriti dobro oblikovan zadatak u opipljiv napredak. To čini jasnoću vrijednijom, a ne manje vrijednom. Razlika neće biti u tome tko može zatražiti od AI-ja najveću promjenu. Bit će u tome tko može oblikovati pouzdan put od namjere do dokaza do izdanja.

Sljedeća uloga u izvršavanju softvera stoga nije pasivni nadzor. To je odgovorno usmjeravanje: postavljanje cilja, dizajniranje zaštitnih ograda, zahtijevanje dokaza i prepoznavanje kada je ljudska odluka najvažniji korak u sustavu.