När är det dags att bygga något själv?

Många organisationer köper stora system för att lösa relativt avgränsade problem. Systemen införs, integreras och förvaltas — men efter några år används kanske bara en mindre del av funktionaliteten. Resten finns kvar som menyer ingen öppnar, moduler ingen vågar avveckla och möjligheter som lät viktiga under upphandlingen men aldrig blev en del av verksamheten.

Det betyder inte nödvändigtvis att systemet var fel val. En standardprodukt kan ge stabilitet, support, säkerhetsuppdateringar och erfarenheter från många andra kunder. Men när AI-assisterad utveckling gör det snabbare och billigare att skapa programvara behöver vi ställa frågan på nytt:

När är det bättre att bygga något litet och ändamålsenligt än att köpa något stort och generellt?

Vi jämför ofta fel saker

När organisationer väljer mellan att köpa och bygga jämför de vanligtvis licenskostnaden med uppskattad utvecklingskostnad. Det är en alltför enkel jämförelse.

Ett inköpt system medför kostnader för upphandling och införande, konfiguration, integrationer, utbildning, licenser, leverantörsstyrning, uppgraderingar, anpassning av verksamhetens processer — och för funktionalitet som aldrig används.

Ett egenutvecklat system medför andra kostnader: analys och utveckling, testning, dokumentation, drift och övervakning, säkerhetsuppdateringar, kompetensförsörjning, incidenthantering och långsiktig förvaltning.

Den verkliga frågan är därför inte vad som är billigast att anskaffa. Den är:

Vilket alternativ är organisationen bäst rustad att ta ansvar för under systemets hela livslängd?

AI förändrar kostnaden för att börja bygga

AI-assisterad utveckling har redan sänkt tröskeln för att skapa prototyper och mindre system. En erfaren utvecklare kan snabbare undersöka olika lösningar, skapa användargränssnitt, skriva integrationer, generera tester, dokumentera kod, refaktorera befintliga implementationer och prova en idé med verkliga användare.

Det gör att organisationer inte alltid behöver fatta ett stort köp-eller-byggbeslut från början. I stället kan de bygga en liten, avgränsad lösning för att förstå problemet bättre. En fungerande prototyp kan visa vilka behov som är verkliga, vilka integrationer som krävs och vilka delar som faktiskt ger användarna värde.

Det är viktigt, eftersom en kravspecifikation ofta beskriver vad människor tror att de behöver. En användbar prototyp visar vad de verkligen använder.

Men snabbare kod är inte samma sak som ett förvaltningsbart system

Det är här diskussionen ofta blir för optimistisk.

AI kan hjälpa oss att producera kod snabbare. Den tar inte automatiskt ansvar för arkitekturen, informationssäkerheten, tillgängligheten, personuppgiftsbehandlingen, driftsäkerheten, beroendena, framtida uppgraderingar eller verksamhetens kontinuitet.

Det är relativt enkelt att få en AI-assistent att bygga något som fungerar under en demonstration. Det är betydligt svårare att bygga något som fortfarande går att förstå, förändra och driftsätta säkert fem år senare.

Skillnaden mellan en prototyp och ett verksamhetssystem består inte främst av fler funktioner. Den består av ansvar.

När kan vi lita på AI-utvecklad kod?

Frågan innehåller egentligen ett missförstånd. Vi bör inte lita på kod därför att den är skriven av en människa. Vi bör inte heller misstro kod enbart därför att den är genererad med AI.

Vi ska lita på de processer som gör koden verifierbar. Kod blir inte pålitlig genom sitt ursprung, utan genom att vi kan visa att den:

uppfyller dokumenterade krav
har relevanta automatiserade tester
har granskats
hanterar fel på ett förutsägbart sätt
inte innehåller kända kritiska sårbarheter
kan övervakas i drift
går att återställa
har dokumenterade beroenden
kan förändras utan orimlig risk

En erfaren utvecklare kan skriva dålig kod. En AI kan generera bra kod. Det omvända är också sant. Den avgörande skillnaden är om organisationen har förmåga att bedöma resultatet.

AI minskar tiden det tar att producera kod. Den minskar inte automatiskt behovet av tekniskt omdöme. I vissa situationer ökar snarare behovet av omdöme, eftersom större mängder kod kan produceras på kortare tid.

När är vi redo att förvalta AI-utvecklade system?

En organisation är inte redo bara för att den kan bygga systemet. Den är redo när den kan svara på följande frågor:

Vem äger systemet?
Vem förstår arkitekturen?
Var finns källkoden?
Hur granskas förändringar?
Hur testas nya versioner?
Hur upptäcks incidenter?
Hur hanteras säkerhetsuppdateringar?
Vilka externa bibliotek och AI-tjänster är systemet beroende av?
Hur återställs systemet efter ett fel?
Vad händer när den ursprungliga utvecklaren försvinner?
Hur avvecklas systemet när det inte längre behövs?

Om svaren saknas har organisationen inte ett förvaltat system. Den har en fungerande prototyp med ett växande beroende. Det gäller oavsett om koden är skriven av anställda, konsulter eller AI.

Alla system är inte lika lämpliga att börja med

Det finns ingen generell tidpunkt då AI-utvecklad kod plötsligt blir säker för alla typer av system. Riskerna är olika.

Ett internt verktyg som sammanställer information och alltid låter en människa kontrollera resultatet kan vara en bra kandidat. Ett system som fattar myndighetsbeslut, hanterar känsliga personuppgifter eller styr kritisk infrastruktur är något helt annat.

Bra tidiga kandidater har ofta tydligt avgränsad funktion, begränsat antal användare, låg konsekvens vid fel, liten mängd känslig information, tydlig mänsklig kontroll, möjlighet till manuell reservrutin, få kritiska integrationer och mätbar nytta.

Dåliga första kandidater är system där ett fel kan påverka människors rättigheter, stoppa en central verksamhet eller skapa svårupptäckta säkerhetsproblem.

Börja inte med kärnsystemet

Organisationer som vill undersöka egen utveckling bör inte börja med att ersätta sitt största verksamhetssystem. Börja i kanten. Det kan vara ett internt arbetsflöde, ett verktyg för datakvalitet, en avgränsad integration, en sök- eller sammanställningstjänst, ett beslutsstöd där människan fattar beslutet, ett administrationsgränssnitt — eller en manuell process som idag bygger på kalkylblad och e-post.

Bygg något litet. Låt verkliga användare prova det. Mät om det sparar tid eller förbättrar kvaliteten. Dokumentera hur lösningen byggdes och vad som krävs för att förvalta den.

Då utvärderar organisationen inte bara AI:s förmåga att skriva kod. Den utvärderar sin egen förmåga att äga resultatet.

Egenutveckling behöver inte betyda att man bygger allt

Valet är inte binärt. En organisation kan kombinera standardprodukter, öppna komponenter, molntjänster, egna integrationer, mindre specialbyggda applikationer och AI-assisterad utveckling.

Det mest rimliga kan vara att köpa det generella och bygga det verksamhetsspecifika. Identitet, loggning, databaser och standardiserad dokumenthantering behöver sällan uppfinnas på nytt. Men den del som uttrycker organisationens unika arbetsprocess kanske inte behöver pressas in i en stor produkt som är konstruerad för hundratals andra användningsfall.

Gränsen är organisatorisk, inte tidsmässig

Det är frestande att fråga när AI kommer att vara tillräckligt bra för att vi ska kunna lita på AI-utvecklade system. Kanske om två år. Kanske om fem.

Men den viktigaste gränsen går inte i kalendern. Den går mellan organisationer som kan verifiera, äga och förvalta programvara och organisationer som bara kan beställa den.

AI kan redan idag vara användbar för att utveckla avgränsade lösningar. Men den organisation som saknar teststrategi, arkitekturkompetens, säkerhetsarbete och tydligt systemägarskap blir inte redo bara för att modellerna förbättras. Tvärtom kan det bli farligare när det blir ännu enklare att skapa system som ser färdiga ut.

Den nya frågan före plattformen

Tidigare frågade vi:

Vilket system ska vi köpa?

Nu behöver vi först fråga:

Vilken del av problemet är generell, vilken del är unik för oss och vad är vi beredda att förvalta själva?

Ibland blir slutsatsen att köpa en etablerad produkt. Ibland blir den att bygga en liten egen lösning. Ofta blir svaret en kombination.

Det viktiga är att beslutet inte börjar med plattformen — och inte heller med fascinationen inför vad AI kan generera. Det börjar med verksamheten, risken och ansvaret.

Det är inte dags att bygga själv när AI kan producera koden. Det är dags när organisationen kan ta ansvar för systemet som koden blir en del av.