Översikt
Det här dokumentet berättar historien om hur AISDLC konciperades, designades och byggdes på Aventude – tankarna bakom varje fas, logiken bakom varje agent och de principer som formade hur AI och mänskligt omdöme kombineras genom hela processen. Det är inte en produktbroschyr. Det är en ärlig redogörelse för vad det krävde att bygga en mjukvaruutvecklingscykel som är genuint AI-native, noggrant strukturerad och ansvarsfull av design.
Problemet vi satte oss för att lösa
AI har kommit in i mjukvaruutvecklingen som ett verktyg. Vi frågade oss om det kunde vara själva processen.
Den första versionen av frågan som Aventude ställde var: hur använder vi AI för att göra våra team snabbare? Det var fel fråga. Det är den fråga som de flesta ingenjörsorganisationer fortfarande ställer, och den leder till samma destination – en samling AI-assisterade verktyg ovanpå en oförändrad process. Något snabbare. Fundamentalt sett densamma.
Den rätta frågan – den vi till slut kom fram till – var annorlunda: om du skulle designa en mjukvaruutvecklingscykel från grunden idag, med vetskap om vad AI-agenter kan göra, vad skulle du bygga? Inte vilka steg du skulle lägga till AI i. Hur skulle hela saken se ut om AI-kapabilitet var ett designinput snarare än ett tillägg?
Den frågan öppnade upp ett helt annat utrymme. Och den ledde till Aventude AISDLC.
Vad som var trasigt i traditionell utveckling
Innan vi kunde designa något bättre var vi tvungna att vara ärliga om vad som var trasigt. Inte trasigt på ett ovanligt eller exceptionellt sätt – trasigt på det vanliga, ihållande sätt som alla inom ingenjörskonst har lärt sig att arbeta runt. Så vi pratade med alla våra mjukvaruingenjörer, UX-designers, kvalitetsingenjörer, projektledare, arkitekter och produktchefer.
Våra slutsatser:
- Discovery tar för lång tid. Veckor av manuell arkeologi innan någon plan kan ta form. Kodbaser växer, dokumentation driftar, och den faktiska formen på ett system blir något som bara ett fåtal personer fullt ut förstår – om någon alls.
- Antaganden färdas tyst. Från en idé till en arkitektur till en spec till en bygge – den ursprungliga avsikten förlorar trohet vid varje överlämning. Det som anländer vid leverans är sällan exakt vad som föreställdes i början.
- Testning är sekventiell. Bygg först, testa efteråt. Problem som upptäcks sent kostar mer att åtgärda än problem som upptäcks tidigt, och sekventiell testning garanterar sen upptäckt.
- Specifikationer är mänskligt begränsade. Att skriva detaljerade, entydiga specifikationer för varje arbetsuppgift är en av de mest tidskrävande delarna av leveransprocessen. Och de är fortfarande ofta ofullständiga.
- Kvalitet är en fas. I de flesta processer kontrolleras kvalitet i slutet snarare än att byggas in i varje steg. Det är strukturellt baklänges.
Inget av dessa problem är nytt. Ingenjörer har känt till dem i decennier. Det som var nytt var den realistiska möjligheten att lösa dem – inte genom att lägga till AI-verktyg till det befintliga arbetsflödet, utan genom att redesigna arbetsflödet kring vad AI-agenter nu tillförlitligt kan göra. Frågan var inte hur man gör utvecklare snabbare. Det var hur man komprimerar hela processen, inklusive de delar som inte hade något med att skriva kod att göra.
Principerna vi designade kring
Innan den första agenten definierades fastställde vi vad processen måste vara – icke-förhandlingsbart.
AISDLC designades utifrån fem principer. Varje agent, varje grind, varje fas utvärderades mot dem. När ett designbeslut konflikterade med en princip ändrades designen – inte principen.
AI-native, inte AI-förstärkt
Detta var det grundläggande beslutet. AISDLC är inte en traditionell mjukvaruutvecklingsprocess med AI-verktyg insatta i vissa steg. Varje fas är designad kring vad AI-agenter kan producera. Inputs, outputs och strukturen för varje fas definieras av agentkapabilitet, inte anpassade från en pre-AI-modell av hur mjukvara skapas.
Outputs
Implikation: Agenter är inte produktivitetsverktyg. De är strukturella komponenter i livscykeln.
Människor leder. Agenter utför.
De viktigaste besluten inom mjukvaruutveckling är inte de mest automatiserbara. Vad ska vi bygga? Varför bygger vi det på det här sättet? Uppfyller detta output standarden faktiskt? Dessa frågor kräver mänskligt omdöme, och AISDLC är arkitekturerat så att människor fattar dem vid varje kritisk punkt. Agenter kan inte passera en grind utan mänskligt godkännande. Det är strukturellt, inte rådgivande.
Outputs
Implikation: Processens kvalitet beror på kvaliteten på mänskliga beslut, inte frånvaron av dem.
Problem yppas tidigt eller inte alls.
Kostnaden för att åtgärda ett problem inom mjukvaruutveckling är ungefär proportionell mot hur sent det upptäcks. AISDLC är designat så att strukturella problem – felinriktat koncept, fel arkitektur, ofullständig spec – inte kan färdas framåt till senare faser. Varje fas har en grind. Varje grind har en människa. Problem som når grinden löses innan de når nästa fas.
Outputs
Implikation: Kvalitet är inbyggd i strukturen, inte kontrollerad i slutet.
Processen måste fungera i båda riktningarna.
Aventude bygger två typer av mjukvaruprojekt: nya produkter från idé, och modernisering av befintliga system. En enda livscykel behövde fungera för båda – inte som en kompromiss som delvis passade varje typ, utan som en sammanhängande design med en gemensam grund och vägspecifika faser där arbetet genuint skiljer sig.
Outputs
Implikation: De gemensamma faserna är där merparten av ingenjörsarbetet sker. De vägspecifika faserna är där de verkliga skillnaderna hedras.
Inget går förlorat mellan överlämningar.
Ett av de minst synliga men mest skadliga felmönstren inom mjukvaruutveckling är kontextförlust mellan faser. Ett beslut fattat i arkitektur når inte specen. En nyans i specen når inte utvecklaren. AISDLC är byggt på vår AI-plattform specifikt för att den upprätthåller fullständigt sammanhang över alla faser – varje beslut, revision och artefakt är tillgänglig för varje efterföljande agent.
Outputs
Implikation: Processen har minne. Agenter arbetar med hela bilden, inte bara vad som senast lämnades till dem.
Två vägar. En livscykel.
Det första strukturella beslutet: AISDLC är inte en process. Det är två vägar som konvergerar till en gemensam grund.
Aventude bygger nya produkter från grunden, och moderniserar system som redan existerar. Det är genuint olika ingenjörsproblem – inte olika i skala eller komplexitet, utan olika till sin natur. En ny produktutvecklingsprocess måste börja med en idé och göra den verklig. En moderniseringsprocess måste börja med ett system och förstå det innan man bestämmer vad man ska göra med det.
Vi övervägde att bygga två separata livscykler. Vi övervägde att bygga en process som försökte rymma båda. Inget av dem var rätt. Vad vi istället byggde är två distinkta vägar för de faser där arbetet genuint skiljer sig, som konvergerar till en gemensam uppsättning faser för arbetet som är fundamentalt detsamma oavsett vilken väg man kom in från.
Väg 1: Ny produktutveckling
Den centrala utmaningen med att bygga en ny produkt är inte teknisk. Det är att hålla den ursprungliga avsikten intakt genom varje fas i processen. Idéer förlorar trohet. Antaganden färdas tyst. Scope driftar. Produkten som anländer vid leverans är sällan exakt vad som föreställdes, och klyftan mellan dem upptäcks sällan förrän det är dyrt att stänga.
AISDLC Väg 1 är designad för att stänga den klyftan strukturellt. Innan någon arkitektur ritas eller någon kodrad skrivs går idén igenom två distinkta stadier – vardera följt av en mänsklig verifieringsgrind – som gör produkten verklig innan den byggs.
Den nya produktvägen i ett nötskal
Ideationsagent
Förvandlar en råidé till ett strukturerat produktkoncept genom dialog med produktägaren. Fångar problemet, användarna, värdeerbjudandet och de antaganden som fortfarande behöver testas. Agenten ställer de svåra frågorna – de som är lätta att hoppa över i ivern att börja bygga.
Verifiering 1 · PO + Kund
Hårt stopp. Konceptet presenteras för produktägaren och kunden. Inget designas förrän båda formellt bekräftar att det återspeglar vad de vill bygga. Ideationsagenten reviderar så många gånger som behövs.
Visualiseringsagent + UX-ingenjörer
Det bekräftade konceptet blir en synlig produkt – wireframes, högupplösta mockups, annoterade interaktionsflöden – genom samarbete mellan Visualiseringsagenten och Aventudes mänskliga UX-ingenjörer. Agenten genererar i hög hastighet. Ingenjörerna tillför omdöme, tillgänglighetsthänkande och hantverk.
Verifiering 2 · PO + Kund
Hårt stopp. Designerna presenteras iterativt tills båda parter bekräftar dem. När denna grind passeras låses designerna. Det som bekräftades är det som byggs. Scope-drift – den vanligaste anledningen till att produkter besviker – elimineras strukturellt.
Ny produktblåkopia
En komplett produktblåkopia genereras: användartyper, användningsflöden, feature-backlog, story-backlog, arkitekturrekommendationer och tech-stack-vägledning – strukturerat enligt arkitekturprinciper. Byggd framåt från den bekräftade visionen. Förd in i de gemensamma faserna utan förlust.
Väg 2: Kodbasövertagande och modernisering
Den centrala utmaningen med att modernisera ett befintligt system är inte koden. Det är att veta vad man faktiskt börjar från. Kodbaser ackumuleras. Dokumentation driftar från verkligheten. Systemet som existerar är sällan det system som någon tror existerar, och varje arkitektoniskt beslut fattat på falska antaganden propagerar den falskheten framåt.
AISDLC Väg 2 börjar med att eliminera det problemet helt. Innan någon mänsklig arkitekt fattar något beslut om vad systemet ska bli, producerar Kodövertagandeagenten en komplett, strukturerad bild av vad det faktiskt är – direkt från repositoriet, utan att något filtrerats genom selektivt minne eller föråldrad dokumentation.
Kodbasövertagandevägen i ett nötskal
Kodövertagandeagent
Läser hela repositoriet vid anslutning. Identifierar användartyper från autentiseringsvakter och rollannoteringar. Kartlägger funktioner från routedefinitioner och kontrollerslogik. Spårar alla integrationspunkter. Lyfter fram hela tech-stacken. Analyserar kodbasisens strukturella hälsa. Producerar en komplett, strukturerad produktblåkopia inom en timme – utan att något går förlorat i översättningen.
Arkitekt + PO-granskning · Mänsklig grind
Den mänskliga arkitekten och produktägaren granskar blåkopian med kunden. De bekräftar att bilden är korrekt, noterar var den överraskar dem, och inleder samtalet om vad som behöver förändras – och varför.
Strategisk avsikt · Mänskligt beslut
Arkitekten och PO definierar den strategiska avsikten – anledningen till förändring och det önskade utfallet. Molntransformation. Skalbarhetsfixar. Mikrotjänstmigrering. UX-uppgradering. Avsikten formar varje efterföljande arkitektoniskt och leveransbeslut. Om avsikten är UX aktiveras Visualiseringsagenten för en parallell design- och verifieringsväg innan ingenjörsarbetet börjar.
Arkitektagent: Gapanalys + Färdplan
Arkitektagenten kör en formell gapanalys – jämför nuläget med målläget, kartlägger risker och beroenden, och föreslår en målarkitektur och sekvenserad färdplan med en arbetsuppdelningsstruktur ned till minsta exekverbara enhet. Varje förslag utforskas och förfinas genom konversation med den mänskliga arkitekten tills planen är solid. Inget låses förrän arkitekten säger det.
Plattformen AISDLC körs på
AISDLC krävde en plattform för att bygga AI-agenter.
I takt med att designen av AISDLC mognade stod det klart att ingen befintlig AI-plattform kunde stödja vad vi behövde. Kraven var specifika: multi-agentorkestrering med strukturerade överlämningar, dubbelriktad feedback över alla faser, persistent kontext över hela livscykeln, och human-in-the-loop-grindar som var strukturella snarare än rådgivande.
Generella AI-plattformar byggdes för enkelvänds- eller kort-kontextinteraktioner. De var inte designade för kraven hos ett flerstegs-, fler-agent-ingenjörsarbetsflöde där outputen från Fas 1 måste vara tillgänglig och intakt i Fas 4, och där ett mänskligt beslut i Fas 2 måste begränsa vad en agent kan göra i Fas 3.
Det är inte bara en AI-agentisk plattform – det är ett produktbyggande OS.
Det fungerar som det centrala intelligenslagret för produktingenjörsarbete, grundat i den enda källan till sanning: själva kodbasen.
Genom att kontinuerligt förstå arkitektur, implementation, beroenden och ingenjörskontext blir det den operativa hjärnan bakom hela mjukvaruutvecklingscykeln. Aventudes AISDLC-agenter är byggda ovanpå det och utnyttjar denna grundläggande intelligens för att möjliggöra autonoma ingenjörsarbetsflöden, kontextuellt beslutsfattande och skalbar produktleverans.
Vad vår plattform tillhandahåller
Multi-agentorkestrering
Agenter i AISDLC är inte oberoende verktyg som råkar användas i sekvens. De samarbetar, överlämnar och i vissa konfigurationer kontrollerar varandras arbete – Testagenten som kör mot Devagentens output i realtid är ett exempel. Det tillhandahåller orkestreringslagret som gör detta möjligt.
Persistent kontext över faser
Varje beslut, revision och artefakt producerad i varje fas är tillgänglig för varje efterföljande agent. Specagenten vet vad Arkitektagenten beslutade. Devagenten vet vad Specagenten specificerade. Inget går förlorat mellan överlämningar – vilket är ett av de vanligaste och minst synliga felmönstren inom mjukvaruleverans.
Dubbelriktade feedbackslingor
AISDLC är inte ett vattenfall med AI-agenter. Varje fas är ansluten i båda riktningarna. Output som inte uppfyller standarden flödar tillbaka uppströms – aldrig framåt – så kvalitetsgrindar aldrig kringgås. Det upprätthåller detta riktningsvis på plattformsnivå.
Human-in-the-loop av arkitektur
De mänskliga beslutsgrindarnas i AISDLC är inte konventioner eller bästa praxis. De är strukturella funktioner i vår plattform. En agent kan inte gå förbi en grind utan en mänsklig åtgärd. Detta är inte konfigurerbart. Det är den ansvarsfulla ingenjörsgarantin som AISDLC är byggt på.
Vad vi lärde ossnär vi byggde det
Att bygga AISDLC lärde oss saker vi inte förväntade oss att lära. Några av dem förändrade designen avsevärt.
Verifieringsgrindarnas var det svåraste designproblemet
Den ursprungliga designen hade en verifieringsgrind per väg. Erfarenheten visade att vi behövde två för den nya produktvägen – en efter ideation och en efter visualisering – och att grindarnas behövde vara genuina hårda stopp, inte rekommendationer. Frestelsen att flytta en grind nedströms för att hålla momentum igång är verklig och konstant. Grindens värde är precis dess motstånd mot det trycket.
Vi lärde oss också att kvaliteten på vad som händer vid en grind beror nästan helt på vad som anländer till den. En Ideationsagent som producerar ett vagt eller ofullständigt koncept producerar en grindgranskning som är icke-avgörande. Agenterna och grindarnas är ömsesidigt beroende: bra grindar kräver bra agenter, och bra agenter kräver väldesignade grindar att förankra sina outputs till.
Mänskligt omdöme kan inte ingenjörseras bort, och bör inte vara det
Tidigt i designprocessen fanns det en version av AISDLC som försökte minimera de mänskliga beslutspunkterna i hastighetens intresse. Vi gick bort från detta inte för att det var tekniskt omöjligt utan för att det var konceptuellt fel. Värdet av att ha en mänsklig arkitekt godkänna ett arkitektoniskt beslut är inte beslutet i sig – det är ansvarsskyldigheten som kommer med det. En AI-agent kan inte hållas ansvarig för ett system som misslyckas i produktion. En mänsklig arkitekt kan det.
AISDLC är snabbare än traditionell utveckling inte för att det tar bort människor utan för att det tar bort lågvärdigt mänskligt arbete – manuell discovery, specskrivning, repetitiv QA – och koncentrerar mänsklig uppmärksamhet på de beslut som genuint kräver mänskligt omdöme.
Blåkopian är den viktigaste artefakten i processen
Oavsett om den genereras från en kodbas eller byggs framåt från en idé – är produktblåkopian det dokument som allt annat beror på. En svag blåkopia producerar en svag arkitektur. En svag arkitektur producerar svaga specs. Svaga specs producerar kod som inte gör vad produktägaren avsåg. Processens kvalitet flödar från blåkopians kvalitet.
Denna insikt formade hur mycket arbete vi lade på Kodövertagandeagenten och Ideationsagenten. De är inte discovery-verktyg. De är grunden för varje beslut som följer.
Den parade Dev- och Testmodellen krävde ett nytt sätt att tänka kring hur specs skrivs
Du kan inte köra tester i realtid mot kod som produceras om testfallen inte är skrivna innan bygget börjar. Det låter självklart, men det har en betydande konsekvens: Specagenten måste producera testfall av tillräcklig kvalitet och specificitet för att vara maskinexekverbara – inte bara mänskligt läsbara godkännandekriterier. Detta höjde ribban för vad en spec behövde innehålla, vilket i sin tur höjde ribban för vad Arkitektagenten behövde producera som inputs till Specagenten.
Hela processen är en kedja. Kvaliteten på varje länk begränsar och begränsas av de angränsande länkarna.
Den större bilden
AISDLC är inte det slutgiltiga svaret på hur mjukvara bör byggas med AI. Det är vårt bästa nuvarande svar, designat för att utvecklas.
Vi tror att branschen befinner sig mitt i en övergång som de flesta ingenjörsorganisationer ännu inte fullt ut har kommit till rätta med. AI-verktyg har anlänt snabbare än de processer som borde styra dem. Resultatet är att många team bygger mjukvara snabbare, men inte nödvändigtvis bygger bättre mjukvara – eller bygger den mer ansvarsfullt.
Distinktionen mellan AI-förstärkt och AI-native utveckling är inte semantisk. I en AI-förstärkt process gör AI enskilda steg snabbare men processen behåller sin ursprungliga form – sekventiell, mänskligt tempoanpassad, med samma strukturella felmönster i annan skepnad. I en AI-native process börjar designen från vad AI-agenter tillförlitligt kan producera och arbetar utåt därifrån. Processens form är annorlunda. Felmönstren är annorlunda. Relationen mellan mänskligt och maskinellt beslutsfattande är annorlunda.
AISDLC är Aventudes åtagande till den andra kategorin. Det är inte en produkt-roadmap. Det är ett påstående om hur vi anser att mjukvara bör skapas – ansvarsfullt, noggrant, med människor genuint i kontroll över de beslut som spelar roll och agenter genuint ansvariga för arbetet som inte bör kräva mänsklig tid.
Vad AISDLC inte är
- Det är inte autonomt. Agenter kan inte gå förbi mänskliga grindar. Den mänskliga arkitektens omdöme är strukturellt, inte valfritt, vid varje kritisk punkt.
- Det är inte snabbare genom att ta genvägar. Verifieringsgrindarnas, specgranskningen, arkitektens slutliga godkännande är inte overhead – de är mekanismen genom vilken kvalitet upprätthålls. Hastigheten kommer från att ta bort lågvärdigt arbete, inte från att hoppa över högvärdiga beslut.
- Det är inte ett verktyg eller en plattform. AISDLC är en process. Vår plattform är det den körs på. De två är distinkta. Aventude tillhandahåller båda.
- Det är inte färdigt. Varje projekt lär oss något. Processen kommer att utvecklas. Principerna kommer inte att göra det.