Pillar lapa

Programmatūras izstrāde ar MI

Pārbaudīts izstrādes automatizācijas process ar MI aģentu komandu — no prasību analīzes, caur kodēšanu un daudzslāņu testiem (unit, integrācijas, E2E, drošības, veiktspējas), līdz ražošanas izvietošanai ar pilnu audita pierakstu.

Parunāsim par pilotprojektu Mūsu pakalpojumi

Mūsu rīcībā ir specializētu MI aģentu komanda, kas piedalās katrā programmatūras izstrādes cikla posmā — no prasību analīzes, caur arhitektūras projektēšanu, kodēšanu un daudzslāņu testēšanu, līdz koda pārskatam, dokumentācijai un izvietošanai ar pilnu audita pierakstu.

Tā mēs veidojam savus ESKOM AI produktus — daudzu aģentu platformu HybridCrew, Compliance audita sistēmu, KRS+CRBR mikropakalpojumu un vairākas integrācijas. To pašu procesu piemērojam klientu projektos: gan veidojot jaunus mikropakalpojumus, gan modernizējot legacy sistēmas.

Šajā rakstā aprakstīts, kā tas darbojas praksē: kādus uzdevumus pārņem aģenti, kas paliek cilvēka pusē, kādus testus palaižam un kāpēc šis process ir atkārtojams.

Kāpēc automatizēt izstrādi?

Klasisks programmatūras izstrādes cikls (analīze → kods → testi → pārskats → izvietošana) nobriedušā komandā vidēja izmēra funkcijai parasti aizņem 2-4 nedēļas. Lielākā daļa šī laika ir atkārtoti uzdevumi: boilerplate rakstīšana, vienību testu ģenerēšana, izmaiņu pārskatīšana, dokumentācijas atjaunināšana, datu bāzes migrāciju ģenerēšana. Visi tie ir automatizējami.

Mūsu procesa mērķis ir vienkāršs: divi-trīs cilvēki ar MI aģentiem nodrošina vērtību, ko agrāk sniedza 8-10 cilvēku komanda — bez izdegšanas, ar augstāku kvalitāti (vairāk testu, labāks koda pārskats, pilna dokumentācija) un saīsinātu laiku līdz tirgum.

Tas nav „MI aizstās programmētājus". Tas ir „programmētāji ar MI aizstās programmētājus bez MI". Pieredzējuši inženieri paliek nepieciešami — viņi projektē arhitektūru, pieņem stratēģiskus lēmumus, pārskata sarežģītas izmaiņas. Aģenti pārņem rutīnu.

Sešu posmu process

Plūsma no prasībām līdz ražošanai. Katru posmu veic specializēti MI aģenti, un cilvēks uzrauga un apstiprina galvenos lēmumus.

Prasību analīze un arhitektūra

MI aģenti analizē biznesa dokumentāciju, sarunas ar klientu (no transkripcijām), esošo kodu. Piedāvā mikropakalpojumu arhitektūru, datu bāzes shēmu, galapunktu sarakstu, atļauju modeli. Cilvēks (CTO/arhitekts) pirms kodēšanas pārskata un apstiprina priekšlikumu.

Koda rakstīšana (TDD)

Vispirms testi, tad ieviešana. Backend aģents raksta API valodā FastAPI/Express, frontend aģents — React komponentus. Katras izmaiņas = atsevišķs pull request ar skaidru commit ziņojumu. Kodēšanas standartus (Black, ESLint, Prettier) automātiski piespiež.

Daudzslāņu testēšana

Unit (pytest, Jest), integrācijas (testcontainers ar reālu PostgreSQL), E2E (Playwright), UI snapshot, drošības (OWASP, gitleaks, bandit), veiktspējas (k6/locust), pieejamības (axe). Katrs PR palaiž pilnu plūsmu — neizdevies tests bloķē merge.

MI koda pārskats

SecurityReviewer aģents skenē OWASP Top 10 jautājumus, QualityReviewer aģents pārbauda lasāmību un šablonus, ArchitectureReviewer aģents verificē konsekvenci ar pārējo sistēmu. Šaubīgas vietas tiek eskalētas cilvēkam.

Dokumentācija un CHANGELOG

Katras izmaiņas loģikā = versijas paaugstinājums + ieraksts CHANGELOG.md formātā Keep a Changelog. API dokumentācija (OpenAPI/Swagger) tiek ģenerēta automātiski. CLAUDE.md tiek atjaunināts pēc katras sesijas ar jaunām atziņām.

Izvietošana ar Change Request

Izvietošana vienmēr caur Git (NEKAD tiešs scp). Vispirms testa vide, Playwright verifikācija, tikai pēc tam ražošana pēc CR apstiprināšanas. Izvietošanas skripts iekļauj atcelšanas plānu (<5 min) un veselības pārbaudes.

Ko iegūst uzņēmums?

Tūkstošiem automātisku testu

Katram ražošanas projektam ir no dažiem līdz vairākiem desmitiem tūkstošu testu — unit, integrācijas, E2E, drošības, veiktspējas. Regresijas tiek atklātas CI, pirms tās nonāk pie lietotāja.

Pilns audita pieraksts

Katras izmaiņas kodā, datu bāzē, konfigurācijā tiek pierakstītas: Git, audita žurnāls datu bāzē, CHANGELOG, Change Request. Atbilst ISO 27001, EU AI Act, GDPR prasībām.

Komandas mērogojamība

Divi-trīs cilvēki ar MI aģentiem nodrošina vērtību, ko agrāk sniedza 8-10 cilvēku komanda. Bez izdegšanas, ar augstāku kvalitāti un īsāku grafiku.

Eskalācija uz stiprākiem modeļiem

LLM maršrutēšana izvēlas piemērotu modeli uzdevumam: nelielas izmaiņas — lokāls Ollama (izmaksas $0), sarežģīta arhitektūra — Claude Opus. Izmaksu un kvalitātes optimizācija vienā.

Atkārtojamība un standarti

Katrs projekts izmanto tos pašus standartus: feature branch workflow, squash merge, Conventional Commits, CHANGELOG, EU AI Act, GDPR. Jauns izstrādātājs saprot struktūru vienā dienā.

Drošība pēc noklusējuma

Gitleaks pre-commit + CI, noslēpumi HashiCorp Vault, privāti repozitoriji, Keycloak SSO, Tailscale VPN iekšējiem pakalpojumiem. Nulles kompromisi attiecībā uz ātrumu.

Daudzslāņu testēšana — kvalitātes pamats

Katras ražošanas koda izmaiņas iziet caur pilnu testa plūsmu. Bez izņēmumiem — pat drukas kļūdas labojums komentārā palaiž CI, jo testa plūsma ir iebūvēta Git hook, nevis izstrādātāja politisks lēmums.

Vienību testi (unit): pytest, Jest, vitest. Pārbauda atsevišķas funkcijas un klases. Pārklājums >80% kritiskajam kodam.
Integrācijas testi: testcontainers ar reāliem PostgreSQL, Redis, Vault gadījumiem. Mock objekti tikai trešās puses ārējiem API.
E2E (end-to-end) testi: Playwright Firefox pārlūkā (pēc noklusējuma), Chrome (pēc izvēles). Simulē pilnus lietotāja ceļus: pieslēgšanās → darbība → verifikācija.
UI testi (snapshot, pieejamības): Playwright + axe-core. WCAG 2.0 AA kā bāzes līmenis, Lighthouse 100/100/100/100 kā mērķis.
Drošības testi: OWASP Top 10 (semgrep, bandit, eslint-plugin-security), gitleaks (noslēpumu skenēšana pre-commit un CI), trivy (Docker attēlu skenēšana).
Veiktspējas testi: k6 vai locust slodzes testiem, p95/p99 atbildes laika pārbaude zem slodzes.
Regresijas testi: pilna kopa palaista pirms katras ražošanas izvietošanas. Katrs ziņotais defekts kļūst par regresijas testu.
Smoke testi: minimāla 5-10 testu kopa, ko palaiž pēc izvietošanas ražošanas vidē (vai aplikācija vispār ir startējusi).
Acceptance testi: biznesa testi (Cucumber/Gherkin), kas apstiprina, ka prasība ir izpildīta.

Neizdevies tests = bloķēts merge. Bez izņēmumiem. Ja tests ir „flaky" (nestabils), diagnostikas aģents analizē cēloni un labo testu vai kodu, bet nekad nedzēš testu bez cilvēka lēmuma.

Tipiski lietojuma gadījumi

Šabloni, ko izmantojam visbiežāk. Katram ir savs aģentu, rīku un veidņu komplekts. Laiks līdz vērtībai mērīts nedēļās, nevis mēnešos.

Legacy sistēmas modernizācija

•Veca monolīta aplikācija (PHP/.NET, bez testiem, grūti uzturēt)
•Aģenti monolītu sadala mikropakalpojumos (inkrementāls process, bez dīkstāves)
•Pirms refaktorēšanas ģenerē raksturojuma testus (nofiksē pašreizējo uzvedību)
•Datu migrācija ar pilnu audita pierakstu un atcelšanas plānu

Jauns enterprise mikropakalpojums

•Specifikācija ieejā (Jira tikets, PRD dokuments, sapulces transkripcija)
•Arhitektūra → kods → testi → pārskats → izvietošana 2-3 nedēļās
•Integrācija ar esošo SSO (Keycloak), audita žurnālu, monitoringu
•Pilna atbilstība EU AI Act un GDPR no pirmās koda rindas

Sistēmu integrācija

•ERP, CRM, KRS, Microsoft Graph, IBM, Cisco, ārējo partneru savienošana
•Aģenti raksta adapterus, kartējumus, retry/backoff, idempotenci
•Integrācijas testi reālos galapunktos (sandbox API)
•Monitorings (Prometheus + Grafana) un brīdinājumi (Sentry) automātiski pievienoti

Multi-tenant platformas

•Daudzklientu SaaS ar pilnu datu izolāciju (per-tenant shēma vai row-level security)
•Klientu onboarding automatizēts (Keycloak provisioning, datu bāze, lomas)
•Norēķini balstīti uz SSO Billing SDK (token usage tracking, fail-open)
•Atbilstība: GDPR, ISO 27001, EU AI Act gatava auditam

Salīdzinājums: klasiska komanda vs. MI process

Aspekts	Klasiska komanda (8-10 cilvēki)	Komanda ar MI aģentiem (2-3 cilvēki)
Laiks līdz tirgum (vidēja funkcija)	2-4 nedēļas	3-7 dienas
Testu pārklājums	40-60% (ja komandai ir laiks)	>80% pēc noklusējuma (testi tiek ģenerēti kopā ar kodu)
Koda pārskats	1 cilvēks, vidēji 30-60 min	3 aģenti (drošības, kvalitātes, arhitektūras) + cilvēks pie sarežģītām izmaiņām
Dokumentācija	Bieži nepilna, „pievienota vēlāk"	Ģenerēta kopā ar kodu (OpenAPI, README, CHANGELOG)
Audita pieraksts	Git vēsture	Git + audita žurnāls datu bāzē + CHANGELOG + Change Request
Mērogošana	Lineāra (vairāk cilvēku = augstākas komunikācijas izmaksas)	Nelineāra (vairāk aģentu = tas pats cilvēku skaits uzraudzībā)
Atbilstība (EU AI Act, GDPR, ISO 27001)	Bieži ārējs audits pēc fakta	Iebūvēta procesā no pirmās koda rindas

Biežāk uzdotie jautājumi

Kas ir automatizēta programmatūras izstrāde ar MI?

Tas ir process, kurā specializēti MI aģenti piedalās katrā programmatūras izstrādes cikla posmā: no prasību analīzes, caur arhitektūras projektēšanu, kodēšanu, automātiskiem testiem (unit, integrācijas, E2E, drošības, veiktspējas, regresijas), līdz koda pārskatam un ražošanas izvietošanai. Cilvēks joprojām uzrauga procesu un pieņem galvenos lēmumus, bet rutīnas uzdevumus (koda rakstīšana, testu ģenerēšana, refaktorēšana, dokumentācija) veic MI aģenti, ievērojot saskaņotos kvalitātes standartus.

Ar ko šis process atšķiras no klasiskās programmēšanas ar Copilot?

Copilot ir automātiskā papildināšana — palīdz uzrakstīt atsevišķas koda rindas. Programmatūras izstrāde ar MI ir pilna orķestrācija: viens aģents plāno arhitektūru, otrs raksta kodu, trešais raksta testus, ceturtais veic koda pārskatu, piektais izvieto. Katram ir sava specializācija, epizodiskā atmiņa (mācās no iepriekšējiem projektiem), rīki un konteksts. Rezultāts: daudz lielāks automatizācijas mērogs nekā ar vienu Copilot, saglabājot enterprise standartus (testi, drošība, audita pieraksts).

Kādus testu veidus palaiž šis process?

Katru testu veidu, kas tiek izmantots nobriedušās izstrādes komandās: vienību (unit), integrācijas, end-to-end (E2E), UI (Playwright), drošības (OWASP Top 10, gitleaks), veiktspējas (load), regresijas, smoke un acceptance. Testi tiek rakstīti pirms koda vai paralēli tam (TDD), un katrai izmaiņai ir jāiziet visa plūsma.

Vai MI patstāvīgi izvieto kodu ražošanā?

Ne automātiski. Ražošanas izvietošanas prasa apstiprinātu Change Request (CR) un cilvēka lēmumu. MI aģenti sagatavo izmaiņu dokumentāciju, palaiž regresijas testus, ģenerē izvietošanas skriptus ar atcelšanas plāniem, taču galīgā palaišana ražošanā prasa operatora apstiprinājumu. Šis noteikums ir apzināts — tas minimizē neparedzētu seku risku un saglabā pilnu audita pierakstu.

Vai šis process darbojas enterprise projektos?

Jā. Mēs to izmantojam savos produktos, ieskaitot daudzu aģentu platformu HybridCrew, konsultāciju platformu ar SSO, PostgreSQL mikropakalpojumos, integrācijās ar ārējām sistēmām (KRS, MS Graph, IBM, Keycloak). Katram projektam ir sava CI/CD plūsma, dev/test/prod vides, monitorings un audita žurnāls. Process mērojas no atsevišķa mikropakalpojuma līdz daudzu konteineru platformai.

Cik ilgs laiks vajadzīgs, lai šo procesu ieviestu mūsu uzņēmumā?

Atkarīgs no konteksta. Mazai komandai (1-3 izstrādātāji) integrācija ar esošo repozitoriju un CI/CD plūsmu parasti aizņem 2-4 nedēļas: audits, aģentu konfigurācija, pielāgošanās kodēšanas standartiem, apmācība. Lielākām organizācijām pilotprojekti (viena komanda, viens mikropakalpojums) ilgst 6-8 nedēļas, pēc kā seko pakāpeniska paplašināšanās uz nākamajām komandām.

Kā ar pirmkoda drošību?

Klienta repozitoriji nekad netiek nodoti ārējiem pakalpojumiem bez nepārprotamas piekrišanas. Pēc noklusējuma viss process (MI aģenti, LLM modeļi, vektoru datu bāze, audita žurnāls) darbojas klienta infrastruktūrā vai ESKOM AI privātajā mākonī ar pilnu izolāciju. Noslēpumus pārvaldām caur HashiCorp Vault, kodu skenējam ar gitleaks pirms katra commit, un visi repozitoriji pēc noklusējuma ir privāti.

Vai aizstāsiet mūsu izstrādes komandu?

Nē. Pieredzējuši izstrādātāji ir nepieciešami — viņi projektē arhitektūru, pieņem lēmumus, pārskata sarežģītas izmaiņas, risina netipiskas problēmas. MI aģenti pārņem atkārtotus un automatizācijai piemērotus uzdevumus: boilerplate rakstīšana, testu ģenerēšana, dokumentācija, refaktorēšana, pirmā līmeņa koda pārskats. Mērķis: divi-trīs cilvēki ar MI nodrošina vērtību, ko agrāk sniedza 8-10 cilvēku komanda — bez izdegšanas, ar augstāku kvalitāti un pilnu audita pierakstu.

Cik maksā programmatūras izstrāde ar MI?

Cenas vienmēr ir individuālas un atkarīgas no mēroga, norēķinu modeļa (platformas abonēšana vs. dedicēts projekts), nepieciešamajām integrācijām un no tā, vai aģenti darbojas lokālos LLM modeļos (Ollama klienta GPU — zemākas darbības izmaksas) vai mākonī (Anthropic, OpenAI — augstāka elastība). Pilotprojektos cenšamies sasniegt ieguldījumu atdevi pirmajā ceturksnī pēc pilnas palaišanas.

Kādi ir tipiski signāli, ka uzņēmums ir gatavs šim procesam?

Labākos rezultātus sasniedz komandas, kurām jau ir: versiju kontrolēts repozitorijs (Git), definēti kodēšanas standarti, pamata CI/CD plūsma, skaidri dokumentētas prasības (Jira/Linear/pašu sistēma) un koda pārskata kultūra. Kāda no šiem elementiem trūkums nebloķē ieviešanu — tādā gadījumā sākam ar auditu un pamatu sagatavošanu. Vismazāk nobriedušas ir organizācijas bez versiju kontroles vai ar ražošanas kodu, ko neviens netestē.

Gatavi pilotprojektam?

Sākam ar esošā procesa auditu un pilotprojektu izvēlētā mikropakalpojumā. Pirmie rezultāti redzami 2-4 nedēļās. Bez ilgtermiņa līgumiem.

Pierakstīties uz sarunu Skatīt produktus