Oversikt
Dette papiret forteller historien om hvordan AISDLC ble konsipiert, designet og bygget hos Aventude, tenkningen bak hver fase, resonnementet bak hver agent, og prinsippene som formet hvordan AI og menneskelig vurdering kombineres gjennom hele prosessen. Det er ikke en produktbrosjyre. Det er en ærlig redegjørelse for hva det tok å bygge en programvareutviklingslivssyklus som er genuint AI-native, strengt strukturert og ansvarlig ved design.
Problemet Vi satte oss for å løse
AI har kommet inn i programvareutvikling som et verktøy. Vi spurte oss selv om det kunne være prosessen selv.
Den første versjonen av spørsmålet som Aventude stilte var: hvordan bruker vi AI for å gjøre teamene våre raskere? Det var det gale spørsmålet. Det er spørsmålet som de fleste ingeniørorganisasjoner fortsatt stiller, og det fører til samme destinasjon — en samling AI-assisterte verktøy som ligger på toppen av en uendret prosess. Litt raskere. Fundamentalt sett det samme.
Det rette spørsmålet, det vi til slutt kom fram til, var annerledes: hvis du designet en programvareutviklingslivssyklus fra bunnen av i dag, vet du hva AI-agenter kan gjøre, hva ville du bygget? Ikke hvilke trinn ville du lagt AI til. Hva ville hele tingen se ut som hvis AI-kapabilitet var en designinnsats i stedet for et tilleggsprodukt?
Det spørsmålet åpnet opp et helt annet rom. Og det førte til Aventude AISDLC.
Hva som var brutt i tradisjonell utvikling
Før vi kunne designet noe bedre, måtte vi være ærlig om hva som var brutt. Ikke brutt på en uvanlig eller eksepsjonell måte, brutt på den ordinære, vedvarende måten som alle i ingeniørfag har lært å jobbe rundt. Så vi snakket med alle programvare-ingeniørene våre, UX-designerne, kvalitetsingeniørene, prosjektlederne, arkitektene og produktlederne.
Våre funn:
- Oppdagelse tar for lang tid. Uker med manuell arkeologi før noen plan kan dannes. Kodebaser vokser, dokumentasjon avviker, og den faktiske formen på et system blir noe bare noen få mennesker fullt ut forstår, hvis noen gjør det.
- Forutsetninger reiser stille. Fra en idé til en arkitektur til en spesifikasjon til en bygging, mister den opprinnelige hensikten oppløsning ved hver overdragelse. Hva som ankommer ved levering er sjelden akkurat det som ble imaginert ved starten.
- Testing er sekvensielt. Bygg først, test etterpå. Problemer oppdaget sent koster mer å fikse enn problemer oppdaget tidlig, og sekvensielle tester garanterer sen oppdagelse.
- Specs er menneske-paced. Å skrive detaljert, entydig spesifikasjoner for hvert arbeidsemne er en av de mest tidskrevende delene av leveringsprosessen. Og de er fortsatt ofte ufullstendige.
- Kvalitet er en fase. I de fleste prosesser sjekkes kvalitet ved slutten i stedet for å bygges inn i hvert trinn. Det er strukturelt bakover.
Ingen av disse problemene er nye. Ingeniører har visst om dem i tiår. Det som var nytt var den realistiske muligheten til å løse dem, ikke ved å legge AI-verktøy til den eksisterende arbeidsflytene, men ved å omforme arbeidsflytene rundt hva AI-agenter nå pålitelig kan gjøre. Spørsmålet var ikke hvordan å gjøre utviklere raskere. Det var hvordan å komprimere hele prosessen, inkludert delene som ikke hadde noe med å skrive kode å gjøre.
Prinsippene Vi designet rundt
Før den første agenten ble definert, etablerte vi hva prosessen måtte være, ikke omsettelig.
AISDLC ble designet fra fem prinsipper. Hver agent, hver port, hver fase ble evaluert mot dem. Når en designbeslutning kom i konflikt med et prinsipp, endret designet seg, ikke prinsippet.
AI-native, ikke AI-augmentert
Dette var den grunnleggende beslutningen. AISDLC er ikke en tradisjonell programvareutviklingsprocess med AI-verktøy satt inn i bestemte trinn. Hver fase er designet rundt hva AI-agenter kan produsere. Innsatser, resultater og struktur for hver fase er definert av agent-evne, ikke tilpasset fra en pre-AI-modell av hvordan programvare lages.
Utganger
Implikasjon: Agenter er ikke produktivitetsverktøy. De er strukturelle komponenter i livssyklusen.
Mennesker leder. Agenter utfører.
De viktigste beslutningene i programvareutvikling er ikke de mest automatiserbare. Hva skal vi bygge? Hvorfor bygger vi det på denne måten? Oppfyller dette resultatet faktisk standarden? Disse spørsmålene krever menneskelig vurdering, og AISDLC er arkitektet slik at mennesker gjør dem på hvert kritisk punkt. Agenter kan ikke komme forbi en port uten menneskelig godkjenning. Det er strukturelt, ikke rådgivende.
Utganger
Implikasjon: Prosessens kvalitet avhenger av kvaliteten på menneskelige beslutninger, ikke mangelen på dem.
Problemer vises tidlig eller slett ikke.
Kostnaden for å fikse et problem i programvareutvikling er grovt proporsjonal med hvor sent det blir oppdaget. AISDLC er designet slik at strukturelle problemer, uausrettete konsepter, feil arkitektur, ufullstendige spesifikasjoner, ikke kan reise forover inn i senere faser. Hver fase har en port. Hver port har et menneske. Problemer som når porten blir løst før de når neste fase.
Utganger
Implikasjon: Kvalitet er bygget inn i strukturen, ikke sjekket ved slutten.
Prosessen må fungere i begge retninger.
Aventude bygger to typer programvareavtaler: nye produkter fra ideation, og modernisering av eksisterende systemer. En enkelt livssyklus måtte fungere for begge, ikke som et kompromiss som delvis passet hver enkelt, men som et koherent design med et delt grunnlag og stispisifikke faser hvor arbeidet genuint skiller seg.
Utganger
Implikasjon: De delte fasene er der det meste av ingeniørarbeidet lever. De stispesifikke fasene er der de reelle forskjellene blir hedret.
Ingenting går tapt mellom handlinger.
En av de minst synlige men mest skadelige feilvise modiene i programvareutvikling er konteksttap mellom faser. En beslutning gjort i arkitektur når ikke spesifikasjonen. En nyanse i spesifikasjonen når ikke utvikleren. AISDLC er bygget på vår AI-plattform spesielt fordi det opprettholder full kontekst på tvers av alle faser, hver beslutning, revisjon og artefakt er tilgjengelig for hver etterfølgende agent.
Utganger
Implikasjon: Prosessen har minne. Agenter jobber med det hele bildet, ikke bare hva som sist ble overlevert til dem.
To veier. En livssyklus.
Den første strukturelle beslutningen: AISDLC er ikke en prosess. Det er to veier som konvergerer inn i et delt grunnlag.
Aventude bygger nye produkter fra bunnen av, og moderniserer systemer som allerede eksisterer. Dette er genuint forskjellige ingeniørproblemer, ikke forskjellige i skala eller kompleksitet, men forskjellige i slag. En ny produktutviklingsprosess må starte med en idé og gjøre den virkelig. En moderniseringsprosess må starte med et system og forstå det før du bestemmer hva du skal gjøre med det.
Vi vurderte å bygge to separate livssykluser. Vi vurderte å bygge en prosess som prøvde å sette plass til begge. Ingen var riktig. Hva vi bygget i stedet er to distinkte veier for fasene hvor arbeidet genuint skiller seg, konvergerer inn i et delt sett av faser for arbeidet som er fundamentalt det samme uavhengig av hvilken vei du kom inn fra.
Vei 1: Ny produktutvikling
Den sentrale utfordringen ved å bygge et nytt produkt er ikke teknisk. Det er å holde den opprinnelige hensikten intakt gjennom hver fase av prosessen. Ideer mister oppløsning. Antagelser reiser stille. Omfang driver. Produktet som ankommer ved levering er sjelden akkurat det som ble imaginert, og gapet mellom dem er sjelden oppdaget før det er dyrt å lukke.
AISDLC Vei 1 er designet for å lukke det gapet strukturelt. Før noen arkitektur er tegnet eller noen linje med kode er skrevet, ideen går gjennom to distinkte stadier, hver etterfulgt av en menneskelig verifikasjonsport, som gjør produktet virkelig før det er bygget.
Den nye produktveien på et blikk
Ideation Agent
Gjør en rå idé til et strukturert produktkonsept gjennom dialog med produkteieren. Fanger problemet, brukerne, verdiforslagene og antagelsene som fortsatt trenger testing. Agenten stiller de vanskelige spørsmålene, de som er lette å hoppe over i hastigheten til å begynne å bygge.
Verifisering 1 · PO + Kunde
Hardt stopp. Konseptet presenteres for produkteieren og kunden. Ingenting blir designet før begge formelt bekrefter det reflekterer det de vil bygge. Ideation Agent revideres så mange ganger som nødvendig.
Visualization Agent + UX Engineers
Det bekreftet konseptet blir et synlig produkt, wireframes, high-fidelity mockups, annoterte interaksjonsflyt, gjennom samarbeid mellom Visualization Agent og Aventudes menneskelige UX-ingeniører. Agenten genererer med hastighet. Ingeniørene bringer vurdering, tilgjengelighetstenking og håndverk.
Verifisering 2 · PO + Kunde
Hardt stopp. Designene presenteres iterativt til begge parter bekrefter dem. Når denne porten passerer, er designene frosset. Det som ble bekreftet er hva som blir bygget. Omfangsdrift, den mest vanlige grunnen til at produkter skuffer, elimineres strukturelt.
Vei 2: Kodebasis overtakelse og modernisering
Modernisering av eksisterende systemer krever først å forstå dem. Discovery-agenten kartlegger kodestrukturen, kartlegger avhengigheter, identifiserer kritiske og legacy komponenter, og dokumenterer mønstre og antipatterns som er innebygd. Prosessen produserer en komplett kodemeritkart — en strukturell diagnose av systemet slik det faktisk er, ikke som dokumentasjon sier det burde være.
En arkitekt gjennomgår kartene og fastslår moderniserings-strategi: hvilke komponenter skal omskrives, hvilke skal bevares, hvilke skal erstattes. Strategidokumentet blir den samme type moderne produktplan som ville emerge fra ny produktutvikling — en frosset forståelse av hva som skal gjøres og hvorfor.
Codebase overtakelse veien på et blikk
Discovery Agent
Analyserer kodebasen strukturelt. Kartlegger arkitektur, identifiserer teknisk gjeld, dokumenterer mønstre, avdekker risiko. Produserer et komplett diagnostic dokument som danner grunnlaget for moderniserings-strategi.
Verifisering 1 · Arkitekt
Arkitekten bekrefter kartene er akkurat, identifiserer forbedringsområder, og autoriserer moderniserings-strategi basert på funn.
Modernization Strategy
Basert på diagnostic, dokumenteres moderniserings-planene som separate arbeidsspor: omskrivelser, erstatninger, bevaring. Hver spor blir en moderne produktplan som styrer senere faser.
Verifisering 2 · PO + Arkitekt
Bekrefter strategi, omfang og prioritering før arbeidet begynner.
Plattformen AISDLC kjører på
AISDLC krevde en plattform for å bygge AI-agenter.
Etter hvert som designet av AISDLC modnet, ble det klart at ingen eksisterende AI-plattform kunne støtte det vi trengte. Kravene var spesifikke: multi-agent orchestration med strukturert handoffs, toveis tilbakemelding på tvers av alle faser, vedvarende kontekst på tvers av hele livssyklusen, og menneskelig-i-løkke porter som var strukturelle i stedet for rådgivende.
Generelle AI-plattformer ble bygget for enkelttur eller kortkontekst interaksjoner. De var ikke designet for kravene fra en multi-fase, multi-agent leveringsprosess som måtte opprettholde full kontekst og støtte komplekse verifikasjoner ved hvert gatekryss.
Vi bygde vår egen plattform
Den resultaten er en intern plattform — en proprietær agent orchestration engine — designet spesifikt for AISDLC. Den håndterer multi-phase workflows, vedvarende kontekst, human gates, feedback loops, versioning av artefakter og complete observability på tvers av hver fase.
Plattformen er ikke generell formål. Det er bygget rundt strukturen i AISDLC, og det er det som gjør det kraftig. Hvert design-valg reflekterer leksjonene fra å bygge prosessen selv.
Hva vår plattform gir
Multi-phase Orchestration
Hver fase er en separat arbeidsenhet med inndata, utdata, og verifisering. Agenter kjører sekvensielt eller parallelt som arbeidet dikterer.
Full Context Persistence
Hver beslutning, hver versjon, hver artefakt er tilgjengelig for hver etterfølgende fase. Agenter jobber aldri med delvis informasjon.
Human Gates as Structural
Mennesker godkjenner eller avslår ved konfigurerte kritiske punkter. Agenter kan ikke fortsette uten menneskelig signering.
Bidirectional Feedback
Når senere faser identifiserer problemer, kan de rute tilbake til tidligere faser med detalj, og tidligere faser revisjoner i kontekst.
Complete Observability
Hvert trinn, hver agent-beslutning, hver menneskelig handling er logget og gjøres transparent til interessenter.
Versioning and Rollback
Hver fase kan versjoneres uavhengig. Hvis senere arbeid avsløre problemer, kan tidligere stadier rulles tilbake og revideres uten å miste senere arbeid.
Hva vi lærteVed å bygge den
Å bygge AISDLC lærte oss ting vi ikke forventet å lære. Noen av dem endret designet betydelig.
Verifikasjonsportene var det vanskeligste designproblemet
Vi startet med antagelsen om at hvis vi bare kunne automatisere hver fase, ville prosessen være rask. Realiteten var annerledes. Gater må gjøres av mennesker, og menneskelig review tar tid. Det vi ikke forstod var at kostnaden ved å gjøre review bredt (få mennesker, mange gjennomganger) var høyere enn kostnaden ved å gjøre den strukturelt (mange mennesker, fokuserte gjennomganger).
Vi endte opp med et design der hver gate har en dedikert menneskelig rolle, og hver rolle er ansvarlig for én type beslutning. Arkitekten godkjenner arkitektur. Produkteieren godkjenner produktmatch. QA-leder godkjenner test-dekning. Dette gjør hver gjennomgang raskere fordi hver person jobber innenfor sitt domenekunnskap.
Menneskelig vurdering kan ikke bli engineered ut, og bør ikke
Vi forsøkte å designe automatisering for hver mulig gate. Noen av dem fungerte. Noen av dem feilet. Vi fant raskt at de gater som trengte mest menneskelig vurdering — "gjør dette systemet møte standarden?", "gjør denne moderniserings-strategien mening?" — var portene som ville gjøre eller bryte tilliten på prosessen.
Nåværende design anerkjenner dette. Mennesker er ikke bottlenecks som skal elimineres. De er det strukturelle veivektet som prosessen bygges rundt. Agenter forberederer. Mennesker godkjenner. Denne separasjonen av blikk er det som holder prosessen både rask og ansvarlig.
Kontekst opprettholde eller dø
Uten full kontekst opprettholding på tvers av fasene, gjenoppdager agenter samme informasjon gjentatte ganger. En arkitektur-beslutning fra fase 2 må være kjent til fase 5. Et krav som ble nevnt i fase 3 må være tilgjengelig til fase 7. Vi oppdaget at kontekst-opprettholding var ikke en optimalisering. Det var en grunnleggende nødvendighet.
Vi bygde plattformen rundt persistent kontekst som første-klasse designbeslutning. Hver agent har tilgang til hele historien av hver tidligere fase. Agenter produserer ikke bare resultater. De legger til historikk. Den kumulative konteksten blir det som gjør senere faser smarter.
Feedback loops må være toveis
Vi designet initialt AISDLC som lineær: fase 1 → fase 2 → fase 3 → levering. Det holdt ikke i praksis. Når test-fasen avdekket problemer, måtte de rute tilbake til arkitektur eller spec. Da måtte vi håndtere revidert arbeid videre fremover. Toveis feedback ble viktig.
Nåværende design tillater hvilken som helst fase å revurdere tidligere arbeid med detaljert grunngiving, og tidligere faser revisjoner i full kontekst. Det er ikke sekvensielt. Det er en iterativ loop som lukkes når problemer løses, ikke når en dato nås.
Det større Bildet
AISDLC er ikke det endelige svaret på hvordan programvare bør bygges med AI. Det er vårt beste gjeldende svar, designet for å evolusere.
AISDLC er en gjennomtesting av hypotesen: hvis du bygget en programvareutviklingsprocess fra bunnen av i dag, med AI som et designinnsats i stedet for et verktøy, hva ville det se ut som? Prosessen som oppstår er radikal sammenlignet med hvordan programvare for tiden bygges. Men det er ikke radikal sammenlignet med hva som teknologisk er mulig.
Hva kommer neste? Muligens AI-agenter som lærer fra tidligere mønstre og blir bedre på sine særlige roller over tid. Muligens verktøy for å dele designene med andre organisasjoner som ønsker å adaptere. Muligens ny innsikt fra å kjøre samme prosess på hundrevis av prosjekter.
Hvem som helst kan kopiere en prosess. Det som er vanskelig — og det som betyr noe — er å bygge en kultur der prosessen faktisk fungerer. Å ha mennesker som godkjenner riktig. Å bygge observability som mennesker faktisk bruker. Å designe omgivelsene slik at agenter og mennesker faktisk hjelper hverandre.
Hva AISDLC er ikke
- Det er ikke en magic bullet. Hvis grunnproblemet ditt er dårlig folk, dårlig ledelse eller uklare krav, vil AISDLC ikke løse det. Den forverrer det muligens synlig.
- Det er ikke modelklar. Denne prosessen er designet rundt hvordan Aventude jobber, hvordan vi tenker, hvilke roller vi har. Andre organisasjoner må adaptere det, ikke bare ta det.
- Det er ikke sekkefull av verktøy. AISDLC er ikke et sett av implementeringer. Det er en struktur. Organisasjoner må bygge eller velge verktøy som passer den strukturen.
- Det er ikke det endelige design. Dette er hva vi vet i dag. Neste år, når vi har kjørt prosessen på tusenvis av prosjekter, vil vi vite annerledes ting.