Plattformar kommer att äta världen

År 2011 hävdade Marc Andreessen att programvarubolagen höll på att ta över stora delar av ekonomin, därför att programvaran hade blivit mekanismen genom vilken en bransch kunde omorganiseras, skalas och till slut ersättas. Gränsen mellan ett teknikbolag och ett vanligt bolag började suddas ut. Bank, handel, logistik, media, telekom och transport skulle alla sluta med att drivas av programvara, och så gott som allt annat också.

Han fick rätt.

Programvaran skulle aldrig bli den sista abstraktionen. Den är ett lager i en process som började långt innan datorer fanns: människor tar en mekanism som kräver uttalad kunskap och manuell styrning, sveper in den bakom en abstraktion och bygger något kraftfullare ovanpå. Mekanismen försvinner inte. Den blir infrastruktur.

Det händer igen, och den här gången är mekanismen programvaruutvecklingen själv.

Branschen läser för närvarande AI som en bättre programmerare. Vi byggde kodagenter, AI-utvecklingsmiljöer och produkter som gör ett stycke engelska till en körande applikation. Replit, Lovable och Claude Code har visat hur långt kostnaden för att producera kod har fallit — beskriv en app och se databaser, API:er, skärmar och affärslogik dyka upp på en eftermiddag i stället för på ett kvartal.

Det är en verklig bedrift, och antagligen en övergående. Den intressanta frågan är inte om AI kan skriva programvara snabbare än människor. Det kan den, och den kommer att bli mycket bättre på det. Frågan är varför de flesta verksamhetssystem över huvud taget ska fortsätta skrivas ner som källkod. Vårt svar är att de inte ska det.

Nästa abstraktion skiljer systemet från programvaran som kör systemet. Plattformen är programvara. Systemen som körs på den är deklarativa data. AI arbetar på det deklarativa lagret och monterar system ur begränsade, testade plattformsförmågor i stället för att generera en ny implementation av de förmågorna för varje kund.

Det låter som en arkitektonisk smaksak. Det avgör vem som kan bygga verksamhetsprogramvara, vad det kostar att ändra den och hur länge den överlever.

Om programvaran åt världen kommer plattformarna att äta programvaran.

Ny teknik automatiserar alltid den gamla världen först. Tidiga bilar såg ut som vagnar utan häst. Tidiga webbplatser såg ut som trycksidor. Tidiga smarttelefoner ärvde antaganden från stationära datorer. Det gamla paradigmet ger oss orden vi förstår det nya med, så det första någon gör med en ny förmåga är att rikta den mot gårdagens uppgift.

I sjuttio år har det betytt kod att producera programvara. Så när maskiner blev kapabla att resonera om programmering var det självklara draget att låta dem producera kod. Beskriv resultatet, få en implementation. Enormt användbart, och en automatisering av en abstraktion vi redan hade.

Resultatet är fortfarande en kodbas. Den innehåller fortfarande arkitektur, beroenden, tillståndsmodeller, gränssnitt, databasantaganden, behörighetsregler, integrationsstrategier och flera tusen implementationsbeslut. Den ändras fortfarande. Den behöver fortfarande migreringar. Den samlar fortfarande på sig historia ingen minns att den skapat, har fortfarande samspel ingen avsåg, och måste fortfarande hänga ihop medan organisationen den representerar ändras under den.

AI gör den komplexiteten billigare. Billig komplexitet är fortfarande komplexitet.

Det finns en märkligare följd bakom den. Vi kan snart komma att producera programvarukomplexitet snabbare än organisationer kan förstå den. Ett bolag som samlat tio miljoner rader under ett decennium skulle kunna generera samma volym på ett par månader. Skrivproblemet försvinner. Sammanhangsproblemet gör det inte.

Bättre modeller tar tillbaka en del av det här. Större kontextfönster, resonemang på förvarsnivå, automatisk testning, formell verifiering och kapablare agenter kommer att låta AI hantera långt större kodbaser än något mänskligt team kunde hålla i huvudet. Kvar står ändå den arkitektoniska frågan: varför lägga så mycket intelligens på att generera, och sedan läsa om, miljontals unika implementationsbeslut som beskriver förmågor någon redan löst?

Den bästa användningen av AI är inte att göra den gamla abstraktionen oändligt billig. Det är att bygga nästa.

De tidigaste programmerarna arbetade i representationer bundna direkt till hårdvaran. Assembler lade ett läsbart lager över maskininstruktionerna. Högnivåspråk tog bort registren ur arbetet. Operativsystemen tog över hårdvaran. Databasmotorerna tog över lagringen. SQL lät en beskriva de data man ville ha i stället för stegen som krävdes för att hämta dem. Skräpsamlare raderade en hel felkategori ur vanligt applikationsarbete.

Varje sådan övergång såg dyr, begränsande eller kraftlös ut för dem som förstod lagret under. De hade ofta rätt. Assembler kunde saker tidiga kompilatorer inte kunde. C blottar kontroll som hanterade körmiljöer döljer. En handskriven fråga slår ibland fortfarande abstraktionen, och dedikerad infrastruktur slår fortfarande generiska molntjänster. Lägre lager förblir nödvändiga överallt där den extra kontrollen är värd det extra arbetet.

Det är inte det intressanta i historien. Det intressanta är att värdets tyngdpunkt flyttade uppåt.

Nästan ingen som bygger ett verksamhetssystem i dag skriver maskinkod, assembler, ett operativsystem, en databasmotor eller en nätverksstack. De förlitar sig på enorma mängder programvara de inte skrivit och inte skulle kunna förklara i detalj. Det är ingen svaghet i modern ingenjörskonst. Det är skälet till att modern ingenjörskonst fungerar alls.

För verksamhetssystem är applikationskoden nästa lager som sjunker.

Ett lånesystem är inte kontrollklasser, databastabeller, React-komponenter och REST-slutpunkter. Det är mekanismer. Systemet är kunder, ansökningar, lån, säkerheter, beslut, dokument, behörigheter, beräkningar, tillstånd och arbetsflöden, plus reglerna som säger vad som får hända, under vilka villkor, vem som får utlösa det, vilken information som krävs, vilka andra system som rådfrågas och vad som följer när det väl sker.

Detsamma gäller ett affärssystem, ett CRM, ett inköpssystem, en ärendehanteringsplattform, ett försäkringssystem och en logistikapplikation. De är körbara beskrivningar av organisationer. De säger vad som finns, vad människor får göra, vad maskiner får göra, vad som händer sedan, hur saker hänger ihop och vad organisationen försöker åstadkomma.

Vi skrev ner de modellerna som källkod därför att källkod var det kraftfullaste generella sättet att uttrycka körbart beteende. Med tiden blev det historiska faktumet tyst ett antagande, och nu förväxlar branschen implementationen med det som implementeras.

Organisationen är inte TypeScript. Inköpsprocessen är inte Java. En kreditpolicy är inte C#. En attesthierarki är inte en samling API-slutpunkter.

Det är översättningar, och en översättning finns därför att den som utför inte kan läsa originalet. Byt ut det som utför och översättningen kan gå.

Det här handlar inte om att flytta några konstanter till JSON-filer. Inte konfigurationsstyrd utveckling. Inte scheman lindade kring en i övrigt konventionell applikation. Inte att generera källkod ur metadata och checka in resultatet. Inte en visuell byggare som tyst spottar ur sig ännu en skräddarsydd applikation på slutet.

Vi menar hela systemet. Domänmodell, gränssnitt, arbetsflöden, handlingar, behörigheter, valideringar, beräkningar, integrationer, relationer, affärsregler, tillståndsövergångar och beteende, alltihop som deklarativa data som består.

De data ÄR systemet. Plattformen läser in dem och kör dem.

Det finns inget kompileringssteg där definitionen blir en unik applikation som sedan påbörjar en livscykel av eget slag. Ingen organisation behöver ännu ett kodförvar med ännu en implementation av inloggning, formulär, behörigheter, arbetsflöden, lagring, API:er, tillståndshantering och integrationsrörmokeri. Plattformen vet redan hur det fungerar.

Ett system säger vad som finns och vad som ska hända. Plattformen avgör hur det körs. Det är skillnaden mellan att beskriva en organisation och att bygga ännu en programvarustack som råkar representera en.

Plattformen är själv programvara, och den delen betyder mer än något annat här. Inget av det här vilar på att koden försvinner ur databehandlingen. Tvärtom: ju mer ansvar som flyttar in i plattformen, desto mer avgör plattformens ingenjörskvalitet allting.

En plattform generell nog att vara värd bytet måste rymma genuint svår programvara. Exekveringssemantik, dataåtkomst, säkerhet, behörigheter, gränssnittsförmågor, arbetsflödeskörning, integrationsmekanismer, observerbarhet, cachning, validering, transaktioner. Adaptrar som pratar med databaser och externa system den inte konstruerades mot. Abstraktioner breda nog att tjäna organisationer ingen hade i tankarna när de skrevs.

Den svåra ingenjörskonsten försvinner alltså inte. Den koncentreras. Plattformsingenjörer resonerar fortfarande om algoritmer, arkitektur, samtidighet, databaser, protokoll, prestanda och säkerhet, och de använder AI-kodagenter flitigt, eftersom det vore idiotiskt att tacka nej till bättre verktyg. Skillnaden är att de löser de problemen en gång, i plattformslagret, i stället för att lösa varianter av dem inuti varje kunds system.

Ingen implementerar processchemaläggning, virtuellt minne, drivrutiner och filsystemssemantik innan de skriver en bokföringsapplikation. Det hör till ett annat lager, och alla accepterar det utan diskussion. En plattform för verksamhetssystem för samma tanke ett steg uppåt.

Plattformen är kod. Systemet är data. Förväxla de två och inget av resten fungerar.

Generativ AI är kraftfull delvis därför att den arbetar över enorma möjlighetsrymder. Be en modell implementera en funktion och det finns tusentals tekniskt rimliga implementationer. Den väljer en, utifrån förfrågan, koden runtomkring, sin träning och vilka ramar den kan sluta sig till.

Den friheten är precis vad man vill ha när det som byggs är genuint nytt. Den är nästan värdelös när problemet redan har ett kanoniskt svar.

Ett företagssystem ska inte behöva AI för att uppfinna en behörighetsarkitektur varje gång någon lägger till ett arbetsflöde. Det ska inte behöva en ny valideringsstrategi per formulär, eller ett beslut från grunden om hur transaktioner, spårbarhet, identitet och dataåtkomst borde fungera. De besluten ska vara avgjorda av plattformen innan modellen kommer.

En plattform gör en enorm implementationsrymd till en avgränsad förmågerymd. Om den erbjuder behörigheter beskriver AI:n en behörighet i stället för att skriva en. Om den kör arbetsflöden definierar AI:n ett arbetsflöde i stället för att bygga en motor. Om den förstår relationer anger AI:n relationen. Modellen resonerar fortfarande. Den kan bara inte improvisera grunden.

Poängen är inte att begränsa intelligensen. Det är att sluta lägga den på problem som redan är lösta.

Allt annat i det här argumentet vilar på ett påstående: AI ska montera system ur betrodda byggstenar snarare än uppfinna system på nytt som källkod.

Jämförelsen är tillverkning. En ingenjör som konstruerar en komplex produkt återupptäcker inte metallurgin, tillverkar inte varje transistor och uppfinner inte varje skruv. Den industriella civilisationen fungerar därför att standardiserade förmågor går att sätta ihop till saker av absurd komplexitet. Programvaran kom det mesta av vägen dit med bibliotek, ramverk, API:er, tjänster och molninfrastruktur, och stannade sedan ett lager för tidigt. Vi återanvänder komponenterna och skriver sedan skräddarsydd applikationskod som håller ihop dem.

Gör hopfogandet deklarativt och det intressanta arbetet byter form. Vad försöker organisationen åstadkomma? Vilka objekt finns? Vilken information rör sig mellan dem, och vad begränsar den rörelsen? Vem har befogenhet? Vilka beslut går att automatisera och vilka kräver omdöme? Vilka steg är sekventiella bara av gammal vana? Vilka externa system deltar, och vilka undantag spelar faktiskt roll?

Det är resonemangsproblem, och de avgör om systemet är värt något. Om implementationen använde ett tillståndsmönster eller ett annat gör det inte.

Vi lägger hellre intelligensen på den första listan.

Inget av det här tar bort kreativiteten ur systembyggandet. Det flyttar den dit den alltid gjorde störst nytta.

Ta två bolag som inför orderhantering på samma plattform. Det första digitaliserar processen det redan har. Det andra lägger märke till att tre av dess attesteg finns bara därför att information förr rörde sig långsamt mellan avdelningar, ritar om flödet, automatiserar rutinbesluten och lämnar de tvetydiga till människor.

Det andra bolaget byggde det bättre systemet. Inte för att dess kod är elegantare — det kanske inte finns någon applikationskod alls. Det byggde det bättre systemet för att det förstod sin egen verksamhet bättre.

Det betyder mer i takt med att implementationskostnaden faller. När nästan vem som helst kan producera funktionalitet slutar funktionalitet vara det som skiljer, och frågan blir vilken funktionalitet som borde finnas. Den knappa förmågan flyttar från implementationskunskap mot domänkunskap och systemtänkande.

Varför finns den här processen? Vilka begränsningar är verkliga och vilka är historiska olyckor? Var dubblerar vi information, och var väntar människor på andra människor? Vilket beslut kräver omdöme och vilket är bara en regel som följs för hand? Vilket steg överlever bara för att två gamla system inte kunde prata med varandra?

Det är kreativa frågor, och de som lagt karriärer på att lära sig svara på dem är sällan programmerare.

Varje steg går att försvara. Varje steg tappar något. När systemet når produktion har en enorm andel av arbetet gått åt till att flytta kunskap från dem som förstår organisationen till en form en maskin kan köra. Sedan ändras organisationen och kedjan börjar om.

AI ovanpå en deklarativ plattform trycker ihop den kedjan, därför att den som bygger systemet i allt högre grad kan vara den som förstår problemet. En managementkonsult. En entreprenör. En redovisningsekonom som förstår en genuint hemsk ekonomiprocess. En logistikspecialist. En försäkringsexpert. En driftchef som sett samma överlämning fallera i tjugo år.

I dag skriver de personerna krav till utvecklare. På en deklarativ plattform kan de bygga den körbara modellen direkt, med AI som översätter avsikt till plattformens begränsade semantik.

Programmeraren försvinner inte. Programmeraren flyttar ner i stacken och blir plattformsingenjör, medan verksamhetsexperten flyttar närmare maskinen, och lagret mellan dem blir tunt.

Det är en långt större demokratisering av programvaran än att lära alla prompta en kodagent.

Den traditionella utvecklarens avgörande färdighet är att göra önskat beteende till en fungerande implementation. Den avgörande färdigheten hos den som bygger system härnäst är att förstå system i den äldre, bredare meningen: organisationer, drivkrafter, information, begränsningar, beslut och utfall.

Det är konsultarbete, med en skillnad som ändrar allt. Konsultarbete slutar normalt i dokument, diagram och rekommendationer, och någon annan måste göra dem till fungerande verklighet. Det är där de flesta av dem dör.

På en deklarativ plattform är processmodellen inte dokumentation om programvaran. Den är en del av programvaran. Behörighetsmodellen är inte en specifikation som väntar på att implementeras; den är det som upprätthålls. Arbetsflödet är inte ett diagram bifogat ett ärende; det är arbetsflödet.

Skillnaden mellan att utforma organisationen och att utforma dess informationssystem faller samman, därför att en modern organisation redan är oskiljaktig från sina system.

Ett moget verksamhetssystem bär en häpnadsväckande mängd institutionell kunskap. Det vet vilken kundinformation som spelar roll, vilka tillstånd en order kan befinna sig i, vem som får godkänna en transaktion, vilka dokument ett ärende kräver, hur priset räknas fram, vad som utlöser en avisering och vilka undantag som eskaleras.

I konventionell programvara ligger den kunskapen utspridd i källkod, databasscheman, konfigurationsfiler, dokumentation, ärenden, invand vana och huvudena på medarbetare som varit där länge nog. Den splittringen är ett av huvudskälen till att företagssystem är så svåra att ändra. Innan du kan ändra beteendet måste du hitta det.

Ett deklarativt system gör kunskapen uttalad, och en uttalad modell går att resonera om. AI kan granska arbetsflödena, hitta vänttillstånden som inte tjänar någon, jämföra två avdelningar som gör samma sak olika, upptäcka regler som motsäger varandra, förklara exakt varför en användare får utföra en handling och simulera en ändring innan någon tillämpar den.

Till slut kan den ställa en bättre fråga än hur nästa krav ska implementeras. Den kan fråga varför organisationen fungerar så här alls.

Den självklara invändningen: riktiga företagssystem är komplicerade. Korrekt. Organisationer är komplicerade. En multinationell tillverkare driver inköp, produktion, ekonomi, regelefterlevnad, logistik och kvalitetskontroll över hundratals externa system. En bank bär produkter, regelverk, riskmodeller, behörigheter och processer som tagit decennier att samla på sig. Ett försäkringsbolag kodifierar regler ingen nu anställd minns att någon skrev.

Slutsatsen som normalt dras är att sådana system kräver enorma skräddarsydda kodbaser. Det följer inte.

Komplexitet kan inte avskaffas genom att man ändrar hur den skrivs ner. Har verksamheten tiotusen meningsfulla regler måste tiotusen regler bo någonstans. Men verksamhetskomplexitet och implementationskomplexitet är olika storheter, och vi multiplicerar dem vanemässigt med varandra.

Ett skattesystem med tusentals regler behöver inte tusentals egna infrastrukturdelar. Ett arbetsflöde med hundratals övergångar behöver inte skräddarsydd arkitektur per övergång. En organisation med tusentals behörighetsrelationer behöver inte tusentals handskrivna behörighetskontroller.

Målet är inte att utplåna den väsentliga komplexiteten. Det är att sluta multiplicera den med den tillfälliga, och att låta organisationens komplexitet vara synlig som organisatorisk komplexitet i stället för begravd i maskineri.

Inget av det här fungerar om plattformen är en bekväm hög komponenter. Den måste vara generell nog att representera system dess konstruktörer aldrig föreställde sig, och det är den genuint svåra delen.

Varje abstraktion byter frihet mot räckvidd. För smal, och användarna går in i väggen och flyr ut i egen kod. Samla nog många nödutgångar så är plattformen ett ramverk med skräddarsydda applikationer runt sig, vilket är precis det vi försöker sluta med.

Målet är en uppsättning byggstenar grundläggande nog att enorm variation kommer ur komposition snarare än ur implementation. En databas klarar det: dess konstruktörer vet inte vad någon kommer att lagra. Det gör ett programspråk också, och ett operativsystem. Ingen av dem känner sin egen framtida last.

En systemplattform måste träffa samma egenskap ett lager högre. Den kan inte känna verksamheterna i förväg. Den måste veta tillräckligt om beräkning, information, interaktion och hur organisationer faktiskt beter sig för att de verksamheterna ska kunna beskriva sig själva.

Det är mycket svårare än att generera ännu en applikation. Det är också den enda delen värd att göra, för det är den delen som inte behöver göras om.

En av de minst omtalade kostnaderna för konventionell programvara är att dess abstraktioner åldras i egen takt. Ett bolag bygger en applikation 2026, och dess beroenden, arkitektur, ramverksantaganden och mönster är alla 2026. Fem år senare behöver verksamheten fortfarande applikationen, och den tekniska världen runt den har flyttat sig.

Då börjar arkeologin. Beroenden ska uppgraderas. API:er tas ur bruk. Säkerhetsmodeller ändras. Ramverk överges. Infrastrukturantaganden går ut. Någon föreslår en omskrivning, någon annan påpekar korrekt att omskrivningar är hur bolag dör, och pengarna går till att hålla gårdagens implementation vid liv.

AI kommer att göra migreringar billigare. Den bättre frågan är varför migreringen finns i applikationslagret alls.

Om systemet är deklarativa data som tolkas av en plattform som fortsätter utvecklas sker de flesta av de migreringarna under det. Ingen migrerar ett arbetsflöde för att plattformen ändrat hur den renderar gränssnittet. Ingen skriver om en behörighetsmodell för att behörighetsimplementationen blev bättre. Verksamhetssemantiken står stilla medan körmiljön rör sig.

Ett system kan hålla sig tekniskt aktuellt utan att dess implementationsstack är fastfrusen i det år någon skrev den.

Konventionell utveckling har ett multiplikationsproblem. Varje ny applikation är ännu en angreppsyta, ännu en beroendegraf, ännu en inloggningsintegration, ännu en behörighetsimplementation, ännu en uppsättning API:er och ännu en hög med chanser att göra fel.

Genererad kod löser inte det. Den förvärrar det, därför att antalet applikationer en organisation måste försvara stiger med hur lätt de är att producera.

En plattform ändrar säkerhetsarbetets enhet. Om identitet, behörigheter, dataåtkomst och spårbarhet tillhör plattformen ärver varje system dem, och varje förbättring landar överallt på en gång.

Det gör inte systemen automatiskt säkra. En illa utformad behörighetsmodell är fortfarande en illa utformad behörighetsmodell, och deklarativa regler kan vara fel på alla sätt kod kan vara det. Det som försvinner är behovet av att implementera efterlevnaden tusentals gånger var för sig.

Den säkraste säkerhetskoden är den kod en applikation aldrig får chansen att skriva.

Programvaruteknik har jagat återanvändning i decennier, och varje generation höjde enheten. Funktioner återanvänder logik. Bibliotek återanvänder funktioner. Ramverk återanvänder arkitektur. Tjänster återanvänder funktionalitet. Molnplattformar återanvänder infrastruktur. Och sedan avslutar vi ändå jobbet med att skriva ännu en applikation.

Det är den gränsen en plattform flyttar. Den återanvändbara enheten upphör att vara kod och blir förmåga.

Ett system sätter samman dem efter vad organisationen behöver. Plattformsingenjörer bygger och utvecklar förmågorna. Systembyggare monterar dem. AI gör monteringsgränssnittet långt kraftfullare än en inställningssida någonsin var.

Det är Lego på företagsberäkningens nivå, förutom att bitarna inte är visuella komponenter. De är generaliserad körbar semantik.

Det fanns en tid då att ändra vad en maskin gjorde betydde att ändra maskinen. Sedan skildes beteendet från hårdvaran: instruktioner kunde lagras, och en generell maskin kunde göra radikalt olika saker beroende på vad den blev tillsagd. Den separationen gav en av de största utvidgningarna av teknisk förmåga i historien.

Härifrån ser det absurt ut att koda in varje ny verksamhetsapplikation i dedikerad hårdvara. Det går, och det finns fall där specialiserad kisel är precis rätt, men ingen föreslår att tillverka en ny krets för att inköpsflödet ändrats. Beteendet hör hemma på en högre nivå.

Samma fråga gäller nu applikationskoden. Varför är varje verksamhetssystem i praktiken inbränt i sin egen implementation?

Källkod är oändligt mycket följsammare än ett kretskort, men mönstret rimmar. Det önskade beteendet binds till en artefakt, och den artefakten skaffar sig beroenden, versioner, arkitektur, driftsättningsmekanik och en egen livscykel. Om en tillräckligt generell körmiljö kan köra systemdefinitionen direkt börjar det se ut som en onödigt lågnivåaktig representation att koda varje system som skräddarsydd applikationskod.

Vilket är därför en jämförelse med steget från C++ till C# underskattar skiftet. Den närmare liknelsen är separationen av programvaran från maskinen. Plattformen blir den generella maskinen, och det deklarativa systemet är det den kör.

Git är utomordentligt bra på det det gör, och det är bra på det därför att källkoden för närvarande är applikationens auktoritativa representation. Ändra det och verktygsfrågan öppnas på nytt.

Versionshantering betyder fortfarande något. Det gör historik, spårbarhet, testning, återställning och samarbete också. Inget av det kräver att systemet finns som filer fulla av programspråkssyntax, och vi bör akta oss för att ta dagens utvecklingsverktyg för permanenta egenskaper hos databehandling.

Ett framtida system skulle kunna bära en långt rikare historik än dagens applikationer utan att innehålla någon applikationskällkod alls, därför att varje strukturell ändring kan registreras semantiskt. ”La till ett attesteg för transaktioner över en miljon kronor” säger mer än en diff över tolv filer. ”Gav regionchefer åtkomst till de här objekten” säger mer än en ändring i behörighetsmellanvaran.

Systemet börjar beskriva sin egen utveckling på verksamhetens språk, vilket också är språket verksamheten kan bråka på.

Och AI slipper sluta sig till verksamhetsinnebörd ur implementationsdiffar. Innebörden ligger där.

Det finns en liten paradox i hur branschen använder de här modellerna. Vi räcker extremt kapabla system en utomordentligt stökig miljö, och gratulerar dem sedan till att de klarar sig.

En mogen kodbas är miljontals tokens spridda över språk, ramverk, konventioner, inaktuella kommentarer, historiska olyckor och implementationsdetaljer. Innan en modell tryggt kan ändra något måste den rekonstruera det begreppsliga systemet ur de bevisen. Sedan ber vi den lägga till en funktion.

En deklarativ plattform vänder på situationen. Den begreppsliga strukturen sluts inte till, den är angiven. Objekt är objekt, relationer är relationer, behörigheter är behörigheter, arbetsflöden är arbetsflöden.

Det gör inte resonemanget lätt. Det gör resonemanget relevant — lagt på att förstå organisationen i stället för på en annan ingenjörs implementationsbeslut för fyra år sedan.

När system väl är strukturerade körbara modeller kan agenter göra något annat än att skriva kod. De kan arbeta på systemet självt.

En agent kan läsa en process och hitta steget som bara finns för att avisera någon som inte längre läser. Den kan lägga märke till två avdelningar som samlar in samma information oberoende av varandra, eller en regel som tyst motsäger en annan regel tre processer bort. Den kan föreslå automatisering där ett beslut är deterministiskt, och märka ut ställena där mänskligt omdöme faktiskt gör ett jobb.

Kör det fortlöpande och du har något som resonerar om glappet mellan de utfall en organisation vill ha och systemen den använder för att åstadkomma dem.

En kodassistent frågar vilken kod den ska skriva. Det här frågar vilket system som borde finnas. Den andra frågan är där pengarna finns.

Software as a Service förändrade distributionen. I stället för att varje organisation installerar och driver sin egen programvara driver en leverantör en fortlöpande förbättrad produkt åt tusentals kunder, och den ekonomin är svår att argumentera mot.

Den kom med en kompromiss. Organisationen anpassar sig till produkten: leverantören äger modellen, kunderna konfigurerar runt den, och när ett verkligt behov avviker från leverantörens antaganden blir anpassningen dyr eller helt enkelt nekad.

Egenutveckling ger det omvända bytet. Systemet passar exakt, och nu äger organisationen en skräddarsydd implementation med varje kostnad det innebär. Hela konsultbranscher finns för att hantera det enda valet.

En plattform skiljer de två frågorna åt. Maskineriet standardiseras utan att organisationen standardiseras: tusentals system delar körmiljö, semantik och förmågor samtidigt som de kör olika datamodeller, arbetsflöden, gränssnitt och regler. Det är närmare SaaS-ekonomi med egenutvecklingens passform än någondera sidan av den gamla frågan kan komma.

För en stor klass av verksamhetssystem är köpa eller bygga en fråga ärvd från en lägre abstraktion.

Organisationer ändras oavbrutet. De köper bolag, tar emot nya regelverk, lanserar och avvecklar produkter, flyttar människor mellan roller, reagerar på marknader, förbättrar processer och upptäcker att förra årets antagande nu är fel.

Programvaran har alltid beskattat det. Att ändra organisatoriskt beteende betyder att ändra en implementation: krav insamlade, ärenden skrivna, utvecklare som tolkar, kod ändrad, tester körda, släpp planerade, migreringar genomförda.

Fördröjningen får en följd folk underskattar. En organisation vars system ändras långsamt börjar organisera sig efter programvarans gränser. Den som arbetat i ett stort bolag har sett omkastningen ske — människor som utför en absurd manuell rutin inte för att den är vettig utan för att systemet fungerar så.

Verktyget slutar med att styra organisationen det köptes för att tjäna.

När den organisatoriska semantiken representeras direkt blir organisatorisk förändring systemförändring utan en hel utvecklingscykel emellan. Det är inte utvecklarproduktivitet. Det är skillnaden mellan ett bolag som kan agera på vad det lär sig och ett som lägger det till nästa släpp.

Varje ny abstraktion kommer med någon som utropar yrkets död under den, och utropet har alltid fel. Kompilatorer utplånade inte dem som förstår processorer. Databaser utplånade inte lagringsteknik. Molnet utplånade inte infrastrukturteknik. De färdigheterna koncentrerades, och blev för det mesta svårare.

Detsamma gäller här. Plattformsteknik är mer krävande än applikationsutveckling, inte mindre. Körmiljön måste vara exceptionellt tillförlitlig därför att allt hänger på den. Abstraktionerna måste utformas omsorgsfullt därför att ett misstag sprider sig in i varje system som byggs på dem. Prestandaarbete, säkerhetsarbete och generalisering bär alla oproportionerliga följder.

En plattformsingenjör är ingen förminskad applikationsutvecklare. De bygger maskinen applikationerna kör på.

Det kan behövas färre än de som i dag implementerar samma skärmar i olika bolag. Arbetet som återstår är svårare.

Plus hela kategorier ingen tänkt på. Kod är inte förlegad, och att påstå något annat vore lika dumt som att påstå att elektriciteten gjorde maskinteknik förlegad. Tekniker utplånar sällan de användbara lagren under sig. De ändrar var de lagren sitter.

C++ är fortfarande nödvändigt, och nästan ingen som bygger ett attestflöde skriver C++. Assembler är fortfarande nödvändigt, och ingen föreslår att implementera ett CRM i det för den extra kontrollen.

Frågan var aldrig om koden överlever. Den är om skräddarsydd applikationskod förblir det dominerande sättet att representera verksamhetssystem.

Ingen plattform kommer någonsin att rymma varje förmåga någon behöver. Nya krav dyker upp, och vissa system vill ha beteende plattformen inte kan uttrycka. Att låtsas annat är hur plattformar förtjänar ryktet att ljuga för sina användare.

Rätt svar behandlar gränsen som information. När något genuint nytt kräver kod skriver plattformsingenjörerna den, och sedan ställs den verkliga frågan: går det här att generalisera? Går det blir det en del av plattformen, och det som var en nödutgång blir en byggsten. Går det inte förblir det en engångsföreteelse och alla vet vilken det är.

Det skapar ett spärrhjul. Varje genuint nytt problem som löses i plattformslagret utvidgar vad varje framtida system kan uttrycka utan kod, och den uttrycksfulla gränsen rör sig bara åt ett håll.

Plattformen samlar förmåga i stället för att applikationer samlar skuld.

En skräddarsydd applikation ackumulerar. Fler funktioner, fler beroenden, fler migreringar, fler beslut ingen minns att någon fattat, mer underhållsåtagande. Varje år kostar den mer att behålla och mer att ändra.

En plattform gör tvärtom. Förbättra dataåtkomstlagret och varje system blir snabbare. Förbättra spårbarheten och varje system blir mer spårbart. Rätta tillgängligheten i en gränssnittsbyggsten och varje skärm som använder den ärver rättningen. Lägg till en databasadapter och varje system kan nå en sak till.

Avkastningen på en dags ingenjörsarbete slutar tillhöra en applikation. Traditionell utveckling löser liknande problem lokalt, om och om igen, i kodbaser som aldrig möts. Plattformsutveckling försöker lösa problemklasser en gång, och varje klass som tas bort slutar dyka upp i nästa projekt.

Det ena angreppssättet växer sin underhållsyta. Det andra växer vad nästa system kan göra innan någon skrivit en rad.

Ray Kurzweils lag om accelererande avkastning säger, ungefär, att framsteg går fortare därför att varje framsteg hjälper till att producera nästa. Vad man än anser om de mer ambitiösa förutsägelserna knutna till hans namn är mekanismen synlig överallt i databehandlingen. Bättre datorer hjälper till att konstruera bättre datorer. Bättre programvara hjälper till att bygga bättre programvara. Bättre verktyg hjälper till att bygga bättre verktyg.

AI skärper den loopen, därför att verktyget nu deltar direkt i att göra nästa generation av verktyget. För en plattform har loopen en bestämd form: AI hjälper ingenjörer generalisera förmågor in i plattformen, de förmågorna begränsar rymden framtida AI arbetar i, bättre begränsningar gör resultaten mer tillförlitliga, mer tillförlitlighet låter AI ta sig an mer följdrik komposition, fler system blottar fler mönster, och mönstren visar vad som ska generaliseras härnäst.

Samtidigt fortsätter avstånden mellan abstraktionslagren att krympa. Fysiska mekanismer tog sekler att mogna. Elektriska system omformade industrin under decennier. Databehandlingens abstraktioner kom i allt snabbare generationer. Internet tryckte ihop distributionen, molnet tryckte ihop infrastrukturen, och AI trycker nu ihop det intellektuella implementationsarbetet självt.

Eftersom AI kan hjälpa till att bygga abstraktioner behöver nästa lager inte byggas i mänsklig takt.

Kodproduktionen gick fortare. Abstraktionsproduktionen gick också fortare, och det är den som ändrar taket.

Det mesta av dagens AI-arbete med programvara ber maskiner bete sig som programmerare. Generera filerna. Skriv funktionen. Skapa komponenten. Rätta typfelet. Kör testerna. Öppna pull-begäran. Det är användbart, därför att världen vi har är organiserad kring precis de aktiviteterna.

Det borde ändå slå oss som märkligt att anta att en övermänsklig programvaruintelligens, om vi bygger en, ska tillbringa evigheten med att redigera textfiler för att det var så människor råkade skriva program på nittonhundratalet.

AI behöver inte källkod av de skäl vi behöver den. Den behöver representationer som gör dess resonemang tillförlitligt, och en strukturerad systemmodell är ett bättre gränssnitt för det än ett vidsträckt förvar av implementationsartefakter.

Målet är inte att göra AI extraordinärt bra på att navigera vår historiska röra. Det är att sluta producera röran.

Branschen har lagt decennier på att föra människor närmare datorerna. Vänligare språk. Visuell programmering. Low-code. No-code. Gränssnitt i naturligt språk. Kodassistenter. Var och en av dem behöll samma antagande under sig: någon, eller något, måste fortfarande konstruera applikationen som programvara.

Det mer radikala draget är att skilja människor från implementationen helt. Ekonomichefen resonerar om ekonomi. Logistikspecialisten resonerar om logistik. Regelefterlevnadsexperten resonerar om ramarna. Konsulten resonerar om hur organisationen borde fungera. Plattformsingenjören resonerar om beräkning. AI överbryggar lagren.

Det är vad en abstraktion är till för. Inte att göra alla kapabla att programmera — att göra programmering onödig för det mesta en verksamhet behöver av programvara.

Vi väntar inte på att få veta om det händer. Vi bygger plattformen det kräver.