Latest / M365.FM – Microsoft 365, Copilot & KI Podcast auf Deutsch / Schluss mit Flicken-Debugging: GitHub Copilot Agent Mode für .NET und Azure in der Praxis (KI-Synchronfassung)

Transcript

Schluss mit Flicken-Debugging: GitHub Copilot Agent Mode für .NET und Azure in der Praxis (KI-Synchronfassung) · M365.FM – Microsoft 365, Copilot & KI Podcast auf Deutsch

0:00
Bereit für 10 Tage voller Microsoft 365, Co-Pilot, KI-Escher und den Vordenkern, die die Zukunft der Arbeit gestalten?
0:07
Diesen Januar ist die M2 in 1260-Con zurück und wir legen noch eine Schippe drauf.
0:12
Seien Sie dabei bei Live-Sessions, Praxis-Demos und Expertenwissen von MVPs und Branchenprofis aus aller Welt.
0:18
Keine generischen Folien, kein endloses Buzzword-Bingo.
0:22
Wir gehen die echten Herausforderungen an.
0:23
Co-Pilot Studio, KI-Agenten, Fabrik, Sicherheit, Governance und Automatisierung.
0:28
Egal ob IT-Profi, Entwickler oder Führungskraft, wir haben die passenden Sessions für Sie.
0:35
An 10 vollen Tagen können Sie Technologien erkunden und sich mit einer globalen Community vernetzen.
0:40
Schauen Sie live zu und nehmen Sie praktische Erkenntnisse mit in Ihr Unternehmen.
0:45
Januar 2027, 10 Tage, eine Microsoft-Community.
0:49
Die Registrierung ist jetzt geöffnet.
0:51
Besuchen Sie m365con.net und sichern Sie sich noch heute Ihren Platz.
0:55
Das ist m365con.net.
1:00
Melden Sie sich jetzt auf m365con.net an.
1:03
Wir sehen uns live im Januar.
1:05
Wenn Sie schon einmal eine Lösung geöffnet haben und sich sofort von der Flut an Dateien, Referenzen und Fehlern erschlagen fühlten, sind Sie damit nicht allein.
1:11
Sind Sie damit nicht allein?
1:12
Die meisten Entwickler arbeiten reaktiv wie ein Patch dort ein Debugging.
1:15
Der Agentenmodus von GitHub-Copilot zielt darauf ab, einen breiteren Kontext zu erfassen und Änderungen teilübergreifend zu koordinieren.
1:19
In diesem Video zeigen wir, wie dieser Workflow in einem echten .net und Azure-Projekt aussieht.
1:25
Wir gehen eine Live-Lösung durch und zeigen den Zustand vor und nach den Änderungen durch den Erkenntnis.
1:28
Sie sehen, wie Sie dateiübergreifenden Code mit weniger Aufwand erstellen, Fehler schneller beheben und sogar eine einfache Beschreibung nutzen, um Funktionen zu entwickeln.
1:36
Bevor wir dazu kommen, schauen wir uns die versteckten Kosten der Debugging-Schleife an, in der viele von uns täglich feststecken.
1:41
Die versteckten Kosten von Flicken-Debugging.
1:43
Sie setzen sich hin, um einen scheinbar einfachen Fehler zu beheben.
1:46
Die Anwendung lässt sich nicht erstellen und die Konsole markiert eine Zahl in Ihrer Hauptprojektattach.
1:50
Sie passen die Methode an, kompilieren neu und denken, Sie hätten es gelöst, bis dieselbe Meldung in leicht geänderter Form wieder auftaucht.
1:56
Eine weitere halbe Stunde verstreicht, bevor Sie das eigentliche Problem entdecken.
1:59
Eine fehlende Abhängigkeit versteckt in einem anderen Projektordner.
2:02
Bis die Referenz korrigiert ist und Sie neu bereitgestellt haben, ist der Großteil des Nachmittags mit Flickenarbeit verflogen.
2:07
Die geplante Arbeit an neuen Funktionen wird auf morgen verschoben.
2:09
Dieses Muster ist so verbreitet, dass es sich schon normal anfühlt.
2:12
Oberflächlich betrachtet kommen Sie voran, weil jeder behobene Fehler wie ein Erfolg wirkt.
2:16
In der Praxis drehen Sie sich jedoch im Kreis.
2:17
Die Schleife lautet Programmieren, Kompilieren, Fehler, Korrektur, Wiederholung.
2:21
Stunden verschwinden bei der Verfolgung von Ursache und Wirkung und das Nettoergebnis ist eher reaktiver Fortschritt statt echter Verbesserungen.
2:27
Wie viele von Ihnen haben schon einen ganzen Nachmittag in genau dieser Schleife verloren?
2:29
Hinterlasst einen kurzen Kommentar, ich werde die besten Antworten durchlesen.
2:32
Was diesen Kreislauf so erschöpfend macht, ist, dass sich die Tools um uns herum weiterentwickeln, das Muster jedoch nicht.
2:36
Editoren erhalten neue Funktionen, Frameworks entwickeln sich weiter und Integrationen werden tiefer, aber das Debugging erfordert immer noch einen reaktiven Ansatz.
2:44
Es ist, als würde man versuchen, ein wachsendes Feuer mit einem Eimer Wasser aufzuhalten.
2:47
Jeder Aufflackern wird im Moment gelöst, aber die zugrunde liegenden Bedingungen bleiben bestehen und garantieren fast den nächsten Brand.
2:53
Und mit jedem Tab-Wechsel steigen die versteckten Kosten.
2:55
Man wechselt von einer Serviceklasse in eine Konfigurationsdatei und springt dann zu einem Abhängigkeitsgrafen.
2:58
Jeder Wechsel reißt einen aus dem Gedankengang heraus und erzwingt einen mentalen Reset.
3:04
Es sind nicht nur die Sekunden, die man mit dem Fensterwechsel verbringt, sondern die geistige Belastung, den Kontext immer wieder neu aufzubauen.
3:10
Über einen Tag hinweg summieren sich diese kleinen Resets zu etwas Schwerwiegendem.
3:13
Für einzelne Entwickler äußert sich die Erschöpfung in Frustration und Zeitverschwendung.
3:17
Für Teams, die an Unternehmensprojekten arbeiten, potenziert sich der Effekt.
3:20
Debugging-Schleifen bringen Sprintziele vom Kurs ab, verzögern Feature-Launches und lassen einen Backlog wachsen, der schneller wächst, als er schrumpft.
3:26
Die Zunahme technischer Schulden ist nur ein weiterer Nebeneffekt der Stunden, die mit Brandbekämpfung verloren gehen.
3:31
Viele Teams berichten, dass ein großer Teil ihrer Entwicklungszeit in reaktives Debugging abfließt.
3:35
Das ist nicht der aufregende Teil des Engineering.
3:37
Niemand plant eine Roadmap, um die fünfmalige Verfolgung desselben Abhängigkeitskonflikts zu holen.
3:41
Doch genau hier landet die Bandbreite Woche für Woche.
3:44
Wenn das Beheben von Fehlern zur Definition von Fortschritt wird, rückt das Bau neuer Funktionen in den Hintergrund und die Architektur leidet im Stillen und die Architektüren.
3:51
Die unbequeme Wahrheit ist, dass Flicken von Fehlern die Dinge nicht nur verlangsamt.
3:54
Es festigt eine Kultur der Reaktion anstatt der Gestaltung.
3:58
Man verbringt Zeit damit, Flammen zu löschen, anstatt Systeme zu konstruieren.
4:02
Das mag das Produkt kurzfristig am Leben erhalten, aber es begrenzt, wie weit ein Team skalieren und wie sicher es liefern kann.
4:08
Bleiben wir also kurz bei diesem Bild. Brandbekämpfung.
4:10
Zum Brandherd eilen, Wasser drauf, weiter geht's.
4:12
Das Problem ist nicht, dass Entwickler nicht gut darin wären. Das sind sie.
4:15
Das Problem ist, dass die Flammen nie wirklich aufhören.
4:18
Sie wandern nur umher, flackern in neuen Dateien, neuen Projekten, neuen Konfigurationen auf und halten alle im Reaktionsmodus statt im Erstellungsmodus.
4:25
Das wirft die Frage auf, was passiert, wenn dieser Kreislauf nicht allein auf dir lastet?
4:29
Was, wenn die repetitiven Teile die Schleife aus Tracing, Wechseln und Patchen anders gehandhabt werden könnten, während du dich auf das Bauen konzentrierst?
4:36
Denn während die Belastung durch die Brandbekämpfung offensichtlich ist, gibt es noch einen anderen Druckpunkt, den du bisher nicht angesprochen hast.
4:41
Die wahre Herausforderung beginnt, wenn der Projekt nicht nur aus einer Datei oder einem Modul besteht.
4:45
Dann, wenn der nötige Fix mehrere Ebenen gleichzeitig betrifft.
4:48
Stellen Sie sich vor, Sie öffnen eine Lösung, deren Logik sich über verschiedene Projekte, Dienste und Bibliotheken erstreckte.
4:54
Das benötigte Teil existiert an drei Stellen gleichzeitig und den Überblick zu behalten ist ein Kampf für sich.
5:01
Multify Chaos vs. KI-Kontext-Kontrolle
5:03
Wenn Projekte mehrere Ebenen umspannen, ist das eigentliche Problem nicht das Programmieren.
5:08
Es ist das Zusammenhalten aller beweglichen Teile.
5:10
Hier zeigt sich die Spannung zwischen Multify Chaos und KI-gestützter Kontext-Kontrolle am deutlichsten.
5:16
Nehmen Sie eine große Docknet-Lösung mit einem Dutzend oder mehr Projekten?
5:19
Jedes neue Feature berührt meist verschiedene Ebenen zugleich.
5:22
Ein Controller hier, ein Service dort und eine Reihe von Konfigurationsdateien, die ganz woanders liegen, die ganz woanders liegen.
5:27
Bevor Sie eine Zeile schreiben, verbringen Sie Zeit damit, Referenzen nachzuverfolgen und Abhängigkeiten zu prüfen,
5:32
in der Hoffnung, dass eine kleine Änderung keine unerwarteten Fehler in der Kette auslöst.
5:35
Dieser Arbeitsablauf ist keine Ausnahme.
5:37
Er ist normal bei Unternehmensanwendungen, besonders sobald Azure-Dienste und Integration ins Spiel kommen.
5:42
Die Struktur dieser Systeme ist nicht flach.
5:45
Schnittstellen, Dependency-Injection-Mappings und projektübergreifende Referenzen spielen alle eine Rolle.
5:49
Mit Azure im Mix verlassen einige Abhängigkeiten den Lösungsordner komplett.
5:53
Function-Apps, Service-Boss-Bindings, Ressourceneinstellungen, Speicherverbindungen, Speicherverbindungen.
5:58
Sie koordinieren Code in Ihrer IDE, Konfigurationsdateien auf der Festplatte und Dienste in der Cloud.
6:04
Keinem davon ist es wichtig, dass Sie weniger Klicks bevorzugen werden.
6:06
Jedes Mal, wenn Sie den Kontext wechseln, verbrauchen Sie Energie, um das Gesamtbild neu zu rekonstruieren.
6:10
Die meisten von uns versuchen, diesen Kontext im Arbeitsspeicher zu jonglieren.
6:12
Anfangs ist das machbar, doch mit dem Wachstum des Projekts schleichen sich Fehler ein.
6:16
Sie fügen eine neue Methode im Service hinzu, vergessen aber deren DIY-Restrierung.
6:19
Sie programmieren eine Azure-Funktion und bemerken erst später, dass das Binding nie in die Hostung desen oder das Deployment-Template aufgenommen wurde.
6:25
Nichts warnt Sie bis zur Laufzeit, wenn Sie plötzlich Debuggen anstatt zu entwickeln.
6:28
Der Code an sich ist nicht der schwierige Teil.
6:30
Es ist die dateiübergreifende Koordination.
6:32
Jeder kennt das Gefühl, durch Tabs zu springen vom Controller zum Service, zum Modell, in Konfigurationsdateien und wieder zurück.
6:37
Nur um dann zu vergessen, warum man die Datei überhaupt geöffnet hatte.
6:41
Es ist eine kleine Unterbrechung, die sich dutzende Male am Tag wiederholt.
6:45
Diese Interaktionen summieren sich und erzeugen Reibung, die den Fortschritt bremst.
6:48
Das Ergebnis ist eine langsamere Bereitstellung, nicht weil das Schreiben langsam ist, sondern weil das Synchronisieren den Fokus raubt.
6:54
Dieser Aufwand wächst bei Cloud-First-Projekten.
6:57
Azure verteilt wichtige Einstellungen auf mehrere Orte.
7:00
Lokale Konfigurationsdateien, Umgebungsvariablen, ARM- oder BICEP-Templates und CI-CD-Pipelines.
7:06
Was wie eine einfache Feature-Anfrage aussieht, erstreckt sich oft über vier Abstraktionsebene.
7:11
Diese Komplexität ist nicht optional.
7:12
Sie ist fest in der Funktionsweise des Ökosystems Funke.
7:15
Genau hier stellt der Agentenmodus eine potenzielle Veränderung dar.
7:18
Anstatt die gesamte Orchestrierung Ihnen zu überlassen, ist er darauf ausgelegt, einen breiteren Kontext über mehrere Dateien hinweg zu behalten.
7:23
Das bedeutet, wenn Sie eine Änderung auf einer Ebene anfordern, werden die anderen nicht ignoriert.
7:27
In der Demo erstelle ich eine neue Azure-Funktion und zeige, wie der Agent hilft, indem er den Methodenkörper generiert, die Binding-Konfiguration erstellt und Host aktualisiert.
7:34
JSON und sogar die korrekte DI-Registrierung vorschlägt.
7:38
Normalerweise ist das ein mehrstufiger Prozess, der über verschiedene Dateien verstreut ist.
7:41
Ein Agent kann dies in einem einzigen Ablauf optimieren.
7:43
Es geht nicht darum, ihr Urteilsvermögen zu ersetzen, sondern die repetitive Buchhaltung zu entfernen, damit Sie sich auf die eigentlichen Designentscheidungen konzentrieren können.
7:50
Menschen können sich eine grobe Skizze im Kopf behalten oder auf einem Whiteboard notieren.
7:54
Eine KI kann die Details Datei für Datei verfolgen, ohne den Faden zu verlieren.
7:57
Was für uns eine enorme kognitive Belastung darstellt, ist für den Agenten nur grundlegender Kontext.
8:02
Der Unterschied in der Praxis liegt im Wechsel vom fragmentierten Tab-Jongelieren hin zu orchestrierten Änderungen, die synchron bleiben.
8:07
Ich werde während der Demo auch den vom Agenten erstellten Pull-Request oder Div aufrufen, damit Sie genau sehen können, welche Bearbeitung vorgenommen wurde.
8:12
Diese Sichtbarkeit ist wichtig.
8:14
Sie behalten die volle Kontrolle zur Überprüfung und Freigabe, während die Arbeit bei der Aktualisierung mehrere Dateien für Sie erledigt wird.
8:19
Anstatt also einen Nachmittag damit zu verbringen, Fragmente zusammenzufügen, leiten Sie die Änderung einmal an, bestätigen die generierten Updates und gehen zum übergeordneten Design über.
8:25
Die Entlastung liegt nicht nur in gesparten Klicks oder Tasteneingaben, sondern darin, sich auf die Lösung echter Probleme zu konzentrieren, statt nachzuvollziehen, wie ein Dutzend Dateien zusammenhängen.
8:34
Dieser Vorteil zeigt sich am deutlichsten, wenn etwas kaputt geht, denn selbst mit besserer Kontextverwaltung versagen Systeme, Konfigurationen driften ab und falsche Referenzen schleichen sich wieder ein.
8:42
Und genau da beginnt der nächste Test, wie Fehler aufgespürt und behoben werden, sobald sie auftreten.
8:47
Von der Fehlersuche hin zu autonom korrekt.
8:49
Denken Sie daran, wie oft Sie auf eine Fehlermeldung stoßen, die direkt auf eine einzige Datei verweist.
8:53
Sie folgen im Stacktrace zu der genannten Methode, nehmen eine kleine Anpassung vor und starten den Bild neu.
8:58
Es fühlt sich wie die offensichtliche Lösung an, bis derselbe Fehler wieder auftaucht, nur in einer etwas anderen Form.
9:03
Dann erkennen Sie, dass der Stacktrace nur das Symptom gezeigt hat.
9:06
Das eigentliche Problem liegt ganz woanders, vielleicht in einer unterstützenden Klasse oder versteckt in einer Konfigurationsdatei, die Sie die ganze Woche nicht geöffnet haben.
9:12
Jeder Entwickler stand schon einmal vor dieser Art von Irreführung.
9:14
Was wie das Problem aussieht, ist oft nicht der Ort, an dem die Lösung liegt.
9:17
Das frisst schnell Zeit.
9:17
Man passt etwas an, baut neu, wartet.
9:20
Dann begrüßt einen ein neuer Fehler, der zu einer anderen Datei einer weiteren Anpassung und einem erneuten Bild führt.
9:25
Diese Schleife wirkt produktiv, weil man sich bewegt, tippt und neu kompiliert.
9:28
Aber eigentlich ist es eher Herumprobieren als echte Problemlösung.
9:32
Dieser Kreislauf kann Stunden verschlingen und hinterlässt nur kleine Korrekturen an der Oberfläche, statt das ursprüngliche Feature voranzubringen.
9:38
Gag, die eigentlichen Kosten liegen in der verpassten Chance.
9:40
Während man im Rhythmus von Neubauen und Wiederholen feststeckt, löst man keine Geschäftsprobleme und liefert keine Funktionen, auf die Nutzer warten.
9:48
Die Energie fließt in Vermutungen statt in die Entwicklung.
9:50
Es fühlt sich in dem Moment aktiv an, aber diese Stunden bringen kaum mehr, als das System gerade noch so am Laufen zu halten.
9:56
Im Team bremst diese oberflächliche Betriebsamkeit alles aus und erzeugt einen Berg an Features, die immer weiter aufgeschoben werden.
10:01
Erden.
10:02
Hier beginnt ein Agent-Workflow anders zu wirken.
10:04
Die Idee ist, nicht bei der einen Zeile stehen zu bleiben, wie der Stacktrace hervorhebt.
10:07
Stattdessen ist er darauf ausgelegt, Systemkontext zu erfassen und zu fragen, nicht nur, was diese Datei tun soll,
10:13
sondern welche Änderungen über verbundene Teile hinweg nötig sind, um Konsistenz wiederherzustellen.
10:18
In der Praxis bedeutet das, dass er Änderungen vorschlagen kann, die mehrere Dateien betreffen.
10:22
Im Demo-Beispiel sehen Sie zum Beispiel, wenn eine Methode Änderungen erfordert, kann er passende Anpassungen zu gehörigen Configs oder Deployment-Templates vorschlagen,
10:29
statt dass Sie diese selbst suchen müssen.
10:31
Das ist der Sprung von Autocomplete zu etwas Umfassenderem.
10:34
Autocomplete ergänzt Zeilen, ein Agent koordiniert Dateiübergreifend.
10:37
Und diese Koordination ist besonders wichtig, wenn Fehler nicht ordentlich an einem Ort liegen.
10:40
Nehmen wir ein typisches Azure-Szenario.
10:42
Sie haben eine neue Function-App erstellt, aber nach dem Deployment schlägt der Cure-Trigger fehl,
10:46
weil das Binding nicht zur Methodensignatur passt.
10:47
Normalerweise durchforsten Sie Protokolle, finden heraus, welches Binding falsch ist, passen das Function-JSON-Manual an und ändern vielleicht sogar Ihr Infrastruktur-Template, falls dort ebenfalls ein Wert nicht übereinstimmt.
10:57
Jeder Schritt ist eine eigene Suche und jede Korrektur löst einen weiteren Testlauf aus.
11:02
Im Agent-Modus ist der Workflow anders.
11:04
Er kann die Codeänderung vorschlagen, das korrekte Function-JSON-Binding generieren und Anpassungen für Deployment-Skripte vorschlagen, falls diese nicht übereinstimmen.
11:10
Sie prüfen, bestätigen und kommen voran, ohne Stunden damit zu verbringen, jede Ebene einzeln zusammenzusetzen.
11:14
Und Vertrauen ist hier der Schlüssel.
11:16
Niemand sollte das Gefühl haben, dass im Hintergrund unsichtbare Änderungen vorgenommen werden.
11:19
Der Cell-Review-Prozess so wichtig?
11:20
In dieser Demo gehen wir das gemeinsam durch.
11:22
Der Agent schlägt die koordinierten Änderungen vor.
11:24
Wir öffnen das DIV, um genau zu prüfen, was generiert wurde, führen unsere Unit-Tests aus, validieren den Bild lokal und entscheiden erst dann, ob wir die Änderungen annehmen oder ablehnen.
11:33
Diese Validierungsschleife lässt Ihnen die volle Kontrolle, während Sie in die mühsame Arbeit abnehmen.
11:36
Es ist wichtig zu betonen, Agenten können helfen, schneller zu arbeiten, aber sie ersetzen keine bewährten technischen Praktiken.
11:42
Code-Reviews und CI sollten für Sie nach wie vor unverhandelbare Kontrollinstanz bleiben.
11:45
Lassen Sie die KI die Zeit für Detektivarbeit verkürzen, aber behalten Sie automatisierte Prüfungen und menschliche Überprüfungen als Sicherheitsnetz bei.
11:51
Dieses Gleichgewicht löst das Vertrauensproblem und stellt sicher, dass der Geschwindigkeitsvorteil die Stabilität nicht gefährdet.
11:56
Der Geschwindigkeitsunterschied ist nicht rein theoretisch.
11:58
Wo Fehlersuche und manuelle Patches einen halben Tag kosten können, reduzieren koordinierte Vorschläge dies auf Minuten.
12:02
Und die wiedergewonnene Zeit fließt zurück in die Arbeit, in die Sie tatsächlich Energie investieren möchten.
12:07
In die Funktionen, die Ihre Nutzer bemerken und in die Architekturentscheidungen, die Ihre Code-Basis verbessern.
12:11
Anstatt zur Laufzeit ständig Brände zu löschen, können Sie von vornherein mit Zuversicht designen.
12:15
So muss die Debugging-Schleife Ihren Arbeitstag nicht mehr bestimmen.
12:18
Mit einem Agenten, der dateiübergreifende Updates vorschlägt, wechseln Sie von zielloser Suche zu einem Rhythmus aus Überprüfen und Freigeben.
12:23
Sie hören auf, im Kreis durch Fehler zu irren und beginnen, Debugging als strukturierten, fast automatisierten Schritt in Ihrem Workflow zu betrachten.
12:30
Dieser Bundle schafft kognitiven Freiraum und Zeit für die Entwicklung neuer Funktionen, anstatt nur Mängel zu beheben.
12:34
Und sobald Fehlerbehebung weniger zum Jagen von Symptomen wird, öffnet sich die Tür für etwas Größeres,
12:39
wie Sie ganze Funktionen auf die gleiche strukturierte Weise starten könnten.
12:43
Stellen Sie sich vor, derselbe Workflow, der koordinierte Korrekturen vorschlägt,
12:46
könnte auch eine Spezifikation in einfacher Sprache nehmen und daraus eine funktionierende Struktur formen.
12:50
Hier beginnt die nächste Stufe der Entwicklung.
12:54
Spezifikationsgetriebene Entwicklung ohne den Administrativen.
12:55
Einer der interessantesten Wechsel findet statt, wenn Sie aufhören, nur in Dateien und Methoden zu denken und stattdessen beginnen,
13:00
Arbeit in einfacher Sprache zu formulieren.
13:03
Genau hier kommt die spezifikationsgetriebene Entwicklung ohne den Overhead ins Spiel.
13:06
Stellen Sie sich vor, Sie schreiben eine einfache Feature-Anfrage.
13:08
Füge einen Reporting-Workflow hinzu, der monatliche Zusammenfassungen erstellt, speichert und sie über eine Admin-Seite verfügbar macht.
13:14
Anstatt nur ein paar isolierte Schnipsel zu erhalten,
13:16
bekommen Sie eine funktionierende Struktur, die bereits über Ihre App hinweg verknüpft ist.
13:19
Controller angelegt, Modelle erstellt, Services registriert und die Konfiguration eingebunden.
13:24
Dieser Schritt vom Beschreiben der Absicht hin zum konkreten Grundgerüst in Ihrem Projekt ist der Moment,
13:28
in dem sich dieser Ansatz endlich praktisch statt theoretisch anfühlt.
13:31
In traditionellen Umgebungen hat Spec-First-Entwicklung einen eher schwerfälligen Ruf.
13:35
In großen Unternehmen bedeutet das meist lange Anforderungsdokumente, mehrseitige Design-Sheets und starre Diagramme, die jeden verlangsamen.
13:42
Sie ergeben Sinn in regulierten Branchen oder global verteilten Teams,
13:44
aber im alltäglichen Programmieren lassen die meisten Entwickler sie aus.
13:47
Schreiben und pflegen detaillierter Spezifikationen verursacht Kosten, für die niemand Geduld oder Zeit hat.
13:52
Es ist zusätzliche Arbeit, die zur Bereitstellung von Funktionen hinzukommt
13:54
und wenn Termine näher rücken, werden diese zusätzlichen Zyklen meist geopfert.
13:57
Die Ironie ist offensichtlich, Entwickler denken eigentlich gerne in größeren Zusammenhängen.
14:01
Die Strukturen vorauszukennen ist beruhigend, das Problem ist nicht die Absicht, sondern die Pflege.
14:06
Sobald die Spezifikation nicht mehr mit der Realität übereinstimmt, wird die Wartung zur Last.
14:10
Deshalb driftet so viel Arbeit im echten Leben in Richtung Improvisation statt vollständigem Design ab,
14:14
selbst in Firmen, die eigentlich strikte Planung befürworten.
14:17
Ein Agenten-Workflow bietet eine Alternative.
14:20
Anstatt ein ausgefeiltes Design-Dokument zu fordern,
14:22
hilft es dabei, eine Spezifikation in einfacher Sprache in einen Grundgerüst zu übersetzen, das Sie verfeilen können.
14:26
Sie brauchen keine UML-Diagramme oder handgeschriebene Schnittstellenpläne.
14:29
Sagen Sie einfach, erstelle ein Reporting-Modul mit einem neuen API-Endpunkt,
14:33
verknüpfe es mit dem Speicher und sichere es mit rollenbasierter Zugriffssteuerung
14:36
und das System generiert eine Basis über die Dateien Ihrer .NET-Lösung hinweg.
14:40
In der Demo werde ich eine Spezifikation in einfacher Sprache vorlesen,
14:43
dann die vom Agenten erstellten Dateien Controller, Modelle und Dienstregistrierung zeigen
14:47
und auf die Stellen hinweisen, die noch manueller Verfeinerung bedurften.
14:50
So können Sie die Qualität selbst beurteilen.
14:53
Dies schafft einen Mittelweg zwischen zwei Entwicklermodi.
14:56
Auf der einen Seite gibt es das Vibe-Coding, schnell, frei formuliert, aber anfällig für langfristige Systeme.
15:01
Auf der anderen Seite gibt es das spezifikationsgesteuerte Design, zuverlässig, aber quälend langsam.
15:06
Mit Unterstützung durch Agenten skizzieren Sie die Idee in natürlichen Worten, das Grundgerüst erscheint
15:10
und Sie können fast so schnell iterieren wie beim Vibe-Coding,
15:12
während Sie die Vorteile einer organisierten Struktur beibehalten.
15:14
Nehmen noch einmal diesen Reporting-Workflow.
15:15
Normalerweise müssten Sie das Modell herstellen, den Datendienst aufbauen,
15:19
den Controller verdrahten, die Sicherheit konfigurieren und alles beim Start verbinden.
15:23
Das bedeutet, durch mehrere Dateien zu springen und zu hoffen, dass die Konsistenz gewandt bleibt.
15:27
Mit diesem Ansatz landet das Grundgerüst sofort an der richtigen Stelle.
15:29
Die wirkliche Ersparnis liegt weniger im Tippen, weniger Zeilen,
15:32
sondern darin, Fehler zwischen den Dateien zu vermeiden.
15:34
Etwa wenn man vergisst, einen neuen Dienst nach dem Erstellen zu registrieren.
15:37
Natürlich gibt es immer die Frage des Deals.
15:38
Wird eine KI Standardcode erzwingen oder konventionloser Kraft setzen?
15:42
In der Praxis spiegeln Agenten in ihren Vorschlägen oft bestehende Projektmuster wieder.
15:46
In der Demo werden Sie beide Seiten sehen.
15:48
Stellen, an denen die Controllerstruktur perfekt mit der unseres Teams übereinstimmte
15:51
und Stellen, an denen die Vermutungen daneben lagen.
15:54
Diese Mischung ist wichtig.
15:55
Sie werden wissen, was Sie vertrauen können und was Sie noch anpassen müssen.
15:58
Das Endergebnis ist kein 0815.
16:00
Es fühlt Sie immer noch wie Ihr Projekt an, nur mit weniger manueller Arbeit am Grundgerüst.
16:04
Sie behalten Ihre Geschwindigkeit bei und verlassen sich gleichzeitig auf ein Fundament,
16:06
das Sie für zukünftiges Wachstum verfeinern können.
16:09
Statt dass Spezifikationsarbeit auf Architekten mit Geduld für Diagramme beschränkt bleibt,
16:12
wird Sie zu einem Werkzeug für jeden Entwickler, der schnell experimentieren will, ohne die Ordnung zu opfern.
16:18
Und wenn dies Teil Ihres täglichen Arbeitsablaufs wird,
16:20
fühlt sich die Spezifikation nicht mehr wie ein formeller Unternehmensschritt an,
16:22
sondern wie eine leichtgewichtige Kurzschrift.
16:25
Sie beschreiben Ihre Absicht, das System legt den Grundstein
16:27
und Sie konzentrieren sich darauf, die Details auszuarbeiten.
16:29
Die größere Wirkung entsteht nicht nur durch den Code, den Sie generieren,
16:32
sondern durch das, was die Zeitersparnis Woche für Woche bedeutet.
16:35
Mehr Stunden für Funktionen, weniger Mühe sei bei der Einrichtung.
16:37
Das bringt uns direkt zu der Frage, die jedem Entwickler am meisten am Herzen liegt.
16:41
Was diese Änderungen in Bezug auf die Produktivität tatsächlich ausmachen.
16:45
Die Produktivitätsaustellung.
16:47
Die eigentliche Frage ist nicht, ob Sie hier und da ein paar Minuten sparen,
16:49
sondern wie sich diese kleinen Verschiebungen über eine Woche hinweg zu bedeutenden Stunden summieren.
16:55
Dies ist die Produktivitätsaustellung.
16:56
Zeit zurückgewinnen, die normalerweise unbemerkt durch Kontextwechsel,
16:59
wiederholte Bildzyklen und manuelle Korrekturen verloren geht.
17:02
Die meisten Entwickler akzeptieren diese kleinen Verluste einfach als Teil der Arbeit.
17:05
10 Minuten hier, um einem Konfigurationswert nachzujagen,
17:08
weitere 15 Minuten für einen erneuten Lauf nach einer fehlenden Referenz
17:10
oder das Springen zwischen Dateien und Verbindungen zu bieten.
17:12
Für sich genommen wirken Sie geringfügig.
17:14
Aber zusammengerechnet über einen ganzen Sprint hinweg,
17:16
bestimmen Sie, wie viel tatsächlicher Wert geliefert wird.
17:18
Was wie Routinebewegungen aussieht, verbirgt eine echte Verzögerung bei den Lieferzeiten.
17:22
Das versteckte Gewicht liegt nicht in Kompilierzeiten oder Tippgeschwindigkeit.
17:25
Es liegt im Stopp-Start-Rhythmus der Ihrer Konzentration aufgezwungen.
17:27
Jedes Mal, wenn Sie von einer Datei zur anderen wechseln, setzt Ihr Gehirn neu an.
17:31
Dieser reset hat seinen Preis.
17:32
Das Auslagern repetitiver Korrekturen an einen Agenten erleichtert diese Last.
17:35
Anstatt ständig den Kontext neu aufzubauen, investieren Sie Fokus dort, wo es zählt,
17:40
beim Lösen der größeren Designprobleme.
17:42
Viele Teams verfolgen diese Mikrokosten nicht,
17:44
weil sie nicht in Jira-Tickets oder der Git-Historie erscheinen.
17:47
Arbeit, die zu nichts führt, wird nicht protokolliert, verbraucht aber dennoch Energie.
17:50
Und während Codebasen skalieren, addiert sich diese Reibung nicht nur linear.
17:53
Mehr Ebenen bedeuten mehr Abhängigkeiten, die man im Gedächtnis behalten muss
17:56
und mehr Möglichkeiten, Zeit allein damit zu verlieren, die Struktur anzugleichen,
17:58
die Struppe anzugleichen, bevor es weitergehen kann.
18:00
Agenten-Workflows ändern die Rechnung, indem Sie diese Schwachstellen direkt annehmen.
18:03
Sie füllen nicht nur Methoden stubschneller aus.
18:05
Sie reduzieren die Schleifen des Suchens, Korrigierens und erneuten Ausführens die ganze Nachmittage verschlingen.
18:09
Teams, die Agenten-Workflows nutzen, berichten in vielen Fällen von kürzeren Zeiten bis zur Problemlösung.
18:14
In diesem Video demonstrieren wir eine Vorher-Nachher-Aufgabe, damit Sie den Einfluss beurteilen können.
18:18
Ich werde die Zeit stoppen, die benötigt wird, um dieselbe Azure-Funktion manuell
18:21
und dann erneut mit dem Agenten zu implementieren, damit Sie den Produktivitätsgewinn konkret sehen können.
18:25
Aus geschäftlicher Sicht zeigt sich der Mehrwert in der Projektgeschwindigkeit.
18:29
Schnellere Zyklen bedeuten nicht nur mehr Zufriedenheit für Entwickler.
18:32
Sie entscheiden, ob Funktionen mit diesem Release erscheinen oder sich um Quartale verschieben.
18:35
Sie beeinflussen technische Schulden, da weniger Hacks und Regressionen in den Backlog wandern.
18:39
Ein reibungsloserer Ablauf erlaubt Teams, sauber voranzukommen,
18:42
statt kaputte Arbeit aus dem vorherigen Sprint zu korrigieren.
18:45
Diese Beständigkeit führt mit der Zeit zu weniger Feuerlöschen und einer stärkeren Bereitstellung.
18:48
Es gibt auch den menschlichen Faktor.
18:50
Ein Tag, der mit Fehlersuche verloren geht, erschöpft jeden Ingenieur.
18:53
Ist man erst einmal ermüdet, wird sauberes Design schwieriger, Details entfallen und Fehler schleichen sich ein.
18:58
Indem man mechanische Korrekturen an einen Agenten abgibt, bleiben Entwickler länger konzentriert.
19:02
Dieser zusätzliche Fokus schärft sowohl die Produktivität als auch die Qualität.
19:06
Wenn man nicht durch ständige Reibungsverluste ausgebremst wird, kann man freier denken und effektiver planen.
19:11
Der Unterschied in der Praxis sieht so aus.
19:12
Eine neue Azure-Funktion mit mehreren Bindungen und Service-Integrationen kann ohne Hilfe zwei volle Tage dauern.
19:18
Zwischen Konfiguration, Tests und dem Zurückverfolgen fehlerhafter Referenzen zieht sich die Aufgabe in die Länge.
19:24
Mit der Hilfe eines Agenten kann dieselbe Funktion in einem halben Tag entstehen.
19:27
Nicht, weil man sich Arbeit leicht macht, sondern weil das dateiübergreifende Setup und die Orchestrierung auf Anhieb sitzen.
19:32
Der Zeitplan verkürzt sich durch das Vermeiden von Fehlstarts und redundanter Arbeit.
19:36
Einige Entwickler äußern Berechtebedenken.
19:38
Dumpfen die eigenen Fähigkeiten ab, wenn man sich bei der Wartung auf KI verlässt.
19:41
Diese Perspektive übersieht oft, was sich tatsächlich verändert.
19:44
Das Auslagern repetitiver Aufgaben schwächt nicht die Expertise, sondern schont sie für Design und Architektur beurteilt.
19:48
Entscheidungsvermögen entscheidend ist.
19:50
In Wirklichkeit gewinnt man Raum für anspruchsvollere Problemlösungen, statt Energie mit Korrekturen zu verschwenden.
19:55
Wenn Sie dies ausprobieren, schreiben Sie in die Kommentare, wie viele Stunden Sie pro Spann zurückgewandt.
19:58
Ich werde interessante Antworten in zukünftige Videos einbauen.
20:00
Zu hören, wie andere Teams den Wandel erleben, gibt jedem ein besseres Bild des echten Mehrwerts jenseits von Demos und Beispielen.
20:07
Ein vorsichtiger Hinweis jedoch, Automatisierung hilft, aber Sicherheit ist weiter nicht.
20:10
Führen Sie immer Ihre Tests durch und nutzen Sie Code-Reviews, um von Agenten erstellte Änderungen zu validieren.
20:14
Ertrauen Sie darauf, dass lästige Arbeit reduziert wird, aber behalten Sie die bestehende Sicherheitsvorkehrungen.
20:18
Der Geschwindigkeitsvorteil zahlt sich nur aus, wenn die Qualität stabil bleibt.
20:21
Starke Tests und kluge PR-Reviews schützen Ihre Release-Pipeline vor anfälliger Automatisierung.
20:25
Der Gewinn liegt weniger darin, Zeilen schnell zu produzieren, sondern mehr darin, Raum für bessere Lösungen zu schaffen.
20:31
Weniger Ermüdung und weniger.