Maksymilian

AI Engineer | Pomagam wdrażać AI do polskich firm | Propagator myślenia :)

[Maksymilian @MAXIMISEART]

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.

[Maksymilian @MAXIMISEART]

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

[Maksymilian @MAXIMISEART]

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.

[Maksymilian @MAXIMISEART]

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.

[Maksymilian @MAXIMISEART]

@smaczny classic

[Maksymilian @MAXIMISEART]

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. https://t.co/8W70fRf6Fq

2. https://t.co/XckGGCNzJ7

Link do materiału w załączniku: https://t.co/hJ9QMOr21H

[Maksymilian @MAXIMISEART]

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.

[Maksymilian @MAXIMISEART]

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.

[Maksymilian @MAXIMISEART]

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ł: https://t.co/UcOwrMWEer

[Maksymilian @MAXIMISEART]

"Nie potrzebujemy geniusza do pisania maili."

[Maksymilian @MAXIMISEART]

https://t.co/G9JaXfeI1s

[Maksymilian @MAXIMISEART]

https://t.co/G9JaXfeI1s

[dex @dexhorthy]

Absolute banger

[Maksymilian @MAXIMISEART]

Czy podstawy software engineeringu mają jeszcze jakieś znaczenie?

Czy zawód programisty właściwie już umarł? Czy powinniśmy mieć w dupie kod i skupiać się wyłącznie na rezultatach generowanych przez AI, traktując je jak czarną skrzynkę? Czy powinniśmy trząść portkami na widok tego, co nas czeka?

Nie.

Wydaje mi się, że my jako ludzie mamy trochę wspólnego z agentami, których tak maltretujemy. W większości przypadków człowiek osiąga różne wyniki w zależności od środowiska, w którym się znajduje.

Niektórzy pracują znacznie efektywniej, gdy mają uporządkowane stanowisko, nic im nie zawadza i nic ich nie rozprasza. Inni przywiązują wagę do odpowiedniego oświetlenia, muszą mieć swój fancy aromatyzer i kubek ulubionej kawy obok siebie. Każdy ma swoje preferencje.

Z agentami jest podobnie. Tylko że u nich całym środowiskiem jest kod. To oznacza, że jakość tego środowiska bezpośrednio wpływa na jakość ich pracy. Wnioski nasuwają się więc same - kiepski, chaotyczny codebase będzie zapewniał równie kiepskie rezultaty. Co gorsza, taki stan nie pojawia się nagle tylko narasta stopniowo.

Istnieje takie pojęcie jak entropia oprogramowania. Jeżeli świadomie nie dbasz o strukturę swojego projektu, nie myślisz strategicznie i w longtermie oraz nie stosujesz podstaw software engineeringu, kod z czasem staje się coraz bardziej chaotyczny, trudniejszy w utrzymaniu i rozwijaniu, czyli po prostu staje się slopem.

Co najważniejsze, z tego, co dzisiaj obserwujemy podczas pracy z AI, ludzie radzą sobie w takim środowisku znacznie lepiej niż LLM-y.

Głównie dlatego, że człowiek ma pamięć. Potrafi zapamiętać, co w danym projekcie działa, a co nie. Oczywiście nie jest to system idealny, ale pozwala z czasem wyrobić sobie intuicję dotyczącą tego, jak wygląda słaby codebase, i wiedzieć, czego unikać w przyszłości. Prowizoryczne systemy pamięci dokładane do agentów nie są rozwiązaniem tego problemu (jeszcze).

Jeżeli oglądaliście film „Memento”, można zauważyć tutaj ciekawą analogię. Agent „budzi się” w projekcie i nie pamięta nic. Za każdym razem musi nauczyć się wszystkiego od nowa. W efekcie AI może popełniać te same błędy w kółko, jeśli nie zapewnisz mu odpowiednich ograniczeń, wskazówek i struktury. Dotyczy to praktycznie wszystkich modeli od tych słabszych po te najlepsze.

Sednem problemu nie jest wcale sama zdolność rozumowania modelu. Problem polega na tym, że codebase'y są trudne do eksploracji, modyfikacji i zrozumienia, a to czyni je wymagającym środowiskiem dla AI.

Dlatego uważam, że dzisiaj największą wartość mają osoby, które potrafią tworzyć dobre środowiska pracy dla agentów. Takie, w których czytanie kodu jest łatwe, testy są sensownie napisane i dobrze pokrywają kluczowe scenariusze, a moduły oraz interfejsy zostały zaprojektowane w przemyślany sposób.

Więc podstawy software engineeringu nie tylko nie straciły na wartości, ale są dziś ważniejsze niż kiedykolwiek wcześniej. Jakość codebase'u bezpośrednio przekłada się na jakość pracy AI.

[Maksymilian @MAXIMISEART]

PRO TIP: Wiele harnessów, a zwłaszcza Claude Code, jest domyślnie przeładowanych treścią w swoim system prompcie. W praktyce oznacza to, że tysiące tokenów, z których większość i tak nigdy nie jest wykorzystywana, trafiają do context window na początku każdej sesji.

W wielu przypadkach nie potrzebujemy fragmentów związanych z workflow, planowaniem czy synchronizacją z monitoringiem, ponieważ zwyczajnie z nich nie korzystamy.

Na szczęście Claude pozwala to wszystko dostosować. W pliku ~/.claude/settings.json możemy wyłączyć zbędne elementy i w ten sposób znacząco odchudzić nasz system prompt. Jeżeli ktoś nie korzysta np. z wbudowanego narzędzia "AskUserQuestion", może je bezpiecznie wyłączyć. To samo dotyczy narzędzi do planowania cron tasków, wbudowanych mechanizmów code review, dynamicznych workflowów, zdalnego sterowania czy funkcji artifacts. Wszystkie te elementy zwiększają liczbę tokenów, a jeżeli nie są używane, nie wnoszą żadnej realnej wartości.

Efekt takiego odchudzania może być bardzo odczuwalny. Zredukowanie początkowego kontekstu z kilkudziesięciu tysięcy tokenów do zaledwie kilku tysięcy powinno znacząco poprawić experience z pracy z agentem, a przede wszystkim wydłużyć czas jego pracy w smart zone.

Im mniej, tym lepiej (dlatego Pi jest tak popularne). Agent ma mniej zbędnych rzeczy, które mogłyby go rozpraszać, dzięki czemu może skupić się na tym, co naprawdę ma znaczenie.

[Maksymilian @MAXIMISEART]

Kluczowe zasady context engineeringu przy budowie swoich agentów.

[Maksymilian @MAXIMISEART]

Context Engineering – rzeczy do zapamiętania:

- Danie agentowi dostępu do komputera (file system, shell): To krok, który bardzo ułatwia i tak już trudne zarządzanie kontekstem.

- Bezpieczny sandbox: Jak już agent ma dostęp do komputera, musi operować w jakimś sandboxie, tak aby było to bezpieczne.

- Używanie małej ilości narzędzi: Dawanie agentowi szerokich, atomowych narzędzi (np. glob, grep, read, write, ls) świetnie działa, ponieważ dajemy mu computer use, dzięki któremu może offload'ować akcje. Narzędzia mogą zajmować dużo miejsca, jeśli chodzi o kontekst – przykładowo GitHub MCP ma w sobie 32k tokenów w 32 narzędziach. Poza tym, im więcej narzędzi agent ma pod sobą, tym bardziej narażamy się na context confusion.

- Progressive disclosure narzędzi: Zamiast dawać wszystkie narzędzia bezpośrednio do okna kontekstu, lepiej używać ich on demand za pomocą Tool Search Tool. Można też zastosować podobne podejście: zaindeksować opisy narzędzi, a później robić semantic search, żeby zfetchować poprawne narzędzie do danego zadania.

- Pushowanie akcji do komputera: Pushowanie samego opisu narzędzi do file systemu to jedna rzecz, ale drugą – znacznie ciekawszą – jest pushowanie akcji narzędzia do komputera. To jest właśnie mocna strona dawania agentowi computer use: nawet z niedużą liczbą narzędzi agent może zrobić bardzo dużo.

- Sprytniejsze zarządzanie MCP servers: Zamiast dawać je bezpośrednio dla LLM, możemy zrobić coś sprytniejszego: wrzucić poszczególne narzędzia do file systemu (jako pojedyncze pliki), a potem robić zwykły file search (np. glob, grep czy indeksowanie).

- CLI dla MCP: Jeszcze inną metodą jest po prostu zbudowanie CLI dla MCP.

- Skille jako SOPs: Traktowanie skilli jako SOPs (Standard Operating Procedures) dla agenta do robienia różnych rzeczy w komputerze – np. używanie poszczególnych CLI czy pisanie kodu dla danego zadania.

- Offload'owanie rezultatów narzędzi do file systemu: Dawanie agentowi tylko pointerów lub summary od danego narzędzia, a jeżeli chciałby przeczytać cały plik może go zawsze zfetchować z file systemu. Wyniki narzędzi mogą być bardzo ciężkie tokenowo. Bez tego mechanizmu mogą zostać wrzucone w historię czatu, akumulować się z czasem i być wysyłane przy każdej turze (czego przecież nie chcemy).

- Scratchpad concept: Kolejne, bardzo podobne rozwiązanie, to offload'owanie planów jako scratchpad.

- Cache'owanie kontekstu (KV cache): Bardzo ważne, jeśli chodzi o produkcję. To ogromny lewar pod kątem szybkości i kosztów.

- Izolacja kontekstu poprzez subagentów: Subagenci nie są po to, żeby mieli swoje osobne role i nagle zajmowały się kompletnie innym zadaniem, tylko po to, żeby zwiększyć okno kontekstu swojego „rodzica”. Klasycznym przykładem izolowania kontekstu w ten sposób jest deep research.

- Loops dla long-running agentów: Tutaj można by się długo rozpisywać, ale podstawowym przykładem jest posiadanie planu w formie pliku (gdzie znajdują się todo tasks), file systemu oraz pliku progress.md jako scratchpad. Gdy odpalamy nasz loop:

1. Pierwszy agent zaczyna pracę nad jednym punktem z planu.
2. Kiedy kończy pracę, commituje wszystko do file systemu, a na koniec aktualizuje nasz plik progress.md (jeden agent = jedno okno kontekstu).
3. Następnie spawn'owany jest drugi agent, który czyta historię Gia oraz progress.md, robi refleksję nad planem, a potem bierze się za swoje zadanie.
4. Proces powtarza się w kółko, aż cały plan zostanie wykonany.

- Reflektowanie agenta na podstawie przeszłych sesji: Pisałem o tym więcej w osobnym poście tutaj: https://t.co/zkT8np8cE9

To są według mnie najważniejsze rzeczy, o których trzeba myśleć, jeżeli mówimy o context engineeringu.

Jeżeli ktoś chciałby coś dodać, to śmiało chętnie poczytam

[Maksymilian @MAXIMISEART]

@igorzakrzewski Jasne, zgadzam się!

[Maksymilian @MAXIMISEART]

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.

[Maksymilian @MAXIMISEART]

Tak, zgadzam się i rozumiem. Sprzedaje się rozwiązanie problemu, a nie sam produkt. Tak jak nie sprzedaje się lotu, tylko wakacje.

Powtarzając jednak założenie, na którym bazuje ta teza: jeżeli rozwiązaniem problemu jest nasz produkt, a produkt zależy od kodu, to ten kod musi być dobry. Nie mówie ze będzie i musi być we wszystkim idealny, ale nie może być slopem.

To, że przed erą AI również było dużo slopu, nie jest wymówką, żeby teraz tworzyć go jeszcze więcej i jeszcze szybciej.

Jeżeli chodzi o programistów, którzy nie są wymiataczami, to jestem tego świadomy. Ale to również nie jest żadna wymówka. Wydaje mi się, że w naszym własnym interesie leży to, żeby stawać się coraz lepszymi i stale się rozwijać, a nie zadowalać się byciem średniakiem.

[Maksymilian @MAXIMISEART]

Nie zgadzam się ze stwierdzeniem, że kod staniał albo że jest najtańszy, odkąd istnieje. Uważam, że kod nigdy nie był droższy niż teraz.

Samo pisanie kodu rzeczywiście stało się tańsze, ale jego prawdziwa cena nie leży w procesie tworzenia. Leży w utrzymaniu, czytelności oraz w tym, jaki wpływ kod ma na działające w nim AI.

Wszyscy, którzy nadal myślą, że kod jest tani, tak naprawdę budują zwykły slop w swoich codebase'ach. Coraz bardziej odczuwalne jest to, że dobra architektura i dbanie o jakość nie są kosztem, tylko najtańszą inwestycją w tej nowej erze.

Lepszy kod = lepszy output.

[Maksymilian @MAXIMISEART]

Dużo firm i startupów tworzy wertykalnych agentów, co w praktyce jest niczym innym jak budowaniem harnessu pod wąskie zadanie w konkretnej domenie. Przykładem może być np. https://t.co/GiqYgLIqi7.

Istnieje również wiele frameworków, na których takie firmy budują swoje rozwiązania, np. LangChain/LangGraph czy deepagents. Kolejnym przykładem jest OpenClaw, który został zbudowany na PI.

Dobrym podejściem jest tzw. sandwich funnel:

harness engineering → finetuning → harness engineering.

Jeżeli chodzi o sam finetuning, to oczywiście trzeba wiedzieć, jak go przeprowadzić, ale nie należy on do najtrudniejszych zadań. Kluczowe jest dobranie odpowiedniej metody, np. LoRA, QLoRA itd.

Przykładem dobrze przeprowadzonego finetuningu jest artykuł od LangChaina: https://t.co/naQLWdbxSQ

[Maksymilian @MAXIMISEART]

https://t.co/FSIIbWehpa

[Maksymilian @MAXIMISEART]

@futurologiae Tak, o kontekście też trochę pisałem.

pozdro

[Maksymilian @MAXIMISEART]

1/6 Jak sprawić, by agenci AI byli naprawdę niezawodni i radzili sobie z trudnymi zadaniami w realnym świecie? Sam mocny model nie wystarczy. Wszystko rozbija się o architekturę, jaką wokół niego zbudujemy. Ostatnio głośno jest o pojęciu loop engineering i dlatego w tej nitce chcę prosto wytłumaczyć, o co w tym chodzi. Krótko mówiąc ta metoda polega na sprytnym układaniu w stosy konkretnych pętli operacyjnych. Dzięki temu zwykłe, statyczne modele LLM zamieniają się w samodzielne systemy, które potrafią dążyć do celu i same poprawiać własne działanie. Przejdźmy krok po kroku przez cztery poziomy takich struktur.

[Maksymilian @MAXIMISEART]

Założenie jest takie że fundamentem produktu jest kod, inaczej mówienie w ogóle o kodzie nie ma sensu. Jeżeli kod jest slopem i na nim opiera się produkt to produkt tez jest gównem i wtedy nie ma żadnej wartości biznesowej.

zły kod --> gówniany produkty --> zero wartości --> biznes umiera

Tak to widzę.