Kunder spør stadig oftere om vi bruker KI i utviklingen, og hva det betyr for dem. Det er et rimelig spørsmål, og svaret bør være konkret framfor prinsipielt. Her er hvordan vi faktisk jobber.
Hvis du heller er ute etter hvordan bransjen som helhet har endret seg, har vi skrevet om det i KI og webutvikling.
Hvor vi bruker det
Kodeassistenter er en del av det daglige arbeidet. De er nyttigst på det forutsigbare: å sette opp strukturer, skrive tester for de kjedelige tilfellene, lage testdata, og skrive kode som ligner på noe som er skrevet mange ganger før.
Testing er der vi ser mest igjen for det. God testdekning er noe alle er enige om at man bør ha, og som i praksis ofte nedprioriteres fordi det er kjedelig arbeid. Når terskelen blir lavere, blir det faktisk gjort, og det merkes på hvor mange feil som når fram til dere.
Vi bruker det også til å komme raskt inn i ukjent kode. Overtar vi en løsning noen andre har bygget, er det nyttig å få et hurtig overblikk over hvordan delene henger sammen, før vi går grundig gjennom det som betyr noe.
Og til rutinearbeid rundt selve utviklingen: å konvertere data mellom formater, rydde i oppsett, og skrive den typen dokumentasjon som ellers blir liggende.
Hvor vi ikke bruker det
Vi lar ikke verktøy ta arkitekturvalg. Beslutninger om hvordan en løsning skal struktureres har konsekvenser som først viser seg om to år, og de krever at noen forstår hva dere skal bruke systemet til.
Vi bruker det ikke til å finne ut hva som skal bygges. Det arbeidet handler om å snakke med folk, forstå hvordan de faktisk jobber, og ta stilling til hva som kan vente. Ingen verktøy gjør det for oss.
Og vi limer ikke kundedata inn i eksterne tjenester. Det er en absolutt regel. Skal noe testes med realistiske data, bruker vi data vi har laget for formålet.
Regelen vi har satt for oss selv
Ingen kode går inn i et kundeprosjekt uten at en utvikler har lest den, forstått hva den gjør, og kan forklare hvorfor den er der.
Dette er ikke en formalitet. Kode som produseres raskt og ingen egentlig har tenkt gjennom, fungerer gjerne akkurat nå og blir dyr senere, når noen skal endre den og ikke vet hvorfor den er som den er. Tidsbesparelsen er bare ekte hvis noen går god for resultatet.
I praksis betyr det at KI hos oss er et verktøy som gjør en erfaren utvikler raskere, ikke noe som erstatter vurderingen.
Hva dere faktisk merker
Vær skeptisk til leverandører som lover dramatisk lavere priser fordi de bruker KI. Koding er ikke den største posten i et appprosjekt, så raskere koding gir ikke halvert pris.
Det dere merker er mer beskjedent og mer reelt. Rutinearbeid går fortere, så mer av tida går til det som faktisk er spesielt for deres løsning. Testdekningen er bedre enn den var for noen år siden. Og små endringer etter lansering kan gjøres raskere, noe som betyr at terskelen for å justere ut fra brukertilbakemeldinger er lavere.
Det dere ikke merker er at et halvårsprosjekt er blitt et månedsprosjekt, for det er det ikke.
KI i selve produktet er noe annet
Dette blandes ofte sammen, så det er verdt å skille tydelig.
At vi bruker KI-verktøy i utviklingen, er en del av hvordan vi jobber og påvirker ikke løsningen dere får. At løsningen deres skal ha KI-funksjonalitet, for eksempel et søk som forstår naturlig språk eller en assistent som svarer ut fra deres dokumentasjon, er en egen funksjon som koster å bygge og som koster penger hver måned i drift.
Vi har skrevet om kostnadssiden i hvordan påvirker AI prisen på apputvikling, og om hvilke oppgaver som egner seg i kan en app med AI forenkle oppgaver i bedriften din.
Det som fortsatt avgjør prosjektet
Ingen verktøy har endret det som gjør prosjekter vellykkede.
Omfanget må være avgrenset. Noen hos dere må kunne ta beslutninger raskt. Og dere må se noe som faktisk virker underveis, framfor å lese statusrapporter. Disse tre tingene betyr fortsatt mer for utfallet enn hvilke verktøy utviklerne har.
Vil du vite mer om hvordan vi jobber? Se apputvikling og webapplikasjoner, eller ta kontakt for en prat om prosjektet ditt.