Zadaj dużemu modelowi językowemu pytanie, a dostaniesz odpowiedź. Zadaj to samo pytanie za tydzień, a otrzymasz mniej więcej to samo — nie lepiej, nie gorzej. Model nie pamięta zeszłego tygodnia, nie wie, że kod bazowy poszedł od tego czasu do przodu, i nie ma żadnego mechanizmu, by zauważyć, że rada, której właśnie udzielił, przeczy decyzji podjętej przez zespół trzy commity temu. To cichy sufit, o który uderza większość zespołów pracujących z AI: agenci są przydatni danego dnia, ale w twojej pracy tak naprawdę nigdy nie stają się lepsi.

Z tego plateau jest wyjście i nie wymaga ono większego modelu. Wymaga dania agentom czegoś, czego zwykle nie mają — nocnej zmiany. Ten artykuł opisuje podejście, które utrzymujemy na produkcji: zespół wyspecjalizowanych agentów, którzy według harmonogramu i najczęściej wtedy, gdy nikt nie patrzy, na nowo czytają własne instrukcje, studiują kod, za który odpowiadają, wydobywają na wierzch znaleziony dług i możliwości oraz proponują ulepszenia samym sobie — do zatwierdzenia przez człowieka. Skąd wzięła się ta idea, jak działa główna pętla, jak nie zamienić tego w kosztowny bałagan i dlaczego zyski się kumulują.

Agenci, którzy nie stają się lepsi

Domyślny sposób korzystania z LLM jest bezstanowy i reaktywny. Wchodzi prompt, wychodzi odpowiedź, kontekst zostaje wyrzucony. Dla jednorazowego zadania to w porządku, ale ma trzy strukturalne problemy w chwili, gdy próbujesz uczynić agenta trwałą częścią zespołu.

Gnicie kontekstu. Agent jest tak dobry, jak dobry jest dany mu kontekst. Kod bazowy zmienia się codziennie; instrukcje — prawie nigdy. W ciągu kilku tygodni obraz świata agenta po cichu się dezaktualizuje: odwołuje się do przemianowanego modułu, do porzuconej konwencji, do serwisu, którego już nie ma.

Dryf instrukcji. Kiedy instrukcje agenta jednak utrzymujesz ręcznie, dryfują w drugą stronę: gromadzą reguły dla sytuacji, które już nie zachodzą, przeczą sobie nawzajem i obrastają długim ogonem wskazówek, których nikt nie czytał od miesięcy. Za zauważanie tego nikt nie odpowiada.

Nic się nie kumuluje. Najbardziej przygnębiające: nic się nie odkłada. Każda sesja startuje od zera. Kolega z zespołu, który w zeszłym miesiącu przeglądał twój moduł płatności, wnosi ten kontekst w nowy miesiąc; bezstanowy agent za każdym razem wyprowadza go od nowa — i to źle. Wychodzi genialny stażysta z całkowitą amnezją — a amnezji nie leczy żadna inżynieria promptów.

Lekarstwem nie jest mądrzejszy model. To praktyka: powtarzalna, zaplanowana rutyna, która zamienia jednorazowe odpowiedzi w rosnący zasób wiedzy.

Daj zespołowi nocną zmianę

Sama idea jest prosta do wypowiedzenia: niech agenci pracują, kiedy ty nie pracujesz — nie nad kodem produkcyjnym, lecz nad własnym jego rozumieniem. Każdej nocy harmonogram kolejno budzi kilku agentów. Każdy na nowo czyta opis własnej roli, wyrywkowo ogląda tę część kodu, za którą odpowiada, i zapisuje, co zrozumiał: na co uważać, co wygląda źle, o co zapytałby, zanim czegokolwiek dotknie. Co istotne, zaznacza też, gdzie jego własne instrukcje przestały odpowiadać rzeczywistości, i szkicuje proponowaną poprawkę. Nad ranem masz stos krótkich, konkretnych notatek i garść zaproponowanych samo-ulepszeń czekających na przegląd.

Nazywamy to śnieniem (dreaming) i to nie tylko marketing — nazwa wskazuje wprost, skąd wzięła się idea.

Zespół wyspecjalizowanych agentów żyje obok kodu jako zwykłe pliki. Harmonogram budzi ich według grafiku; każdy studiuje kod, zapisuje artefakty z powrotem do repozytorium, a człowiek przegląda i stosuje to, co zatwierdzone.

Skąd wzięła się ta idea

Spostrzeżenie, że inteligencja poprawia się offline — w czasie przestoju, bez nowego wejścia ze świata — jest stare i nadchodzi naraz z kilku stron.

Z neuronauki. Mózg nie uczy się tylko na jawie. Podczas snu odtwarza doświadczenie minionego dnia, konsoliduje to, co ważne, w pamięci długotrwałej, a resztę przycina. Uczenie się to nie tylko pozyskiwanie, lecz konsolidacja — a konsolidacja zachodzi, gdy system jest „offline”.

Z uczenia ze wzmocnieniem. Ta sama zasada występuje jako powtórka doświadczeń (experience replay): agent przechowuje swoje doświadczenia i uczy się z nich później, offline, oddzielnie od działania. Cała linia agentów „z modelem świata” idzie dalej — uczą się skompresowanego modelu środowiska, a potem doskonalą się, „wyobrażając sobie” przebiegi w jego wnętrzu: dosłownie uczą się ze snów, a nie ze świeżej interakcji.

Z agentów na LLM. Najbardziej użyteczny świeży wątek to autorefleksja: agenci, którzy krytykują własne wyjście, prowadzą bieżącą pamięć tego, co zadziałało, i wprowadzają te refleksje do kolejnej próby. Pokrewne prace dają długo żyjącym agentom strumień pamięci, który okresowo zwijają w refleksje wyższego poziomu, oraz biblioteki umiejętności rosnące z czasem — tak że agent staje się sprawniejszy, im dłużej żyje.

Z inżynierii oprogramowania. Nic z tego nie przetrwa zderzenia z produkcją bez drugiej połowy rodowodu — dyscypliny operacyjnej zadań cron, ciągłej integracji i podręcznika SRE (rotacje, timeouty, obserwowalność), plus nawyku docs-as-code i infrastructure-as-code, by źródło prawdy trzymać w systemie kontroli wersji. W istocie stosuje się tu zasadę agents-as-code: sami agenci to pliki w twoim repozytorium, a ulepszenie agenta jest recenzowaną zmianą jak każda inna.

Imię dla brakującego elementu. Andrej Karpathy ujął tę samą intuicję dosadnie. W rozmowie z 2025 roku zauważył, że człowiek podczas snu destyluje kontekst minionego dnia do wag mózgu — a dzisiejsze modele nie mają odpowiednika tej fazy destylacji, dlatego właśnie zalicza ciągłe uczenie się i trwałą pamięć do brakujących elementów, przez które agenci rozsypują się przy prawdziwej pracy. Osobno naszkicował paradygmat, który nazwał system prompt learning (uczenie przez prompt systemowy): zamiast zmieniać wagi spadkiem gradientu, model powinien uczyć się tak, jak człowiek robi notatki — w istocie pisać sobie książkę o tym, jak rozwiązywać problemy, i poprawiać ją edycjami. Podejście z tego artykułu to konkretna, z człowiekiem przy bramce, realizacja dokładnie tego: instrukcje agenta to książka, samokształcenie to robienie notatek, a propozycja ewolucji to edycja.

Połącz obie połowy — „systemy poprawiają się offline, odtwarzając i konsolidując doświadczenie” z nauki oraz „automatyzuj bezpiecznie, trzymaj wszystko w kontroli wersji, zostaw człowieka w pętli” z inżynierii — a otrzymasz praktykę, o której jest ten artykuł.

Pętla samokształcenia

Wszystko opiera się na jednym głównym cyklu, wykonywanym per agent. Jest celowo mały i ograniczony; celem jest skończona notatka każdej nocy, a nie idealna mapa repozytorium.

Nocny cykl samokształcenia pojedynczego agenta: na nowo przeczytać swoją rolę, wyrywkowo zbadać kod w granicach ścisłego budżetu, napisać notatkę z nauki, wykryć rozjazd między instrukcjami a rzeczywistością i — tylko gdy problem jest strukturalny — naszkicować propozycję samo-ulepszenia do zatwierdzenia przez człowieka.

1. Przeczytaj rolę na nowo. Agent zaczyna od przeczytania własnego opisu — po co jest i jak ma się zachowywać. To punkt zaczepienia; wszystko inne mierzy się względem niego.

2. Zobacz kod wyrywkowo — w granicach budżetu. Następnie ogląda swoją część systemu: pliki-manifesty zdradzające stos technologiczny, listing katalogów, kilka plików wymienionych z nazwy w jego własnych instrukcjach. Budżet jest ścisły celowo — garść odczytów, nie wyczerpujące przeczesywanie. Krótka, trafna notatka bije długie śledztwo, które nigdy się nie kończy, a ciasny budżet utrzymuje każde uruchomienie tanim i szybkim.

3. Napisz notatkę z nauki. Wynikiem jest krótka notatka markdown: rola agenta w jednym zdaniu, lista obserwacji trzech do pięciu konkretnych rzeczy do sprawdzenia właśnie w tym repozytorium (nie ogólne porady) oraz jedno pytanie doprecyzowujące, które agent zadałby człowiekowi przed nietrywialną zmianą. To krok konsolidacji — „czego się dziś nauczyłem”.

4. Wykryj rozjazd. Czytając, agent porównuje swoje instrukcje z tym, co faktycznie znajduje. Plik, do którego odwołują się instrukcje, zniknął. Reguła opisuje przepływ, którego już nie ma. Brakuje zabezpieczenia. Sama niezgodność jest znaleziskiem — a agentowi wprost zabroniono iść to naprawiać, tylko odnotować.

5. Zaproponuj ewolucję. Gdy niezgodność jest strukturalna — nie literówka, lecz realny rozjazd wart przeglądu — agent pisze osobną propozycję ewolucji: co jest nie tak, konkretną zmianę w jego własnym opisie i uzasadnienie. To krok samo-ulepszenia i najważniejsza decyzja projektowa w całym podejściu: agent proponuje, decyduje człowiek. To uczenie się edycjami, nie spadkiem gradientu — owo system prompt learning Karpathy'ego — tylko pióro trzyma człowiek. Agent nigdy nie edytuje swoich instrukcji bezpośrednio. Człowiek przegląda propozycję i stosuje ją w parę minut — albo ją odrzuca.

Uruchamiaj tę pętlę nocami w całym zespole, a instrukcje agentów przestają gnić. Podążają za kodem, zamiast za nim zostawać — bo najlepiej umiejscowiony, by zauważyć, że instrukcja się zdezaktualizowała, jest ten agent, który czyta instrukcję i kod jednocześnie.

Jeden wzorzec, wiele soczewek

Gdy masz już bezpieczny sposób uruchamiania ograniczonego agenta według harmonogramu i zbierania jego wyjścia jako artefaktu, samokształcenie jest tylko pierwszym zastosowaniem. Ta sama maszyneria celuje w inne pytania przez samą podmianę promptu.

Jeden wzorzec uruchomienia w tle — wiele soczewek. Każdy skaner czyta repozytorium przez inne pytanie i pisze ustrukturyzowane artefakty markdown z powrotem do niego: dług, pomysły, pętle operacyjne, kondycja bazy wiedzy.

Wykrywanie długu technicznego. Cotygodniowy przebieg czyta repozytorium tak, jak zrobiłby to starszy inżynier w kiepski dzień — szukając TODO/FIXME/HACK, znajdując pliki podejrzanie często zmieniane, pominięte testy, pliki na tysiąc linii, zduplikowaną logikę — i zakłada górną garść jako konkretne, ograniczone, warte zachodu pozycje. Nie dziesięć tysięcy uwag lintera, lecz pięć rzeczy naprawdę wartych czyjegoś dnia pracy.

Generowanie pomysłów produktowych. Inna soczewka czyta ten sam kod i pyta, czego brakuje: które funkcje architektura czyni tanimi, jakie luki poczułby użytkownik — i zakłada je jako pomysły do przeglądu, o jedno kliknięcie od stania się zadaniem w twoim trackerze.

Pętle operacyjne. Kolejna dokumentuje powracające procesy zespołu — CI/CD, wydanie, dyżury, retrospektywy — jako żywe opisy: wyzwalacz, kroki, tryby awarii, gdzie zajrzeć najpierw, gdy coś się psuje.

Kondycja bazy wiedzy. Jeszcze inna pilnuje uczciwości dokumentacji projektu, zaznaczając, gdzie spisane wiki rozjechało się z kodem.

Myśl spajająca: każda soczewka to wąski, uruchamiany według harmonogramu, ograniczony agent, którego jedynym zadaniem jest zauważać i odnotowywać, nigdy zmieniać kod. Różnorodność bierze się z pytania, a nie z nowej maszynerii.

Sprawiedliwość i bezpieczniki

Uruchamianie agentów bez nadzoru, według harmonogramu, wywołujących realne odwołania do modelu za realne pieniądze — to dokładnie ten rodzaj automatyzacji, który zamienia się w horror, jeśli zbudować go naiwnie. Dyscyplinę, która temu zapobiega, zapożycza się w całości z eksploatacji.

Każde uruchomienie to ograniczona sesja o ścisłym cyklu życia. Watchdog zabija wszystko, co utknęło; uzgadniacz zamyka wszystko, co umarło bez raportu. Nic nie działa w nieskończoność, a każde uruchomienie kończy się w znanym stanie.

Rotacja. Rzadko chcesz uruchamiać każdego agenta co noc — to wolne i drogie. Zamiast tego agenci stoją w rotacji, a harmonogram bierze kilku z góry: najpierw nowych, potem tych, których badano najdawniej, a priorytetowy poziom podbija w górę najważniejszych. Każdy agent dostaje swoją kolej, nikt nie głoduje, a ważni przychodzą częściej. To ta sama logika sprawiedliwości, co grafik dyżurów.

Limity współbieżności. Globalny pułap oznacza, że nawet jeśli podeszło kilkunastu agentów, naraz biegnie jeden czy dwóch. Maszyna pozostaje responsywna, a koszt przewidywalny.

Timeouty i watchdog. Każda sesja jest ograniczona w czasie zegarowym. Watchdog obserwuje wyjście; jeśli uruchomienie na zbyt długo milknie, zostaje zabite. Samokształcenie z założenia jest do krótkich sesji przeglądu — nie jest miejscem, w którym chowa się długie, otwarte zadania.

Uzgadnianie. Procesy czasem umierają brzydko. Uzgadniacz okresowo przechodzi i zamyka każdą sesję, której proces zniknął, ale wpis wciąż mówi „działa”, tak by rozliczenie zawsze się zgadzało.

Nic z tego nie jest egzotyczne. To nudna warstwa operacyjna — harmonogramy, kwoty, timeouty, kontrole kondycji — która zamienia stertę skryptów w coś, co naprawdę można zostawić działające.

Praca kierowana: orkiestracja i bramki jakości

Samokształcenie i skanery są autonomiczne i tłowe: nikt nie prosił o nic konkretnego, agenci po prostu utrzymują bazę wiedzy świeżą. Lustrzanym odbiciem jest praca kierowana i pierwszoplanowa: masz konkretny cel i chcesz, by zespół go wykonał. Tych samych agentów można prowadzić i tak.

Tutaj nadzorca bierze swobodnie sformułowany cel — „zaprojektuj i wdróż funkcję X w module Y” — i rozkłada go na podagentów, rozprowadzając pracę i zbierając ją z powrotem. Dla czegokolwiek nietrywialnego uruchomienie zostaje zorganizowane jako kaskada: potok faz z bramką jakości między każdą z nich.

Uruchomienie kierowane: nadzorca rozkłada cel na podagentów, a ustrukturyzowana praca płynie przez fazy rozdzielone bramkami jakości. Każda bramka albo zatwierdza pracę, albo odsyła ją na kolejny przebieg, albo odrzuca uruchomienie — tak że zła wczesna faza nie może po cichu zatruć wszystkiego w dół potoku.

Typowa kaskada biegnie: kontrakt → projekt → implementacja → przegląd → QA. Między fazami stoi bramka wydająca jeden z trzech werdyktów: zatwierdź (idź dalej), wróć na etap (za słabo, iterujemy) lub odrzuć (zatrzymaj uruchomienie). Bramki są całą istotą. Puszczone prosto na wylot, chwiejny kontrakt zatruwa projekt, ten zatruwa implementację, a odkrywasz to wszystko dopiero na QA. Bramki łapią problem na granicy, gdzie naprawa jest najtańsza, i czynią jakość uruchomienia czytelną: widać dokładnie, gdzie utknęło i dlaczego.

To ten sam instynkt, co przy etapowych potokach CI i punktach kontrolnych przeglądu projektu, zastosowany do zespołu agentów zamiast zespołu ludzi.

Artefakty jako interfejs

Przez wszystko powyżej przewija się nić, którą łatwo przeoczyć i którą warto wypowiedzieć wprost: wyjście każdego agenta to zwykły plik w twoim repozytorium. Notatka z nauki, propozycja ewolucji, pozycja długu, pomysł, pętla, plan — każde jest markdownem z odrobiną ustrukturyzowanego frontmattera, zapisanym do zwykłego folderu i zacommitowanym do gita.

Ten jeden wybór daje wiele.

Trwałość i audyt. Wyjście przeżywa sesję. Pół roku później możesz przeczytać, dlaczego agent coś zaznaczył, zobaczyć w diffie, jak zmieniało się jego rozumienie, i prześledzić linię aż do nocy, w której ją napisano.

Przenośność. Markdown-z-frontmatterem nie jest przywiązany do żadnego dostawcy, modelu ani dashboardu. Zamień model, zmień wykonawcę, wyrzuć narzędzie w całości — artefakty wciąż pozostają plikami, które należą do ciebie.

Człowiek w pętli domyślnie. Ponieważ wyjście jest plikiem, a samomodyfikacja propozycją, przegląd staje się normalną częścią przepływu pracy — diff, pull request, przycisk „zatwierdź”, a nie specjalny właz awaryjny. Agenci generują, ludzie decydują.

Kompozycja niezależna od narzędzi. Na wierzchu może budować się cokolwiek, co potrafi czytać pliki: dashboard do przeglądania notatek, „jednym kliknięciem zamień pomysł w zadanie”, metryka objętości otwartego długu. Artefakty to stabilny interfejs; cała reszta jest opcjonalna.

Dlaczego to działa

Zbierając w całość, podejście zarabia na siebie z kilku powiązanych powodów.

Kumuluje się. Pojedyncza nocna notatka jest niemal bezwartościowa. Trzysta takich, nagromadzonych i skonsolidowanych przez rok, to żywa baza wiedzy o twoim systemie, której nikt nie musiał siadać i pisać. To właśnie małe, nudne przyrosty się kumulują — bo naprawdę się zdarzają.

Bije w dryf u źródła. Najlepiej umiejscowiony, by zauważyć, że instrukcja się zdezaktualizowała, jest agent czytający tę instrukcję i bieżący kod jednym tchem. Samokształcenie stawia wykrywanie dryfu tam, gdzie jest informacja, zamiast liczyć, że człowiek pamięta o audycie.

Jest tanie tam, gdzie powinno. Ograniczone, krótkie, pozaszczytowe uruchomienia z osobna kosztują mało. Wydajesz przestój i drobne, by utrzymać dużą powierzchnię ciepłą.

Jest zarządzane i obserwowalne. Rotacja, kwoty, timeouty i artefakt na każde uruchomienie oznaczają, że to nie czarna skrzynka nieprzejrzystej automatyzacji. Widać, co się uruchomiło, co wytworzyło i ile kosztowało — i każde można wyłączyć.

Odpowiedzialności pozostają rozdzielone. „Mózgi” agentów żyją obok kodu, o którym rozumują; harmonogram i orkiestrator to cienka warstwa sterująca na wierzchu. Żadne nie jest właścicielem drugiego, więc każde można zmieniać osobno — a ta sama warstwa sterująca prowadzi jeden projekt albo pięćdziesiąt.

Kompromisy i kiedy nie warto

To nie jest darmowe i dla części zadań jest złym narzędziem. Uczciwość co do tego to część oferty.

Wymaga dyscypliny przeglądu. Bramka człowieka to funkcja, ale i stały obowiązek. Jeśli propozycji nikt nie przegląda, piętrzą się, a wartość pętli wycieka. Podejście zakłada zespół, który poświęci kilka minut dziennie na „tak” lub „nie”.

Kosztuje tokeny. Skromnie na uruchomienie, odczuwalnie w sumie. Rotacja i limity współbieżności istnieją właśnie po to, by to ograniczać, ale to pozycja kosztowa i na malutkim czy jednorazowym projekcie się nie zwróci.

Wyjście jest niedeterministyczne. Dwie noce, dwie nieco różne notatki. Dla odkrywania i konsolidacji to w porządku — chodzi o wyniesienie rzeczy przed człowieka — ale to znaczy, że surowego wyjścia agenta nie należy wpinać wprost w cokolwiek, co wymaga determinizmu.

Wynagradza dobrą higienę. Agenci są tak dobrzy, jak dobre są napisane przez ciebie role i foldery, do których pozwalasz im pisać. Zasada „śmieci na wejściu” wciąż obowiązuje: pętla czyni lepszym dobrze zdefiniowanego agenta, a nie spójnym — rozmytego.

Jeśli projekt jest mały, krótkotrwały albo w całości mieści się w głowie jednej osoby, która żyje w nim codziennie — odpuść. Podejście zwraca się na systemach dostatecznie dużych, dostatecznie długowiecznych i dzielonych między dostatecznie wiele osób, by nikt nie trzymał całości w głowie. To właśnie tam gnije wiedza — i właśnie tam nocna zmiana się opłaca.

Jak zacząć od małego

Niczego z tego nie wdraża się w całości. Minimalna działająca wersja jest niemal krępująco mała — i o to właśnie chodzi.

Zacznij od jednego agenta, jednej notatki, jednego nawyku. Napisz jeden opis agenta dla ważnej ci części systemu. Niech wytworzy jedną notatkę samokształcenia — ręcznie, na timerze, jak wolisz. Przeczytaj notatkę następnego ranka. Jeśli lista obserwacji jest przydatna, a zaznaczony dryf realny — sprawdziłeś całą ideę za grosze.

Potem dodaj pętlę: uruchamiaj według harmonogramu. Potem dodaj bramkę: pozwól proponować zmiany we własnym opisie i wyrób nawyk zatwierdzania lub odrzucania ich. Potem dodaj drugiego agenta i drugą soczewkę — dług, potem pomysły. Każdy krok jest przydatny sam w sobie; żaden nie wymaga następnego. Zanim zbudujesz pełen zespół na nocnej rotacji z orkiestracją i bramkami, każdy element zdąży zasłużyć na swoje miejsce.

Cała rzecz to zmiana nastawienia: przestań traktować AI jak automat z przekąskami, do którego podchodzisz po odpowiedź, a zacznij traktować je jak zespół, który staje się odrobinę lepszy każdej nocy — gdy ty śpisz.

Najczęstsze pytania

Czym są samodoskonalące się zespoły agentów AI?
To zespół wyspecjalizowanych agentów AI, które żyją obok kodu i działają według harmonogramu, głównie nocą. Każdy agent okresowo na nowo czyta własne instrukcje, studiuje kod, za który odpowiada, i zapisuje, czego się nauczył — wydobywając dług techniczny, pomysły i proponowane poprawki do własnych instrukcji do zatwierdzenia przez człowieka. Celem są agenci, którzy z czasem stają się lepsi właśnie w twojej pracy, zamiast uderzać w sufit.
Na czym polega pętla samokształcenia?
To niewielki nocny cykl wykonywany dla każdego agenta: agent na nowo czyta swoją rolę, wyrywkowo ogląda kod w granicach ścisłego budżetu, pisze krótką notatkę z listą obserwacji i pytaniem doprecyzowującym oraz wykrywa rozjazd między instrukcjami a rzeczywistym kodem. Dopiero gdy niezgodność jest strukturalna, szkicuje propozycję zmiany własnego opisu do przeglądu przez człowieka.
Czy agenci sami automatycznie przepisują swoje instrukcje?
Nie. Agent jedynie proponuje zmianę, a człowiek ją przegląda i stosuje albo odrzuca. To właśnie zasada „agent proponuje, decyduje człowiek" czyni podejście bezpiecznym do uruchamiania bez nadzoru: zła propozycja nic nie kosztuje, a dobra wykonała już najtrudniejsze — zauważyła rozjazd i napisała poprawkę.
Skąd wzięła się idea „śnienia"?
Z kilku stron naraz: konsolidacji pamięci podczas snu w neuronauce, powtórki doświadczeń i agentów „z modelem świata" w uczeniu ze wzmocnieniem oraz agentów z autorefleksją, którzy przechowują pamięć tego, co zadziałało — w połączeniu z dyscypliną operacyjną harmonogramów, rotacji i kontroli wersji. Andrej Karpathy ujął te same intuicje, zauważając, że dzisiejszym modelom brakuje fazy destylacji podobnej do snu, i opisał „system prompt learning", w którym model doskonali się, edytując własne notatki, a nie spadkiem gradientu.
Kiedy warto wdrożyć to podejście, a kiedy nie?
Opłaca się na bazach kodu, które są dostatecznie duże, długowieczne i dzielone między tyle osób, że nikt nie trzyma całości w głowie — właśnie tam wiedza się starzeje. Odpuść je przy małych lub jednorazowych projektach: kosztuje tokeny i wymaga dyscypliny faktycznego przeglądania propozycji. Zalecane wejście to zacząć od małego — jeden agent, jedna nocna notatka i jeden nawyk przeglądu — a potem rosnąć.
← Powrót do MiCode