Agentpõhise arenduse võimalused

Pärast Anthropic Opus 4.5 mudeli tulekut võib suhteliselt suure kindlusega öelda, et üks ajastu hakkab täna läbi saama. Ajastu, mil kulutasime aega ja raha, et Jira piletitest käsitsi valmis kirjutada tüüpilist lähtekoodi oma infosüsteemides. Nüüd, kus AI-agendid suudavad ise katta suure osa tavapärase infosüsteemi lähtekoodi arendusest, ei ole enam mõistlik vanamoodi jätkata. Erandid, mis eeldavad käsitsi sekkumist, jäävad alati, kuid toimumas on põhimõtteline suunamuutus tarkvaraarenduses.

Seni kehtinud agiilse arenduse praktikas on analüütik analüüsinud mingi osa tulevase süsteemi funktsionaalsuset, teinud Jira pileti ja seejärel on seda mindud Scrumi abil lahendama – alustades planning pokerist ja lõpetades tundide raporteerimisega.

Analüütiku roll

Siis uues ajajärgus näen, et analüütik peab keskenduma sellele, et saada oma kasutajate käest kätte kogu vajalik domeenipõhine teave probleemi lahendamiseks ning seejärel tükelda AI abil seda agendile sobivateks arendusülesanneteks. Need peavad olema piisava detailsusega, et tänase võimekusega mudelid suudaksid oma kontekstipiirangutega seda läbi töötada ja vajadusel võtta sisse ka täiendavaid lisadokumente.

Tekib küsimus: kas me kasutame siin üldse enam traditsioonilisi vahendeid nagu Word, Confluence ja Jira? Või jätame selle osa vahele ning analüütikud toodavad sobivad dokumendid otse Git-i repositooriumi, agentidele sobivas universaalses formaadis nagu Markdown? Markdown-failid võivad sisaldada nii teksti, tabeleid kui ka kõikvõimalikke diagramme, mis annavad probleemi olemust ja domeeniteadmist hästi edasi.

Arendaja roll

Järgmine samm peaks olema arendajatel, kes koostavad sobiva arhitektuuri ja jagavad lahenduse domeenist lähtuvalt komponentideks. Igale komponendile saab võtta aluseks mõne arendusraamistiku jaoks kohandatud rakenduspõhja, kus on juba realiseeritud olulised arhitektuurimustrid ja arendusnõuded ning kasutusele võetud koodigeneraatorid. Praktikas täidab seda rolli meeskonnas see, kellel on vastav tehniline vastutus ja kogemus.

Siinkohal on oluline rõhutada, et asutusel või ettevõttel peaks olema hästi hallatud rakenduspõhjade kollektsioon, mida järjepidevalt kaasajastatakse ja mis on agendipõhiseks arenduseks ka optimeeritud. Kui organisatsioonil on erinevate tehnoloogiate ja raamistike jaoks kvaliteetsed rakenduspõhjad olemas, saab uute projektidega kiiresti alustada ning AI-agentidel on kohe sobiv kontekst, millest lähtuda.

Oluline on, et agendipõhiseks arenduseks saab ette valmistada ka juba olemasoleva projekti: lasta AI-l koodibaas läbi analüüsida, tuvastada senised praktikad ja põhimõtted ning sellest automaatselt koostada `AGENTS.md` ja esialgsed reeglifailid. Nii muutub ka olemasolev projekt agentidele sõbralikuks, mitte ainult uued lahendused.

SQL-i migratsioonifailidest või OpenAPI spetsifikatsioonist erinevate lähtekoodi failide genereerimine on mõistlik teha jätkuvalt tavapäraste genereerijatega. Seda ei tasu jätta LLM-idele, kus me ei saa alati olla 100%, et väljund on iga kord ühesugune.

Rakenduspõhja ülesehitus

Tänase rakenduspõhja juurde kuulub kindlasti `AGENTS.md` ehk agendi juhend, mis on kohandatud vastava raamistiku iseärasuste järgi ja õpetab AI-agendile, kuidas antud rakenduspõhjaga vajalikku lähtekoodi kirjutada.

Selle faili üks oluline osa on suunata AI-agent pärast igat sammu ja vahetulemit tööd valideerima. Selleks kasutatakse erinevaid töövahendeid: linterit, Sonarit, tüübikontrolle ja erineva tasemega automaatteste. Lõpuks teeb agent ka iseenda tööle koodiülevaatuse.

Reeglite kogumik

Lisaks `AGENTS.md` failile kuulub sellise koodipõhja juurde ka kvaliteetne reeglite kogumik – agendile kohandatud arendusnõuded Markdown-failidena. Need hõlmavad programmeerimiskeele kasutamise põhimõtteid, raamistiku, testimise, dokumenteerimise ja turvanõudeid.

Erinevalt klassikalisest arendajast, kes arendades sageli kõiki nõudeid punktuaalselt ei järgi, on agendil oluliselt lihtsam etteantud nõudeid täpselt järgida. Siinkohal võib tekkida küsimus: miks neid nõudeid üldse vaja, kui mudelid on treenitud maailmapraktikate pealt? Tegelikkuses on igas organisatsioonis tihtipeale omad reeglid, kuidas arendusi täpsemalt tehakse.

Kvaliteet ja refaktoreerimine

Arendusmeeskonna poolt hästi ettevalmistatud sisend võimaldab agendil oluliselt lihtsamini toota koodi, mis on reaalselt kvaliteetne ja nõuetele vastav – mitte lihtsalt järjekordne vibe-codingu tulemus.

Märkimata ei saa jätta üht olulist aspekti. Kes on agentpõhist arendust praktikas katsetanud, teab, et refaktoreerimine – siiani kalliks luksuseks peetud tegevus – on agentpõhise arendamise juures igapäevane. Traditsioonilises arenduses jäi koodi ümberkirjutamine parema loetavuse, tehnoloogilise võla vähendamise või optimeerimise nimel sageli tegemata, sest sprintides polnud selleks aega. AI-agendiga arendades võib seda lubada isegi konkreetse töö käigus jooksvalt teha. Mida suuremaks infosüsteem kasvab, seda rohkem võib refaktoreerimist ette tulla, et valmiks parim tulemus.

Töö alustamine ja jälgimine

Pärast rakenduspõhja ja dokumentatsiooni ettevalmistamist on võimalik agendil osade kaupa tööd alustada. Agent saab Markdown-failide abil pidada järge, milline funktsionaalsus on realiseeritud ja mis on ootel ning seekaudu samm-sammult meeskonna visiooni ellu viia.

Kuna uued AI-võimendusega töövahendid võimaldavad ka spetsiaalset planeerimisrežiimi, on võimalik täiendava kindluse ja kvaliteedi tagamiseks lasta AI-l alustuseks analüüsida: kas ta sai tööülesandest õigesti aru, kas ta võttis arvesse kogu konteksti ja kõiki mittefunktsionaalseid nõudeid. Alles seejärel lastakse ülesanne ära realiseerida.

Koodiülevaatus ja AI-ga paarisprogrammeerimine

Kindlasti peab täna agendi töö valmimisele järgnema ka arendajapoolne koodiülevaatus. Koodi kvaliteedi vastutus jääb arendajale, kes ülevaatust teeb – seda rolli ei saa agentidele delegeerida. Nii nagu analüütik vastutab oma sisendi eest ka siis, kui osa kirjeldamisest teeb AI, vastutab arendaja lõpliku koodi eest: kui agent toodab sobimatu lahenduse, saab arendaja selle muuta, sisendit täpsustada või töö tagasi lükata.

Praktikas tähendab see, et arendaja võib AI-d kasutada kui paarisprogrammeerijat: koodi kirjutamine ja kiire ülevaatus käivad läbisegi, et kohe parandada ja õppida. Selline skeem eeldab, et arendaja oskab AI-d hästi kasutada – siis on agent tõeline võimendaja, mitte lisarisk.

Kokkuvõte

Kokkuvõtvalt võib öelda, et peamised arenduse etapid jäävad ka sellise arendusmudeli juures samaks nagu analüüs ja arhitektuur. Küll aga liigub nii arhitekti, analüütiku kui ka arendaja enda roll suunas, kus nende eesmärk on tekitada sobivad tingimused selleks, et AI-põhine koodiagent saaks õnnestuda.

Kõik eelnev põhineb isiklikul kogemusel ja praeguse ajal maailmapraktikate arenguid igapäevaselt jälgides. Iga meeskond saab need põhimõtted enda konteksti kohandada ja võtta kasutusele selle osa, mis päriselt väärtust lisab.

Mart Järvi
valdkonna peaarhitekt