Programvaruutveckling hos Idego
Sex steg. Gemensamma kontroller. Mänskliga godkännanden.
Agenter implementerar, testar och granskar. Människor godkänner omfattningen och slår ihop ändringar till main. Specifikationer, kontroller och processen finns i projektets kodarkiv.
En AI-native SDLC är en process för programvaruutveckling som agenter utför och människor styr. Specifikationer, tester, granskningsregler och godkännanden versionshanteras i projektets kodarkiv.
AI-assistans hjälper människor med enskilda uppgifter. En AI-native process kopplar ihop uppgifterna genom gemensamma, obligatoriska kontroller och dokumenterar vad som ändrats, vilka kontroller som godkänts och vem som godkänt arbetet.
Assistenter kan skriva tester och granska kod. Skillnaden är om teamet har en gemensam process som kräver dessa steg.
| Område | AI-assisterad utveckling | AI-native utveckling |
|---|---|---|
| Var processen finns | Kan bero på personliga vanor och instruktioner. | Versionshanterade standarder, specifikationer och agentfärdigheter finns i kodarkivet. |
| Specifikation före kod | En specifikation kan vara valfri eller ligga utanför arbetsflödet. | En specifikation som är klar att implementera krävs före kod. Ett dokumenterat undantag gäller enbart dokumentation eller processarbete. |
| Tester före implementation | Assistenter kan skriva tester, men ordningen behöver inte vara obligatorisk. | Varje beteende börjar med ett test som misslyckas och kräver en matris för gränsfall. |
| Automatisk granskning | Granskningen kan bero på vem som begär den och väljer kontrollerna. | Fyra granskare kontrollerar säkerhet, buggar, standarder och specifikationer samt underhållbarhet. |
| Allvarlighetsgrad och uppskjutna åtgärder | Gemensamma allvarlighetsgrader och dokumenterade uppskjutna åtgärder kan saknas. | Kritiska brister och brister med hög allvarlighetsgrad måste åtgärdas. Medelhöga och låga får skjutas upp endast med skriftlig motivering i PR:en. |
| Gränser för upprepningar | Nya försök kan sakna en gemensam gräns eller regel för eskalering. | Ett andra misslyckande stoppar loopen och ger en rapport om brister till en människa. |
| Mänskliga godkännanden | Godkännanden kan bero på personliga arbetssätt. | Människor godkänner omfattning, väljer ärenden, bekräftar commits och slår ihop ändringar till main. |
| Flytt mellan agentverktyg | Instruktioner kan skilja sig mellan verktyg. | Samma färdigheter körs i Cursor, Claude Code och Codex. En kontroll verifierar att de stämmer överens. |
| Spårbarhet efter sammanslagning | Kopplingar mellan krav, tester och beslut kan vara ofullständiga. | Ärenden länkar till specifikationer, tester, PR:er och arkiverade krav som beskriver det levererade systemet. |
Enkelt uttryckt: varje ändring går igenom sex steg och kan inte gå vidare till nästa steg förrän kontrollerna har godkänts. Varje steg avslutas med en kontroll som blockerar fortsatt arbete om den misslyckas. Leverans av ett enskilt ärende (/deliver-issue) omfattar stegen från Start till Arkivering. Leverans av en milstolpe (/deliver-milestone) kör ärenden i parallella omgångar, vart och ett i en isolerad arbetskatalog, slår ihop deras PR:er i en integrationsgren och öppnar en övergripande utkast-PR till main. En människa utför den slutliga sammanslagningen till main.
ResultatÄrenden och milstolpe
Vi kommer överens om en tydlig, testbar omfattning innan genomförandet börjar.
Ett fokuserat samtal och en genomgång av kodarkivet delar upp idén i fungerande delar av en funktion, var och en för en PR, med testbara acceptanskriterier och beroenden. För minst tre ärenden anger en milstolpe körordningen; en granskning utan kodändringar kan också skapa en prioriterad förbättringsmilstolpe med etiketter.
ResultatGren, utkast-PR och specifikation
Vi tar fram en specifikation som är klar att implementera för det valda ärendet.
Ett ärende får en gh-<n>-gren och en utkast-PR med Closes #<n>; oklar omfattning förtydligas och skrivs om, med dokumenterade beslut och ordlistetermer. Före kod tar agenten fram ett OpenSpec-förslag, en design, scenarier och uppgifter eller dokumenterar spec:skip för arbete som enbart gäller dokumentation eller processer.
ResultatKod, tester och kontrollresultat
Vi implementerar ett beteende i taget, med tester och obligatoriska kontroller.
Förkontroller av beredskap, specifikation, arkitekturgränser, säkerhet och dokumentation måste godkännas innan en underagent per uppgiftsgrupp arbetar testdrivet: misslyckat test, minimal kod, refaktorering. Gränsfallsmatrisen omfattar tomma och ogiltiga indata, gränser, företrädesregler, arv, isolering och asymmetri; efterkontroller omfattar lint, typkontroll, enhets- och integrationstester, produktionsbygge och varje specifikationsscenario.
ResultatGranskningsrapport och testplan
Vi granskar ändringen parallellt och åtgärdar brister som hindrar att arbetet slutförs.
Fullständig verifiering och fyra parallella granskare ger resultat med allvarlighetsgrader; kritiska brister och brister med hög allvarlighetsgrad måste åtgärdas, medan medelhöga och låga kräver skriftlig motivering i PR:en för att skjutas upp. Granskningen har högst två omgångar, varefter kvarstående kritiska eller höga brister ger NOT DONE och eskalering till en människa.
ResultatUppdaterade systemspecifikationer
Vi uppdaterar de löpande underhållna specifikationerna så att de stämmer med den verifierade koden.
För ändringar som kräver en specifikation för agenten in ändringsspecifikationerna i det aktuella specifikationsbiblioteket. Den sparar de uppdaterade specifikationerna i en commit så att de beskriver det byggda systemet.
ResultatMänskligt godkänd sammanslagning
En människa godkänner och slår ihop den färdiga ändringen.
En människa granskar det färdiga arbetet och slår ihop det till main. Att samla ärendenas PR:er i en integrationsgren är ett separat steg och ger inte agenten rätt att slå ihop till main.
Agenter utför arbetet och rapporterar bevis. Människor anger riktningen och behåller kontrollen över oåterkalleliga beslut.
Varje betydande ändring börjar med en specifikation som är klar att implementera innan kodarbetet börjar. Scenarierna anger vad tester och slutlig verifiering måste bevisa.
OpenSpec lagrar ändringsdokumenten i kodarkivet. Beslutsdokument förklarar valen, ordlistan definierar verksamhetens termer och arkiverade specifikationer beskriver det aktuella systemet.
En dokumenterad bedömning av tillämpligheten kan tillåta spec:skip för arbete som enbart gäller dokumentation eller processer. Den undantar inte kodändringar och tillåter inte agenter att hoppa över obligatoriska kontroller.
Startkriterier avgör om arbetet kan börja. Slutkriterier avgör om det är klart. Testdriven utveckling, gränsfallsmatrisen och godkända kontroller krävs innan leveransen kan gå vidare.
Kontrollerar säkerhetsrisker och projektets säkerhetsregler.
Kontrollerar korrekthet, felhantering och gränsfall.
Kontrollerar kodarkivets regler och varje specificerat scenario.
Ifrågasätter onödig komplexitet och kod som är svår att ändra.
Kodarkivet innehåller reglerna och bevisen som ditt team behöver för att styra agenternas arbete. Kontrollerna gör processen möjlig att granska och upprepa.
Standarder för beredskap, slutförande, testning, säkerhet, granskning, kod och samordning har ett gemensamt huvudindex. Ett enhetstest får CI att misslyckas om en standard läggs till eller tas bort utan att indexet uppdateras.
Testdrivet arbete och gränsfallsmatrisen är obligatoriska. Agenter återanvänder UI-grundkomponenter från designsystemets register; egna ersättningar är inte tillåtna. PR-etiketter och Conventional Commits är obligatoriska; CI kräver grennamn enligt gh-<n>.
Kodarkivet kopplar ihop ärenden, specifikationer, tester, PR:er och arkiverade krav. Beslutsdokument och en ordlista för verksamheten bevarar skälen till arbetet.
Granskningsomgångar, nya försök med misslyckade tester och upprepad verifiering har en gräns på två misslyckanden. Det andra stoppar loopen med BLOCKED och en rapport om brister. Varje fasrapport har en Loops:-rad med omgångar, försök, delegeringar och uppskjutna åtgärder.
Samma färdigheter körs i Cursor, Claude Code och Codex. En kontroll verifierar att deras beteende stämmer överens; processen är oberoende av en viss modell.
Människor godkänner omfattning, väljer ärenden, bekräftar commits och slår ihop till main. Agenter rapporterar hinder och eskaleringar så att en människa kan besluta om nästa steg.
Vi arbetar med utvecklingsteam i Storbritannien och hela Europa. För organisationer som vill låta agenter utföra utvecklingen, behålla tydlig kontroll och låta det egna teamet fortsätta med samma process.
Du får ett projektarkiv med specifikationer, leveransregler och agentfärdigheter från första dagen. Rapporter visar vilka kontroller som godkänts och vad som fortfarande kräver ett beslut.
Ge agenter en gemensam process med obligatoriska tester, granskningar och mänskliga godkännanden, utan att varje utvecklare behöver sätta ihop ett eget arbetsflöde.
Samma process finns kvar i ditt kodarkiv. Följ varje ärende genom specifikation, tester, PR och arkiverade krav och använd sedan processen för nästa ändring.
Det är en process för programvaruutveckling som agenter utför och människor styr. Kodarkivet innehåller specifikationer, standarder, agentfärdigheter och kvalitetskontroller samt rapporter och dokumenterade godkännanden.
En kodningsassistent kan hjälpa till att skriva, testa och granska kod. AI-native utveckling gör dessa aktiviteter till en gemensam, obligatorisk process med specifikationer före kod, granskningsregler, gränser för nya försök och mänskliga godkännanden.
Agenter slår aldrig ihop till main. För en milstolpe kan de samla ärendenas PR:er i en integrationsgren och öppna en övergripande utkast-PR. En människa godkänner och utför den slutliga sammanslagningen till main.
Automatiska loopar stoppar efter ett andra misslyckande med BLOCKED och en rapport om brister för en människa att lösa. Granskning tillåter högst två omgångar; kvarstående kritiska eller höga brister innebär då NOT DONE och eskalering.
Processen är oberoende av modell. Samma färdigheter körs i Cursor, Claude Code och Codex, och en kontroll i arbetsflödet verifierar att färdigheterna stämmer överens mellan verktygen.
En OpenSpec-ändring som är klar att implementera kommer före kod, och verifieringen kontrollerar varje scenario. Därefter för Arkivering in ändringsspecifikationerna i det aktuella kravbiblioteket. Endast en dokumenterad bedömning av ren dokumentation eller processarbete tillåter spec:skip.
Ja. Processen, standarderna, specifikationerna och agentfärdigheterna finns kvar i projektets kodarkiv. Ditt team kan köra samma arbetsflöde och följa beslut och resultat för varje levererad ändring.
Grundläggande säkerhetskrav ingår i förkontrollerna. En särskild säkerhetsgranskare arbetar tillsammans med granskarna för buggar, standarder och specifikation samt underhållbarhet. Kritiska och höga brister måste åtgärdas; medelhöga och låga som skjuts upp behöver skriftlig motivering i PR:en.
Börja med processen, inte verktyget. Lägg specifikationer, tester och granskningsregler i kodarkivet så att varje agent och utvecklare arbetar med samma kontroller. Ge agenter tydliga gränser, låt människor godkänna omfattning och sammanslagningar och prova processen i ett riktigt projekt. När den fungerar lämnar ni över den till teamet som ska driva den varje dag.
Mät leveransresultat, inte intryck. Registrera ett utgångsläge för ändringarnas ledtid, driftsättningsfrekvens, andelen ändringar som orsakar fel och granskningstid. Jämför sedan resultaten efter införandet. Självskattningar kan vara missvisande: i en METR-studie från 2025 var erfarna utvecklare 19% långsammare med AI-verktyg på de undersökta uppgifterna, men trodde att de hade varit 20% snabbare.
Specifikationsdriven utveckling innebär att komma överens om vad en ändring ska göra innan någon kod skrivs. En kort specifikation beskriver problemet, omfattningen, designbesluten och de scenarier som testerna måste bevisa. För AI-kodagenter är specifikationen både arbetsinstruktionen och överenskommelsen som tester och granskningar kontrollerar. På Idego finns specifikationerna i kodarkivet med OpenSpec.
Ja, när styrningen är en del av processen från början. Företag behöver standarder definierade som kod, arbetsregler som följs, specifikationer som stämmer med systemet och en spårbar historik över vad som ändrats och vem som godkänt det. Agenter slår aldrig på egen hand ihop ändringar med main. Människor behåller därför kontrollen över varje release.
Prata med oss om dina leveransbehov, godkännanderegler och överlämningen till teamet. Vi kan avgränsa arbetet och visa var agenter passar in.