Jak zamieniłem wiedzę z lekcji kursu AI-Devs-4 w pamięć decyzyjną dla siebie i moich asystentów AI

Ukończyłem AI-Devs-4 z czymś, czego nie da się zmierzyć samą liczbą przerobionych lekcji, zadań czy commitów.

Od początku kursu miałem jedno dodatkowe postanowienie: razem z materiałem będę budował bazę wiedzy merytorycznej dla siebie i dla moich asystentów AI. Nie archiwum notatek. Raczej graf pojęć, narzędzi, przykładów i decyzji, z którego później będzie można korzystać przy realnej pracy nad projektami.

Przez vault rozumiem tutaj mój zbiór notatek w formacie .md, zebranych w katalogu otwartym w Obsidianie. Technicznie to pliki tekstowe. Praktycznie: moja prywatna wiki, w której pojedyncze notatki łączą się w graf wiedzy.

To założenie było dla mnie ważne, bo świat narzędzi AI zmienia się szybciej niż jakikolwiek kurs, dokumentacja czy pojedynczy model. Gdy pojawia się nowy framework, biblioteka albo usługa, nie chcę tylko zapytać modelu: „czy to jest dobre?”. Chcę móc dodać to do własnej wiki jako pojęcie lub narzędzie, połączyć z istniejącymi standardami i poprosić asystenta, żeby ocenił przydatność w kontekście konkretnego projektu: mojego stacku, moich ograniczeń, moich kryteriów technicznych i mojego sposobu pracy.

Problem nie polega na tym, że model nie zna pojęć.

Problem polega na tym, że nie wie, które z nich są częścią mojego sposobu pracy.

Bazowa wiedza modelu mówi mu, co istnieje. Web search mówi mu, co jest aktualne. RAG mówi mu, gdzie coś zapisano. Ale żadne z nich nie mówi mu, jak ja ważę decyzje: kiedy wolę prosty wrapper, kiedy potrzebuję warstwy pośredniej, kiedy narzędzie ma być częścią stacku, a kiedy jest tylko ciekawostką z internetu.

To ma dla mnie dodatkowe znaczenie, bo nie jestem programistą z klasyczną ścieżką kariery. Nie mam za sobą lat pracy w software house’ach, utrzymywania dużych systemów produkcyjnych i setek decyzji technologicznych podjętych jeszcze przed pojawieniem się LLM-ów. Moje wejście w kodowanie jest inne: bardziej projektowe, architektoniczne, wspierane przez agentów AI.

Właśnie dlatego ten system jest dla mnie tak ważny.

Gdy ekspert widzi nowe narzędzie, często od razu umie umieścić je na mapie. Wie, czy to alternatywa dla czegoś, co zna. Wie, czy problem jest realny, czy tylko dobrze opakowany marketingowo. Wie, gdzie mogą pojawić się koszty utrzymania, lock-in, ryzyka bezpieczeństwa albo zwykły overengineering.

Ja tego doświadczenia nie mogę udawać. Mogę natomiast zbudować system, który pomaga mi je stopniowo zdobywać.

Kiedy trafiam na nowe pojęcie, framework albo usługę, nie chcę, żeby asystent tłumaczył mi je z powietrza na podstawie generycznego web searcha. Chcę, żeby dodał je do mojej wiki w oparciu o źródła, które już zebrałem i zsyntetyzowałem. Chcę, żeby porównał je z tym, co już mam w grafie. Chcę, żeby pokazał mi różnice, napięcia i decyzje w języku zrozumiałym dla mojego profilu: architekta, który uczy się agentic engineeringu przez budowanie.

To zmienia sposób robienia notatek.

Zwykła notatka odpowiada na pytanie: „co było w materiale?”. Dobra notatka dla asystenta AI musi odpowiadać też na inne pytania: kiedy tego używać, z czym to się łączy, jakie decyzje z tego wynikają, gdzie są ryzyka i czego nie robić automatycznie.

To nie jest kosmetyczna różnica w sposobie prowadzenia vaulta. To zmienia notatkę z zapisu treści w element środowiska decyzyjnego.

Przykładowa notatka.

Tak wygląda pojedynczy element tej pamięci. Daytona nie jest tu tylko hasłem „sandbox do uruchamiania kodu”. Jest narzędziem osadzonym w grafie: ma aliasy, kategorię, powiązane pojęcia, miejsce w materiale kursu i źródła, do których agent może wrócić.

Dla człowieka to porządek. Dla asystenta AI to mapa kontekstu.

Widać to szczególnie przy wyborze narzędzi.

Coraz częściej agent nie tylko pomaga pisać kod, ale też podpowiada, jakiego stacku użyć. Wybiera bazę danych, framework, bibliotekę do UI, system kolejek, platformę deploymentu albo sposób obsługi autoryzacji. Czasem robi to dobrze. Czasem robi to w oparciu o popularność w danych treningowych. Czasem myli status narzędzia, rekomenduje rozwiązanie przestarzałe albo buduje od zera coś, czego rozsądny inżynier nie powinien budować samodzielnie.

To nie jest drobny problem. Jeśli agent wybiera narzędzie, to w praktyce wybiera też kierunek architektury. A jeśli nie zna moich kryteriów, to decyzja będzie poprawna tylko statystycznie.

Właśnie tutaj graf wiedzy zaczyna mieć sens.

Nie chodzi o to, żeby asystent miał dostęp do większej liczby definicji. Chodzi o to, żeby miał dostęp do relacji między definicjami. Jeśli dodaję do wiki nowe narzędzie, nie chcę zapisać tylko „co to jest”. Chcę zapisać, do jakich problemów pasuje, z czym konkuruje, jakie ma koszty, jakie niesie ryzyka, kiedy jest overengineeringiem i w jakich typach projektów może być domyślnym wyborem.

Wtedy nowe pojęcie nie jest luźną notatką. Staje się częścią mojego stacku decyzyjnego.

Konkretny przykład: trafiam na tekst Petera Panga o AI-first engineeringu.

Najpłytsze użycie AI polegałoby na tym, że proszę asystenta o streszczenie wątku. Dostałbym listę narzędzi, kilka haseł o CI/CD, observability, ewaluacji, bramkach jakości i uprawnieniach. Poprawne, ale mało użyteczne.

Dużo ciekawsze jest coś innego.

Proszę agenta, żeby potraktował tekst jako zewnętrzną tezę i porównał ją z wiedzą, którą mam już zapisaną w AI-Devs-4 oraz Brain-Vault. Nie pytam tylko: „co autor napisał?”. Pytam: jaka jest esencja tekstu, które pojęcia z mojego grafu pomagają mi go zrozumieć, czego brakuje i co warto dopisać.

Przykładowa wymiana z asystentem OpenClaw na Telegramie.

To jest moment, w którym nowa wiedza z internetu zaczyna pracować.

Agent nie zastępuje mojego myślenia. Pomaga mi szybciej zobaczyć strukturę problemu: esencję tekstu, pojęcia znane z kursu, braki w mojej wiki i jedną lekcję, którą warto przenieść do własnego systemu pracy.

Wtedy agent nie jest streszczaczem artykułów.

Jest sparingpartnerem, który korzysta z grafu jako kontekstu do zrozumienia nowej treści.

Bez vaulta dostałbym streszczenie. Z vaultem dostaję porównanie.

I to jest dużo bliższe temu, co chcę osiągnąć. Każdy nowy artykuł, narzędzie albo pojęcie może zostać dodane do systemu nie jako luźny link, ale jako element mapy: co mówi, z czym się zgadza, z czym się kłóci, jakie decyzje zmienia i co warto pogłębić w mojej wiedzy.

Drugi przykład to observability.

Przed kursem znałem to słowo raczej ogólnie. Wiedziałem, że systemy powinny mieć logi, monitoring i możliwość debugowania. Ale dopiero pracując z materiałem AI-Devs-4 zacząłem lepiej rozumieć, że przy agentach observability nie jest dodatkiem technicznym. Jest warunkiem sensownej autonomii.

Jeśli agent podejmuje decyzje, wywołuje narzędzia i działa w kilku krokach, to samo „zadziałało / nie zadziałało” przestaje wystarczać. Trzeba widzieć, co agent zobaczył, jaką decyzję podjął, jakiego narzędzia użył, jaki był wynik, gdzie pojawił się błąd i czy ten błąd wynikał z promptu, danych, narzędzia, uprawnień czy samego modelu.

I teraz najważniejsze: ta wiedza nie została u mnie tylko w głowie.

Trafiła do vaulta jako pojęcia, przykłady, połączenia i kryteria projektowe. Dzięki temu, kiedy planuję nowy system agentowy, nie muszę polegać wyłącznie na bazowej wiedzy asystenta. Mogę powiedzieć: przejdź przez mój graf dotyczący observability, evals i permissions, znajdź powiązane przykłady z kursu, a potem zaproponuj sposób monitorowania tego konkretnego workflow.

To zmienia jakość rozmowy z agentem.

Bez vaulta agent może dać poprawną, ale ogólną odpowiedź: „dodaj logi, tracing, metryki i dashboard”. Z vaultem może odwołać się do materiału, który już przerobiłem, i zapytać o rzeczy bliższe realnemu projektowaniu: które decyzje agenta trzeba logować, gdzie potrzebny jest trace wykonania, jakie akcje wymagają potwierdzenia, jakie błędy powinny trafić do ewaluacji i co powinno być widoczne, zanim zwiększę agentowi poziom autonomii.

To nadal jest wiedza merytoryczna, której się uczę. Różnica polega na tym, że uczę się jej w formie, która później może pracować razem ze mną. Notatka zapisuje pojęcie. Graf pozwala agentowi użyć tego pojęcia w decyzji projektowej.

I jeśli pojawi się nowe narzędzie do observability, nowy framework evalowy albo nowy sposób śledzenia pracy agentów, mogę dodać go do tej samej wiki. Nie jako luźny link. Jako kolejny element mapy: do czego służy, z czym się łączy, kiedy ma sens, jakie problemy rozwiązuje i jak wypada wobec standardów, które już wyciągnąłem z kursu.

W tym sensie vault nie jest miejscem, w którym odkładam wiedzę „na później”.

On jest sposobem, w jaki ta wiedza zmienia mój przyszły sposób pracy.

To jest dla mnie najciekawsza konsekwencja całego eksperymentu. Kiedy notatki są pisane tylko dla człowieka, naturalnie skracamy je do haseł, cytatów i przypomnień. Wystarczy, że po kilku miesiącach sam zrozumiem, o co mi chodziło. Ale kiedy zakładam, że z tych notatek będzie korzystał też agent, muszę pisać inaczej. Muszę dopisywać kontekst, relacje, powody, ograniczenia i przykłady użycia.

Nie dlatego, że agent jest głupi.

Dlatego, że agent nie był ze mną w momencie nauki.

Nie wie, które zdanie było dla mnie przełomowe. Nie wie, który przykład zmienił moje rozumienie problemu. Nie wie, że dane pojęcie połączyło mi się z konkretnym projektem, decyzją albo ryzykiem. Jeśli tego nie zapiszę, zostanie tylko tekst. Jeśli to zapiszę i połączę, powstaje pamięć.

To jest inny sposób myślenia o notatkach.

Notatka nie jest już końcem procesu uczenia się. Jest interfejsem między tym, czego się nauczyłem, a tym, jak będę później podejmował decyzje z pomocą AI.

Dlatego coraz bardziej myślę, że w pracy z agentami AI samo „zarządzanie wiedzą” to za mało. Nie chodzi tylko o to, żeby coś znaleźć. Chodzi o to, żeby przyszły agent mógł wejść w kontekst moich decyzji bez zaczynania od zera.

To wymaga innego typu materiału niż zwykłe streszczenia.

Potrzebne są notatki, które mówią:

• co to jest,
• kiedy tego używać,
• z czym to porównać,
• jakie są ryzyka,
• jakie decyzje z tego wynikają,
• gdzie są przykłady,
• kiedy człowiek powinien wrócić do pętli.

Dla mnie AI-Devs-4 było świetnym materiałem do takiego eksperymentu, bo kurs nie dawał tylko luźnych pojęć. Dawał problemy, narzędzia, przykłady i sytuacje, w których trzeba było coś zaprojektować albo uruchomić. To był dokładnie ten typ materiału, który można przerobić na pamięć decyzyjną.

Nie tylko dla mnie.

Także dla każdego asystenta, który później dostanie dostęp do tego grafu.

Na koniec chcę też podziękować Adamowi Gospodarczykowi za przygotowanie merytorycznej części AI-Devs-4. To był dla mnie nie tylko kurs, ale bardzo dobry materiał wyjściowy do dalszego samodzielnego rozwoju, budowy własnych standardów pracy z agentami i projektowania narzędzi AI.