Latest / M365.FM – podcast o Microsoft 365, Copilot i AI po polsku / Koniec z łataniem błędów: tryb agenta GitHub Copilot dla .NET i Azure (Dubbing AI)

Transcript

Koniec z łataniem błędów: tryb agenta GitHub Copilot dla .NET i Azure (Dubbing AI) · M365.FM – podcast o Microsoft 365, Copilot i AI po polsku

• 0:00
  Gotowi na 10 dni Microsoft 365, Kopilota, AI, Azure oraz ludzi kształtujących przyszłość pracy?
• 0:07
  W styczniu wraca M365Con i tym razem działamy z większym rozmachem.
• 0:12
  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.
• 0:18
  Żadnych nudnych prezentacji, żadnych niekończących się modnych haseł.
• 0:22
  Zajmujemy się prawdziwymi wyzwaniami, Kopilot Studio agentami, AI Fabric, bezpieczeństwem, ładem korporacyjnym i automatyzacją.
• 0:29
  Niezależnie od tego, czy jesteś specjalistą i programistą, czy liderem biznesowym, mamy sesje przygotowane właśnie dla Ciebie.
• 0:35
  Podczas 10 pełnych dni zgłębisz wiele technologii i nawiążesz kontakty z globalną społecznością.
• 0:40
  Oglądaj na żywo i zabierz praktyczne wnioski do swojej organizacji.
• 0:44
  Styczeń 2027 roku, 10 dni, jedna społeczność Microsoft.
• 0:49
  Rejestracja jest już otwarta.
• 0:51
  Wejdź na m365con.net i zarezerwuj miejsce już dziś.
• 0:56
  To m365con.net
• 0:58
  Dołącz teraz na m365con.net i widzimy się na żywo w styczniu.
• 1:05
  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.
• 1:12
  Większość programistów pracuje reaktywnie, łatając tu i debugując tam.
• 1:15
  Tryb agenta w GitHub Kopilot ma na celu utrzymanie szerszego kontekstu i koordynację zmian między plikami.
• 1:20
  W tym filmie pokażemy, jak ten przepływ pracy wygląda w rzeczywistym projekcie .net i Azure.
• 1:25
  Przeanalizujemy działające rozwiązanie i pokażemy stan przed oraz po zmianach wprowadzonych przez agenta.
• 1:28
  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.
• 1:36
  Zanim jednak do tego przejdziemy, zacznijmy od ukrytych kosztów pętli debugowania, w której wielu z nas tkwi każdego dnia.
• 1:41
  Ukryty koszt doraźnego debugowania.
• 1:43
  Siadasz do naprawy błędu, który wygląda na dość prosty.
• 1:46
  Aplikacja nie chce się skompilować, a konsola wskazuje linię w głównym pliku projektu.
• 1:50
  Poprawiasz metodę, kompilujesz ponownie i myślisz, że rozwiązałeś problem, aż ten sam komunikat pojawia się w nieco innej formie.
• 1:56
  Mija kolejne pół godziny, zanim dostrzeżesz prawdziwy problem.
• 1:59
  Brakująca zależność ukryta gdzieś w innym folderze projektu.
• 2:02
  Zanim poprawisz referencję i wdrożysz zmiany, większość popołudnia przepada na łataniu błędów.
• 2:07
  Praca nad zaplanowaną funkcją zostaje przełożona na jutro.
• 2:09
  Ten wzorzec jest tak powszechny, że wydaje się normalny.
• 2:13
  Pracujesz do przodu, ponieważ każdy naprawiony błąd sprawia wrażenie sukcesu.
• 2:16
  W praktyce kręcisz się w kółko.
• 2:17
  Pętla to kodowanie, kompilacja, błąd, poprawka i powtórka.
• 2:21
  Godziny znikają na ściganiu przyczyn i skutków, a efektem netto jest reaktywny postęp, a nie realne usprawnienia.
• 2:27
  Ilu z Was straciło popołudnie na dokładnie taką pętlę?
• 2:29
  Zostaw komentarz, przeczytam najpopularniejsze odpowiedzi.
• 2:32
  To, co wyczerpuje w tym cyklu, to fakt, że nasze narzędzia stale się rozwijają, a schemat pracy nie.
• 2:37
  Edytory zyskują nowe funkcje, frameworki ewoluują, a integracje stają się głębsze, ale debugowanie wciąż wymaga reaktywnego podejścia.
• 2:44
  To jak próba powstrzymania pożaru za pomocą wiadra wody.
• 2:47
  Każdy wybuch jest gaszony na bieżąco, ale przyczyny, które go wywołały, pozostają, niemal gwarantując kolejny pożar.
• 2:52
  A z każdą zmianą karty ukryty koszt rośnie.
• 2:55
  Przechodzisz z klasy serwisowej do pliku konfiguracyjnego, a potem skaczesz do grafu zależności.
• 3:00
  Każda taka zmiana wyrywa Cię z toku myślenia, wymuszając mentalny reset.
• 3:04
  Nie chodzi tylko o sekundy spędzone na przełączaniu okien, ale o koszt odtwarzania kontekstu wciąż na nowo.
• 3:09
  W ciągu dnia te małe resety sumują się w coś naprawdę męczącego.
• 3:13
  Dla pojedynczych programistów zmęczenie objawia się frustracją i stratą czasu.
• 3:16
  W zespołach pracujących nad projektami korporacyjnymi wpływ ten się multiplikuje.
• 3:20
  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.
• 3:26
  Pogłębianie długu technicznego to tylko kolejny efekt uboczny godzin traconych na gaszenie pożarów.
• 3:31
  Wiele zespołów zgłasza, że znaczna część ich czasu pracy jest wysysana przez reaktywne debugowanie.
• 3:35
  To nie jest najbardziej ekscytująca część inżynierii.
• 3:38
  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.
• 3:44
  Kiedy naprawianie błędów staje się definicją postępu, tworzenie nowych funkcji schodzi na drugi plan, a architektura po cichu cierpi w tle.
• 3:51
  Niewygodna prawda jest taka, że doraźne debugowanie nie tylko spowalnia pracę.
• 3:55
  Wzmacnia kulturę reagowania zamiast projektowania.
• 3:58
  Spędzasz czas na gaszeniu pożarów, a nie na budowaniu systemów.
• 4:02
  Może to utrzymać produkt przy życiu na krótką metę, ale ogranicza skalowalność zespołu i pewność wdrażania zmian.
• 4:07
  Zatrzymajmy się więc przy tym obrazie gaszenie pożarów.
• 4:10
  Pędź do źródła ognia, wylej wodę, idź dalej.
• 4:12
  Problem nie polega na tym, że programiści nie są w tym dobrzy.
• 4:15
  Są.
• 4:15
  Problem w tym, że płomienie nigdy tak naprawdę nie gasną.
• 4:18
  Po prostu przenoszą się, wybuchając w nowych plikach, projektach i konfiguracjach, utrzymując wszystkich w trybie reagowania zamiast tworzenia.
• 4:25
  To rodzi pytanie, co by było, gdyby ten cykl nie spoczywał tylko na tobie?
• 4:29
  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?
• 4:36
  Bo choć presja gaszenia pożarów jest oczywista, istnieje inny punkt zapalny, którego jeszcze nie poruszyliśmy.
• 4:41
  Prawdziwy ciężar pojawia się, gdy projekt to nie tylko jeden plik czy moduł.
• 4:45
  Dzieje się tak, gdy potrzebna poprawka obejmuje wiele warstw jednocześnie.
• 4:48
  Wyobraź sobie, że otwierasz rozwiązanie, w którym logika rozciąga się na różne projekty, usługi i biblioteki.
• 4:54
  Potrzebny element znajduje się w trzech miejscach naraz, a utrzymanie tego w głowie to osobna walka.
• 5:01
  Chaos wielu plików kontra kontrola kontekstu przez AI.
• 5:03
  Gdy projekty obejmują wiele warstw, prawdziwym wyzwaniem nie jest pisanie kodu.
• 5:08
  Chodzi o to, by utrzymać wszystkie ruchome części w całości.
• 5:11
  Właśnie tutaj napięcie między chaosem wielu plików a kontrolą kontekstu przez AI ujawnia się najwyraźniej.
• 5:16
  Weźmy duże rozwiązanie .NET z kilkunastoma lub większą liczbą projektów.
• 5:19
  Każda nowa funkcja zazwyczaj dotyka kilku warstw jednocześnie.
• 5:22
  Kontroler w jednym miejscu, usługa w innym i zestaw plików konfiguracyjnych gdzie indziej.
• 5:27
  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.
• 5:35
  Taki przepływ pracy nie jest wyjątkiem.
• 5:37
  Jest to norma w aplikacjach korporacyjnych, zwłaszcza gdy w grę wchodzą usługi Azure i integracje.
• 5:42
  Struktura tych systemów nie jest płaska.
• 5:44
  Interfejsy mapowania, wstrzykiwania zależności i odwołania między projektami odgrywają tu swoją rolę.
• 5:50
  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ą.
• 5:58
  Koordynujesz kod w IDE, pliki konfiguracyjne na dysku i usługi zdefiniowane w chmurze.
• 6:03
  Żaden z nich nie przejmuje się tym, że wolisz mniej klikania.
• 6:06
  Za każdym razem, gdy zmieniasz kontekst, tracisz energię na odtwarzanie szerszego obrazu.
• 6:10
  Większość z nas próbuje żonglować tym kontekstem w pamięci roboczej.
• 6:13
  Początkowo jest to wykonalne, ale w miarę wzrostu projektu wkradają się błędy.
• 6:16
  Dodajesz nową metodę w usłudze, ale zapominasz o jej rejestracji w D.
• 6:19
  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.
• 6:25
  Nic Cię nie ostrzega aż do momentu uruchomienia, kiedy debugujesz zamiast budować.
• 6:28
  Sam kod nie jest najtrudniejszą częścią.
• 6:30
  Jest nią koordynacja między plikami.
• 6:32
  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.
• 6:42
  To drobne zakłócenie powtarzane dziesiątki razy dziennie.
• 6:44
  Te interakcje sumują się, tworząc tarcie, które hamuje realny postęp.
• 6:48
  Efektem jest wolniejsze dostarczanie nie dlatego, że pisanie jest wolne, ale dlatego, że utrzymywanie wszystkiego w synchronizacji kradnie koncentrację.
• 6:54
  Ten narzut rośnie w projektach typu Cloud First.
• 6:57
  Azure umieszcza kluczowe ustawienia w wielu miejscach, lokalnych plikach konfiguracyjnych, zmiennych środowiskowych, szablonach arm lub bicep oraz potokach chi ciąg dalszy.
• 7:06
  To, co wygląda na pojedyncze zgłoszenie funkcji, często rozciąga się na cztery warstwy abstrakcji.
• 7:10
  Ta złożoność nie jest opcjonalna.
• 7:12
  Jest ona wpisana w sposób działania całego ekosystemu.
• 7:15
  W tym właśnie miejscu tryb agenta, agent mode, stanowi potencjalny punkt zwrotny.
• 7:18
  Zamiast pozostawiać całą tę orkiestrację, tobie zaprojektowano go tak, aby utrzymywał szerszy kontekst w wielu plikach.
• 7:23
  Oznacza to, że gdy prosisz o zmianę w jednej warstwie, nie ignoruje on pozostałych.
• 7:27
  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.
• 7:34
  I on, a nawet sugerując odpowiednią rejestrację wstrzykiwania zależności, di.
• 7:38
  Zazwyczaj jest to wieloetapowy proces rozproszony w różnych plikach.
• 7:41
  Agent może usprawnić to działanie do postaci jednego przepływu.
• 7:44
  Nie chodzi o zastąpienie twojego osądu, lecz o usunięcie powtarzalnej pracy administracyjnej, abyś mógł skupić się na realnych wyborach projektowych.
• 7:50
  Ludzie potrafią utrzymać w głowie ogólny zarys lub szkic na tablicy.
• 7:54
  Sztuczna inteligencja potrafi śledzić szczegóły plik po pliku, nie tracąc przy tym wątku.
• 7:58
  To, co dla nas stanowi ogromne obciążenie poznawcze, dla agenta jest jedynie podstawowym kontekstem.
• 8:02
  W praktyce różnica polega na przejściu odżonglowania wieloma kartami do orkiestrowanych zmian, które pozostają ze sobą zsynchronizowane.
• 8:07
  Podczas prezentacji pokażę również utworzony przez agenta PulliQuest lub Div, abyś mógł zobaczyć dokładnie, jakie edycje zostały wprowadzone.
• 8:12
  Ta przejrzystość ma znaczenie.
• 8:14
  Masz pełną kontrolę, aby przejrzeć i zatwierdzić zmiany, podczas gdy żmudna praca nad aktualizacją wielu plików wykonuje się za Ciebie.
• 8:19
  Zamiast spędzać popołudnie na łączeniu fragmentów kodu, zlecasz zmianę raz, potwierdzasz wygenerowane aktualizacje i przechodzisz do projektowania na wyższym poziomie.
• 8:26
  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.
• 8:34
  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ą.
• 8:42
  I tu zaczyna się kolejny test, w jaki sposób błędy są wykrywane i naprawiane, gdy już się pojawią.
• 8:47
  Od polowania na błędy po autonomiczne poprawki.
• 8:49
  Pomyśl, jak często trafiasz na komunikat o błędzie, który wskazuje bezpośrednio na jeden konkretny plik.
• 8:53
  Podążasz za śladem stosu do wskazanej metody, wprowadzasz małą poprawkę i uruchamiasz ponowną kompilację.
• 8:58
  Wydaje się to oczywistym rozwiązaniem, dopóki ten sam błąd nie pojawi się ponownie w nieco innej formie.
• 9:03
  Wtedy zdajesz sobie sprawę, że ślad stosu wskazywał tylko objaw.
• 9:06
  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.
• 9:11
  Każdy programista doświadczył tego rodzaju zmylenia.
• 9:14
  To, co wygląda na problem, wcale nie jest miejscem, gdzie leży rozwiązanie.
• 9:16
  To błyskawicznie pożera czas.
• 9:18
  Poprawiasz jedną rzecz, przebudowujesz, czekasz.
• 9:20
  Potem wita Cię nowy błąd, prowadzący do kolejnego pliku, kolejnej poprawki i kolejnej przebudowy.
• 9:25
  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.
• 9:32
  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ś.
• 9:38
  Prawdziwym kosztem jest tutaj utracona szansa.
• 9:40
  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.
• 9:47
  Pęd marnuje się na domysły zamiast na projektowanie.
• 9:50
  W danej chwili wydaje się to pracą, ale te godziny niewiele wnoszą poza utrzymaniem systemu w stanie używalności.
• 9:56
  W skali zespołu ten powierzchowny ruch spowalnia wszystko i tworzy zaległości w funkcjach, które są ciągle przekładane.
• 10:01
  W tym miejscu przepływ pracy oparty na agencie zaczyna wyglądać inaczej.
• 10:05
  Pomysł nie polega na zatrzymaniu się na jednej linii wskazanej przez ślad stosu.
• 10:08
  Zamiast tego jest zaprojektowany tak, aby zachować kontekst całego systemu, pytając nie tylko, co powinien robić ten plik,
• 10:14
  ale jaka sekwencja zmian jest potrzebna w powiązanych elementach, aby przywrócić spójność.
• 10:18
  W praktyce oznacza to, że agent może proponować edycje obejmujące wiele plików.
• 10:22
  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,
• 10:29
  zamiast zmuszać Cię do ich szukania.
• 10:30
  To krok od autouzupełniania ku czemuś znacznie szerszemu.
• 10:33
  Autouzupełnianie kończy linię, a agent koordynuje działania w wielu plikach.
• 10:37
  Ta koordynacja jest najważniejsza, gdy błędy nie ograniczają się do jednego miejsca.
• 10:40
  Weźmy typowy scenariusz Azure.
• 10:42
  Stworzyłeś nową aplikację funkcji, ale po wdrożeniu wyzwalacz kolejki zawodzi, ponieważ powiązanie nie pasuje do sygnatury metody.
• 10:48
  Zazwyczaj przeszukujesz logi, sprawdzasz, które powiązanie jest błędne, ręcznie dostosowujesz pliki od SON funkcji,
• 10:53
  a może nawet zmieniasz szablon infrastruktury, jeśli tam również wartość jest niedopasowana.
• 10:57
  Każdy krok to osobne polowanie, a każda poprawka uruchamia kolejny test.
• 11:01
  W trybie agenta przepływ pracy wygląda inaczej.
• 11:04
  Może on zaproponować zmiany kodu, wygenerować poprawne powiązanie JSON funkcji
• 11:07
  i wyświetlić propozycje edycji skryptów wdrożeniowych, jeśli są one niespójne.
• 11:10
  Przeglądasz, zatwierdzasz i idziesz naprzód, nie tracąc godzin na łączenie każdej warstwy z osobna.
• 11:14
  Kluczem jest tutaj zaufanie.
• 11:16
  Nikt nie powinien odnosić wrażenia, że w tle dzieją się niewidoczne edycje.
• 11:18
  Właśnie dlatego proces weryfikacji jest tak ważny.
• 11:20
  W tym demo przejdziemy przez to wspólnie.
• 11:22
  Agent sugeruje skoordynowane zmiany.
• 11:24
  Otwieramy podgląd zmian, aby sprawdzić, co dokładnie wygenerował model, uruchamiamy testy jednostkowe,
• 11:29
  walidujemy kompilację lokalnie i dopiero wtedy decydujemy o akceptacji lub odrzuceniu poprawek.
• 11:33
  Ta pętla walidacji zapewnia pełną kontrolę, eliminując jednocześnie żmudną pracę.
• 11:37
  Warto podkreślić, agenci AI pomagają działać szybciej, ale nie zastępują dobrych praktyk inżynierskich.
• 11:42
  Nadal należy traktować przeglądy kodu i systemy ci jako nienegocjowalne punkty kontrolne.
• 11:45
  Niech AI skróci czas poświęcany na pracę detektywistyczną,
• 11:48
  ale automatyczne testy i weryfikacja przez ludzi pozostaną siecią bezpieczeństwa.
• 11:51
  Taka równowaga rozwiązuje problem zaufania i zapewnia, że zysk szybkości nie osłabia stabilności.
• 11:55
  Różnica w prędkości nie jest teoretyczna.
• 11:58
  Tam, gdzie szukanie błędów i ręczne poprawki zajmują pół dnia,
• 12:00
  skoordynowane sugestie mogą skrócić ten czas do kilku minut,
• 12:03
  a odzyskany czas można przeznaczyć na pracę, na której faktycznie chcesz się skupić.
• 12:07
  Na funkcje, które zauważą użytkownicy i decyzje architektoniczne, które poprawiają jakość twojego kodu.
• 12:11
  Zamiast gasić pożary w trakcie działania programu, możesz projektować pewnie od samego początku.
• 12:15
  Więc pętla debugowania nie musi już definiować twojego dnia.
• 12:18
  Gdy agent sugeruje aktualizację w wielu plikach,
• 12:20
  przechodzisz od chaotycznego przeszukiwania do rytmu przeglądania i zatwierdzania.
• 12:24
  Przestajesz błądzić wśród błędów w kółko i zaczynasz traktować debugowanie jako uporządkowany,
• 12:28
  niemal zautomatyzowany etap pracy.
• 12:30
  Ta zmiana uwalnia przestrzeń poznawczą i czas w kalendarzu na tworzenie nowych funkcji,
• 12:33
  a nie tylko naprawianie usterek.
• 12:34
  A gdy usuwanie błędów przestaje polegać na gonitwie za objawami,
• 12:37
  otwiera to drogę do czegoś większego.
• 12:39
  Możesz zacząć tworzyć całe funkcje w ten sam ustrukturyzowany sposób.
• 12:43
  Wyobraź sobie, że ten sam przepływ pracy, który proponuje skoordynowane poprawki,
• 12:46
  może również przyjąć opis w języku naturalnym i zbudować wokół niego gotową strukturę.
• 12:50
  W tym miejscu zaczyna się kolejny etap rozwoju.
• 12:53
  Programowanie sterowane specyfikacją bez zbędnego narzutu.
• 12:56
  Jedna z najciekawszych zmian zachodzi, gdy przestajesz myśleć tylko o plikach i metodach,
• 13:00
  a zaczynasz formułować zadania w języku naturalnym.
• 13:02
  Właśnie tutaj wkracza programowanie sterowane specyfikacją bez zbędnego narzutu.
• 13:06
  Wyobraź sobie, że piszesz proste zapytanie o nową funkcję.
• 13:08
  Dodaj przepływ raportowania, który generuje comiesięczne podsumowania,
• 13:11
  zapisuje je i udostępnia za pomocą strony administratora.
• 13:14
  Zamiast otrzymywać jedynie izolowane fragmenty kodu,
• 13:17
  otrzymujesz gotową strukturę rozplanowaną w całej aplikacji.
• 13:20
  Kontrolery utworzone, modele gotowe, usługi zarejestrowane, a konfiguracja połączona.
• 13:24
  To przejście od opisu intencji do zobaczenia gotowego szkieletu w projekcie sprawia,
• 13:28
  że to podejście wydaje się wreszcie praktyczne, a nie teoretyczne.
• 13:31
  W tradycyjnych rozwiązaniach tworzenie oparte na specyfikacji ma opinię uciążliwego procesu.
• 13:36
  W dużych organizacjach zazwyczaj oznacza to długie dokumenty wymagań,
• 13:39
  wielostronicowe projekty i sztywne diagramy, które wszystkich spowalniają.
• 13:42
  Mają one sens w regulowanych branżach lub rozproszonych zespołach,
• 13:45
  ale w codziennym programowaniu większość twórców je pomija.
• 13:47
  Pisanie i utrzymywanie szczegółowych specyfikacji generuje koszty,
• 13:50
  na które nikt nie ma czasu ani cierpliwości.
• 13:52
  To dodatkowa praca ponad dostarczanie funkcji,
• 13:54
  a gdy zbliżają się terminy, te dodatkowe cykle są zazwyczaj poświęcane.
• 13:57
  Ironia jest oczywista, programiści tak naprawdę lubią myśleć w szerszej perspektywie.
• 14:01
  Znajomość struktury z wyprzedzeniem jest uspokajająca.
• 14:04
  Problemem nie są intencje, lecz utrzymanie dokumentacji.
• 14:06
  Gdy specyfikacja zaczyna rozmijać się z rzeczywistością, jej aktualizacja staje się ciężarem.
• 14:10
  Dlatego tak wiele prac w świecie rzeczywistym zmierza w stronę improwizacji,
• 14:13
  a nie pełnego projektu, nawet w firmach, które technicznie wspierają dokładne planowanie.
• 14:17
  Przepływ pracy oparty na agentach oferuje alternatywę.
• 14:20
  Zamiast wymagać dopracowanego dokumentu projektowego,
• 14:22
  może on pomóc przekształcić specyfikację w prostym języku w szkielet, który możesz udoskonalić.
• 14:26
  Nie potrzebujesz diagramów UML, ani ręcznie rysowanych map interfejsów.
• 14:30
  Możesz po prostu powiedzieć, stwórz moduł raportowania z nowym punktem końcowym API,
• 14:34
  połącz go z pamięcią masową i zabezpiecz dostępem opartym na rolach,
• 14:37
  a system wygeneruje bazę w plikach Twojego rozwiązania .NET.
• 14:40
  W demo przeczytam specyfikację napisaną prostym językiem,
• 14:43
  pokażę pliki stworzone przez agenta kontrolery,
• 14:46
  modele i rejestrację usług oraz wskażę miejsca, które nadal wymagały ręcznej poprawy.
• 14:50
  W ten sposób będziesz mógł samodzielnie ocenić jakość.
• 14:53
  Tworzy to złoty środek między dwoma trybami pracy programisty.
• 14:56
  Z jednej strony mamy Vibe Codding – szybkie i swobodne, ale kruche w systemach długoterminowych.
• 15:01
  Z drugiej strony mamy projektowanie oparte na specyfikacji niezawodne, ale boleśnie wolne.
• 15:06
  Dzięki wsparciu agenta opisujesz pomysł naturalnymi słowami,
• 15:08
  pojawia się szkielet i możesz iterować niemal tak szybko jak w Vibe Codding,
• 15:12
  zachowując korzyści zorganizowanej struktury.
• 15:14
  Wróćmy do tego przepływu pracy z raportowaniem.
• 15:16
  Zazwyczaj musiałbyś stworzyć model, zbudować usługę danych, podpiąć kontroler,
• 15:20
  skonfigurować zabezpieczenia i połączyć wszystko przy starcie.
• 15:23
  Oznacza to skakanie po wielu plikach i nadzieję, że spójność zostanie zachowana.
• 15:27
  Dzięki temu podejściu szkielet wskakuje na swoje miejsce od razu.
• 15:30
  Prawdziwe oszczędności wynikają mniej z pisania mniejszej liczby linii,
• 15:32
  a bardziej z unikania błędów między plikami,
• 15:34
  takich jak zapomnienie o rejestracji nowej usługi po jej zbudowaniu.
• 15:37
  Oczywiście zawsze pojawia się kwestia stylu.
• 15:39
  Czy AI narzuci standardowy kod lub nadpisze konwencje?
• 15:42
  W praktyce agenty często odzwierciedlają w swoich sugestiach wzorce istniejące w projekcie.
• 15:46
  W demo zobaczysz obie strony.
• 15:48
  Miejsca, w których idealnie dopasowało się do struktury kontrolerów naszych ludzi
• 15:51
  oraz miejsca, w których jego domysły się rozminęły.
• 15:54
  Ta mieszanka jest istotna.
• 15:55
  Będziesz wiedzieć, czemu możesz ufać, a co nadal musisz skorygować.
• 15:58
  Efekt końcowy to nie szablonowy kod.
• 16:00
  Nadal czuć, że to twój projekt, tylko z mniejszą ilością ręcznej pracy nad szkieletem.
• 16:04
  Zachowujesz szybkość, opierając się na fundamencie,
• 16:06
  który możesz udoskonalać pod kątem przyszłego rozwoju.
• 16:09
  Zamiast ograniczać tworzenie specyfikacji do architektów z cierpliwością do diagramów,
• 16:13
  staje się ono narzędziem dla każdego programisty,
• 16:15
  który chce szybko eksperymentować bez utraty porządku.
• 16:17
  A kiedy stanie się to częścią codziennej pracy,
• 16:19
  specyfikacja przestaje wydawać się formalnym krokiem korporacyjnym,
• 16:23
  a staje się lekkim skrótem myślowym.
• 16:25
  Opisujesz swoje zamiary, system przygotowuje grunt,
• 16:27
  a ty skupiasz się na dopracowaniu szczegółów.
• 16:29
  Większy wpływ płynie nie tylko z generowanego kodu,
• 16:32
  ale z tego, co oszczędność czasu oznacza tydzień po tygodniu.
• 16:35
  Więcej godzin na funkcję, mniej żmudnej konfiguracji.
• 16:37
  To prowadzi nas bezpośrednio do pytania,
• 16:39
  które każdego programistę interesuje najbardziej.
• 16:42
  Co te zmiany faktycznie wnoszą w kontekście produktywności?
• 16:45
  Zysk z produktywności.
• 16:47
  Prawdziwe pytanie nie brzmi, czy zaoszczędzisz kilka minut tu i tam,
• 16:50
  ale jak te drobne zmiany sumują się w znaczące godziny w skali tygodnia.
• 16:54
  To właśnie jest zysk z produktywności.
• 16:56
  Odzyskiwanie czasu, który zazwyczaj niezauważalnie ucieka
• 16:59
  przez przełączanie kontekstu, powtarzane cykle budowania i ręczne poprawki.
• 17:02
  Większość programistów akceptuje te małe straty jako nieodłączną część pracy.
• 17:05
  10 minut szukania wartości konfiguracyjnej, kolejne 15 na ponowne uruchomienie
• 17:09
  po pominięciu referencji lub skakanie między plikami, by sprawdzić połączenia.
• 17:12
  Z osobna wydają się nieistotne, ale zsumowane w trakcie całego sprintu
• 17:15
  kształtują to, ile realnej wartości zostaje dostarczone.
• 17:18
  To, co wygląda na rutynowe działania, ukrywa prawdziwe opóźnienie w harmonogramach dostaw.
• 17:22
  Ukryty ciężar nie leży w czasie kompilacji ani szybkości pisania.
• 17:25
  Leży w przerywanym rytmie narzuconym twojej koncentracji.
• 17:27
  Za każdym razem, gdy przechodzisz z jednego pliku do drugiego,
• 17:30
  twój mózg się resetuje.
• 17:31
  Ten reset ma swoją cenę. Przerzucenie powtarzalnych poprawek na agenta zmniejsza to obciążenie.
• 17:36
  Zamiast ciągle odtwarzać kontekst, skupiasz się na tym, co ważne,
• 17:39
  rozwiązując większe problemy projektowe.
• 17:41
  Wiele zespołów nie śledzi tych mikrokosztów, ponieważ nie pojawiają się one
• 17:44
  w zgłoszeniach Jira ani w historii Git.
• 17:46
  Praca, która donikąd nie prowadzi, nie jest logowana, ale nadal zużywa energię.
• 17:50
  A w miarę skalowania baz kodu, to tarcie nie rośnie tylko liniowo.
• 17:53
  Więcej warstw oznacza więcej zależności do utrzymania w pamięci
• 17:56
  i więcej szans na stratę czasu na samodopasowanie struktury,
• 17:58
  zanim będzie można ruszyć dalej. Przepływy pracy z agentami zmieniają
• 18:01
  rachunek, uderzając bezpośrednio w te straty.
• 18:03
  Nie tylko szybciej wypełniają szkielety metod.
• 18:05
  Redukują pętlę wyszukiwania, poprawiania
• 18:07
  i ponownego uruchamiania, które zjadają popołudnia.
• 18:09
  Zespoły korzystające z pracy agentów
• 18:11
  zgłaszają w wielu przypadkach krótszy czas
• 18:13
  odblokowania zadań. W tym filmie
• 18:15
  zaprezentujemy zadanie przed i po, abyś mógł
• 18:17
  ocenić efekt. Nagram czas potrzebny
• 18:19
  na wdrożenie tej samej funkcji Azure ręcznie,
• 18:21
  a następnie z użyciem agenta, abyś mógł
• 18:23
  zobaczyć wzrost produktywności w konkretnych
• 18:25
  liczbach. Z perspektywy biznesowej wartość
• 18:27
  ta uwidacznia się w tempie realizacji projektu.
• 18:29
  Szybsze cykle to nie tylko kwestia zadowolenia
• 18:31
  programistów. Decydują one o tym, czy funkcje
• 18:33
  trafią do tego wydania, czy zostaną przesunięte
• 18:35
  o kwartały. Wpływają na dług techniczny,
• 18:37
  ponieważ mniej haków i regresji trafia do
• 18:39
  backlogu. Płynniejszy proces pozwala zespołom
• 18:41
  działać sprawnie, zamiast wracać do niedokończonej
• 18:43
  pracy z poprzedniego sprintu. Ta spójność
• 18:45
  z czasem przekłada się na mniejszą liczbę sytuacji
• 18:47
  awaryjnych i skuteczniejsze dostarczanie efektów.
• 18:48
  Istnieje również czynnik ludzki.
• 18:50
  Dzień stracony na szukanie błędów wyczerpuje
• 18:52
  każdego inżyniera. Gdy jesteś zmęczony,
• 18:54
  trudniej o czysty projekt, szczegóły umykają,
• 18:56
  a błędy wkradają się do kodu. Przenosząc
• 18:58
  mechaniczne poprawki na agenta, programiści
• 19:00
  zachowują koncentrację przez dłuższy czas.
• 19:02
  To dodatkowe skupienie zwiększa zarówno
• 19:04
  produktywność, jak i jakość. Gdy nie
• 19:06
  blokuje Cię powtarzalne tarcie, możesz
• 19:08
  myśleć szerzej i planować skuteczniej.
• 19:11
  W praktyce różnica wygląda tak.
• 19:13
  Nowa funkcja Azure z wieloma
• 19:14
  powiązaniami i integracjami usług
• 19:16
  może zająć samodzielnie dwa pełne dni.
• 19:18
  Przez konfigurację, testowanie i poprawianie
• 19:20
  niedopasowanych referencji zadanie
• 19:22
  ciągnie się w nieskończoność. Z pomocą
• 19:24
  agenta tę samą funkcję można stworzyć
• 19:26
  w pół dnia. Nie dlatego, że idziemy na
• 19:28
  skróty, ale dlatego, że konfiguracja plików
• 19:30
  i orkiestracja działają od razu.
• 19:32
  Harmonogram skraca się dzięki wyeliminowaniu błędnych
• 19:34
  startów i zbędnego wysiłku. Niektórzy
• 19:36
  programiści wyrażają słuszną obawę. Czy
• 19:38
  poleganie na AI przy utrzymaniu kodu osłabia
• 19:40
  własne umiejętności? Ta perspektywa często
• 19:42
  pomija to, co naprawdę się zmienia.
• 19:44
  Odciążenie od powtarzalnej konfiguracji nie osłabia
• 19:46
  wiedzy, lecz zachowuje ją dla projektowania
• 19:48
  i architektury, gdzie liczy się osąd. W rzeczywistości
• 19:50
  zyskujesz przestrzeń na rozwiązywanie
• 19:52
  problemów wyższego rzędu, zamiast marnować energię
• 19:54
  na poprawki. Jeśli wypróbujesz to rozwiązanie
• 19:56
  napisz w komentarzu, ile godzin odzyskałeś
• 19:58
  w splincie. Ciekawe odpowiedzi wykorzystam
• 20:00
  w przyszłych filmach. Słuchanie o tym, jak inne
• 20:02
  zespoły doświadczają tej zmiany, daje lepszy
• 20:04
  obraz realnej wartości poza wersjami demonstracyjnymi.
• 20:07
  Uwaga jednak, automatyzacja pomaga,
• 20:08
  ale bezpieczeństwo nadal jest kluczowe.
• 20:10
  Zawsze uruchamiaj testy i używaj przeglądu
• 20:12
  kodu, aby zweryfikować zmiany stworzone przez
• 20:14
  agenta. Wierz w redukcję żmudnej pracy,
• 20:16
  ale zachowaj dotychczasowe zabezpieczenia.
• 20:18
  Różnica w prędkości opłaca się tylko wtedy,
• 20:20
  gdy jakość pozostaje stabilna. Solidne testy
• 20:22
  i inteligentna weryfikacja PR chronią potok
• 20:24
  wydań przed kruchą automatyzacją.
• 20:26
  Zysk polega nie tyle na szybkim pisaniu linii
• 20:28
  kodu, co na zwolnieniu przestrzeni dla tworzenia
• 20:30
  lepszych rozwiązań. Przy mniejszym zmęczeniu
• 20:32
  i mniejszej liczbie.