Testirao sam Qoder Experts ceo dan, tim Agent stručnjaka je zaista moćan.
Qoder V0.8 je objavio Experts Mode, prošli put sam uzeo PaiGit za test inkrementalne funkcije (issue i Wiki), učinak Experts Mode me je donekle zasmetao.
Ali inkrementalni razvoj je u suštini izmena na postojećem kodu, u glavi mi je ostalo jedno nerešeno pitanje: ako je u pitanju izgradnja potpuno novog modula od nule, da li Experts Mode i dalje može da izdrži?
Zato sam ovog puta uzeo izazovniji zadatak — dao PaiAgentu da razvije funkciju integracije API key-eva velikog modela, za svakog korisnika, tako da pri korišćenju Wiki funkcije može koristiti svoj paket.
Tipičan zadatak celog full-stack razvoja od 0.1 do jednog, savršen za ispitivanje Experts Mode.
Ceo sadržaj je vrlo intenzivan, vežite sigurnosne pojaseve, krećemo. Di-di-di, polazimo.
01. Izazov razvoja od nule
Inkrementalni razvoj ima prirodnu prednost: postojeći kod je najbolja referenca.
AI može gledati Issue modul da nauči kako dizajnirati entitete, gledati Wiki modul da nauči kako pisati Controller, pa napraviti osam desetina procenta po uzoru. Čak i ako negde postoji odstupanje, cena ispravke nije velika.
Ali razvoj od nule je drugačiji.
Nema reference, što znači da AI sam mora od početka da odluči: kako dizajnirati tabele baze podataka, kako planirati API putanje, kako dogovoriti front-end i back-end interfejse, koja logika ide u sloj baze radi atomičnosti, šta u aplikacioni sloj. Svaka odluka može uticati na kasnije faze, jednom pogrešno izabrana arhitektura znači ogromne troškove prepravljanja.
Obratite pažnju, svaki put kada postoji novi zahtev, Qoder-ov Experts Mode prvo pušta istraživača Alexa da detaljno istraži.
Da vidi kojom infrastrukturom može da se koristi, izbegavajući velike prerade.
Namerno u zahtevima nisam jasno objasnio te detalje, hteo sam da vidim da li Experts Mode sam može da ih otkrije i obradi.
Ovaj problem u softverskom inženjerstvu se zove „obrada nejasnoća zahteva“. Odličan arhitekta prepoznaje te nejasne tačke u ranoj fazi dizajna i aktivno ih razjašnjava.
Većina AI alata pri nejasnim zahtevima ili nagađa, ili zastane i ne radi ništa.
Hteo sam da vidim kako će Qoder-ov Leader Agent to da obradi.
Sudeći po rezultatu, Qoder je to obradio vrlo dobro.
Važnije je da je ovakav zadatak zapravo posebno pogodan za testiranje stvarnog nivoa Agent-a.
Zašto?
Zato što to nije neki lagan posao tipa „promeni boju dugmeta” ili „dodaj polje u interfejs”, već tipična inter-slojna prepravka: baza podataka, back-end servis, poziv spoljnog modela, front-end stranica sa podešavanjima, provera dozvola, prikaz grešaka, regresiono testiranje — sve se dira. Svaki segment koji se ne razume na vreme može se na kraju ispoljiti kao „funkcija izgleda gotova, ali zapravo ne može u produkciju”.
Zato ovog puta ne posmatram više da li jedan Agent ume da piše kod, već da li čitav Experts Mode istovremeno može tri stvari:
- Prvo, da li može nejasne zahteve upotpuniti u izvršiv plan
- Drugo, da li može u paralelnom radu više ljudi održati konzistentnost interfejsa i implementacije
- Treće, da li može pre isporuke sam pregaziti zamke, umesto da probleme ostavi meni za kraj
Ako te tri stvari može, onda njegova vrednost nije samo „ušteda vremena”, već zaista počinje da pristupa organizovanoj AI razvojnoj ekipi.
02. Pokretanje Experts Mode
Otvorite Qoder, napravite novu sesiju, prebacite se na [stručnjake], odnosno Experts Mode, unesite zahtev:
Pošto je brzina AI generisanja Wiki-ja relativno spora, da li možemo napraviti brzi test, da vidimo da li je ovaj AI povezan, da li radi. Drugim rečima, da li možemo prebaciti ovaj API key iz konfiguracione datoteke na svaki nalog, tako da svaki korisnik unese svoj API key, može izabrati Zhipu, Tongyi Qianwen, ili DeepSeek.
Po završetku unosa, pritisnite Enter, Leader Agent kreće.
Ovaj korak me najviše zanima: pred novim modulom, kako će ga razložiti?
Nakon oko 15 sekundi, istraživač Alex je završio istraživanje.
Ukupno osam faza, dva P0, dva P1, dva P2, dva P3:
- P0: Proširenje šeme baze (tabela users dodaje AI Key polje)
- P0: Proširenje User entiteta (novo polje, Hibernate mapiranje)
- P1: UserAiKeyService (šifrovano skladištenje + logika provere)
- P1: Controller za upravljanje AI Key (CRUD + test krajnja tačka)
- P2: Front-end AI Settings panel
- P2: Refaktoring podrške za više modela (OpenAiConfig Factory)
- P3: Poboljšanje Wiki generacije (podrška za korisnički nivo konfiguracije)
- P3: Audit log (evidencija korišćenja AI Key)
Ovaj pristup klasifikacije prioriteta je vrlo profesionalan.
P0 je blokirajući osnovni rad, bez polja baze i proširenja entiteta, sve sledeće funkcije ne mogu početi. P1 je osnovna funkcionalnost, uključujući šifrovano skladištenje i API interfejs, to je glavna vrednost koju korisnik oseća. P2 je optimizacija iskustva, front-end panel i fabrika konfiguracije čine funkciju potpunijom. P3 je dodatna vrednost, audit log je važan za enterprise aplikacije, ali za MVP verziju se može odložiti.
Zatim je izašao jedan plan.
Funkcionalnost je ono što smo ranije spomenuli.
Migracija AI API Key iz globalnih promenljivih okruženja application.yml u nezavisnu konfiguraciju svakog korisnika, podrška za tri provajdera: Zhipu, Tongyi Qianwen, DeepSeek, i jednoklikno testiranje povezanosti, kako bi korisnik brzo proverio da li je API Key dostupan pre Wiki generacije.
Na kraju je isplanirano 5 zadataka.
- Task 1: Proširenje baze + sloja entiteta (back-end)
- Task 2: Back-end interfejs za AI podešavanja (back-end)
- Task 3: Prepravka Wiki servisa za generisanje (back-end)
- Task 4: Front-end AI panel za podešavanja
- Task 5: Verifikacija
Ova sposobnost dekompozicije zadataka odražava razumevanje Leader Agent-a za najbolje prakse softverskog inženjerstva.
Task 1 i Task 2 su nezavisni back-end razvoj, mogu paralelno; Task 3 zavisi od interfejsa Task 2; Task 4 front-end zavisi od Task 2 API-ja; Task 5 verifikacija zavisi od svih prethodnih zadataka. Prepoznavanje ovih zavisnosti omogućava paralelni razvoj i izbegava beskorisno blokirajuće čekanje.
Ova sposobnost nije prostu „čitanje koda”, već pravo „razumevanje arhitekture”.
I ovde postoji jedna tačka koju mnogi lako previde pri prvom korišćenju multi-Agent alata: vrednost Leader Agent-a nije u tome da li ume da napiše deo koda, već da li može da utvrdi „ispravan redosled rada”.
U softverskom razvoju nije najgore što je neki zadatak spor, već što je redosled pogrešan. Baza još nije definisana, a front-end već piše formu; protokol interfejsa nije dogovoren, a test već snima skriptu; na kraju su svi zauzeti, ali je rezultat gomila prepravki.
Ovog puta Qoder mi je ostavio utisak da nije mehanički podelio zadatke na 5 Agent-a, već je prvo procenio zavisnosti, a onda rasporedio paralelni rad. Ta razlika je ogromna. Prvo je samo „više otvorenih prozora”, drugo je „organizacija borbe kao pravi Tech Lead”.
03. Pet stručnjaka kreće istovremeno
Nakon istraživanja, tri back-end inženjera, jedan front-end inženjer i jedan inženjer za testiranje kreću paralelno.
Back-end inženjer Jimmy je odgovoran za zadatak 1: proširenje baze + sloja entiteta (AI konfiguraciona polja).
Jimmy je prvo analizirao postojeću strukturu User entiteta i otkrio da koristi JPA anotacije, sa jasnim mapiranjem polja. Odlučio je da u tabelu users doda tri polja: ai_provider (tip provajdera, enumeracija), ai_api_key (šifrovani API Key), ai_key_updated_at (vreme poslednje izmene).
Ključna odluka ovde je izbor VARCHAR tipa za čuvanje šifrovanog Key-a umesto TEXT, jer je i šifrovani Key dovoljno ograničen na ispod 500 znakova.
Back-end inženjer Bill je odgovoran za zadatak 2: Back-end interfejs za AI podešavanja (CRUD + test povezanosti).
Bill-ov dizajn ima dobar osećaj za slojevitost. Prvo je implementirao osnovne CRUD interfejse: GET /api/user/ai-config za preuzimanje konfiguracije, POST /api/user/ai-config za čuvanje, DELETE /api/user/ai-config za brisanje.
Zatim ključni interfejs za testiranje povezanosti POST /api/user/ai-config/test, koji zaista poziva API provajdera da proveri da li je Key validan. Ovde je jedan detalj: Bill nije direktno pozivao Zhipu/Qianwen/DeepSeek interfejse, već je ponovo iskoristio postojeći OpenAiChatClient u projektu, prosledivši korisnički konfigurisani Key i Base URL, čime je stepen ponovnog korišćenja koda visok.
Back-end inženjer Robin je odgovoran za zadatak 3: prepravka Wiki servisa za generisanje (korisnički nivo API Key).
Robin-ov posao je prepravka WikiService-a, da pređe sa globalne konfiguracije na korisničku konfiguraciju. Suočio se sa jednom dizajnerskom odlukom: ako korisnik nije konfigurisao API Key, da li prijaviti grešku ili koristiti podrazumevani deljeni Key? Na kraju je izabrao strategiju elegantne degradacije — prvo koristi korisnički konfigurisani Key, ako nije konfigurisano koristi sistemski podrazumevani Key, ako ni sistem nema konfiguraciju baca izuzetak. Ovaj dizajn osigurava da iskustvo postojećih korisnika ne bude pogođeno, a novim korisnicima daje fleksibilnost.
Front-end inženjerka Lee odgovorna je za zadatak 4: Front-end AI panel za podešavanja.
Lee-in dizajn posebno vodi računa o korisničkom iskustvu. Dodala je novi „AI konfiguracija” tab na stranici sa korisničkim podešavanjima, koji sadrži tri dela: izbor provajdera (padajuća lista sa opcijama Zhipu/Qianwen/DeepSeek), polje za unos API Key-a (tip password, sa prikazivanjem/sakrivanjem), dugme za testiranje povezanosti.
Ovde je jedan detalj: Lee je ispod polja za unos dodala tekst sa objašnjenjem „Vaš API Key će biti šifrovano uskladišten i korišćen samo za Wiki funkciju”, ovakav transparentan dizajn daje korisniku veće poverenje. Dugme za test nakon klika prikazuje status učitavanja i na osnovu rezultata prikazuje poruku o uspehu ili neuspehu.
Inženjer za testiranje Chris odgovoran je za zadatak 5: end-to-end verifikacija.
Chris-ova strategija testiranja je vrlo sveobuhvatna. Dizajnirao je pet test scenarija: scenarij jedan je normalan tok, konfiguriše Zhipu API Key i testira povezanost, zatim generiše Wiki i proverava da li je korišćen korisnički konfigurisani Key; scenarij dva je granični test, unosi nevažeći API Key i proverava da li je poruka o grešci prijateljska; scenarij tri je test dozvola, neprijavljeni korisnik pokušava da pristupi AI konfiguracionom interfejsu i proverava da li se vraća 401; scenarij četiri je test kompatibilnosti, stari korisnik bez konfigurisanog Key-a generiše Wiki i proverava da li se koristi podrazumevana konfiguracija; scenarij pet je test konkurentnosti, brzo prebacivanje provajdera i Key-a uz proveru konzistentnosti stanja.
Ovaj mehanizam koordinacije je glatkiji nego što sam očekivao.
Chris-ovi dizajnirani test slučajevi su sveobuhvatniji nego što sam očekivao, ne samo da sam otvara pretraživač, već i beleži svaki korak.
Ovaj snimak ekrana, iskreno, kad ja testiram, nisam siguran da bih sačuvao toliko kompletno.
Naravno, prednost kompletnog čuvanja je što nema prebacivanja odgovornosti sa programera na druge, niti ljutnje Leader-a.
Zaista savesan.
Ovo je prava garancija kvaliteta, nije puko prolazak kroz formalnost, već suštinsko testiranje.
04. U čemu je ovaj test zaista jak
Mislim da je prava snaga Experts Mode u tome što nije „istovremeno generisao mnogo koda”, već što je nekoliko stvari koje su pre zahtevale ljudsko koordinisanje pomaklo napred i prepustilo sistemu da ih sam svarí.
Prva jakost je što aktivno donosi granične odluke.
Na primer, pitanja poput „šta ako korisnik nije konfigurisao API Key”, „da li je stara logika kompatibilna”, „da li test interfejs zaista treba da pozove tri provajdera modela”, „da li front-end poruka treba da pokaže šifrovano skladištenje” — strogo govoreći, nijedno od ovih u zahtevima nisam jasno definisao. Ali Qoder se nije pravio da ne vidi, već u fazi dekompozicije pretvara ta pitanja u dizajnerske odluke.
To je ključno. Jer u stvarnim projektima, mnogi bug-ovi uopšte nisu u tome što se kod ne zna napisati, već u tim sivim zonama gde niko ne razmisli jasno.
Druga jakost je što je nasleđivanje konteksta prilično stabilno.
Multi-Agent se najviše plaši da „svako piše svoje”. Back-end A misli da se polje zove providerType, back-end B misli da se zove aiProvider, front-end prihvata po trećem imenu, i na kraju sve spojeno puno problema.
Qoder mi je ovog puta ostavio utisak da je Leader Agent prvo utvrdio pravac, a kasniji Agent-i su uglavnom krenuli po istom skupu ograničenja, pa su konačni interfejsi, polja, stranice i testovi imali manje osećaja spajanja.
Da budem jasan, šta to znači?
Znači da vaš odnos sa AI-om prelazi iz „ja mu kažem da napiše deo koda” u „ja njega teram da isporuči funkciju”. Između te dve stvari je razlika od više od jednog reda veličine.
05. Konačna isporuka
Nakon završetka svih zadataka, klikom na prozor za ćaskanje možete videti šta je tačno uradio svaki član, sve na jednom mestu.
Izmenjene datoteke se takođe mogu direktno pregledati klikom, šta je tačno isporučeno svaki put.
Ceo tok od unosa zahteva do završetka QA prijema trajao je oko 10 minuta.
Ranije, sa tim tolikim ljudima u timu, brzina razvoja je bila užasno spora.
Često bi back-end prebacivao krivicu na front-end, front-end na test, pa je ukupna efikasnost bila jako niska.
Ručno sam proverio tok, nisam otkrio probleme. Kvalitet koda je sveukupno prilično dobar, dizajn baze je razuman, dizajn API-ja je standardan, front-end komponente su uredno enkapsulirane i mogu se direktno spojiti.
U poređenju sa tradicionalnim načinom razvoja: da sam sam od nule pisao ovaj modul, sama faza dizajna bi zahtevala razmišljanje o tome kako napraviti bazu i isplanirati API, verovatno jedan dan; uz implementaciju i integraciju, dva data otprilike.
Experts Mode je koristio 10 minuta.
Naravno, vreme nije jedina dimenzija.
Ovakva Agent koordinacija je ono što je najjače.
Ali ako bih dao malo smireniji rezime, rekao bih da je još uvek malo udaljen od „potpunog poverenja bez nadzora”.
ending
Ja sam već dugogodišnji programer.
Rano u karijeri, da bi se funkcija isporučila, tok je bio ovakav: revizija zahteva → planiranje → back-end razvoj → front-end razvoj → testiranje → produkcija.
Za kompletnu funkciju, sedam-osam radnih dana nije izlazilo, a samo planiranje se čekalo danima.
Sada osećaj Experts Mode je drugačiji. Leader Agent pravi plan, Researcher istražuje kod, dva Backend Dev paralelno razvijaju, Frontend Dev prati, QA Tester čeka prijem — sve se dešava istovremeno, ja samo donosim nekoliko ključnih odluka.
Ovo nije „brži samostalni razvoj”, ovo je „jedan čovek upravlja timom”.
Uloga se promenila.
Jedan čovek koji piše kod, gornja granica je taj jedan čovek. Jedan čovek koji upravlja AI timom, gornja granica je taj tim.
Ali to još nije kraj.
Prava promena je u sledećem: kada AI tim može da obrađuje sve više „izvršnog” rada, vrednost čoveka se sve više ispoljava u „definisanju pravih problema”. To uključuje razumevanje poslovnih zahteva, dizajn sistemske arhitekture, donošenje tehnoloških izbora, balansiranje različitih trade-off-ova.
Ova promena nije nadogradnja alata, već fundamentalno preoblikovanje profesionalne uloge.
Vidimo se u sledećem.