Gi en stor språkmodell tre stikkpunkter, og den vil levere tilbake et polert produktkravsdokument — komplett med brukerhistorier, akseptansekriterier, kanttilfeller og en profesjonell tone som ville ha tatt en forretningsanalytiker en uke å produsere. Det kommer på minutter, og det leser som om noen tenkte grundig på det. Det gjorde ingen.

Modellen fylte hvert gap mellom dine tre stikkpunkter med troverdig oppfinnelse. Den kjenner ikke brukerne dine, det regulatoriske miljøet ditt, de gamle begrensningene dine, eller den politiske virkeligheten til interessenten som vil drepe prosjektet hvis rapporteringsmodulen ikke samsvarer med hennes mentale modell. Den vet hvordan kravdokumenter vanligvis ser ut, og den produserte ett.

Den samme feilen gjentar seg ett steg tidligere, i produktoppdagelse. Be en LLM om å «forske på markedet» for produktideen din, og den vil gjøre noe farlig: si seg enig med deg. Språkmodeller speiler innramningen av prompten. Spør «hva er markedsmulighetene for X» og du mottar en veltalende sak for X. Utdataene ankommer formatert som forskning — segmenter, trender, konkurrentgap, noen ganger henvisninger — og hallusinerte kilder forblir et uløst problem på tvers av selv de sterkeste modellene, spesielt i flerrundes forskningsstil arbeidsflyter der feilratene stiger kraftig.

Dette er den første mytiske suksessen i den AI-native livssyklusen: en validert produktidé som aldri ble validert. Alt bygget på toppen av den arver feilen.

Be AI om en systemarkitektur og du får en som vinner møtet. Den kompilerer. Prototypen imponerer. Diagrammet er rent nok til å sette foran en CEO. Det det optimaliserer for er prompten — og prompten inneholder nesten aldri tingene som avgjør om en arkitektur overlever kontakt med virkeligheten: samsvarssystemet du opererer under, den faktiske formen på trafikken din, teamets operative modenhet, integrasjonskvirkene til det femten år gamle kjernesystemet du ikke kan erstatte, og de ikke-funksjonelle kravene ingen tenkte å skrive.

Modeller er trent på offentlige mønstre; dine begrensninger er private. Resultatet er arkitektur-som-troverdighet: et design som ligner gode systemer uten å være avledet av systemets behov. Og fordi prototypen virker, forankrer organisasjonen seg på den. Å bygge om fundamentene etter en vellykket demo er politisk dyrt, så gjetningen under demoen blir stille produksjonssystemet.

Hvis de tidligere stadiene feiler stille, er utviklingsstadiet der forskere faktisk har fanget forfallet på kamera — i stor skala. GitClear har analysert strukturerte kodeendringsdata på tvers av hundrevis av millioner endrede linjer siden 2020, som spenner over private bedriftsreposer og store open source-prosjekter. Deres bane leser som en tidslapse av erosjon.

I 2024, for første gang på rekord, oversteg kopiert-limt kode refaktorert kode i commits. Innen deres 2026 «Maintainability Gap»-rapport hadde dupliserte kodeblokker steget 81 % over 2023-nivåer — det høyeste som noen gang er målt — mens flyttet (refaktorert) kode kollapset fra rundt 21 % av endrede linjer i 2022 til under 4 %. Utviklere er nå omtrent fem ganger mer sannsynlig til å duplisere eksisterende logikk enn å konsolidere den. I det siste pre-AI-året løp den preferansen to-til-en i motsatt retning.

Mekanismen er ordinær. En AI-assistent genererer en ny blokk raskere enn den gjenkjenner at en tilsvarende funksjon allerede eksisterer tre filer unna — dens kontekstvindu ser den umiddelbare oppgaven, ikke kodebasens kanon. Hver duplisert blokk pålegger det GitClear kaller en propagasjonsskatt: endre én kopi, og du arver forpliktelsen til å finne og evaluere hvert søsken, på tvers av filer og domener du kanskje ikke kjenner. Multipliser det over en kodebase som vokser med AI-hastighet, og hastighet i dag finansieres stille av gjeld med flytende rente.

Stack Overflows utviklerforskning avdekket en slående statistikk: rundt to tredjedeler av utviklere nevner AI-løsninger som er «nesten riktige, men ikke helt» som den største enkeltfrustrasjonen med verktøyene. Den setningen fortjener mer oppmerksomhet enn den får, fordi nesten-riktig kode er verre enn feil kode.

Feil kode feiler høyt. Den kompilerer ikke, eller den krasjer på første kjøring, og feilen annonserer seg selv før noen er avhengig av den. Nesten-riktig kode kompilerer, passerer en tilfeldig gjennomgang, håndterer lykkestien i demoen, og sendes. Feilen dens — en off-by-one i en grensebetingelse, et misforstått krav, en subtilt feil antagelse om tilstand — dukker opp i produksjon, uker senere, etter at alles tillit til funksjonen allerede er brukt opp og utvikleren som aksepterte forslaget har gått videre.

Testing bør være sikkerhetsnettet som fanger alt ovenfor. I en AI-native arbeidsflyt blir det ofte en del av illusjonen i stedet. Når den samme modellen — eller den samme sesjonen, eller den samme misforståtte spesifikasjonen — produserer både implementasjonen og dens tester, sertifiserer testene implementasjonen heller enn intensjonen.

Hvis den genererte logikken misforsto kravet, koder de genererte testene den samme misforståelsen og består med utmerkelse. Dekningsgrader stiger. Rørledningen lyser grønt. Dashbordet rapporterer hundre prosent bestått mot null prosent forsikring om at produktet gjør det noen faktisk trengte.

Googles DORA-forskningsprogram — den mest omfattende pågående studien av programvareleveringsytelse — fanget konsekvensen på systemnivå. Funnene viste AI-adopsjon assosiert med en beskjeden forbedring i kodekvalitet på individnivå, ved siden av en estimert 7,2 % reduksjon i leveringsstabilitet. Begge funn er sanne på én gang, og forsoningen er leksjonen.

AI gjør det enkelt å produsere mer endring, raskere, i større partier — og tiår med leveringsforskning sier at store partier er tregere å gjennomgå, vanskeligere å resonnere om, og mye mer sannsynlig til å ødelegge noe når de lander. Hver generert blokk kan være marginalt bedre; flommen av blokker gjør systemet mer ustabilt. Lokal optimalisering, global degradering.

Det siste datapunktet er kanskje det mest stille alarmerende. GitClear sporer andelen av kodeendringer som berører kode som er mer enn tolv måneder gammel — konsoliderings-, dokumentasjons- og pensjoneringsarbeidet som holder langlivede systemer sunne. Det tallet har falt omtrent 74 % siden 2023.

Mønsteret det beskriver: team sprinter utover, genererer nye v1-funksjoner med AI-hastighet, mens de eldre lagene av kodebasen kalsifiserer — udokumenterte, ukonsoliderte, i økende grad ueide. Ingenting ser galt ut. Produktet vokser. Så brekker noe gammelt, og organisasjonen oppdager at ingen mennesker har konteksten lenger, og modellen hadde det aldri. Regningen for AI-hastighetsvekst ankommer i år to, adressert til hvem som enn er der.

Ta et skritt tilbake, og de syv stadiene forteller én historie. Hvert steg i livssyklusen produserer nå artefakter som ser ferdige ut: krav som leser komplette, forskning som ligner innsikt, arkitekturer som demoes bra, kode som kompilerer, tester som består, utgivelser som sendes, kodebasen som vokser. AI er en motor for å generere troverdighet — og den er genuint fremragende på det.

Men produktsuksess krever sannhet, ikke troverdighet: krav som noen validerte mot en ekte bruker, arkitektur avledet fra ekte begrensninger, kode som er riktig snarere enn nesten riktig, tester som koder intensjon uavhengig av implementasjon, levering som forblir stabil, og en kodebase noen fortsatt forstår.

Gapet mellom troverdig og sant er der produkter stille avsporer — og faren forsterkes fordi troverdighet føles som fremgang. METR-persepsjonsgapet er ikke en kodingsverktøy-kuriositet; det er den emosjonelle signaturen til hele den AI-native livssyklusen. Alt føles greit helt til det ikke gjør det.

Svaret er ikke mindre AI. Team som trekker seg tilbake fra disse verktøyene gir opp ekte innflytelse, og innflytelsen er genuin — den samme forskningen som dokumenterer risikoene dokumenterer også tunge AI-brukere som meningsfylt oversender sine egne pre-AI-grunnlinjer. Svaret er å nekte komforten mens man beholder akselerasjonen, og det viser seg å være et ingeniørproblem i seg selv.

Hos Aventude har vi truffet de fleste av disse fellene selv. Selvsikker-fiksjon-krav, demo-optimaliserte design, tester som sertifiserte feil atferd — vi møtte dem ikke i et tenkelapper men i live levering. Å overvinne dem er grunnen til at vår AI-native programvareutviklingslivssyklus, AISDLC, er bygget slik den er: ikke som AI boltet på en gammel prosess, men som en tosidig menneskelig–AI samarbeidsmodell med verifisering designet inn i strukturen.

Ingen av disse bremser livssyklusen ned nesten så mye som intuisjon antyder. Det det bremser ned er produksjonen av mytisk suksess — og det er poenget.

Det farligste øyeblikket i AI-drevet produktbygging er når alt føles bra. Å føle seg rask er ikke å være rask. Å se ferdig ut er ikke å være ferdig. Teamene som vinner neste tiår vil ikke være de som genererer mest — de vil være de som fortsatt kan se forskjellen.

Vi har konstruert oss forbi de fleste av disse feilmodusene, og vi er åpne om de vi fortsatt jobber med. Hvis du bygger med AI og vil ha akselerasjonen uten komfortfellen, snakk med oss hos Aventude — vi viser deg hvordan AISDLC fungerer, hva det fanget i vår egen levering, og hva det kunne fanget i din.