Flyt i AI-ens tid: når det blir lettere å lage, men vanskeligere å bevege seg

Christian Neverdal (Telenor) · JavaZone 2026, Room 7 Programsiden på JavaZone

Dette foredraget praktiserer det det forkynner: Christian har bygget en Discord-basert AI-agent ("Kerrigan") som genererer nye slides live gjennom hele talken, på forespørsel eller ut fra det som skjer i salen. Formatet i seg selv er poenget - hele foredraget handler om flyt: ikke bare individuell utvikler-flyt, men flyt for teamet, produktet og hele organisasjonen, og hvorfor AI som kun akselererer ett enkelt steg i en verdikjede (koding) ofte bare flytter køen et annet sted.

Vibecoding som eksperiment, ikke bare lek

Christian har vibecodet en rekke små apper på fritiden - en oversetter-app ("Ambient Translator"), en app som gjenkjenner source-knappen på en fjernkontroll fra et bilde, en universalfjernkontroll-hjelper, og flere til.

Ambient Translator: velg språk eller la appen oppdage det automatisk ▶ Se dette i opptaket

Poenget er ikke antallet apper, men hva som er blitt mulig: avstanden fra idé til brukt produkt har kollapset. Der en normal designprosess ville droppet et rart edge-case ("hva om du skal trykke med nesa?"), kan man nå bare spørre AI-en og få et forsøk på svar med det samme.

Fra idé til faktisk produkt: fem vibecodede apper, og poenget er ikke antallet ▶ Se dette i opptaket

Et konkret eksempel: i stedet for å lage wireframes eller Figma-skisser til brukertesting, sendte han ut fire fullstendig fungerende oversetter-app-varianter til ekte testere, med ulik kompleksitet og ulike avveininger. Folk vil ha forskjellige ting - "kanskje folk vil ha fire forskjellige typer spagettisaus" - og med AI koster det ham nesten ingenting å la dem faktisk prøve alle fire i stedet for å gjette seg frem til én.

Flyt handler om hele verdikjeden, ikke ett steg

Kjernepåstanden: det er lett å optimalisere individuelle steg i en prosess med AI - Figma har sin AI, Jira har kanskje sin, Slack, IDE-en, GitHub - men ingen tar tak i integrasjonspunktene mellom dem, fordi det er det vanskelige. Og det er akkurat disse punktene som avgjør om noe faktisk flyter.

En kø oppstår overalt hvor noe brukes 100 %: motorveien, trappa opp til andre etasje, studielånet, CPU-en, GPU-en - eller en AI-agent som kjøres på makset kapasitet. En del av det AI har lovet er frigjort tid, men hvis den frigjorte tiden bare fylles opp igjen til 100 % (game jockeying, "token-maxing"), er man tilbake der man startet. Konklusjonen er ikke ny, men blir viktigere: hold gjerne utnyttelsen rundt 80 %, med litt slakk - akkurat som 20 %-ordninger på jobb egentlig er innebygd slakk i forkledning.

flowchart LR
    A[Design<br/>egen AI] -. ingen som eier<br/>integrasjonen .-> B[Kode<br/>egen AI]
    B -. ingen som eier<br/>integrasjonen .-> C[Review<br/>egen AI]
    C -. ingen som eier<br/>integrasjonen .-> D[Release<br/>egen AI]
    D -. ingen som eier<br/>integrasjonen .-> E[Drift<br/>egen AI]
    style A fill:#2563eb,color:#fff
    style B fill:#2563eb,color:#fff
    style C fill:#2563eb,color:#fff
    style D fill:#2563eb,color:#fff
    style E fill:#2563eb,color:#fff

Hvert steg blir raskere hver for seg, men de stiplede overgangene - der ingen har ansvar for helheten - er der flyten faktisk går tapt.

Ti ganger output betyr ti ganger kø et annet sted i systemet - typisk hos den som skal reviewe. "Shift left on AI" betyr å tenke på hele arbeidsflyten fra intensjon til produksjon, ikke bare på hvor fort agenten skriver kode.

Å game metrikker er faktisk helt greit

Et bevisst kontroversielt poeng: hvis noen gamer en metrikk (for eksempel antall pull requests), er den beste responsen ikke å bli sint, men å innse at metrikken ikke fanget det du egentlig ville måle. Løsningen er enten å måle noe som er vanskeligere å game - som brukertilfredshet - eller å måle hele livssyklus-kostnaden i stedet for ett steg i midten.

Å game er greit! ▶ Se dette i opptaket

Hvis ledelsen ønsker å måle noe som "100 deploys om dagen", kan man svare med et motspørsmål: skal vi også spørre folk hvor smertefullt de synes det er å deploye, og hvor mange av de deployene som faktisk har en hensikt? Ofte er svaret nok til at alle skjønner at metrikken bare var en proxy for en intensjon - ikke intensjonen selv.

Menneskelig venting er ikke bortkastet tid

Et gjennomgangstema er at "sitte og gjøre ingenting mens agenten jobber" i seg selv er unaturlig for mennesker. Løsningen trenger ikke være mer produktivitetspress - å spille et raskt spill med en kollega mens agenten jobber er ofte bedre enn å presse den til å gjøre enda et sett med endringer mens du er sliten selv. Ventetiden er dessuten sjelden helt passiv: folk svarer på spørsmål, hjelper andre med avklaringer - de gjør noe nyttig som ellers ville skapt kø.

Konkrete grep i praksis

Behandle agent-instruksjoner som prompt for samarbeid, ikke bare for koding. Legg for eksempel inn i agentfilen at den skal sjekke antall åpne, gamle pull requests via GitHub sitt API før den begynner på noe nytt
er inventory full, har du ikke fått mest mulig ut av AI-en enda.
Bruk sunn fornuft fremfor harde grenser. En regel som "denne filen skal være maks 8000 linjer" blir gamet til 7999 - be heller agenten om ikke å sette nye rekorder (i byggetid, fillengde, kompleksitet), og la den bruke skjønn.
Vær forsiktig med å pakke alt inn i skript som kjøres fra kaldstart hver gang. Et skript som bygger og kjører alle tester på nytt for hver minste endring er tryggere, men også tregere - noen ganger er det greit at agenten, som et menneske, gjør litt for lite og heller retter opp etterpå.
"Make it so." Som kaptein Picard i Star Trek delegerte han ikke bare oppgaven, men handlingsrommet til å løse den. Det samme gjelder agenter: skal de faktisk kunne jobbe selvstendig, må de ha fullmakt til å handle innenfor tydelige rammer - ikke spørre om tillatelse for hvert steg.
Null overlevering er målet. Et cloud-designverktøy krevde eksport av en zip-fil og manuell utpakking for hver ny iterasjon - to klikk med friksjon var nok til å ødelegge flyten helt. Sammenlign med å FTP-synke en fil rett til en live server: alt som ikke er sømløst, skaper venting og frustrasjon, og batchene vokser for å kompensere.
Stå ikke i veien for andre. Spør først om en "harmløs" endring (f.eks. en avhengighetsoppdatering) kan blokkere noen, før du gjør den - en overraskende full disk på en delt byggeserver er en dyr måte å lære det på.

Feature flags som teknisk gjeld

Feature flags er en gjenganger i mange organisasjoner - men hvert flagg betyr reelt sett to versjoner av systemet, to flagg betyr fire. Christian foreslår å behandle dem eksplisitt som gjeld: gjeld er nyttig så lenge du betaler den ned, med en tydelig eier, utløpsdato og plan for sletting.

Feature flags er teknisk gjeld - gjeld er nyttig hvis du betaler den ned ▶ Se dette i opptaket

Håpet er at bedre AI-drevet selvtillit i utrulling etter hvert gjør mange flagg overflødige - men inntil videre er eksplisitt gjeldshåndtering bedre enn stilltiende opphopning.

Mikrotjenester, batch-størrelse og tautologiske tester

Mikrotjeneste-arkitektur flytter kompleksitet ut av boksene og inn i pilene (nettverkskallene) mellom dem - og ingen tester pilene ordentlig før de er fulle i produksjon. Her er agenter (kombinert med OpenTelemetry-basert sporing) overraskende gode til å feilsøke og selvkorrigere raskere enn et menneske ville gjort.

Uber sin gamle tommelfingerregel er verdt å låne: hvis en god utvikler trenger mer enn to dager på å reimplementere en tjeneste fra spesifikasjonen alene, er den for stor og bør deles opp. Med en agent som referanse gir det samme heuristikken enda mer kraft - trenger agenten mer enn to dager på en tjeneste, er dere sannsynligvis ute og sykler.

En kjent svakhet er at AI-genererte tester ofte blir tautologiske - de bekrefter bare at en mock ble kalt, ikke at koden faktisk gjør noe riktig. Mutasjonstesting (som bytter om true/false, </> og lignende i koden og sjekker at testene faktisk feiler) er en underbrukt, ikke-AI-basert teknikk for å avsløre nettopp dette - og noe man fint kan be en agent gjøre selv som en sjekk på sine egne tester.

Kaos-agenten og live-genererte slides

Kodebasen bak talken (inkludert Kerrigan-agenten) vokste til over 8000 linjer og 70 markdown-filer. I stedet for å reorganisere manuelt, fikk en egen agent ved navn "Zero Chaos" som eneste oppdrag å redusere kaos i arbeidsflyten - konsolidere filer, rydde struktur, ingenting annet.

Selve slidedekket ble bygget opp live, tips for tips, gjennom hele talken - et konkret bevis på at avstanden fra idé ("lag en slide om X") til brukt resultat kan kollapse helt ned til sekunder når integrasjonen er god nok.

Alle de live-genererte tipsene samlet, seksjon for seksjon ▶ Se dette i opptaket

Nøkkeltakeaways

Flyt er en egenskap ved hele verdikjeden, ikke et enkeltstående steg - optimaliser integrasjonspunktene, ikke bare de individuelle verktøyene.
100 % utnyttelse skaper kø, uansett om det er en motorvei, en agent eller en person - planlegg med slakk.
Ikke bli sint på at folk gamer en metrikk - bytt til en metrikk som er vanskeligere å game, eller mål hele livssyklusen.
Deleger handlingsrom til agenter ("make it so"), ikke bare enkeltoppgaver
men gi dem samtidig fullmakt til å bruke skjønn fremfor rigide skript og harde grenser.
Null overlevering (ingen zip-filer, ingen manuelle eksportsteg) er idealet - all friksjon i integrasjonen skaper venting og større batcher.
Behandle feature flags som eksplisitt teknisk gjeld: eier, utløpsdato, sletteplan.