[i tłumaczy dlaczego]  ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­

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.
Nie lubię z tego samego powodu,
z którego nie lubię nazwy mikroserwisy.
"

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,
które implementują plugin.”

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,
to implementowanie architektury pluginowej nie ma najmniejszego sensu. (...) To jest strzelanie z armaty do wróbli."

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.
A modułów jest aż dziesięć. O projektowaniu systemów i procesu SDLC tak, by w pełni wykorzystać potencjał dzisiejszych narzędzi.

Obejrzyj i oceń.

Dziś otwieramy moduł 2 w całości:
Architektura modułowa jako maksymalizacja możliwości AI”.

A pojutrze, w środę 2 września o 21:00, zamykamy nabór do 2. Edycji.

== TUTAJ dołączysz do 2. Edycji Architekta Jutra » ==
(2 499 PLN brutto | raty 3x 0% | zwrot do 20 września)

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.
Nowy Rok Szkolny to świetny moment na uzupełnienie swoich kompetencji.
To naprawdę robi różnicę.

Zapraszamy!

Pozdro!
Maciej Aniserowicz z ekipą devstyle i AJ
architektjutra.pl | devstyle.pl