Jeg gikk på ski denne uken. Det viser seg at det å være en skiløper i blå løype som blir skjøvet videre til de røde bakkene, gir deg omtrent 1000 ganger mindre tid til å tenke på AI. Prioriteten blir tanker som «Hvordan skal jeg klare neste sving?» og «Vær så snill, Gud, la den snowboarderen løpe lenger vekk fra meg». Kanskje jeg burde prioritere ekstrem bevegelse i hverdagen for å bufre denne kvartlivskrisen? Eller … kanskje det bare er enda et lag av krisen.
Når jeg tar en pause fra mine mer dommedagsfokuserte AI-tanker, pleier jeg å være besatt av å pusse opp vårt typiske tre kvadratmeter store bad i København. Det er sannsynligvis min lengste pågående ChatGPT-tråd. Vi diskuterer stadig hvor komplisert det er å rive det selv og få profesjonelle til å bygge det opp igjen. På papiret høres det ikke så komplisert ut. Millioner av mennesker har gjort det før. Men hva om det er asbest? Du vet hvor den samtalen ender.
Jeg vil heller la fagfolk ta seg av det og betale en høyere pris for å være sikker på at det blir gjort skikkelig og oppfyller mine forventninger og kvalitetsstandarder. Selv om jeg kan se all verdens YouTube-veiledninger, er tiden min bedre brukt på andre ting.
Denne tankeprosessen fører meg ofte tilbake til de endringene vi ser, og som vi vil fortsette å se, i ansettelsestrendene for programvareutviklere. Etter den pandemiske ansettelsesboomen i programvaresektoren og den påfølgende korreksjonen, er den langsiktige etterspørselen etter utviklere fortsatt sterk. Det forventes en vekst på rundt 17 % i stillinger innen programvareteknikk i løpet av det neste tiåret. Det er ikke behovet for ingeniører som er i endring, men hvordan bedriftene bruker denne kompetansen. Organisasjoner blir langt mer bevisste på når de skal ansette internt og når de skal benytte seg av ekstern ekspertise.
I min tidligere artikkel «Rethinking Software Development» argumenterte jeg for at det blir stadig billigere å kode og bygge programvare. Men eierskap, distribusjon og realisering av verdi er fortsatt vanskelig å etablere. I en tid med «vibe coding» og stadig mer tilgjengelige verktøy som kan blåse opp den opplevde ekspertisen, blir det enda viktigere å være kritisk til når man bør bygge og når man bør kjøpe. AI setter fart på utviklingen, men det akselererer også kunnskapsforfallet.
For å gå tilbake til baderomsoppussingsanalogien: Det finnes mye bra innhold på nettet som forklarer hvordan man bytter ut dusjrør, legger om rør og legger fliser. Det kan sikkert jeg og samboeren min finne ut av. Men er det noe jeg kan stå inne for om mange år, når leiligheten har fått nye eiere og jeg kanskje fortsatt er ansvarlig for rørleggerarbeidet?
Tilgang til kunnskap har aldri vært billigere. Det betyr ikke at kostnadene ved feil har endret seg. Billig kunnskap er ikke ensbetydende med billige konsekvenser. La dette være styrende når du skal velge om du skal bygge eller kjøpe programvareløsninger. Det kan føles fristende å bygge alt selv når informasjon og verktøy er så lett tilgjengelig. Men urealiserte kunnskapshull er en langsom morder. Å bygge løsninger som er enkle å lage, men vanskelige å eie, vil til slutt føre til at fokuset ditt sporer av fra det som driver verdien din. Jeg er selv en byggmester i hjertet, og jeg kan lett kaste bort tid og penger på å bygge og eie noe som er bedre å kjøpe. Hvor ligger det gode punktet mellom å bygge og å kjøpe? Min erfaring med ingeniører som raskt kan tilegne seg kunnskap på tvers av domener og som er svært dyktige byggere, viser at avgjørelsen om å bygge eller kjøpe ofte kommer ned til noen få signaler.
Når du skal bygge
- Iterasjonshastighet er viktig – Når du ser på et prosjekt med store tilpasningsbehov og en etableringsterskel for domene-FoU, er det her du velger å bygge. Internt eierskap blir en fordel, ettersom det gjør det mulig for teamet å bevege seg uten ekstern koordinering, eller enda verre, tillatelse eller debatt. Jo raskere dere utvikler og lærer av systemet, desto mer verdifullt blir eierskapet.
- Kunnskap bygges opp internt – Som en sideeffekt av det første punktet, hvis det å bygge en løsning øker din målrettede ekspertise, så gjør det. Som Michael Scott ville sagt, er det en vinn-vinn-vinn-situasjon. Kunnskapen som bygges opp gjennom disse prosjektene, bygges opp internt. Dette er en langsiktig investering for deg og dine ansatte. Outsourcing vil gå på bekostning av muligheten til å utvikle ekspertise som senere kan bli et konkurransefortrinn.
- Lav risiko for å mislykkes – Sist, men ikke minst, prøv å vurdere hva kostnaden ved å ta feil kan bli. Hvis feilene er lette å rette opp og ikke får langsiktige konsekvenser, kan læringen man får av å bygge, oppveie kostnadene ved å kjøpe. I slike situasjoner blir eksperimenteringen en vellykket investering i stedet for en belastning.
Når du skal kjøpe
- Skjult kompleksitet – Infrastruktur, sikkerhet, samsvar og distribuerte systemer skjuler lag av kompleksitet som ikke avsløres før det oppstår en feil. Eksterne domenespesialister bidrar med erfaring som gjør det enklere å unngå dyre prøving og feiling.
- Ansvars- eller sikkerhetsrisiko – Kostnadene ved feil er ikke alltid av teknisk art. De kan også omfatte juridiske og økonomiske konsekvenser. Når det gjelder sikkerhet, samsvar og trygghet, må du trå varsomt. Feil på disse områdene får varige konsekvenser langt utover implementeringen. Det er her spesialistprisen er verdt tryggheten, og det er her vi ser at de fleste vibrasjonskodede løsninger mislykkes. Det er ikke lett å gjenopprette troverdigheten som går tapt på disse områdene.
- Ikke-kjernekompetanse – Alt handler om å styrke virksomhetens verditilbud. Hvis den etterspurte kapasiteten ikke styrker verditilbudet ditt, kan det å bygge den internt tappe ressurser og avlede oppmerksomheten fra det som bygger opp konkurransefortrinnet ditt. Ved å kjøpe inn aspekter som faller utenfor dette området, kan teamet fokusere på områder der eierskap skaper verdi.
Når vi tenker tilbake på dilemmaet med baderomsrenoveringen, var det egentlige spørsmålet aldri om vi kunne renovere det selv. Med nok tid, opplæring og tålmodighet kunne vi sannsynligvis gjøre det. Og la oss være ærlige… med mye involvering fra fedrene våre, haha. Det virkelige spørsmålet var om vi ønsket å ta konsekvensene av den avgjørelsen mange år senere.
Programvarebeslutninger er ikke så annerledes. Kunstig intelligens har senket terskelen for å bygge nesten hva som helst, men ansvaret for å eie det du bygger, forblir uendret. Systemer må vedlikeholdes, sikres, støttes og ha tillit til lenge etter at den første begeistringen over å bygge dem har lagt seg. Bare fordi du kan bygge noe, betyr ikke det at du bør gjøre det. I en tid der det er enklere enn noensinne å bygge, kan det å vite når man ikke skal bygge, bli den mest verdifulle ferdigheten.
Enklere kunnskapsinnhenting hever foreløpig terskelen for hva slags programvare vi velger å investere i. Men de reelle kostnadene ved å bygge utallige små, interne løsninger er ennå ikke fullt ut avdekket. Vi vil sannsynligvis først forstå kostnadene når noen av disse systemene begynner å svikte. Til syvende og sist handler mange av disse beslutningene om økonomi, og det er noe jeg har tenkt mye på. Hvordan vil AI-revolusjonen og den kommende agent-æraen endre prisingen av programvareløsninger? Det skal jeg utforske i mitt neste innlegg.
I mellomtiden kan du utforske byggemulighetene med et åpent sinn og eksperimentere med AI-løsninger som fremskynder leveransen, men vær kritisk til de langsiktige kostnadene.
Denne bloggen ble opprinnelig publisert av forfatteren på Just Because You Can Build It Doesn’t Mean You Should.
