Pilier puslapis

Programinės įrangos kūrimas su DI

Patikrintas programinės įrangos kūrimo automatizavimo procesas su DI agentų komanda — nuo reikalavimų analizės, per kodavimą ir daugiasluoksnį testavimą (vienetinį, integracinį, E2E, saugos, našumo), iki produkcinio diegimo su pilnu audito pėdsaku.

Pakalbėkime apie bandomąjį projektą Mūsų paslaugos

Turime specializuotų DI agentų komandą, kuri dalyvauja kiekviename programinės įrangos kūrimo ciklo etape — nuo reikalavimų analizės, per architektūros projektavimą, kodavimą ir daugiasluoksnį testavimą, iki kodo peržiūros, dokumentacijos ir diegimo su pilnu audito pėdsaku.

Būtent taip kuriame savo ESKOM AI produktus — HybridCrew daugiakomponentę platformą, Compliance audito sistemą, KRS+CRBR mikropaslaugą ir keliolika integracijų. Tą patį procesą taikome klientų projektuose: tiek kuriant naujas mikropaslaugas, tiek modernizuojant senas (legacy) sistemas.

Šis straipsnis aprašo, kaip tai veikia praktikoje: kokias užduotis perima agentai, o kurios lieka žmogaus pusėje, kokius testus paleidžiame ir kodėl šis procesas yra kartotinis.

Kam automatizuoti kūrimo procesą?

Klasikinis programinės įrangos kūrimo ciklas (analizė → kodas → testai → peržiūra → diegimas) brandžioje komandoje vidutinio dydžio funkcijai paprastai užtrunka 2-4 savaites. Didžioji laiko dalis skiriama pasikartojančioms užduotims: boilerplate kodo rašymui, vienetinių testų generavimui, pakeitimų peržiūrai, dokumentacijos atnaujinimui, duomenų bazės migracijų generavimui. Visa tai pasiduoda automatizavimui.

Mūsų proceso tikslas paprastas: du-trys žmonės su DI agentais sukuria tokią vertę, kokią anksčiau teikė 8-10 žmonių komanda — be perdegimo, su geresne kokybe (daugiau testų, geresnė kodo peržiūra, pilna dokumentacija) ir trumpesniu time-to-market.

Tai nėra „DI pakeis programuotojus". Tai yra „programuotojai su DI pakeis programuotojus be DI". Patyrę inžinieriai išlieka būtini — projektuoja architektūrą, priima strateginius sprendimus, peržiūri sudėtingus pakeitimus. Agentai perima rutiną.

Šeši proceso etapai

Pipeline nuo reikalavimų iki produkcijos. Kiekvieną etapą atlieka specializuoti DI agentai, o žmogus prižiūri ir tvirtina pagrindinius sprendimus.

Reikalavimų analizė ir architektūra

DI agentai analizuoja verslo dokumentaciją, pokalbius su klientais (iš transkripcijų), esamą kodą. Siūlo mikropaslaugų architektūrą, duomenų bazės schemą, endpoint'ų sąrašą, leidimų modelį. Žmogus (CTO/architektas) peržiūri ir patvirtina pasiūlymą prieš pradedant kodavimą.

Kodo rašymas (TDD)

Pirmiausia testai, tada įgyvendinimas. Backend agentas rašo API FastAPI/Express, frontend agentas — React komponentus. Kiekvienas pakeitimas = atskiras pull request su aiškiu commit pranešimu. Kodavimo standartai (Black, ESLint, Prettier) užtikrinami automatiškai.

Daugiasluoksnis testavimas

Vienetiniai (pytest, Jest), integraciniai (testcontainers su tikru PostgreSQL), E2E (Playwright), UI snapshot, saugos (OWASP, gitleaks, bandit), našumo (k6/locust), prieinamumo (axe). Kiekvienas PR paleidžia visą pipeline — raudonas testas = užblokuotas merge.

DI kodo peržiūra

SecurityReviewer agentas skenuoja pagal OWASP Top 10, QualityReviewer agentas tikrina skaitomumą ir šablonus, ArchitectureReviewer agentas — nuoseklumą su likusia sistemos dalimi. Abejotinos vietos eskaluojamos žmogui.

Dokumentacija ir CHANGELOG

Kiekvienas logikos pakeitimas = versijos pakėlimas + įrašas CHANGELOG.md pagal Keep a Changelog formatą. API dokumentacija (OpenAPI/Swagger) generuojama automatiškai. CLAUDE.md atnaujinamas po kiekvienos sesijos su naujomis pamokomis.

Diegimas su Change Request

Diegimas visada per Git (NIEKADA tiesioginis scp). Pirmiausia testavimo aplinka, Playwright patikra, tik tada produkcija po CR patvirtinimo. Diegimo skriptas apima rollback planą (<5 min) ir health check'us.

Ką įmonė gauna?

Tūkstančiai automatinių testų

Kiekvienas produkcinis projektas turi nuo kelių iki keliolikos tūkstančių testų — vienetinių, integracinių, E2E, saugos, našumo. Regresijos aptinkamos CI, prieš pasiekiant vartotoją.

Pilnas audito pėdsakas

Kiekvienas pakeitimas kode, duomenų bazėje, konfigūracijoje yra užfiksuotas: Git, audito žurnalas duomenų bazėje, CHANGELOG, Change Request. Atitinka ISO 27001, EU AI Act, BDAR reikalavimus.

Komandos mastelio keitimas

Du-trys žmonės su DI agentais teikia tokią vertę, kokią anksčiau teikė 8-10 žmonių komanda. Be perdegimo, su geresne kokybe ir greitesniu grafiku.

Eskalavimas į stipresnius modelius

LLM maršrutizavimas parenka tinkamą modelį užduočiai: smulkūs pakeitimai — vietinis Ollama (kaina $0), sudėtinga architektūra — Claude Opus. Kainos ir kokybės optimizacija viename.

Kartotinumas ir standartai

Kiekvienas projektas taiko tuos pačius standartus: feature branch workflow, squash merge, Conventional Commits, CHANGELOG, EU AI Act, BDAR. Naujas kūrėjas supranta struktūrą per 1 dieną.

Sauga pagal nutylėjimą

Gitleaks pre-commit + CI, paslaptys HashiCorp Vault, privatūs repozitoriumai, SSO Keycloak, Tailscale VPN vidinėms paslaugoms. Jokių kompromisų greičio sąskaita.

Daugiasluoksnis testavimas — kokybės pagrindas

Kiekvienas produkcinio kodo pakeitimas pereina pilną testų pipeline. Be išimčių — net rašybos klaidos taisymas komentare paleidžia CI, nes testų pipeline įdiegtas į Git hook, o ne yra politinis kūrėjo sprendimas.

Vienetiniai testai (unit): pytest, Jest, vitest. Tikrina atskiras funkcijas ir klases. Padengimas >80% kritiniam kodui.
Integraciniai testai: testcontainers su tikromis PostgreSQL, Redis, Vault instancijomis. Mock'ai tik trečiųjų šalių išorinių API.
E2E (end-to-end) testai: Playwright Firefox naršyklėje (numatytasis), Chrome (pasirinktinai). Simuliuoja pilnus vartotojo kelius: prisijungimas → veiksmas → patikra.
UI testai (snapshot, prieinamumas): Playwright + axe-core. WCAG 2.0 AA kaip pagrindas, Lighthouse 100/100/100/100 kaip tikslas.
Saugos testai: OWASP Top 10 (semgrep, bandit, eslint-plugin-security), gitleaks (paslapčių skenavimas pre-commit ir CI), trivy (Docker atvaizdų skenavimas).
Našumo testai: k6 arba locust apkrovos testams, p95/p99 atsako laiko tikrinimas esant apkrovai.
Regresijos testai: pilnas suite paleidžiamas prieš kiekvieną produkcinį diegimą. Kiekviena pranešta klaida tampa regresijos testu.
Smoke testai: minimalus 5-10 testų rinkinys, paleidžiamas po diegimo produkcinėje aplinkoje (ar aplikacija išvis pasileido).
Priėmimo (acceptance) testai: verslo testai (Cucumber/Gherkin), patvirtinantys, kad reikalavimas įgyvendintas.

Raudonas testas = užblokuotas merge. Be išimčių. Jei testas yra „flaky" (nestabilus), diagnostikos agentas analizuoja priežastį ir taiso testą arba kodą, bet niekada nepašalina testo be žmogaus sprendimo.

Tipiški panaudojimo atvejai

Šablonai, kuriuos taikome dažniausiai. Kiekvienas turi savo agentų, įrankių ir šablonų rinkinį. Time-to-value matuojamas savaitėmis, ne mėnesiais.

Senos (legacy) sistemos modernizavimas

•Sena monolitinė aplikacija (PHP/.NET, be testų, sunkiai prižiūrima)
•Agentai išskaido monolitą į mikropaslaugas (inkrementinis procesas, be prastovų)
•Generuoja charakteristinius testus (užfiksuojančius esamą elgesį) prieš refaktoringą
•Duomenų migracija su pilnu audito pėdsaku ir rollback planu

Nauja enterprise mikropaslauga

•Specifikacija įvestyje (Jira ticket, PRD dokumentas, susitikimo transkripcija)
•Architektūra → kodas → testai → peržiūra → diegimas per 2-3 savaites
•Integracija su esamu SSO (Keycloak), audito žurnalu, monitoringu
•Pilnas atitikimas EU AI Act ir BDAR nuo pirmos kodo eilutės

Sistemų integracija

•ERP, CRM, KRS, Microsoft Graph, IBM, Cisco, išorinių partnerių jungimas
•Agentai rašo adapterius, mapping'us, retry/backoff, idempotentiškumą
•Integraciniai testai su tikrais endpoint'ais (sandbox API)
•Monitoringas (Prometheus + Grafana) ir įspėjimai (Sentry) prijungiami automatiškai

Multi-tenant platformos

•Daugiaklientės SaaS su pilna duomenų izoliacija (per-tenant schema arba row-level security)
•Automatizuotas kliento onboarding (Keycloak provisioning, duomenų bazė, rolės)
•Apmokėjimas pagrįstas SSO Billing SDK (token usage tracking, fail-open)
•Compliance: BDAR, ISO 27001, EU AI Act paruošti auditui

Palyginimas: klasikinė komanda vs. procesas su DI

Aspektas	Klasikinė komanda (8-10 žmonių)	Komanda su DI agentais (2-3 žmonės)
Time-to-market (vidutinė funkcija)	2-4 savaitės	3-7 dienos
Testų padengimas	40-60% (jei komanda turi laiko)	>80% pagal nutylėjimą (testai generuojami kartu su kodu)
Kodo peržiūra	1 asmuo, vidutiniškai 30-60 min	3 agentai (saugos, kokybės, architektūros) + žmogus sudėtingiems pakeitimams
Dokumentacija	Dažnai nepilna, „pridedama vėliau"	Generuojama kartu su kodu (OpenAPI, README, CHANGELOG)
Audito pėdsakas	Git istorija	Git + audito žurnalas duomenų bazėje + CHANGELOG + Change Request
Mastelio keitimas	Tiesinis (daugiau žmonių = didesnė komunikacijos kaina)	Netiesinis (daugiau agentų = tas pats prižiūrinčių žmonių skaičius)
Compliance (EU AI Act, BDAR, ISO 27001)	Dažnai išorinis auditas post factum	Įdiegta į procesą nuo pirmos kodo eilutės

Dažniausiai užduodami klausimai

Kas yra automatizuotas programinės įrangos kūrimas su DI?

Tai procesas, kuriame specializuoti DI agentai dalyvauja kiekviename programinės įrangos kūrimo ciklo etape: nuo reikalavimų analizės, per architektūros projektavimą, kodavimą, automatinius testus (vienetinius, integracinius, E2E, saugos, našumo, regresijos), iki kodo peržiūros ir produkcinio diegimo. Žmogus toliau prižiūri procesą ir priima pagrindinius sprendimus, bet rutinines užduotis (kodo rašymą, testų generavimą, refaktoringą, dokumentaciją) atlieka DI agentai, išlaikant sutartus kokybės standartus.

Kuo šis procesas skiriasi nuo klasikinio programavimo su Copilot?

Copilot yra autocomplete — padeda rašyti atskiras kodo eilutes. Programinės įrangos kūrimas su DI yra pilna orkestracija: vienas agentas planuoja architektūrą, kitas rašo kodą, trečias rašo testus, ketvirtas atlieka kodo peržiūrą, penktas diegia. Kiekvienas turi savo specializaciją, epizodinę atmintį (mokosi iš ankstesnių projektų), įrankius ir kontekstą. Rezultatas: žymiai didesnis automatizavimo mastas nei naudojant vien Copilot, išlaikant enterprise standartus (testai, sauga, audito pėdsakas).

Kokius testų tipus paleidžia šis procesas?

Kiekvieną testų tipą, kuris naudojamas brandžiose kūrimo komandose: vienetinius (unit), integracinius, end-to-end (E2E), UI (Playwright), saugos (OWASP Top 10, gitleaks), našumo (load), regresijos, smoke ir priėmimo. Testai rašomi prieš arba kartu su kodu (TDD), o kiekvienas pakeitimas turi pereiti visą pipeline.

Ar DI savarankiškai diegia kodą į produkciją?

Ne automatiškai. Produkciniai diegimai reikalauja patvirtinto Change Request (CR) ir žmogaus sprendimo. DI agentai paruošia pakeitimų dokumentaciją, paleidžia regresijos testus, generuoja diegimo skriptus su rollback planu, bet galutinis paleidimas produkcijoje reikalauja operatoriaus sutikimo. Ši taisyklė tikslinga — minimizuoja nenumatytų pasekmių riziką ir išlaiko pilną audito pėdsaką.

Ar šis procesas tinka enterprise projektams?

Taip. Taikome jį savo produktuose, įskaitant HybridCrew platformą (daugiakomponentę), konsultacinę platformą su SSO, mikropaslaugas su PostgreSQL, integracijas su išorinėmis sistemomis (KRS, MS Graph, IBM, Keycloak). Kiekvienas projektas turi savo CI/CD pipeline, dev/test/prod aplinkas, monitoringą ir audito žurnalą. Procesas keičiamas mastelio nuo vienos mikropaslaugos iki kelių konteinerių platformos.

Kiek laiko užtrunka šio proceso įdiegimas mūsų įmonėje?

Priklauso nuo konteksto. Mažai komandai (1-3 kūrėjai) integracija su esamu repozitoriumu ir CI/CD pipeline paprastai užtrunka 2-4 savaites: auditas, agentų konfigūracija, pritaikymas kodavimo standartams, mokymai. Didesnėms organizacijoms bandomieji projektai (viena komanda, viena mikropaslauga) trunka 6-8 savaites, po to laipsniškas plėtimas į kitas komandas.

O kaip su šaltinio kodo saugumu?

Klientų repozitoriumai niekada nepatenka į išorines paslaugas be aiškaus sutikimo. Pagal nutylėjimą visas procesas (DI agentai, LLM modeliai, vektorinė duomenų bazė, audito žurnalas) veikia kliento infrastruktūroje arba privačiame ESKOM AI debesyje su pilna izoliacija. Paslaptis valdome per HashiCorp Vault, kodą skenuojame gitleaks prieš kiekvieną commit, o visi repozitoriumai pagal nutylėjimą yra privatūs.

Ar pakeisite mūsų kūrimo komandą?

Ne. Patyrę kūrėjai yra būtini — projektuoja architektūrą, priima sprendimus, peržiūri sudėtingus pakeitimus, sprendžia netipines problemas. DI agentai perima pasikartojančias ir automatizavimui pasiduodančias užduotis: boilerplate rašymą, testų generavimą, dokumentaciją, refaktoringą, pirmojo lygio kodo peržiūrą. Tikslas: du-trys žmonės su DI teikia tokią vertę, kokią anksčiau teikė 8-10 žmonių komanda — be perdegimo, su geresne kokybe ir pilnu audito pėdsaku.

Kiek kainuoja programinės įrangos kūrimas su DI?

Įkainis visada individualus ir priklauso nuo masto, atsiskaitymo modelio (platformos prenumerata vs. dedikuotas projektas), reikalingų integracijų bei to, ar agentai veikia vietiniuose LLM modeliuose (Ollama kliento GPU — mažesni veiklos kaštai) ar debesyje (Anthropic, OpenAI — didesnis lankstumas). Bandomuosiuose projektuose siekiame investicijų grąžos pirmąjį ketvirtį po pilno paleidimo.

Kokie tipiniai signalai, kad įmonė pasiruošusi šiam procesui?

Geriausius rezultatus pasiekia komandos, kurios jau turi: versijomis valdomą repozitoriumą (Git), apibrėžtus kodavimo standartus, bazinį CI/CD pipeline, aiškiai surašytus reikalavimus (Jira/Linear/savo) ir kodo peržiūros kultūrą. Vieno iš šių elementų trūkumas neblokuoja įdiegimo — tuomet pradedame nuo audito ir pagrindų paruošimo. Mažiausiai brandžios yra organizacijos be versijų valdymo arba su produkciniu kodu, kurio niekas netestuoja.

Pasiruošę bandomajam projektui?

Pradedame nuo esamo proceso audito ir bandymo pasirinktoje mikropaslaugoje. Pirmieji rezultatai matomi per 2-4 savaites. Be daugiamečių sutarčių įsipareigojimų.

Susitarti pokalbį Žiūrėti produktus