Ge en stor språkmodell tre punkter och den lämnar tillbaka ett polerat produktkravsdokument — komplett med användarberättelser, acceptanskriterier, kantfall och en professionell ton som skulle ha tagit en affärsanalytiker en vecka att producera. Det anländer på minuter och läses som om någon tänkte hårt på det. Ingen gjorde det.

Modellen fyllde varje lucka mellan dina tre punkter med trovärdigt påhitt. Den känner inte dina användare, din regulatoriska miljö, dina äldre begränsningar eller den politiska verkligheten hos intressenten som kommer att döda projektet om rapporteringsmodulen inte matchar hennes mentala modell. Den vet hur kravdokument vanligtvis ser ut, och den producerade ett.

Samma misslyckande upprepas ett steg tidigare, i produktundersökning. Be en LLM att «undersöka marknaden» för din produktidé och den kommer att göra något farligt: hålla med dig. Språkmodeller speglar inramningen av prompten. Fråga «vad är marknadsmöjligheten för X» och du får ett vältaligt fall för X. Utdata anländer formaterat som forskning — segment, trender, konkurrentluckor, ibland citeringar — och hallucinerade källor förblir ett olöst problem även hos de starkaste modellerna, särskilt i flertursforskningsstilsarbetsflöden där felfrekvenserna ökar kraftigt.

Detta är den första mytiska framgången i den AI-nativa livscykeln: en validerad produktidé som aldrig validerades. Allt byggt ovanpå den ärver felet.

Be AI om en systemarkitektur och du får en som vinner mötet. Den kompilerar. Prototypen imponerar. Diagrammet är tillräckligt rent för att sätta framför en VD. Det den optimerar för är prompten — och prompten innehåller nästan aldrig de saker som avgör om en arkitektur överlever kontakt med verkligheten: det regelverk du verkar under, den faktiska formen på din trafik, ditt teams operativa mognad, integrationskrånglet hos det femton år gamla system av rekord du inte kan ersätta, och de icke-funktionella kraven ingen tänkte skriva.

Modeller tränas på offentliga mönster; dina begränsningar är privata. Resultatet är arkitektur-som-trovärdighet: en design som liknar bra system utan att vara härledd från ditt systems behov. Och eftersom prototypen fungerar förankrar sig organisationen på den. Att bygga om grunder efter en lyckad demo är politiskt dyrt, så gissningen under demon blir tyst produktionssystemet.

Om de tidigare stadierna misslyckas tyst är det i utvecklingsstadiet som forskare faktiskt har fångat förfallet på kamera — i stor skala. GitClear har analyserat strukturerade kodändringsdata över hundratals miljoner ändrade rader sedan 2020, som sträcker sig över privata företagsrepon och stora open source-projekt. Deras bana läses som ett tidslapse av erosion.

År 2024, för första gången i rekord, översteg kopierad-klistrad kod refaktorerad kod i commits. I deras rapport «Maintainability Gap» 2026 hade duplicerade kodblock stigit 81 % över 2023-nivåer — det högsta som någonsin mätts — medan flyttad (refaktorerad) kod kollapsade från ungefär 21 % av ändrade rader 2022 till under 4 %. Utvecklare är nu ungefär fem gånger mer benägna att duplicera befintlig logik än att konsolidera den. Det sista pre-AI-året löpte den preferensen två-till-ett i motsatt riktning.

Mekanismen är vardaglig. En AI-assistent genererar ett nytt block snabbare än den känner igen att en likvärdig funktion redan finns tre filer bort — dess kontextfönster ser den omedelbara uppgiften, inte kodbasens kanon. Varje duplicerat block ålägger vad GitClear kallar en propagationsskatt: ändra en kopia, och du ärver skyldigheten att hitta och utvärdera varje syskon, över filer och domäner du kanske inte känner. Multiplicera det över en kodbas som växer med AI-hastighet, och hastighet idag finansieras tyst av skulder med rörlig ränta.

Stack Overflows forskning avslöjade en slående statistik: ungefär två tredjedelar av utvecklare citerar AI-lösningar som är «nästan rätt, men inte riktigt» som den enskilt största frustrationen med verktygen. Den frasen förtjänar mer uppmärksamhet än den får, eftersom nästan-rätt kod är värre än fel kod.

Fel kod misslyckas högt. Den kompilerar inte, eller den kraschar vid första körning, och felet tillkännager sig självt innan någon förlitar sig på det. Nästan-rätt kod kompilerar, klarar en hastig granskning, hanterar lyckostigen i demon och levereras. Dess fel — ett off-by-one i ett gränstillstånd, ett missförstått krav, ett subtilt fel antagande om tillstånd — dyker upp i produktion, veckor senare, efter att allas förtroende för funktionen redan har förbrukats och utvecklaren som accepterade förslaget har gått vidare.

Testning borde vara säkerhetsnätet som fångar allt ovan. I ett AI-nativt arbetsflöde blir det ofta en del av illusionen istället. När samma modell — eller samma session, eller samma missförstådda specifikation — producerar både implementeringen och dess tester certifierar testerna implementeringen snarare än avsikten.

Om den genererade logiken missförstod kravet kodar de genererade testerna samma missförstånd och klarar med utmärkelse. Täckningsgrader stiger. Pipelinen lyser grönt. Dashboarden rapporterar hundra procent godkänt mot noll procent försäkran om att produkten gör vad någon faktiskt behövde.

Googles DORA-forskningsprogram — den mest omfattande pågående studien av programvarulevereringsprestation — fångade konsekvensen på systemnivå. Dess fynd visade AI-adoption associerad med en blygsam förbättring av kodkvalitet på individnivå, vid sidan av en uppskattad 7,2 % minskning av leveransstabilitet. Båda fynden är sanna på en gång, och försoningen är lärdomen.

AI gör det lätt att producera mer förändring, snabbare, i större batchar — och decennier av leveransforskning säger att stora batchar är långsammare att granska, svårare att resonera kring och mycket mer benägna att bryta något när de landar. Varje genererat block kan vara marginellt bättre; floden av block gör systemet skakigare. Lokal optimering, global degradering.

Den sista datapunkten är kanske den mest tyst alarmerande. GitClear spårar andelen kodändringar som berör kod äldre än tolv månader — konsoliderings-, dokumentations- och pensioneringsarbetet som håller långlivade system friska. Den siffran har sjunkit ungefär 74 % sedan 2023.

Mönstret det beskriver: team sprintar utåt, genererar nya v1-funktioner i AI-hastighet, medan de äldre lagren av kodbasen förstenas — odokumenterade, okonsoliderade, alltmer ägarslösa. Ingenting ser fel ut. Produkten växer. Sedan går något gammalt sönder, och organisationen upptäcker att ingen människa håller kontexten längre, och modellen gjorde det aldrig. Notan för AI-hastighetstillväxt anländer år två, adresserad till vem som än är kvar.

Ta ett steg tillbaka och de sju stadierna berättar en historia. Varje steg i livscykeln producerar nu artefakter som ser klara ut: krav som läses kompletta, forskning som liknar insikt, arkitekturer som demoas bra, kod som kompilerar, tester som klarar, releases som levereras, kodbasen som växer. AI är en motor för att generera trovärdighet — och den är genuint utmärkt på det.

Men produktframgång kräver sanning, inte trovärdighet: krav som någon validerade mot en riktig användare, arkitektur härledd från riktiga begränsningar, kod som är rätt snarare än nästan rätt, tester som kodar avsikt oberoende av implementering, leverans som förblir stabil och en kodbas som någon fortfarande förstår.

Gapet mellan trovärdigt och sant är där produkter tyst spårar ur — och faran förstärks eftersom trovärdighet känns som framsteg. METR-uppfattningsgapet är inte en kodningsverktygs-kuriositet; det är den emotionella signaturen av hela den AI-nativa livscykeln. Allt känns bra precis tills det inte gör det.

Svaret är inte mindre AI. Team som drar sig tillbaka från dessa verktyg ger upp verklig hävstång, och hävstången är genuin — samma forskning som dokumenterar riskerna dokumenterar också att tunga AI-användare meningsfullt levererar mer än sina egna pre-AI-baslinjer. Svaret är att vägra bekvämligheten medan man behåller accelerationen, och det visar sig vara ett ingenjörsproblem i sig.

På Aventude har vi själva hamnat i de flesta av dessa fällor. Självsäker-fiktion- krav, demo-optimerade designer, tester som certifierade fel beteende — vi stötte på dem inte i en tanketext utan i live-leverans. Att övervinna dem är anledningen till att vår AI-nativa programvaruutvecklingslivscykel, AISDLC, är byggd som den är: inte som AI bultad på en gammal process, utan som en dubbelriktad mänsklig–AI samarbetsmodell med verifiering designad in i sin struktur.

Inget av detta bromsar livscykeln så mycket som intuition antyder. Det det bromsar är tillverkningen av mytisk framgång — och det är poängen.

Det farligaste ögonblicket i AI-driven produktutveckling är när allt känns bra. Att känna sig snabb är inte att vara snabb. Att se klar ut är inte att vara klar. De team som vinner nästa decennium kommer inte att vara de som genererar mest — de kommer att vara de som fortfarande kan se skillnaden.

Vi har konstruerat oss förbi de flesta av dessa felmodi, och vi är öppna om de vi fortfarande arbetar med. Om du bygger med AI och vill ha accelerationen utan bekvämlighetsfällan, prata med oss på Aventude — vi visar dig hur AISDLC fungerar, vad det fångade i vår egen leverans och vad det skulle kunna fånga i din.