“Om AI funnits från början”: Billigare kod gör inte besluten om vad som ska byggas enklare

För det mesta av programvarans historia var den dyra delen att bygga den. Team tillbringade månader med att förvandla idéer till fungerande kod, och den knappheten formade allt om hur arbetet organiserades.

Vägkartor sekvenserades runt den tillgängliga ingenjörskapaciteten; arkitekter tjänade sin plats vid bordet eftersom de förstod system som ingen annan gjorde; produktchefer tillbringade sina veckor med att översätta suddiga affärsbegäran till något en utvecklare kunde agera på. Att skriva programvara var flaskhalsen, och naturligtvis var det där som utväxlingen levde.

Det är inte längre sant, och skiftet hände snabbare än de flesta ingenjörsledare har haft tid att smälta.

AI-kodningsverktyg har kollapsat implementationskostnaden. Så, arbete som tog en grupp av ingenjörer veckor tar nu en agent ett par timmar. Och den uppenbara antagandet var att snabbare byggnad skulle översättas direkt till snabbare värde levererat.

Vad som faktiskt har hänt är dock mer komplicerat: team kan nu producera mer programvara än de vet vad de ska göra med, och det som bromsar dem har tyst flyttat sig någon annanstans.

“Du kan inte applicera AI på en trasig process”, sade Pablo Gamba, chef för teknik Amerika på globala programvara och AI-lösningar startup intive. “Det är som att ge en snabbare skovel till en arbetare. Han kommer att arbeta snabbare, men bara i fel riktning.”

Snabbare exekvering, samma gamla begränsning

Varje större inflexion i teknologi – internet, moln och outsourcing har följt en identisk form. Något som användes för att vara dyrt blev billigt nästan över en natt, och allt som ett företag hade byggt på antagandet av den kostnaden måste rivas ner och byggas om.

Denna gång är det som blir billigare den tillämpade tekniska intelligensen i sig, som råkar vara exakt vad tjänsteföretag och ingenjörsteam har tillbringat årtionden med att ta betalt för, påstår Gamba.

Billigare exekvering gör inte begränsningen försvinna, dock. Den flyttar det bara till någonstans mindre synligt. Kodningsflaskhalsen, till exempel, i migrering uppströms, har påskyndat implementationen, men hindret är nu i kodgranskning. Automatisera kodgranskning och det dyker upp i testning och distribution; automatisera det också, och till slut hamnar det på de människor som skriver specifikationerna som agenterna arbetar från.

Eftersom en agent bara kan bygga vad som har beskrivits tillräckligt exakt för att agera på utan att gissa.

Det är fällan som många team går in i just nu, ofta utan att märka det. Om du kan bygga nästan allt på en bråkdel av den tid det använde ta, ökar kostnaden för att bygga fel, inte ner, eftersom du kommer att upptäcka att du hade fel snabbare och med mer redan skeppat.

En antagande som använde ta långsamt, över veckor av manuell kodning, kan nu bli load-bärande infrastruktur innan någon tänker på att ifrågasätta det. Prioritering, inte rå utmatning, bestämmer om AI-investeringen faktiskt betalar för sig.

I denna paradigm tror Gamba att företag borde spåra inte utvecklingshastighet, utan den fulla cykeln från avsikt till produktion. “Om du förbättrar utvecklingshastighet men QA är din flaskhals, har du bara nått QA snabbare. Sedan fixar du QA och flaskhalsen flyttar till kraven”, sade han.

Siffrorna stöder honom också. Fortune 50-företag som använder AI-assisterad utveckling skeppar commits 3-4 gånger snabbare än sina peer, enligt forskning från Cloud Security Alliance, men introducerar nya säkerhetsfynd vid ungefär tio gånger högre hastighet.

Hastighet utan en tydlig destination, i denna mening, slösar inte bara bort ansträngning; den förvärrar risken snabbare än de flesta säkerhetsteam kan hålla jämna steg med.

Få kraven på språk som AI faktiskt kan utnyttja

Om definitionen är där den verkliga begränsningen nu sitter, är lösningen inte mer dokumentation. Det är annan dokumentation, skriven i en form som ett AI-system kan exekvera mot utan att fylla i luckor på egen hand.

Det betyder att pensionera kravdokumentet skrivet för en människa att tolka med omdöme och ersätta det med strukturerade acceptanskriterier, explicita domänmodeller och kontrakts tester som stavar ut vad en funktion borde aldrig göra lika tydligt som vad den borde.

Agenter, efter allt, fyller luckor på samma sätt som en junior ingenjör kan, med en självsäker gissning. Skillnaden är att den senares gissning kommer inlindad i någon tveksamhet, en flagga till en senior kollega, en känsla av att något kan vara fel.

En agents gissning ser inte ut så. Den dyker upp som ren, flytande, fullständig kod, och det finns ingen hänsyn i den, även när den är fel.

Att skriva en specifikation tillräckligt exakt för att överleva den luckan börjar kännas mindre som att utarbeta en produktbeskrivning och mer som att utarbeta ett kontrakt. Du namnger varje aktör, kartlägger varje tillståndsövergång systemet är tillåtet att göra, och tar hänsyn till kanthändelserna istället för att tyst lämna dem till den lyckliga vägen, på det sätt som de flesta kravdokument fortfarande gör.

Team som behandlar detta som en dokumentationsuppgift lär sig det hårda sättet att vag intention bara producerar vag programvara i maskinens hastighet.

De team som faktiskt fångar produktivitetsvinster är de som behandlar sådan specskrivning som sin egen ingenjörsdisciplin, med samma versionskontroll, granskningscykler och testrigor som användes för att reservera koden i sig.

I Gambas ord, AI-nativ är inte tillåtelse att hoppa över process, utan en krav att designa om från scratch. “Många organisationer försöker applicera AI på gamla processer. Det är inte transformation. AI-nativa organisationer börjar med en annan fråga: om AI existerade från början, hur skulle vi designa denna process idag?”

Backlog-chefer, kuratorer av intention

Produkt, arkitektur och ingenjörskap använde att köra som tre separata funktioner med rena överlämningar mellan dem: produkt bestämmer vad som ska byggas, arkitektur bestämmer hur, ingenjörskap skeppar det.

När implementationen blir billig och snabb, blir dessa överlämningar den långsammaste delen av hela kedjan. Vad som slutligen betyder här är vem som kan hålla hela bilden på en gång, översätta intention till något en agent kan exekvera, och fånga en dålig antagande innan det blir skeppat kod som ingen ville ha.

Den omkonstruktionen formar tyst vem som gör definitionen, och vad jobbet faktiskt är längre.

“Tänk på vad som händer med rollen som programvaruutvecklare. De är inte längre bara skriver kod. De övervakar agenternas utmatning, definierar specifikationer, förbereder tester, validerar resultat. Det är en sammanslagning av vad som använde vara tre separata roller i en”, sade Gamba.

Med andra ord, vad som är värdefullt nu är inte att veta hur man skriver en biljett eller kör en sprint. Det är att veta vad “bra” ser ut innan arbetet ens börjar, att kunna skilja på vad som är intellektuellt intressant och vad kunder faktiskt behöver, och att ha modet att döda en idé snabbt när den tydligt inte klarar den ribban.

De är bedömningar som använde fördelas över en produktchef, en arkitekt och en teknisk ledare som jämför anteckningar. Alltmer, landar de på vem som är närmast att definiera arbetet från början.

Och det är också värt att komma ihåg: ingen av detta gör att titlarna försvinner. Men linjerna mellan dem blir svårare att försvara, medan de människor som trivs i den suddiga gränsen är de som agerar som kuratorer av intention.

Snabb exekvering utan skyddsräcken är inte en seger

Det finns en risk som är lätt att förlora ur sikte när intentionen är tydlig och AI-pipelinen faktiskt fungerar: snabb, väldefinierad exekvering kan fortfarande introducera fel som en långsammare, mer mänsklig-mediad process skulle ha fångat nästan av en slump.

Siffrorna här är inte ens i närheten. Veracodes vår 2026-testning över ledande modeller fann att endast 55% av kodgenereringsuppgifter producerade säker utmatning när ingen explicit säkerhetsvägledning tillhandahölls, en siffra som knappt har förändrats under två år även om funktionell exakthet har ökat avsevärt.

Det är tydligt att att få syntaxen rätt slutade vara den hårda delen för länge sedan. De bedömningar en mänsklig ingenjör använde för att göra instinktivt medan man skrev, runt säkerhet, efterlevnad och vilka data som borde och inte borde röra vilket system, är de delar som är svåra att ersätta.

Detta betyder att samma rigor som applicerats för att definiera vad som ska byggas måste utsträckas till att definiera vad som är utanför gränserna, såsom efterlevnadsgränser, datahanteringsregler och etiska begränsningar uttryckta med samma omsorg som funktionella krav.

Att lämna dessa implicita och hoppas att en agent infererar dem korrekt är samma misstag som att lämna produktkrav vagt och korsa fingrarna så att byggnaden någon gång blir bra.

Vad ledarskap ser ut som

Inget av detta argumenterar mot AI-accelererad utveckling; byggnation har aldrig varit snabbare eller billigare, och det finns ingen möjlighet att stoppa det i flaskan.

Men vad som inte har blivit enklare, och kan ha blivit svårare, är att bestämma med verklig precision vad som är värt att bygga, beskriva det tillräckligt bra för en maskin att exekvera troget, och rita linjerna den inte är tillåten att korsa medan den gör det.

På företagsnivå är det team som drar ifrån som inte har de snabbaste kodagenterna, den delen är tydlig. Det är de som utarbetade, innan deras konkurrenter gjorde, att definitionen alltid skulle vara det svårare problemet – och började behandla det som sådant.