Copy English

Why

The video's sharpest point isn't the token-saving numbers, it's why vector search (RAG) fails at this job in particular: semantic similarity is not the same relation as dependency (03:01). An embedding index puts "create account" and "delete account" code close together because both chunks talk about the word "account" — so a similarity-ranked retrieval step can hand the agent the delete path when it meant to touch the create path, and the agent edits the wrong function with full confidence (03:13). That's not a noisy embedding, it's the wrong axis: "these two functions mention the same noun" and "changing this function breaks that one" are different relations, and only the second is what an agent actually needs when it modifies code. A dependency graph, built by static parsing rather than learned similarity, encodes exactly that second relation — call edges, import edges, class membership — so a query against it returns what actually depends on what, not what merely reads alike.

How it works

Building the graph

Graft parses the codebase statically and turns it into a knowledge graph: functions, classes and files become nodes, and calls or dependencies between them become edges, written out as a local JSON file (03:46, 06:24, 06:55). A browser viewer lets you walk that graph visually (07:05), and because the edges are explicit, tracing "what breaks if I touch this" is a graph walk rather than a fresh search — the video frames this as immediate blast-radius tracing along edges (05:11, 06:44).

Feeding the graph to the agent — two modes

Two integration modes, per the video: in CLI/hook mode, an incoming prompt is intercepted and Graft injects the graph-derived related files and up to three specific line positions straight into the prompt, so the agent reads those exact lines without spending turns on search tools at all (07:16). In MCP mode, nothing is injected up front; the agent calls Graft as an MCP tool only when it decides it needs to look something up. The video's own comparison found MCP mode slightly more accurate and CLI/hook mode faster (07:43, 07:55) — a reasonable trade-off, since injection saves turns but front-loads context with things the agent might not have needed.

Keeping it current without a model call

Edits change the graph's shape, so Graft re-parses incrementally: only the modified files are re-analyzed, in the background, with no model call involved (05:22, 08:06). That matters for cost — the graph has to stay cheap to maintain, or the token savings on lookup get eaten by the cost of updating it.

What the numbers actually show

The 162-run benchmark (60% time, 46% tool calls, 42% tokens, 32% cost, all reductions vs. grep-based search, 04:33) is Graft's own test suite, not an independent one. A real-project test the video also ran, on a Calendly-style booking app, is more telling about where the advantage actually sits: building the project from scratch with no graph took 39 minutes versus 47 minutes without it — a small gap (11:10). But once the graph already exists, a full landing-page redesign on that same project finished in under two minutes (11:29). The pattern: Graft front-loads a one-time graph-build cost and pays it back on every later change, not on the first cold build.

Setup and the one real limitation

Install the CLI via npm or pip, run graft init in the project root and point it at an agent such as Claude Code (08:44); for an existing project, graft build generates the dependency map (09:41). The limitation worth remembering: Graft maps dependencies between pure code files only — PRDs, planning markdown, logs and similar non-code assets aren't mapped by default (12:03). That's a real gap for a docs-first repo, not a rounding error.

Where it lands in Jayverse

• Verex: the monorepo boundary is exactly where an agent loses the thread — worth a trial. web/api/sdk/cli/contracts means one change (say, an order-status enum) can touch four packages; propose running graft build plus MCP mode on verex and comparing tool-call counts against today's grep-based sessions before deciding whether to add CLI/hook injection too.
• alice: out of scope for Graft — markdown has no call graph. alice is almost entirely .md, which Graft doesn't map by default (12:03); the equivalent problem there is indexing, not dependency-tracing, and belongs with the Obsidian item's index.md idea (obsidian-three-levels-llm-wiki) instead.
• CI: a graph gives impact analysis for free. "Which modules does this PR touch, by edges" is a query against the same graph Graft already builds, not a new tool — worth adding as a CI step that flags packages a PR's edges reach but its diff doesn't mention.
• Auditor: "which files were read to make this change" becomes a graph query. If CLI/hook mode is in use, the injected file list is the audit trail for that turn — the Auditor row can record it as "checked against the dependency graph, N files, injected at prompt time" instead of reconstructing it after the fact.
• Theory: this is the graphs-vs-embeddings argument in one concrete example. The "create account" vs "delete account" mix-up (03:13) is a clean case for the Theory notes on when structural relations beat semantic similarity — worth cross-linking to the Pocock item (pocock-fundamentals-matter-more) on deep modules, since a codebase of deep modules keeps this graph small and shallow, while a codebase of shallow modules makes the graph itself large and noisy.

Verified and unverified

Verified on 2026-09-19: coding agents such as Claude Code and Codex explore unfamiliar codebases with grep-like search and file reads spread across many turns, and each tool result adds to the running context (documented, observable behavior); static analysis is a standard way to build call and dependency graphs from source; MCP is a real protocol that lets an agent call an external tool on demand; vector/embedding similarity encodes semantic closeness, not call or dependency relationships — these are general, verifiable facts about how agents and these techniques work, independent of this specific tool. Taken from the summary and not independently checked: the tool's exact name and repository (the summary itself calls it "Graph" while showing graft init/graft build commands, so Graft is the most likely name, but no GitHub URL is given or invented here), the 162-run benchmark figures, the 39-vs-47-minute and under-two-minute timings on the booking-app test, and all the (mm:ss) timestamps, which come from the video summary as pasted.

Sources: YouTube — AI LABS, "Github Top Trending Tool Just Fixed The AI Agent's Biggest Problem" · related items: Tech #62 (agentic engineering writes the boundaries), Tech #102 (mlflow-tracing-llm-as-judge, token cost as an observed metric), Pocock fundamentals item (pocock-fundamentals-matter-more, deep modules keep the graph shallow).

← All Knowledge Notes · Workspace Index · Top ↑

Copy 한국어

코딩 에이전트에게 필요한 건 grep 반복이 아니다 — 의존성 그래프다

AI LABS의 유튜브 영상 "Github Top Trending Tool Just Fixed The AI Agent's Biggest Problem"는 GitHub에서 트렌딩에 오른 오픈소스 CLI 하나를 다룬다. 이 도구는 코드베이스의 정적 의존성 그래프를 만들어, 코딩 에이전트가 매 턴 grep과 파일 열람을 반복하는 대신 그래프에 질의하게 한다. 영상 내레이션은 이 도구를 "Graph"라고 부르지만 실제로 보여주는 명령어는 `graft init`과 `graft build`다 — 요약 자체가 이름에서 앞뒤가 안 맞으므로, 이 항목에서는 Graft(CLI 이름)를 쓴다. 주장은 이렇다. "버튼을 초록으로"처럼 사소한 요청조차 에이전트가 올바른 줄을 찾기까지 grep과 파일 열람을 여러 라운드 반복시킬 수 있고(01:11, 01:44), 라운드마다 검색 결과와 그 전까지의 대화 전체가 컨텍스트에 남아 토큰 예산을 빠르게 소모하고 추론을 느리게 하며 컨텍스트가 커질수록 출력 품질도 떨어진다(01:33, 02:11, 02:33). Graft 자체의 162회 벤치마크는 이 grep 기반 기준선 대비 소요 시간 60% 감소, 도구 호출 46% 감소, 토큰 42% 감소, 비용 32% 감소를 보고한다(04:33).

Jayverse에서는 verex에 시험해 볼 만하다. verex는 web, api, sdk, cli, contracts로 나뉜 pnpm 모노레포로, 전체 스택 중 하나의 변경을 추적하려면 패키지 경계를 넘어야 하는 유일한 형태다. grep 반복과 벡터 검색 둘 다 갈피를 잃기 딱 좋은 구조다.

왜

영상에서 가장 날카로운 지점은 토큰 절감 수치가 아니라, 벡터 검색(RAG)이 이 일에서 왜 특히 실패하는가다. 시맨틱 유사도는 의존 관계와 다른 관계다(03:01). 임베딩 인덱스는 '계정 생성'과 '계정 삭제' 코드를 가깝게 배치하는데, 둘 다 '계정'이라는 단어를 다루기 때문이다 — 그래서 유사도로 순위를 매기는 검색 단계가 생성 경로를 고치려는 에이전트에게 삭제 경로를 건넬 수 있고, 에이전트는 확신을 가지고 엉뚱한 함수를 고친다(03:13). 이건 임베딩이 노이즈가 많아서가 아니라 축 자체가 틀린 것이다. '이 두 함수는 같은 명사를 언급한다'와 '이 함수를 바꾸면 저 함수가 깨진다'는 서로 다른 관계이고, 에이전트가 코드를 수정할 때 실제로 필요한 건 후자뿐이다. 학습된 유사도가 아니라 정적 파싱으로 만든 의존성 그래프는 바로 그 두 번째 관계 — 호출 엣지, import 엣지, 클래스 소속 — 를 직접 인코딩하므로, 그래프에 질의하면 겉보기에 비슷한 것이 아니라 실제로 무엇이 무엇에 의존하는지가 나온다.

동작 방식

그래프 만들기

Graft는 코드베이스를 정적으로 파싱해 지식 그래프로 바꾼다. 함수, 클래스, 파일이 노드가 되고 그 사이의 호출·의존이 엣지가 되어 로컬 JSON 파일로 기록된다(03:46, 06:24, 06:55). 브라우저 뷰어로 이 그래프를 시각적으로 탐색할 수 있고(07:05), 엣지가 명시적이므로 '이걸 건드리면 뭐가 깨지는가'를 추적하는 일이 새 검색이 아니라 그래프 한 번 걷기가 된다 — 영상은 이를 엣지를 따라가는 즉각적인 영향 범위 추적으로 설명한다(05:11, 06:44).

에이전트에게 그래프를 먹이는 두 방식

영상이 말하는 두 연동 모드. CLI/hook 모드에서는 들어오는 프롬프트를 가로채, 그래프에서 나온 관련 파일과 최대 세 곳의 구체적 줄 위치를 프롬프트에 바로 주입한다. 그러면 에이전트는 검색 도구에 턴을 쓰지 않고 바로 그 줄들을 읽는다(07:16). MCP 모드에서는 미리 주입하지 않는다. 에이전트가 필요하다고 판단할 때만 Graft를 MCP 도구로 호출한다. 영상 자체 비교에서는 MCP 모드가 정확도가 조금 더 높았고 CLI/hook 모드가 더 빨랐다(07:43, 07:55) — 합리적인 트레이드오프다. 주입은 턴을 아끼지만 에이전트가 필요 없었을 수도 있는 내용으로 컨텍스트를 먼저 채우기 때문이다.

모델 호출 없이 최신 상태 유지

수정이 일어나면 그래프의 모양도 바뀌므로, Graft는 점진적으로 재파싱한다. 수정된 파일만 백그라운드에서 다시 분석하고, 모델 호출은 없다(05:22, 08:06). 비용 면에서 이게 중요한 이유는, 조회에서 절약한 토큰을 그래프 유지 비용이 다시 갉아먹지 않으려면 그래프 유지 자체가 싸야 하기 때문이다.

숫자가 실제로 보여주는 것

162회 벤치마크(시간 60%, 도구 호출 46%, 토큰 42%, 비용 32%, 모두 grep 기반 검색 대비 감소, 04:33)는 Graft 자체 테스트 스위트이지 독립 검증이 아니다. 영상이 함께 돌린 실제 프로젝트 테스트, 캘린들리형 예약 앱은 이점이 실제로 어디 있는지 더 잘 보여준다. 그래프 없이 처음부터 프로젝트를 빌드하는 데 39분, 그래프 없는 쪽은 47분 — 차이가 작다(11:10). 하지만 그래프가 이미 존재하는 상태에서는 같은 프로젝트의 랜딩 페이지 전면 개편이 2분 미만에 끝났다(11:29). 패턴은 이렇다. Graft는 그래프를 한 번 만드는 비용을 먼저 치르고, 그 이후의 모든 변경에서 그 비용을 회수한다. 첫 콜드 빌드에서 회수하는 게 아니다.

설정과 유일한 진짜 한계

npm이나 pip로 CLI를 설치하고, 프로젝트 루트에서 graft init을 실행해 Claude Code 같은 에이전트를 지정한다(08:44). 기존 프로젝트는 graft build로 의존성 맵을 생성한다(09:41). 기억해 둘 한계: Graft는 기본적으로 순수 코드 파일 간의 의존성만 매핑한다 — PRD, 기획 markdown, 로그 같은 비코드 자산은 기본적으로 매핑 대상이 아니다(12:03). 문서 중심 저장소에는 반올림 오차가 아니라 실제 공백이다.

Jayverse에서의 위치

• Verex: 모노레포 경계가 바로 에이전트가 갈피를 잃는 지점이다 — 시험해 볼 가치가 있다. web/api/sdk/cli/contracts라는 구조는 변경 하나(예: 주문 상태 enum)가 패키지 네 개를 건드릴 수 있다는 뜻이다. verex에 graft build와 MCP 모드를 돌려 오늘의 grep 기반 세션과 도구 호출 수를 비교한 뒤, CLI/hook 주입까지 추가할지 판단하자고 제안한다.
• alice: Graft의 범위 밖이다 — markdown에는 호출 그래프가 없다. alice는 거의 전부 .md이고, Graft는 기본적으로 이를 매핑하지 않는다(12:03). alice에서 대응하는 문제는 의존성 추적이 아니라 인덱싱이며, Obsidian 항목의 index.md 아이디어(obsidian-three-levels-llm-wiki)와 묶어 다루는 게 맞다.
• CI: 그래프가 있으면 영향 분석이 거저 딸려온다. "이 PR이 엣지로 어느 모듈을 건드리는가"는 Graft가 이미 만든 그래프에 대한 질의일 뿐 새 도구가 아니다. PR의 diff에는 언급되지 않았지만 엣지로는 닿는 패키지를 표시하는 CI 단계로 추가할 가치가 있다.
• Auditor: "이 변경을 만들기 위해 어떤 파일을 읽었는가"가 그래프 질의가 된다. CLI/hook 모드를 쓴다면 주입된 파일 목록 자체가 그 턴의 감사 기록이다 — Auditor 행은 사후에 재구성하는 대신 "의존성 그래프 대비 확인, N개 파일, 프롬프트 시점에 주입"이라고 기록할 수 있다.
• Theory: 이건 그래프 대 임베딩 논쟁의 구체적 사례 하나다. '계정 생성' 대 '계정 삭제' 혼동(03:13)은 구조적 관계가 시맨틱 유사도를 이기는 경우를 다루는 Theory 노트에 딱 맞는 사례다. Pocock 항목(pocock-fundamentals-matter-more)의 깊은 모듈 논의와 연결할 가치가 있다. 깊은 모듈로 이루어진 코드베이스는 이 그래프를 작고 얕게 유지하는 반면, 얕은 모듈로 이루어진 코드베이스는 그래프 자체를 크고 시끄럽게 만든다.

확인된 것과 미확인

2026-09-19 확인: Claude Code나 Codex 같은 코딩 에이전트가 낯선 코드베이스를 grep류 검색과 파일 열람으로 여러 턴에 걸쳐 탐색하고, 도구 결과마다 진행 중인 컨텍스트에 쌓인다는 것(문서화되어 관찰 가능한 동작); 정적 분석이 소스에서 호출·의존성 그래프를 만드는 표준적인 방법이라는 것; MCP가 에이전트가 필요할 때 외부 도구를 호출하게 하는 실제 프로토콜이라는 것; 벡터·임베딩 유사도는 시맨틱 근접성을 인코딩할 뿐 호출·의존 관계를 인코딩하지 않는다는 것 — 이들은 이 특정 도구와 무관하게 에이전트와 이 기법들이 어떻게 작동하는지에 대한 일반적이고 검증 가능한 사실이다. 요약에서 가져왔고 독립 확인하지 않은 것: 도구의 정확한 이름과 저장소(요약 자체가 "Graph"라고 부르면서 graft init/graft build 명령어를 보여주므로 Graft가 가장 유력한 이름이지만, GitHub URL은 주어지지 않았고 여기서 지어내지 않았다), 162회 벤치마크 수치, 예약 앱 테스트의 39분 대 47분과 2분 미만 수치, 그리고 페이스트된 영상 요약에서 온 모든 (mm:ss) 타임스탬프.

출처: YouTube — AI LABS, "Github Top Trending Tool Just Fixed The AI Agent's Biggest Problem" · 관련 항목: Tech #62(에이전틱 엔지니어링은 경계를 쓴다), Tech #102(mlflow-tracing-llm-as-judge, 토큰 비용을 관측 지표로), Pocock fundamentals 항목(pocock-fundamentals-matter-more, 깊은 모듈이 그래프를 얕게 유지한다).

← 전체 기술 노트 · 워크스페이스 인덱스 · 맨 위 ↑