AI-native SDLC: zeven werkwijzen voor betrouwbare softwareoplevering
<p dir="auto">Een programmeeragent kan klaar zijn met zijn taak terwijl de wijziging nog op review of een release wacht. Voor een CTO hangt de winst af van de vraag of de volledige wijziging sneller bij gebruikers terechtkomt, met aanvaardbare kwaliteit en kosten.</p><p dir="auto">In een AI-native software development life cycle (SDLC) maakt agentwerk deel uit van het opleverproces van het team, met afgebakende taken, rechten en acceptatiecontroles. Mensen bepalen de richting en blijven verantwoordelijk voor wat in productie komt. Deze aanbevelingen steunen op praktijkervaring bij de engineeringteams van Artefact.</p><h2 dir="auto">1. Breng het opleverproces en het knelpunt in kaart</h2><p dir="auto">Neem enkele recente wijzigingen en volg hun traject door verduidelijking, ontwerp, implementatie, tests, review en deployment. Maak onderscheid tussen werktijd, wachttijd en tijd voor correcties. Zo ziet u of de grootste vertraging voortkomt uit onduidelijke vereisten, een trage testsuite of een wachtrij voor review.</p><p dir="auto">Richt het eerste experiment op die vertraging. Als review het knelpunt is, kan meer code produceren het probleem vergroten. Testresultaten voorbereiden of wijzigingen kleiner houden helpt dan mogelijk meer. Meet het effect tot in productie, zodat u ziet of het knelpunt is opgelost of alleen verplaatst.</p><h2 dir="auto">2. Maak de vraag toetsbaar en geef de nodige context</h2><p dir="auto">Beschrijf het verwachte gedrag, wat ongewijzigd moet blijven en welke controles het resultaat moet doorstaan.</p><p dir="auto">‘Voeg een klantenexport toe’ laat bijvoorbeeld belangrijke beslissingen open. De opdracht moet aangeven wie welke records en velden mag exporteren, welke beperkingen gelden en hoe fouten worden afgehandeld. Gebruik die regels om de acceptatiecontroles vast te leggen.</p><p dir="auto">Geef de agent de relevante repositoryconventies, interfaces en instructies om tests uit te voeren. Houd die context actueel en wijs er een verantwoordelijke voor aan. Ontbreekt essentiële informatie, dan moet de agent stoppen en een gerichte vraag stellen in plaats van een aannemelijke interpretatie te kiezen.</p><h2 dir="auto">3. Leg vast wat agents mogen doen en wie het resultaat aanvaardt</h2><p dir="auto">Geef agents de bevoegdheid om binnen een afgesproken afbakening wijzigingen door te voeren en controles uit te voeren. Wijs een persoon aan die verantwoordelijk blijft voor de acceptatie, met duidelijke regels voor wanneer de agent moet stoppen of escaleren.</p><p dir="auto">Stem de review af op de gevolgen van een fout. Een documentatie-update vraagt andere controles dan een wijziging aan toegangsrechten. Leg vast welke wijzigingen expliciete menselijke goedkeuring vereisen.</p><p dir="auto">Automatische controles merken een verkeerde interpretatie van de vereiste niet altijd op. Schrijft een agent zowel code als tests, dan kunnen beide dezelfde fout bevatten. Reviewers moeten het afgesproken gedrag en het effect op het omliggende systeem controleren, inclusief foutscenario's die de eigen tests van de agent mogelijk misten.</p><h2 dir="auto">4. Beheers de toegang en houd het werk bij</h2><p dir="auto">Laat agents werken in een geïsoleerde omgeving met taakspecifieke rechten. Beperk toegang tot inloggegevens en data, en volg voor toegang tot productie het normale autorisatieproces. Een sandbox alleen verhindert niet dat een agent de gekregen inloggegevens gebruikt.</p><p dir="auto">Als een ticket of gebeurtenis een sessie start, leg dan vast welk werk daarmee is toegestaan, wat de agent mag wijzigen en wanneer hij moet stoppen.</p><p dir="auto">Houd een gedeeld overzicht bij van acties, codewijzigingen, testresultaten en fouten. Maak het alleen toegankelijk voor het betrokken team en verwijder of bescherm geheimen en gevoelige data. Een andere engineer moet het werk kunnen begrijpen en overnemen zonder afhankelijk te zijn van de laptop van de oorspronkelijke uitvoerder.</p><h2 dir="auto">5. Evalueer volledige workflows met representatieve taken</h2><p dir="auto">Stel een evaluatieset samen uit werk in uw eigen repositories, inclusief de beperkingen die dat werk doorgaans moeilijk maken. Neem ook gevallen op waarin verduidelijking vragen of stoppen bij een bevoegdheidsgrens de juiste reactie is.</p><p dir="auto">Vergelijk volledige configuraties: model, instructies, context, tools en controles. Houd taken en acceptatiecriteria gelijk en registreer naast geslaagde uitvoeringen ook menselijke correcties, doorlooptijd en totale kosten. Herhaal belangrijke gevallen om te zien of het succes consistent is.</p><p dir="auto">Gebruik openbare benchmarks om kandidaten te selecteren en beslis vervolgens op basis van resultaten in uw eigen omgeving wat u inzet. Herhaal evaluaties wanneer een model of een ander belangrijk onderdeel van de configuratie verandert.</p><h2 dir="auto">6. Meet tijd, kwaliteit, waarde en kosten</h2><p dir="auto">Houd twee tijdmetingen uit elkaar:</p><ul dir="auto"><li data-preset-tag="p"><p dir="auto">De tijd van aanvraag tot productie begint bij een afgesproken behoefte en eindigt wanneer de wijziging bruikbaar is in productie. Ze omvat verduidelijking, wachttijd en herwerk.</p></li><li data-preset-tag="p"><p dir="auto"><a data-framer-link="Link:{"type":"url","url":"https://dora.dev/guides/dora-metrics/"}">De change lead time van DORA</a> loopt van een commit in versiebeheer tot deployment in productie. Dat is een beperkter deel van het traject.</p></li></ul><p dir="auto">Koppel snelheid aan kwaliteit en bewijs van het beoogde voordeel. Voor een functie kan gebruik relevant zijn, voor een betrouwbaarheidsverbetering telt mogelijk vooral dat incidenten minder vaak terugkeren. Volg ook mislukte deployments en fouten die na de release worden ontdekt.</p><p dir="auto">Reken voor de kosten per aanvaarde wijziging het modelgebruik, de uitvoeringsinfrastructuur en menselijke review of correctie mee. Tel ook de kosten van mislukte pogingen. Definieer acceptatie vooraf en vergelijk wijzigingen met een vergelijkbare omvang en moeilijkheid.</p><h2 dir="auto">7. Begin met één team voordat u uitbreidt</h2><p dir="auto">Start met één team en een herhaalbare taak waarbij een fout beperkte gevolgen heeft. Spreek vóór het proefproject de afbakening, de uitgangsprestaties en de vereiste resultaten voor uitbreiding af. Bepaal wanneer u de proef stopt of inperkt.</p><p dir="auto">Gebruik echt werk uit het proefproject voor de opleiding. Product owners moeten oefenen met het schrijven van acceptatiecriteria; engineers met het herkennen van aannemelijke maar foute resultaten. Ga na of het team een mislukte wijziging kan onderzoeken en de herstelprocedure kan volgen, ook wanneer de agent of zijn leverancier niet beschikbaar is.</p><p dir="auto">Breid uit wanneer de resultaten aan de afgesproken criteria voldoen en het team de workflow kan gebruiken zonder van één specialist af te hangen.</p><p dir="auto">Neem naar uw volgende planningssessie één vertraagde wijziging mee en onderzoek waar ze moest wachten. Wilt u hulp om die diagnose te vertalen naar een eerste proefproject? <a data-framer-link="Link:{"type":"url","url":"https://www.agilytic.com/contact"}">Neem contact op met Agilytic</a>.</p>