«FermAI-paradokset»: Hvor blir det av alle appene?
Hele verden vibbekoder, men vi ser ingen eksplosjon av nye tjenester. Grunnene er mange, tror Kent Inge Fagerland Simonsen og Peter N. M. Hansteen, og mener løsningen heter Solid.
Publisert
GenAI og Agentisk AI har gjort seg bemerket innen AI. Nylig publiserte kode24.no resultatene fra en studie som viser at brorparten av Norges utviklere bruker AI-verktøy i sine daglige virker.
AI-utviklere, eller utviklere med AI-verktøy, gjør det mulig å bygge langt mer programvare langt fortere og langt billigere. Så effektive er disse verktøyene at selv lekfolk, mennesker uten videre bakgrunn eller erfaring innen programvareutvikling, nå kan bruke denne typen verktøy for å lage det de måtte ønske av programvare.
Vi har altså dramatisk redusert kostnaden, samtidig som vi har dramatisk utvidet tilgjengeligheten av programvareutviklere. Dette burde, isolert sett, føre til en eksplosjon i ny programvare samtidig som kvaliteten på den programvaren vi allerede bruker burde vært dramatisk forbedret.
Det at vi ikke ser en slik eksplosjon i applikasjoner kan vi kalle et slags Fermi-paradoks.
Akkurat som Fermi lurte på hvor det blir av alle romvesenene, gitt mengden solsystem og planeter i universet, kan vi likeens lure på:
Hvor det blir av alle appene?
Teori #1: Koden var ikke problemet
Vi kan tenke oss flere plausible forklaringer for hvor det blir av appene.
En mulig forklaring er at kode-generering ikke løser opp flaskehalsen i programvareutvikling. Altså at det var aldri kodingen som holdt oss tilbake. Det medfører riktighet at det ofte ikke er i programmering flaskehalsen sitter i enterprise-sammenhenger, men heller i et av de andre leddene som er nødvendige for enterprise-programvare til å skapes på riktig måte.
Denne forklaringen svikter likevel på følgende punkter: Gitt demokratiseringen av utvikling, så burde det likevel bli laget betydelige mengder programvare med mer lettvekt-metoder, det vil si app-er av alle lekfolkene som nå kan lage systemer.
Videre bruker vi også AI i disse andre nødvendige funksjonene som kvalitetssikring, plattformdesign, kravspesifikasjon, og så videre. Så vi burde sett samme produktiviteteksplosjon i disse leddene også.
Teori #2: Ting tar tid
Det er velkjent at teknologiske nyvinninger ikke oppnår full effekt før reglene som skulle kompensere for den beskrankninger nyvinningen løser er endret for å tilpasse seg nyvinningen.
Dette kan være en del av forklaringen på hvorfor vi ikke ser en eksplosjon i mengden nye og spennende apper.
Men, dette gjelder kun etablerte miljøer med eksisterende regler. Vi skulle fremdeles forventet å se en eksplosjon av nye apper fra amatører og oppstartbedrifter.
Teori #3: Vi bare får det ikke med oss
Det kan også være at app-eksplosjonen er i full gang, men at forfatteren rett og slett ikke har fått det med seg. Det lanseres tross alt apper og vevsteder hver eneste dag.
Men om man ser på tallene så ser det mer ut som jevn (om høy) vekst:
Apples App Store hadde for eksempel 10.8% mer apper i 2025 enn i 2024. Men vi ser også at antallet apper i App Store vokste enda mer fra 2023 til 2024, så ingen eksplosiv akselerasjon kan i grunn sees fra de datapunktene.
I Google Play-butikken for Android Apper ser vi også vekst, fra et bunnpunkt i tidlig 2025, men veksten virker jevn, og Google Play har stadig langt færre apper enn før Google innførte kvalitetskrav i 2024.
Når det kommer til vevsider, så er der tegn til dramatisk og tiltagende vekst i antall. Likevel er antall aktive vevsider bemerkelsesverdig jevnt.
Det er nok tenkelig at noe av den forventede effekten av disse teknologiene er noe overdrevet.
Teori #4: Effekten er overdrevet
En nærliggende forklaring kan også være at antagelsene om at AI (eller KI) gir en slik fantastisk forbedring i ytelse, eller i demokratisering av, utvikling rett og slett ikke stemmer.
Og det er nok tenkelig at noe av den forventede effekten av disse teknologiene er noe overdrevet. Men: erfaring viser at disse verktøyene har en effekt.
Så dette kan trolig heller ikke fullt ut forklare den manglende eksplosjonen, særlig når det kommer til enkle applikasjoner med under middels strenge kvalitetskrav, hvor språkmodeller virkelig briljerer.
Teori #5: Portvokterne
Om vi skulle spekulert, så kan det tenkes at del av forklaringen kan være at det finnes en eller annen form for portvoktere.
For mobil-applikasjoner er en slike portvoktere åpenbart App Store og Play, som gjør prosessen med å gjøre produktet tilgjengelig noe mer kompleks, og medfører kostnader for utvikleren.
For applikasjoner som i tillegg skal lagre data sentralt, så trenger man backend og database, og plutselig har man behov for overvåkning og brannmurer og greier.
Alt i alt kan det fort bli mye.
Teori #6: Kompleksiteten
En annen, men kanskje relatert, forklaring kan være at LLM-kode tenderer til å være veldig "korrekt" i forhold til visse "beste praksis"-er. Dette betyr at koden vil tendere til å være full av gode abstraksjoner og bruke moderne verktøy, god test-dekning og gode greier.
Selv om alt dette isolert sett er gode ting, legger hvert gode valg til mer kode, og mer kode betyr mer feil, eller muligheten for at noe feiler.
Siden utvikling av applikasjoner, selv for modeller, blir vanskeligere etterhvert som programvaren vokser, så kan det tenkes at mange møter en slags vegg her før programvaren er helt klar for slipp.
Dette kan også tenkes å kombinere med en effekt av vibbekoding som gjør at vibbekoderen kontinuerlig vil lage bare en til egenskap.
Teori #7: Jussen
Til slutt er det ikke lenger helt risikofritt å slippe programvare.
Fersk lovgiving som CRA og NIS2 stiller krav til programvare og digitale produkter om rapportering og sikkerhet.
Nå er det usikkert hvor mange lekfolk, eller til og med profesjonelle utviklere, kjenner til disse lovgivningene. Likevel så kan dette ha en noe nedkjølende effekt etterhvert som applikasjoner nærmer seg slipp.
Løsningen: Solid
Til slutt kan det tenkes at arkitekturene som språkmodellene skaper ikke nødvendigvis til tilpasset en vibbekodet verden. Om det stemmer så kan denne føre til at applikasjoner blir startet, men stopper opp enten fordi utviklingen stopper opp eller fordi produksjonsetting blir vanskelig.
Dersom vi ønsker å fasilitere en demokratisering og eksplosjon av programvare kan vi tenke oss at en enklere arkitektur vil kunne redusere noen av de overnevnte, potensielle, hindre:
Standarden Solid, som er utformet av W3C og ODI, kan være en del av en slik arkitektur.
Solid har som designmål å gjøre web bedre ved å gi brukere tilbake kontrollen over egne data. Solid gjør dette ved å la brukere lage en identitet ved hjelp av WebID og en "pod" hos egen-algt leverandør. Brukerens applikasjoner vil da, med brukerens tillatelse, lese og skrive data til pod-en. Slik havner ikke brukerens data i applikasjonsutviklerens systemer og brukeren kan velge hvilke applikasjoner den vil bruke til å håndtere hvilke data og når.
Sett fra applikasjonsutvikleres synspunkt gjør dette at applikasjonsutvikling og, viktigst for vårt argument her, drift blir dramatisk forenklet. I mange tilfeller fjerner denne arkitekturen behovet for å prosessere brukerdata annet enn i brukergrensesnittet, som kjører på brukerens egen vevleser eller dings.
Dette reduserer applikasjon-utviklerens risiko fordi de ikke lenger har noen database full av brukerdata som kan lekke. Dette forenkler også den nødvendige infrastrukturen, og særlig for applikasjoner som ikke lenger trenger noen tjener side prosessering fordi all data er brukerdata som havner i brukernes pod. For web-applikasjoner betyr dette av de kan være helt statiske med ingen annen backend nødvendig enn en webserver og et filsystem.
Få Solid til vibbekoderne
Hvordan kan vi få vibbekodere til å bruke denne arkitekturen?
For det første kan profesjonelle utviklere, og generelt den type mennesker som leser kode24, gå foran med et godt eksempel og lage applikasjoner som lar brukere kontrollere egne data, gjerne med Solid eller noe lignende.
Videre trenger vi lokal infrastruktur for dette. Det betyr at vi trenger en, eller helst flere, Solid Pod-leverandører.
Vi kan også tenke oss en fremtid det offentlige etater også gir innbyggere tilbake kontrollen over relevante data som omhandler dem via en offentlig kontrollert Solid Pod-leverandør, eventuelt med mulighet for å velge andre leverandører, for dem som vil.
Med både infrastruktur og eksemplariske rollemodeller på plass vil det siste problemet være å enten utdanne utviklere til å benytte disse teknologiene, eller å utdanne modellene til å anbefale personvern vennlige løsninger som førstevalg.
Et steg i den retningen kan være via leserinnlegg i kode24, hvor vi går herfra er opp til leseren.
Foretrekk oss i Google Discover
Ved å legge oss til som foretrukket kilde i Google vil du blant annet få opp flere av sakene våre i Google Discover. Tusen takk for støtten!
