For et par år siden var listene over teknologier som skulle endre apputvikling nesten identiske uansett hvor du leste. AI, stemmestyring, chatboter, blokkjede, 5G, AR og VR. Nå har det gått nok tid til at vi kan se hva som faktisk ble tatt i bruk i vanlige norske prosjekter, og hva som ble liggende igjen i konferanseforedragene.
Det korte svaret er at AI har endret hvordan apper lages, og til en viss grad hva de gjør. Resten av lista gikk hver sin vei, og nettopp det er lærerikt.
AI endret utviklingen før den endret produktene
Den største praktiske forskjellen har skjedd på utviklersiden. Kodeassistenter er nå en normal del av arbeidsflyten, og de gjør en erfaren utvikler merkbart raskere på rutinearbeid. Det som tidligere var en halvtime med å skrive strukturer, testdata og standardoppsett, tar nå noen minutter.
Effekten er reell, men mindre enn overskriftene antyder, og det er verdt å forstå hvorfor. I et appprosjekt er det sjelden selve kodeskrivingen som tar lengst tid. Det er å finne ut hva som skal bygges, teste det med ekte brukere, rette opp det som ikke traff, og gjøre løsningen klar for produksjon. Verktøy som skriver kode fortere hjelper på én del av en lengre kjede.
Der vi ser tydeligst gevinst er på prosjekter med mye standardfunksjonalitet, og på testing. Å få hjelp til å dekke de kjedelige tilfellene med tester er noe verktøyene er gode på, og det er arbeid som ellers ofte blir nedprioritert. Det er også hovedgrunnen til at den enkle enden av markedet er blitt rimeligere, noe vi går gjennom i hva koster det å lage en app.
Hva AI faktisk gjør inne i apper nå
På produktsiden har adopsjonen vært mer selektiv, og det er stort sett en god ting.
Søk og gjenfinning er det som oftest gir tydelig verdi. En app der brukeren kan beskrive det hen leter etter med egne ord, framfor å treffe nøyaktig riktig søkeord, er målbart bedre. Dette er også relativt rimelig å bygge, fordi du bruker eksisterende tjenester framfor å trene noe selv.
Innholdsproduksjon inne i apper, som å foreslå tekst eller oppsummere, er nyttig når brukeren beholder kontrollen og kan redigere. Det blir problematisk når systemet handler på egen hånd uten at noen ser over.
Det som derimot ikke har innfridd, er den dyptgripende personaliseringen som ble lovet. Å tilpasse en app til hver enkelt bruker krever mye data per bruker, og de fleste norske apper har ikke nok trafikk til at det gir mening. For en app med noen tusen brukere er godt gjennomtenkt standardoppsett nesten alltid bedre enn en modell som gjetter.
Chatboter ble bedre, men ikke slik det var tenkt
Den opprinnelige ideen var chatboter med ferdigskrevne svar og knapper. De var stort sett irriterende, fordi de sto mellom brukeren og et menneske uten å kunne hjelpe.
Så kom språkmodellene, og de gjorde noe annet mulig: en assistent som faktisk kan svare på spørsmål ut fra selskapets egen dokumentasjon. Det fungerer, og vi bygger slikt.
Men det fungerer bare med to forutsetninger. Den må vise hvor svaret kommer fra, slik at brukeren kan kontrollere det. Og den må kunne si at den ikke vet, og sende brukeren videre til en person. En assistent som finner på svar når den er usikker, skaper mer arbeid enn den sparer, og koster tillit. Vi har skrevet om hvordan dette bygges i praksis i slik integrerer du kunstig intelligens i en app.
Stemmestyring fant en nisje
Spådommen var at vi snart skulle snakke til apper framfor å trykke. Det skjedde ikke, og grunnen er sosial framfor teknisk.
Talegjenkjenning fungerer godt nå. Problemet er at folk ikke vil snakke til telefonen på bussen, på kontoret eller i en butikk. Stemme fungerer der man er alene eller har hendene opptatt, og det er en mindre del av hverdagen enn entusiastene antok.
Der det har festet seg er derfor i bilen, på kjøkkenet, og i arbeidssituasjoner der folk har hansker eller bærer noe. For en app rettet mot montører eller lagerarbeidere kan stemme være et reelt fortrinn. For de fleste andre er det en funksjon få bruker. Diktering, altså å snakke inn tekst framfor å kommandere, har derimot blitt vanlig, men det løses av operativsystemet og er ikke noe du trenger å bygge.
Det som ble liggende
Blokkjede er det tydeligste eksempelet på en teknologi som lette etter et problem. Bruksområdene som ble skissert, særlig sporbarhet i varekjeder og sikrere betaling, viste seg i praksis å være bedre løst med en vanlig database og en etablert betalingsleverandør. Fordelen ved blokkjede er at den fjerner behovet for å stole på en sentral part. I de fleste forretningssammenhenger finnes det allerede en part alle stoler på, og da betaler man for kompleksitet uten å få noe igjen. Der teknologien brukes i dag, er det som regel fordi selve produktet handler om kryptovaluta.
AR og VR har funnet plass i noen nisjer, som produktvisualisering i møbelhandel og enkelte opplæringsløsninger, men er ikke blitt en vanlig del av appprosjekter. Kostnaden er høy og bruksterskelen hos brukerne er fortsatt reell.
5G endret lite for vanlige apper, av den enkle grunn at de fleste apper ikke var begrenset av nettverkshastighet i utgangspunktet. En app som føles treg, er som regel treg fordi den gjør for mye arbeid eller henter for mye data, ikke fordi mobilnettet er for sakte. Det er fortsatt riktigere å bruke tid på å redusere hva appen laster, enn å regne med at nettet tar seg av det.
Kryssplattformutvikling, derimot, ble akkurat så dominerende som spådd. Det er i dag standardvalget for de aller fleste prosjekter, og vi har skrevet om avveiningen i native, hybrid eller webapp.
Sikkerhet og personvern er det som faktisk har blitt strengere
Den utviklingen som har hatt størst konkret betydning for norske prosjekter, er ikke en teknologi, men regelverk og forventninger.
Begge app-butikkene krever nå at du er tydelig på hvilke data du samler inn, og mangelfulle svar er en vanlig grunn til at apper blir avvist ved innsending. Biometrisk innlogging er blitt normalen framfor et tilvalg. Og med AI-funksjoner følger et nytt spørsmål som må besvares før lansering: hvor blir det av dataene brukeren skriver inn, og brukes de til å trene noe?
Dette er ikke et teknisk detaljspørsmål. Skal du bruke en ekstern AI-tjeneste i en app som behandler personopplysninger, må du vite hvor behandlingen skjer og ha avtalene på plass. Det er raskt å ordne når du tenker på det i planleggingen, og tungt å rydde opp i etterpå.
Hva vi kan lære av dette
Mønsteret er det samme i nesten alle tilfellene, og det er verdt å ha med seg neste gang noe nytt dukker opp.
Teknologien fungerte teknisk i alle sammen. Det som avgjorde var om den løste et problem folk faktisk hadde, i en situasjon der de faktisk befant seg. Stemmestyring feilet på situasjonen. Chatboter feilet først på kvalitet og lyktes da kvaliteten kom. Blokkjede feilet på at problemet ikke fantes.
Det praktiske rådet er derfor enkelt: ikke bygg en app rundt en teknologi. Bygg den rundt en oppgave noen skal få gjort, og velg så det som løser oppgaven best i dag. Hvis AI gjør søket i appen din merkbart bedre, bruk det. Hvis det bare er noe å skrive i pressemeldingen, la det ligge til det finnes en grunn. Brukerne dine bryr seg ikke om hva som kjører under panseret, bare om at det de kom for å gjøre går raskt.
Vurderer du AI-funksjonalitet, kan du se hva slike funksjoner koster i priskalkulatoren. Vil du diskutere om det gir mening for deres løsning? Se hvordan vi jobber med apputvikling, eller ta kontakt, så er vi ærlige om når svaret er nei.