Latest / M365.FM – Microsoft 365, Copilot & AI podcast in het Nederlands / Agentische AI herschrijft DevOps: hoe AI-agents .NET, Azure en de productiviteit van ontwikkelaars veranderen (AI-nasynchronisatie)

Transcript

Agentische AI herschrijft DevOps: hoe AI-agents .NET, Azure en de productiviteit van ontwikkelaars veranderen (AI-nasynchronisatie) · M365.FM – Microsoft 365, Copilot & AI podcast in het Nederlands

0:00
Speaker 2: Wat als je softwareontwikkelingsteam een extra teamgenoot had, iemand die
0:03
Speaker 2: nooit moe wordt, sneller leert dan wie dan ook en
0:05
Speaker 2: het saaie werk zonder klagen opknapt? Dat is in essentie
0:08
Speaker 2: wat Agentic AI aan het worden is. In deze video
0:11
Speaker 2: definiëren we eerst wat Agentic AI echt betekent, laten we
0:15
Speaker 2: zien hoe dit werkt in echte. NET en Azure workflows
0:18
Speaker 2: en verkennen we de impact op de productiviteit van je team.
0:20
Speaker 2: Aan het einde ken je één klein experiment dat je
0:22
Speaker 2: deze week in je eigen. NET pipeline kunt proberen. Maar
0:25
Speaker 2: voordat we naar de toepassingen en resultaten kijken, moeten we
0:28
Speaker 2: zien wat Agentic AI echt anders maakt dan de Addo
0:30
Speaker 2: Complete tools die je al kent. Wat maakt Agentic AI anders?
0:35
Speaker 2: Wat Agentic AI onderscheidt, is niet alleen dat het code
0:37
Speaker 2: kan genereren, maar dat het werkt als een systeem van
0:40
Speaker 2: teamgenoten met specifieke vaardigheden. Om dit te begrijpen, kunnen we
0:43
Speaker 2: het onderverdellen in drie kernkenmerken hoe elke agent context en
0:46
Speaker 2: geheugen vasthoudt, hoe meerdere agents samenwerken als een team en
0:49
Speaker 2: het verschil tussen eenvoudige automatisering en echte adaptieve autonomie. Laten
0:53
Speaker 2: we eerst kijken naar wat een individuele agent onderscheidt, context,
0:57
Speaker 2: Geheugen en doelgerichtheid. Traditionele Addo Complete voorspelt het volgende woord
1:01
Speaker 2: of de volgende regel, maar vergeet al het andere zodra
1:03
Speaker 2: de voorspelling is gedaan. Een AI-agent beschikt daarentegen over een
1:06
Speaker 2: begrip van het bredere project. Hij onthoudt wat er al
1:09
Speaker 2: is geprobeerd, weet waar code staat en past zijn output
1:12
Speaker 2: aan als er iets verandert. Die persistentie maakt het vergelijkbaar
1:15
Speaker 2: met werken met een junior developer, iemand die na verloop
1:17
Speaker 2: van tijd leert in plaats van alleen te raden wat
1:19
Speaker 2: je op dat moment wilt. Het belangrijkste verschil hier is
1:22
Speaker 2: dat tussen voorspellen en plannen. In plaats van op elke
1:24
Speaker 2: toetsaanslag afzonderlijk te reageren, houdt een agent doelen bij en
1:26
Speaker 2: past hij zich aan naarmate situaties zich ontwikkelen. Het volgende
1:29
Speaker 2: punt is hoe meerdere agents met elkaar samenwerken. Een groot
1:32
Speaker 2: misverstand is om agentekij te zien als een ontwikkelingsscript of
1:34
Speaker 2: macro die alleen repetitieve taken automatiseert. Maar in echte softwareprojecten
1:38
Speaker 2: wordt het werk verdeeld over verschillende rollen. Architecten, Reviewers, testers, operators,
1:43
Speaker 2: agents kunnen deze verdeling spiegelen, waarbij ze elk een deel
1:45
Speaker 2: van de levenscyclus afhandelen met perfecte herinnering en consistentie. Stel
1:48
Speaker 2: je één agent voor die zich richt op systeemontwerp en
1:51
Speaker 2: architectuurpatronen en frameworks voorstelt die passen bij bedrijfsdoelen. Een ander
1:55
Speaker 2: beoordeelt codewijzigingen... signaleert problemen en blijft op de hoogte van
1:58
Speaker 2: de volledige projectgeschiedenis. Een derde zou de testtacking kunnen uitbreiden
2:01
Speaker 2: op basis van gebruikersgegevens en testgevallen kunnen genereren zonder dat
2:05
Speaker 2: jij erom hoeft te vragen. Elke agent is gespecialiseerd, maar
2:07
Speaker 2: ze coördineren als een team, altijd beschikbaar, altijd consistent en
2:11
Speaker 2: gemakkelijk schaalbaar afhankelijk van de werkdruk. Waar mensen energie, context
2:14
Speaker 2: of focus verliezen, Blijf een agent standvastig en onthouden ze
2:17
Speaker 2: details met precisie. Het laatste stukje is het onderscheid tussen
2:20
Speaker 2: automatisering en autonomie. Automatisering bestaat al lang in softwareontwikkeling. Denk
2:24
Speaker 2: aan scripts, CI, CD pipelines en schablonen. Deze zijn van
2:28
Speaker 2: nature rigide. Ze volgen stap voor stap exacte instructies, maar
2:31
Speaker 2: ze lopen vast als de omstandigheden onverwacht veranderen. Autonomie hanteert
2:34
Speaker 2: een andere aanpak. AI-agents kunnen direct op veranderingen reageren, zich
2:38
Speaker 2: aanpassen als een afhankelijkheidsversie wijzigt of een servicekeuze heroverwegen wanneer
2:42
Speaker 2: kostenbeperkingen een rol gaan spelen. In plaats van vooraf gedefinieerde
2:45
Speaker 2: paden te volgen, nemen ze beslissingen onder dynamische omstandigheden. Het
2:48
Speaker 2: is een verschuiving van statische uitvoering naar adaptieve probleemoplossing. Het
2:52
Speaker 2: gevolg daarvan is dat deze agents niet langer alleen op
2:54
Speaker 2: commando's wachten. Ze kunnen oplossingen voorstellen zodra er problemen ontstaan,
2:58
Speaker 2: risico's signaleren voordat ze in productie komen en plannen opstellen
3:01
Speaker 2: die uren aan installatiewerk besparen. Als de GitHub-copilot van vandaag
3:04
Speaker 2: codefragmenten kan invullen, fungeert de versie van morgen meer als
3:07
Speaker 2: een projectbijdrager die roadmaps opstelt, release-strategieën suggereert en zelfs architecturale
3:11
Speaker 2: beslissingen markeert die later problemen kunnen veroorzaken. Dat betekent niet
3:15
Speaker 2: dat elke implementatie zonder menselijke inbreng zal verlopen, maar het
3:18
Speaker 2: kan repetitief ingrijpen, aanzienlijk verminderen en ontwikkelaars meer tijd geven
3:21
Speaker 2: om zich te concentreren op de creatieve, waardevolle onderdelen van
3:24
Speaker 2: een project. Om een eerdere formulering op dit gebied te verduidelijken,
3:27
Speaker 2: in plaats van te zeggen, wat gebeurt er als het
3:29
Speaker 2: inrichten van Azure Resources helemaal geen menselijke tussenkomst meer vereist?
3:33
Speaker 2: Zou een nauwkeurigere stelling zijn, deze tools kunnen de hoeveelheid
3:36
Speaker 2: handmatig instelwerk verminderen terwijl de belangrijkste van Rails ondermenselijke controle blijven.
3:41
Speaker 2: Het resultaat is nog steeds transformatief zonder te suggereren dat
3:44
Speaker 2: menselijk toezicht volledig verdwijnt. Het grotere inzicht is dat agentgebaseerde
3:48
Speaker 2: AI niet zomaar een andere plugin is die hier of
3:50
Speaker 2: daar een taak versnelt. Het begint te functioneren als een
3:53
Speaker 2: echt teamlid dat achtergrondwerk afhandelt, zodat ontwikkelaars niet vastlopen in
3:56
Speaker 2: het najagen van details die door een altijd actieve tegenhanger
3:58
Speaker 2: bijgehouden hadden kunnen worden. De capaciteit van het hele team
4:01
Speaker 2: wordt vergroot omdat digitale agents in belangrijke domeinen zij aan
4:04
Speaker 2: zij werken met menselijke specialisten. De theorie begrijpen is belangrijk,
4:08
Speaker 2: maar wat er echt toe doet, is hoe dit uitbakt
4:09
Speaker 2: in vertrouwde omgevingen. Dus hier is de nieuwsgierigheidskloof. Wat verandert
4:13
Speaker 2: er echt op de eerste dag van een nieuw project
4:15
Speaker 2: als agents vanaf het begin actief zijn? Vervolgens kijken we
4:18
Speaker 2: naar een concreet scenario binnen het. NET ecosysteem waar die
4:21
Speaker 2: verschuivingen al zichtbaar worden voordat je je eerste regelcode hebt geschreven.
4:24
Speaker 2: Het heroverwegen van de workflow voor ontwikkelaars in. NET. In.
4:28
Speaker 2: NET ontwikkeling begint de meest zichtbare verandering bij hoe projecten
4:31
Speaker 2: van start gaan. Het heroverwegen van de workflow voor ontwikkelaars
4:34
Speaker 2: komt hier neer op drie tactische voordelen. Snellere architectuur scaffolding,
4:38
Speaker 2: kritiek op projectniveau terwijl je bezig bent en een merkbare
4:40
Speaker 2: afname van vermoeidheid door configuratiewerk. Het eerste is versnelde scaffolding.
4:44
Speaker 2: In plaats van Visual Studio te openen en naar een
4:46
Speaker 2: lege oplossing te staren, kan een AI-agent architectuuropties voorstellen die
4:50
Speaker 2: bij jouw specifieke gebruikscenario passen. Bij het plannen van een
4:52
Speaker 2: web API met real-time updates, suggereert de agent een helder
4:55
Speaker 2: gelaagd ontwerp en geeft aan hoe SignalR natuurlijk in de
4:58
Speaker 2: flow past. Voor een financiële app zet het Entity Framework
5:00
Speaker 2: klaar met sterke type veiligheid en Azure Active Directory integratie
5:04
Speaker 2: nog voordat je één map hebt aangemaakt. Wat normaal gesproken
5:06
Speaker 2: rondes aan discussies of uren aan onderzoek kost, wordt samengevat
5:09
Speaker 2: in een paar op maat gemaakte startpunten. Dit zijn echter
5:11
Speaker 2: geen definitieve blauwdrukken. Het zijn concepten. Teams moeten elke suggestie
5:15
Speaker 2: valideren door een snelle checklist door te lopen. Voldoet de
5:17
Speaker 2: authenticatie aan de verrijste? Is de logging correct geconfigureerd? Zijn
5:21
Speaker 2: de basistestcases aanwezig? Dat lichte toezicht zorgt ervoor dat snelheid
5:25
Speaker 2: niet ten koste gaat van stabiliteit. Het tweede voordeel is
5:27
Speaker 2: voortdurende kritiek. Zie je het minder als codeaanvulling en meer
5:31
Speaker 2: als een adviseur die toeziet op de afstemming van het ontwerp.
5:34
Speaker 2: Als je een repository patroon opzet voor datatoegang, geef de
5:37
Speaker 2: agent aan of je afwijkt van de scheiding der verantwoordelijkheden.
5:40
Speaker 2: Voeg een nieuwe controller toe en hij stelt bij passende
5:42
Speaker 2: unit tests voor of wijst op inconsistenties met de rest
5:45
Speaker 2: van het project. In plaats van je met boilerplate achter
5:47
Speaker 2: te laten, stuurt hij de vorm van je systeem bij
5:50
Speaker 2: elke commit naar onderhoudbare patronen. Probeer voor een praktisch experiment
5:53
Speaker 2: Copilot in Visual Studio in te schakelen voor een klein ASP.NET
5:57
Speaker 2: Core prototype. Vergelijk vervolgens hoe lang het duurt om het
6:00
Speaker 2: eerste zinvolle verzoek te bedienen, een het point met authenticatie
6:03
Speaker 2: en datapersistentie, versus alles handmatig doen. Het is geen garantie
6:06
Speaker 2: voor tijdsbesparing, maar het uitvoeren van een zij-aan-zij oefening in
6:10
Speaker 2: je eigen omgeving is vaak de snelste manier om te
6:12
Speaker 2: zien of deze agents een wezenlijke impact hebben. Het derde
6:14
Speaker 2: voordeel is minder installatiewerk en cognitieve belasting. Veel van het
6:18
Speaker 2: vroege projectwerk is repetitief. Authenticatie, middelwerk koppelen, nu het pakketten ophalen,
6:22
Speaker 2: logging met application insights instellen, Griekse YAML pipelines schrijven. Een
6:26
Speaker 2: agent kan die onderdelen onmiddellijk opzetten, inclusief stapintegratietests die weten
6:30
Speaker 2: welke afhankelijkheden aanwezig zijn. Dat neemt je controle niet weg,
6:33
Speaker 2: het verlegt de focus van je energie. In plaats van
6:35
Speaker 2: een dag te worstelen met configuratiebestanden, besteed je die tijd
6:38
Speaker 2: aan het implementeren van de bedrijfslogica die er echt toe doet.
6:41
Speaker 2: De vermoeidheid van installatiewerk verdwijnt, waardoor er bandbreed overblijft voor
6:44
Speaker 2: creatieve ontwerpbeslissingen in plaats van mechanische taken. Waar dit anders
6:47
Speaker 2: aanvoelt dan traditionele automatisering is de flexibiliteit. Een projectjabloon geeft
6:51
Speaker 2: je statische standaardinstellingen. Een agent past zijn scaffolding aan op
6:55
Speaker 2: basis van je opgegeven zakelijke doel. Als je een samenwerkingsapp bouwt,
6:58
Speaker 2: Verschijnen caching-strategieën zoals Redis en Event-Driven ontwerp met Azure Service
7:02
Speaker 2: Bus in het opgezet plan. Als je overschakelt naar geplande workloads,
7:06
Speaker 2: verschijnen in plaats daarvan achtergrond-services en wachtrijverwerking. Die responsiviteit onderscheidt
7:10
Speaker 2: Agent AI van eenvoudige scripting door aanbevelingen te bieden die
7:13
Speaker 2: lijken op een senior teamlid dat helpt bij vroege beslissingen.
7:16
Speaker 2: Het contrast met het huidige gebruik van Copilot is duidelijk.
7:19
Speaker 2: Op dit moment zien de meeste ontwikkelaars het als een
7:21
Speaker 2: manier om snel door algemene syntax of boilerplate heen te werken.
7:24
Speaker 2: Zij stellen een vraag, de tool vult de regel in.
7:27
Speaker 2: Met agentmogelijkheden begint de tool te adviseren op systeemniveau, biedt
7:31
Speaker 2: contextbewuste alternatieven en toont afwegingen vroeg in de cyclus. De
7:35
Speaker 2: sprong is van het genereren van snippets naar het cureren
7:38
Speaker 2: van werkbare ontwerpen. En dat verandert niet alleen hoe code
7:41
Speaker 2: wordt geschreven, maar hoe teams de hele oplossing vormgeven voordat
7:44
Speaker 2: ze voor één richting kiezen. Niets hiervan neemt de noodzaak
7:47
Speaker 2: voor menselijk beoordelingsvermogen weg. Agents kunnen frameworks, dependencies en werkwijzen voorstellen,
7:51
Speaker 2: maar het verifiëren blijft de taak van het team. Behandel
7:54
Speaker 2: elke aanbeveling als een conceptvoorstel. Accepteer de onderdelen die aansluiten
7:58
Speaker 2: bij uw standaarden... Reviseer de rest- en leglessen vast voor
8:01
Speaker 2: de volgende projectiteratie. De AI neemt het repetitieve zware werk
8:04
Speaker 2: uit handen, terwijl teamleden zich concentreren op het afstemmen van
8:06
Speaker 2: technologiekeuzes op de strategie. Tot nu toe hebben we gekeken
8:09
Speaker 2: hoe agents de programmeerervaring binnen. NET zelf hervormen, maar de
8:13
Speaker 2: betrokkenheid van agents stopt niet bij het ontwerp of de projectstructuur.
8:16
Speaker 2: Zodra de basis staat, begint dezelfde intelligentie zich uit te
8:19
Speaker 2: breiden naar het provisioneren, uithollen en beheren van de infrastructuur
8:22
Speaker 2: waar applicaties op vertrouwen. Dat is waar een andere grote
8:25
Speaker 2: transformatie vorm krijgt en het is niet beperkt tot de
8:27
Speaker 2: lokale workflow van de ontwikkelaar. Het gaat om de cloud-omgeving
8:30
Speaker 2: die er omheen ligt. Cloud agents die Azure op automatische
8:33
Speaker 2: piloot draaien. Laten we dus onze focus verleggen naar wat
8:36
Speaker 2: er gebeurt wanneer Azure beheer zelf op de automatische piloot
8:38
Speaker 2: draait met behulp van agents. De manier waarop deze discussie
8:40
Speaker 2: oorspronkelijk wordt gevoerd, klinkt vaak als science fiction. Wat gebeurt
8:43
Speaker 2: er als bij het provisioneren van Azure resources helemaal geen
8:46
Speaker 2: menselijke tussenkomst meer nodig is? Een betere manier om hierover
8:48
Speaker 2: na te denken is als volgt. Wat gebeurt er als
8:51
Speaker 2: routinematige provisioning en drift detectie minder handmatige interventie vereisen, omdat
8:55
Speaker 2: agents herhaalbaar taken beheren binnen gedefinieerde kaders? Die verschuiving is
8:59
Speaker 2: belangrijk omdat het niet gaat om het verwijderen van mensen,
9:02
Speaker 2: maar om het ontlasten van herhalend werk met behoud van toezicht.
9:05
Speaker 2: Als u ooit een serieuze Azure-omgeving heeft gebouwd, weet u
9:08
Speaker 2: al hoe rommelig het kan worden. U jongleert met templates,
9:10
Speaker 2: scripts en pipeline Griekse YAML, terwijl u schakelt tussen CLI-commando's
9:15
Speaker 2: voor snelheid en de portal voor uitzonderingen. Elke sluip weg
9:17
Speaker 2: wordt technische schuld die wacht om aan de oppervlakte te komen.
9:20
Speaker 2: Een VM die buiten kantooruren blijft draaien, stijgende kosten zonder
9:22
Speaker 2: waarschuwing of een storage account dat blootgesteld is terwijl dat
9:25
Speaker 2: niet zou moeten. En bij cloud operaties zorgen zelfs kleine
9:28
Speaker 2: missers voor enorme hoofdpijn. Rekeningen die plotseling stijgen, regio's die
9:31
Speaker 2: de veerkracht ondermijnen of compliance lacunes die u op het
9:34
Speaker 2: slechtst mogelijke moment ontdekt. Dit is de sleur waar de
9:36
Speaker 2: meeste teams vanaf willen en het is waar een agent
9:38
Speaker 2: aanvoelt als een autonome deployment engineer. Het idee is simpel.
9:42
Speaker 2: Je geeft zakelijke doelstellingen, prestatie eisen, herstelbehoeften, nalevingsregels en budgetmarges
9:48
Speaker 2: op en de agent vertaalt die intentie naar infrastructuurconfiguraties. In
9:51
Speaker 2: plaats van te schakelen tussen meerdere consoles of handmatig idee's
9:54
Speaker 2: te koppelen, zie je IAC-schablonen die al zijn afgestemd op
9:57
Speaker 2: jouw doelen. Vanaf dat punt houdt dezelfde agent toezicht. Hij
10:00
Speaker 2: voert compliance-checks uit, simuleert mogelijke foutieve configuraties en past voorgestelde
10:05
Speaker 2: correcties toe voordat problemen escaleren in productie. Het verschil met
10:08
Speaker 2: bestaande automatisering zit in het aanpassingsvermogen. Een normale CI-CD-pipeline behandelt
10:13
Speaker 2: je Griekse YAML-definities als onomstotelijke waarheid. Ze werken totdat de
10:17
Speaker 2: realiteit verandert door een update van dependencies, een plotselinge piek
10:20
Speaker 2: in de vraag of een nieuw nalevingsvoorschrift en dan breken
10:22
Speaker 2: die statische instructies of ze pushen iets dat geldig lijkt
10:25
Speaker 2: maar niet aan de bedrijfsbehoefte voldoet. Een door agents gestuurde
10:28
Speaker 2: pipeline gedraagt zich anders. Die behandelt die definities als basis,
10:31
Speaker 2: maar werkt ze bij wanneer de omstandigheden veranderen. In plaats
10:34
Speaker 2: van te wachten tot iemand een service opschalt of de
10:36
Speaker 2: regionale distributie aanpast, ziet hij belastingpatronen, voorspelt drempelwaarden en voorziet
10:41
Speaker 2: hij tijdig in extra capaciteit. Dat aanpassingsvermogen maakt scenario's in
10:45
Speaker 2: de praktijk minder foutgevoelig. Stel je een punt net hebt
10:48
Speaker 2: voor die vooral verkeer in de VS bedient. Een week
10:50
Speaker 2: later verschijnen er nieuwe gebruikers in Europa. De latentie neemt toe,
10:53
Speaker 2: maar niemand had in de oorspronkelijke Griekse YAML rekening gehouden
10:56
Speaker 2: met een andere regio. Traditionele automatisering negeert dit. Je merkt
10:59
Speaker 2: het pas als de klachten binnenkomen en de laks zijn bijgewerkt.
11:01
Speaker 2: Een agent daarentegen signaleert het patroon, implementeert direct een Europese
11:04
Speaker 2: replica en configureert de routering via Azure Front door. Hij
11:07
Speaker 2: implementeert niet zomaar iets om daarna te vertrekken. Hij stemt
11:09
Speaker 2: middelen constant af op de intentie. Bijna als een 24-7e
11:13
Speaker 2: operator die nooit moe wordt. Het echte voordeel gaat verder
11:16
Speaker 2: dan schalen. Beveiliging en compliance worden in de lus ingebouwd.
11:19
Speaker 2: Dit kan betekenen dat de agent een onbedoeld blootgestolde opslagcontainer
11:23
Speaker 2: opmerkt en deze automatisch vergrendelt, of afwijkingen in de patch
11:26
Speaker 2: baseline van een VM detecteert en deze herstelt. Dit zijn
11:29
Speaker 2: taken die vaak voorkomen en weinig opvallen, die mensen meestal
11:32
Speaker 2: pas later en na veel moeite opmerken. Door ze in
11:35
Speaker 2: de continue cyclus te plaatsen, verwijder je geen operators, maar
11:38
Speaker 2: bevrijd je ze. In plaats van energie te verspillen aan
11:40
Speaker 2: brandjes blussen, kunnen ze zich concentreren op planning en strategie
11:42
Speaker 2: op een hoger niveau. En dat is een belangrijk nuanceverschil.
11:45
Speaker 2: Menselijk toezicht verdwijnt niet. Je rol verandert van het regel
11:48
Speaker 2: voor regel controleren van vakjes naar het vooraf definiëren van richtlijnen.
11:51
Speaker 2: Welke regio's zijn toegestaan, welke kosten zijn acceptabel, welke nalevingsnormen
11:56
Speaker 2: mogen niet worden geschonden. Een praktische stap voor elk team
11:58
Speaker 2: dat dit wil testen, is om vroegtijdig beleidskaders op te stellen.
12:01
Speaker 2: Stel kostenplafonds in, wijs goedgekeurde regio's aan en voeg compliancegrenzen toe.
12:06
Speaker 2: De agent fungeert dan als handhaver, niet als een ongecontroleerde operator.
12:09
Speaker 2: Dat is het leidende principe. Jij behoudt de controle over
12:12
Speaker 2: de strategische richting, terwijl de agent op grote schaal beveiligingstaken uitvoert.
12:16
Speaker 2: Het betekent ook niet dat je de productie vanaf dag
12:18
Speaker 2: 1 in de handen van de agent legt. Als je
12:19
Speaker 2: risicoavers bent, begin dan in een gecontroleerde testomgeving. Stel de
12:23
Speaker 2: agent bloot aan een niet-kritieke werklast of selecteer één enkele dienst,
12:26
Speaker 2: zoals opslag- of logboekinfrastructuur, en laat deze daar de drift
12:29
Speaker 2: en provisioning beheren. Op deze manier bouw je vertrouwen op
12:31
Speaker 2: in hoe de agent de richtlijnen interpreteert voordat je het
12:34
Speaker 2: bereik uitbreidt. Zie het als het draaien van een pilotproject
12:36
Speaker 2: met een duidelijk gedefinieerde rijkwijde en lage inzet, precies hoe
12:39
Speaker 2: de meeste betrouwbare DevOps-praktijken sowieso volwassen worden. In de kern
12:42
Speaker 2: lijkt een agritische aanpak voor Azure IRC minder op het
12:45
Speaker 2: schrijven van tientallen statische scripts en meer op het beheren
12:48
Speaker 2: van een dynamische checklist. Genereer schablonen, voer pre-deployment controles uit,
12:52
Speaker 2: monitor op afwijkingen en stel oplossingen voor, allemaal binnen de
12:54
Speaker 2: kaders die jij configureert. Het is gestructureerd genoeg voor vertrouwen,
12:58
Speaker 2: maar flexibel genoeg om mee te evolueren als de omstandigheden veranderen.
13:01
Speaker 2: Natuurlijk is het provisioneren en schalen van infrastructuur slechts één
13:04
Speaker 2: kant van betrouwbaarheid. Het lastigere probleem komt vaak later, garanderen
13:07
Speaker 2: dat de code die je in die omgeving implementeert, daadwerkelijk
13:10
Speaker 2: stand houdt onder reële omstandigheden. En daar begint de volgende
13:13
Speaker 2: uitdaging zich te tonen, het opsporen van bugs die mensen
13:16
Speaker 2: simpelweg niet zien totdat ze al in productie zijn. Autonoom testen,
13:20
Speaker 2: baks die mensen missen. Tests dekken alleen wat mensen kunnen
13:23
Speaker 2: bedenken en dat is de kernbeperking. De meeste productiefouten komen
13:27
Speaker 2: niet voort uit wat voorzien is, maar uit wat buiten
13:29
Speaker 2: de menselijke verbeelding valt. Autonome testagents vullen dit gat op
13:32
Speaker 2: door zich te richten op edge cases en dynamische omstandigheden
13:35
Speaker 2: die nooit in een typische testsuite zouden belanden. Denk aan
13:38
Speaker 2: de skill time, race conditie. Een puntnet applicatie in Azure
13:41
Speaker 2: kan perfect presteren onder zware belasting tijdens een geplande stresstest,
13:44
Speaker 2: maar introduceer schaalmomenten waarbij nieuwe instanties tijdens piekverkeer worden opgestart
13:48
Speaker 2: en plotseling verschijnen er fouten in de sessieafhandeling. Tenzij iemand
13:51
Speaker 2: specifiek een test voor die overlap heeft ontworpen, blijft dit onopgemerkt.
13:54
Speaker 2: Een autonome agent spot de afwijking, isoleert deze en genereert
13:57
Speaker 2: een nieuwe regressietest rond die conditie. De volgende keer dat
14:00
Speaker 2: schalen optreedt, is die beveiliging al aanwezig, waardoor wat een
14:02
Speaker 2: verborgen risico was, verandert in een gemonitord scenario. Een ander
14:05
Speaker 2: voorbeeld is input mutatie. Menselijke testers ontwerpen meestal met veilige
14:09
Speaker 2: of voorspelbare data in gedachte. Geldige gebruikersnamen, correcte API payloads
14:13
Speaker 2: of voor de hand liggende edge cases zoals lege strings.
14:15
Speaker 2: Een agent daarentegen begint te experimenteren met variaties waar ontwikkelaars
14:19
Speaker 2: niet aan zouden denken om te dekken. Te grote verzoeken,
14:21
Speaker 2: vreemde coderingen, kleine vertragingen tussen multistep aanroepen. Door dit te doen,
14:25
Speaker 2: kan de agent fouten uitlokken die handmatige testsuites volledig zouden missen.
14:29
Speaker 2: De waarde zit niet alleen in snelheid, maar in diversiteit.
14:32
Speaker 2: Agents verkennen vreemde hoeken van inputruimtes sneller dan door mensen
14:35
Speaker 2: geschreven scripts ooit zouden kunnen. Wat deze verschuiving anders maakt
14:38
Speaker 2: dan traditionele automatisering, is hoe de testsuite evolueert. Een door
14:41
Speaker 2: mensen ontworpen regressiepakket blijft relatief statisch. Het weerspiegelt de kennis
14:45
Speaker 2: en aannames van het team op een bepaald moment. Agents
14:48
Speaker 2: maken daar een continu proces van. Ze breiden de suite
14:51
Speaker 2: uit naarmate het systeem verandert en zoeken constant naar onvoorziene scenario's.
14:55
Speaker 2: In plaats van dat ontwikkelaars moeizaam breekbare scripts bijwerken na
14:58
Speaker 2: elke iteratie, worden nieuwe cases dynamisch gegenereerd op basis van
15:01
Speaker 2: feitelijke observaties van systeemgedrag. Toch is er een belangrijke kanttekening.
15:05
Speaker 2: Niet elke door een agent gegenereerde test verdient een plek
15:07
Speaker 2: in je permanente suite. Onbetrouwbare of irrelevante tests kunnen zich
15:10
Speaker 2: snel opstapelen, wat tijd verspilt en het vertrouwen in automatisering ondermijnt.
15:13
Speaker 2: Daarom is governance essentieel. Teams hebben een beoordelingsproces nodig. Ontwikkelaars
15:18
Speaker 2: of QA-engineers moeten elke voorgestelde test valideren op stabiliteit en
15:21
Speaker 2: zakelijke relevantie voordat deze in het stabiele regressiepakket wordt opgenomen.
15:25
Speaker 2: Net als bij elke automatisering zorgt Toezicht ervoor dat deze
15:27
Speaker 2: tools de betrouwbaarheid vergroten in plaats van teams te overspoelen
15:30
Speaker 2: met ruis. Een ander misverstand dat de wereld uitmoet is
15:33
Speaker 2: het idee dat agents bugs repareren. Ze herschrijven geen productiecode
15:36
Speaker 2: en patchen niet zelfstandig fouten. Wat ze uitzonderlijk goed doen
15:39
Speaker 2: is reproduceerbare scenario's naar boven halen met heldere diagnostische details.
15:43
Speaker 2: Voor een ontwikkelaar maakt een door een agent vastgelegde reeks
15:45
Speaker 2: stappen het verschil tussen urenlang gissen en een snelle oplossing.
15:48
Speaker 2: In sommige gevallen kunnen agents een mogelijke oplossing suggereren op
15:51
Speaker 2: basis van bekende patronen, maar de uiteindelijke beslissing en wijziging
15:54
Speaker 2: blijven in menselijke handen. Zo bezien wordt de taakverdeling duidelijker.
15:58
Speaker 2: Machines doen het ontdekken, mensen doen het oordelen en repareren.
16:01
Speaker 2: De zakelijke impact is minder, randjes blussen. Teams zien minder
16:05
Speaker 2: tickets laat op de avond, minder regressies na releases en
16:08
Speaker 2: een merkbare afname in tijdverlies bij het reproduceren van stappen.
16:11
Speaker 2: Prestatieproblemen worden opgevangen in gecontroleerde omgevingen in plaats van dat
16:15
Speaker 2: ze pas bij eindgebruikers aan het licht komen. Beveiligingsfouten komen
16:18
Speaker 2: aan het licht tijdens interne tests, niet pas na een
16:21
Speaker 2: compliance scan of penetratietest. Die verschuiving creëert ruimte voor QA
16:24
Speaker 2: om zich te richten op vraagstukken op hoger niveau, zoals bruikbaarheid,
16:27
Speaker 2: workflow soepelheid en toegankelijkheid. Gebieden die geen enkele autonome engine
16:31
Speaker 2: zinvol kan beoordelen. Voor beoefenaars die de mogelijkheden willen verkennen,
16:35
Speaker 2: begin klein. Draai een autonome testagent op een staging- of
16:38
Speaker 2: preproductieomgeving gedurende een afgebakende periode. Vergelijk de lijst met problemen
16:42
Speaker 2: die het ontdekt met je huidige backlog. Beschouw de oefening
16:45
Speaker 2: als gegevensverzameling. Zijn de nieuwe bevindingen echt nuttig? Overlappen ze
16:48
Speaker 2: bestaande tests? Laten ze blinde vlekken zien die belangrijk zijn
16:51
Speaker 2: voor je bedrijf? Op deze manier meet je het rendement
16:54
Speaker 2: op je investering en gok je niet met je release
16:56
Speaker 2: kwaliteit op een onbewezen techniek. En wanneer teams dergelijke pilots uitvoeren,
17:00
Speaker 2: ontstaat er een patroon. Het werkelijke lange termijn voordeel zit
17:03
Speaker 2: niet alleen in het vinden van extra bucks, maar in
17:06
Speaker 2: hoe snel die lessen terugvloeien in de bredere ontwikkelingscyclus. Elke
17:09
Speaker 2: vastgelegde anomalie en elk geregistreerd inzicht vertegenwoordigt kennis die niet
17:13
Speaker 2: mag verdwijnen aan het einde van een sprint. De vraag
17:15
Speaker 2: is hoe die intelligentie wordt opgeslagen, gedeeld en meegenomen, zodat
17:19
Speaker 2: dezelfde fouten niet onder andere projectnamen worden herhaald. De intelligentie
17:23
Speaker 2: loop in DevOps sluiten. In DevOps is een van de
17:25
Speaker 2: moeilijkste problemen om op te lossen hoe snel kennis vervaagt
17:28
Speaker 2: tussen sprints. Problemen worden gelogd, postmortems geschreven, maar bij de
17:32
Speaker 2: start van het volgende project bereiken veel van die lessen
17:34
Speaker 2: de workflow niet. Het sluiten van de intelligentie loop in
17:37
Speaker 2: DevOps betekent die verliescyclus doorbreken en zorgen dat wat teams
17:40
Speaker 2: leren ook echt verbetert wat daarna komt. Agentic AI ondersteunt
17:44
Speaker 2: dit door in te pluggen op de plekken waar kennis
17:46
Speaker 2: al stroomt. Het eerste integratiepunt is het opnemen van logs
17:49
Speaker 2: en telemetrie. In plaats van dat engineers dashboards of gearchiveerde
17:52
Speaker 2: incidenten moeten doorspitten, scannen agents continu statistieken, foutpercentages en prestatiegegevens,
17:57
Speaker 2: waarbij ze anomalieën over releases heen verbinden. Het tweede is
18:00
Speaker 2: het analyseren van pull request geschiedenis en code reviews. Beslissingen
18:04
Speaker 2: in opmerkingen bevatten vaak context over afwegingen of risico's die
18:08
Speaker 2: nooit de documentatie halen. Door die gesprekken te verwerken, bewaren
18:11
Speaker 2: agents waarom iets gebeurde, en niet alleen wat er werd samengevoegd.
18:14
Speaker 2: Het derde is het koppelen van geobserveerde fouten aan architectuuradviezen.
18:18
Speaker 2: Als bepaalde cachingstrategieën herhaaldelijk geheugenproblemen veroorzaken of als schaalpatronen time-outs triggeren,
18:23
Speaker 2: worden die inzichten getoond tijdens de planning voordat dezelfde fouten
18:26
Speaker 2: terugkeren in een nieuw systeem. Samen verbeteren deze integratiepunten het
18:29
Speaker 2: institutionele geheugen zonder perfectie te beloven. De waarde is niet
18:33
Speaker 2: dat agents elk detail feilloos onthouden, maar dat ze de
18:35
Speaker 2: kans vergroten dat lessen uit het verleden op het juiste
18:38
Speaker 2: moment weer opduiken. Menselijk toezicht blijft van belang. Ontwikkelaars moeten
18:42
Speaker 2: de relevantie van getoonde inzichten valideren en organisaties moeten regelmatig
18:46
Speaker 2: altijd plannen van wat agents vastleggen om ruis in het
18:49
Speaker 2: systeem te voorkomen. Met een zorgvuldige beoordeling wordt de intelligentie
18:52
Speaker 2: bruikbaar in plaats van overweldigend. Governance is een ander essentieel
18:56
Speaker 2: onderdeel dat niet mag worden overgeslagen. Het voeden van logs,
18:58
Speaker 2: pull requests en deployment resultaten aan een agentsysteem roept vragen
19:01
Speaker 2: op rondom privacy, retentie en compliance. Niet elk artifact hoeft
19:05
Speaker 2: voor eeuwig te bestaan en niet alle data hoort toegankelijk
19:08
Speaker 2: te zijn voor elke rol. Voordat deze geheugenlaag wordt uitgerold,
19:11
Speaker 2: moeten teams duidelijke retentielimieten definiëren, toegangsbeleid instellen en zorgen dat
19:16
Speaker 2: gevoelige data wordt opgeschoond of gemaskeerd. Zonder die kaders riskeer
19:20
Speaker 2: je een ongereguleerde schaduwopslag van de bedrijfsgeschiedenis die altijd bemoeilijkt
19:24
Speaker 2: in plaats van ondersteunt. Voor ontwikkelaars is de meest merkbare
19:27
Speaker 2: impact zichtbaar tijdens de projectstart. In plaats van vage herinneringen
19:30
Speaker 2: aan wat er de vorige keer misging, verschijnen inzichten direct
19:33
Speaker 2: in de juiste context. Begin een nieuwe punt netweb, API
19:36
Speaker 2: en het systeem geeft wellicht de waarschuwing, vorig jaar veroorzaakte
19:38
Speaker 2: deze caching bibliotheek geheugenlekken onder belasting. Overweeg een alternatief. Aanhalingsteken,
19:43
Speaker 2: of tijdens de planning kan het aangeven dat specifieke dependency
19:45
Speaker 2: injection patronen voor instabiliteit zorgden. De herinneringen zijn tijdig, niet achteraf.
19:50
Speaker 2: waardoor de focus verschuift van reageren op problemen naar het
19:52
Speaker 2: voorkomen ervan. Zo versterkt projectintelligentie zich in plaats van elke
19:55
Speaker 2: keer te resetten bij het begin van een nieuwe sprint.
19:57
Speaker 2: Het verandert ook de aard van retrospectives. Traditionele retro's verzamelen
20:02
Speaker 2: feedback op één moment en gaan dan verder. Met agents
20:04
Speaker 2: in de loop wordt die kennis niet terzijde geschoven. Het
20:07
Speaker 2: wordt continu teruggekoppeld in de ontwikkelcyclus. Laks van deze maand,
20:11
Speaker 2: schaalafwijkingen van het laatste kwartaal of prestatieverminderingen van twee jaar
20:15
Speaker 2: geleden informeren de aanbevelingen van vandaag. Door elke release onderdeel
20:19
Speaker 2: te maken van een continu trainingscyclus... verkleinen teams de kans
20:22
Speaker 2: dat oude fouten zich herhalen. Toch moeten resultaten worden gemeten,
20:25
Speaker 2: niet aangenomen. Een simpele eerste stap is de agent te
20:28
Speaker 2: integreren met één bron, zoals applicatielogs of een APM-feed, en
20:31
Speaker 2: deze twee sprints te draaien. Vergelijk daarna heeft de agent
20:34
Speaker 2: patronen blootgelegd die je zelf niet had opgemerkt. Leiden die
20:37
Speaker 2: patronen tot echte wijzigingen in code of infrastructuur? En is
20:40
Speaker 2: de kwaliteit van de release meetbaar verbeterd? Als het antwoord
20:42
Speaker 2: ja is, dan is uitbreiding naar PR-geschiedenis of architectuur mapping logisch.
20:47
Speaker 2: Zo niet, dan onthult het experiment zelf wat aanpassing behoeft,
20:50
Speaker 2: of het nu gaat om databronnen, governance of beoordelingsprocessen. Na
20:53
Speaker 2: verloop van tijd is de opbrengst cumulatief. Door het collectief
20:56
Speaker 2: geheugen te verbeteren, stabiliseert de release snelheid, wordt de architectuur
21:01
Speaker 2: robuuster en gaat minder energie verloren aan het herontdekken van
21:04
Speaker 2: oude valkuilen. GANIS verdwijnt niet langer in de plooien, maar
21:07
Speaker 2: verzamelt zich als een bruikbare bron waar teams op kunnen vertrouwen.
21:10
Speaker 2: En op dat punt ziet de rol van Agentic AI
21:12
Speaker 2: er anders uit. Het is niet langer slechts een helper
21:14
Speaker 2: in één ontwikkelingsfase. Het begint het hele proces te verbinden
21:17
Speaker 2: en lessen door te geven in plaats van ze te
21:19
Speaker 2: laten verwateren. Die continuïteit verandert DevOps van een reeks geïsoleerde
21:23
Speaker 2: taken in een verbonden levenscyclus, wat de weg vrijmaakt voor
21:26
Speaker 2: de bredere verschuiving die nu plaatsvindt bij software teams. Agentic
21:30
Speaker 2: AI signaleert een praktische verschuiving in ontwikkeling. Concept, het is
21:34
Speaker 2: geen codeassistent, maar een systeem dat geheugen, context en doelen
21:37
Speaker 2: door de gehele levenscyclus draagt. Toepassing, de duidelijkste instappunten voor.
21:41
Speaker 2: NET en Azure Teams zijn het opzetten van nieuwe projecten,
21:44
Speaker 2: agents routine taken laten afhandelen en experimenteren met geautomatiseerde testgeneratie. Impact,
21:49
Speaker 2: mid zorgvuldig uitgevoerd, stroomlijnt dit workflows, vermindert het op start
21:52
Speaker 2: overhead en verkleint het de kans dat oude fouten zich
21:55
Speaker 2: herhalen in project. De beste volgende stap is om het
21:57
Speaker 2: te testen in je eigen omgeving. Probeer Copilot in te
22:00
Speaker 2: schakelen voor een klein prototype of laat een agent draaien
22:02
Speaker 2: op staging en hou vervolgens één metriek bij. Bespaar de tijd,
22:05
Speaker 2: ontdek de bugs of voorkomen drift. Heb je een terugkerende
22:08
Speaker 2: DevOps-uitdaging die je team vertraagt? Deel het in de reacties
22:10
Speaker 2: zodat anderen kunnen vergelijken. En als je meer gefundeerd advies
22:14
Speaker 2: wilt over. NET, Azure en AI-adoptie, abonneer je dan voor
22:17
Speaker 2: toekomstige analyses. De winst lijkt in het begin klein, maar
22:20
Speaker 2: stapelt zich op door governance, toezicht en gestage iteratie.