|
Cześć ! Dziś parę słów od Kuby Kubryńskiego - na podstawie jednej z naszych lekcji DEMO z Architekta Jutra ». BTW, piszecie mi, że te lekcje robią robotę i pokazują dlaczego warto dołączyć do tego szkolenia. I super :). A teraz wyobraź sobie... Odpalasz agenta na swoim systemie. Prosisz o zmianę w jednym miejscu. Dostajesz PR-a, który dotyka siedemnastu plików i wprowadza trzecią implementację tej samej funkcji. Więc zmieniasz model. Na nowszy, droższy, z większym oknem kontekstu. I dostajesz dokładnie to samo, tylko szybciej. Problem nie polega na tym, że cały kod nie mieści się w kontekście. Agent i tak nie ładuje go w całości, tylko po nim nawiguje. Problem polega na tym, że często nie wie, gdzie ma patrzeć. Nie ma kontraktu, który da się sprawdzić maszynowo. Nie ma granicy, o której można powiedzieć: po tej stronie rób co chcesz, a po tamtej nie ruszaj. Więc każda zmiana ma promień rażenia równy całemu systemowi, a jedyną weryfikacją jest to, czy ktoś doświadczony zdąży przeczytać diff. A wiemy wszyscy, że trend jest jeden: te diffy będą czytane coraz rzadziej. Człowiek ma całą wiedzę w głowie od lat pracy przy systemie. A agent nie ma nic. Chyba, że odpowiednio zaprojektujemy to, co dostanie. Kuba Kubryński ma na to nazwę. Podręcznikową, i sam jej nie znosi. W lekcji DEMO Kuba mówi wprost: "Nie lubię nazwy Microkernel. Bo "mikro" wszystkim się myli. Ludzie myśleli, że mikroserwis ma tysiąc linii. Porządny ma siedemdziesiąt tysięcy. Tutaj jest ta sama pułapka. Podręcznikowy Microkernel mówi: rdzeń robi absolutne minimum. Brzmi elegancko. A oznacza, że cała reszta spada na pluginy: "Chcesz napisać plugin do fakturowania i zamiast rozmawiać z agentem o stawkach VAT, rozmawiasz o tym, jaką bazę użyć, jakiej biblioteki użyć do parsowania tokenów JWT, jaki boilerplate napisać do wysyłki maili. (...) W pluginie A wysyłka maili będzie przez SendGrid, a w pluginie B używamy Mailjeta, bo tak się akurat wygenerowało." Poznajesz? To jest dokładnie ta trzecia implementacja tej samej funkcji, o której pisałem wcześniej. Więc Kuba idzie w drugą stronę i nazywa to macrokernelem. Rdzeń gruby. Zabetonowany. I wystawia SDK. Jedno zdanie: “To jest taki obszar off-limits dla agentów, To jest ta granica. Nie w Confluence, nie w README, nie w głowie tech leada. Tylko w kodzie, w SDK, w czymś, o co agent na pewno zahaczy. Co to zmienia w praktyce: “Zamiast pisać 100 linii kodu do sprawdzenia uprawnień, nasz agent uczy się użyć metody np. requirePermission. Zamiast zastanawiać się, w jaki sposób zintegrować się z Kafką czy z Rabbitem (…), mamy EventBus.publish.” Można to przenieść na znane i uniwersalne narzędzia, jak IDE. VS Code albo Eclipse? Żaden plugin nie definiuje od zera, czym jest dokument. Dostajesz gotowy obiekt platformowy i dokładasz do niego swoje modyfikacje i funkcje. Nie wymyślasz "dokumentu" od nowa. A w swoim systemie pozwalasz na to agentowi codziennie. I stąd bierze się naprawdę całe mnóstwo problemów. I teraz rzecz, dzięki której Architekt Jutra jest bardzo praktycznym i wartościowym projektem: Na koniec tej samej lekcji Kuba mówi, komu to się NIE opłaca: "Jeżeli Twój projekt ma na przykład 20 tysięcy linii kodu, Jeśli masz mały, czysty projekt, to dowiesz się, jak działać w WIĘKSZEJ skali, ale nie wdrożysz tego u siebie natychmiast. I bardzo dobrze, bo po co marnować czas i zasoby? W Architekcie Jutra dostajesz dostęp do masy praktycznego, codziennego doświadczenia trzech świetnych speców prosto z placu boju. Kuba dorzuca jedno zastrzeżenie: liczy się nie to, ile linii masz dziś, tylko ile będziesz miał. Jeśli projektujesz system, o którym już wiesz, że urośnie, to jest dokładnie ten moment. Macrokernel to jeden z sześciu tematów jednego modułu. Dziś otwieramy moduł 2 w całości: A pojutrze, w środę 2 września o 21:00, zamykamy nabór do 2. Edycji. == TUTAJ dołączysz do 2. Edycji Architekta Jutra » == Doskonale znasz moją obietnicę: nigdy nie będzie taniej. Wręcz przeciwnie, kolejna edycja - jeśli powstanie - prawdopodobnie będzie droższa. A tę wiedzę warto poznać i wdrażać już teraz. Zapraszamy! Pozdro! |