WEBVTT 00:00:00.240 --> 00:00:06.720 Bereit für 10 Tage voller Microsoft 365, Co-Pilot, KI-Escher und den Vordenkern, die die Zukunft der Arbeit gestalten? 00:00:07.780 --> 00:00:11.780 Diesen Januar ist die M2 in 1260-Con zurück und wir legen noch eine Schippe drauf. 00:00:12.980 --> 00:00:17.880 Seien Sie dabei bei Live-Sessions, Praxis-Demos und Expertenwissen von MVPs und Branchenprofis aus aller Welt. 00:00:18.840 --> 00:00:21.160 Keine generischen Folien, kein endloses Buzzword-Bingo. 00:00:22.020 --> 00:00:23.760 Wir gehen die echten Herausforderungen an. 00:00:23.900 --> 00:00:28.560 Co-Pilot Studio, KI-Agenten, Fabrik, Sicherheit, Governance und Automatisierung. 00:00:28.560 --> 00:00:33.620 Egal ob IT-Profi, Entwickler oder Führungskraft, wir haben die passenden Sessions für Sie. 00:00:35.120 --> 00:00:39.900 An 10 vollen Tagen können Sie Technologien erkunden und sich mit einer globalen Community vernetzen. 00:00:40.960 --> 00:00:44.300 Schauen Sie live zu und nehmen Sie praktische Erkenntnisse mit in Ihr Unternehmen. 00:00:45.100 --> 00:00:48.940 Januar 2027, 10 Tage, eine Microsoft-Community. 00:00:49.400 --> 00:00:50.520 Die Registrierung ist jetzt geöffnet. 00:00:51.560 --> 00:00:55.560 Besuchen Sie m365con.net und sichern Sie sich noch heute Ihren Platz. 00:00:55.560 --> 00:00:58.740 Das ist m365con.net. 00:01:00.060 --> 00:01:03.040 Melden Sie sich jetzt auf m365con.net an. 00:01:03.660 --> 00:01:04.740 Wir sehen uns live im Januar. 00:01:05.260 --> 00:01:11.020 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. 00:01:11.360 --> 00:01:12.120 Sind Sie damit nicht allein? 00:01:12.420 --> 00:01:14.820 Die meisten Entwickler arbeiten reaktiv wie ein Patch dort ein Debugging. 00:01:15.260 --> 00:01:19.840 Der Agentenmodus von GitHub-Copilot zielt darauf ab, einen breiteren Kontext zu erfassen und Änderungen teilübergreifend zu koordinieren. 00:01:19.840 --> 00:01:24.840 In diesem Video zeigen wir, wie dieser Workflow in einem echten .net und Azure-Projekt aussieht. 00:01:25.300 --> 00:01:28.340 Wir gehen eine Live-Lösung durch und zeigen den Zustand vor und nach den Änderungen durch den Erkenntnis. 00:01:28.720 --> 00:01:35.820 Sie sehen, wie Sie dateiübergreifenden Code mit weniger Aufwand erstellen, Fehler schneller beheben und sogar eine einfache Beschreibung nutzen, um Funktionen zu entwickeln. 00:01:36.680 --> 00:01:40.980 Bevor wir dazu kommen, schauen wir uns die versteckten Kosten der Debugging-Schleife an, in der viele von uns täglich feststecken. 00:01:41.660 --> 00:01:43.380 Die versteckten Kosten von Flicken-Debugging. 00:01:43.780 --> 00:01:45.880 Sie setzen sich hin, um einen scheinbar einfachen Fehler zu beheben. 00:01:46.520 --> 00:01:50.040 Die Anwendung lässt sich nicht erstellen und die Konsole markiert eine Zahl in Ihrer Hauptprojektattach. 00:01:50.660 --> 00:01:55.880 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. 00:01:56.320 --> 00:01:59.260 Eine weitere halbe Stunde verstreicht, bevor Sie das eigentliche Problem entdecken. 00:01:59.700 --> 00:02:02.080 Eine fehlende Abhängigkeit versteckt in einem anderen Projektordner. 00:02:02.700 --> 00:02:07.000 Bis die Referenz korrigiert ist und Sie neu bereitgestellt haben, ist der Großteil des Nachmittags mit Flickenarbeit verflogen. 00:02:07.500 --> 00:02:09.780 Die geplante Arbeit an neuen Funktionen wird auf morgen verschoben. 00:02:09.780 --> 00:02:12.080 Dieses Muster ist so verbreitet, dass es sich schon normal anfühlt. 00:02:12.500 --> 00:02:15.600 Oberflächlich betrachtet kommen Sie voran, weil jeder behobene Fehler wie ein Erfolg wirkt. 00:02:16.020 --> 00:02:17.500 In der Praxis drehen Sie sich jedoch im Kreis. 00:02:17.820 --> 00:02:20.700 Die Schleife lautet Programmieren, Kompilieren, Fehler, Korrektur, Wiederholung. 00:02:21.100 --> 00:02:26.500 Stunden verschwinden bei der Verfolgung von Ursache und Wirkung und das Nettoergebnis ist eher reaktiver Fortschritt statt echter Verbesserungen. 00:02:27.180 --> 00:02:29.400 Wie viele von Ihnen haben schon einen ganzen Nachmittag in genau dieser Schleife verloren? 00:02:29.740 --> 00:02:31.940 Hinterlasst einen kurzen Kommentar, ich werde die besten Antworten durchlesen. 00:02:32.820 --> 00:02:36.840 Was diesen Kreislauf so erschöpfend macht, ist, dass sich die Tools um uns herum weiterentwickeln, das Muster jedoch nicht. 00:02:36.840 --> 00:02:43.580 Editoren erhalten neue Funktionen, Frameworks entwickeln sich weiter und Integrationen werden tiefer, aber das Debugging erfordert immer noch einen reaktiven Ansatz. 00:02:44.040 --> 00:02:46.600 Es ist, als würde man versuchen, ein wachsendes Feuer mit einem Eimer Wasser aufzuhalten. 00:02:47.420 --> 00:02:52.220 Jeder Aufflackern wird im Moment gelöst, aber die zugrunde liegenden Bedingungen bleiben bestehen und garantieren fast den nächsten Brand. 00:02:53.060 --> 00:02:55.060 Und mit jedem Tab-Wechsel steigen die versteckten Kosten. 00:02:55.620 --> 00:02:58.840 Man wechselt von einer Serviceklasse in eine Konfigurationsdatei und springt dann zu einem Abhängigkeitsgrafen. 00:02:58.840 --> 00:03:03.960 Jeder Wechsel reißt einen aus dem Gedankengang heraus und erzwingt einen mentalen Reset. 00:03:04.560 --> 00:03:09.520 Es sind nicht nur die Sekunden, die man mit dem Fensterwechsel verbringt, sondern die geistige Belastung, den Kontext immer wieder neu aufzubauen. 00:03:10.180 --> 00:03:12.660 Über einen Tag hinweg summieren sich diese kleinen Resets zu etwas Schwerwiegendem. 00:03:13.220 --> 00:03:16.280 Für einzelne Entwickler äußert sich die Erschöpfung in Frustration und Zeitverschwendung. 00:03:17.260 --> 00:03:19.780 Für Teams, die an Unternehmensprojekten arbeiten, potenziert sich der Effekt. 00:03:20.520 --> 00:03:26.220 Debugging-Schleifen bringen Sprintziele vom Kurs ab, verzögern Feature-Launches und lassen einen Backlog wachsen, der schneller wächst, als er schrumpft. 00:03:26.220 --> 00:03:30.680 Die Zunahme technischer Schulden ist nur ein weiterer Nebeneffekt der Stunden, die mit Brandbekämpfung verloren gehen. 00:03:31.560 --> 00:03:35.600 Viele Teams berichten, dass ein großer Teil ihrer Entwicklungszeit in reaktives Debugging abfließt. 00:03:35.960 --> 00:03:37.340 Das ist nicht der aufregende Teil des Engineering. 00:03:37.820 --> 00:03:41.520 Niemand plant eine Roadmap, um die fünfmalige Verfolgung desselben Abhängigkeitskonflikts zu holen. 00:03:41.880 --> 00:03:43.800 Doch genau hier landet die Bandbreite Woche für Woche. 00:03:44.760 --> 00:03:51.200 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. 00:03:51.680 --> 00:03:54.800 Die unbequeme Wahrheit ist, dass Flicken von Fehlern die Dinge nicht nur verlangsamt. 00:03:54.800 --> 00:03:58.140 Es festigt eine Kultur der Reaktion anstatt der Gestaltung. 00:03:58.680 --> 00:04:01.540 Man verbringt Zeit damit, Flammen zu löschen, anstatt Systeme zu konstruieren. 00:04:02.380 --> 00:04:07.300 Das mag das Produkt kurzfristig am Leben erhalten, aber es begrenzt, wie weit ein Team skalieren und wie sicher es liefern kann. 00:04:08.040 --> 00:04:09.800 Bleiben wir also kurz bei diesem Bild. Brandbekämpfung. 00:04:10.500 --> 00:04:12.220 Zum Brandherd eilen, Wasser drauf, weiter geht's. 00:04:12.800 --> 00:04:15.380 Das Problem ist nicht, dass Entwickler nicht gut darin wären. Das sind sie. 00:04:15.380 --> 00:04:17.840 Das Problem ist, dass die Flammen nie wirklich aufhören. 00:04:18.420 --> 00:04:24.280 Sie wandern nur umher, flackern in neuen Dateien, neuen Projekten, neuen Konfigurationen auf und halten alle im Reaktionsmodus statt im Erstellungsmodus. 00:04:25.220 --> 00:04:28.400 Das wirft die Frage auf, was passiert, wenn dieser Kreislauf nicht allein auf dir lastet? 00:04:29.460 --> 00:04:36.140 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? 00:04:36.140 --> 00:04:40.920 Denn während die Belastung durch die Brandbekämpfung offensichtlich ist, gibt es noch einen anderen Druckpunkt, den du bisher nicht angesprochen hast. 00:04:41.300 --> 00:04:44.520 Die wahre Herausforderung beginnt, wenn der Projekt nicht nur aus einer Datei oder einem Modul besteht. 00:04:45.180 --> 00:04:47.700 Dann, wenn der nötige Fix mehrere Ebenen gleichzeitig betrifft. 00:04:48.420 --> 00:04:53.720 Stellen Sie sich vor, Sie öffnen eine Lösung, deren Logik sich über verschiedene Projekte, Dienste und Bibliotheken erstreckte. 00:04:54.860 --> 00:04:59.660 Das benötigte Teil existiert an drei Stellen gleichzeitig und den Überblick zu behalten ist ein Kampf für sich. 00:05:01.280 --> 00:05:03.340 Multify Chaos vs. KI-Kontext-Kontrolle 00:05:03.340 --> 00:05:08.080 Wenn Projekte mehrere Ebenen umspannen, ist das eigentliche Problem nicht das Programmieren. 00:05:08.680 --> 00:05:10.400 Es ist das Zusammenhalten aller beweglichen Teile. 00:05:10.980 --> 00:05:15.340 Hier zeigt sich die Spannung zwischen Multify Chaos und KI-gestützter Kontext-Kontrolle am deutlichsten. 00:05:16.300 --> 00:05:18.940 Nehmen Sie eine große Docknet-Lösung mit einem Dutzend oder mehr Projekten? 00:05:19.540 --> 00:05:21.700 Jedes neue Feature berührt meist verschiedene Ebenen zugleich. 00:05:22.320 --> 00:05:27.460 Ein Controller hier, ein Service dort und eine Reihe von Konfigurationsdateien, die ganz woanders liegen, die ganz woanders liegen. 00:05:27.760 --> 00:05:32.040 Bevor Sie eine Zeile schreiben, verbringen Sie Zeit damit, Referenzen nachzuverfolgen und Abhängigkeiten zu prüfen, 00:05:32.040 --> 00:05:35.120 in der Hoffnung, dass eine kleine Änderung keine unerwarteten Fehler in der Kette auslöst. 00:05:35.720 --> 00:05:37.240 Dieser Arbeitsablauf ist keine Ausnahme. 00:05:37.660 --> 00:05:41.620 Er ist normal bei Unternehmensanwendungen, besonders sobald Azure-Dienste und Integration ins Spiel kommen. 00:05:42.660 --> 00:05:44.440 Die Struktur dieser Systeme ist nicht flach. 00:05:45.440 --> 00:05:49.240 Schnittstellen, Dependency-Injection-Mappings und projektübergreifende Referenzen spielen alle eine Rolle. 00:05:49.240 --> 00:05:53.180 Mit Azure im Mix verlassen einige Abhängigkeiten den Lösungsordner komplett. 00:05:53.340 --> 00:05:58.320 Function-Apps, Service-Boss-Bindings, Ressourceneinstellungen, Speicherverbindungen, Speicherverbindungen. 00:05:58.940 --> 00:06:03.520 Sie koordinieren Code in Ihrer IDE, Konfigurationsdateien auf der Festplatte und Dienste in der Cloud. 00:06:04.220 --> 00:06:06.220 Keinem davon ist es wichtig, dass Sie weniger Klicks bevorzugen werden. 00:06:06.580 --> 00:06:10.100 Jedes Mal, wenn Sie den Kontext wechseln, verbrauchen Sie Energie, um das Gesamtbild neu zu rekonstruieren. 00:06:10.600 --> 00:06:12.920 Die meisten von uns versuchen, diesen Kontext im Arbeitsspeicher zu jonglieren. 00:06:12.920 --> 00:06:16.560 Anfangs ist das machbar, doch mit dem Wachstum des Projekts schleichen sich Fehler ein. 00:06:16.940 --> 00:06:19.540 Sie fügen eine neue Methode im Service hinzu, vergessen aber deren DIY-Restrierung. 00:06:19.900 --> 00:06:25.040 Sie programmieren eine Azure-Funktion und bemerken erst später, dass das Binding nie in die Hostung desen oder das Deployment-Template aufgenommen wurde. 00:06:25.500 --> 00:06:28.260 Nichts warnt Sie bis zur Laufzeit, wenn Sie plötzlich Debuggen anstatt zu entwickeln. 00:06:28.800 --> 00:06:30.100 Der Code an sich ist nicht der schwierige Teil. 00:06:30.440 --> 00:06:31.720 Es ist die dateiübergreifende Koordination. 00:06:32.120 --> 00:06:37.480 Jeder kennt das Gefühl, durch Tabs zu springen vom Controller zum Service, zum Modell, in Konfigurationsdateien und wieder zurück. 00:06:37.480 --> 00:06:41.020 Nur um dann zu vergessen, warum man die Datei überhaupt geöffnet hatte. 00:06:41.020 --> 00:06:44.480 Es ist eine kleine Unterbrechung, die sich dutzende Male am Tag wiederholt. 00:06:45.160 --> 00:06:48.220 Diese Interaktionen summieren sich und erzeugen Reibung, die den Fortschritt bremst. 00:06:48.920 --> 00:06:53.800 Das Ergebnis ist eine langsamere Bereitstellung, nicht weil das Schreiben langsam ist, sondern weil das Synchronisieren den Fokus raubt. 00:06:54.400 --> 00:06:56.300 Dieser Aufwand wächst bei Cloud-First-Projekten. 00:06:57.300 --> 00:06:59.700 Azure verteilt wichtige Einstellungen auf mehrere Orte. 00:07:00.260 --> 00:07:05.940 Lokale Konfigurationsdateien, Umgebungsvariablen, ARM- oder BICEP-Templates und CI-CD-Pipelines. 00:07:06.660 --> 00:07:10.440 Was wie eine einfache Feature-Anfrage aussieht, erstreckt sich oft über vier Abstraktionsebene. 00:07:11.020 --> 00:07:12.460 Diese Komplexität ist nicht optional. 00:07:12.920 --> 00:07:14.880 Sie ist fest in der Funktionsweise des Ökosystems Funke. 00:07:15.300 --> 00:07:17.740 Genau hier stellt der Agentenmodus eine potenzielle Veränderung dar. 00:07:18.160 --> 00:07:22.600 Anstatt die gesamte Orchestrierung Ihnen zu überlassen, ist er darauf ausgelegt, einen breiteren Kontext über mehrere Dateien hinweg zu behalten. 00:07:23.200 --> 00:07:26.520 Das bedeutet, wenn Sie eine Änderung auf einer Ebene anfordern, werden die anderen nicht ignoriert. 00:07:27.200 --> 00:07:34.020 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. 00:07:34.020 --> 00:07:37.660 JSON und sogar die korrekte DI-Registrierung vorschlägt. 00:07:38.180 --> 00:07:41.000 Normalerweise ist das ein mehrstufiger Prozess, der über verschiedene Dateien verstreut ist. 00:07:41.380 --> 00:07:43.160 Ein Agent kann dies in einem einzigen Ablauf optimieren. 00:07:43.880 --> 00:07:49.980 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. 00:07:50.780 --> 00:07:53.860 Menschen können sich eine grobe Skizze im Kopf behalten oder auf einem Whiteboard notieren. 00:07:54.660 --> 00:07:57.760 Eine KI kann die Details Datei für Datei verfolgen, ohne den Faden zu verlieren. 00:07:57.760 --> 00:08:01.820 Was für uns eine enorme kognitive Belastung darstellt, ist für den Agenten nur grundlegender Kontext. 00:08:02.340 --> 00:08:06.860 Der Unterschied in der Praxis liegt im Wechsel vom fragmentierten Tab-Jongelieren hin zu orchestrierten Änderungen, die synchron bleiben. 00:08:07.300 --> 00:08:12.440 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. 00:08:12.880 --> 00:08:13.740 Diese Sichtbarkeit ist wichtig. 00:08:14.160 --> 00:08:18.600 Sie behalten die volle Kontrolle zur Überprüfung und Freigabe, während die Arbeit bei der Aktualisierung mehrere Dateien für Sie erledigt wird. 00:08:19.060 --> 00:08:25.320 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. 00:08:25.320 --> 00:08:33.600 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. 00:08:34.480 --> 00:08:41.820 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. 00:08:42.440 --> 00:08:46.600 Und genau da beginnt der nächste Test, wie Fehler aufgespürt und behoben werden, sobald sie auftreten. 00:08:47.720 --> 00:08:49.100 Von der Fehlersuche hin zu autonom korrekt. 00:08:49.560 --> 00:08:53.280 Denken Sie daran, wie oft Sie auf eine Fehlermeldung stoßen, die direkt auf eine einzige Datei verweist. 00:08:53.280 --> 00:08:57.700 Sie folgen im Stacktrace zu der genannten Methode, nehmen eine kleine Anpassung vor und starten den Bild neu. 00:08:58.540 --> 00:09:03.000 Es fühlt sich wie die offensichtliche Lösung an, bis derselbe Fehler wieder auftaucht, nur in einer etwas anderen Form. 00:09:03.660 --> 00:09:05.820 Dann erkennen Sie, dass der Stacktrace nur das Symptom gezeigt hat. 00:09:06.520 --> 00:09:11.680 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. 00:09:12.080 --> 00:09:14.120 Jeder Entwickler stand schon einmal vor dieser Art von Irreführung. 00:09:14.480 --> 00:09:16.780 Was wie das Problem aussieht, ist oft nicht der Ort, an dem die Lösung liegt. 00:09:17.120 --> 00:09:17.900 Das frisst schnell Zeit. 00:09:17.900 --> 00:09:19.840 Man passt etwas an, baut neu, wartet. 00:09:20.620 --> 00:09:24.400 Dann begrüßt einen ein neuer Fehler, der zu einer anderen Datei einer weiteren Anpassung und einem erneuten Bild führt. 00:09:25.120 --> 00:09:28.120 Diese Schleife wirkt produktiv, weil man sich bewegt, tippt und neu kompiliert. 00:09:28.500 --> 00:09:31.600 Aber eigentlich ist es eher Herumprobieren als echte Problemlösung. 00:09:32.380 --> 00:09:38.040 Dieser Kreislauf kann Stunden verschlingen und hinterlässt nur kleine Korrekturen an der Oberfläche, statt das ursprüngliche Feature voranzubringen. 00:09:38.320 --> 00:09:40.420 Gag, die eigentlichen Kosten liegen in der verpassten Chance. 00:09:40.420 --> 00:09:46.880 Während man im Rhythmus von Neubauen und Wiederholen feststeckt, löst man keine Geschäftsprobleme und liefert keine Funktionen, auf die Nutzer warten. 00:09:48.080 --> 00:09:50.040 Die Energie fließt in Vermutungen statt in die Entwicklung. 00:09:50.480 --> 00:09:55.140 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. 00:09:56.200 --> 00:10:00.980 Im Team bremst diese oberflächliche Betriebsamkeit alles aus und erzeugt einen Berg an Features, die immer weiter aufgeschoben werden. 00:10:01.400 --> 00:10:01.680 Erden. 00:10:02.520 --> 00:10:04.480 Hier beginnt ein Agent-Workflow anders zu wirken. 00:10:04.940 --> 00:10:07.480 Die Idee ist, nicht bei der einen Zeile stehen zu bleiben, wie der Stacktrace hervorhebt. 00:10:07.480 --> 00:10:13.260 Stattdessen ist er darauf ausgelegt, Systemkontext zu erfassen und zu fragen, nicht nur, was diese Datei tun soll, 00:10:13.780 --> 00:10:17.640 sondern welche Änderungen über verbundene Teile hinweg nötig sind, um Konsistenz wiederherzustellen. 00:10:18.480 --> 00:10:21.800 In der Praxis bedeutet das, dass er Änderungen vorschlagen kann, die mehrere Dateien betreffen. 00:10:22.420 --> 00:10:28.820 Im Demo-Beispiel sehen Sie zum Beispiel, wenn eine Methode Änderungen erfordert, kann er passende Anpassungen zu gehörigen Configs oder Deployment-Templates vorschlagen, 00:10:29.260 --> 00:10:30.460 statt dass Sie diese selbst suchen müssen. 00:10:31.000 --> 00:10:33.060 Das ist der Sprung von Autocomplete zu etwas Umfassenderem. 00:10:34.240 --> 00:10:37.140 Autocomplete ergänzt Zeilen, ein Agent koordiniert Dateiübergreifend. 00:10:37.480 --> 00:10:40.440 Und diese Koordination ist besonders wichtig, wenn Fehler nicht ordentlich an einem Ort liegen. 00:10:40.920 --> 00:10:42.060 Nehmen wir ein typisches Azure-Szenario. 00:10:42.720 --> 00:10:45.940 Sie haben eine neue Function-App erstellt, aber nach dem Deployment schlägt der Cure-Trigger fehl, 00:10:46.000 --> 00:10:47.740 weil das Binding nicht zur Methodensignatur passt. 00:10:47.740 --> 00:10:56.500 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. 00:10:57.820 --> 00:11:01.160 Jeder Schritt ist eine eigene Suche und jede Korrektur löst einen weiteren Testlauf aus. 00:11:02.060 --> 00:11:03.680 Im Agent-Modus ist der Workflow anders. 00:11:04.180 --> 00:11:10.100 Er kann die Codeänderung vorschlagen, das korrekte Function-JSON-Binding generieren und Anpassungen für Deployment-Skripte vorschlagen, falls diese nicht übereinstimmen. 00:11:10.700 --> 00:11:14.480 Sie prüfen, bestätigen und kommen voran, ohne Stunden damit zu verbringen, jede Ebene einzeln zusammenzusetzen. 00:11:14.800 --> 00:11:15.560 Und Vertrauen ist hier der Schlüssel. 00:11:16.060 --> 00:11:18.840 Niemand sollte das Gefühl haben, dass im Hintergrund unsichtbare Änderungen vorgenommen werden. 00:11:19.080 --> 00:11:20.100 Der Cell-Review-Prozess so wichtig? 00:11:20.620 --> 00:11:21.920 In dieser Demo gehen wir das gemeinsam durch. 00:11:22.460 --> 00:11:24.160 Der Agent schlägt die koordinierten Änderungen vor. 00:11:24.280 --> 00:11:32.420 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. 00:11:33.460 --> 00:11:36.760 Diese Validierungsschleife lässt Ihnen die volle Kontrolle, während Sie in die mühsame Arbeit abnehmen. 00:11:36.760 --> 00:11:41.860 Es ist wichtig zu betonen, Agenten können helfen, schneller zu arbeiten, aber sie ersetzen keine bewährten technischen Praktiken. 00:11:42.460 --> 00:11:45.300 Code-Reviews und CI sollten für Sie nach wie vor unverhandelbare Kontrollinstanz bleiben. 00:11:45.680 --> 00:11:51.060 Lassen Sie die KI die Zeit für Detektivarbeit verkürzen, aber behalten Sie automatisierte Prüfungen und menschliche Überprüfungen als Sicherheitsnetz bei. 00:11:51.560 --> 00:11:55.440 Dieses Gleichgewicht löst das Vertrauensproblem und stellt sicher, dass der Geschwindigkeitsvorteil die Stabilität nicht gefährdet. 00:11:56.040 --> 00:11:57.680 Der Geschwindigkeitsunterschied ist nicht rein theoretisch. 00:11:58.120 --> 00:12:02.460 Wo Fehlersuche und manuelle Patches einen halben Tag kosten können, reduzieren koordinierte Vorschläge dies auf Minuten. 00:12:02.460 --> 00:12:07.140 Und die wiedergewonnene Zeit fließt zurück in die Arbeit, in die Sie tatsächlich Energie investieren möchten. 00:12:07.660 --> 00:12:11.100 In die Funktionen, die Ihre Nutzer bemerken und in die Architekturentscheidungen, die Ihre Code-Basis verbessern. 00:12:11.780 --> 00:12:15.100 Anstatt zur Laufzeit ständig Brände zu löschen, können Sie von vornherein mit Zuversicht designen. 00:12:15.580 --> 00:12:17.720 So muss die Debugging-Schleife Ihren Arbeitstag nicht mehr bestimmen. 00:12:18.360 --> 00:12:23.460 Mit einem Agenten, der dateiübergreifende Updates vorschlägt, wechseln Sie von zielloser Suche zu einem Rhythmus aus Überprüfen und Freigeben. 00:12:23.460 --> 00:12:29.680 Sie hören auf, im Kreis durch Fehler zu irren und beginnen, Debugging als strukturierten, fast automatisierten Schritt in Ihrem Workflow zu betrachten. 00:12:30.460 --> 00:12:34.440 Dieser Bundle schafft kognitiven Freiraum und Zeit für die Entwicklung neuer Funktionen, anstatt nur Mängel zu beheben. 00:12:34.960 --> 00:12:38.980 Und sobald Fehlerbehebung weniger zum Jagen von Symptomen wird, öffnet sich die Tür für etwas Größeres, 00:12:39.780 --> 00:12:42.220 wie Sie ganze Funktionen auf die gleiche strukturierte Weise starten könnten. 00:12:43.000 --> 00:12:46.280 Stellen Sie sich vor, derselbe Workflow, der koordinierte Korrekturen vorschlägt, 00:12:46.500 --> 00:12:50.180 könnte auch eine Spezifikation in einfacher Sprache nehmen und daraus eine funktionierende Struktur formen. 00:12:50.480 --> 00:12:52.480 Hier beginnt die nächste Stufe der Entwicklung. 00:12:54.120 --> 00:12:55.520 Spezifikationsgetriebene Entwicklung ohne den Administrativen. 00:12:55.860 --> 00:13:00.400 Einer der interessantesten Wechsel findet statt, wenn Sie aufhören, nur in Dateien und Methoden zu denken und stattdessen beginnen, 00:13:00.720 --> 00:13:02.320 Arbeit in einfacher Sprache zu formulieren. 00:13:03.160 --> 00:13:05.840 Genau hier kommt die spezifikationsgetriebene Entwicklung ohne den Overhead ins Spiel. 00:13:06.260 --> 00:13:07.960 Stellen Sie sich vor, Sie schreiben eine einfache Feature-Anfrage. 00:13:08.480 --> 00:13:13.820 Füge einen Reporting-Workflow hinzu, der monatliche Zusammenfassungen erstellt, speichert und sie über eine Admin-Seite verfügbar macht. 00:13:14.520 --> 00:13:16.340 Anstatt nur ein paar isolierte Schnipsel zu erhalten, 00:13:16.800 --> 00:13:19.540 bekommen Sie eine funktionierende Struktur, die bereits über Ihre App hinweg verknüpft ist. 00:13:19.540 --> 00:13:23.820 Controller angelegt, Modelle erstellt, Services registriert und die Konfiguration eingebunden. 00:13:24.780 --> 00:13:28.720 Dieser Schritt vom Beschreiben der Absicht hin zum konkreten Grundgerüst in Ihrem Projekt ist der Moment, 00:13:28.840 --> 00:13:31.620 in dem sich dieser Ansatz endlich praktisch statt theoretisch anfühlt. 00:13:31.620 --> 00:13:35.400 In traditionellen Umgebungen hat Spec-First-Entwicklung einen eher schwerfälligen Ruf. 00:13:35.840 --> 00:13:41.860 In großen Unternehmen bedeutet das meist lange Anforderungsdokumente, mehrseitige Design-Sheets und starre Diagramme, die jeden verlangsamen. 00:13:42.360 --> 00:13:44.800 Sie ergeben Sinn in regulierten Branchen oder global verteilten Teams, 00:13:44.900 --> 00:13:47.280 aber im alltäglichen Programmieren lassen die meisten Entwickler sie aus. 00:13:47.960 --> 00:13:51.620 Schreiben und pflegen detaillierter Spezifikationen verursacht Kosten, für die niemand Geduld oder Zeit hat. 00:13:52.140 --> 00:13:54.800 Es ist zusätzliche Arbeit, die zur Bereitstellung von Funktionen hinzukommt 00:13:54.800 --> 00:13:57.780 und wenn Termine näher rücken, werden diese zusätzlichen Zyklen meist geopfert. 00:13:57.780 --> 00:14:01.780 Die Ironie ist offensichtlich, Entwickler denken eigentlich gerne in größeren Zusammenhängen. 00:14:01.980 --> 00:14:05.840 Die Strukturen vorauszukennen ist beruhigend, das Problem ist nicht die Absicht, sondern die Pflege. 00:14:06.480 --> 00:14:09.960 Sobald die Spezifikation nicht mehr mit der Realität übereinstimmt, wird die Wartung zur Last. 00:14:10.580 --> 00:14:14.600 Deshalb driftet so viel Arbeit im echten Leben in Richtung Improvisation statt vollständigem Design ab, 00:14:14.720 --> 00:14:16.920 selbst in Firmen, die eigentlich strikte Planung befürworten. 00:14:17.740 --> 00:14:19.780 Ein Agenten-Workflow bietet eine Alternative. 00:14:20.280 --> 00:14:22.300 Anstatt ein ausgefeiltes Design-Dokument zu fordern, 00:14:22.300 --> 00:14:26.040 hilft es dabei, eine Spezifikation in einfacher Sprache in einen Grundgerüst zu übersetzen, das Sie verfeilen können. 00:14:26.040 --> 00:14:29.220 Sie brauchen keine UML-Diagramme oder handgeschriebene Schnittstellenpläne. 00:14:29.800 --> 00:14:32.860 Sagen Sie einfach, erstelle ein Reporting-Modul mit einem neuen API-Endpunkt, 00:14:33.080 --> 00:14:36.480 verknüpfe es mit dem Speicher und sichere es mit rollenbasierter Zugriffssteuerung 00:14:36.480 --> 00:14:40.000 und das System generiert eine Basis über die Dateien Ihrer .NET-Lösung hinweg. 00:14:40.880 --> 00:14:43.900 In der Demo werde ich eine Spezifikation in einfacher Sprache vorlesen, 00:14:43.980 --> 00:14:47.540 dann die vom Agenten erstellten Dateien Controller, Modelle und Dienstregistrierung zeigen 00:14:47.540 --> 00:14:50.460 und auf die Stellen hinweisen, die noch manueller Verfeinerung bedurften. 00:14:50.460 --> 00:14:53.000 So können Sie die Qualität selbst beurteilen. 00:14:53.880 --> 00:14:56.040 Dies schafft einen Mittelweg zwischen zwei Entwicklermodi. 00:14:56.900 --> 00:15:00.600 Auf der einen Seite gibt es das Vibe-Coding, schnell, frei formuliert, aber anfällig für langfristige Systeme. 00:15:01.180 --> 00:15:05.140 Auf der anderen Seite gibt es das spezifikationsgesteuerte Design, zuverlässig, aber quälend langsam. 00:15:06.280 --> 00:15:10.060 Mit Unterstützung durch Agenten skizzieren Sie die Idee in natürlichen Worten, das Grundgerüst erscheint 00:15:10.060 --> 00:15:12.000 und Sie können fast so schnell iterieren wie beim Vibe-Coding, 00:15:12.120 --> 00:15:14.060 während Sie die Vorteile einer organisierten Struktur beibehalten. 00:15:14.460 --> 00:15:15.840 Nehmen noch einmal diesen Reporting-Workflow. 00:15:15.840 --> 00:15:19.540 Normalerweise müssten Sie das Modell herstellen, den Datendienst aufbauen, 00:15:19.680 --> 00:15:23.040 den Controller verdrahten, die Sicherheit konfigurieren und alles beim Start verbinden. 00:15:23.760 --> 00:15:26.620 Das bedeutet, durch mehrere Dateien zu springen und zu hoffen, dass die Konsistenz gewandt bleibt. 00:15:27.160 --> 00:15:29.420 Mit diesem Ansatz landet das Grundgerüst sofort an der richtigen Stelle. 00:15:29.960 --> 00:15:32.140 Die wirkliche Ersparnis liegt weniger im Tippen, weniger Zeilen, 00:15:32.240 --> 00:15:34.000 sondern darin, Fehler zwischen den Dateien zu vermeiden. 00:15:34.340 --> 00:15:36.740 Etwa wenn man vergisst, einen neuen Dienst nach dem Erstellen zu registrieren. 00:15:37.220 --> 00:15:38.700 Natürlich gibt es immer die Frage des Deals. 00:15:38.980 --> 00:15:41.920 Wird eine KI Standardcode erzwingen oder konventionloser Kraft setzen? 00:15:42.420 --> 00:15:45.820 In der Praxis spiegeln Agenten in ihren Vorschlägen oft bestehende Projektmuster wieder. 00:15:46.640 --> 00:15:48.000 In der Demo werden Sie beide Seiten sehen. 00:15:48.780 --> 00:15:51.780 Stellen, an denen die Controllerstruktur perfekt mit der unseres Teams übereinstimmte 00:15:51.780 --> 00:15:53.840 und Stellen, an denen die Vermutungen daneben lagen. 00:15:54.360 --> 00:15:55.100 Diese Mischung ist wichtig. 00:15:55.680 --> 00:15:58.000 Sie werden wissen, was Sie vertrauen können und was Sie noch anpassen müssen. 00:15:58.480 --> 00:15:59.920 Das Endergebnis ist kein 0815. 00:16:00.460 --> 00:16:03.420 Es fühlt Sie immer noch wie Ihr Projekt an, nur mit weniger manueller Arbeit am Grundgerüst. 00:16:04.000 --> 00:16:06.840 Sie behalten Ihre Geschwindigkeit bei und verlassen sich gleichzeitig auf ein Fundament, 00:16:06.840 --> 00:16:08.600 das Sie für zukünftiges Wachstum verfeinern können. 00:16:09.100 --> 00:16:12.500 Statt dass Spezifikationsarbeit auf Architekten mit Geduld für Diagramme beschränkt bleibt, 00:16:12.500 --> 00:16:16.660 wird Sie zu einem Werkzeug für jeden Entwickler, der schnell experimentieren will, ohne die Ordnung zu opfern. 00:16:18.180 --> 00:16:20.220 Und wenn dies Teil Ihres täglichen Arbeitsablaufs wird, 00:16:20.360 --> 00:16:22.740 fühlt sich die Spezifikation nicht mehr wie ein formeller Unternehmensschritt an, 00:16:22.840 --> 00:16:24.400 sondern wie eine leichtgewichtige Kurzschrift. 00:16:25.080 --> 00:16:27.080 Sie beschreiben Ihre Absicht, das System legt den Grundstein 00:16:27.080 --> 00:16:29.240 und Sie konzentrieren sich darauf, die Details auszuarbeiten. 00:16:29.620 --> 00:16:32.240 Die größere Wirkung entsteht nicht nur durch den Code, den Sie generieren, 00:16:32.620 --> 00:16:34.920 sondern durch das, was die Zeitersparnis Woche für Woche bedeutet. 00:16:35.420 --> 00:16:37.720 Mehr Stunden für Funktionen, weniger Mühe sei bei der Einrichtung. 00:16:37.720 --> 00:16:41.380 Das bringt uns direkt zu der Frage, die jedem Entwickler am meisten am Herzen liegt. 00:16:41.960 --> 00:16:44.720 Was diese Änderungen in Bezug auf die Produktivität tatsächlich ausmachen. 00:16:45.660 --> 00:16:46.780 Die Produktivitätsaustellung. 00:16:47.300 --> 00:16:49.740 Die eigentliche Frage ist nicht, ob Sie hier und da ein paar Minuten sparen, 00:16:49.880 --> 00:16:53.700 sondern wie sich diese kleinen Verschiebungen über eine Woche hinweg zu bedeutenden Stunden summieren. 00:16:55.140 --> 00:16:55.720 Dies ist die Produktivitätsaustellung. 00:16:56.760 --> 00:16:59.100 Zeit zurückgewinnen, die normalerweise unbemerkt durch Kontextwechsel, 00:16:59.220 --> 00:17:01.620 wiederholte Bildzyklen und manuelle Korrekturen verloren geht. 00:17:02.220 --> 00:17:05.300 Die meisten Entwickler akzeptieren diese kleinen Verluste einfach als Teil der Arbeit. 00:17:05.300 --> 00:17:07.920 10 Minuten hier, um einem Konfigurationswert nachzujagen, 00:17:08.000 --> 00:17:10.260 weitere 15 Minuten für einen erneuten Lauf nach einer fehlenden Referenz 00:17:10.260 --> 00:17:11.800 oder das Springen zwischen Dateien und Verbindungen zu bieten. 00:17:12.240 --> 00:17:13.500 Für sich genommen wirken Sie geringfügig. 00:17:14.000 --> 00:17:16.040 Aber zusammengerechnet über einen ganzen Sprint hinweg, 00:17:16.140 --> 00:17:17.920 bestimmen Sie, wie viel tatsächlicher Wert geliefert wird. 00:17:18.760 --> 00:17:21.700 Was wie Routinebewegungen aussieht, verbirgt eine echte Verzögerung bei den Lieferzeiten. 00:17:22.400 --> 00:17:24.300 Das versteckte Gewicht liegt nicht in Kompilierzeiten oder Tippgeschwindigkeit. 00:17:25.380 --> 00:17:27.580 Es liegt im Stopp-Start-Rhythmus der Ihrer Konzentration aufgezwungen. 00:17:27.960 --> 00:17:30.720 Jedes Mal, wenn Sie von einer Datei zur anderen wechseln, setzt Ihr Gehirn neu an. 00:17:31.040 --> 00:17:32.140 Dieser reset hat seinen Preis. 00:17:32.140 --> 00:17:35.400 Das Auslagern repetitiver Korrekturen an einen Agenten erleichtert diese Last. 00:17:35.940 --> 00:17:39.680 Anstatt ständig den Kontext neu aufzubauen, investieren Sie Fokus dort, wo es zählt, 00:17:40.080 --> 00:17:41.620 beim Lösen der größeren Designprobleme. 00:17:42.340 --> 00:17:44.100 Viele Teams verfolgen diese Mikrokosten nicht, 00:17:44.160 --> 00:17:46.380 weil sie nicht in Jira-Tickets oder der Git-Historie erscheinen. 00:17:47.080 --> 00:17:49.720 Arbeit, die zu nichts führt, wird nicht protokolliert, verbraucht aber dennoch Energie. 00:17:50.480 --> 00:17:52.920 Und während Codebasen skalieren, addiert sich diese Reibung nicht nur linear. 00:17:53.620 --> 00:17:56.100 Mehr Ebenen bedeuten mehr Abhängigkeiten, die man im Gedächtnis behalten muss 00:17:56.100 --> 00:17:58.620 und mehr Möglichkeiten, Zeit allein damit zu verlieren, die Struktur anzugleichen, 00:17:58.640 --> 00:18:00.100 die Struppe anzugleichen, bevor es weitergehen kann. 00:18:00.100 --> 00:18:03.360 Agenten-Workflows ändern die Rechnung, indem Sie diese Schwachstellen direkt annehmen. 00:18:03.640 --> 00:18:05.220 Sie füllen nicht nur Methoden stubschneller aus. 00:18:05.600 --> 00:18:09.440 Sie reduzieren die Schleifen des Suchens, Korrigierens und erneuten Ausführens die ganze Nachmittage verschlingen. 00:18:09.880 --> 00:18:13.820 Teams, die Agenten-Workflows nutzen, berichten in vielen Fällen von kürzeren Zeiten bis zur Problemlösung. 00:18:14.300 --> 00:18:18.040 In diesem Video demonstrieren wir eine Vorher-Nachher-Aufgabe, damit Sie den Einfluss beurteilen können. 00:18:18.600 --> 00:18:21.360 Ich werde die Zeit stoppen, die benötigt wird, um dieselbe Azure-Funktion manuell 00:18:21.360 --> 00:18:25.400 und dann erneut mit dem Agenten zu implementieren, damit Sie den Produktivitätsgewinn konkret sehen können. 00:18:25.400 --> 00:18:28.660 Aus geschäftlicher Sicht zeigt sich der Mehrwert in der Projektgeschwindigkeit. 00:18:29.420 --> 00:18:31.660 Schnellere Zyklen bedeuten nicht nur mehr Zufriedenheit für Entwickler. 00:18:32.180 --> 00:18:34.960 Sie entscheiden, ob Funktionen mit diesem Release erscheinen oder sich um Quartale verschieben. 00:18:35.500 --> 00:18:38.880 Sie beeinflussen technische Schulden, da weniger Hacks und Regressionen in den Backlog wandern. 00:18:39.880 --> 00:18:42.240 Ein reibungsloserer Ablauf erlaubt Teams, sauber voranzukommen, 00:18:42.320 --> 00:18:44.400 statt kaputte Arbeit aus dem vorherigen Sprint zu korrigieren. 00:18:45.220 --> 00:18:48.620 Diese Beständigkeit führt mit der Zeit zu weniger Feuerlöschen und einer stärkeren Bereitstellung. 00:18:48.620 --> 00:18:50.260 Es gibt auch den menschlichen Faktor. 00:18:50.720 --> 00:18:53.000 Ein Tag, der mit Fehlersuche verloren geht, erschöpft jeden Ingenieur. 00:18:53.780 --> 00:18:57.220 Ist man erst einmal ermüdet, wird sauberes Design schwieriger, Details entfallen und Fehler schleichen sich ein. 00:18:58.100 --> 00:19:01.820 Indem man mechanische Korrekturen an einen Agenten abgibt, bleiben Entwickler länger konzentriert. 00:19:02.740 --> 00:19:05.440 Dieser zusätzliche Fokus schärft sowohl die Produktivität als auch die Qualität. 00:19:06.280 --> 00:19:10.700 Wenn man nicht durch ständige Reibungsverluste ausgebremst wird, kann man freier denken und effektiver planen. 00:19:11.200 --> 00:19:12.640 Der Unterschied in der Praxis sieht so aus. 00:19:12.760 --> 00:19:17.800 Eine neue Azure-Funktion mit mehreren Bindungen und Service-Integrationen kann ohne Hilfe zwei volle Tage dauern. 00:19:18.940 --> 00:19:23.520 Zwischen Konfiguration, Tests und dem Zurückverfolgen fehlerhafter Referenzen zieht sich die Aufgabe in die Länge. 00:19:24.320 --> 00:19:26.960 Mit der Hilfe eines Agenten kann dieselbe Funktion in einem halben Tag entstehen. 00:19:27.720 --> 00:19:31.960 Nicht, weil man sich Arbeit leicht macht, sondern weil das dateiübergreifende Setup und die Orchestrierung auf Anhieb sitzen. 00:19:32.660 --> 00:19:35.580 Der Zeitplan verkürzt sich durch das Vermeiden von Fehlstarts und redundanter Arbeit. 00:19:36.540 --> 00:19:37.940 Einige Entwickler äußern Berechtebedenken. 00:19:38.400 --> 00:19:41.180 Dumpfen die eigenen Fähigkeiten ab, wenn man sich bei der Wartung auf KI verlässt. 00:19:41.440 --> 00:19:43.560 Diese Perspektive übersieht oft, was sich tatsächlich verändert. 00:19:44.160 --> 00:19:48.180 Das Auslagern repetitiver Aufgaben schwächt nicht die Expertise, sondern schont sie für Design und Architektur beurteilt. 00:19:48.620 --> 00:19:49.580 Entscheidungsvermögen entscheidend ist. 00:19:50.340 --> 00:19:54.960 In Wirklichkeit gewinnt man Raum für anspruchsvollere Problemlösungen, statt Energie mit Korrekturen zu verschwenden. 00:19:55.500 --> 00:19:58.620 Wenn Sie dies ausprobieren, schreiben Sie in die Kommentare, wie viele Stunden Sie pro Spann zurückgewandt. 00:19:58.880 --> 00:20:00.940 Ich werde interessante Antworten in zukünftige Videos einbauen. 00:20:00.940 --> 00:20:06.760 Zu hören, wie andere Teams den Wandel erleben, gibt jedem ein besseres Bild des echten Mehrwerts jenseits von Demos und Beispielen. 00:20:07.460 --> 00:20:10.100 Ein vorsichtiger Hinweis jedoch, Automatisierung hilft, aber Sicherheit ist weiter nicht. 00:20:10.780 --> 00:20:14.280 Führen Sie immer Ihre Tests durch und nutzen Sie Code-Reviews, um von Agenten erstellte Änderungen zu validieren. 00:20:14.840 --> 00:20:18.160 Ertrauen Sie darauf, dass lästige Arbeit reduziert wird, aber behalten Sie die bestehende Sicherheitsvorkehrungen. 00:20:18.620 --> 00:20:20.960 Der Geschwindigkeitsvorteil zahlt sich nur aus, wenn die Qualität stabil bleibt. 00:20:21.520 --> 00:20:25.540 Starke Tests und kluge PR-Reviews schützen Ihre Release-Pipeline vor anfälliger Automatisierung. 00:20:25.540 --> 00:20:31.240 Der Gewinn liegt weniger darin, Zeilen schnell zu produzieren, sondern mehr darin, Raum für bessere Lösungen zu schaffen. 00:20:31.920 --> 00:20:32.820 Weniger Ermüdung und weniger.