WEBVTT 00:00:00.140 --> 00:00:07.500 Gotowi na 10 dni Microsoft 365, Kopilota, AI, Azure oraz ludzi kształtujących przyszłość pracy? 00:00:07.500 --> 00:00:12.280 W styczniu wraca M365Con i tym razem działamy z większym rozmachem. 00:00:12.500 --> 00:00:18.340 Dołącz do nas, by wziąć udział w sesjach na żywo, pokazach praktycznych i zdobyć wiedzę od MVP oraz ekspertów z całego świata. 00:00:18.600 --> 00:00:22.120 Żadnych nudnych prezentacji, żadnych niekończących się modnych haseł. 00:00:22.320 --> 00:00:28.500 Zajmujemy się prawdziwymi wyzwaniami, Kopilot Studio agentami, AI Fabric, bezpieczeństwem, ładem korporacyjnym i automatyzacją. 00:00:29.440 --> 00:00:35.180 Niezależnie od tego, czy jesteś specjalistą i programistą, czy liderem biznesowym, mamy sesje przygotowane właśnie dla Ciebie. 00:00:35.180 --> 00:00:40.560 Podczas 10 pełnych dni zgłębisz wiele technologii i nawiążesz kontakty z globalną społecznością. 00:00:40.800 --> 00:00:44.580 Oglądaj na żywo i zabierz praktyczne wnioski do swojej organizacji. 00:00:44.860 --> 00:00:49.120 Styczeń 2027 roku, 10 dni, jedna społeczność Microsoft. 00:00:49.480 --> 00:00:51.140 Rejestracja jest już otwarta. 00:00:51.780 --> 00:00:56.000 Wejdź na m365con.net i zarezerwuj miejsce już dziś. 00:00:56.000 --> 00:00:58.840 To m365con.net 00:00:58.840 --> 00:01:04.860 Dołącz teraz na m365con.net i widzimy się na żywo w styczniu. 00:01:05.060 --> 00:01:11.880 Jeśli kiedykolwiek otworzyłeś rozwiązanie i poczułeś się przytłoczony gąszczem plików, odniesień i błędów czyhających na każdym kroku, nie jesteś sam. 00:01:12.120 --> 00:01:15.380 Większość programistów pracuje reaktywnie, łatając tu i debugując tam. 00:01:15.560 --> 00:01:20.220 Tryb agenta w GitHub Kopilot ma na celu utrzymanie szerszego kontekstu i koordynację zmian między plikami. 00:01:20.220 --> 00:01:24.840 W tym filmie pokażemy, jak ten przepływ pracy wygląda w rzeczywistym projekcie .net i Azure. 00:01:25.120 --> 00:01:28.740 Przeanalizujemy działające rozwiązanie i pokażemy stan przed oraz po zmianach wprowadzonych przez agenta. 00:01:28.980 --> 00:01:36.420 Zobaczysz, jak generować kod dla wielu plików przy mniejszym nakładzie pracy, szybciej rozwiązywać błędy międzyplikowe, a nawet używać opisu w języku naturalnym do tworzenia szkieletu funkcji. 00:01:36.640 --> 00:01:41.620 Zanim jednak do tego przejdziemy, zacznijmy od ukrytych kosztów pętli debugowania, w której wielu z nas tkwi każdego dnia. 00:01:41.820 --> 00:01:43.620 Ukryty koszt doraźnego debugowania. 00:01:43.620 --> 00:01:46.340 Siadasz do naprawy błędu, który wygląda na dość prosty. 00:01:46.500 --> 00:01:50.460 Aplikacja nie chce się skompilować, a konsola wskazuje linię w głównym pliku projektu. 00:01:50.600 --> 00:01:56.300 Poprawiasz metodę, kompilujesz ponownie i myślisz, że rozwiązałeś problem, aż ten sam komunikat pojawia się w nieco innej formie. 00:01:56.500 --> 00:01:59.320 Mija kolejne pół godziny, zanim dostrzeżesz prawdziwy problem. 00:01:59.600 --> 00:02:02.620 Brakująca zależność ukryta gdzieś w innym folderze projektu. 00:02:02.800 --> 00:02:07.160 Zanim poprawisz referencję i wdrożysz zmiany, większość popołudnia przepada na łataniu błędów. 00:02:07.300 --> 00:02:09.860 Praca nad zaplanowaną funkcją zostaje przełożona na jutro. 00:02:09.860 --> 00:02:12.340 Ten wzorzec jest tak powszechny, że wydaje się normalny. 00:02:13.620 --> 00:02:16.180 Pracujesz do przodu, ponieważ każdy naprawiony błąd sprawia wrażenie sukcesu. 00:02:16.340 --> 00:02:17.700 W praktyce kręcisz się w kółko. 00:02:17.860 --> 00:02:21.000 Pętla to kodowanie, kompilacja, błąd, poprawka i powtórka. 00:02:21.220 --> 00:02:26.800 Godziny znikają na ściganiu przyczyn i skutków, a efektem netto jest reaktywny postęp, a nie realne usprawnienia. 00:02:27.060 --> 00:02:29.620 Ilu z Was straciło popołudnie na dokładnie taką pętlę? 00:02:29.820 --> 00:02:32.480 Zostaw komentarz, przeczytam najpopularniejsze odpowiedzi. 00:02:32.660 --> 00:02:37.300 To, co wyczerpuje w tym cyklu, to fakt, że nasze narzędzia stale się rozwijają, a schemat pracy nie. 00:02:37.300 --> 00:02:44.020 Edytory zyskują nowe funkcje, frameworki ewoluują, a integracje stają się głębsze, ale debugowanie wciąż wymaga reaktywnego podejścia. 00:02:44.180 --> 00:02:46.940 To jak próba powstrzymania pożaru za pomocą wiadra wody. 00:02:47.160 --> 00:02:52.840 Każdy wybuch jest gaszony na bieżąco, ale przyczyny, które go wywołały, pozostają, niemal gwarantując kolejny pożar. 00:02:52.980 --> 00:02:55.340 A z każdą zmianą karty ukryty koszt rośnie. 00:02:55.560 --> 00:03:00.160 Przechodzisz z klasy serwisowej do pliku konfiguracyjnego, a potem skaczesz do grafu zależności. 00:03:00.160 --> 00:03:04.260 Każda taka zmiana wyrywa Cię z toku myślenia, wymuszając mentalny reset. 00:03:04.440 --> 00:03:09.720 Nie chodzi tylko o sekundy spędzone na przełączaniu okien, ale o koszt odtwarzania kontekstu wciąż na nowo. 00:03:09.880 --> 00:03:12.940 W ciągu dnia te małe resety sumują się w coś naprawdę męczącego. 00:03:13.160 --> 00:03:16.680 Dla pojedynczych programistów zmęczenie objawia się frustracją i stratą czasu. 00:03:16.920 --> 00:03:20.400 W zespołach pracujących nad projektami korporacyjnymi wpływ ten się multiplikuje. 00:03:20.580 --> 00:03:26.560 Pętle debugowania spychają cele sprintu na boczny tor, opóźniają premiery funkcji i tworzą dług, który rośnie szybciej niż jest spłacany. 00:03:26.560 --> 00:03:31.120 Pogłębianie długu technicznego to tylko kolejny efekt uboczny godzin traconych na gaszenie pożarów. 00:03:31.280 --> 00:03:35.480 Wiele zespołów zgłasza, że znaczna część ich czasu pracy jest wysysana przez reaktywne debugowanie. 00:03:35.680 --> 00:03:37.940 To nie jest najbardziej ekscytująca część inżynierii. 00:03:38.120 --> 00:03:44.740 Nikt nie planuje harmonogramu prac wokół pięciokrotnego ścigania tego samego błędu zależności, a jednak to tam ucieka moc przerobowa tydzień po tygodniu. 00:03:44.880 --> 00:03:51.360 Kiedy naprawianie błędów staje się definicją postępu, tworzenie nowych funkcji schodzi na drugi plan, a architektura po cichu cierpi w tle. 00:03:51.360 --> 00:03:55.580 Niewygodna prawda jest taka, że doraźne debugowanie nie tylko spowalnia pracę. 00:03:55.780 --> 00:03:58.400 Wzmacnia kulturę reagowania zamiast projektowania. 00:03:58.700 --> 00:04:01.860 Spędzasz czas na gaszeniu pożarów, a nie na budowaniu systemów. 00:04:02.080 --> 00:04:07.560 Może to utrzymać produkt przy życiu na krótką metę, ale ogranicza skalowalność zespołu i pewność wdrażania zmian. 00:04:07.900 --> 00:04:10.240 Zatrzymajmy się więc przy tym obrazie gaszenie pożarów. 00:04:10.340 --> 00:04:12.460 Pędź do źródła ognia, wylej wodę, idź dalej. 00:04:12.680 --> 00:04:15.180 Problem nie polega na tym, że programiści nie są w tym dobrzy. 00:04:15.440 --> 00:04:15.660 Są. 00:04:15.860 --> 00:04:18.400 Problem w tym, że płomienie nigdy tak naprawdę nie gasną. 00:04:18.620 --> 00:04:25.020 Po prostu przenoszą się, wybuchając w nowych plikach, projektach i konfiguracjach, utrzymując wszystkich w trybie reagowania zamiast tworzenia. 00:04:25.240 --> 00:04:28.840 To rodzi pytanie, co by było, gdyby ten cykl nie spoczywał tylko na tobie? 00:04:29.240 --> 00:04:36.220 Co jeśli powtarzalne czynności, czyli śledzenie, przełączanie i łatanie można by obsłużyć inaczej, podczas gdy ty skupiasz się na budowaniu? 00:04:36.220 --> 00:04:41.160 Bo choć presja gaszenia pożarów jest oczywista, istnieje inny punkt zapalny, którego jeszcze nie poruszyliśmy. 00:04:41.360 --> 00:04:44.860 Prawdziwy ciężar pojawia się, gdy projekt to nie tylko jeden plik czy moduł. 00:04:45.060 --> 00:04:48.360 Dzieje się tak, gdy potrzebna poprawka obejmuje wiele warstw jednocześnie. 00:04:48.620 --> 00:04:54.460 Wyobraź sobie, że otwierasz rozwiązanie, w którym logika rozciąga się na różne projekty, usługi i biblioteki. 00:04:54.900 --> 00:05:00.240 Potrzebny element znajduje się w trzech miejscach naraz, a utrzymanie tego w głowie to osobna walka. 00:05:01.020 --> 00:05:03.880 Chaos wielu plików kontra kontrola kontekstu przez AI. 00:05:03.880 --> 00:05:08.140 Gdy projekty obejmują wiele warstw, prawdziwym wyzwaniem nie jest pisanie kodu. 00:05:08.400 --> 00:05:10.840 Chodzi o to, by utrzymać wszystkie ruchome części w całości. 00:05:11.180 --> 00:05:15.740 Właśnie tutaj napięcie między chaosem wielu plików a kontrolą kontekstu przez AI ujawnia się najwyraźniej. 00:05:16.020 --> 00:05:19.420 Weźmy duże rozwiązanie .NET z kilkunastoma lub większą liczbą projektów. 00:05:19.580 --> 00:05:22.500 Każda nowa funkcja zazwyczaj dotyka kilku warstw jednocześnie. 00:05:22.720 --> 00:05:27.340 Kontroler w jednym miejscu, usługa w innym i zestaw plików konfiguracyjnych gdzie indziej. 00:05:27.340 --> 00:05:35.600 Zanim napiszesz choćby jedną linię, spędzasz czas na śledzeniu referencji i sprawdzaniu zależności, mając nadzieję, że mała zmiana nie spowoduje nieoczekiwanych błędów w dalszej części łańcucha. 00:05:35.840 --> 00:05:37.540 Taki przepływ pracy nie jest wyjątkiem. 00:05:37.820 --> 00:05:42.640 Jest to norma w aplikacjach korporacyjnych, zwłaszcza gdy w grę wchodzą usługi Azure i integracje. 00:05:42.900 --> 00:05:44.900 Struktura tych systemów nie jest płaska. 00:05:44.900 --> 00:05:49.980 Interfejsy mapowania, wstrzykiwania zależności i odwołania między projektami odgrywają tu swoją rolę. 00:05:50.200 --> 00:05:58.480 Gdy dochodzi Azure, niektóre zależności wykraczają poza folder rozwiązania, aplikacje funkcyjne, powiązania, serwis bus, ustawienia zasobów, połączenia z pamięcią. 00:05:58.840 --> 00:06:03.640 Koordynujesz kod w IDE, pliki konfiguracyjne na dysku i usługi zdefiniowane w chmurze. 00:06:03.880 --> 00:06:06.400 Żaden z nich nie przejmuje się tym, że wolisz mniej klikania. 00:06:06.400 --> 00:06:10.280 Za każdym razem, gdy zmieniasz kontekst, tracisz energię na odtwarzanie szerszego obrazu. 00:06:10.480 --> 00:06:13.220 Większość z nas próbuje żonglować tym kontekstem w pamięci roboczej. 00:06:13.220 --> 00:06:16.680 Początkowo jest to wykonalne, ale w miarę wzrostu projektu wkradają się błędy. 00:06:16.920 --> 00:06:19.800 Dodajesz nową metodę w usłudze, ale zapominasz o jej rejestracji w D. 00:06:19.920 --> 00:06:25.120 Kodujesz funkcję Azure i dopiero później zdajesz sobie sprawę, że powiązanie nigdy nie zostało dodane do host, jon, ani szablonu wdrożenia. 00:06:25.380 --> 00:06:28.440 Nic Cię nie ostrzega aż do momentu uruchomienia, kiedy debugujesz zamiast budować. 00:06:28.680 --> 00:06:30.500 Sam kod nie jest najtrudniejszą częścią. 00:06:30.500 --> 00:06:32.420 Jest nią koordynacja między plikami. 00:06:32.420 --> 00:06:41.960 Każdy zna uczucie przeskakiwania między kartami z kontrolera do usługi, potem do modelu, następnie do plików konfiguracyjnych i z powrotem, by w końcu zapomnieć, po co w ogóle otworzyłeś ten plik. 00:06:42.080 --> 00:06:44.740 To drobne zakłócenie powtarzane dziesiątki razy dziennie. 00:06:44.920 --> 00:06:48.380 Te interakcje sumują się, tworząc tarcie, które hamuje realny postęp. 00:06:48.380 --> 00:06:54.400 Efektem jest wolniejsze dostarczanie nie dlatego, że pisanie jest wolne, ale dlatego, że utrzymywanie wszystkiego w synchronizacji kradnie koncentrację. 00:06:54.560 --> 00:06:56.920 Ten narzut rośnie w projektach typu Cloud First. 00:06:57.140 --> 00:07:06.340 Azure umieszcza kluczowe ustawienia w wielu miejscach, lokalnych plikach konfiguracyjnych, zmiennych środowiskowych, szablonach arm lub bicep oraz potokach chi ciąg dalszy. 00:07:06.520 --> 00:07:10.820 To, co wygląda na pojedyncze zgłoszenie funkcji, często rozciąga się na cztery warstwy abstrakcji. 00:07:10.820 --> 00:07:12.620 Ta złożoność nie jest opcjonalna. 00:07:12.820 --> 00:07:15.140 Jest ona wpisana w sposób działania całego ekosystemu. 00:07:15.300 --> 00:07:18.340 W tym właśnie miejscu tryb agenta, agent mode, stanowi potencjalny punkt zwrotny. 00:07:18.540 --> 00:07:23.140 Zamiast pozostawiać całą tę orkiestrację, tobie zaprojektowano go tak, aby utrzymywał szerszy kontekst w wielu plikach. 00:07:23.300 --> 00:07:27.000 Oznacza to, że gdy prosisz o zmianę w jednej warstwie, nie ignoruje on pozostałych. 00:07:27.180 --> 00:07:34.540 W trakcie demo stworzę nową funkcję Azure i pokażę, jak agent pomaga, generując treść metody, tworząc konfigurację powiązań oraz aktualizując host. 00:07:34.540 --> 00:07:38.000 I on, a nawet sugerując odpowiednią rejestrację wstrzykiwania zależności, di. 00:07:38.180 --> 00:07:41.140 Zazwyczaj jest to wieloetapowy proces rozproszony w różnych plikach. 00:07:41.280 --> 00:07:44.000 Agent może usprawnić to działanie do postaci jednego przepływu. 00:07:44.000 --> 00:07:50.620 Nie chodzi o zastąpienie twojego osądu, lecz o usunięcie powtarzalnej pracy administracyjnej, abyś mógł skupić się na realnych wyborach projektowych. 00:07:50.800 --> 00:07:54.020 Ludzie potrafią utrzymać w głowie ogólny zarys lub szkic na tablicy. 00:07:54.240 --> 00:07:57.980 Sztuczna inteligencja potrafi śledzić szczegóły plik po pliku, nie tracąc przy tym wątku. 00:07:58.160 --> 00:08:02.160 To, co dla nas stanowi ogromne obciążenie poznawcze, dla agenta jest jedynie podstawowym kontekstem. 00:08:02.340 --> 00:08:07.120 W praktyce różnica polega na przejściu odżonglowania wieloma kartami do orkiestrowanych zmian, które pozostają ze sobą zsynchronizowane. 00:08:07.120 --> 00:08:12.600 Podczas prezentacji pokażę również utworzony przez agenta PulliQuest lub Div, abyś mógł zobaczyć dokładnie, jakie edycje zostały wprowadzone. 00:08:12.760 --> 00:08:14.020 Ta przejrzystość ma znaczenie. 00:08:14.280 --> 00:08:19.140 Masz pełną kontrolę, aby przejrzeć i zatwierdzić zmiany, podczas gdy żmudna praca nad aktualizacją wielu plików wykonuje się za Ciebie. 00:08:19.340 --> 00:08:26.080 Zamiast spędzać popołudnie na łączeniu fragmentów kodu, zlecasz zmianę raz, potwierdzasz wygenerowane aktualizacje i przechodzisz do projektowania na wyższym poziomie. 00:08:26.080 --> 00:08:34.200 Ulgą nie są tylko zaoszczędzone kliknięcia czy naciśnięcia klawiszy, lecz skupienie się na rozwiązywaniu rzeczywistych problemów zamiast odtwarzaniu powiązań między tuzinem plików. 00:08:34.320 --> 00:08:42.180 Ta zaleta uwidacznia się najbardziej, gdy coś się psuje, ponieważ nawet przy lepszej obsłudze kontekstu systemy zawodzą, konfiguracje się rozjeżdżają, a błędne odwołania powracają. 00:08:42.380 --> 00:08:47.040 I tu zaczyna się kolejny test, w jaki sposób błędy są wykrywane i naprawiane, gdy już się pojawią. 00:08:47.260 --> 00:08:49.460 Od polowania na błędy po autonomiczne poprawki. 00:08:49.660 --> 00:08:53.800 Pomyśl, jak często trafiasz na komunikat o błędzie, który wskazuje bezpośrednio na jeden konkretny plik. 00:08:53.800 --> 00:08:58.340 Podążasz za śladem stosu do wskazanej metody, wprowadzasz małą poprawkę i uruchamiasz ponowną kompilację. 00:08:58.600 --> 00:09:03.280 Wydaje się to oczywistym rozwiązaniem, dopóki ten sam błąd nie pojawi się ponownie w nieco innej formie. 00:09:03.500 --> 00:09:06.320 Wtedy zdajesz sobie sprawę, że ślad stosu wskazywał tylko objaw. 00:09:06.500 --> 00:09:11.760 Prawdziwy problem leży gdzie indziej, być może w klasie pomocniczej lub jest ukryty w pliku konfiguracyjnym, którego nie otwierałeś od tygodnia. 00:09:11.980 --> 00:09:14.040 Każdy programista doświadczył tego rodzaju zmylenia. 00:09:14.220 --> 00:09:16.980 To, co wygląda na problem, wcale nie jest miejscem, gdzie leży rozwiązanie. 00:09:16.980 --> 00:09:18.460 To błyskawicznie pożera czas. 00:09:18.460 --> 00:09:20.660 Poprawiasz jedną rzecz, przebudowujesz, czekasz. 00:09:20.800 --> 00:09:25.040 Potem wita Cię nowy błąd, prowadzący do kolejnego pliku, kolejnej poprawki i kolejnej przebudowy. 00:09:25.220 --> 00:09:32.000 Ta pętla wydaje się produktywna, bo działasz, piszesz, kompilujesz, ale w rzeczywistości to raczej metoda prób i błędów niż właściwe rozwiązanie. 00:09:32.180 --> 00:09:38.500 Ten cykl potrafi pochłonąć godziny, zostawiając Cię z drobnymi poprawkami kosmetycznymi, bez realnych postępów nad funkcją, od której zacząłeś. 00:09:38.640 --> 00:09:40.800 Prawdziwym kosztem jest tutaj utracona szansa. 00:09:40.800 --> 00:09:47.760 Będąc uwięzionym w rytmie przebudowywania i ponawiania prób, nie rozwiązujesz problemów biznesowych ani nie dostarczasz funkcjonalności, na które czekają użytkownicy. 00:09:47.960 --> 00:09:50.340 Pęd marnuje się na domysły zamiast na projektowanie. 00:09:50.620 --> 00:09:55.940 W danej chwili wydaje się to pracą, ale te godziny niewiele wnoszą poza utrzymaniem systemu w stanie używalności. 00:09:56.240 --> 00:10:01.600 W skali zespołu ten powierzchowny ruch spowalnia wszystko i tworzy zaległości w funkcjach, które są ciągle przekładane. 00:10:01.800 --> 00:10:05.020 W tym miejscu przepływ pracy oparty na agencie zaczyna wyglądać inaczej. 00:10:05.020 --> 00:10:08.480 Pomysł nie polega na zatrzymaniu się na jednej linii wskazanej przez ślad stosu. 00:10:08.660 --> 00:10:14.120 Zamiast tego jest zaprojektowany tak, aby zachować kontekst całego systemu, pytając nie tylko, co powinien robić ten plik, 00:10:14.260 --> 00:10:18.160 ale jaka sekwencja zmian jest potrzebna w powiązanych elementach, aby przywrócić spójność. 00:10:18.340 --> 00:10:22.300 W praktyce oznacza to, że agent może proponować edycje obejmujące wiele plików. 00:10:22.480 --> 00:10:29.300 Na przykład w demo zobaczysz, że gdy metoda wymaga zmian, agent może zasugerować pasujące poprawki w powiązanych konfiguracjach lub szablonach wdrożeniowych, 00:10:29.420 --> 00:10:30.840 zamiast zmuszać Cię do ich szukania. 00:10:30.840 --> 00:10:33.660 To krok od autouzupełniania ku czemuś znacznie szerszemu. 00:10:33.660 --> 00:10:37.080 Autouzupełnianie kończy linię, a agent koordynuje działania w wielu plikach. 00:10:37.200 --> 00:10:40.700 Ta koordynacja jest najważniejsza, gdy błędy nie ograniczają się do jednego miejsca. 00:10:40.960 --> 00:10:42.440 Weźmy typowy scenariusz Azure. 00:10:42.700 --> 00:10:48.180 Stworzyłeś nową aplikację funkcji, ale po wdrożeniu wyzwalacz kolejki zawodzi, ponieważ powiązanie nie pasuje do sygnatury metody. 00:10:48.440 --> 00:10:53.620 Zazwyczaj przeszukujesz logi, sprawdzasz, które powiązanie jest błędne, ręcznie dostosowujesz pliki od SON funkcji, 00:10:53.720 --> 00:10:57.480 a może nawet zmieniasz szablon infrastruktury, jeśli tam również wartość jest niedopasowana. 00:10:57.480 --> 00:11:01.460 Każdy krok to osobne polowanie, a każda poprawka uruchamia kolejny test. 00:11:01.460 --> 00:11:03.900 W trybie agenta przepływ pracy wygląda inaczej. 00:11:04.140 --> 00:11:07.440 Może on zaproponować zmiany kodu, wygenerować poprawne powiązanie JSON funkcji 00:11:07.440 --> 00:11:10.500 i wyświetlić propozycje edycji skryptów wdrożeniowych, jeśli są one niespójne. 00:11:10.660 --> 00:11:14.400 Przeglądasz, zatwierdzasz i idziesz naprzód, nie tracąc godzin na łączenie każdej warstwy z osobna. 00:11:14.560 --> 00:11:15.840 Kluczem jest tutaj zaufanie. 00:11:16.080 --> 00:11:18.660 Nikt nie powinien odnosić wrażenia, że w tle dzieją się niewidoczne edycje. 00:11:18.900 --> 00:11:20.780 Właśnie dlatego proces weryfikacji jest tak ważny. 00:11:20.940 --> 00:11:22.560 W tym demo przejdziemy przez to wspólnie. 00:11:22.740 --> 00:11:24.640 Agent sugeruje skoordynowane zmiany. 00:11:24.640 --> 00:11:29.000 Otwieramy podgląd zmian, aby sprawdzić, co dokładnie wygenerował model, uruchamiamy testy jednostkowe, 00:11:29.100 --> 00:11:33.140 walidujemy kompilację lokalnie i dopiero wtedy decydujemy o akceptacji lub odrzuceniu poprawek. 00:11:33.220 --> 00:11:37.260 Ta pętla walidacji zapewnia pełną kontrolę, eliminując jednocześnie żmudną pracę. 00:11:37.460 --> 00:11:41.960 Warto podkreślić, agenci AI pomagają działać szybciej, ale nie zastępują dobrych praktyk inżynierskich. 00:11:42.200 --> 00:11:45.700 Nadal należy traktować przeglądy kodu i systemy ci jako nienegocjowalne punkty kontrolne. 00:11:45.920 --> 00:11:48.100 Niech AI skróci czas poświęcany na pracę detektywistyczną, 00:11:48.100 --> 00:11:51.300 ale automatyczne testy i weryfikacja przez ludzi pozostaną siecią bezpieczeństwa. 00:11:51.460 --> 00:11:55.700 Taka równowaga rozwiązuje problem zaufania i zapewnia, że zysk szybkości nie osłabia stabilności. 00:11:55.960 --> 00:11:57.940 Różnica w prędkości nie jest teoretyczna. 00:11:58.120 --> 00:12:00.700 Tam, gdzie szukanie błędów i ręczne poprawki zajmują pół dnia, 00:12:00.880 --> 00:12:03.460 skoordynowane sugestie mogą skrócić ten czas do kilku minut, 00:12:03.640 --> 00:12:07.280 a odzyskany czas można przeznaczyć na pracę, na której faktycznie chcesz się skupić. 00:12:07.440 --> 00:12:11.560 Na funkcje, które zauważą użytkownicy i decyzje architektoniczne, które poprawiają jakość twojego kodu. 00:12:11.560 --> 00:12:15.360 Zamiast gasić pożary w trakcie działania programu, możesz projektować pewnie od samego początku. 00:12:15.640 --> 00:12:18.260 Więc pętla debugowania nie musi już definiować twojego dnia. 00:12:18.500 --> 00:12:20.580 Gdy agent sugeruje aktualizację w wielu plikach, 00:12:20.700 --> 00:12:23.900 przechodzisz od chaotycznego przeszukiwania do rytmu przeglądania i zatwierdzania. 00:12:24.100 --> 00:12:28.320 Przestajesz błądzić wśród błędów w kółko i zaczynasz traktować debugowanie jako uporządkowany, 00:12:28.460 --> 00:12:30.000 niemal zautomatyzowany etap pracy. 00:12:30.220 --> 00:12:33.520 Ta zmiana uwalnia przestrzeń poznawczą i czas w kalendarzu na tworzenie nowych funkcji, 00:12:33.640 --> 00:12:34.800 a nie tylko naprawianie usterek. 00:12:34.960 --> 00:12:37.840 A gdy usuwanie błędów przestaje polegać na gonitwie za objawami, 00:12:37.840 --> 00:12:39.420 otwiera to drogę do czegoś większego. 00:12:39.660 --> 00:12:42.800 Możesz zacząć tworzyć całe funkcje w ten sam ustrukturyzowany sposób. 00:12:43.080 --> 00:12:46.620 Wyobraź sobie, że ten sam przepływ pracy, który proponuje skoordynowane poprawki, 00:12:46.760 --> 00:12:50.560 może również przyjąć opis w języku naturalnym i zbudować wokół niego gotową strukturę. 00:12:50.700 --> 00:12:53.060 W tym miejscu zaczyna się kolejny etap rozwoju. 00:12:53.260 --> 00:12:56.120 Programowanie sterowane specyfikacją bez zbędnego narzutu. 00:12:56.300 --> 00:13:00.080 Jedna z najciekawszych zmian zachodzi, gdy przestajesz myśleć tylko o plikach i metodach, 00:13:00.140 --> 00:13:02.480 a zaczynasz formułować zadania w języku naturalnym. 00:13:02.720 --> 00:13:06.000 Właśnie tutaj wkracza programowanie sterowane specyfikacją bez zbędnego narzutu. 00:13:06.000 --> 00:13:08.620 Wyobraź sobie, że piszesz proste zapytanie o nową funkcję. 00:13:08.840 --> 00:13:11.640 Dodaj przepływ raportowania, który generuje comiesięczne podsumowania, 00:13:11.780 --> 00:13:14.440 zapisuje je i udostępnia za pomocą strony administratora. 00:13:14.620 --> 00:13:16.980 Zamiast otrzymywać jedynie izolowane fragmenty kodu, 00:13:17.100 --> 00:13:19.900 otrzymujesz gotową strukturę rozplanowaną w całej aplikacji. 00:13:20.080 --> 00:13:24.500 Kontrolery utworzone, modele gotowe, usługi zarejestrowane, a konfiguracja połączona. 00:13:24.680 --> 00:13:28.580 To przejście od opisu intencji do zobaczenia gotowego szkieletu w projekcie sprawia, 00:13:28.760 --> 00:13:31.720 że to podejście wydaje się wreszcie praktyczne, a nie teoretyczne. 00:13:31.720 --> 00:13:35.980 W tradycyjnych rozwiązaniach tworzenie oparte na specyfikacji ma opinię uciążliwego procesu. 00:13:36.160 --> 00:13:38.960 W dużych organizacjach zazwyczaj oznacza to długie dokumenty wymagań, 00:13:39.060 --> 00:13:42.100 wielostronicowe projekty i sztywne diagramy, które wszystkich spowalniają. 00:13:42.320 --> 00:13:44.980 Mają one sens w regulowanych branżach lub rozproszonych zespołach, 00:13:45.120 --> 00:13:47.520 ale w codziennym programowaniu większość twórców je pomija. 00:13:47.700 --> 00:13:50.300 Pisanie i utrzymywanie szczegółowych specyfikacji generuje koszty, 00:13:50.380 --> 00:13:52.060 na które nikt nie ma czasu ani cierpliwości. 00:13:52.300 --> 00:13:54.280 To dodatkowa praca ponad dostarczanie funkcji, 00:13:54.400 --> 00:13:57.740 a gdy zbliżają się terminy, te dodatkowe cykle są zazwyczaj poświęcane. 00:13:57.740 --> 00:14:01.400 Ironia jest oczywista, programiści tak naprawdę lubią myśleć w szerszej perspektywie. 00:14:01.640 --> 00:14:03.960 Znajomość struktury z wyprzedzeniem jest uspokajająca. 00:14:04.120 --> 00:14:06.540 Problemem nie są intencje, lecz utrzymanie dokumentacji. 00:14:06.760 --> 00:14:10.600 Gdy specyfikacja zaczyna rozmijać się z rzeczywistością, jej aktualizacja staje się ciężarem. 00:14:10.840 --> 00:14:13.800 Dlatego tak wiele prac w świecie rzeczywistym zmierza w stronę improwizacji, 00:14:13.920 --> 00:14:17.520 a nie pełnego projektu, nawet w firmach, które technicznie wspierają dokładne planowanie. 00:14:17.720 --> 00:14:20.200 Przepływ pracy oparty na agentach oferuje alternatywę. 00:14:20.400 --> 00:14:22.420 Zamiast wymagać dopracowanego dokumentu projektowego, 00:14:22.420 --> 00:14:26.400 może on pomóc przekształcić specyfikację w prostym języku w szkielet, który możesz udoskonalić. 00:14:26.520 --> 00:14:29.420 Nie potrzebujesz diagramów UML, ani ręcznie rysowanych map interfejsów. 00:14:30.180 --> 00:14:33.920 Możesz po prostu powiedzieć, stwórz moduł raportowania z nowym punktem końcowym API, 00:14:34.060 --> 00:14:37.380 połącz go z pamięcią masową i zabezpiecz dostępem opartym na rolach, 00:14:37.480 --> 00:14:40.640 a system wygeneruje bazę w plikach Twojego rozwiązania .NET. 00:14:40.840 --> 00:14:43.760 W demo przeczytam specyfikację napisaną prostym językiem, 00:14:43.940 --> 00:14:46.140 pokażę pliki stworzone przez agenta kontrolery, 00:14:46.260 --> 00:14:50.660 modele i rejestrację usług oraz wskażę miejsca, które nadal wymagały ręcznej poprawy. 00:14:50.660 --> 00:14:53.520 W ten sposób będziesz mógł samodzielnie ocenić jakość. 00:14:53.680 --> 00:14:56.500 Tworzy to złoty środek między dwoma trybami pracy programisty. 00:14:56.760 --> 00:15:00.660 Z jednej strony mamy Vibe Codding – szybkie i swobodne, ale kruche w systemach długoterminowych. 00:15:01.380 --> 00:15:05.800 Z drugiej strony mamy projektowanie oparte na specyfikacji niezawodne, ale boleśnie wolne. 00:15:06.080 --> 00:15:08.720 Dzięki wsparciu agenta opisujesz pomysł naturalnymi słowami, 00:15:08.860 --> 00:15:11.980 pojawia się szkielet i możesz iterować niemal tak szybko jak w Vibe Codding, 00:15:12.100 --> 00:15:14.100 zachowując korzyści zorganizowanej struktury. 00:15:14.340 --> 00:15:16.420 Wróćmy do tego przepływu pracy z raportowaniem. 00:15:16.420 --> 00:15:20.280 Zazwyczaj musiałbyś stworzyć model, zbudować usługę danych, podpiąć kontroler, 00:15:20.420 --> 00:15:23.300 skonfigurować zabezpieczenia i połączyć wszystko przy starcie. 00:15:23.480 --> 00:15:26.880 Oznacza to skakanie po wielu plikach i nadzieję, że spójność zostanie zachowana. 00:15:27.160 --> 00:15:29.880 Dzięki temu podejściu szkielet wskakuje na swoje miejsce od razu. 00:15:30.100 --> 00:15:32.680 Prawdziwe oszczędności wynikają mniej z pisania mniejszej liczby linii, 00:15:32.760 --> 00:15:34.380 a bardziej z unikania błędów między plikami, 00:15:34.520 --> 00:15:37.060 takich jak zapomnienie o rejestracji nowej usługi po jej zbudowaniu. 00:15:37.280 --> 00:15:39.200 Oczywiście zawsze pojawia się kwestia stylu. 00:15:39.200 --> 00:15:42.040 Czy AI narzuci standardowy kod lub nadpisze konwencje? 00:15:42.220 --> 00:15:46.540 W praktyce agenty często odzwierciedlają w swoich sugestiach wzorce istniejące w projekcie. 00:15:46.780 --> 00:15:48.140 W demo zobaczysz obie strony. 00:15:48.420 --> 00:15:51.660 Miejsca, w których idealnie dopasowało się do struktury kontrolerów naszych ludzi 00:15:51.660 --> 00:15:53.960 oraz miejsca, w których jego domysły się rozminęły. 00:15:54.120 --> 00:15:55.460 Ta mieszanka jest istotna. 00:15:55.700 --> 00:15:58.440 Będziesz wiedzieć, czemu możesz ufać, a co nadal musisz skorygować. 00:15:58.640 --> 00:16:00.320 Efekt końcowy to nie szablonowy kod. 00:16:00.540 --> 00:16:04.060 Nadal czuć, że to twój projekt, tylko z mniejszą ilością ręcznej pracy nad szkieletem. 00:16:04.200 --> 00:16:06.500 Zachowujesz szybkość, opierając się na fundamencie, 00:16:06.640 --> 00:16:09.000 który możesz udoskonalać pod kątem przyszłego rozwoju. 00:16:09.000 --> 00:16:12.880 Zamiast ograniczać tworzenie specyfikacji do architektów z cierpliwością do diagramów, 00:16:13.020 --> 00:16:14.940 staje się ono narzędziem dla każdego programisty, 00:16:15.120 --> 00:16:17.480 który chce szybko eksperymentować bez utraty porządku. 00:16:17.780 --> 00:16:19.760 A kiedy stanie się to częścią codziennej pracy, 00:16:19.940 --> 00:16:22.980 specyfikacja przestaje wydawać się formalnym krokiem korporacyjnym, 00:16:23.040 --> 00:16:24.820 a staje się lekkim skrótem myślowym. 00:16:25.020 --> 00:16:27.520 Opisujesz swoje zamiary, system przygotowuje grunt, 00:16:27.640 --> 00:16:29.640 a ty skupiasz się na dopracowaniu szczegółów. 00:16:29.820 --> 00:16:32.080 Większy wpływ płynie nie tylko z generowanego kodu, 00:16:32.240 --> 00:16:35.100 ale z tego, co oszczędność czasu oznacza tydzień po tygodniu. 00:16:35.300 --> 00:16:37.920 Więcej godzin na funkcję, mniej żmudnej konfiguracji. 00:16:37.920 --> 00:16:39.720 To prowadzi nas bezpośrednio do pytania, 00:16:39.900 --> 00:16:41.960 które każdego programistę interesuje najbardziej. 00:16:42.200 --> 00:16:45.220 Co te zmiany faktycznie wnoszą w kontekście produktywności? 00:16:45.660 --> 00:16:47.000 Zysk z produktywności. 00:16:47.180 --> 00:16:50.560 Prawdziwe pytanie nie brzmi, czy zaoszczędzisz kilka minut tu i tam, 00:16:50.740 --> 00:16:54.360 ale jak te drobne zmiany sumują się w znaczące godziny w skali tygodnia. 00:16:54.540 --> 00:16:55.920 To właśnie jest zysk z produktywności. 00:16:56.700 --> 00:16:59.080 Odzyskiwanie czasu, który zazwyczaj niezauważalnie ucieka 00:16:59.080 --> 00:17:02.120 przez przełączanie kontekstu, powtarzane cykle budowania i ręczne poprawki. 00:17:02.360 --> 00:17:05.660 Większość programistów akceptuje te małe straty jako nieodłączną część pracy. 00:17:05.660 --> 00:17:09.160 10 minut szukania wartości konfiguracyjnej, kolejne 15 na ponowne uruchomienie 00:17:09.160 --> 00:17:11.980 po pominięciu referencji lub skakanie między plikami, by sprawdzić połączenia. 00:17:12.220 --> 00:17:15.700 Z osobna wydają się nieistotne, ale zsumowane w trakcie całego sprintu 00:17:15.700 --> 00:17:18.300 kształtują to, ile realnej wartości zostaje dostarczone. 00:17:18.480 --> 00:17:22.180 To, co wygląda na rutynowe działania, ukrywa prawdziwe opóźnienie w harmonogramach dostaw. 00:17:22.340 --> 00:17:25.160 Ukryty ciężar nie leży w czasie kompilacji ani szybkości pisania. 00:17:25.400 --> 00:17:27.740 Leży w przerywanym rytmie narzuconym twojej koncentracji. 00:17:27.960 --> 00:17:30.160 Za każdym razem, gdy przechodzisz z jednego pliku do drugiego, 00:17:30.260 --> 00:17:31.120 twój mózg się resetuje. 00:17:31.120 --> 00:17:36.020 Ten reset ma swoją cenę. Przerzucenie powtarzalnych poprawek na agenta zmniejsza to obciążenie. 00:17:36.260 --> 00:17:39.540 Zamiast ciągle odtwarzać kontekst, skupiasz się na tym, co ważne, 00:17:39.740 --> 00:17:41.680 rozwiązując większe problemy projektowe. 00:17:41.920 --> 00:17:44.840 Wiele zespołów nie śledzi tych mikrokosztów, ponieważ nie pojawiają się one 00:17:44.840 --> 00:17:46.580 w zgłoszeniach Jira ani w historii Git. 00:17:46.760 --> 00:17:50.340 Praca, która donikąd nie prowadzi, nie jest logowana, ale nadal zużywa energię. 00:17:50.460 --> 00:17:53.420 A w miarę skalowania baz kodu, to tarcie nie rośnie tylko liniowo. 00:17:53.680 --> 00:17:56.180 Więcej warstw oznacza więcej zależności do utrzymania w pamięci 00:17:56.180 --> 00:17:58.580 i więcej szans na stratę czasu na samodopasowanie struktury, 00:17:58.580 --> 00:18:01.520 zanim będzie można ruszyć dalej. Przepływy pracy z agentami zmieniają 00:18:01.520 --> 00:18:03.420 rachunek, uderzając bezpośrednio w te straty. 00:18:03.660 --> 00:18:05.620 Nie tylko szybciej wypełniają szkielety metod. 00:18:05.800 --> 00:18:07.560 Redukują pętlę wyszukiwania, poprawiania 00:18:07.560 --> 00:18:09.740 i ponownego uruchamiania, które zjadają popołudnia. 00:18:09.960 --> 00:18:11.620 Zespoły korzystające z pracy agentów 00:18:11.620 --> 00:18:13.380 zgłaszają w wielu przypadkach krótszy czas 00:18:13.380 --> 00:18:15.080 odblokowania zadań. W tym filmie 00:18:15.080 --> 00:18:17.380 zaprezentujemy zadanie przed i po, abyś mógł 00:18:17.380 --> 00:18:19.360 ocenić efekt. Nagram czas potrzebny 00:18:19.360 --> 00:18:21.340 na wdrożenie tej samej funkcji Azure ręcznie, 00:18:21.460 --> 00:18:23.320 a następnie z użyciem agenta, abyś mógł 00:18:23.320 --> 00:18:25.240 zobaczyć wzrost produktywności w konkretnych 00:18:25.240 --> 00:18:27.260 liczbach. Z perspektywy biznesowej wartość 00:18:27.260 --> 00:18:29.200 ta uwidacznia się w tempie realizacji projektu. 00:18:29.400 --> 00:18:31.280 Szybsze cykle to nie tylko kwestia zadowolenia 00:18:31.280 --> 00:18:33.260 programistów. Decydują one o tym, czy funkcje 00:18:33.260 --> 00:18:35.120 trafią do tego wydania, czy zostaną przesunięte 00:18:35.120 --> 00:18:37.040 o kwartały. Wpływają na dług techniczny, 00:18:37.100 --> 00:18:39.140 ponieważ mniej haków i regresji trafia do 00:18:39.140 --> 00:18:41.300 backlogu. Płynniejszy proces pozwala zespołom 00:18:41.300 --> 00:18:43.440 działać sprawnie, zamiast wracać do niedokończonej 00:18:43.440 --> 00:18:45.200 pracy z poprzedniego sprintu. Ta spójność 00:18:45.200 --> 00:18:47.040 z czasem przekłada się na mniejszą liczbę sytuacji 00:18:47.040 --> 00:18:48.920 awaryjnych i skuteczniejsze dostarczanie efektów. 00:18:48.920 --> 00:18:50.580 Istnieje również czynnik ludzki. 00:18:50.800 --> 00:18:52.700 Dzień stracony na szukanie błędów wyczerpuje 00:18:52.700 --> 00:18:54.620 każdego inżyniera. Gdy jesteś zmęczony, 00:18:54.740 --> 00:18:56.540 trudniej o czysty projekt, szczegóły umykają, 00:18:56.640 --> 00:18:58.500 a błędy wkradają się do kodu. Przenosząc 00:18:58.500 --> 00:19:00.480 mechaniczne poprawki na agenta, programiści 00:19:00.480 --> 00:19:02.420 zachowują koncentrację przez dłuższy czas. 00:19:02.580 --> 00:19:04.440 To dodatkowe skupienie zwiększa zarówno 00:19:04.440 --> 00:19:06.720 produktywność, jak i jakość. Gdy nie 00:19:06.720 --> 00:19:08.720 blokuje Cię powtarzalne tarcie, możesz 00:19:08.720 --> 00:19:10.860 myśleć szerzej i planować skuteczniej. 00:19:11.100 --> 00:19:12.920 W praktyce różnica wygląda tak. 00:19:13.100 --> 00:19:14.600 Nowa funkcja Azure z wieloma 00:19:14.600 --> 00:19:16.560 powiązaniami i integracjami usług 00:19:16.560 --> 00:19:18.480 może zająć samodzielnie dwa pełne dni. 00:19:18.780 --> 00:19:20.900 Przez konfigurację, testowanie i poprawianie 00:19:20.900 --> 00:19:22.600 niedopasowanych referencji zadanie 00:19:22.600 --> 00:19:24.680 ciągnie się w nieskończoność. Z pomocą 00:19:24.680 --> 00:19:26.700 agenta tę samą funkcję można stworzyć 00:19:26.700 --> 00:19:28.640 w pół dnia. Nie dlatego, że idziemy na 00:19:28.640 --> 00:19:30.700 skróty, ale dlatego, że konfiguracja plików 00:19:30.700 --> 00:19:32.200 i orkiestracja działają od razu. 00:19:32.420 --> 00:19:34.620 Harmonogram skraca się dzięki wyeliminowaniu błędnych 00:19:34.620 --> 00:19:36.520 startów i zbędnego wysiłku. Niektórzy 00:19:36.520 --> 00:19:38.520 programiści wyrażają słuszną obawę. Czy 00:19:38.520 --> 00:19:40.520 poleganie na AI przy utrzymaniu kodu osłabia 00:19:40.520 --> 00:19:42.660 własne umiejętności? Ta perspektywa często 00:19:42.660 --> 00:19:44.140 pomija to, co naprawdę się zmienia. 00:19:44.140 --> 00:19:46.580 Odciążenie od powtarzalnej konfiguracji nie osłabia 00:19:46.580 --> 00:19:48.400 wiedzy, lecz zachowuje ją dla projektowania 00:19:48.400 --> 00:19:50.900 i architektury, gdzie liczy się osąd. W rzeczywistości 00:19:50.900 --> 00:19:52.440 zyskujesz przestrzeń na rozwiązywanie 00:19:52.440 --> 00:19:54.580 problemów wyższego rzędu, zamiast marnować energię 00:19:54.580 --> 00:19:56.620 na poprawki. Jeśli wypróbujesz to rozwiązanie 00:19:56.620 --> 00:19:58.460 napisz w komentarzu, ile godzin odzyskałeś 00:19:58.460 --> 00:20:00.440 w splincie. Ciekawe odpowiedzi wykorzystam 00:20:00.440 --> 00:20:02.560 w przyszłych filmach. Słuchanie o tym, jak inne 00:20:02.560 --> 00:20:04.500 zespoły doświadczają tej zmiany, daje lepszy 00:20:04.500 --> 00:20:06.960 obraz realnej wartości poza wersjami demonstracyjnymi. 00:20:07.200 --> 00:20:08.780 Uwaga jednak, automatyzacja pomaga, 00:20:08.780 --> 00:20:10.520 ale bezpieczeństwo nadal jest kluczowe. 00:20:10.720 --> 00:20:12.460 Zawsze uruchamiaj testy i używaj przeglądu 00:20:12.460 --> 00:20:14.360 kodu, aby zweryfikować zmiany stworzone przez 00:20:14.360 --> 00:20:16.280 agenta. Wierz w redukcję żmudnej pracy, 00:20:16.460 --> 00:20:18.100 ale zachowaj dotychczasowe zabezpieczenia. 00:20:18.320 --> 00:20:20.100 Różnica w prędkości opłaca się tylko wtedy, 00:20:20.260 --> 00:20:22.360 gdy jakość pozostaje stabilna. Solidne testy 00:20:22.360 --> 00:20:24.400 i inteligentna weryfikacja PR chronią potok 00:20:24.400 --> 00:20:25.940 wydań przed kruchą automatyzacją. 00:20:26.220 --> 00:20:28.240 Zysk polega nie tyle na szybkim pisaniu linii 00:20:28.240 --> 00:20:30.260 kodu, co na zwolnieniu przestrzeni dla tworzenia 00:20:30.260 --> 00:20:32.260 lepszych rozwiązań. Przy mniejszym zmęczeniu 00:20:32.260 --> 00:20:33.100 i mniejszej liczbie.