Maksymilian

10 lekcji z kodowania z AI 1. Wdrażaj, żeby się uczyć Można zajść całkiem daleko, stosując SDD (Spec-Driven Development), ale to dopiero pisanie kodu ujawnia decyzje, których na początku nie brałeś pod uwagę, i sprawia, że sama specyfikacja staje się lepsza. Skoro więc PISANIE kodu jest tanie, warto implementować po to, aby się uczyć. 2. Często buduj od nowa Aby zdobywać nowe doświadczenie, implementuj wcześnie i regularnie. Forkuj projekty i twórz nawet najbardziej szalone eksperymenty. Sprawdzaj, jak daleko można rozwinąć dany pomysł lub funkcjonalność. Oczywiście nie zapominaj o iterowaniu i rozwijaniu dotychczasowej pracy, ale skoro mamy dziś takie możliwości, eksperymentuj i odkrywaj nowe rozwiązania, o których wcześniej nawet nie myślałeś albo które były praktycznie niemożliwe do zrealizowania. 3. Inwestuj w testy Powinniśmy poświęcać więcej czasu na tworzenie testów, które sprawdzają, co produkt robi, a nie tylko jak to robi. Potrzebujemy możliwości swobodnego przebudowywania i ponownego implementowania aplikacji bez obawy o zmianę jej zachowania. 4. Dokumentuj intencje Testy opisują cele, kod odzwierciedla sposób realizacji, ale ani jedno, ani drugie nie odpowiada na pytanie, dlaczego podjęto daną decyzję. Intencja jest motywacją stojącą za architekturą i implementacją. Posiadanie jej obok kodu pomaga zarówno tobie, jak i agentowi konsekwentnie rozwijać projekt w tym samym kierunku. 5. Utrzymuj specyfikację świeżą Regularnie aktualizuj spec (pliki .md zawierające cele i plan projektu) wraz z rozwojem kodu i testów. Jeżeli specyfikacja staje się dokumentem statycznym i zamrożonym, cała wiedza zdobyta podczas implementacji idzie w błoto. Aktualna specyfikacja wspiera zarówno ciebie, jak i agentów w podejmowaniu trafnych decyzji oraz bardzo ułatwia częste przebudowy projektu (w przyszłości napiszę o tym więcej). 6. Szukaj rzeczy trudnych Pracując długo nad danym projektem, dojdziesz do momentu, w którym skończą ci się proste zadania. Po uporaniu się z oczywistymi problemami pozostaną wyzwania takie jak: intuicyjny UX, wydajność, bezpieczeństwo, odporność czy architektura. Dzisiaj te łatwe rzeczy jest w stanie zrobić prawie każdy. Prawdziwa wartość tkwi więc w rzeczach trudnych. Znajdź je i właśnie tam poświęć swój czas oraz energię. 7. Automatyzuj wszystko co łatwe Logicznie myśląc, jeżeli chcesz poświęcać więcej czasu na rzeczy trudne, musisz ograniczyć czas spędzany na prostych czynnościach. Zamieniaj zdobyte doświadczenie w gotowe skille i workflowy, buduj pętle, automatyzuj tę żmudną część code review i pozwól swoim narzędziom pracować za ciebie. Trzeba tylko uważać, żeby nie utknąć w środowisku pełnym automatyzacji, których działania sam przestajesz rozumieć. 8. Rozwijaj swój gust inżyniera W sytuacji, gdy kod powstaje błyskawicznie, a wartościowy feedback pojawia się znacznie później, jedynym źródłem informacji, które nadąża za tym tempem pracy, jest twój własny osąd. Im lepiej rozumiesz swoją domenę, użytkowników i ich problemy, tym dalej możesz dojść bez konieczności weryfikowania każdej decyzji. 9. Agenci wzmacniają doświadczenie Kodując z AI, często nie zdajemy sobie sprawy, ile intuicji przekazujemy swoim agentom już w samych promptach: właściwe słownictwo, odpowiedni kontekst czy odpowiedni poziom szczegółowości. Jeżeli dobrze znasz swój stack, możesz zaoszczędzić ogromną liczbę iteracji zarówno podczas implementacji, jak i debugowania, ograniczając jednocześnie eksplorowanie różnych rozwiązań przez agenta. 10. Utrzymanie, wsparcie i bezpieczeństwo kodu nie jest tanie Tak, pisanie kodu jest tanie. Jednak wszystko wokół niego, a często nawet ważniejsze od samego pisania, czyli wsparcie, utrzymanie i bezpieczeństwo, nadal wymagają czasu, pieniędzy i odpowiedzialności. Zawsze miej świadomość tych kosztów podczas budowania. Jeżeli macie jakieś swoje lekcje których tu nie wypisałem to chętnie je poznam i poczytam.

Bardzo ciekawe. Jeżeli chodzi o pamięć to są takie rozwiązania co znacznie ułatwiają życie w tym aspekcie. Gorzej już z tym pracowaniem przez tygodnie/miesiące. Modele to commodity i cały moat leży poza nim to prawda. Jeżeli chodzi o wiedze i ludzi którzy ja maja i się nią powszechnie dzielą to trochę ich jest, ale czasami ciężko znaleźć, na pewno trudniej tutaj niż za oceanem.

@MAXIMISEART Taki AI Operating System, a nie kolejny chatbot, jeszcze z rok nauki i może coś z tego wyjdzie 😅

Jakie macie problemy, używając, pracując czy też ucząc się z AI? Na jakie przeszkody natrafiacie? Co was powstrzymuje przed osiągnięciem swojego dream outcome? Czym on w ogóle jest? Gdybyście mogli magicznie usunąć lub rozwiązać jeden z tych problemów, co by to było? Nieważne, kim jesteś - devem, właścicielem firmy, osobą nietechniczną czy studentem. Każdy problem jest dla mnie ważny. Ja zacznę. Moim problemem jest to, że AI pokazało mi, że mogę robić więcej. Teraz robię wszystko, żeby robić jak najwięcej, a i tak nie wykorzystuję pełnego potencjału tego narzędzia (fajnie byłoby się sklonować). Drugi problem to cognitive debt. Robienie kilku rzeczy naraz i ciągłe przeskakiwanie z jednego kontekstu do drugiego w celu optymalizacji czasu i niemarnowania go może powodować słabsze zrozumienie tego, co się tworzy. Trzeci problem jest taki, że wszyscy dostaliśmy od AI pewnego rodzaju „awans” na wyższe stanowisko. Moja praca polega dziś głównie na ciągłym myśleniu, a znacznie mniej na fizycznym robieniu. To bardziej strategiczne i długodystansowe myślenie zamiast taktycznego, krótkowzrocznego działania, co z czasem po prostu męczy umysł. Zachęcam do podzielenia się swoimi.

@InfZakladowy "Programowanie jest przyjemne, przeglądy kodu już nie za bardzo. " To w naszej kwestii jest to żeby przegląd kodu był przyjemny, albo chociaż nie był nieprzyjemny. Wydaje mi się że ci bardziej sprytni już rozwiązali ten problem i nie jest to już ich przysłowiowe wąskie gardło.

To jest wątek o moich bieżących obserwacjach dotyczących AI i LLM-ów w programowaniu i o tym dokąd to wszystko zmierza. W dwóch słowach: nie wiem. W pięciu słowach: nie wiem, ale się wypowiem. A więc tak: LLM-y tu są i z nami zostaną, bo

@pojara666 Tak chętnie podzielę się swoją wiedzą, jeżeli chcesz możesz do mnie napisać, postaram się pomóc jak tylko umiem :)

@MAXIMISEART Czy pomagasz osobom nietechnicznym ale mającym jakieś tam podstawy wejść bardziej profesjonalnie w temat Ai? Interesuje mnie tak najbardziej pomoc w ustawieniu konkretnego setupu który pomógłby mi w stawianiu własnych projektów po godzinach

wiki wiki wiki!!! i to nie obsidian tylko coś level wyżej polecam :)

@mredlica Tak, człowiek nadal jest tu potrzebny (stety czy niestety)

@MAXIMISEART Co do pkt 4: Trzeba regularnie przeglądać pamięć, bo wnioski jakie agent potrafi wyciągnąć potrafią zrobić więcej bubu niż dobrego - w najlepszym wypadku zje więcej tokenów. Przykładem są wątki na reddit odnośnie Hermesa w stylu "dlaczego agent teraz je tyle tokenow" 😉

Od zera do AI Engineer #2 4 rodzaje pamięci potrzebne agentom AI Dobrze zaprojektowany agent nie polega tylko na kontekście rozmowy, ale też na trwałej wiedzy, umiejętnościach i doświadczeniach. To właśnie pamięć jest tym, co odróżnia zwykłego chatbota od prawdziwego agenta AI. Dobrą analogią jest pamięć ludzka, którą możemy podzielić na: 1. Pamięć krótkotrwałą. 2. Wiedzę faktograficzną (znanie faktów). 3. Nauczone umiejętności. 4. Osobiste doświadczenia. Wychodzi na to, że dobrze zaprojektowany agent też musi mieć te cztery typy pamięci. Dobrze pokazuje to framework CoALA (Cognitive Architectures for Language Agents), który podporządkowuje pamięć agentów czterem kategoriom: 1. Working memory To nic innego jak pamięć robocza, czyli bieżący kontekst, jaki ma agent: rozmowa, system prompty, wczytane pliki itd. Dosyć często porównuje się ją do pamięci RAM, ponieważ jest szybka i natychmiast dostępna, ale jednocześnie dosyć ulotna oraz ograniczona pojemnością. 2. Semantic memory Możemy to przetłumaczyć jako pamięć wiedzy, czyli: fakty, reguły, konwencje, dokumentacja i ogólna wiedza o projekcie. W praktyce są to najczęściej pliki Markdown w repo, które zawierają potrzebne informacje na temat architektury, konwencji kodowania oraz tego, co robić, a czego nie robić. 3. Procedural memory Opisuje, jak agent ma wykonywać zadania. Procedural memory stosujemy codziennie, używając SKILLI, czyli modułów z instrukcjami opisującymi, jak wykonać dane zadanie krok po kroku. Agent ładuje je dopiero wtedy, gdy są potrzebne. Wszystko po to, żeby nie zaśmiecać kontekstu i nie wrzucać wszystkiego naraz. 4. Episodic memory To pamięć doświadczeń z poprzednich interakcji, sesji i decyzji. Zamiast przechowywać pełne, ciężkie transkrypcje, sprytne systemy zapisują skondensowane i użyteczne wspomnienia, które będą pomocne w przyszłości. Dlaczego to niby ważne? Trzeba podkreślić, że nie każdy agent potrzebuje wszystkich czterech typów pamięci. Wszystko zależy od tego, jakie jest przeznaczenie naszego agenta. Prosty agent albo jakiś prototyp może działać tylko z working memory. Jakiś prostszy support bot może potrzebować jeszcze procedural memory. Natomiast bardziej złożony agent, np. do kodowania, będzie wykorzystywał wszystkie cztery typy pamięci. Do zapamiętania Pamięć w agentach to nie jedna rzecz, tylko zestaw warstw o różnych rolach: Working memory – co jest teraz? Semantic memory – co jest prawdą? Procedural memory – jak to zrobić? Episodic memory – czego się nauczyliśmy?

@spietrza Jasne zrobię, dzięki za pomysł!

@MAXIMISEART Dobre rozróżnienie. W produkcji dochodzi trzeci wymiar: MCP ładnie wygląda na demie, a potem walczysz z auth, latencją i wersjonowaniem tooli. Skills tańsze poznawczo, dopóki nie potrzebujesz stanu. Zrobisz #2 o tym, co się sypie na produkcji?

Od zera do AI Engineer #1 MCP vs SKILLS Czym są? Jak się różnią? Kiedy używać których? MCP MCP, albo inaczej Model Context Protocol, możemy przedstawić jako ustandaryzowaną warstwę między agentem a usługami zewnętrznymi, np. CRM, bazą danych itp. Często jest to tłumaczone jako USB-C dla agenta, dzięki któremu może on podłączać się do różnych narzędzi bez potrzeby tworzenia osobnych API dla każdego z nich. Zamiast podawać modelowi surowe API, dokumentację i tokeny, MCP abstrahuje to do formatu „LLM ready” oraz zajmuje się autoryzacją i tłumaczeniem JSON-owych zadań modelu na faktyczne wywołania HTTP (GET/POST). MCP rozwiązuje problem: jak dać modelowi dostęp do aktualnych danych w kontrolowany sposób. To, o czym trzeba pamiętać podczas korzystania z MCP, to fakt, że serwery MCP mogą być bardzo token heavy i obciążać nasze context window jeszcze przed wykonaniem jakiegokolwiek zadania. SKILLS Luką, której MCP nie rozwiązuje, jest to, że LLM nadal jest niedeterministyczny i trudno wymusić na nim identyczny format czy workflow za każdym razem. Skille są po to, żeby „spakować” właśnie takie powtarzalne zadanie w zdefiniowany plik Markdown z metadanymi (tytuł, opis, kiedy używać oraz treść promptu), umieszczony w folderze z dodatkowymi skryptami i zasobami. Dzięki tzw. progressive disclosure skille mogą być automatycznie ładowane do kontekstu tylko wtedy, gdy są potrzebne. Dzięki temu model wie, jak wykonać dane zadanie w sposób powtarzalny. Dodatkowym tipem jest to, że skille mogą być w ogóle niewidoczne dla agenta (zmniejszamy tym jeszcze bardziej liczbę początkowych tokenów). Wtedy to my, jako człowiek, musimy pamiętać, kiedy ich używać, a nie agent. Kiedy MCP, a kiedy SKILLS? Gdy potrzebujemy, żeby agent miał dostęp do danych real time i zewnętrznego świata przy ścisłym sterowaniu uprawnieniami, wybierz MCP. Gdy z kolei zależy nam na powtarzalnych zadaniach, workflowach i lepszym zarządzaniu kontekstem, wybierz SKILLE. Tutaj mały disclaimer dotyczący SKILLI. Jest jeszcze jedna rzecz – trzeba umieć je pisać, co również może sprawiać trudności. Pisanie skilli przez agenta nie jest rozwiązaniem tego problemu.

PRO TIP: Nie łap się na 1 milion tokenów kontekstu Dzisiejsze duże modele często mają okna kontekstu rzędu miliona tokenów. W praktyce jednak tylko niewielka część tego okna nadaje się do realnej pracy. Już rok temu Chroma opublikowała swoje badania na temat context rot – degradacji kontekstu podczas długiej rozmowy lub pracy modelu. Jest to sytuacja, w której model nadal widzi wszystkie poprzednie informacje, ale coraz gorzej potrafi wyłowić z nich to, co istotne. Im więcej tokenów znajduje się w oknie kontekstu, tym gorzej działa nasz agent. Dzieje się tak dlatego, że dodając każdy nowy token, model musi brać pod uwagę nie tylko ten konkretny token, ale też każdą relację pomiędzy nim a pozostałymi tokenami. Efektem są częstsze halucynacje, gorsze wyszukiwanie informacji i słabsze outputy. Praktycznym rozwiązaniem jest podzielenie context window na smart zone i dumb zone. W smart zone mamy do dyspozycji pełną inteligencję modelu, natomiast w dumb zone nasz agent zaczyna stopniowo głupieć. Ważne, żeby zaznaczyć, że nie jest to nagły spadek jakości, a raczej stopniowa degradacja. Jeżeli więc chcemy maksymalnie wykorzystać tokeny i inteligencję modelu, powinniśmy wykonywać nasze zadania wyłącznie w smart zone. Nie oznacza to jednak, że zadań, które nie wymagają wyjątkowo dużej inteligencji ze strony modelu, nie możemy wykonywać w dumb zone. Musimy jedynie mieć z tyłu głowy jej ograniczenia. W zależności od modelu oraz konkretnego zadania granica między smart zone i dumb zone może się różnić. Trzymałbym się jednak zakresu pomiędzy 120–150 tys. tokenów. Co zrobić, gdy już jesteś w dumb zone? -clear sesji, żeby wyczyścić cały kontekst, -compact sesji, żeby skompaktować kontekst, -przekaż zadanie do innego agenta w odrębnej sesji, -potraktuj to jako sygnał, że warto przebudować swoje workflow tak, aby nie wypełniało aż tak okna kontekstu. Tutaj krótki filmik tłumaczący czym jest dumb zone: youtube.com/shorts/sOd7svd…

@JacekPlaPlacek Tak mogą być, zgadzam się. Czesto są nawet lepszym rozwiązaniem

@MAXIMISEART Zamiast MCP mogą być też narzędzia CLI.

Większość dzisiejszego slopu to nasza wina. Ogólnie większość rzeczy, które dzieją się w naszym życiu, to nasza wina. Slop wynika z niedostatecznego doprecyzowania oraz z braku zrównania się „myśleniem” z AI. Bardzo często to człowiek tak naprawdę nie wie, co jest dobre, a co złe. Nie potrafi też tego jasno wyjaśnić. W takiej sytuacji AI nie robi nic innego, tylko wypełnia tę lukę, która powstała z naszej winy, najbardziej przeciętnymi założeniami i decyzjami. Więc osoby, które obwiniają AI za przeciętne rezultaty -to wasza wina (moja czasami też, nie jestem idealny). To, co powinniśmy robić, żeby tego uniknąć, to zatrzymać się na chwilę i zastanowić, co tak naprawdę dajemy temu AI i jak ono to widzi. Nie wiem, czy też to widzicie, ale jest dokładnie tak samo jak z ludźmi. Możemy mówić te same słowa, ale słyszeć coś zupełnie innego.

@smaczny classic

wrocilem troche do dzialania jako freelancer i ilosc stron ktora ktos zrobil/dostal od kogos z ai slop designem mnie przeraza💀 rzeczy o ktorych mowie usuwa pierwszy lepszy skill i to po prostu byl opus puszczony z promptem zrob mi strone pizzeri no mistakes💀

PRO TIP: Nie, nie używaj nigdy komendy /init. Nigdy też nie generuj automatycznie swojego CLAUDE.md . (załączony filmik jest dla kontekstu czemu o tym w ogóle pisze, link do niego na końcu tweeta). Nie wiem, z czego wynika to polecenie tego Pana i dlaczego uważa, że akurat takie podejście jest jakkolwiek dobre. Wygenerowany CLAUDE.md przy użyciu komendy /init, albo jakkolwiek automatycznie wygenerowany, ma kilka problemów: - marnuje tokeny i budżet przeznaczony na instrukcje, - szybko się dezaktualizuje i zaczyna wprowadzać twojego agenta w błąd, - duża część tej treści jest po prostu zbędna albo może zostać bardzo łatwo odnaleziona bezpośrednio w kodzie. Wspólnym mianownikiem jest to, że te treści są albo trywialnie odkrywalne z kodu, albo bardzo szybko się dezaktualizują. Źródłem prawdy o architekturze powinien pozostać sam filesystem i kod, a nie jakieś statyczne streszczenie w Markdownie. Twój agent i tak przechodzi fazę eksploracji, w której, zanim cokolwiek zmieni, czyta pliki, przeszukuje bazę kodu i buduje swój kontekst na bieżąco pod dane zadanie. Żeby sterować zachowaniem swojego agenta, lepszym sposobem jest używanie skilli, które są niczym innym jak instrukcjami, po które agent może sięgnąć wtedy, gdy są potrzebne, zamiast obciążać nimi każdą sesję. Zgadzam się z tym Panem w tym, co mówi pod koniec – CLAUDE.md nie powinien być zbyt duży i powinny znaleźć się w nim wyłącznie rzeczy uniwersalne. Dlatego nie rozumiem, dlaczego proponuje rozwiązanie tego problemu komendą /init, która stoi z tym podejściem w sprzeczności. Twój CLAUDE.md powinien być prawie pusty i zawierać tylko to, czego nie da się wykryć z poziomu kodu, a co jednocześnie jest istotne globalnie. I przede wszystkim powinieneś go pisać TY - ręcznie. Jeżeli ktoś chciałby poczytać o tym więcej, to polecam dwa artykuły: 1. aihero.dev/never-run-clau… 2. humanlayer.com/blog/writing-a… Link do materiału w załączniku: @devsteer_/video/7657133923784264992?is_from_webapp=1&sender_device=pc&web_id=7663528441736545814" target="_blank" rel="nofollow noopener">tiktok.com/@devsteer_/vid…

To co łączy te frameworki które wypisałem to to że są one model agnostic i są level wyżej niż CC/Codex w headless. Ale tak, jeżeli chcemy to też możemy ich używać do agent-first, pipeline-owych use caseów nadają się świetnie. To też trzeba zaznaczyć że np. claude -p jest czymś innym niż sam LangGraph. Gdzie -p używamy do wywołania samego modelu, a LangGrapha jako bibliotekę której używamy do orkiestracji całego systemu, w którym -p jest tylko jakimś składnikiem.

@MAXIMISEART Nie umieściłeś w tym zestawieniu Claude Code / Codex w trybie headless. Uważasz że nie nadają się, czy nie jest to ta sama kategoria, co CrewAI / AutoGen / BabyAGI?

Czym jest agentic AI framework? Jaki wybrać? I po co one w ogóle istnieją? Możemy sobie to wyobrazić jako zestaw gotowych klocków, z których budujemy bardziej skomplikowane systemy, które planują, wykonują określone działania i iterują aż do momentu osiągnięcia celu. Nie są tylko statycznymi chatbotami. Frameworki te pomagają również w integracji, monitoringu, zarządzaniu zadaniami oraz komunikacji między agentami. Podzielmy sobie te frameworki na 5 typów systemów: 1. Liniowe workflow – systemy, gdzie akcja dzieje się krok po kroku, kolejne etapy zachodzą w ustalonej kolejności i są zależne od siebie. 2. Autonomiczne systemy agentowe – systemy, w których kilka agentów samodzielnie współpracuje, żeby osiągnąć postawiony cel. 3. Systemy na bazie roli – systemy wieloagentowe, gdzie mamy jasno przypisane role, np. agent od deep researchu, agent od pisania, kolejny od edytowania itd. 4. Orkiestracja w produkcji – systemy do wdrożeń produkcyjnych, mocno zintegrowane z API, bazami danych oraz procesami biznesowymi. 5. Prototypowanie – systemy do szybkiego testowania pomysłów i budowania prototypów, bez potrzeby pełnej architektury. W praktyce wybór danego frameworka powinien raczej wynikać z architektury problemu niż z samej popularności danego narzędzia. Jeśli więc potrzebujesz stabilności i kontroli, skorzystaj z prostych liniowych workflow. Jeśli natomiast potrzebujesz większej eksploracji i współpracy między kilkoma agentami, wybierz architekturę multi-agent. Tak samo ma się to z etapem danego projektu – czy jesteśmy na poziomie wchodzenia na produkcję, czy też dopiero sprawdzamy nasze pomysły. Tutaj wypiszę przykładowe narzędzia do danego typu systemu: 1. Liniowe workflow: LangChain, LlamaIndex, LangGraph. 2. Autonomiczne systemy agentowe: AutoGen, CrewAI, BabyAGI. 3. Systemy na bazie roli: CrewAI, AutoGen, ChatDev. 4. Orkiestracja w produkcji: LangGraph, Deep Agents, Eve. 5. Prototypowanie: LangFlow, Flowise. Wydaje mi się, że takie podejście jest szczególnie ważne w projektach AI, ponieważ pozwala nam uniknąć budowania zbyt skomplikowanych rozwiązań na samym początku. Dobrze dobrany framework nie tylko przyspiesza pracę, ale też zmniejsza ryzyko, że cały system stanie się trudny do utrzymania.

PRO TIP: Pisz lepsze claude/agent.md Ten plik .md służy do tego, żeby wprowadzić agenta w twój codebase na początku każdej sesji. Żeby to uprościć, claude/agent.md powinien opisywać trzy rzeczy: CO, DLACZEGO, JAK. CO Pokaż swojemu agentowi, z jakiej technologii korzystamy, jaki mamy stack i jaka jest struktura naszego projektu. Powinniśmy dać mu mapę naszego repo. Wyjaśnić, co jest czym i gdzie ma tego szukać. DLACZEGO Twój agent nie powinien rozumieć tylko tego, co jest w kodzie, ale też po co to istnieje. Opisz cel projektu oraz funkcje poszczególnych repo. JAK Naucz agenta, jak ma pracować z projektem. Jeśli używasz X zamiast Y albo masz konkretne komendy do testów, to właśnie tutaj powinno się to znaleźć. Tutaj powinno być wszystko, co jest potrzebne, aby agent mógł sensownie działać w twoim środowisku. Mniej znaczy lepiej Upychanie każdej możliwej komendy i reguły jest bez sensu. Ten plik działa o wiele lepiej, gdy zawiera możliwie mało informacji, ale za to są to rzeczy uniwersalne i przydatne w każdej nowej sesji. Progressive disclosure Lepiej rozdzielić wiedzę na osobne pliki z opisowymi nazwami. Plik powinien wskazywać, gdzie agent ma szukać szczegółów, zamiast zawierać je wszystkie od razu w claude/agent.md. To znacznie ogranicza rozmiar kontekstu i sprawia, że plik pozostaje użyteczny także wtedy, gdy projekt rośnie. Odwołanie do źródeł Lepszym sposobem od wklejania fragmentów kodu do dokumentacji jest odsyłanie do konkretnego miejsca w repo. Dzięki temu dokument nie starzeje się aż tak szybko. Jeżeli ktoś by chciał bardziej się zagłębić to polecam ten artykuł: humanlayer.dev/blog/writing-a…

"Nie potrzebujemy geniusza do pisania maili."