Agentski inženjering u praksi: specifikacije, kontekst, verifikacija i vlasništvo

„Agentski inženjering“ se često predstavlja kao ishod: agenti grade softver. Po našem iskustvu, to je skup praksi. Agenti preuzimaju jasno ograničene zadatke; ljudi odlučuju koji su to zadaci, proveravaju rezultate i ostaju odgovorni za ono što stigne u produkciju. Bez tih praksi, brzina se pretvara u ponovni rad.

Ovaj tekst opisuje četiri prakse koje primenjujemo na svakom projektu: specifikaciju, zajednički kontekst, verifikaciju i vlasništvo. Nijedna od njih nije nova. Ono što se sa agentima menja je koliko strogo moraju da se poštuju.

1. Specifikacija: svaki zadatak počinje u pisanoj formi

Agent ne može da pita product menadžera šta je mislio. Zato, pre nego što agent dotakne kod, inženjer piše kratku specifikaciju zadatka.

Task: Add organization invitations by email
Scope: api/invitations/*, web/settings/members/*
Out of scope: billing, SSO
Constraints:
  - active organization comes from the session, never the request body
  - invitation tokens expire after 7 days
Checks:
  - unit tests for expiry and reuse
  - an admin of org A cannot invite into org B
  - typecheck and lint pass

Specifikacija postavlja granicu, a ne samo cilj. Fajlovi van obima ostaju netaknuti; sve što agent predloži van te granice odbacuje se, koliko god razumno delovalo.

2. Zajednički kontekst: odluke žive u repozitorijumu

Agenti rade na osnovu onoga što mogu da pročitaju. Ako su razlozi iza arhitekture u nečijoj glavi ili u nekoj staroj chat prepisci, agent će ih izmisliti iznova, obično drugačije. Kratke zapise o odlukama, beleške o arhitekturi i konvencije pisanja koda čuvamo u repozitorijumu, pored koda.

• Zapisi o odlukama objašnjavaju zašto: „Tenancy se sprovodi u bazi podataka, kao i u API-ju, zato što…“
• Beleške o arhitekturi opisuju granice: koji modul je vlasnik kojih podataka.
• Konvencije pokrivaju obradu grešaka, imenovanje i obrasce testiranja.

Isti fajlovi pomažu i novom inženjeru već prvog dana. Ispostavlja se da je kontekst napisan za agente zapravo kontekst napisan za ljude.

3. Verifikacija: ništa se ne spaja na poverenje

Svaka izmena agenta stiže kao običan pull request. Pre nego što je čovek pregleda, pokreću se automatske provere: provera tipova, linting i testovi navedeni u specifikaciji. Zatim inženjer čita diff red po red.

Preferiramo male izmene. Izmenu agenta od 2.000 redova nije moguće pravilno pregledati, pa umesto toga delimo posao. Kritični fajlovi, poput onih za autentifikaciju, naplatu i migracije, dobijaju dodatnog recenzenta.

4. Dozvole i vlasništvo

Agenti dobijaju dozvole koje su zadatku potrebne i ništa više: čitanje repozitorijuma, pokretanje testova, otvaranje pull request-a. Ne dobijaju produkcione kredencijale, prava za deploy niti pristup skladištima podataka klijenta.

Za svaku izmenu koja stigne u produkciju odgovoran je imenovani inženjer. Ako nešto otkaže u 2 ujutru, odgovor na pitanje „ko ovo razume?“ je čovek, a ne alat.

Gde agenti najviše pomažu, a gde ne

Kada se koriste na ovaj način, agenti skraćuju dobro definisan posao, što je deo razloga zašto možemo da se obavežemo na prvo izdanje za 30 dana za fiksni obim. Metod je važniji od alata. Pročitajte više o isporuci uz pomoć AI-ja ili, ako želite AI u sopstvenim tokovima rada, pogledajte AI automatizaciju.