Det snakkes mye om at KI har endret programvareutvikling fundamentalt. Som med de fleste slike påstander ligger sannheten et sted i midten, og det er verdt å være presis om hvor.
Verktøyene har endret hvordan vi jobber til daglig. De har ikke endret hva som gjør et prosjekt vellykket, og de har i mindre grad enn mange tror endret hva ting koster.
Hva som faktisk går raskere
Kodeassistenter er en normal del av arbeidsflyten nå. Gevinsten er reell, men den er ujevnt fordelt.
Den er størst der arbeidet er forutsigbart. Å sette opp strukturer, skrive tester for de kjedelige tilfellene, lage testdata, konvertere mellom dataformater, og skrive kode som ligner på noe som er skrevet tusen ganger før. Dette er arbeid som tidligere tok en halvtime og nå tar noen minutter.
Testing er kanskje 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 blir nedprioritert fordi det er kjedelig. Når terskelen for å skrive tester går ned, blir det faktisk gjort, og det merkes på kvaliteten.
Den er minst der arbeidet krever forståelse av nettopp deres situasjon. Å finne ut hvorfor en integrasjon mot et gammelt fagsystem oppfører seg uventet, eller å velge mellom to måter å strukturere noe på når konsekvensene først dukker opp om to år, er fortsatt arbeid som krever en som har sett det før.
Hvorfor prosjekter ikke er blitt tilsvarende billigere
Fordi koding aldri var den største posten.
I et vanlig prosjekt går en stor del av tiden til å 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. Legg til avklaringer, godkjenninger og ventetid på tredjeparter, og det blir tydelig at raskere kodeskriving påvirker én del av en lengre kjede.
Det er også kommet en ny kostnad som er verdt å nevne. Kode som produseres raskt, må fortsatt leses og forstås av noen som skal vedlikeholde den. Kode ingen egentlig har tenkt gjennom, blir dyr senere, selv om den fungerte da den ble skrevet. Tidsbesparelsen er ekte bare når noen går god for resultatet.
Hva dette betyr for deg som kunde
Det praktiske rådet er å være skeptisk til leverandører som lover dramatisk lavere priser fordi de bruker KI.
Enten har de ikke regnet på hvor tiden faktisk går, eller så kutter de i det som ikke bør kuttes. En app blir ikke god av at koden ble skrevet fort. Den blir god av at noen har tenkt gjennom hva den skal gjøre, testet det med folk som skal bruke den, og ryddet opp etterpå.
Det som er rimelig å forvente, er at rutinearbeid går raskere, at testdekningen er bedre enn den var for noen år siden, og at små endringer kan gjøres kjappere. Ikke at et halvårsprosjekt er blitt et månedsprosjekt.
Det som ikke har endret seg
Prosjekter lykkes fortsatt av de samme grunnene de alltid har gjort.
Omfanget må være avgrenset. En løsning med halvparten så mange funksjoner tar omtrent halvparten så lang tid, uansett hvilke verktøy som brukes.
Noen må kunne ta beslutninger raskt. Ventetid på avklaringer er fortsatt den vanligste enkeltårsaken til forsinkelse, og ingen verktøy hjelper på det.
Og dere må se noe som virker underveis. Det er fortsatt først når folk klikker på noe at de oppdager at de mente noe annet enn de sa.
Vi har samlet mer om dette i vanlige feil i apputvikling.
KI inne i selve løsningen
Dette er en annen diskusjon enn hvordan utviklere jobber, og den blandes ofte sammen.
Skal nettløsningen deres bruke KI til noe, for eksempel et søk som forstår hva brukeren mener, eller en assistent som svarer ut fra deres egen dokumentasjon, er det en egen funksjon som koster å bygge og som koster å drifte hver måned.
Der vi ser tydeligst verdi er søk og gjenfinning, og avlastning av kundeservice på spørsmål som besvares av dokumentasjon dere allerede har. Der vi ser minst verdi er funksjoner som er lagt til fordi de skulle være der.
Vi har skrevet mer om kostnadssiden i hvordan påvirker AI prisen på apputvikling, og om hva som faktisk er tatt i bruk i AI i apputvikling.
Hvordan vi bruker det
Vi bruker KI-assistenter der de gir gevinst, og vi leser gjennom det som kommer ut. Ingen kode går inn i et kundeprosjekt uten at en utvikler har forstått hva den gjør og hvorfor.
Det betyr at dere får noe av gevinsten i form av raskere framdrift på rutinearbeid, og at dere slipper risikoen som følger med kode ingen har tenkt gjennom.
Vil du diskutere et prosjekt? Se hvordan vi jobber med webapplikasjoner og apputvikling, eller ta kontakt.