CTO-en fornyer ingeniørlivssyklusen – og konsekvensene for teamet hans

Sergey Terentyev leder teknologi og ingeniørvirksomhet i et lisensiert digitalt bankmiljø. Det siste året har han gjennomgått hele utviklingslivssyklusen slik at KI er integrert i hvert trinn.

Vi tok en prat med Sergey for å lære mer. Han fortalte oss hva han endret, og hvordan det påvirket teamet hans.

KI endrer mer enn verktøyene

Jeg heter Sergey og er for tiden CTO innen bank og fintech i De forente arabiske emirater. Jeg begynte som programvareingeniør og gikk over i ledelse ved å bygge produkter, skalere team og løse komplekse teknologiproblemer.

Veien min til KI-transformasjon var enkel: Tradisjonelle metoder for å bygge og drive teknologiteam går for sakte. Team bruker fortsatt for mye tid på repetitive oppgaver, koordinering, dokumentasjon, brukerstøtte og manuelle prosesser.

Nå fokuserer jeg på praktisk bruk av KI i organisasjoner for utvikling og produktarbeid. Ikke KI som moteord, men som en måte å jobbe raskere på, forbedre leveransene, redusere sløsing og hjelpe mindre team med å oppnå mye mer.

Jeg ser på dette som en tid for å tenke nytt om hvordan teknologiorganisasjoner arbeider. KI endrer ikke bare verktøyene, men også teamene, ledelsen og hvordan selskaper bygger produkter.

Å balansere innovasjon og regulering

Organisasjonen der jeg leder teknologi og ingeniørvirksomhet, opererer i et sterkt regulert område. Teknologilandskapet kombinerer derfor moderne produktutvikling med sikkerhet, etterlevelse og driftskrav på virksomhetsnivå.

Ingeniørorganisasjonen dekker mobil- og nettplattformer, backend-tjenester, skyinfrastruktur, cybersikkerhet, integrasjoner, dataplattformer og leverandørstyring. Vi arbeider både med intern utvikling og strategiske eksterne partnere, samtidig som vi gradvis flytter flere kjernefunksjoner internt.

Arkitekturmessig beveger vi oss mot en mer modulær og API-drevet modell med tydeligere eierskap i produktutviklingsteamene. Miljøet er ganske komplekst fordi vi opererer på tvers av banksystemer, fintech-integrasjoner, betalingsinfrastruktur, kundeorienterte applikasjoner og interne driftsplattformer.

Distribusjon og leveranser skjer svært iterativt, med et sterkt fokus på automatisering, CI/CD, skyinfrastruktur, observerbarhet og operasjonell robusthet. En viktig prioritet er å redusere avhengigheten av tradisjonelle leveransemodeller og øke utviklingshastigheten gjennom KI-assistert utvikling og automatisering.

En stor del av rollen min handler om å balansere innovasjonstempoet med realitetene ved å operere i et regulert finansmiljø, der pålitelighet, sikkerhet og styring er avgjørende.

Slik endrer obligatorisk KI arbeidsflytene for utvikling

Vi introduserte KI direkte i arbeidsflyten for utviklingsleveranser, i stedet for å behandle det som et valgfritt individuelt verktøy.

Før dette brukte utviklerne mye tid på repetitive oppgaver som standardimplementering, dokumentasjon, kodeanalyse, feilsøking, testforberedelser, gjennomgang av leverandørkode og oversettelse av forretningskrav til tekniske oppgaver. Operasjonell belastning overlesset seniorutviklerne og hindret dem i å fokusere på arkitektur- og produktbeslutninger.

Det siste året har vi systematisk integrert KI-assistert utvikling i de daglige utviklingsprosessene. Dette omfattet kodegenerering, støtte ved kodegjennomgang, dokumentasjonsgenerering, konsekvensanalyse, hendelsesundersøkelser og raskere prototyping.

Endringen påvirket ikke bare hastigheten, men også hvordan teamene arbeider. Utviklerne bruker nå mindre tid på repetitive aktiviteter med lav verdi og mer tid på systemdesign, produktforståelse og beslutningstaking. Det reduserte også avhengigheten av et lite antall seniorer ved å gjøre det enklere å spre kunnskap på tvers av teamene.

Det største skiftet var sannsynligvis kulturelt. Teamene sluttet å se på KI som et eksperimentelt verktøy, og det ble en del av den normale arbeidsflyten for utvikling. Nå forventer de automatisering som standard, i stedet for å anta at alle prosesser må være manuelle.

Sergey deler

Vi introduserte KI direkte i arbeidsflyten for utviklingsleveranser, i stedet for å behandle det som et valgfritt individuelt verktøy.

Slik kan KI påvirke alle deler av utviklingslivssyklusen

La oss se på veien fra et forretningskrav til en produksjonsklar teknisk implementering.

Det starter vanligvis med en produkt- eller forretningsforespørsel skrevet i et høynivåspråk. KI bidrar med å oversette dette til strukturerte tekniske krav, identifisere avhengigheter, foreslå API-kontrakter og fremheve mulige grense­tilfeller eller integrasjonsrisikoer tidlig i prosessen.

Derfra bruker utviklere KI-assisterte utviklingsverktøy under implementeringen til å sette opp tjenester, generere repetitive kodemønstre, lage testtilfeller og effektivisere dokumentasjonen. Målet er ikke fullstendig autonom koding, men å redusere manuelt arbeid med lav verdi, slik at utviklerne kan fokusere på arkitektur og logikk.

Under utviklingen bidrar KI også med kodegjennomganger, forklarer ukjente deler av kodebasen, identifiserer mulige sårbarheter og validerer implementeringstilnærminger. For systemer som ofte er utsatt for hendelser, bruker utviklere KI til å analysere logger og oppsummere unormal atferd langt raskere enn ved tradisjonell manuell undersøkelse.

Når endringer går inn i distribusjonspipelines, håndterer automatisering testing, validering og overvåking. KI blir nyttig igjen etter distribusjon ved å hjelpe team med å tolke varsler, sammenstille hendelser og redusere tiden det tar å undersøke driftsproblemer.

Som du kan se, er KI nå integrert i hele utviklingslivssyklusen, i stedet for bare å være en isolert chatbot eller kodeassistent. Den har blitt en del av den daglige arbeidsflyten fra planlegging til drift.

Hvorfor CTO-er må forbedre maskinlesbarheten

Vi har redusert avhengigheten av sentralisert kunnskap og manuell koordinering. I stedet for at kritisk informasjon bare finnes hos bestemte personer eller team, har vi innført arbeidsflyter der KI hjelper utviklere med å navigere i systemer, forstå arkitekturen, analysere hendelser og komme raskere i gang på egen hånd.

Det bringer meg til en annen viktig endring vi har gjort: å utforme systemer for maskinlesbarhet, ikke bare lesbarhet for mennesker.

Ryddige API-er, strukturert dokumentasjon, overvåking, modulære tjenester og veldefinerte grensesnitt forbedrer både menneskelig produktivitet og KIs effektivitet betraktelig.

Hvorfor KI ikke kan håndtere skjønn i en regulert bransje

KI øker særlig leveringshastigheten og reduserer repetitivt utviklingsarbeid. Under håndtering av hendelser hjelper KI for eksempel utviklere med å analysere logger, identifisere mulige grunnårsaker, oppsummere funn og fremskynde undersøkelsen.

Samtidig er enkelte områder fortsatt uttrykkelig menneskestyrte. Endelige arkitekturbeslutninger, sikkerhetsstyring, risikoaksept, prioritering og ansvar for produksjonen krever fortsatt erfarne mennesker som kan utøve skjønn.

Kort sagt er KI svært god på akselerasjon og mønstergjenkjenning, men lederbeslutninger i komplekse systemer er fortsatt avhengige av kontekst, avveininger, forretningsprioriteringer, reguleringer og langsiktig tenkning. Særlig innen finansielle tjenester kan man ikke automatisere ansvar fullt ut.

Hvordan KI kan påvirke utviklingsteam negativt

Det største positive resultatet har vært utviklingshastigheten. Oppgaver som tidligere tok flere dager, kan nå noen ganger utføres på timer. Friksjonen i driften er også redusert, noe som forbedrer den samlede leveringsflyten og gjør det mulig for senioransatte å fokusere mer på arkitektur og beslutningstaking i stedet for stadig brannslukking.

Vi så også raskere opplæring og innføring fordi KI-støtte hjelper utviklere med å forstå ukjente systemer langt raskere.

Det har imidlertid også vært en negativ side:

• Vi lærte at kunstig intelligens kan skape en falsk følelse av trygghet. Generert kode ser ofte korrekt ut selv når de underliggende antakelsene er feil. Uten et solid teknisk fundament og gode prosesser for gjennomgang kan team bevege seg raskere i feil retning.
• Vi la merke til at svakere utviklere noen ganger blir for avhengige av KI-verktøy uten å forstå systemene de bygger fullt ut. En uventet utfordring var derfor å sikre at KI øker kapasiteten i stedet for å redusere den tekniske dybden.
• Styring og sikkerhet har blitt en større utfordring. I regulerte miljøer trenger man tydelige grenser for hvilke data eksterne KI-systemer kan få tilgang til, hvordan generert kode skal gjennomgås, og hvordan man sikrer at beslutninger fortsatt kan revideres.

Områder der KI ikke leverer som forventet

KI har ennå ikke levert på autonom programvareutvikling. Det er stor begeistring rundt ideen om fullstendig KI-genererte systemer eller å erstatte utviklingsteam, men i praksis er vi fortsatt langt unna dette i komplekse virksomhetsmiljøer.

KI akselererer, lager prototyper for og bistår erfarne utviklere svært godt. Men når systemer blir store, sammenkoblede, regulerte og driftskritiske, blir begrensningene tydelige. Håndtering av kontekst, langsiktig konsistens, arkitektoniske avveininger og dyp systemforståelse er fortsatt svakt sammenlignet med erfarne menneskers evner.

Påliteligheten til resultater som skal brukes i produksjon, skuffet meg også. KI-generert kode ser ofte imponerende ut i starten, men kvaliteten kan raskt forringes i spesielle tilfeller, ved skaleringsutfordringer, sikkerhetskrav eller behov for vedlikehold. De siste 20 prosentene av utviklingsarbeidet er fortsatt svært menneskelige.

Sergey deler

KI akselererer, lager prototyper for og bistår erfarne utviklere svært godt. Men når systemer blir store, sammenkoblede, regulerte og driftskritiske, blir begrensningene tydelige.

Hvordan KI utfordrer antakelser om team og arkitektur

Utviklingskapasitet kommer ikke lenger hovedsakelig fra å ansette flere mennesker.

Mindre, svært tekniske team med gode KI-verktøy kan bevege seg langt raskere enn mye større organisasjoner med omfattende prosessbyrde. I noen tilfeller ble selve koordineringen en større flaskehals enn det faktiske utviklingsarbeidet.

Derfor gikk vi over til mindre, produktorienterte utviklingsteam med tydeligere eierskap og mer automatisering rundt leveranser, drift og dokumentasjon.

KI endret også hvordan jeg tenker på ansiennitet. Tidligere skapte tilgang til informasjon og erfaring sterke flaskehalser rundt noen få seniorutviklere eller arkitekter. KI reduserer noe av denne asymmetrien fordi kunnskap, dokumentasjon og teknisk utforskning blir langt mer tilgjengelig i hele organisasjonen.

Arkitektonisk førte dette også til at jeg gikk i retning av enklere og mer modulære systemer. KI fungerer langt bedre når systemer er velstrukturerte, observerbare og tydelig avgrensede. Komplekse, udokumenterte miljøer skaper friksjon både for mennesker og KI-systemer.

Hvorfor mennesker krever mer oppmerksomhet enn verktøy ved innføring av KI

Jeg undervurderte den menneskelige siden ved innføringen.

I begynnelsen fokuserte vi hovedsakelig på verktøy og kapasitet. Vi antok at innføringen ville skje naturlig så snart utviklerne fikk tilgang til kraftige KI-systemer. Teamene reagerte svært forskjellig. Noen utviklere ble umiddelbart dramatisk mer produktive, mens andre knapt endret arbeidsflyten sin.

Hvis jeg kunne gjort deler av utrullingen på nytt, ville jeg brukt mindre tid på å evaluere dusinvis av KI-verktøy og mer tid på å redesigne arbeidsflyter, lære opp team og definere tydelige operative mønstre for hvordan KI skulle brukes i utviklingsarbeidet.

Hvorfor teknologidirektører må se dette som en endring av driftsmodellen

Mitt råd til CTO-er er å behandle AI som et skifte i driftsmodellen, ikke bare som en oppgradering av verktøy.

Mange selskaper tilnærmer seg fortsatt AI slik de gjorde med tidligere programvarebølger – ved å kjøpe plattformer, gjennomføre pilotprosjekter og legge til isolerte bruksområder. Dette overser den større endringen. AI endrer hvordan utviklingsteam arbeider, hvordan produkter bygges, og hvordan organisasjoner skalerer.

For det andre: Vær pragmatisk. Akkurat nå finnes det en enorm hype, og mange selskaper prøver å tvinge AI inn i problemer der teknologien tilfører liten verdi. De beste resultatene kommer vanligvis av å forbedre eksisterende arbeidsflyter først, i stedet for å jage futuristiske ideer.

For det tredje: Invester sterkt i grunnleggende utviklingsprinsipper i stedet for å anta at AI erstatter dem. God arkitektur, en god utviklingskultur, tydelig eierskap, operasjonell disiplin og erfarne medarbeidere er enda viktigere i et AI-drevet miljø.

Og til slutt bør CTO-er bruke disse systemene personlig og direkte – ikke gjennom rapporter eller leverandørdemoer, men ved å arbeide praktisk med dem. Utviklingen går for raskt til at dette temaet bare kan håndteres strategisk uten direkte kjennskap til selve teknologien.

Følg med

Du kan følge arbeidet til Sergey Terentyev på LinkedIn.

Det kommer flere ekspertintervjuer på The CTO Club.