94 prosent bruker KI i utvikling – bare 6 prosent kan styre skaleringen

|Forfatter: QUASAs redaksjon|5 min lesetid
94 prosent bruker KI i utvikling – bare 6 prosent kan styre skaleringen

I Atlassians kunngjøring fra Team ’26 Europe i Amsterdam 7. oktober 2026 oppgir selskapet at 94 prosent av de spurte teknologilederne sier teamene deres bruker KI, mens bare 6 prosent sier de har systemer for å skalere og styre bruken. Samtidig presenterte Atlassian funksjoner som skal knytte sammen planlegging, kodearbeid, gjennomgang og drift. Prosentene beskriver svar i selskapets undersøkelse, ikke en måling av hvor godt alle utviklingsteam faktisk styrer KI.

En KI-native utviklingsprosess betyr i Atlassians lansering at agenter får oppgavens bakgrunn, utfører avgrenset arbeid og etterlater informasjon som mennesker kan bruke når de vurderer resultatet. I TechRadars dekning fra Amsterdam sa Atlassians toppsjef Mike Cannon-Brookes: «Models are the engine, but context is the fuel». Funksjonene har ulik tilgangsstatus: Noen er generelt tilgjengelige, mens andre fortsatt er i beta eller begrenset tidlig tilgang.

Kodeagenten trenger mer enn en oppgavetekst

Jira, Confluence og Code Context knytter en utviklingsoppgave til beslutninger og relevant kode.

Teamwork Graph er kontekstlaget Atlassian vil bygge utviklingsarbeidet rundt. Det knytter kode til dokumentasjon, beslutninger og tekniske standarder innenfor tilgangsrettighetene som gjelder for innholdet. En agent som får en Jira-oppgave, kan dermed få mer av bakgrunnen for endringen enn det som står i selve oppgavebeskrivelsen. Det er særlig relevant når tidligere arkitekturvalg eller arbeid i andre deler av kodebasen begrenser løsningen.

Code Context utvider laget til tilkoblede Bitbucket- og GitHub-repositorier. Funksjonen kartlegger blant annet filer, klasser, funksjoner og forholdet mellom dem, og kobler koden til arbeid i Jira, innhold i Confluence og opptak i Loom. Ved presentasjonen var Code Context under gradvis utrulling i åpen beta for betalende Atlassian-kunder. Den statusen gir ikke grunnlag for å omtale funksjonen som tilgjengelig for alle utviklingsteam.

Sammenhengene skal også gjøre det lettere å bevare begrunnelsen for en endring når arbeidet flyttes mellom mennesker og agenter. For en teknologileder er styringsspørsmålet derfor større enn om en agent kan skrive kode: Det omfatter hvilken informasjon agenten fikk tilgang til, hvilket arbeid den ble satt til, og om denne sammenhengen følger endringen videre.

Fra godkjent plan til kodeagent

Planner er ment å gjøre en grov idé om til en spesifikasjon før utviklingen starter. Funksjonen skal hente inn relevant kontekst, be om avklaringer og samle mål, avgrensninger, risiko, eiere og åpne beslutninger i en Confluence-plan. Når mennesker har godkjent planen, kan den brytes ned i Jira-oppgaver med akseptansekriterier, avhengigheter og koblinger til relevant kode. Planner var i privat tidlig tilgang ved kunngjøringen.

I designfasen var Record for Agent tilgjengelig i åpen beta. Her kan en Loom-gjennomgang av en prototype eller en visuell feil gjøres om til en strukturert instruksjon for en agent. Opptaket skal bevare detaljer som klikk og skjermendringer, slik at en foreslått kodeendring kan knyttes til det designeren faktisk viste og forklarte.

På kodesiden kunne Jira-oppgaver tildeles agenter fra Devin, Factory og Warp via integrasjoner i Atlassian Marketplace. Agenten kan bruke oppgavens sammendrag og beskrivelse, rapportere fremdrift på saken og åpne en pull request for gjennomgang. Støtte for OpenAI Codex var varslet som kommende, og innsamling av lokale agentsesjoner fra utviklingsverktøy til Jira var heller ikke ferdig lansert. Disse statusene er viktige for team som vil følge agentarbeidet i ett felles saksforløp.

Gjennomgang og drift krever synlige beslutninger

En agentassistert endring går fra Jira til en Bitbucket-pull request og venter på menneskelig godkjenning.

En agent kan gjøre en første kodegjennomgang mot felles tekniske standarder, men beslutningen om å godkjenne endringen ligger hos mennesker. AI Review og agentløkker var i privat tidlig tilgang. Interaktive Loom-gjennomganger av pull requests i Bitbucket var i lukket tidlig tilgang; de er tenkt å vise hva agenten endret, hvorfor den gjorde det, og hvilke risikoer en menneskelig gjennomgår bør se nærmere på.

Etter utrulling oppstår et tilsvarende behov i driften. Agent Sessions skal knytte lokale og skybaserte agentsesjoner til riktig Jira-sak og bevare mål, endringer, beslutninger og samtalen som styrte arbeidet. Funksjonen var i lukket tidlig tilgang. Dermed må team som ikke har slik sesjonssporing, bygge oversikten fra oppgaver, pull requests, godkjenninger og driftslogger de allerede har.

En sammenhengende kontrollkjede har et dokumentert behov og akseptansekriterier før koding, en kobling fra agentens arbeid til den foreslåtte endringen, og en navngitt menneskelig godkjenning før produksjon. Den må også vise om endringen senere krevde feilretting eller tilbakerulling. Dette er kontrollpunktene som gjør det mulig å skille raskere produksjon av kode fra en prosess som faktisk er lettere å styre.

Målingene sier ulike ting om effekten

DX AI Measurement var generelt tilgjengelig ved kunngjøringen. Løsningen skal koble bruk av KI-verktøy til leveranser, kvalitet og friksjon i utviklingsarbeidet, og gi innsyn i agentsesjoner. Brukstall kan vise hvor utbredt verktøyene er, men sier alene lite om gjennomløpstid, feil etter utrulling eller arbeid som må gjøres om. Slike utfall må registreres over sammenlignbare perioder dersom effekten skal vurderes.

I Atlassians omtale av interne tester oppgis 44 prosent bedre svarkvalitet og 48 prosent lavere tokenbruk for agenter som brukte Teamwork Graph som kontekst. Dette er leverandørmålte resultater for den testede kombinasjonen av agent og kontekstlag, ikke uavhengig dokumentert effekt av hele utviklingsprosessen hos kunder. Undersøkelsens svar om KI-bruk og styringssystemer er på sin side selvrapporterte, ikke produktivitetsmålinger.

Lanseringen gjør flere deler av agentarbeidet synlige i Jira, men flere av kontrollpunktene i gjennomgang og drift har fortsatt begrenset tilgang. For team som skal vurdere skalering, blir det avgjørende om de kan følge en endring helt frem til godkjenning og drift – og se tiden brukt på rettinger i det samme resultatbildet.

Les også:

Del:

Abonner på nyhetsbrevet vårt

Få de siste nyhetene om Web3, KI og krypto rett i innboksen.

0