Šta razvoj uz AI agente znači u praksi
Agentic engineering, ili razvoj uz AI agente, naš je naziv za način rada u kojem iskusni inženjeri izrađuju softver uz AI agente za programiranje kao što su Claude Code i Codex. Agent čita kod, piše kod, pokreće testove i ponavlja taj krug. Inženjer odlučuje šta se izrađuje, kako se to uklapa u arhitekturu i da li je rezultat dovoljno dobar za merge.
Ovaj članak je za CTO-e, osnivače i vođe inženjerskih timova koji žele znati kako to izgleda na stvarnom SaaS proizvodu, gdje se kod mora održavati godinama. Autocomplete predlaže sljedeću liniju. AI agent za programiranje može preuzeti dobro definisan zadatak, izmijeniti desetak fajlova, pokrenuti testove i vratiti pull request. Vrijeme inženjera manje odlazi na kucanje, a više na specifikaciju, pregled i odluke.
Mijenja se i ono što može poći po zlu. Agenti brzo pišu kod koji izgleda uvjerljivo, pa i kod koji je uvjerljiv, a suptilno pogrešan. Prakse u nastavku su način na koji dobijamo brzinu, a kvalitet držimo tamo gdje treba biti.
Zadatke definišite kao za novog člana tima
Agenti najbolje rade na zadacima s jasnim ciljem, jasnim granicama i načinom da se rezultat provjeri. Teško im idu nejasni zahtjevi koji traže produktnu procjenu ili zahvataju cijeli sistem.
- Prave veličine: jedan dio funkcije, jedna migracija ili jedan integracijski endpoint. Nešto što iskusni inženjer može pregledati za 15 do 30 minuta.
- S granicama: navedite fajlove, module ili slojeve koji su u obimu i šta se ne smije mijenjati.
- Provjerljive: recite kako se provjerava uspjeh, na primjer testovi koji prolaze, čista provjera tipova ili snimak ekrana novog prikaza.
- S kontekstom: u repozitoriju držite fajl
AGENTS.mdiliCLAUDE.mds konvencijama, komandama, bilješkama o arhitekturi i stvarima koje treba izbjegavati, da svaka sesija krene od istih osnovnih pravila.
Veće dijelove posla inženjer prvo razbije na manje. Ta podjela je dizajnerski posao i ostaje kod ljudi.
Prvo napišite specifikaciju i testove
Najpouzdaniji obrazac koji koristimo: specifikacija i testovi nastaju prije nego što agent napiše implementaciju. Testovi pretvaraju nejasan zahtjev u izvršivu definiciju gotovog posla i daju agentu krug koji može vrtjeti sam: implementiraj, pokreni testove, popravi, ponovi.
Na primjer, za naplatu po broju korisničkih mjesta u SaaS proizvodu inženjer granične slučajeve napiše kao testove:
Agent zatim implementira prorateSeatChange dok testovi ne prođu. Inženjer pažljivo pregleda testove, jer agent od kojeg se traži da testovi prođu ponekad izmijeni same testove. Naše pravilo je jednostavno: agenti smiju dodavati testove, ali svaka izmjena postojećeg testa traži izričito obrazloženje u pull requestu.
Disciplina pregleda: svaka linija ima vlasnika
Brže pisanje pomaže samo ako pregled drži korak. Rezultat agenta prolazi isti pregled kao kod kolege, a u nekim oblastima i strožiji. Na šta pazimo:
- Izmjene koje niko nije tražio: preformatirani fajlovi, preimenovane varijable, nove zavisnosti ili refaktorisanje izvan zadatka.
- Dupliranje: nova pomoćna funkcija, iako je trebalo iskoristiti postojeću.
- Tiho rukovanje greškama: široki
try/catchblokovi, progutane greške i zamjenska rješenja koja skrivaju kvarove. - Kvalitet testova: testovi koji provjeravaju implementaciju umjesto ponašanja, ili mockom uklone baš ono što se testira.
- Performanse: N+1 upiti, indeksi koji nedostaju i API pozivi unutar petlji.
Mali pull requestovi drže ovo pod kontrolom. Radije ćemo u danu spojiti pet malih, dobro pregledanih izmjena nego jednu veliku koju niko nije pročitao do kraja.
Gdje agenti pomažu, a gdje kontrolu zadržavaju inženjeri
| Agenti dobro rade | Inženjeri zadržavaju kontrolu |
|---|---|
| CRUD endpointe, obrasce i administratorske ekrane po postojećim obrascima | Arhitekturu, modele podataka i granice servisa |
| Testove za poznato ponašanje i granične slučajeve | Odluku koje ponašanje je ispravno |
| Migracije, nadogradnje zavisnosti i refaktorisanje uz dobru pokrivenost testovima | Autentifikaciju, autorizaciju i logiku naplate |
| Integracije s dokumentovanim API-jima | Kompromise oko troška, performansi i izbora dobavljača |
| Čitanje nepoznatog koda i objašnjavanje | Šta ide u upotrebu, i kada |
Obrazac je uvijek isti. Agenti su jaki tamo gdje je posao dobro definisan i provjerljiv, a inženjeri donose svaku odluku koju je skupo poništiti.
Sigurnost kada agenti pišu i pokreću kod
AI agent za programiranje pokreće komande na računaru koji ima pristup vašem kodu. Zaslužuje istu pažnju kao svaka druga automatizacija s pravom pisanja.
- Agente pokrećite u izolovanim okruženjima, kao što su kontejneri ili odvojeni worktreeji, bez pristupnih podataka za sisteme u stvarnoj upotrebi.
- Tajne ključeve držite izvan repozitorija i izvan konteksta agenta, a za sve što agent mora pozvati koristite tokene s ograničenim pravima i kratkim rokom važenja.
- Ograničite koje komande se mogu pokrenuti bez odobrenja, posebno one koje objavljuju, brišu ili diraju infrastrukturu.
- Sadržaj koji agent čita, na primjer issue, web stranice i README fajlove zavisnosti, tretirajte kao nepouzdan ulaz koji može sadržavati prompt injection.
- U CI-ju zadržite skeniranje zavisnosti, skeniranje tajnih ključeva i statičku analizu, a za merge u glavnu granu tražite odobrenje čovjeka.
Kako početi sa svojim timom
- 01Dodajte
AGENTS.mds vašim konvencijama, komandama i bilješkama o arhitekturi. - 02Pobrinite se da se testovi, provjera tipova i linting brzo pokreću jednom komandom.
- 03Izaberite jednu vrstu dobro definisanih zadataka, na primjer administratorske ekrane ili integracijske endpointe, i tu prvo uvedite agente.
- 04Za nove funkcije pišite testove prvo, uz jasno pravilo za izmjene postojećih testova.
- 05Pull requestove držite malim i rezultat agenta pregledajte liniju po liniju.
- 06Postavite sandbox i dozvole za komande prije nego što proširite upotrebu.
Ovako naši inženjeri svakodnevno izrađuju softver za klijente. Naš projekat za SaaS scale-up kompaniju pokazuje efekat na rokove isporuke, a kako radimo opisuje kako vodimo projekte uz AI agente za programiranje.