Coding agents-க்கு Graft codebase map பயன்படுத்துவது

Coding agents-க்கான codebase map என்றால் என்ன

Coding agents-க்கான codebase map என்பது உங்கள் repository-ன் ஒரு நிலையான index ஆகும். ஒவ்வொரு புதிய session-லும் புதிதாக grep செய்வதற்குப் பதிலாக, agent இந்த index-ஐப் பயன்படுத்தி தகவல்களைத் தேடும். Graft என்பது இந்த கருத்தாக்கத்தின் ஒரு செயல்படுத்தல் முறை ஆகும். இது tree-sitter மூலம் உங்கள் code-ஐப் பகுப்பாய்வு செய்து, இணைக்கப்பட்ட markdown nodes கொண்ட ஒரு கோப்புறையையும், ஒவ்வொரு symbol-க்கும் இடையிலான wiring graph-ஐயும் உருவாக்குகிறது. மேலும், MCP (model context protocol - coding agents வெளிப்புறக் கருவிகளை அழைக்கப் பயன்படுத்தும் தரப்படுத்தப்பட்ட interface) மூலம் retrieval கருவிகளை இது வழங்குகிறது.

Graft ஒரு proxy அல்ல, இது ஒரு gateway-வும் அல்ல. உங்கள் agent-க்கும் model API-க்கும் இடையில் எதுவும் செயல்படுவதில்லை. இந்த map என்பது உங்கள் disk-ல் உள்ள ஒரு கோப்புறை மட்டுமே; அதை agent வாசித்துக் கொள்ளும். இந்த வேறுபாடு நீங்கள் எந்தப் பிரச்சினையைத் தீர்க்கிறீர்கள் என்பதைத் தீர்மானிக்கிறது: a self-hosted token gateway நீங்கள் அனுப்பும் கோரிக்கைகளை அளவிடுகிறது மற்றும் வழிநடத்துகிறது, ஆனால் ஒரு map என்பது நீங்கள் எத்தனை கோரிக்கைகளை அனுப்ப வேண்டும் என்பதையே மாற்றியமைக்கிறது.

இந்த நுட்பம் இந்தக் கருவியை விடப் பழமையானது மற்றும் இது நீண்ட காலம் நிலைத்திருக்கும். முதலில் நுட்பத்தைக் கற்றுக்கொள்ளுங்கள், அதன் பிறகு அதன் செயல்பாட்டு முறைகளைத் தெரிந்துகொள்ளுங்கள்.

Coding agents ஏன் கட்டமைப்பை மீண்டும் கண்டறியும் முயற்சியில் context-ஐ வீணடிக்கின்றன

ஏற்கனவே ஐம்பது முறை பார்த்த ஒரு repository-ல் ஒரு agent வேலை செய்யத் தொடங்குவதைக் கவனியுங்கள். அது directories-ஐ பட்டியலிடுகிறது. ஒரு symbol-ஐத் தேட grep செய்கிறது. எந்தக் கோப்பில் function வரையறுக்கப்பட்டுள்ளது என்பதைக் கண்டறிய மூன்று கோப்புகளைத் திறக்கிறது, பின்னர் யார் அதை அழைக்கிறார்கள் என்பதைக் கண்டறிய நான்காவது கோப்பைத் திறக்கிறது. இதில் எதுவுமே உண்மையான பணி அல்ல. இது ஒரு orientation (திசை அறிதல்) செயல்முறை, இதற்கு ஒவ்வொரு session-லும் input tokens மூலம் கட்டணம் செலுத்தப்படுகிறது.

இதற்கான காரணம் எளிதானது. ஒரு model-க்கு session-களுக்கு இடையே நினைவாற்றல் கிடையாது. உங்கள் கோப்பு முறைமை (layout) பற்றி agent கற்றுக்கொண்ட அனைத்தும், session முடிந்ததும் நீக்கப்படும் context window-ல் மட்டுமே இருந்தன. எனவே, அதே கண்டறியும் செயல்முறை மீண்டும் பூஜ்ஜியத்திலிருந்து, முழு கட்டணத்தில் தொடங்குகிறது. ஒரு பெரிய repository-ல், திருத்தம் செய்வதை விட orientation கட்டமே அதிக செலவை ஏற்படுத்துகிறது: குறியீட்டைக் கண்டறிய பத்து tool calls, அதை மாற்ற ஒரு tool call. Orientation என்பது அந்தச் செலவில் பாதி, திருத்தம் என்பது மீதி. இதனால்தான் வேலை செய்யும் மிகச்சிறிய மாற்றத்திற்கு agent-ஐக் கட்டுப்படுத்தும் திறன் என்பது, ஒரு வரைபடத்துடன் (map) இணைத்துச் செயல்படுவதற்கு மதிப்புடையது; இரண்டில் ஒன்றை மட்டும் தேர்ந்தெடுப்பதை விட இது சிறந்தது.

ஒரு வரைபடம், கண்டறியும் பணியை model-லிருந்து நீக்கி disk-க்கு மாற்றுவதன் மூலம் அந்தச் சுழற்சியை உடைக்கிறது. ஒரு parser repository-ஐ ஒருமுறை ஆய்வு செய்து, எந்த symbol எங்கே வரையறுக்கப்பட்டுள்ளது மற்றும் எது எதை அழைக்கிறது என்பதைப் பதிவு செய்கிறது, பின்னர் குறியீடு மாறும்போது அந்தப் பதிவைப் புதுப்பித்த நிலையில் வைத்திருக்கிறது. Agent ஒரு கேள்வியைக் கேட்கிறது, அதற்குரிய கோப்பு மற்றும் வரி எண்ணுடன் பதில் கிடைக்கிறது. மீண்டும் மீண்டும் செய்யப்படும் தேடல், மலிவான lookup-ஆக மாறுகிறது.

நீங்கள் ஏற்கனவே இதன் ஒரு பலவீனமான பதிப்பைப் பயன்படுத்துகிறீர்கள். உங்கள் மரபுகளைக் குறிப்பிடும் ஒரு AGENTS.md கோப்பு, ஒவ்வொரு முறையும் உங்கள் மரபுகளை agent மீண்டும் கண்டறியும் முயற்சியைத் தடுக்கிறது. உருவாக்கப்பட்ட ஒரு வரைபடம் (generated map), அது உங்கள் கட்டமைப்பை மீண்டும் கண்டறியும் முயற்சியைத் தடுக்கிறது. இதில் உள்ள வித்தியாசம், அதை யார் எழுதுகிறார்கள் என்பதுதான். நீங்கள் அறிவுறுத்தல் கோப்பை (instruction file) கையால் எழுதுவதால், அது சிறியதாகவே இருக்கும். ஒரு parser வரைபடத்தை உருவாக்குவதால், அது பத்தாயிரம் கோப்புகளைக் கூட உள்ளடக்கும். ஒரு session-க்குள் பட்ஜெட் உண்மையில் எங்கே செலவாகிறது என்பதைப் பற்றி, Claude Code தனது context window-ஐ எவ்வாறு செலவிடுகிறது என்ற கட்டுரை விளக்குகிறது.

Graft உண்மையில் எதை உருவாக்குகிறது

repository-ன் root-ல் உள்ள ஒரே graft/ கோப்புறைக்குள் இரண்டு artefacts உருவாக்கப்படுகின்றன.

முதலாவது, linked markdown வடிவில் எழுதப்பட்ட node graph ஆகும்; ஒவ்வொரு node-க்கும் ஒரு கோப்பு வீதம் இருக்கும். ஒவ்வொரு node-லும் ஒரு எளிய ஆங்கிலச் சுருக்கம், source-லிருந்து எடுக்கப்பட்ட முக்கியமான logic வரிகளின் "crux", content hash கொண்ட துல்லியமான source கோப்புகள், பிற node-களுக்கான typed wikilinks (depends_on, part_of, uses, implements) மற்றும் regeneration-ன் போதும் அழியாத notes பகுதி ஆகியவை இருக்கும். இந்த notes பகுதியில், parser-ஆல் கண்டறிய முடியாத சூழல் தகவல்களை நீங்கள் குறித்து வைத்துக்கொள்ளலாம்.

இரண்டாவது graft/.graph/wiring.json ஆகும்; இது tree-sitter பிரித்தெடுக்கும் per-symbol structural graph ஆகும்: இதில் definitions, references மற்றும் அவற்றுக்கு இடையேயான call edges ஆகியவை அடங்கும்.

இந்த பிரிப்பு முக்கியமானது, ஏனெனில் இதில் ஒரு பகுதிக்கு மட்டுமே model தேவைப்படுகிறது. graft build என்பது முற்றிலும் tree-sitter-ஐ சார்ந்தது; இது ஒருபோதும் LLM-ஐ (large language model) அழைப்பதில்லை. எனவே, இது deterministic தன்மையுடையது மற்றும் இதற்கு எந்த செலவும் இல்லை. graft build --deep என்பது எழுதப்பட்ட சுருக்கங்களையும் per-symbol cruxes-களையும் சேர்க்கிறது; இவை model அழைப்புகளை உள்ளடக்கியவை என்பதால், அவற்றுக்கு நீங்கள் கட்டணம் செலுத்த வேண்டியிருக்கும்.

Language support அடுக்குமுறையில் (tiered) பிரிக்கப்பட்டுள்ளது; ஒரு call graph-ஐ எவ்வளவு தூரம் நம்பலாம் என்பதை இந்த அடுக்கு தீர்மானிக்கிறது. TypeScript, JavaScript, Python, Go மற்றும் Java ஆகிய மொழிகளுக்கு scope-ஐ உணர்ந்த cross-file resolution வசதி உள்ளது. Rust, C, C++, C#, Ruby, PHP, Kotlin, Scala, Swift, Elixir, Solidity, OCaml, Zig மற்றும் Dart ஆகிய மொழிகளுக்கு symbols மற்றும் generic call edges வசதி உள்ளது. இதன் பொருள், ஒரு edge என்பது resolved reference-ஆக இல்லாமல், வெறும் name match-ஆக இருக்கலாம். Compiler-grade edges வசதியை --lsp மற்றும் rust-analyzer அல்லது gopls போன்ற language server மூலம் நீங்கள் விருப்பத்தேர்வாக (opt-in) பெற்றுக்கொள்ளலாம்.

Graft-ஐ நிறுவுதல் மற்றும் அதன் பதிப்பைப் பூட்டுதல் (Pinning)

Graft இயங்க Node.js 20 அல்லது அதற்குப் பிந்தைய பதிப்பு தேவை. இது MIT உரிமம் பெற்றது. ஆகஸ்ட் 2026 நிலவரப்படி, இதன் தற்போதைய வெளியீடு 0.10.1 ஆகும். இதன் முதல் பதிப்பான 0.1.0, ஜூலை 2026-ல் வெளியிடப்பட்டது. இது ஒரு புதிய மென்பொருள் என்பதால் கவனத்துடன் கையாளவும்.

npm install -g @nanonets/graft@0.10.1
npm ls -g @nanonets/graft

npm ls -g கட்டளையை இயக்கும்போது @nanonets/graft@0.10.1 என்று காட்ட வேண்டும். அந்தப் பதிப்பைத் திட்டமிட்டுப் பூட்டி வைக்கவும் (Pin). வெறும் npm install -g @nanonets/graft கட்டளையை இயக்கினால், அது இயக்கும் நேரத்தில் உள்ள latest குறிச்சொல்லை (tag) எடுத்துக்கொள்ளும். மாதத்திற்குப் பல சிறிய வெளியீடுகளைக் கொண்ட ஒரு திட்டத்தில், நீங்கள் செவ்வாய்க்கிழமை பயன்படுத்தும் கருவியும், உங்கள் சக ஊழியர் திங்கட்கிழமை நிறுவிய கருவியும் வெவ்வேறாக இருக்க வாய்ப்புள்ளது. பதிப்பைப் பூட்டி வைப்பதன் மூலம், CLI flags மற்றும் graph format அனைவருக்கும் ஒரே மாதிரியாக இருக்கும். எனவே, நீங்கள் விரும்பும் போது மட்டும் பதிப்பை மேம்படுத்திக்கொள்ளலாம்.

பின்பு, உங்களுக்குச் சொந்தமான ஒரு repository-உடன் இதை இணைக்கவும்:

cd /path/to/your/repo
graft init --dry-run
graft init

graft init கட்டளையை இயக்கும்போது, எந்த coding agent-ஐ இணைக்க வேண்டும் என்று கேட்கும், அதன் பிறகு graph-ஐ உருவாக்கும். முதலில் --dry-run கட்டளையை இயக்கி, அது மாற்றப்போகும் கோப்புகளின் பட்டியலைப் படிக்கவும்; ஏனெனில் அவற்றில் சில கோப்புகள் repository-க்கு வெளியே இருக்கலாம். graft init என்பது idempotent தன்மை கொண்டது, இது ஏற்கனவே உள்ள configuration-களை மேலெழுதாது (overwrite). எனவே, இதை இரண்டாவது முறை இயக்குவது பாதுகாப்பானது.

ஆகஸ்ட் 2026 நிலவரப்படி, இந்த இணைப்பு Claude Code, Cursor, Codex, GitHub Copilot, Google Gemini, Kiro, Windsurf மற்றும் AdaL ஆகியவற்றை உள்ளடக்கியது. Claude Code-க்கு மிக ஆழமான ஒருங்கிணைப்பு கிடைக்கிறது: ஒரு MCP server entry, graph-ன் அளவு மற்றும் அதன் தற்போதைய நிலையை (staleness) காட்டும் statusline, graph-ஐ மீண்டும் உருவாக்கும் post-edit hooks, மற்றும் .claude/-ன் கீழ் ஒரு skill file. மற்றவற்றுக்கு, இந்தத் tools இருப்பதை agent-க்குத் தெரிவிக்கும் ஒரு instruction அல்லது rule file மட்டுமே கிடைக்கும். எனவே, "Supported" என்பது Graft அந்த இணைப்பை உருவாக்குகிறது என்று பொருள். ஒரு agent தனது சொந்த rules file-ஐப் புறக்கணித்தால், அது இந்த வரைபடத்தையும் (map) புறக்கணிக்கும். இதுதான் agents ignore the instructions you write for them என்பதற்கான பொதுவான காரணம், இது இங்கும் பொருந்தும்.

உங்கள் repository-ல் எவை சேரும், எவை git-ல் இருக்கக்கூடாது

graft init-க்கு பிறகு, இவற்றை எதிர்பார்க்கலாம்:

• graft/: markdown node graph மற்றும் graft/.graph/wiring.json. இவை உங்களுக்காக .gitignore-ல் சேர்க்கப்படும்.
• .mcp.json: graft MCP server-ஐ பதிவு செய்கிறது, இதனால் Claude Code அதைத் தொடங்கும்.
• .claude/settings.json: அந்தந்த இடத்திலேயே இணைக்கப்பட்டு, statusline மற்றும் post-edit hooks-ஐ சேர்க்கிறது.
• AGENTS.md, GEMINI.md, .github/copilot-instructions.md, .cursor/rules/graft.mdc, .kiro/steering/graft.md, .windsurf/rules/graft.md மற்றும் .adal/skills/graft/SKILL.md: நீங்கள் தேர்ந்தெடுத்த agents-க்கு பொருந்தும் கோப்புகளில் marker-fenced பிரிவுகள் சேர்க்கப்படும்.
• ~/.codex/config.toml, ~/.codex/hooks.json மற்றும் ~/.codex/hooks/graft/graft-hooks.cjs: இவை machine-wide அமைப்புகள், நீங்கள் Codex-ஐ தேர்ந்தெடுக்கும்போது மட்டுமே எழுதப்படும். graft init --no-global இவற்றைத் தவிர்க்கும், மற்றும் graft init --no-hooks hook shim-ஐ மட்டும் தனியாகத் தவிர்க்கும்.

இந்த graph ஒரு cache, node_modules போன்றது. இதை commit செய்ய வேண்டாம். இது சில நொடிகளில் code-லிருந்து மீண்டும் உருவாக்கப்படும், ஒவ்வொரு மாற்றத்தின் போதும் இது மாறும். இதை commit செய்தால், ஒரு வரி மாற்றத்திற்கு பல நூறு கோப்புகள் diff-ல் தோன்றும், அதை யாரும் சரிபார்க்க முடியாது. அதற்குப் பதிலாக wiring-ஐ commit செய்யுங்கள், அதில் AGENTS.md மற்றும் .mcp.json அடங்கும். உங்கள் குழு உறுப்பினர் repository-ஐ clone செய்து, graft build-ஐ இயக்கினால், அவர்களுக்குத் தேவையான local graph கிடைத்துவிடும்.

உங்கள் முதல் commit-க்கு முன், ignore rule சரியாகச் சேர்க்கப்பட்டுள்ளதா எனச் சரிபார்க்கவும்:

grep -n graft .gitignore
git status --short

grep கட்டளை graft/ அடங்கிய வரியை அச்சிட வேண்டும், மேலும் git status --short கட்டளை graft/-ன் கீழ் எதையும் காட்டக்கூடாது. graft/-ன் கீழ் உள்ள கோப்புகள் அந்த output-ல் தெரிந்தால், ignore entry விடுபட்டுள்ளது அல்லது வேறு எங்காவது override செய்யப்பட்டுள்ளது என்று அர்த்தம். commit செய்வதற்கு முன்பே இதைச் சரிசெய்யவும், ஏனெனில் ஒரு கோப்பு git-ல் சேர்க்கப்பட்ட பிறகு, அதை git தொடர்ந்து கண்காணிக்கும். பிற்காலத்தில் செய்யப்படும் .gitignore மாற்றம் அதை untrack செய்யாது.

நீங்கள் MCP server-ஐ கைமுறையாகப் பதிவு செய்ய விரும்பினால், அல்லது நீங்கள் நிறுவிய அதே version-ஐ pin செய்ய விரும்பினால், அந்த entry சிறியது:

{
  "mcpServers": {
    "graft": {
      "command": "npx",
      "args": ["-y", "@nanonets/graft@0.10.1", "mcp"]
    }
  }
}

grep-க்கு மாற்றாக உங்கள் agent பயன்படுத்தும் retrieval கருவிகள்

Graft, MCP வழியாக ஆறு கருவிகளை வழங்குகிறது. graft_find_code, ஒரு பணி விளக்கத்திற்கான தரவரிசைப்படுத்தப்பட்ட (ranked) nodes-களை, கோப்பு மற்றும் வரி எண்ணுடன் வழங்குகிறது. graft_file_api, ஒரு கோப்பில் உள்ள அனைத்து signature-களையும், அதன் body பகுதிகள் இன்றி வழங்குகிறது. graft_trace_calls, callers அல்லது callees-களை பல நிலைகள் ஆழத்திற்குச் சென்று ஆராய்கிறது. graft_find_all, regex மூலம் தேடப்பட்ட முடிவுகளை symbol அடிப்படையில் தொகுத்து வழங்குகிறது. graft_repo_map, அறிமுகமில்லாத ஒரு repository-ஐ மேலோட்டமாகப் பார்க்க உதவுகிறது. graft_check_freshness, graph தற்போதைய code-உடன் ஒத்துப்போகிறதா என்பதைத் தெரிவிக்கிறது.

ஒவ்வொரு கருவிக்கும் ஒரு CLI இணையான கருவி உள்ளது; உங்கள் agent-க்கு உண்மையில் என்ன தரவுகள் வழங்கப்படுகின்றன என்பதை இதன் மூலம் நீங்கள் சரிபார்க்கலாம்:

graft map .
graft ask "where do we validate the refresh token"
graft skeleton src/auth/session.ts
graft callers validateRefreshToken
graft callers validateRefreshToken --direction out
graft grep "refresh_token" --json

graft ask, கோப்பு உள்ளடக்கங்களுக்குப் பதிலாக file:line குறிப்புகளைக் கொண்ட தரவரிசைப்படுத்தப்பட்ட nodes-களை அச்சிட வேண்டும். இதுவே முழுமையான செயல்பாட்டு முறை: agent ஒரு pointer-ஐப் பெற்று அந்த ஒரு கோப்பை மட்டும் திறக்கிறது; சரியான கோப்பைக் கண்டறிய பத்து கோப்புகளை வாசிப்பதற்குப் பதிலாக இது செயல்படுகிறது. நீங்கள் graph-ஐ நீங்களே பார்க்க விரும்பினால், graft viz localhost-ல் ஒரு interactive viewer-ஐத் திறக்கும். முப்பது வினாடிகளில் நீங்கள் பதிலளிக்கக்கூடிய ஒரு கேள்விக்கு graft ask பயனுள்ள முடிவுகளைத் தரவில்லை என்றால், graph காலாவதியாகிவிட்டது அல்லது உங்கள் programming language 'broad tier'-ல் உள்ளது என்று அர்த்தம்; இத்தகைய சூழலில் map உங்கள் agent-க்கும் உதவாது.

கவனிக்கத் தவறக்கூடிய ஒரு செலவு உள்ளது. ஒவ்வொரு request-ன் system prompt-லும் ஆறு கருவி வரையறைகள் (tool definitions) முழு session-க்கும் சேர்க்கப்படுகின்றன. agent அந்த map-ஐப் பயன்படுத்தினாலும் சரி, பயன்படுத்தாவிட்டாலும் சரி, இதற்கான கட்டணத்தை நீங்கள் செலுத்த வேண்டும். context-க்குள் அடங்கக்கூடிய சிறிய repository-களில், இந்த நிலையான கட்டணம், அது சேமிக்கும் தேடல் நேரத்தை விட அதிகமாக இருக்கலாம்.

குறியீடு மாறும்போது வரைபடத்திற்கு என்ன நடக்கும்

கட்டமைப்பு ரீதியான புதுப்பித்தல் (Structural refresh) செலவு குறைவானது மற்றும் தானியங்கி முறையில் நடக்கும். Graft, git-க்கு பதிலாக உங்கள் working tree-ஐ வாசிக்கிறது. எனவே, நீங்கள் commit செய்யாத மாற்றம் மற்றும் staged செய்த மாற்றம் ஆகிய இரண்டும் அதற்கு சமமாகத் தெரியும். ஒரு query, stat மாறிய கோப்புகளை மட்டுமே மீண்டும் parse செய்யும். திட்ட ஆவணங்களின்படி, இதற்கு சுமார் 3 ms கூடுதல் நேரம் மட்டுமே தேவைப்படும். மேலும், ஒரு turn-end rebuild, குறியீடு நகர்த்தப்பட்ட கோப்புகளை மட்டுமே கையாளும். வட்டில் உள்ள வரைபடத்திலிருந்து மீண்டும் parse செய்யாமல் பதிலைப் பெற, GRAFT_NO_REFRESH=1-ஐ அமைக்கவும் அல்லது --no-refresh-ஐப் பயன்படுத்தவும். Graft-ஐ மேம்படுத்திய பிறகு, அனைத்தையும் முழுமையாக மீண்டும் parse செய்ய --no-reuse-ஐப் பயன்படுத்தவும்.

மாதிரியால் எழுதப்பட்ட பகுதி (model-written half) மாறுபட்ட முறையில் செயல்படும், இதுவே அமைதியாகப் பிழைகளை ஏற்படுத்தும் பகுதியாகும். சுருக்கங்கள் (summaries) மற்றும் முக்கியக் குறிப்புகள் (cruxes) cache செய்யப்படுகின்றன. ஒவ்வொரு node-ம் அதன் source-களின் content hash-ஐப் பதிவு செய்கிறது. எனவே, ஒரு source file மாறும்போது, அந்த node தற்போதைய நிலையில் இருப்பதாகக் காட்டப்படாமல், stale (பழையது) என அடையாளப்படுத்தப்படும். ஏதேனும் ஒரு செயல்பாடு அதைச் சரிபார்த்தால் மட்டுமே இந்த flag உதவும். graft build --deep மூலம் புதுப்பிக்கவும், இது மீண்டும் model tokens-ஐப் பயன்படுத்தும்.

Staleness-ஐத் தெரிவுபடுத்தவும்:

graft check .
echo $?

Exit status 0 என்பது வரைபடம் குறியீட்டுடன் ஒத்துப்போவதைக் குறிக்கிறது. Exit status 1 என்பது முரண்பாட்டைக் (drift) குறிக்கிறது. இதை ஒரு pre-push hook-ல் அல்லது CI-ல் உள்ள branch-ல் இயக்கவும். அப்போதுதான், மார்ச் மாதம் மாற்றியமைக்கப்பட்ட குறியீட்டைப் பற்றி, ஆறு மாதங்களுக்கு முந்தைய வரைபடம் தவறான பதிலைத் தராது.

வெளியிடப்பட்ட benchmark எண்களை கவனமாகப் படிக்கவும்

Graft-ன் முக்கிய கூற்று "4 மடங்கு வரை மலிவானது மற்றும் 3 மடங்கு வேகமானது, துல்லியத்தில் எந்த இழப்பும் இல்லை அல்லது மேம்பட்ட துல்லியம்" என்பதாகும். இவை திட்டத்தின் சொந்த README-ல் வெளியிடப்பட்ட benchmark முடிவுகளிலிருந்து பெறப்பட்டவை. அது முழுமையாகப் புகாரளிக்கும் இரண்டு சோதனைகள் இங்கே உள்ளன.

[
  {
    "label": "Controlled sweep",
    "run_count": 162,
    "token_saving_pct": 42,
    "tool_call_saving_pct": 46,
    "correctness_pct": 93,
    "baseline_correctness_pct": 93
  },
  {
    "label": "SWE-bench Verified",
    "run_count": 50,
    "token_saving_pct": 23,
    "tool_call_saving_pct": 25,
    "correctness_pct": 66,
    "baseline_correctness_pct": 54
  }
]

கட்டுப்படுத்தப்பட்ட sweep என்பது 162 சோதனைகளை உள்ளடக்கியது. இது இரண்டு repositories-ல் மேற்கொள்ளப்பட்டது, அதில் ஒன்று Graft-ன் சொந்த repository ஆகும். ஒவ்வொரு பணிக்கும் மூன்று முறை சோதனைகள் செய்யப்பட்டன. இது 42% குறைவான tokens-ஐயும், 46% குறைவான tool calls-ஐயும் பயன்படுத்துவதாகக் குறிப்பிடுகிறது. SWE-bench Verified சோதனையானது 50 instances-ஐக் கொண்டது. இதில் இரண்டு தரப்பிலும் ஒரே மாதிரியான model பயன்படுத்தப்பட்டது. இது குறைவான சேமிப்பையே காட்டுகிறது: 23% tokens மற்றும் 25% tool calls. மூன்றாவது சோதனையில், ஐந்து merged PocketBase pull requests-ஐ மீண்டும் உருவாக்கியதில், baseline-ன் 13.91 அமெரிக்க டாலர்களுக்கு எதிராக 11.02 அமெரிக்க டாலர்கள் செலவானது.

இவை அனைத்தையும் ஒரு vendor benchmark-ஆகவே கருத வேண்டும். இவை உங்களுக்குத் தரும் தகவல்களை இரண்டு விஷயங்கள் கட்டுப்படுத்துகின்றன. கட்டுப்படுத்தப்பட்ட sweep-ல் Graft-ன் சொந்த repository-ம் அடங்கும்; அதன் ஆசிரியர்கள் இந்த codebase-ஐ வைத்தே tool-ஐ மேம்படுத்தியுள்ளனர். SWE-bench Verified என்பது நன்கு அறியப்பட்ட open-source Python திட்டங்களின் சிக்கல்களைக் கொண்ட ஒரு பொதுவான dataset ஆகும். பொதுவான datasets-ல் கருவிகள் மேம்படுத்தப்படுவது இயல்பானது, அது திட்டமிட்டு செய்யப்பட்டதா இல்லையா என்பது முக்கியமல்ல. இவை எதுவும் உங்கள் சொந்த monorepo-வைப் பற்றிய முடிவுகள் அல்ல; உங்கள் repository-க்கு என்று தனித்துவமான பெயரிடும் முறைகளும், பயன்படுத்தப்படாத code-களும் இருக்கலாம்.

துல்லியத்தன்மையை (correctness) மீண்டும் ஒருமுறை கவனிக்க வேண்டும். கட்டுப்படுத்தப்பட்ட sweep-ல் அது மாறவில்லை: map-உடன் 93% மற்றும் அது இல்லாமல் 93%. SWE-bench Verified-ல் மட்டுமே 54%-லிருந்து 66%-ஆக உயர்வு காணப்படுகிறது. உங்கள் token செலவைக் குறைத்து, தரத்தை அப்படியே வைத்திருக்கும் ஒரு கருவி நல்ல லாபகரமானதே. ஆனால், SWE-bench-ன் துல்லியத்தன்மை முடிவையும், sweep-ன் token சேமிப்பு முடிவையும் ஒன்றாக இணைத்து ஒரே கூற்றாகக் குறிப்பிட வேண்டாம்.

எந்தவொரு தகவலையும் நம்புவதற்கு முன் உங்கள் சொந்த token delta-வை அளவிடுங்கள்

உங்கள் repository-லிருந்து கிடைக்கும் எண் மட்டுமே முக்கியமானது. இந்த முறைக்கு ஒரு மதிய நேரம் தேவைப்படும்.

துல்லியமாக மீண்டும் செய்யக்கூடிய ஒரு பணியைத் தேர்வு செய்யுங்கள். ஒரு திருத்தத்தை விட ஒரு கேள்வி சிறந்தது, ஏனெனில் திருத்தம் repository-ஐ மாற்றும், இரண்டாவது முறை செய்யப்படும் சோதனை அதே சோதனையாக இருக்காது. "login route-ல் rate limit-ஐ எந்த module அமல்படுத்துகிறது" என்பது சரியான வடிவம்.

Telemetry-ஐ இயக்கி, அதை உங்கள் terminal-க்கு அனுப்புங்கள்:

export CLAUDE_CODE_ENABLE_TELEMETRY=1
export OTEL_METRICS_EXPORTER=console
claude

Console exporter, metric பதிவுகளைச் சேகரிக்கும்போது அவற்றை அச்சிடும். உங்களுக்குத் தேவையானது claude_code.token.usage ஆகும், இது input, output, cacheRead அல்லது cacheCreation ஆகியவற்றுள் ஏதேனும் ஒன்றின் type பண்பைக் கொண்டிருக்கும். கோப்பின் உள்ளடக்கங்கள் அங்குதான் சேர்வதால், orientation என்பது input மற்றும் cacheRead ஆகியவற்றில் தெரியும். அந்த இரண்டையும் கூட்டிக்கொள்ளுங்கள்.

வரைபடம் (map) இணைக்கப்பட்ட நிலையில், ஒவ்வொரு முறையும் புதிய session-ல் அந்தப் பணியை மூன்று முறை செய்யுங்கள். பிறகு .mcp.json-லிருந்து graft entry-ஐ நீக்கிவிட்டு, மீண்டும் மூன்று முறை செய்யுங்கள். ஒற்றை ஓட்டங்களை விட median மதிப்புகளை ஒப்பிடுங்கள், ஏனெனில் agent ஓட்டங்கள் பெருமளவில் மாறுபடும், ஒரு துரதிர்ஷ்டவசமான ஓட்டம் உண்மையை மாற்றிச் சொல்லக்கூடும். Tool-call எண்ணிக்கையையும் பதிவு செய்யுங்கள்: tool calls என்பது செயல்முறை, tokens என்பது அதன் விளைவு; எனவே tool calls குறையாமல் token சேமிப்பு ஏற்பட்டால், ஏதோ ஒன்று மாறியிருக்கிறது என்று அர்த்தம்.

பிறகு, benchmark காட்டாத செலவுகளைக் கழித்துவிடுங்கள். graft build --deep ஒவ்வொரு முழு refresh-க்கும் model tokens-ஐச் செலவிடுகிறது. ஆறு tool schemas-ம் ஒவ்வொரு கோரிக்கையிலும் உடன் செல்கின்றன. உங்கள் agents நீங்கள் வாடகைக்கு எடுத்த server-ல் இயங்கினால், agent செலவுக்கு ஒரு உச்ச வரம்பை நிர்ணயிப்பது இதை ஒரு எதிர்பாராத செலவிலிருந்து திட்டமிடப்பட்ட வரவுசெலவாக மாற்றும், மேலும் coding agent-ன் telemetry உண்மையில் எதைப் புகாரளிக்கிறது என்பது, exporter-ஐ இயக்கிய பிறகு கணினியிலிருந்து வெளியேறுவது என்ன என்பதை விளக்குகிறது.

codebase map எப்போது பயனளிக்காது?

• Repository ஏற்கனவே context-க்குள் அடங்கிவிடுகிறது. ஒரு சிறிய service-க்கு map தேவையில்லை, ஆனால் ஒவ்வொரு request-க்கும் நீங்கள் ஆறு tool schemas-க்கான கட்டணத்தைச் செலுத்த வேண்டியிருக்கும். உங்கள் agent இன்று ஒன்று அல்லது இரண்டு tool calls-லேயே எந்தக் கோப்பையும் கண்டறிந்தால், map-ஐத் தவிர்க்கவும்.
• உங்கள் language broad tier-ல் உள்ளது. பொதுவான call edges இருப்பதால், graft callers ஒரு caller-ஐத் தவறவிடலாம் அல்லது பெயர் மோதலால் (name collision) தவறான ஒன்றைக் காட்டலாம். blast radius-ஐ நம்பும் முன் graft grep மூலம் உறுதிப்படுத்தவும்.
• Graph பழையதாகிவிட்டது, யாரும் கவனிக்கவில்லை. drift ஏற்படும்போது graft check 1 என்ற exit code-ஐத் தரும், ஆனால் அதை யாராவது இயக்கினால் மட்டுமே இது பயனுள்ளது. இது ஒரு பழக்கமாக இருக்கக்கூடாது, ஒரு hook அல்லது CI step-ஆக இருக்க வேண்டும்.
• Monorepo-விற்கு scoping தேவை. ஒரு single-git monorepo, workspace file, go.mod, pyproject.toml அல்லது Cargo.toml மூலம் தானாகவே பிரிக்கப்படுகிறது, மேலும் graft ask "..." --in services/billing/ ஒரு query-ஐ ஒரு sub-project-க்குள் சுருக்குகிறது. ஒவ்வொரு package-க்கும் தனித்தனி AGENTS.md கோப்புகள் வைக்கும் அதே அணுகுமுறையே map-க்கும் பொருந்தும்.
• Agent wiring-ஐப் புறக்கணிக்கிறது. map பயன்படுத்தப்படுகிறதா என்பதை முடிவு செய்வதற்கு முன், ஒரு உண்மையான session-ல் tool calls-ஐக் கவனிக்கவும். ஒரு agent இன்னும் grep-ஐ இயக்குகிறது என்றால், அது rules கோப்பை வாசிக்கவில்லை என்று அர்த்தம்.

FAQ

graft/ கோப்புறையை git-ல் commit செய்ய வேண்டுமா?

கூடாது. graft build, graft/-ஐ உங்கள் .gitignore-ல் தானாகவே சேர்க்கிறது. ஏனெனில், இந்த வரைபடம் (graph) என்பது node_modules போன்ற மீண்டும் உருவாக்கக்கூடிய ஒரு cache ஆகும். இது ஒவ்வொரு திருத்தத்தின் போதும் மாறுவதால், இதை commit செய்வது நூற்றுக்கணக்கான உருவாக்கப்படும் கோப்புகளுக்குள் உண்மையான diff-களை மறைத்துவிடும். வரைபடம் இருப்பதை முகவர்களுக்கு (agents) உணர்த்தும் இணைப்புகளை மட்டும் commit செய்யுங்கள் (அவற்றில் AGENTS.md மற்றும் .mcp.json அடங்கும்). ஒவ்வொரு குழு உறுப்பினரும் graft build-ஐ உள்ளூர் அளவில் இயக்கட்டும். உங்கள் முதல் commit-க்கு முன்பே grep -n graft .gitignore மற்றும் git status --short மூலம் சரிபார்க்கவும். ஏனெனில், ஒருமுறை சேர்க்கப்பட்ட கோப்பை git தொடர்ந்து கண்காணிக்கும்; அதன் பிறகு .gitignore-ஐத் திருத்தினாலும் அது கண்காணிப்பிலிருந்து நீங்காது.

Graft-ஐ இயக்க பணம் செலவாகுமா?

அதன் கட்டமைப்புப் பகுதிக்கு (structural half) செலவாகாது. graft build, graft ask, graft check மற்றும் ஆறு MCP retrieval கருவிகள் ஆகியவை tree-sitter செயல்பாடுகள் ஆகும்; இவை எந்தவொரு model-ஐயும் அழைப்பதில்லை. graft build --deep என்பது கட்டணப் பகுதி: இது LLM மூலம் எளிய ஆங்கிலச் சுருக்கங்களையும், ஒவ்வொரு குறியீட்டிற்கான முக்கிய அம்சங்களையும் (cruxes) உருவாக்குகிறது. இதற்கு GRAFT_PROVIDER, GRAFT_API_KEY, GRAFT_MODEL மற்றும் OpenAI-இணக்கமான எந்தவொரு endpoint-க்கும் GRAFT_BASE_URL ஆகியவற்றைப் பயன்படுத்தி உள்ளமைக்க வேண்டும். நீங்கள் Graft-ஐ அதன் கட்டமைப்புடன் மட்டும் இயக்கலாம், வரைபடத்திற்காக எந்தவொரு token-ஐயும் செலவிட வேண்டியதில்லை.

ஒரு codebase வரைபடம் எனது repository-ல் எவ்வளவு சேமிப்பைத் தரும்?

அளவிடாமல் எவராலும் இதைக் கூற முடியாது. இந்தத் திட்டம் அதன் சொந்த 162-முறை சோதனையில் 42% குறைவான token-களையும், SWE-bench Verified-ல் 23% குறைவான token-களையும் பதிவு செய்துள்ளது. இவை இரண்டும் வரைபடம் இல்லாத baseline-உடன் ஒப்பிடப்பட்டவை. இவை விற்பனையாளர் அளவீடுகள்; இதில் ஒன்று Graft-ன் சொந்த repository-ல் பகுதியளவு இயக்கப்பட்டது, மேலும் இவை உங்கள் தனிப்பட்ட குறியீட்டை விவரிக்கவில்லை. வரைபடத்துடன் மூன்று முறையும், வரைபடம் இல்லாமலும் மூன்று முறை ஒரே கேள்வியை இயக்கி, CLAUDE_CODE_ENABLE_TELEMETRY=1 மற்றும் OTEL_METRICS_EXPORTER=console ஆகியவற்றை அமைத்து, input மற்றும் cacheRead வகைகளுக்கான claude_code.token.usage-ன் median மதிப்பை ஒப்பிட்டுப் பார்க்கவும்.

நான் refactor செய்யும்போது வரைபடத்திற்கு என்னவாகும்?

கட்டமைப்பு தன்னைத்தானே மீண்டும் பகுப்பாய்வு (re-parse) செய்துகொள்ளும். Graft working tree-ஐ ஆய்வு செய்து, மாறிய கோப்புகளை மட்டும் மீண்டும் பகுப்பாய்வு செய்கிறது. எனவே, ஒரு பெயர் மாற்றம் அடுத்த query-ல் சுமார் 3 ms கூடுதல் நேரத்தில் கண்டறியப்படும். இது git வரலாற்றை விட கோப்புகளை நேரடியாக வாசிப்பதால், commit செய்யப்படாத மாற்றங்களையும் இது கவனிக்கிறது. model-ஆல் எழுதப்பட்ட சுருக்கங்கள் மட்டுமே காலாவதியாகின்றன: ஒவ்வொரு node-ம் அதன் ஆதாரங்களின் content hash-ஐச் சேமிக்கிறது. ஆதாரம் மாறினால், அந்த node-ஐ மீண்டும் எழுதுவதற்குப் பதிலாக, அது காலாவதியானதாகக் குறிக்கப்படும். மாற்றங்களைக் காண graft check .-ஐ இயக்கவும், பின்னர் எழுதப்பட்ட பகுதியை மீண்டும் புதுப்பிக்க graft build --deep-ஐ இயக்கவும்.

இன்று எந்தெந்த coding agents-கள் Graft-ஐப் பயன்படுத்தலாம்?

ஆகஸ்ட் 2026 நிலவரப்படி, graft init ஆனது Claude Code, Cursor, Codex, GitHub Copilot, Google Gemini, Kiro, Windsurf மற்றும் AdaL ஆகியவற்றை இணைக்கிறது. Claude Code அதிகப்படியான வசதிகளைப் பெறுகிறது: .mcp.json-ல் ஒரு MCP server entry, statusline, post-edit hooks மற்றும் .claude/-ன் கீழ் ஒரு skill கோப்பு. Codex ஒரு AGENTS.md பகுதியையும், ~/.codex/-ன் கீழ் கணினி அளவிலான entries-களையும் பெறுகிறது (இதை graft init --no-global தவிர்க்கிறது). மற்றவை ஒரு rules அல்லது steering கோப்பைப் பெறுகின்றன. வேறு எந்தவொரு MCP client-ம் npx -y @nanonets/graft@0.10.1 mcp கட்டளையைப் பதிவு செய்வதன் மூலம் நேரடியாக இந்த server-ஐப் பயன்படுத்தலாம்.