--- title: "Poprawka Andreja Karpathy'ego dla pamięci LLM działa także na kod" source: "https://medium.com/ai-all-in/andrej-karpathys-fix-for-llm-memory-works-on-code-too-9a9e38b18b4e?source=home_for_you---------3-98--------------------0dafcc76_5f3c_4bc6_bff8_35a939ffb2db-------15-------" author: - "[[Yanli Liu]]" published: 2026-07-28 created: 2026-07-31 description: "Dwa narzędzia open-source, które zamieniają jego pomysł w graf kodu dla własnej bazy kodu." tags: - "clippings" --- ## Dwa narzędzia open-source, które zamieniają jego pomysł w graf kodu dla własnej bazy kodu. ![](https://miro.medium.com/v2/resize:fit:1400/format:webp/0*dtqmeOA4U98MiuB4) Zdjęcie: Kevin Butz na Unsplash [Przeczytaj to za darmo](https://medium.com/ai-all-in/andrej-karpathys-fix-for-llm-memory-works-on-code-too-9a9e38b18b4e?sk=6429de91d574260cebe1b572abee952a) Prosi swojego agenta programistycznego, by znalazł każdego dzwoniącego daną funkcję, zanim ją dotkniesz. Gregreje repozytorium, otwiera cztery lub pięć plików, przegląda importy, których nie potrzebuje, i daje ci odpowiedź. Zapytaj jutro ponownie, ten sam repozytorium, to samo pytanie. Zaczyna od zera i robi cały crawl od nowa. **Nic, czego się wczoraj nauczył, nie przeniosło się do niej.** Pisałem o tej dokładnej awarii w kwietniu, tylko nie dla kodu. " [RAG, LLM Wiki czy Gbrain? "Jak twój agent pamięta zmienia wszystko](https://medium.com/ai-advances/rag-llm-wiki-or-gbrain-how-your-agent-remembers-changes-everything-56829e66725c) " porównał trzy sposoby, w jakie agent może pamiętać: za każdym razem szukać na nowo, skompilować wiki raz i ciągle je zapytać, albo iść dalej i działać na podstawie tego, co wie. Tweet Andreja Karpathy'ego był kotwicą tego tekstu. Jego argument: przestańcie traktować LLM jako wyszukiwarki, które czytają te same dokumenty na każde pytanie. Skompiluj wiedzę w strukturę raz. Zamiast tego zapytaj strukturę. Ten tekst dotyczył badań i robienia notatek. Kod ma ten sam problem. Więc poszukałem narzędzi, które traktują bazę kodu tak, jak Karpathy traktuje folder badawczy: przeanalizują ją raz, zbudują strukturę, pozwólą agentowi zapytać strukturę zamiast ponownie czytać pliki. Istnieje kilka takich przypadków. Graphify i codebase-memory-mcp robią wersje tego do szerszych wejść, plików Terraform, notatek ze spotkań, całych zestawów dokumentacji, nie tylko kodu. Dwa z nich pozostają dedykowane kodowi: - [colbymchenry/codegraph](https://github.com/colbymchenry/codegraph) to wersja ogólnego przeznaczenia, z ponad 60 000 gwiazdek na GitHub. - [tirth8205/code-review-graph](https://github.com/tirth8205/code-review-graph) zawęża tę samą ideę, by pull request review, z ponad 25 000 gwiazdek dla siebie. Chciałem się dowiedzieć, czy którykolwiek z tych rozwiązań faktycznie zmienia sposób pracy agenta na co dzień i jak byś go wykorzystał. ![](https://miro.medium.com/v2/resize:fit:1400/format:webp/1*0FjeXwKE4itTViYegY7EQQ.png) Diagram autorstwa autora: RAG, LLM Wiki i GBrain, z dodanym Code Wiki jako odpowiednikiem kodu Grep traktuje twój kod jak zwykły tekst. Może wskazać każdą linijkę, w której pojawia się imię. Nie potrafi powiedzieć, co faktycznie zależy od tego imienia, ani co przerywa dwa kroki od linii, na którą patrzysz. Wykres to naprawia, zachowując relacje, a nie tylko słowa. Przeanalizuj kod raz i zamiast wyrzucać właśnie znalezioną strukturę, zapisz ją: ta funkcja wywołuje tamto, ten plik importuje tamten, ta klasa dziedziczy tamtę. To daje ci dwie rzeczy, które warto nazwać osobno. 1. Najważniejszą z **nich jest niezawodność**: agent przestaje brakować zależności bez tych samych słów, ponieważ **istnieje krawędź grafu, niezależnie od tego, czy dwa pliki używają tego samego słownictwa.** 2. **Koszt** to druga, mniejsza rzecz, którą warto znać. Zapytanie wstępnie obliczonego grafu pod kątem "kto to wywołuje" kosztuje kilka wierszy, a nie pięć plików surowego tekstu do przeczytania i rozważania. Oba narzędzia budują wykres w ten sam sposób. - Parsuj za pomocą tree-sittera, prawdziwego parsera, który rozumie granice funkcji, zamiast zgadywać na podstawie wcięcia czy słów kluczowych. - Zapisz wynik w SQLite: symbole jako węzły, wywołania i importy oraz dziedziczenie jako krawędzie. - Siedź za serwerem MCP, żeby twój agent bezpośrednio zapytywał graf, zamiast gregre i czytać pliki od zera w każdej sesji. Jeszcze jedna rzecz, którą warto wiedzieć przed instalacją czegokolwiek: oba narzędzia są najpierw lokalne. Brak wywołań sieciowych, brak kluczy API, tylko plik SQLite na twoim komputerze. Żadne dane nie opuszczają laptopa, a koszt za zapytanie nie ma więcej niż jednorazowe składanie. ![](https://miro.medium.com/v2/resize:fit:1400/format:webp/1*dusPBEHzG5KSRBJqOprQJA.png) Diagram autora: Współdzielony potok: tree-sitter parsuje raz, graf znajduje się w SQLite, MCP udostępnia go agentowi ### Czym jest Codegraph Codegraph to narzędzie na pozostałe dziewięćdziesiąt procent czasu spędzonego z agentem kodującym: zrozumienie bazy kodu. Instalacja to jedno polecenie:. Następnie przelewa go do swojego agenta i buduje indeks.`curl -fsSL https://raw.githubusercontent.com/colbymchenry/codegraph/main/install.sh | sh` `codegraph install` `codegraph init` Uruchomiłem to na [OmniRoute](https://github.com/diegosouzapw/OmniRoute), open-source projekcie ponad 8 000 plików. Indeks kończył się w 34 sekundy i zajmował 325 megabajtów na dysku, nieco więcej niż 233-megabajtowy repozytorium źródłowe, z którego został zbudowany. Gdy już zostanie zbudowany, agent otrzymuje nowe polecenia zamiast polegać na grepcie i odczytach plików. znajduje, kto coś dzwoni. Ślady się psują, jeśli to zmienisz. Oba zwracają krótką, bezpośrednią odpowiedź zamiast stosu akt do przeczytania.`codegraph callers` `codegraph impact` Oto jak to wyglądało na prawdziwej imprezie. OmniRoute ma kontrolę routingu o nazwie *classifyRoute*, ukrytą w kodzie uwierzytelniania. Zapytałem codegraph, co by się zmieniło, gdybym to zmienił. Odpowiedź pojawiła się jednym wywołaniem, 344 bajty: sama classifyRoute, jej jeden bezpośredni wywołujący oraz plik o nazwie proxy.ts. To ostatnie jest ciekawe. proxy.ts nie wywołuje bezpośrednio classifyRoute, lecz funkcję o nazwie runAuthzPipeline, która wywołuje classifyRoute. Grep, szukając dosłownego tekstu "classifyRoute", znalazł 17 dopasowań w trzech plikach. Nigdy nie wypłynęło proxy.ts. Połączenie jest oddalone o dwa kroki, a grep pasuje tylko do słów. **Codegraph znalazł to, ponieważ wykres śledzi, co faktycznie co nazywa**.Wspólne słownictwo nie ma z tym nic do rzeczy. Odpowiedź Codegraph była o 98,7% mniejsza niż sam grając i czytając trzy pasujące pliki. To jest codzienna wartość. Zanim dotkniesz funkcji, zapytaj, co od niej zależy, i uzyskaj odpowiedź uwzględniającą pośrednictwo, a nie tylko taką, która wyróżnia to, co dzieje się przy dzieleniu twojego hasła wyszukiwania. ### Czym jest Code Review Graph? code-review-graph istnieje dla węższego momentu: momentu, w którym dokonałeś zmiany i musisz wiedzieć, co ona dotyka, zanim otworzysz pull request. Instalacja to najpierw w środowisku wirtualnym, jeśli twój system nie ma jeszcze skonfigurowanego PIP. Wtedy i.`pip install code-review-graph` `code-review-graph install` `code-review-graph build` Zbudowanie tego samego grafu OmniRoute zajęło 2 minuty i 25 sekund, czyli około cztery razy dłużej niż codegraph. Lokalny sklep zajmował 1,4 gigabajta, ponad czterokrotnie większy niż codegraph. To wymiana za dodatkową głębię, którą uchwyca. To jednak uchwyca więcej. Zapytanie code-review-graph dla wywołujących classifyRoute zwracało ten sam proxy.ts zależności, jaki znajdował codegraph, plus coś, co odpowiedź codegraph złożyła w jeden ogólny wpis pliku: cztery indywidualne przypadki testowe, każdy nazwany i numerowany linijkami, które konkretnie wykonują classifyRoute. **Taka szczegółowość to właśnie to, czego recenzent naprawdę chce.** Zanim zatwierdzisz zmianę, chcesz wiedzieć nie tylko, czy coś w pliku testowym ją obejmuje, ale także które testy są właściwe i czy są właściwe. code-review-graph przypisuje również ocenę ryzyka do zmienionego kodu i może na niej wyciągnąć pull request. To zestaw czynników ważonych, ile rzeczy nazywa ten kod, czy jest on objęty testami, czy nazwa pasuje do listy słów kluczowych brzmiących bezpiecznie, sumowanych i ograniczonych. **To nie jest model wytrenowany na rzeczywistych rezultatach.** Potraktuj to jako zachętę do bliższego przyjrzenia się, a nie jako werdykt. ![](https://miro.medium.com/v2/resize:fit:1400/format:webp/1*bi-YgDTUL423bzOQ1TWBMQ.png) Diagram autora: ocena ryzyka code-review-graph: sześć czynników ważonych zsumowanych i ograniczonych Poproś o coś szerszego, na przykład pełny promień wybuchu całego pliku zamiast jednej funkcji, a wynik szybko rośnie. Mój test wyniósł 596 kilobajtów, a obcięte do 500 z 5 264 dotkniętych węzłów. Szerokie zapytania zachowaj na momenty, gdy naprawdę potrzebujesz pełnego obrazu, a wąskie na codzienne przeglądy. ![](https://miro.medium.com/v2/resize:fit:1400/format:webp/1*dCBdXUb-toyDz4-GV5oYvw.png) Schemat autora: Wąskie zapytanie pozostaje małe; balonki o szerokim promieniu wybuchu do 596KB ### codegraph vs code-review-graph Obok siebie dwa narzędzia dzielą się dokładnie wzdłuż oczekiwanych schematów: jedno stworzone do szybkości i codziennego użytkowania, drugie pod kątem głębi podczas recenzji. ![](https://miro.medium.com/v2/resize:fit:1400/format:webp/1*KzImUp3rmJLtchyU-HpgBA.png) Diagram autora: ocena ryzyka code-review-graph: sześć czynników ważonych zsumowanych i ograniczonych Używaj Codegraph do pisania i rozumienia kodu, a jeśli potrzebujesz głębszej recenzji kodu, dodaj code-review-graph. ![](https://miro.medium.com/v2/resize:fit:1400/format:webp/1*EfEsTccVeMjtvBtG1b0aNw.png) Diagram autora: Używaj codegraphu podczas pisania, przegląd kodu przed scalaniem Pamiętaj, że żadne z tych narzędzi nie jest gotowym oprogramowaniem i oba mają nierówne krawędzie, które warto znać, zanim na nich polegasz. Auto-sync, funkcja, która ma utrzymać wykres w aktualności bez zastanowienia się, powoduje problemy z GitHubem na obu repozytoriach opisujące luki. Plik zapisany w trakcie edycji może zostać zindeksowany względem przestarzałego hasha i pozostać nieprawidłowy aż do pełnej rekonstrukcji. Przemianowane pliki mogą pozostawić nieaktualny węzeł pod starą nazwą i nieindeksowany pod nową. Żadne z narzędzi nie ostrzega cię, gdy to się dzieje, więc odbuduj to, zanim zaufasz odpowiedzi, która ma znaczenie. Zakres języków też nie jest jednolity. Niezależny akademicki benchmark na powiązanym narzędziu, Codebase-Memory, wykazał, że parsowanie oparte na drzewie gwałtownie spada na makro-wysoko obciążonym C, ponieważ parser w ogóle nie reprezentuje makr preprocesora. Kod opierający się na mocnych makr w C napotka tu prawdziwe luki. Precyzja Code-Review-Graph w analizie wpływu jest niższa niż sugerują liczby nagłówkowe. Według własnych opublikowanych danych, blisko cztery na dziesięć oznaczonych "dotkniętych" plików okazuje się nie. Z tego samego powodu, dla którego zapytania recenzyjne są wąskie, co w ostatniej części. To wszystko nie czyni żadnego z tych narzędzi bezużytecznymi. Oznacza traktowanie wykresu jako mocnego pierwszego podejścia, a nie jako źródła prawdy, którego nigdy nie trzeba sprawdzać. ![](https://miro.medium.com/v2/resize:fit:1400/format:webp/1*rwxFjJ7h-zMVV1cGV5jjkQ.png) Diagram autora: Trzy szczere ograniczenia, które warto sprawdzić, zanim zaufasz któremukolwiek z narzędzi ### Ostateczne przemyślenia **Karpathy nigdy nie chodził o wiki. Chodziło o to, żeby remake LLM nie działał, bo już działał.** codegraph i code-review-graph stosują to do kodu: parsują raz, zachowują strukturę, zapytują ją zamiast czytać ponownie. Zacznij od codegraph. To szybsza konfiguracja i obejmuje to, co robisz najbardziej: rozumienie kodu podczas jego pisania. Dodaj code-review-graph, gdy faktycznie będziesz mieć workflow pull request, który wymaga sprawdzenia promienia wybuchu przed merge. Następnie uruchom jedno zapytanie na własnym kodzie. Wybierz funkcję, którą zamierzasz zmienić i uruchom. Sprawdź, czy odpowiedź nie wyświetli czegoś, co Grep mógłby przeoczyć. To jedyny punkt odniesienia, który się tu liczy, i możesz go sam przeprowadzić w ciągu najbliższych pięciu minut.`codegraph impact ` ## [Jak sprawić, by Claude w kilka minut zaczął prowadzić badania jak doktorat](https://medium.com/ai-all-in/how-to-make-claude-research-like-a-phd-in-minutes-f226e9c40677?source=post_page-----9a9e38b18b4e---------------------------------------) ### Jak STORM Stanforda zamienia temat w cytowany, wieloperspektywiczny brief i jak go przedstawić w Claude. medium.com ## Zanim pójdziesz! 🦸🏻♀️ Jeśli podobała ci się moja historia i chcesz mnie wesprzeć: 1. Rzuć trochę Medium miłości 💕 (brawa, komentarze i podkreślenia), wasze wsparcie znaczy dla mnie wszystko. 👏 2. [Śledź mnie](https://medium.com/@yanli.liu/about) na Medium i subskrybuj, aby otrzymywać mój najnowszy artykuł🫶 ## [O nim - Yanli Liu - Medium](https://medium.com/@yanli.liu/about?source=post_page-----9a9e38b18b4e---------------------------------------) ### Przeczytaj teksty Yanli Liu na Medium. Dzienny specjalista finansowy z Luksemburga, doświadczony programista i pasjonat... medium.com