Hvis AI Eksisterte fra Dag En: Billigere Kode Gjorde Ikke Valget av Hva å Bygge Enklere

For det meste av softwarens historie var den dyre delen å bygge det. Teamene brukte måneder på å omdanne ideer til fungerende kode, og denne knappheten formede alt om hvordan arbeidet ble organisert.

Roadmaps ble sekvensert rundt den tilgjengelige ingeniørkapasiteten; arkitekter tjente sin plass ved bordet fordi de forstod systemer som ingen andre gjorde; produktledere brukte ukene sine på å oversette vage forretningsforespørsler til noe en utvikler kunne handle på. Å skrive software var flaskenhalen, og naturligvis var det der hvor gevinsten lå.

Dette er ikke lenger sant, og skiftet skjedde raskere enn de fleste ingeniørledere har hatt tid til å fordøye.

AI-kodingverktøy har kollapset kostnaden av implementering. Så, arbeid som tok en gruppe ingeniører uker, tar nå en agent noen timer. Og den åpenbare antakelsen var at raskere bygging ville oversettes direkte til raskere verdi levert.

Hva som faktisk har skjedd, er imidlertid mer komplisert: teamene kan nå produsere mer software enn de vet hva de skal gjøre med, og det som bremser dem, har stille og rolig flyttet seg et annet sted.

“Du kan ikke bruke AI på en feilaktig prosess,” sa Pablo Gamba, teknologisjef for Amerika i det globale software- og AI-løsningsselskapet intive. “Det er som å gi en raskere spade til en arbeider. Han vil jobbe raskere, men bare i feil retning.”

Raskere Utførelse, Samme Gamle Begrensning

Hver større vending i teknologi – internett, sky og outsourcing – har fulgt en identisk form. Noe som tidligere var dyrt, ble billig nesten over natten, og alt et firma hadde bygget på antagelsen av den kostnaden, måtte rives ned og bygges opp igjen.

Denne gangen er det applied technical intelligence selv som blir billig, noe som skjer å være akkurat det serviceselskaper og ingeniørteam har brukt året til å fakturere for, hevder Gamba.

Billigere utførelse gjør ikke begrensningen forsvinne, selv om det flytter den til et mindre synlig sted. Kodingflaskenhalen, for eksempel, i migrering oppstrøms, har økt implementeringen, men hindringen ligger nå i kodegjennomgang. Automatiser kodegjennomgang og det viser seg i testing og deploy; automatiser det også, og til slutt lander det på menneskene som skriver spesifikasjonene agentene jobber fra.

Fordi en agent bare kan bygge det som er beskrevet nøyaktig nok til å handle på uten å gjette.

Dette er fellen mange team går inn i nå, ofte uten å merke det. Hvis du kan bygge nesten hva som helst på en brøkdel av tiden det tok tidligere, øker kostnaden av å bygge feil, ikke ned, fordi du vil finne ut du hadde feil raskere og med mer allerede levert.

En antakelse som tidligere dukket opp langsomt, over uker med manuell koding, kan nå bli bærebærende infrastruktur før noen tenker på å spørre det. Prioritering, ikke rå utgang, bestemmer om AI-investeringen faktisk betaler seg.

I denne paradigmen mener Gamba at selskaper bør spore ikke utviklingshastighet, men hele syklusen fra intensjon til produksjon. “Hvis du forbedrer utviklingshastighet, men QA er din flaskenhalen, har du bare nådd QA raskere. Så fikser du QA og flaskenhalen flytter seg til krav,” sa han.

Tallene støtter ham også. Fortune 50-foretak som bruker AI-assistert utvikling, leverer commits 3-4 ganger raskere enn sine jevnaldrende, ifølge forskning fra Cloud Security Alliance, men introduserer nye sikkerhetsfunn på omtrent ti ganger raskere.

Hastighet uten en klar destinasjon, i denne forstand, ikke bare sparer anstrengelse; det akselerer risiko raskere enn de fleste sikkerhetsteam kan holde tritt med.

Få Krav Inn i et Språk AI Kan Faktisk Utnytte

Hvis definisjon er der den virkelige begrensningen nå sitter, er fikset ikke mer dokumentasjon. Det er annen dokumentasjon, skrevet i en form en AI-system kan utføre mot uten å fylle hull på egen hånd.

Dette betyr å pensjonere kravdokumentet skrevet for en menneskelig tolkning med dømmekraft og erstatte det med strukturerte akseptkriterier, eksplisitte domenmodeller og kontrakttester som spesifiserer hva en funksjon aldri skal gjøre like tydelig som hva den skal.

Agenter fyller usikkerhet på samme måte en junioringeniør kan, med en selvbevisst gjett. Forskjellen er at den sistes gjett kommer pakket med noen tøffel, en flagg til en senior kollega, en følelse av at noe kan være galt.

En agents gjett ser ikke ut som det. Det viser seg som ren, flytende, fullt utformet kode, og det er ingen reserve i det, selv når det er feil.

Å skrive en spesifikasjon nøyaktig nok til å overleve den gapen, begynner å føles mindre som å utarbeide en produktbeskrivelse og mer som å utarbeide en kontrakt. Du navngir hver aktør, kartlegger hver tilstandsovergang systemet er tillatt å gjøre, og tar hensyn til kanttilfellene i stedet for å stille til den lykkelige vei, måten de fleste kravdokumenter fortsatt gjør.

Team som behandler dette som en dokumentasjonskore, lærer den harde måten at vag intent bare produserer vag software i maskinens hastighet.

Teamene som faktisk fanger produktivitetsgevinstene, er de som behandler slik spesifikasjonsskriving som sin egen ingeniørdisciplin, med samme versjonskontroll, gjennomgangssykluser og testrigor som tidligere var reservert for koden selv.

I Gamba’s ord, AI-nativ er ikke tillatelse til å hoppe over prosess, men en krav til å redesigne fra scratch. “Mange organisasjoner prøver å bruke AI på gamle prosesser. Det er ikke transformasjon. AI-nativ organisasjoner starter med en annen spørsmål: hvis AI eksisterte fra dag en, hvordan ville vi designe denne prosessen i dag?”

Backlog Managers, Kuratorer av Intent

Produkt, arkitektur og ingeniør brukte å kjøre som tre separate funksjoner med rene overleveringer mellom dem: produkt bestemmer hva som skal bygges, arkitektur finner ut hvordan, ingeniør leverer det.

Når implementering blir billig og rask, blir disse overleveringene den langsomste delen av hele kjeden. Hva som kommer til å bety noe her, er hvem som kan holde hele bildet på én gang, oversette intent til noe en agent kan utføre, og fange en dårlig antakelse før den blir til levert kode ingen ønsker.

Dette redesignet former nå hvem som gjør definisjonen, og hva jobben faktisk er nå.

“Tenk på hva som skjer med softwareingeniørrollen. De er ikke lenger bare skrivende kode. De overvåker agentenes utgang, definerer spesifikasjoner, forbereder tester, validerer resultater. Det er en sammenføring av hva som tidligere var tre separate roller i én,” sa Gamba.

Med andre ord, hva som er verdifullt nå, er ikke å vite hvordan man skriver en billett eller kjører en sprint. Det er å vite hva “godt” ser ut som før arbeidet overhode starter, å kunne si forskjell på hva som er intellektuelt interessant og hva kundene faktisk trenger, og å ha nerven til å drepe en idé raskt når den ikke klarer den standarden.

Disse dømmekallene som tidligere ble fordelt over en produktleder, en arkitekt og en teknisk leder som sammenligner notater. Økende, lander de på hvem som er nærmest å definere arbeidet fra første sted.

Og det er også verdt å huske: ingen av dette gjør at tittelene forsvinner. Men linjene mellom dem blir harder å forsvare, mens personene som trives i den uskarpe grensen, er de som handler som kuratorer av intent.

Rask Utførelse Uten Guardrails Er Ikke en Seier

Det er en risiko som er lett å miste av syne når intent er klar, og AI-pipeline er faktisk hummende: rask, veldefinert utførelse kan fortsatt introdusere feil en langsommere, mer menneske-mediatorisk prosess ville ha fanget nesten ved en tilfeldighet.

Tallene her er ikke engang nær. Veracodes vårtesting over ledende modeller fant at bare 55% av kodegenereringsoppgaver produserte sikker utgang når ingen eksplisitt sikkerhetsveiledning var gitt, en verdi som knapt har beveget seg i to år, selv om funksjonell nøyaktighet har hoppet betydelig.

Det er klart å få syntaksen riktig sluttet å være den harde delen for lenge siden. Dømmekallene en menneskelig ingeniør tidligere gjorde instinktivt mens de skrev, rundt sikkerhet, overholdelse og hva data skulle og ikke skulle berøre, er delene som er harde å erstatte.

Dette betyr at samme rigor som brukes til å definere hva som skal bygges, må utvides til å definere hva som er utenfor grensene, som overholdelsesgrenser, datahåndteringregler og etiske begrensninger spesifisert med samme omsorg som funksjonelle krav.

Å la disse være implisitte og håpe at en agent inferer dem korrekt, er samme feil som å la produktkrav være vage og krysse fingrene for at byggingen noen gang blir bra.

Hva Ledelse Ser Ut

Ingenting av dette taler mot AI-akselerert utvikling; bygging har aldri vært raskere eller billigere, og det er ingen måte å sette det tilbake i flasken på.

Men hva som ikke har blitt enklere, og kanskje har blitt vanskeligere, er å bestemme med virkelig presisjon hva som er verdt å bygge, å beskrive det godt nok for en maskin til å utføre trofast, og å tegne linjene det ikke er tillatt å krysse mens det gjøres.

På bedriftsnivå er teamene som trekker fremover, ikke de med de raskeste kodeagentene, det er tydelig. Det er de som har funnet ut, før konkurrentene, at definisjon alltid ville være det harde problemet – og startet å behandle det på den måten.