Kodėl vieno Copilot nepakanka
DI asistentai IDE (Copilot, Codeium, Cursor) padidina programuotojo produktyvumą 20-30%. Tai realios sąnaudos, bet tai tik automatinio užbaigimo sluoksnis. Agentas padeda rašyti kodo eilutes, bet žmogus vis dar nusprendžia, ką rašyti, projektuoja struktūrą, paleidžia testus, atlieka derinimą, kodo peržiūrą, rašo dokumentaciją, diegia. Siaurasis tarpas nėra kodo rašymo greitis — tai keliasdešimt skirtingų veiksmų koordinavimas kūrimo cikle.
Specializuotų DI agentų komanda šią problemą sprendžia kitaip. Kiekvienas agentas turi aiškų vaidmenį ir atsakomybę. Vienas agentas analizuoja reikalavimus ir kuria techninę specifikaciją. Antras projektuoja modulio struktūrą. Trečias rašo įgyvendinimą. Ketvirtas rašo vienetinius ir integracinius testus. Penktas atlieka kodo peržiūrą saugumo ir standartų atitikties atžvilgiu. Šeštas generuoja dokumentaciją. Septintas valdo diegimą. Žmogus architektas koordinuoja, recenzuoja, priima strateginių sprendimų — bet rutiną perima agentų komanda.
Orkestravimo šablonai — kaip agentai iš tikrųjų bendradarbiauja
Trys pagrindiniai orkestravimo šablonai pasiteisina praktikoje:
- Sekvencinis konvejeris — agentai atlieka užduotis nustatyta tvarka (analizė → projektas → kodas → testai → peržiūra → diegimas). Kiekvienas agentas gauna ankstesnio išvestį kaip įvestį. Paprasiausias įgyvendinti, mažiausiai lankstus.
- Hub-and-spoke — centrinis koordinuojantis agentas (orchestrator) deleguoja užduotis specializuotiems agentams ir agreguoja rezultatus. Geras užduotims su daugeliu nepriklausomų použduočių (pvz., lygiagretus darbas su skirtingais moduliais).
- Peer-to-peer derybos — agentai bendrauja tiesiogiai, gali tarpusavyje skirti použduotis, eskaluoti problemas, klausti sprendimų. Lanksiausias, bet reikalauja aiškių komunikacijos protokolų ir konfliktų sprendimo mechanizmų.
Produkcinėje praktikoje matome hibridą: orchestrator pagrindiniam darbo srautui, peer-to-peer specializuotoms užduotims (pvz., testavimo agentas gali tiesiogiai konsultuotis su saugumo agentu neaktyvuodamas orchestrator).
Vaidmenys komandoje — kurie yra esminiai
Pagal mūsų patirtį produkcinėje daugiaagentęje platformoje, svarbiausi vaidmenys yra:
- Verslo analitiko agentas — verslo vartotojo reikalavimus paverčia technine specifikacija. Pateikia tikslinančius klausimus. Identifikuoja trūkstamą informaciją.
- Architekto agentas — projektuoja modulio struktūrą, parenka projektavimo šablonus, sprendžia dėl komponentų ribų. Konsultuojasi su saugumo agentu dėl jautrių sprendimų.
- Backend kūrėjo agentas — įgyvendina verslo logiką, API, integracijas. Pasirenka bibliotekas ir framework.
- Frontend kūrėjo agentas — įgyvendina UI, komponentus, integracijas su API.
- Duomenų inžinieriaus agentas — projektuoja duomenų bazės schemą, rašo Alembic/Flyway migracijas, optimizuoja užklausas.
- QA agentas — rašo vienetinius, integracinius, E2E testus. Apima happy path, kraštinius atvejus ir klaidų scenarijus. Generuoja testus iš dokumentacijos.
- Kodo peržiūros agentas — analizuoja pull requestų OWASP Top 10, kodo standartų, testų kokybės, architektūros atitikties atžvilgiu. Eskaluoja abejones žmogui.
- Dokumentacijos agentas — generuoja OpenAPI specifikacijas, README, CHANGELOG, inline komentarus ten, kur WHY nėra akivaizdus.
- DevOps agentas — ruošia Dockerfile, docker-compose, CI/CD konfigūracijas, monitoring.
Kas konkrečiai keisis organizacijoje
8-10 programų kūrėjų komandą gali pakeisti 2-3 patyrę inžinieriai + agentų komanda, teikiantys palygin lyginą ar didesnę vertę. Vidutinio funkcionalumo time-to-market sutrumpėja nuo 2-4 savaičių iki 3-7 dienų. Testų aprasptis išauga nuo įprasto 40-60% iki 80-90% — nes testai generuojami kartu su kodu (TDD kaip default), o ne „pridedami vėliau”.
Antras, mažiau matomas pokyčio aspektas yra standartizavimas. Kiekvienas projektas taiko tas pačias praktikas — feature branch workflow, squash merge, Conventional Commits, CHANGELOG Keep a Changelog formatu, audit log duomenų bazėje, automatiškai generuojama OpenAPI dokumentacija. Agentai nepamiršta šių taisyklių, nepraranda motyvacijos, nesutrumpina kelio terminų spaudimu.
Kas lieka žmogaus vaidmuo
Žmogus architektas neukžnėja — priešingai, jo vaidmuo tampa svarbesnis. Kritinės sritys:
- Strateginiai architektūriniai sprendimai — pasirinkimai tipo „mikroservisai ar monolitas”, „PostgreSQL ar Mongo”, „kiek cache sluoksnių”. Agentai siūlo variantus, žmogus pasirenka.
- Kodo peržiūra pakeitimams, paveikiantiems daug modulių — agentai geri mechaniniam tikrinimui, žmogus mato kryžmines pasekmes.
- Produkcinis derinimas — kai kas nors griuvo produkcijoje, patyręs inžinierius su mintiniu sistemos modeliu yra nepakeičiamas.
- Verslo ir etiniai sprendimai — kada prisiimti refaktoringo sąnaudas, kaip išsprendi dilemą su klientu, ar įgyvendinti etiškai abejotiną funkciją.
Diegimas — nuo ko pradėti
Geriausias diegimo kelias esamoje komandoje yra evoliucija, ne revoliucija. Pirmas žingsnis: pridėti kodo peržiūros agentą kaip antrą akis porą kiekviename pull request. Antras žingsnis: vienetinių testų generavimo agentas — paleidžiamas su kiekviena nauja funkcija. Trečias žingsnis: dokumentacijos agentas, generuojantis OpenAPI ir README. Ketvirtas žingsnis: diegimą valdantis agentas (CI/CD). Tik kai komanda jaučiasi patogiai su šiais vaidmenimis, pridedame aukštesnio lygio agentus (architekto, verslo analitiko).
Esminis yra aiškus eskalavimo protokolas — kada agentas turi sustoti ir paprašyti žmogaus sprendimo. Be to komanda arba sustoja kiekvienu žingsniu (paranoja), arba agentai savarankiškai priima sprendimus, kurių neturėtų priimti (rizika).
Išvados sprendėjams
Programinės įrangos kūrimas su DI agentų komanda nėra laikina mada — tai fundamentalus pokyčis, panaaus mastu į perėjimą nuo waterfall prie agile. Įmonės, kurios įdiegs šį modelį per artimiausius 12-24 mėnesius, įgys ilgalaikį sąnaudų ir kokybės pranaumą. Įmonės, kurios delsia, atsidurs įmonių, kurios 2012 metais ignoravo debesį, situacijoje. Klausimas jau nėra „ar”, o „kaip greitai ir nuo ko pradėti”.