Latest / M365.FM – Microsoft 365, Copilot & AI podcast in het Nederlands / Stop met lapwerk-debuggen: GitHub Copilot Agent Mode voor .NET en Azure (AI-nasynchronisatie)

Transcript

Stop met lapwerk-debuggen: GitHub Copilot Agent Mode voor .NET en Azure (AI-nasynchronisatie) · M365.FM – Microsoft 365, Copilot & AI podcast in het Nederlands

0:00
Klaar voor 10 dagen Microsoft 365, Copilot, AI, Azure en de mensen die de toekomst van werk vormgeven?
0:07
Deze januari is M365, kom terug en we pakken groter uit.
0:12
Doe mee voor live sessies, praktijkdemo's en praktische kennis van MVP's en experts van over de hele wereld.
0:18
Geen algemene presentaties, geen eindeloze modewoorden.
0:21
We pakken de echte uitdagingen aan Copilot Studio, AI Agents, Fabric, Beveiliging, Governance en Automatisering.
0:29
Of je nu IT-professional, ontwikkelaar of zakelijk leider bent, er zijn sessies speciaal voor jou.
0:35
Met 10 volledige dagen kun je verschillende technologieën verkennen en contact leggen met een wereldwijde community.
0:40
Kijk live mee en neem praktische inzichten mee terug naar je organisatie.
0:44
Januari 2027, 10 dagen, 1 Microsoft Community.
0:49
Registratie is nu geopend.
0:51
Ga naar m365.com.net en verzeker je vandaag nog van een plek.
0:56
Dat is m365.com.net.
1:00
Meld je nu aan op m365.com.net, dan zien we je live in januari.
1:05
Als je ooit een oplossing hebt geopend en je meteen overweldigd voelde door het web van bestanden, verwijzingen en bugs die je opwachten, dan ben je niet alleen.
1:12
De meeste ontwikkelaars werken reactief, hier wat patchen, daar wat debuggen.
1:15
De agentmodus van GitHub Copilot is bedoeld om bredere context te behouden en wijzigingen over bestanden heen te coördineren.
1:20
In deze video laten we zien hoe die workflow eruit ziet in een echt podcast.net en Azure project.
1:25
We lopen door een live oplossing en laten het verschil zien voor en na agentwijzigingen.
1:28
Je ziet hoe je code voor meerdere bestanden genereert met minder overhead, fouten tussen bestanden sneller oplost en zelfs een specificatie in gewone taal gebruikt om features op te zetten.
1:36
Maar voordat we zover zijn, laten we beginnen met de verborgen kosten van de debugging loop waar zo vele van ons dagelijks in zitten.
1:41
De verborgen kosten van ad hoc debuggen. Je gaat zitten om een fout te herstellen die simpel genoeg lijkt.
1:46
De applicatie bouwt niet en de console geeft een foutmelding op een regel in je hoofdprojectbestand.
1:50
Je past de methode aan, compileert opnieuw en denkt dat je het hebt opgelost, totdat dezelfde melding in een iets andere vorm verschijnt.
1:56
Er gaat weer een half uur voorbij voordat je het werkelijke probleem ontdekt.
1:59
Een ontbrekende afhankelijkheid die diep in een andere projectmap verborgen zat.
2:02
Tegen de tijd dat de verwijzing is gecorrigeerd en je opnieuw implementeert, is het grootste deel van je middag opgegaan aan labwerk.
2:07
Het geplande werk aan features schuift door naar morgen. Dit patroon is zo gebruikelijk dat het normaal aanvoelt.
2:12
Op het eerste gezicht boek je vooruitgang, omdat elke bak die je verhelpt als een overwinning voelt.
2:16
In de praktijk draai je in cirkels. De lus is coderen, compileren, fout, herstellen, herhalen.
2:21
Uren verdwijnen in het achtervolgen van oorzaak en gevolg en het netto resultaat is reactieve vooruitgang in plaats van zinvolle verbeteringen.
2:26
Hoeveel van jullie zijn al eens een middag kwijtgeraakt aan precies deze lus?
2:29
Laat een reactie van één zin achter, ik zal de beste antwoorden doorlezen.
2:32
Wat deze cyclus zo uitputtend maakt is dat de tools om ons heen blijven verbeteren, terwijl het patroon gelijk blijft.
2:37
Editors krijgen nieuwe functies, frameworks evolueren en integraties worden diepgaander, maar debuggen vereist nog steeds een reactieve aanpak.
2:44
Het is alsof je een groeiende brand probeert te blussen met een emmer water.
2:47
Elke uitslaande brand wordt op dat moment aangepakt, maar de onderliggende oorzaken blijven bestaan, wat de volgende brand bijna garandeert.
2:52
En met elke tabbladwissel stijgen de verborgen kosten.
2:55
Je verplaatst je van een serviceklasse naar een configuratiebestand en springt daarna door naar een afhankelijkhedengrafie.
2:59
Elke verschuiving haalt je uit de logische lijn waar je mee bezig bent en dwingt je tot een mentale reset.
3:04
Het zijn niet alleen de seconden die je kwijt bent aan het wisselen van vensters, het is de mentale tol van het telkens opnieuw opbouwen van context.
3:10
Gedurende de dag stapelen die kleine resets zich op tot een zware last.
3:13
Voor individuele ontwikkelaars uit de vermoeidheid zich in frustratie en verloren tijd.
3:17
Voor teams die aan bedrijfsprojecten werken, wordt de impact vermenigvuldigd.
3:20
Debugging lussen halen, sprinttelen onderuit, vertragen de lancering van functies en creëren een backlog die sneller groeit dan hij krimpt.
3:26
De toename van technische schuld is slechts een ander bij effect van uren die verloren gaan aan brandjes blussen.
3:31
Veel teams melden dat een groot deel van hun ontwikkeltijd opgaat aan reactief debuggen.
3:35
Het is niet het meest boeiende onderdeel van engineering.
3:38
Niemand plant een roadmap rondom met vijf keer moeten oplossen van hetzelfde afhankelijkheidsconflict.
3:42
Toch is dit waar de capaciteit week na week naartoe gaat.
3:44
Wanneer het verhelpen van fouten de definitie van vooruitgang wordt, raakt het bouwen van nieuwe functies op de achtergrond en leidt de architectuur in stilte.
3:51
De ongemakkelijke waarheid is dat ad hoc debuggen het proces niet alleen vertraagt, het versterkt een cultuur van reactie in plaats van ontwerp.
3:58
Je besteedt tijd aan het blussen van branden in plaats van aan het bouwen van systemen.
4:02
Dat houdt het product op korte termijn misschien in de lucht, maar het beperkt de schaalbaarheid van een team en de zekerheid waarmee ze kunnen releasen.
4:07
Dus laten we even stilstaan bij dat beeld, brandjes blussen, naar de hotspot rennen, water er overheen en weer door.
4:12
Het probleem is niet dat ontwikkelaars er niet goed in zijn.
4:15
Dat zijn ze wel.
4:16
Het probleem is dat de vlammen nooit echt doven.
4:18
Ze verplaatsen zich gewoon, laaien op in nieuwe bestanden, nieuwe projecten, nieuwe configuraties en houden iedereen in de responsmodus in plaats van de creatiemodus.
4:25
Dat roept de vraag op, wat gebeurt er als de cyclus niet alleen op jouw schouders rust?
4:29
Wat als de repetitieve onderdelen, de lus van traceren, schakelen en patchen, anders beheerd zouden kunnen worden terwijl jij je blijft focussen op bouwen?
4:36
Want hoewel de druk van het brandjes blussen duidelijk is, is er nog een pijnpunt dat we nog niet hebben besproken.
4:41
De echte last komt wanneer je project niet uit slechts één bestand of module bestaat.
4:44
Dat is wanneer de oplossing die je nodig hebt meerdere lagen tegelijk beslaat.
4:48
Stel je voor dat je een oplossing opent waarbij de logica verspreidt is over verschillende projecten, services en bibliotheken.
4:54
Het onderdeel dat je nodig hebt staat op drie plekken tegelijk en het overzicht behouden is al een strijd op zich.
5:01
Chaos in meerdere bestanden versus AI contextbeheer.
5:04
Wanneer projecten meerdere lagen beslaan, is het schrijven van code niet de echte uitdaging.
5:08
Het is het bij elkaar houden van alle bewegende onderdelen.
5:10
Dit is waar de spanning tussen de chaos van meerdere bestanden en AI gestuurde contextcontrole het duidelijkst wordt.
5:16
Neem een grote .NET oplossing met wel twaalf of meer projecten.
5:19
Elke nieuwe functionaliteit raakt meestal verschillende lagen tegelijk.
5:22
Een controller op de ene plek, een service op een andere en een set configuratiebestanden die ergens anders staan.
5:27
Voordat je één regel schrijft, ben je tijd kwijt aan het nagaan van verwijzingen en afhankelijkheden,
5:32
in de hoop dat een kleine wijziging niet leidt tot onverwachte fouten verderop in de keten.
5:35
Die workflow is geen uitzondering. Het is normaal bij bedrijfsapplicaties, zeker zodra Azure services en integraties erbij komen kijken.
5:42
De structuur van deze systemen is niet plat.
5:45
Interfaces, dependency injection mappings en cross-project verwijzingen spelen allemaal een rol.
5:50
Met Azure in de mix stappen sommige afhankelijkheden volledig buiten de oplossingsmap, function apps, servicebus bindings, resource instellingen, opslagverbindingen.
5:57
Je coördineert tussen code in je IDE, configuratiebestanden op schijf en services gedefinieerd in de cloud.
6:04
Geen van hen geeft erom dat je liever minder wilt klikken.
6:06
Elke keer dat je van context wisselt, verbruikt je energie om het grotere geheel te reconstrueren.
6:10
De meeste van ons proberen die context in het werkgeheugen te jong leren.
6:13
In het begin is het te doen, maar naarmate het project groeit, sluipen er fouten in.
6:16
Je voegt een nieuwe methode toe aan de service, maar vergeet de registratie.
6:20
Je programmeert een Azure functie en merkt pas later dat de binding nooit is toegevoegd aan host, JSON of het deployment schabloon.
6:25
Niets waarschuwt je tot runtime wanneer je aan het debuggen bent in plaats van aan het bouwen.
6:28
De code zelf is niet het moeilijke deel.
6:30
Het is de coördinatie tussen bestanden.
6:32
Iedereen kent het gevoel van heen en weer springen tussen tabbladen, van een controller naar een service, dan naar een model, dan in configuratiebestanden en dan weer terug,
6:39
om vervolgens te vergeten waarom je dat bestand ook alweer had geopend.
6:41
Het is een kleine onderbreking die tientallen keren per dag herhaald wordt.
6:45
Die interacties stapelen zich op en creëren wrijving die echte vooruitgang vertraagt.
6:48
Het resultaat is een tragere oplevering, niet omdat het schrijven langzaam gaat, maar omdat het synchroniseren van alles je focus steelt.
6:54
Deze overhead groeit in cloud-first projecten.
6:57
Azure verspreidt belangrijke instellingen over meerdere locaties, lokale configuratiebestanden, omgevingsvariabelen, arm of bicep templates en CI-CD pipelines.
7:06
Wat een enkel verzoek om een nieuwe functie lijkt, beslaat vaak vier abstractielagen.
7:10
Deze complexiteit is geen optie.
7:12
Het zit ingebakken in de manier waarop het ecosysteem werkt.
7:15
En hier komt agentmode in beeld als een mogelijke verandering.
7:18
In plaats van die hele orkestratie aan jou over te laten, is het ontworpen om bredere context over meerdere bestanden vast te houden.
7:22
Dat betekent dat wanneer je vraagt om een wijziging in één laag, de andere lagen niet worden genegeerd.
7:27
In de demo maak ik een nieuwe Azure functie en laat ik zien hoe de agent helpt door de method body te genereren, de binding config te maken en een host bij te werken.
7:34
JSON en zelfs de juiste de registratie voor te stellen.
7:37
Dat is meestal een proces in meerdere stappen dat verspreid is over verschillende bestanden.
7:41
Een agent kan dit stroomlijnen tot één workflow.
7:43
Dit gaat niet over het vervangen van jouw oordeel, maar over het wegnemen van repetitief administratief werk, zodat jij je op de echte ontwerpkeuzes kunt richten.
7:50
Mensen kunnen een ruwe schets in hun hoofd houden of op een whiteboard tekenen.
7:54
Een AI kan de details per bestand bijhouden zonder de rode draad te verliezen.
7:58
Wat voor ons aanvoelt als een enorme cognitieve belasting, is voor de agent slechts basiscontext.
8:02
Het verschil in de praktijk is de overgang van gefragmenteerd tabbladenbeheer naar jorchestreerde wijzigingen die in sync blijven.
8:07
Ik zal tijdens de demo ook de door de agent gemaakte pull request of diff laten zien, zodat je precies kunt zien welke bewerkingen er zijn uitgevoerd.
8:12
Die zichtbaarheid is belangrijk.
8:14
Je behoudt volledige controle om te beoordelen en goed te keuren, terwijl het voorbereidende werk van het bijwerken van meerdere bestanden voor je wordt gedaan.
8:19
Dus in plaats van een hele middag besteden aan het aan elkaar knopen van fragmenten, stuur je de wijziging één keer aan, bevestig je de gegenereerde updates en ga je door met het ontwerp op een hoger niveau.
8:26
De opluchting zit niet alleen in bespaarde klikken of toetsaanslagen, maar in de focus op het oplossen van echte problemen in plaats van het herleiden van hoe een dozijn bestanden met elkaar verbonden is.
8:34
Dit voordeel wordt het duidelijkst wanneer dingen kapot gaan, want zelfs met betere contextverwerking falen systemen, verlopen configuraties en sluipen er weer foutieve verwijzingen in.
8:42
En daar begint de volgende test hoe fouten worden opgespoord en opgelost zodra ze de kop opsteken.
8:47
Van foutenjacht naar autonome oplossingen.
8:49
Denk eens aan hoe vaak je een foutmelding krijgt die direct naar één bestand wijst.
8:53
Je volgt de stacktrace naar de methode die wordt genoemd, maakt een kleine aanpassing en drukt op opnieuw opbouwen.
8:58
Het voelt als de voor de hand liggende oplossing, totdat dezelfde fout weer verschijnt, maar dan in een iets andere vorm.
9:03
Op dat moment besef je dat de stacktrace alleen het symptoom toonde.
9:06
Het werkelijke probleem ligt ergens anders, misschien in een ondersteunende klasse of verborgen in een configuratiebestand dat je de hele week niet hebt geopend.
9:11
Elke ontwikkelaar heeft met dat soort misleiding te maken gehad.
9:14
Wat het probleem lijkt, is vaak niet de plek waar de oplossing hoort.
9:17
Dit vreet razendsnel tijd. Je past iets aan, herbouwt en wacht.
9:20
Dan begroet een nieuwe foutje, wat leidt tot een ander bestand, nog een aanpassing en weer een herbouw.
9:25
De lus lijkt productief omdat je bezig bent, typt en hercompileert, maar onder de oppervlakte is het meer vallen en opstaan dan echte oplossing.
9:31
Die cyclus kan uren opsloeken en je achterlaten met kleine oppervlakkige correcties, zonder echte vooruitgang op de functie waarmee je begon.
9:38
De werkelijke kosten hier zijn gemiste kansen.
9:41
Terwijl je vast zit in het ritme van herbouwen en opnieuw proberen, los je geen zakelijke problemen op en lever je geen functionaliteit waar je gebruikers op wachten.
9:47
Momentum gaat verloren aan giswerk in plaats van aan ontwerp.
9:50
Het voelt op dat moment actief, maar die uren leveren weinig op behalve het systeem draaiende houden.
9:55
Binnen een team vertraagt deze oppervlakkige beweging alles en ontstaat er een achterstand van functies die maar vooruit blijven schuiven.
10:02
Hier begint een agent workflow er anders uit te zien.
10:04
Het idee is niet om te stoppen bij de ene regel die je stacktrace markeert.
10:08
In plaats daarvan is het ontworpen om context op systeemniveau te bewaren en vraagt het niet alleen wat dit bestand moet doen,
10:14
maar welke reeks wijzigingen nodig is voor verbonden onderdelen om consistentie te herstellen.
10:18
In de praktijk betekent dit dat je ziet dat het bewerkingen voorstelt die meerdere bestanden beslaan.
10:22
In de demo zul je bijvoorbeeld zien dat wanneer een methode wijzigingen vereist,
10:25
het bij passende aanpassingen kan voorstellen in gerelateerde configuraties of deployment schablonen,
10:29
in plaats van dat jij ze zelf moet zoeken.
10:31
Dat is de sprong van automatisch aanvullen naar iets breders.
10:34
Automatisch aanvullen voltooit regels, een agent coördineert over bestanden heen,
10:37
en die coördinatie is cruciaal wanneer fouten niet netjes op één plek staan.
10:40
Neem een veel voorkomend Azure scenario.
10:42
Je hebt een nieuwe function-app gebouwd, maar na implementatie faalt de Q-trigger omdat de binding niet overeenkomt met de methode-signatuur.
10:48
Normaal gesproken spit je door Lux, zoek je uit welke binding niet klopt,
10:51
pas je de function-yason handmatig aan en wijzig je misschien zelfs je infrastructuur-schabloon als daar ook een waarde niet matcht.
10:57
Elke stap is een aparte zoektocht en elke correctie triggert een nieuwe te strong.
11:01
Met de agent-modus is de workflow anders.
11:04
Deze kan de codewijziging voorstellen,
11:05
de juiste function-yason binding genereren en bewerkingen voor deployment scripts tonen als die niet op elkaar zijn afgestemd.
11:10
Je beoordeelt, bevestigt en gaat verder zonder uren te besteden aan het bij elkaar puzzelen van elke laag.
11:14
En vertrouwen is hier de sleutel.
11:16
Niemand hoort het gevoel te hebben dat er onzichtbare wijzigingen op de achtergrond plaatsvinden.
11:18
Daarom is het beoordelingsproces zo belangrijk.
11:20
In deze demo lopen we er samen doorheen.
11:22
De agent stelt de gecoördineerde wijzigingen voor.
11:25
We openen de div om precies te inspecteren wat er is gegenereerd,
11:27
draaien onze unit-tests,
11:29
valideren de beeldlokaal en kiezen pas daarna of we de bewerkingen accepteren of afwijzen.
11:33
Die validatie lushoudt je volledig in controle terwijl het saaie werk wordt weggenomen.
11:37
Het is de moeite waard om te benadrukken,
11:38
agents kunnen helpen om sneller te werken,
11:40
maar ze vervangen geen goede engineering-praktijken.
11:42
Je moet codereviews en CI nog steeds als ononderhandelbare poortwachters blijven zien.
11:45
Laat de AI de tijd die je aan speurwerk besteedt verminderen,
11:48
maar hou geautomatiseerde checks en menselijke controle als vangnet.
11:51
Die balans lost het vertrouwensprobleem op
11:53
en zorgt ervoor dat de snelheidswinst de stabiliteit niet ondermijnt.
11:55
Het snelheidsverschil is niet theoretisch.
11:58
Waar fouten opsporen en handmatig patchen een halve dag in beslag kan nemen,
12:01
kunnen gecoördineerde suggesties dit tot minuten beperken.
12:03
En de teruggewonnen tijd vloeit terug naar het werk waar je echt energie in wilt steken.
12:07
De functies die je gebruikers opmerken,
12:09
de architectuurbeslissingen die je codebasis verbeteren.
12:11
In plaats van brandjes blussen tijdens runtime, kun je vooraf met vertrouwen ontwerpen.
12:15
Dus de debugging-lus hoeft je dag niet langer te bepalen.
12:18
Met een agent die updates over meerdere bestanden voorstelt,
12:21
verschuif je van lukraak zoeken naar een ritme van beoordelen en goedkeuren.
12:24
Je stopt met in cirkels dwalen door fouten en begint debugging te behandelen als een gestructureerde,
12:28
bijna geautomatiseerde stap in je workflow.
12:30
Die verschuiving maakt cognitieve ruimte en agendauren vrij voor het bouwen van functies,
12:33
in plaats van alleengebreken herstellen.
12:34
En zodra het oplossen van fouten minder gaat over symptoombestrijding,
12:38
opent dit de deur naar iets groters.
12:39
Hoe je hele functies op dezelfde gestructureerde manier zou kunnen starten.
12:43
Stel je voor dat dezelfde workflow die gecoördineerde fix is voorstelt,
12:46
ook een specificatie in gewone taal kan nemen en daar een werkende structuur omheen vormt.
12:50
Dat is waar de volgende fase van ontwikkeling begint.
12:53
Specificatie gestuurde ontwikkeling zonder de overhead.
12:56
Een van de meest interessante verschuivingen komt wanneer je stopt met alleen in termen van bestanden en methoden te denken,
13:00
en werk in plaats daarvan in gewone taal kadert.
13:02
Dat is waar specificatie gestuurde ontwikkeling zonder de overhead om de hoek komt kijken.
13:06
Stel je voor dat je een simpel functieverzoek uitschrijft.
13:08
Voeg een rapportage workflow toe die maandelijkse samenvattingen genereert,
13:12
deze opslaat en beschikbaar maakt via een beheerpagina.
13:14
In plaats van slechts een paar geïsoleerde fragmenten te krijgen,
13:17
kom je terug met een werkende structuur die al over je hele app is uitgezet.
13:20
Controllers opgezet, modellen aangemaakt, services geregistreerd en configuratie gekoppeld.
13:24
Die stap van het beschrijven van intentie naar het zien verschijnen van een concreet raamwerk in je project
13:28
is waar deze aanpak eindelijk praktisch in plaats van theoretisch aanvoelt.
13:32
In traditionele opstellingen heeft Spec First Ontwikkeling een zware reputatie.
13:35
In grote organisaties betekent het meestal lange documenten met vereisten,
13:39
ontwerpsheets van meerdere pagina's en rigide diagrammen die iedereen vertragen.
13:42
Ze zijn zinvol in gereguleerde industrieën of wereldwijd verspreide teams,
13:45
maar voor dagelijks coderen slaan de meeste ontwikkelaars ze over.
13:47
Het schrijven en bijhouden van gedetailleerde specificaties kost tijd en geduld die niemand heeft.
13:52
Het is extra werk bovenop het opleveren van functies,
13:54
en naarmate deadlines naderen, worden die extra taken meestal opgeofferd.
13:58
De ironie is duidelijk, ontwikkelaars denken eigenlijk graag in grote lijnen.
14:01
De structuur vooraf kennen is geruststellend. Het probleem is niet de intentie, maar het onderhoud.
14:06
Zodra de specificatie niet meer strookt met de werkelijkheid, wordt het onderhoud een last.
14:10
Daarom neigt het echte werk vaak naar improvisatie in plaats van volledig ontwerp,
14:15
zelfs bij bedrijven die officieel zwaar inzetten op planning.
14:17
Een agent workflow biedt een alternatief.
14:20
In plaats van een gepolijst ontwerp document te eisen,
14:22
kan het helpen een specificatie in gewone taal te vertalen naar een opzet die je kunt verfijnen.
14:26
Je hebt geen UML-diagrammen of handgeschreven interface-maps nodig.
14:30
Je kunt simpelweg zeggen, maak een rapportage-module met een nieuw API-inpoint,
14:34
koppel deze aan opslag en beveilig het met op rollen gebaseerde toegang,
14:37
waarna het systeem een basis genereert in je puntnet-oplossing.
14:40
In de demo lees ik een specificatie in gewone taal voor,
14:43
laat ik de bestanden zien die de agent heeft gemaakt,
14:45
controllers, modellen en service-registratie,
14:48
en wijs ik de punten aan die nog handmatige verfijning vereisten.
14:51
Zo kun je de kwaliteit zelf beoordelen.
14:53
Dit creëert een middenweg tussen twee manieren van ontwikkelen.
14:56
Aan de ene kant is er FIBE-coding, snel en vrij, maar kwetsbaar voor systemen op lange termijn.
15:01
Aan de andere kant is er SPEC-driven design, betrouwbaar, maar tergend traag.
15:05
Met ondersteuning van een agent schets je het idee in natuurlijke taal,
15:08
verschijnt het raamwerk en kun je bijna net zo snel itereren als bij FIBE-coding,
15:11
terwijl je de voordelen van een georganiseerde structuur behoudt.
15:14
Neem nog eens die rapportage-workflow.
15:16
Normaal gesproken moet je het model maken, de dataservice bouwen,
15:19
de controller koppelen, beveiliging configureren en alles in de opstartfase verbinden.
15:23
Dat betekent schakelen tussen meerdere bestanden in de hoop dat de consistentie behouden blijft.
15:27
Met deze aanpak staat het raamwerk in één keer op zijn plek.
15:30
De echte winst zit hem minder in het type van minder regels en meer in het vermijden van fouten tussen bestanden,
15:34
zoals vergeten een nieuwe service te registreren nadat je deze al hebt gebouwd.
15:37
Natuurlijk is er altijd de vraag over stijl.
15:39
Zal een i-standaardcode afdelingen of conventies negeren?
15:42
In de praktijk weerspiegelen agents in hun suggesties vaak bestaande patronen in het project.
15:46
In de demo zul je beide kanten zien.
15:48
Plekken waar het de controllerstructuur van ons Team Perfect volgde en plekken waar de aannames niet helemaal aansloten.
15:54
Die mix is belangrijk.
15:55
Je zult weten wat je kunt vertrouwen en wat je nog moet aanpassen.
15:58
Het eindresultaat is geen eenheidsworst aan code.
16:00
Het voelt nog steeds als jouw project, alleen met minder handmatig voorbereidend werk.
16:04
Je behoudt snelheid en vertrouwt nog steeds op een basis die je kunt verfijnen voor toekomstige groei.
16:08
In plaats van dat specificatiewerk beperkt blijft tot architecten met geduld voor diagrammen, wordt het een tool voor elke ontwikkelaar die snel wil experimenteren zonder orde op te offeren.
16:17
En wanneer dit onderdeel wordt van je dagelijkse flow, voelt specificatie niet meer als een formele bedrijfstap, maar als een lichtgewicht afkorting.
16:24
Je beschrijft je intentie, het systeem legt het fundament en jij focust je op het vormgeven van de details.
16:29
De grotere impact komt niet alleen van de code die je genereert, maar van wat de tijdsbesparing week na week betekent.
16:35
Meer uren voor functies, minder zwoegen bij de opzet.
16:38
Dat brengt ons direct bij de vraag waar elke ontwikkelaar het meest om geeft.
16:41
Wat deze veranderingen daadwerkelijk opleveren in termen van productiviteit.
16:45
De productiviteitswinst.
16:47
De echte vraag is niet of je hier en daar een paar minuten bespaart, maar hoe die kleine verschuivingen optellen tot betekenisvolle uren in een week.
16:54
Dit is de productiviteitswinst.
16:56
Tijd terugwinnen die normaal onopgemerkt weglekt door context switches, herhaalde beeldscycli en handmatige aanpassingen.
17:02
De meeste ontwikkelaars accepteren die kleine verliezen als een onderdeel van het werk.
17:05
10 minuten hier om een configuratiewaarde te zoeken, nog eens 15 minuten opnieuw draaien na een gemiste verwijzing, of schakelen tussen bestanden om verbindingen te checken.
17:12
Op zichzelf lijken ze klein, maar bij elkaar opgeteld over een volledige sprint, bepalen ze hoeveel werkelijke waarde er wordt opgeleverd.
17:18
Wat lijkt op routinematige beweging, verbergt een echte vertraging in de opleveringstermijnen.
17:22
Het verborgen gewicht zit niet in compileertijden of typesnelheid.
17:25
Het zit in het stopstartritme dat aan je concentratie wordt opgelegd.
17:28
Elke keer dat je van het ene bestand naar het andere gaat, reset je brein.
17:31
Die reset heeft een prijs.
17:32
Repetitieve correcties uitbesteden aan een agent verlicht die last.
17:35
In plaats van constant context te reconstrueren, besteed je focus waar het telt, het oplossen van de grotere ontwerpvraagstukken.
17:42
Veel teams houden deze microkosten niet bij omdat ze niet in JIRA tickets of gitgeschiedenis verschijnen.
17:46
Werk dat nergens toe leidt wordt niet gelogd, maar kost nog steeds energie.
17:50
En naarmate codebezes schalen, voegt deze wrijving zich niet alleen lineair toe.
17:53
Meer lagen betekenen meer afhankelijkheden om in het geheugen te houden en meer kansen om tijd te verliezen met simpelweg de structuur uitlijnen voordat je verder kunt.
18:00
Agent Workflows veranderen de rekensom door deze lekken direct aan te pakken.
18:03
Ze vullen niet alleen sneller methoden stups in.
18:05
Ze verminderen de lussen van zoeken, patchen en opnieuw draaien die middagen opslokken.
18:09
Teams die Agent Workflows gebruiken, rapporteren in veel gevallen een kortere tijd tot de blokkering.
18:14
In deze video demonstreren we een voor en na taak zodat je de impact zelf kunt beoordelen.
18:18
Ik meet de tijd die nodig is om dezelfde Azure functie handmatig te implementeren en daarna met de agent.
18:23
Zodat je de productiviteitswinst concreet kunt zien.
18:25
Vanuit zakelijk perspectief is de waarde zichtbaar in de projectsnelheid.
18:29
Snellere cycli gaan niet alleen over de tevredenheid van ontwikkelaars.
18:32
Ze bepalen of functies in deze release verschijnen of kwartalen opschuiven.
18:35
Ze beïnvloeden technische schuld doordat er minder hacks en regressies in de backlog belanden.
18:39
Een soepelere flow laat Teams vooruitgang boeken in plaats van kapot werk uit de voorrige sprint te herstellen.
18:44
Die consistentie zorgt na verloop van tijd voor minder brandjes blussen en betere opleveringen.
18:48
Er is ook de menselijke factor.
18:50
Een dag die verloren gaat aan het zoeken naar fouten laat elke engineer uitgeput achter.
18:53
Als je vermoeid bent, wordt zorgvuldig ontwerpen lastiger, glippen details weg en sluipen er fouten in.
18:58
Door mechanische correcties naar een agent te verplaatsen, blijven ontwikkelaars langer alert.
19:02
Die extra focus verscherpt zowel de productiviteit als de kwaliteit.
19:06
Wanneer je niet wordt afgeremd door herhaaldelijke frictie, ben je vrijer om breder te denken en effectiever te plannen.
19:11
Het verschil in de praktijk ziet er als volgt uit.
19:13
Een nieuwe Azure-functie met meerdere bindings- en service-integraties kan zonder hulp wel twee volle dagen duren.
19:18
Tussen configuratie, testen en het corrigeren van verkeerde referenties sleept de taak zich voort.
19:24
Met hulp van een agent kan diezelfde functie in een halve dag klaar zijn.
19:27
Niet omdat er hoekjes worden afgesneden, maar omdat de crossfile setup en orkestratie direct goed staan.
19:32
De tijdlijn krimpt door valse starts en redundant werk te elimineren.
19:35
Sommige ontwikkelaars uiten een terechte zorg.
19:38
Maakt het vertrouwen op AI voor onderhoud je eigen vaardigheden minder scherp?
19:41
Dit perspectief mist vaak wat er werkelijk verandert.
19:44
Het uitbesteden van repeterend werk verzwakt je expertise niet, maar bewaart deze voor ontwerp en architectuur waarin zich het verschil maakt.
19:50
In werkelijkheid krijg je ruimte voor probleemoplossing op een hoger niveau in plaats van energie te verspillen aan correcties.
19:55
Als je dit uitprobeert, laat dan in de comments weten hoeveel uur je per sprint hebt teruggewonnen.
19:58
Ik zal interessante reacties in toekomstige video's verwerken.
20:01
Horen hoe andere teams deze verandering ervaren, geeft iedereen een beter beeld van de werkelijke waarde voor bij demo's en voorbeelden.
20:07
Toch een waarschuwing, automatisering helpt, maar veiligheid blijft cruciaal.
20:10
Draai altijd je tests en gebruik code reviews om door AI gemaakte wijzigingen te valideren.
20:14
Vertrouw op de vermindering van routine werk, maar behoud dezelfde vangrails.
20:18
Het snelheidsverschil loont alleen als de kwaliteit stabiel blijft.
20:21
Sterke tests en slimme PR reviews beschermen je release pipeline tegen fragiele automatisering.
20:26
De winst zit minder in het snel produceren van regels, code en meer in het creëren van ruimte voor betere oplossingen.
20:31
Met minder vermoeidheid en minder.