Åkte skidor i veckan. Det visar sig att om man är en skidåkare i den blå backen som pressas vidare till den röda backen får man ungefär 1.000 gånger mindre tid att tänka på AI. Prioriteringen blir tankar som “Hur ska jag göra nästa sväng?” och “Snälla Gud, låt den där snowboardåkaren springa längre bort från mig.” Kanske borde jag prioritera extrem rörelse i min dag för att buffra denna kvartlivskris? Eller… det kanske bara är ännu ett lager av krisen.
När jag tar en paus från mina mer domedagsfokuserade AI-tankar brukar jag bli besatt av att renovera vårt typiska Köpenhamnsbadrum på tre kvadratmeter. Det är förmodligen min längsta pågående ChatGPT-tråd. Vi diskuterar hela tiden hur komplicerat det är att riva det själva och låta proffs bygga om det. På pappret låter det inte så komplicerat. Miljontals människor har gjort det förut. Men tänk om det finns asbest? Du vet vart det samtalet leder.
Jag vill hellre att proffs sköter det och betalar ett högre pris för att se till att det görs ordentligt och uppfyller mina förväntningar och kvalitetsstandarder. Även om jag kan titta på alla YouTube-tutorials i världen, är min tid bättre spenderad på andra saker.
Den här tankeprocessen leder mig ofta tillbaka till de förändringar vi ser, och kommer att fortsätta se, i rekryteringstrenderna för mjukvaruutvecklare. Efter den pandemiska anställningsboomen inom mjukvarusektorn och den efterföljande korrigeringen är den långsiktiga efterfrågan på utvecklare fortfarande stark. Antalet mjukvaruutvecklare förväntas växa med cirka 17 % under det kommande decenniet. Det som förändras är inte behovet av ingenjörer, utan hur företagen utnyttjar den kapaciteten. Organisationerna blir mycket mer medvetna om när de ska anställa internt och när de ska förlita sig på extern expertis.
I min tidigare artikel, “Rethinking Software Development”, hävdade jag att det blir allt billigare att koda och bygga programvara. Men ägande, distribution och värdeförverkligande är fortfarande svårt att etablera. I en tid av “vibe coding” och alltmer lättillgängliga verktyg som kan blåsa upp den upplevda expertisen blir det ännu viktigare att vara kritisk till när man ska bygga och när man ska köpa. AI påskyndar utvecklingen, men det påskyndar också kunskapsförfallet.
För att återgå till badrumsrenoveringsanalogin finns det gott om bra innehåll online som förklarar hur man byter ut duschrör, omdirigerar rör och lägger kakel. Min partner och jag skulle förmodligen kunna räkna ut det. Men är det något jag med säkerhet skulle stå bakom om flera år, när lägenheten har nya ägare och jag kanske fortfarande är ansvarig för VVS-arbetet?
Tillgången till kunskap har aldrig varit billigare. Det betyder inte att kostnaden för misstag har förändrats. Billig kunskap innebär inte billiga konsekvenser. Låt detta vara den kraft som vägleder ditt beslut när du väljer om du ska bygga eller köpa programvarulösningar. Det kan kännas lockande att bygga allt själv när information och verktyg är så lättillgängliga. Men orealiserade kunskapsluckor är långsamma dödare. Att bygga lösningar som är lätta att skapa men svåra att äga kommer så småningom att leda bort ditt fokus från det som driver ditt värde. Eftersom jag är en byggare i hjärtat kan jag lätt bränna tid och pengar på att besluta mig för att bygga och äga något som är bättre att köpa. Var ligger den gyllene gränsen mellan att bygga och köpa? Min erfarenhet av att arbeta med ingenjörer som snabbt kan tillgodogöra sig kunskap inom olika områden och som är mycket skickliga byggare visar att beslutet om att bygga eller köpa ofta handlar om några få signaler.
När ska man bygga
- Iterationshastigheten är viktig – När du tittar på ett projekt med stora anpassningsbehov och en etableringströskel för FoU inom domänen, är det här du väljer att bygga. Internt ägande blir en fördel eftersom det gör det möjligt för ditt team att agera utan extern samordning, eller ännu värre, utan tillstånd eller debatt. Ju snabbare du utvecklar och lär dig av systemet, desto mer värdefullt blir ägandet.
- Kunskapen sprids internt – Som ett sidospår till den första punkten kan man säga att om du får mer kunskap genom att bygga en lösning så är det bara att köra på. Som Michael Scott skulle säga, det är en win-win-win. Kunskap som byggs upp genom dessa projekt sprids internt. Det här är en långsiktig investering för dig och dina medarbetare. Outsourcing skulle äventyra möjligheten att utveckla expertis som senare kan växa till din konkurrensfördel.
- Låg risk för misslyckande – Sist men absolut inte minst, försök att bedöma vad kostnaden för att ha fel kan bli. Om misstag är lätta att rätta till och inte får några långsiktiga konsekvenser kan lärandet av att bygga uppväga kostnaden för att köpa. I dessa situationer blir experimenterandet en lyckad investering snarare än en belastning.
När ska du köpa
- Dold komplexitet – Infrastruktur, säkerhet, efterlevnad och distribuerade system döljer lager av komplexitet som inte avslöjas förrän ett misstag inträffar. Externa domänspecialister bidrar med erfarenhet som hjälper till att undvika dyra kostnader för försök och misstag.
- Ansvars- eller säkerhetsrisk – Kostnaden för ett misslyckande är inte alltid teknisk; högre kostnader för ett misslyckande inkluderar juridiska och ekonomiska konsekvenser. När säkerhet, efterlevnad och trygghet påverkas ska man vara försiktig. Misstag inom dessa områden skapar bestående konsekvenser långt bortom implementeringen. Det är här specialistpriset är värt din sinnesfrid, och det är här vi ser att de flesta vibrationskodade lösningar misslyckas. Det är inte lätt att återställa trovärdighet som förlorats inom dessa områden.
- Icke-kärnkompetens – Allt handlar om att förbättra ditt värdeerbjudande som verksamhet. Om den eftertraktade förmågan inte stärker ditt värdeerbjudande kan det ta resurser i anspråk att bygga upp den internt och avleda uppmärksamheten från det som skapar din konkurrensfördel. Att köpa aspekter som faller utanför detta intervall gör att ditt team kan fokusera på områden där ägandet skapar värde.
När jag tänker tillbaka på dilemmat med badrumsrenoveringen var den verkliga frågan aldrig om vi kunde renovera det själva. Med tillräckligt med tid, handledning och tålamod skulle vi förmodligen kunna göra det. Och låt oss vara ärliga … mycket engagemang från våra pappor, haha. Den verkliga frågan var om vi ville ta konsekvenserna av det beslutet flera år senare.
Mjukvarubeslut är inte så annorlunda. AI har sänkt tröskeln för att bygga nästan vad som helst, men ansvaret för att äga det man bygger förblir oförändrat. System måste underhållas, säkras, stödjas och vara pålitliga långt efter att den första spänningen med att bygga dem har försvunnit. Bara för att man kan bygga något betyder det inte att man bör göra det. I en tid då det är enklare än någonsin att bygga kan det vara en mer värdefull färdighet att veta när man inte ska bygga.
För närvarande höjer den enklare kunskapsinhämtningen tröskeln för vilken typ av programvara vi väljer att investera i. Men den verkliga kostnaden för att bygga otaliga små interna lösningar har ännu inte avslöjats fullt ut. Vi kommer sannolikt att förstå den kostnaden först när några av dessa system börjar fallera. I slutändan handlar många av dessa beslut om ekonomi, vilket är något som jag har funderat mycket på. Hur förändrar den här AI-revolutionen och den kommande agentiska eran prissättningen av programvarulösningar? Jag kommer att utforska det i mitt nästa inlägg.
Under tiden kan man utforska byggmöjligheter med ett öppet sinne och experimentera med AI-lösningar som snabbar upp leveranserna, men vara kritisk till de långsiktiga kostnaderna.
Den här bloggen publicerades ursprungligen av författaren på Bara för att du kan bygga det betyder det inte att du borde.
