Den nøyaktige KI-leveransestakken en CPO bruker for å redusere omarbeid med 25 %
KI kan generere kode på sekunder. Men uten arkitektur hjelper den deg bare med å levere feil løsning raskere. I dette intervjuet deler en CPO og teknologidirektør det arkitektur-først-baserte KI-systemet han bruker for å halvere prototyptiden, redusere omarbeid med 25 % og utforme sikkerhetsregler for en KI-drevet programvareutviklingslivssyklus.
Yurii Lozinskyi
CPO og teknologidirektør i Verysell
KI-ledelse: KI flytter prosjektledelse fra koordinering til systemdesign og reduserer manuelle oppgaver ved å bygge inn KI.
Arkitekturens rolle: Robust arkitektur hindrer KI-leveringskaos ved å tilpasse KI-generert arbeid til kvalitetsstandarder og mål.
Prototyp effektivitet: Arkitekturveiledet KI reduserer kostnadene kraftig og fremskynder prototyper fra idé til fungerende modell på få dager.
Ingeniørverdi: KI øker verdien av senioringeniører ved å styrke arkitekturdesign og redusere tilfeldig koding.
Skiftet i prosjektledelse: Fremtidens prosjektlederroller vil utnytte KI til koordinering og ha større fokus på design, strategi og styring.
Yurii Lozinskyi er CPO og teknologidirektør i Verysell AI, der han leder AI-leveranser. Med 25 års erfaring er det han kan best: å gjøre programvare- og AI-initiativer om til målbare forretningsresultater.
Så vi satte oss ned med ham for å lære hvordan han gjør det. Her er det han fortalte oss.
Å sørge for at AI ikke bare er et skinnende leketøy
Jeg er en leder innen produktutvikling og teknologi som befinner seg der AI-systemer, programvareleveranser og forretningsvirkeligheten møtes. Jeg har brukt over 15 år på å levere løsninger innen bank, forsikring, ITSM/MSP-plattformer, detaljhandel og helsetjenester. Og av en eller annen grunn vender jeg stadig tilbake til forsikring, fordi det er der både kompleksiteten og påvirkningen er størst.
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
Akkurat nå driver jeg ikke prosjekter på tradisjonell måte. Jeg utformer hvordan prosjekter bør drives, og prøver å være praktisk involvert under leveransen. Det innebærer driftsmodeller, AI-drevne leveransemønstre og veikart for hypotesevalidering på tvers av flere team og kunder.
Kort sagt er jobben min å sørge for at AI ikke er et skinnende leketøy på siden, men en del av hvordan arbeidet defineres, utføres og styres fra ende til annen.
Hvordan AI flytter prosjektledelse fra koordinering til systemdesign
Leveranseledelse går fra kalenderstyring til systemdesign. Jeg bruker langt mindre tid i statusmøter eller på å utarbeide artefakter manuelt som maskiner nå produserer på sekunder. Hvis AI kan hjelpe meg med å skrive den første versjonen av en plan eller et sammendrag, lar jeg den gjerne gjøre det.
Mange prosjektledere bruker fortsatt 40–60 % av tiden på å etterspørre status, rapportere manuelt, identifisere grunnleggende risikoer og flytte informasjon mellom verktøy og personer. I et AI-forsterket miljø faller dette til under 10–15 %, ettersom innebygde agenter håndterer oppdateringer, sammendrag, påminnelser og enkle eskaleringer på tvers av Jira/Linear, Slack/Teams og dokumenter.
Avveiningen er at jobben min har flyttet seg opp et nivå: Jeg bekymrer meg for begrensninger, akseptansekriterier, beskyttelsesmekanismer og tilbakemeldingssløyfer. Med andre ord utformer jeg «skinnene» som mennesker og AI-agenter kjører på.
Jeg er arkitekturorientert: Jeg bruker C4-modellen og ISO/IEC 25010 som rammeverk for arkitekturvisjonsdokumenter, og bruker deretter disse som ledetekster. Det er den morsomme delen – å behandle arkitektur som et API for AI. Arkitekturdokumentene dine er ikke hyllevare, men drivstoff for en AI-drevet livssyklus for programvareutvikling (SDLC). Mer om dette om litt.
AI gjør det trivielt enkelt å gå raskt, så min rolle er å sørge for at vi går raskt i riktig retning. I stedet for å spørre «Hvem gjør hva denne uken?», spør jeg derfor: «Gjør systemet vårt det vanskelig å levere feil ting raskt?»
AI gjør det trivielt enkelt å gå raskt, så min rolle er å sørge for at vi går raskt i riktig retning.
Hvorfor arkitektur hindrer AI-utløst leveransekaos
Jeg liker C4, ISO 25010 og arkitekturvisjonsdokumenter fordi de danner en ryggrad for å integrere AI i leveranser. Uten denne ryggraden kan AI raskt bli enda en kilde til kaos i leveransene.
Mer konkret:
- C4 gir AI et kart over systemet. I stedet for «Bare skriv litt kode» kan vi si: «Innenfor denne konteksten og beholderen, mot disse grensesnittene, implementer denne endringen.» Dette holder AI-generert arbeid innenfor tydelige arkitektoniske rammer.
- ISO 25010 definerer hva som er «godt» utover «det kompilerer». Vi oversetter kvalitetsattributtene til konkrete scenarier – ytelse, sikkerhet, vedlikeholdbarhet og pålitelighet – og innarbeider dem i ledetekster og akseptansekriterier. AI genererer deretter konseptbevis og tester som samsvarer med uttrykkelige kvalitetsforventninger, ikke bare funksjonalitet.
- Arkitekturvisjonsdokumenter integrerer alt. De knytter sammen forretningsmål, C4-visninger og ISO-lignende kvalitetsscenarier i én samlet fortelling for både mennesker og AI. For mennesker fungerer de som et samordningsartefakt. For AI utgjør de den primære kontekstkilden for generering av kode, tester og dokumentasjon.
Sammen forvandler de AI fra en tilfeldig superkraft til en kontrollert komponent i en AI-drevet livssyklus for programvareutvikling, med tydelige grenser, sporbarhet og en felles forståelse av hva vi har som mål å bygge.
Slik reduserer du kostnadene ved å ta feil med arkitekturstyrte AI-prototyper
Her er et eksempel. Vi hadde en AI-funksjon for matching som i «den gamle verden» ville ha tatt omtrent to uker fra idé til en klikkbar prototype.
I stedet for å begynne med Jira-oppgaver og ad hoc-forespørsler skrev vi først et kort dokument for arkitekturvisjon. Vi tegnet diagrammer i C4-stil: systemkontekst, involverte containere, sentrale komponenter, samt en håndfull kvalitetsscenarioer inspirert av ISO 25010 (f.eks. responstid, revisjonssporbarhet og feilhåndtering).
Deretter behandlet vi denne arkitekturen som et API for AI:
- Vi matet dokumentet for arkitekturvisjon og C4-utdragene inn i kodeassistenten vår som eneste kilde til sannhet for forespørslene.
- Vi ba den generere grunnstruktur, logikk for kjerneflyten og tester i første versjon innenfor de angitte containerne og grensesnittene.
Du ber ikke AI om å «Skriv litt kode for meg», men om å «Implementere denne spesifikke samhandlingen med disse begrensningene og disse kvalitetsegenskapene». Det er et helt annet spill. Og resultatet ble en sammenhengende PoC på et par dager, i stedet for at vi måtte håndkode alt fra bunnen av.
Ingeniørene gjennomgikk og rettet fortsatt ting, men:
- Tiden fra «vi burde prøve dette» til «interessentene kan klikke seg gjennom en fungerende prototype» falt fra omtrent ti arbeidsdager til tre eller fire. Det føles nesten urettferdig hvor raskt du kan oppnå en troverdig prototype når arkitekturen forankrer forespørslene dine i stedet for vage ønsker.
- Vi så 20–25 % færre runder med omarbeiding, fordi den AI-genererte koden allerede respekterte grensene og mønstrene som var innebygd i arkitekturen.
- Ingeniørene rapporterte at de brukte rundt 20 % mindre tid på standardkode og limkode, noe som i praksis eliminerte behovet for en separat «integrasjonsingeniør»-rolle.
- Testdekningen for denne delen ble høyere i første runde, siden assistenten brukte de dokumenterte kvalitetsscenarioene til å foreslå tester av kanttilfeller som vi sannsynligvis ikke ville ha skrevet så tidlig.
Med andre ord: Da vi gjorde arkitekturen eksplisitt og strukturert, sluttet AI å oppføre seg som en smart autofullføring og begynte å fungere mer som en junioringeniør som faktisk forstår systemkartet, skriver god dokumentasjon og aldri sover.
Og viktigst av alt: Det reduserte kostnadene ved å ta feil, noe som er akkurat det du ønsker i uoversiktlige domener.
Hvorfor AI gjør senioringeniører mer verdifulle, ikke mindre
Til tross for det du kanskje tror, gjør AI senioringeniører mer verdifulle, ikke mindre.
Hvis du kobler AI til en svak arkitektur og dårlig dømmekraft, får du et rot som oppstår raskere. Setter du den under en dyktig arkitekt, kan plutselig én senior utforske fem utforminger før lunsj og fortsatt ha tid til å snakke med interessentene.
AI tetter noen kompetansegap, men forsterker forskjellen mellom tilfeldig koding og bevisst utforming.
Hvis du kobler AI til en svak arkitektur og dårlig dømmekraft, får du et rot som oppstår raskere. Setter du den under en dyktig arkitekt, kan plutselig én senior utforske fem utforminger før lunsj og fortsatt ha tid til å snakke med interessentene.
Farvel, forretningsanalytiker – velkommen, fagekspert.
Hvilke leveranseoppgaver bør automatiseres først med AI?
Akkurat nå er de delene av leveransearbeidet som egner seg best for automatisering, aktiviteter som er «konteksttunge, mønsterrike og lite egosensitive»:
- Som nevnt, generering av PoC-kode og tester fra arkitekturvisjonsdokumenter og C4/ISO 25010-spesifikasjoner
- Utarbeidelse av beslutningslogger, designalternativer og risikolister
- Å gjøre rotete Slack-tråder om til noe fremtidige deg kan lese uten å gråte
KI er utmerket til å foreslå; den er forferdelig til å ta ansvar. Det er her mennesker fortsatt har det fulle ansvaret:
- Å definere problemet
- Å veie risiko opp mot hastighet
- Å håndtere regulatoriske og etiske grenser
- Å avgjøre når «teknisk korrekt» fortsatt er feil ting å sette i produksjon
Det beste stedet å være akkurat nå er å komprimere de tidlige oppdagelses- og designløkkene. Agenter er gode til å omdanne en helhetlig spesifikasjon til plausible veier videre. De forstår ennå ikke når en vei er politisk, etisk eller strategisk feil, så mennesker beholder kontrollen.
Hvorfor prosjektledere bør prioritere tilbakemeldingssløyfer fremfor ritualer
Tradisjonell prosjektledelse inneholder ofte mange ritualer uten et tydelig formål. Jeg beveger meg bort fra dette og over mot systemer som prioriterer tilbakemeldinger fremfor ritualer.
I praksis betyr det:
- Færre monolittiske planer; flere små, testbare hypoteser
- Færre store statusmøter; flere asynkrone oppdateringer som oppsummeres automatisk av KI
- Færre oppblåste kravdokumenter; flere levende arkitekturvisjonsdokumenter som både mennesker og KI kan handle ut fra
Vi bryr oss fortsatt om datoer, budsjetter og risikoer. Men vi lar KI håndtere bokføringen, slik at mennesker kan konsentrere seg om design, beslutninger og interessentenes virkelighet.
Ironien er at når du fjerner halvparten av ritualene, respekterer folk den gjenværende strukturen mer.
Ironien er at når du fjerner halvparten av ritualene, respekterer folk den gjenværende strukturen mer.
Hvordan KI-integrasjoner effektiviserer prosjektleveranser i GitHub og CI/CD
Fra et teknisk perspektiv betydde «å gå lettvekts» å koble KI direkte inn i kodebasen og miljøene, ikke bare å legge til enda et kontrollpanel.
Mer konkret integrerte vi en KI-kodeassistent kalt Codex i GitHub-repositoriene og CI/CD-pipelinen vår. Utviklerne arbeider i sitt vanlige IDE, men assistenten kan se repositoriets struktur og gjøre alt jeg nevnte ovenfor, basert på C4-lignende arkitekturdiagrammer og et arkitekturvisjonsdokument. Til omtrent $20 USD per utvikler per måned er dette billigere enn nesten alle andre produktivitetsvirkemidler du kan ta i bruk.
I tillegg bruker vi enkel distribusjonsautomatisering (GitHub-baserte pipelines), slik at vi kan distribuere KI-assisterte endringer til et dedikert prototype-miljø med ett klikk.
Selv genereringen av ledetekster er delvis automatisert: En moderne modell i GPT-klassen (GPT-5.2) kan generere strukturerte ledetekster for verktøy som Eraser fra arkitekturvisjonsdokumentene våre.
Nøkkelen er at alt dette skjer innenfor standardiserte sikkerhetsrammer: Utviklerne gjennomgår fortsatt hver forespørsel om innfletting, CI/CD kjører fortsatt, og ingenting går i produksjon uten menneskelig godkjenning. KI akselererer de kjedelige delene; mennesker er fortsatt ansvarlige for design, risiko og den endelige avgjørelsen.
Hvorfor KI-prototyper omdefinerer leveranseritualene
Alt dette har hatt stor innvirkning på leveranseritualene våre.
Det å definere omfang pleide å være: «La oss snakke i timevis og deretter skrive et dokument som vi alle ignorerer.» Nå er det: «La oss komme raskt frem til en prototype og diskutere med noe interaktivt.»
Vi starter med et resultat på høyt nivå, fanger det i et arkitekturvisjonsdokument, skisserer C4-visninger og bruker deretter KI til å generere en PoC eller i det minste en realistisk skisse. Plutselig har alle en mening – fordi det finnes noe konkret å reagere på.
Med andre ord oppnår vi enighet rundt atferd, ikke punktlister.
Vi validerer ved hjelp av en blanding av KI-genererte tester (utmerket for dekning og regresjon) og menneskeutformede scenarier (utmerket for skjønn og merkelige grensetilfeller).
Og vi flytter gjennomføringsstyringen fra «tilordne oppgaver» til «utforme arbeidsflyter»: Hvem eller hva skal se dette arbeidet som neste, og med hvilken kontekst?
Slik ser en enkel leveransestakk for AI ut
Stakken min er tydelig basert på egne meninger, men enkel.
For arkitektur og samkjøring bruker jeg diagrammer i C4‑stil og arkitekturvisjonsdokumenter, tegnet i verktøy som Eraser. Det gjør dem enkle å videreutvikle foran mennesker og deretter mate inn i AI.
For spesifikasjoner foretrekker jeg tekstdokumenter som beskriver hensikt, begrensninger og kvalitetsattributter på en måte en LLM kan forstå.
På ingeniørsiden bruker jeg moderne IDE-er med god AI-støtte og verktøy som Claude Code og Codex til å generere PoC-implementasjoner og tester direkte fra disse arkitekturelementene. Jeg har bevisst ikke satt ut komplette funksjoner til AI for produksjon. Den utarbeider utkast, setter opp grunnstrukturen og foreslår løsninger. Ingeniørene – ekte mennesker – avgjør fortsatt hva som går i produksjon.
Det er viktig at hvert av disse verktøyene har sluttet å være en isolert øy. Nå er de koblet sammen i en AI-drevet SDLC: Krav, arkitektur, programmering, testing og til og med styring har alle et støttelag.
I praksis forventer jeg at denne endringen vil frigjøre omtrent 18-25 % produktivitetsgevinster på tvers av leveransen. Men det er viktig å presisere at tallet i stor grad avhenger av organisasjonens utgangspunkt – modenhet, eksisterende prosesser og arkitekturdisiplin.
Slik forbedrer selektiv bruk av verktøy AI-leveransen
Det siste året begynte vi bevisst å bytte ut og pilotere verktøy, i stedet for å forsøke å «AI-aktivere» alt på én gang.
På leveransesiden tok vi i bruk Miro til enkel veikartlegging og arkitekturworkshops, men bare som en pilot i noen få små prosjekter. Målet var å vurdere hvor godt Miro-tavler, kombinert med AI-genererte sammendrag, kunne erstatte lange presentasjoner og manuelle samkjøringsdokumenter. De første signalene er gode, men vi må fortsatt ferdigstille og skalere tilnærmingen før den blir standard.
For dokumentasjon og spesifikasjoner beholdt vi et tekstbasert dokumentasjonsverktøy for arkitekturvisjonsdokumenter. Vi la AI-støtte oppå dette med svært enkle, tilpassede GPT-er – og avviklet i det stille store, statiske spesifikasjonsdokumenter som vi ikke vedlikeholdt, og som ikke fungerte godt som grunnlag for ledetekster.
Jeg var inne på dette ovenfor, men på ingeniørsiden la vi til Codex som en AI-assistent for programmering, integrert med Git-repositoriet og CI-pipelinen vår, for oppsett av PoC-er og generering av tester, samtidig som vi beholdt de eksisterende IDE-ene og distribusjonsverktøyene våre. Med andre ord river vi ikke ut stakken ennå. Vi legger AI oppå der det tydelig sparer tid, og starter med kontrollerte piloter før vi ruller noe ut i hele selskapet.
Vi river ikke ut stakken ennå. Vi legger AI oppå der det tydelig sparer tid, og starter med kontrollerte piloter før vi ruller noe ut i hele selskapet.
Hvor prosjektledelse er på vei de neste fem årene
Om fem år vil «prosjektleder» som en ren koordineringsrolle i stor grad forsvinne i teknologibransjen. Arbeidet vil fortsatt eksistere, men innebygde AI-agenter vil håndtere det meste av koordineringen, oppfølgingen og rapporteringen i verktøyene dine.
Menneskene som tidligere ble kalt PM-er, vil enten gå videre til å utforme AI-drevne SDLC-er og styringsmodeller, eller over til produkt- og strategiske roller.
Resultattavler for PM-ytelse vil gå bort fra «i tide / innenfor budsjett» og over til et lite utvalg systemmåltall som de aktivt påvirker: gjennomløpstid for endringer, andel feil som slipper gjennom, beslutningsforsinkelse, gjennomføringstakt for eksperimenter og tillitspoeng fra interessenter. AI vil gjøre det meste av opptellingen. PM-ene vil være ansvarlige for om tallene beveger seg i riktig retning – ikke fordi de fulgte opp flere saker, men fordi de utformet bedre arbeidsmåter.
PM-ene som blir værende i «statusgjeting», vil i stillhet bli erstattet av roboter som gjør jobben døgnet rundt og ikke har noe imot å oppdatere seks resultattavler samtidig.
Hvorfor PM-er bør behandle AI som en lagkamerat, ikke som et tema som skal læres
Mitt råd: Slutt å prøve å «lære AI» som om det er et nytt rammeverk, og behandle det som en ny type lagkamerat med bestemte styrker og blindsoner. Vi kaller vår spøkefullt for «gptBuddy».
Velg én arbeidsflyt, ett team og én viktig måleindikator, og gjennomfør et kompromissløst eksperiment. Hvis du ikke ser en meningsfull forbedring, endrer du oppsettet eller avslutter.
Den virkelige verdien av AI ser kjedelig ut utenfra. Det er ikke science fiction-greiene folk forventer. Det er de lite glamourøse, kumulative gevinstene: testgenerering, opprydding i dokumentasjon, oppsett av grunnstruktur, utforsking av varianter og så videre.
Samtidig bør du løfte blikket fra verktøyene og skissere hvordan en AI-drevet SDLC ville sett ut for organisasjonen din. Hvis du ikke gjør det, vil noen andre gjøre det – og teamene deres vil bevege seg raskere, med færre møter og mindre drama.
Slutt å prøve å «lære AI» som om det er et nytt rammeverk, og behandle det som en ny type lagkamerat med bestemte styrker og blindsoner.
Følg med
Du kan følge Yurii Lozinskyi på LinkedIn og Dev.to mens han deler sin tekniske kunnskap om AI, utvikling, produkt og leveranser. Ta også en titt på Verysell AI.
Flere ekspertintervjuer kommer på The Digital Project Manager!
