Zergatik ez den nahikoa Copilot bakar bat
IDE-ko IA-laguntzaileek (Copilot, Codeium, Cursor) programatzailearen produktibitatea %20-30 igotzen dute. Aurrezpen erreala da, baina autobetetze-geruza baino ez da. Agenteak kode-lerroak idazten laguntzen du, baina gizakiak oraindik erabakitzen du zer idatzi, egitura diseinatzen du, probak abiarazten ditu, arazketa egiten du, code review egiten du, dokumentazioa idazten du, hedatzen du. Botila-lepoa ez da kodea idazteko abiadura — garapen-zikloko hamarka jardueren koordinazioa da.
IA agente espezializatuen taldeak arazo hori bestelako modu batean ebazten du. Agente bakoitzak rol eta erantzukizun argia du. Agente batek baldintzak aztertzen ditu eta zehaztapen tekniko bat sortzen du. Bigarrenak moduluaren egitura diseinatzen du. Hirugarrenak inplementazioa idazten du. Laugarrenak unitate- eta integrazio-probak idazten ditu. Bosgarrenak code review egiten du segurtasun eta estandarrekiko betetzeari dagokionez. Seigarrenak dokumentazioa sortzen du. Zazpigarrenak hedapena kudeatzen du. Gizaki-arkitektoak koordinatzen du, berrikusten du, erabaki estrategikoak hartzen ditu — baina errutina agenteen taldeak hartzen du.
Orkestrazio-ereduak — nola lan egiten duten agenteek benetan
Hiru oinarrizko orkestrazio-eredu funtzionatzen dute praktikan:
- Pipeline sekuentziala — agenteek zereginak ezarritako ordenan egiten dituzte (analisia → diseinua → kodea → probak → review → hedapena). Agente bakoitzak aurrekoaren output-a jasotzen du input gisa. Inplementatzeko errazena, malgutasun gutxien duena.
- Hub-and-spoke — agente koordinatzaile zentral batek (orchestrator) zereginak agente espezializatuei eskuordetzen dizkie eta emaitzak biltzen ditu. Ona azpitarea independente askorekin (adib. modulu desberdinetan lan paraleloan).
- Peer-to-peer negoziazioa — agenteak zuzenean komunikatzen dira, elkarri azpitareak agindu diezazkiokete, arazoak eskalatu, erabakiak eskatu. Malguena, baina komunikazio-protokolo argiak eta gatazkak konpontzeko mekanismoak behar ditu.
Produkzio-praktikan hibrido bat ikusten dugu: orchestrator workflow nagusirako, peer-to-peer zeregin espezializatuetarako (adib. probetarako agenteak zuzenean kontsulta dezake segurtasun-agentearekin orchestrator-a inplikatu gabe).
Taldeko rolak — zeintzuk diren funtsezkoak
Gure produkzio-plataforma multi-agentearen esperientziatik, rol garrantzitsuenak hauek dira:
- Negozio-analista agentea — erabiltzailearen baldintzak zehaztapen teknikora itzultzen ditu. Argitze-galderak egiten ditu. Falta den informazioa identifikatzen du.
- Arkitektura-agentea — moduluaren egitura diseinatzen du, diseinu-ereduak hautatzen ditu, osagaien mugak erabakitzen ditu. Erabaki delikatuak segurtasun-agentearekin kontsultatzen ditu.
- Backend developer agentea — negozio-logika, API-ak, integrazioak inplementatzen ditu. Liburutegiak eta framework-a hautatzen ditu.
- Frontend developer agentea — UI, osagaiak, API-ekin integrazioak inplementatzen ditu.
- Datu-ingeniari agentea — datu-baseko eskema diseinatzen du, Alembic/Flyway migrazioak idazten ditu, kontsultak optimizatzen ditu.
- QA agentea — unitate-, integrazio-, E2E-probak idazten ditu. Happy path, edge case-ak eta errore-eszenategiak estaltzen ditu. Probak sortzen ditu dokumentaziotik.
- Code review agentea — pull request-ak aztertzen ditu OWASP Top 10, kode-estandarrak, proben kalitatea, arkitekturarekiko betetzea kontuan hartuta. Zalantzak gizakira eskalatzen ditu.
- Dokumentazio-agentea — OpenAPI espezifikazioak, README, CHANGELOG, inline-iruzkinak sortzen ditu WHY argi ez denean.
- DevOps agentea — Dockerfile, docker-compose, CI/CD konfigurazioak, monitorizazioa prestatzen ditu.
Zer aldatzen den zehazki erakundean
8-10 garatzaileko taldea 2-3 ingeniari esperientziadun + agente-taldeak ordezka dezakete, balio konparagarria edo handiagoa emanez. Time-to-market ertaineko feature batentzat 2-4 astetik 3-7 egunera murrizten da. Proba-estaldura ohiko %40-60tik %80-90era igotzen da — probak kodearekin batera sortzen direlako (TDD lehenetsi gisa), eta ez „ondoren gehitzen”.
Bigarren aldaketa, agerikoa ez dena, estandarizazioa da. Proiektu bakoitzak praktika berberak aplikatzen ditu — feature branch workflow, squash merge, Conventional Commits, CHANGELOG Keep a Changelog formatuan, audit log datu-basean, automatikoki sortutako OpenAPI dokumentazioa. Agenteek ez dituzte arau hauek ahazten, ez dute motibazioa galtzen, ez dituzte bideak laburtzen epeen presiopean.
Zer izaten jarraitzen den gizakiaren rola
Gizaki-arkitektoa ez da desagertzen — alderantziz, bere rola garrantzitsuagoa bihurtzen da. Eremu kritikoak:
- Arkitektura-erabaki estrategikoak — „mikrozerbitzuak ala monolitoa”, „PostgreSQL ala Mongo”, „cache-geruza zenbat” bezalako aukerak. Agenteek aukerak proposatzen dituzte, gizakiak aukeratzen du.
- Modulu anitzetan eragiten duten aldaketen code review — agenteak onak dira egiaztapen mekanikoan, gizakiak gurutzaketa-ondorioak ikusten ditu.
- Produkzioko debugging — produkzioan zerbait apurtzen denean, sistemaren eredu mentala duen ingeniari esperientziaduna ordezkaezina da.
- Negozio- eta etika-erabakiak — noiz ordaindu refactoring-kostua, nola konpondu bezeroarekiko dilema, etikoki zalantzazko feature bat inplementatu behar den ala ez.
Zure baitan inplementatzea — non hasi
Lehendik dagoen taldean inplementatzeko biderik onena eboluzioa da, ez iraultza. Lehen urratsa: code review agente bat gehitzea bigarren begi-pareko gisa pull request bakoitzean. Bigarren urratsa: unitate-probak sortzen dituen agentea — funtzio berri bakoitzean abiarazten dena. Hirugarren urratsa: OpenAPI eta README sortzen dituen dokumentazio-agentea. Laugarren urratsa: hedapena kudeatzen duen agentea (CI/CD). Taldea rol horiekin eroso dagoenean baino ez dugu maila handiagoko agenterik gehitzen (arkitektoa, negozio-analista).
Funtsezkoa da eskalatze-protokolo argi bat — noiz eten behar duen agenteak eta gizakiari erabakia eskatu. Hori gabe, taldea urrats bakoitzean gelditzen da (paranoia), edo agenteek beren kabuz hartzen dituzte hartu behar ez lituzketen erabakiak (arriskua).
Erabakitzaileentzako ondorioak
IA agenteen taldearekin software garatzea ez da aldi baterako moda — funtsezko aldaketa da, waterfall-etik agile-ra trantsizioaren antzeko eskala duena. Hurrengo 12-24 hilabeteetan eredu hau ezartzen duten enpresek kostu- eta kalitate-abantaila iraunkorra lortuko dute. Berandutuko diren enpresak 2012an hodeia ezikusten zuten enpresen egoeran egongo dira. Galdera ez da jada „ea”, baizik eta „zenbat azkar eta nondik hasi”.