Flere av oss tok noen ekstra dager da vi først var på tur, og vi fikk med oss stand-up, musicals, fotballkamper og mye god mat og drikke. Men siden dette er en fagblogg, deler noen av oss litt av de faglige inntrykkene vi sitter igjen med etter konferansen:

Richard: Kodeagenter

Dette var min andre gang på QCon London og femte gang på en QCon-konferanse. Konferansen holdt gjennomgående høy kvalitet, og innholdet var svært relevant.

Det kom fram mange interessante perspektiver og observasjoner. Ett poeng som særlig utmerket seg, kom fra Netlify i frontend-sporet: Dagens utviklerverktøy må utvikles for å støtte agenter og fleksible rammeverk, slik at agenter kan arbeide effektivt. Samtidig ble det pekt på at utviklerrollen blir mer strategisk og arkitektonisk, med større ansvar for å bygge robuste plattformer og veilede neste generasjon utviklere.

Et annet foredrag som ga viktige perspektiver, var fra Yinka Omole fra Personio. Han argumenterte for å prioritere grunnleggende ingeniørutfordringer fremfor teknologihype. Hovedbudskapet var at varig verdi skapes gjennom dyp ekspertise, bevisste teknologivalg og fokus på løsninger som tåler endring over tid. Det ble også understreket at god forståelse av domenet man jobber i blir stadig viktigere.

Dette var et tema som gikk igjen i flere foredrag. Når kodeagenter skriver stadig mer av koden, blir det viktigere å ha tydelig forståelse av hva som skal bygges. Samtidig ble det fremhevet at når kostnaden ved å produsere kode blir lavere, åpner det for å eksperimentere med flere løsninger, teste alternative versjoner og i større grad tilby brukertilpassede grensesnitt.

Et annet perspektiv som ble diskutert, var hvordan dette også kan påvirke teamorganisering. Flere mente at utviklingsteam kan bli mindre enn i dag, fordi økt produktivitet fra kodeagenter reduserer behovet for like mange utviklere per produkteier. Ett eksempel som ble nevnt, var team med om lag to utviklere per produkteier, mot større team slik man ofte ser i dag. Dette ble knyttet til en mulig forskyvning der mer kapasitet flyttes fra ren implementering til prioritering, produktutvikling og styring.

Flere tok også opp behovet for en AI-plattform for effektiv bruk av kodeagenter, gjerne organisert som en pipeline med flere steg:

• Et system for å generere og forbedre prompts, inkludert bruk av domenespesifikk kontekst for å hjelpe modellen å levere bedre resultater.
• Kjøring av AI-modeller i sandkasser med begrensede rettigheter til nettverk, internett og filsystem, der modellen kun gis tilgang til det som er nødvendig for oppgaven.
• Et evalueringslag som vurderer det AI-modellen produserer, for eksempel gjennom tester som verifiserer at generert kode oppfyller tekniske krav. Dette ble også trukket fram som viktig for å gjøre det enklere å bytte AI-modeller (uten å måtte manuelt teste).
• Omfattende automatiske tester, gjerne flere enn tidligere, som følge av behovet for høyere grad av kvalitetssikring når AI-generert kode tas i bruk.

Noen tok til orde for at en slik AI-plattform bør forvaltes av et eget team, med ansvar både for plattformutvikling og AI-sikkerhet.

Det var flere foredrag som understreket et skifte fra fokus på ren kodeproduksjon til større vekt på problemløsning, domeneinnsikt, plattformtenkning, organisering og styring av AI-baserte utviklingsprosesser.

Jon-Håkon: Fra hype til håndverk

Dette var mitt første møte med QCon, og jeg må si meg imponert over faglig innhold og nivå på konferansen generelt. Ikke overraskende var det mye fokus på AI, selv om veteranene i gruppen kunne melde om at det var enda mer overvekt av dette i fjor. Det interessante med mye av fokuset i år var kanskje at man nå har kjent AI-kodingen på kroppen lenge nok til at mange har gjort seg mer reflekterte meninger om hvordan det påvirker faget vårt: Det var ikke kun hype om hva det neste store innen AI blir.

Et av temaene som gikk igjen var hvordan det påvirker rekruttering og opplæring av neste generasjons utviklere. Færre rekrutterer juniorutviklere og “ingen” tar seg bryet med den kjedelige feilsøkingen som bygger erfaringen man trenger for å kunne innse at det agenten har kodet er en dårlig løsning.

Et annet poeng var hvordan vi egentlig ikke vet hvordan agentisk koding påvirker effektiviteten til utviklere - Det meste baserer seg på selvrapportert “opplevd effektivitetsøkning”. De få skikkelige studiene som eksisterer er allerede utdaterte, og man sliter nå med å rekruttere kontrollgrupper til nye studier, ettersom ingen utviklere har lyst til å kode uten AI-støtte.

Det var også mye fokus på hvordan vi har gått fra “prompt engineering” til “context design”. Man ser at forbedringer i ytelsen til LLM-modeller for koding har begynt å flate ut, og det viktigste er ikke hvordan man stiller det perfekte spørsmålet, men hvordan man tilgjengeliggjør kontekst. Derfor er det også viktig å gi kontekst den samme livssyklushåndteringen som kode: Versjonskontroll, peer-review og CI/CD.

Jan-Helge: Site Reliability Engineering med AI

20-åringen holder koken. På QCon var det spesielt interessant å høre om Netflix sin tilnærming til Site Reliability Engineering ved bruk av ontologier og GenAI. SkyNet neste!

Krister: AI overalt, men ikke uten skepsis

Jeg tror de fleste IT-konferanser har hovedvekt av AI-foredrag i disse dager, og QCon London var ikke noe unntak. Det var mye AI-positivisme, men heldigvis også litt skepsis. Blant de positive var det flere budskap. Et budskap var at kode er nå «write only». Et annet var at AI lager så mye kode at code review er blitt den store flaskehalsen. Løsningen på dette? Kutte code reviews. Noen mente man kunne la AI gjøre code reviews, andre mente at man måtte code reviewe AI-instruksene i forkant.  Andre igjen mente at det ville være testene som dokumenterte systemet, så det er disse som må reviewes og sikres god kvalitet. Jeg ble ikke helt overbevist, men absolutt nyttig å høre andres refleksjoner om temaet.

På den skeptiske siden ble det påpekt at de fleste studier som viser positive effekter av AI-støttet utvikling stort sett kommer fra leverandørene selv, eller uansett bare støtter seg på «opplevd effekt». Men «den eneste» kontrollerte studien på området er METR-studien fra juni 2025 som viste at selv om utviklerne tror de jobber raskere med AI, er de i praksis tregere. Dette ble omtalt i kode24. Nå er juni 25 en evighet siden med tanke på AI-assistert utvikling. Dessverre er det vanskelig å gjøre en oppfølgingsstudie fordi forskningsorganisasjonene sliter med å finne en kontrollgruppe av utviklere som jobber uten AI.