200 लाइनों के कोड में Claude Code को लागू करने का तरीका

• AI coding assistant की मुख्य संरचना कोई जटिल जादू नहीं, बल्कि लगभग 200 लाइनों के सरल Python code से बनी होती है
• सिस्टम LLM के साथ conversation loop पर आधारित होता है, जहाँ LLM tool call का अनुरोध करता है और local code उसे चलाकर परिणाम वापस भेजता है
• ज़रूरी बुनियादी tools सिर्फ तीन हैं: फ़ाइल पढ़ना(read), फ़ाइल सूची(list), फ़ाइल संपादित करना(edit); इनके जरिए project को explore करना और code को modify करना संभव है
• LLM tools के signature और description(docstring) के आधार पर यह खुद तय करता है कि कौन-सा tool कब call करना है
• यह संरचना Claude Code जैसे commercial product के core के समान है, और सरल संरचना से भी शक्तिशाली coding agent लागू किया जा सकता है

---

coding agent की बुनियादी अवधारणा

• coding agent, LLM के साथ conversation-आधारित सिस्टम होता है, जो user के निर्देश लेकर tool call के जरिए वास्तविक file operations करता है
  • user “hello world फ़ंक्शन वाला नया फ़ाइल बनाओ” जैसे अनुरोध दर्ज करता है
  • LLM आवश्यक tool call को JSON फ़ॉर्मैट में response करता है
  • प्रोग्राम उस tool को execute करता है और परिणाम फिर LLM को भेजता है
• LLM सीधे file system तक पहुँच नहीं करता, वह सिर्फ अनुरोध करता है, और वास्तविक काम local code संभालता है

आवश्यक तीन tools

• read_file: निर्दिष्ट फ़ाइल की पूरी सामग्री पढ़कर लौटाता है
• list_files: directory के अंदर files और folders की सूची लौटाता है
• edit_file: मौजूदा string को नई string से बदलता है, या old_str खाली होने पर नया फ़ाइल बनाता है
  • बदलने वाली string न मिले तो “old_str not found” लौटाता है
• सिर्फ इन तीन tools से ही फ़ाइल बनाना, संशोधित करना और खोजबीन संभव है

tool registration और LLM integration

• सभी tools को TOOL_REGISTRY में नाम और function के साथ register किया जाता है, ताकि LLM उन्हें call कर सके
• हर tool का docstring और signature निकालकर LLM को दिया जाता है
• system prompt, LLM को “उपलब्ध tools की सूची” और “call format” साफ़ तौर पर बताता है
  • tool call को 'tool: TOOL_NAME({JSON_ARGS})' फ़ॉर्मैट तक सीमित रखा जाता है
  • tool execution का परिणाम tool_result(...) रूप में LLM को भेजा जाता है

tool call parsing और LLM response handling

• LLM के response में tool: से शुरू होने वाली पंक्तियाँ खोजकर tool का नाम और arguments(JSON) निकाले जाते हैं
• हर tool चलाने के बाद परिणाम को JSON में serialize करके conversation history में जोड़ा जाता है
• execute_llm_call function, LLM API को call करता है और response text लौटाता है
• run_coding_agent_loop user input लेकर LLM के साथ conversation loop बनाए रखता है
  • अंदरूनी loop तब तक दोहरता है जब तक LLM आगे कोई tool call नहीं माँगता

execution examples और विस्तार की संभावना

• उदाहरण conversation:
  • “hello.py फ़ाइल बनाओ और hello world लागू करो” → edit_file call से नया फ़ाइल बनाया जाता है
  • “hello.py में दो संख्याओं को गुणा करने वाला फ़ंक्शन जोड़ो” → read_file के बाद edit_file call
• लगभग 200 लाइनों के code में पूरा coding assistant लागू किया जा सकता है
• commercial products इसमें आगे error handling, streaming responses, context management, अतिरिक्त tools, approval process जैसी चीज़ें जोड़ते हैं
• मुख्य संरचना वही रहती है: LLM तय करता है और code execute करता है — ऐसा सरल loop

अभ्यास और विस्तार

• पूरा source लगभग 200 लाइनों का है, और दूसरे LLM provider को बदलना या tools जोड़ना जैसे विस्तार संभव हैं
• सरल संरचना के साथ भी शक्तिशाली AI coding agent prototype को सीधे लागू किया जा सकता है

[GN⁺]

Hacker News की राय

• मैं जो चीज़ जोड़ना चाहूँगा, वह है planning
  प्रभावी tool use की कुंजी यह समझने में है कि ये एक dynamic TODO list पर काम करते हैं
  Plan mode उस list को seed करने और यह bootstrap करने का काम करता है कि हर item कब execute होगा
  user interaction उस list को reorder करने के तरीके से काम करता है
  पिछले महीने मैंने यह test किया कि Claude Code CTF समस्याएँ कितनी अच्छी तरह हल करता है, और जब TodoList tool और planning बंद कर दिए, तो performance 1–2 स्तर गिर गई
  संबंधित वीडियो के लिए Breaking Bots: Cheating at Blue Team CTFs with AI Speed Runs देखें
  दिलचस्प बात यह है कि बहुत से लोग सिर्फ़ इस पर ध्यान देते हैं कि “plan mode इस्तेमाल करें या नहीं”, लेकिन TODO list हमेशा active रहती है
  और “smart context management” को सिर्फ़ साधारण TODO items मान लेने वाली पोस्टें देखना थोड़ा हास्यास्पद भी लगता है
  इसे खुद implement करने की कोशिश में production environment में टूट जाने वाले evaluation results की वजह से 1 साल बर्बाद हो जाना भी आम बात है

  • Claude Code के system prompt को extract किए गए gist को देखें, वहाँ TODO iteration के बारे में काफ़ी detail है
    इसे सिर्फ़ reasoning tokens के रूप में जोड़ा जा सकता है, लेकिन वास्तव में इसे explicit single-key storage tool के रूप में implement करना कहीं अधिक predictable और effective है
    language structure को store करने वाले दूसरे tool ideas पर भी यह simple approach काम कर सकती है
  • CLI agents के लिए “working memory” file बनाए रखने का तरीका बहुत अच्छा काम करता है
    Codex को test करते समय मैंने लगभग 10 मिनट specs को organize करके उन्हें change list में बाँटा, फिर उसे file में save कराया, और हर change के बाद plan को review और revise करने का निर्देश दिया
    इससे LLM छोटे goal-oriented tasks पर focused रह सकता है और लगातार prompt input की ज़रूरत भी नहीं रहती
    व्यवहार में इसका असर subagent रखने जैसा होता है
  • मैं भी अक्सर prompt के अंत में “इस task के लिए बहुत granular todo list का उपयोग करो” जोड़ता हूँ
    कभी-कभी आख़िरी todo के रूप में “पूरे काम को फिर से review करो और linter आदि से quality verify करो” भी लिखता हूँ
  • TODO list को अक्सर context के HEAD में फिर से insert किया जाता है ताकि LLM पिछले और अगले steps को पहचान सके
    context compression के दौरान यह session की concise representation के रूप में भी उपयोग होती है
  • साल के अंत तक शायद “How to Code Claude Code in 200 Million Lines of Code” जैसा मज़ाक भी सामने आ जाए

• coding agent का core वास्तव में एक साधारण loop और tool-calling structure है
  लेकिन अगर आप “The Emperor Has No Clothes: How to Code Claude Code in 200 Lines of Code” जैसा लेख लिखने जा रहे हैं, तो Thorsten Ball का How to Build an Agent ज़रूर देखना चाहिए
  उस लेख ने सबसे पहले यह विचार रखा था कि “agent का सार सरल है”
  बेशक, वास्तविकता में TODO और तरह-तरह की scaffolding की ज़रूरत होती है, और Claude Code खुद भी complex settings, plugins और UI features से भरा है
  फिर भी, सिर्फ़ minimal loop से भी इसे bootstrap किया जा सकता है ताकि यह खुद features expand करे
  अगर आप इसका अंदरूनी behavior देखना चाहते हैं, तो claude-trace से LLM और tool calls के बीच interaction trace किया जा सकता है

  • मैंने Claude Code और Codex के local transcripts का analysis करके इसकी internal structure देखी है
    simple loop के अलावा uuid threading, message queue handling, file change snapshots, subagent sidechains जैसे बहुत से complex elements हैं
    इसलिए “200 lines” conceptual रूप से सही हो सकता है, लेकिन actual production level उससे काफ़ी ज़्यादा complex है
    Codex में अभी queuing feature नहीं है, फिर भी वह काफ़ी powerful है
    मैंने Contextify नाम का एक macOS app बनाया है, जो Claude Code और Codex के CLI transcripts को real time में monitor करता है और Total Recall feature के ज़रिए conversation history पर query करने देता है
  • code editing सबसे महत्वपूर्ण हिस्सा है
    Claude models को उनके अपने str replace tool schema पर train किया गया है
    पूरी file को फिर से लिखना inefficient है, इसलिए partial edits ही key हैं
  • कुछ लोगों की प्रतिक्रिया थी, “मुझे लगा यही पोस्ट फिर से repost हुई है”
  • और यह अनुरोध भी आया कि “क्या आप वह simple core loop सीधे दिखा सकते हैं?”

• वास्तव में इसमें और भी कई तत्व हैं
  उदाहरण के लिए, agent कभी-कभी early stopping कर देता है और task को समय से पहले समाप्त मान लेता है
  यह समस्या नए reasoning models से भी हल नहीं होती
  Claude Code इसे हर prompt में TODO inject करके हल करता है, ताकि बचे हुए tasks याद रहें
  HolmesGPT के public repository में तरह-तरह के experiment benchmarks हैं

  • यह सवाल भी पूछा गया कि “early stop होता ही क्यों है?”

• शुरुआत में यह विचार झकझोर देने वाला था कि “LLM को बस tools की list और call format बता दो”
  LLM तो सिर्फ़ text generate करता है, फिर वह tools कैसे call करेगा—ऐसा लगता था, लेकिन जब समझ आया कि यही पूरी बात है, तो वह जादू जैसा लगा

• छुट्टियों के दौरान मैंने Opus के साथ Prolog DSL-आधारित coding agent बनाया था (हालाँकि वह 200 lines से ज़्यादा था)
  हैरानी की बात यह थी कि वह लगभग तुरंत अच्छी तरह काम करने लगा
  लगता है कि latest generation models अब उस stage पर पहुँच गए हैं जहाँ agent harness की अहमियत कम हो गई है
  संबंधित प्रयोग के लिए यह पोस्ट देखें

• एक साल पहले यह लेख काफ़ी सटीक था, लेकिन अब harnesses बहुत आगे बढ़ चुके हैं, इसलिए simple loop model से Claude Code के वास्तविक behavior को समझाना मुश्किल है

  • बेशक आधुनिक harnesses में ज़्यादा features हैं, लेकिन मूल अवधारणा अब भी valid है
    simple agents भी वही model इस्तेमाल करें तो performance gap बहुत बड़ा नहीं होता
    यह कुछ वैसा है जैसे “अपना DB खुद बनाना” tutorial, जो basic B-tree दिखाता है
  • tbench.ai leaderboard के अनुसार complexity performance को थोड़ा बढ़ाती है, लेकिन “Terminus” जैसे simple loop-आधारित systems भी काफ़ी powerful हैं
  • यह भी कहा गया कि “यह लेख जनवरी 2025 में प्रकाशित हुआ था”
  • वास्तव में पिछले 1 साल की प्रगति का बड़ा हिस्सा prompt और tool design को सरल बनाने पर केंद्रित रहा है
    Subagent, MCP, और Skills मध्यम स्तर के तत्व हैं, और context optimization का महत्व मुख्यतः long-running execution में है
  • codex-cli repository का उपयोग करके models का बेहतर analysis किया जा सकता है

• मैं खुद enterprise agent loops बनाता हूँ और हर महीने 1 billion से ज़्यादा tokens process करता हूँ
  simple loop core तो है, लेकिन real-world environment में countless details complexity को विस्फोटक रूप से बढ़ा देती हैं
  उदाहरण के लिए, अगर user बीच में message भेज दे तो loop को कैसे handle करें, Slack जैसे webhook inputs को कैसे synchronize करें,
  approvals, guardrails, asynchronous task processing जैसी बहुत सी चीज़ों पर विचार करना पड़ता है
  सोच रहा हूँ कि इन अनुभवों को ब्लॉग में लिखूँ

• संदर्भ के लिए You Should Write An Agent और How To Build An Agent उपयोगी लेख हैं

• हमारी SWE-bench team ने 100-line open source agent जारी किया है
  उसका नाम mini-swe-agent है, और वह academia तथा industry दोनों में लोकप्रिय है
  agent ecosystem सीखने के लिए यह एक अच्छा starting point है

• 2023 में “LangChain को 100 lines में फिर से implement करना” नाम की एक पोस्ट थी
  मैंने उस पोस्ट को देखकर वास्तव में इसे implement किया और कई projects में इस्तेमाल भी किया

  • इस पर प्रतिक्रिया आई, “अरे, यह तो पहले ही 3 साल पुरानी बात हो गई”