LLM을 프롬프트하는 대신 결정론적 AST 리팩토링을 구축한 이유

작성자

카테고리:

← 피드로
DEV Community · VANSH ARORA · 2026-10-01 개발(SW)

VANSH ARORA

When developers ask an AI agent to “rename handleUser to processUser across the project”, most agents perform fuzzy grep searches and attempt sequential file rewrites.

This approach is prone to edge-case errors:

  • Over-matching: Renaming handleUser inside string literals or unrelated comments.
  • Shadowing: Colliding with existing scoped variables.
  • Missed exports: Forgetting re-exported names in barrel files.

The AST Approach

In TokenCap, refactoring commands are executed by deterministic tree-sitter AST traversal rather than generative token prediction.

# Safely rename a function across the entire call graph
tokencap refactor rename src/auth.js:validateSession authenticateSession --dry-run

Enter fullscreen mode Exit fullscreen mode

Output:

Inspecting 58 files...
Resolved 12 exact symbol references:
  ✓ src/auth.js:24: declaration
  ✓ src/middleware/session.js:15: call site
  ✓ src/routes/api.js:82: call site
  - Skipping string literal at src/tests/mock.js:12 ("validateSession")
Dry run complete: 12 references updated across 3 files with 0 syntax errors.

Enter fullscreen mode Exit fullscreen mode

Similarly, tokencap refactor rm-dead uses our AST call-resolution graph to detect uncalled, unexported dead functions and prune them safely.

By using the LLM for high-level decision making and TokenCap for deterministic syntax-tree transforms, refactor operations remain safe and reproducible.

Documentation available at tokencap.vansharora.app

원문에서 계속 ↗