Coding agent कैसे बनाएं

(ghuntley.com)

62 पॉइंट द्वारा GN⁺ 2025-08-25 | 4 टिप्पणियां | WhatsApp पर शेयर करें

2025 में coding agent को खुद बनाना किसी व्यक्तिगत developer के लिए आज़माने लायक सबसे बेहतरीन projects में से एक है
agent सिर्फ 300 lines of code और LLM token loop से चलता है, और इसे बनाकर आप consumer नहीं बल्कि AI producer बनने का मौका पा सकते हैं
इसके बुनियादी components हैं file read, file list, Bash execution, file edit, code search जैसे tools, जिनसे वास्तविक automation features लागू किए जा सकते हैं
model चुनते समय Claude Sonnet, Kimi K2 जैसे agentic models उपयुक्त हैं, और ज़रूरत पड़ने पर GPT जैसे oracle model को tool की तरह जोड़कर उच्च-स्तरीय validation किया जा सकता है
वास्तव में Amp, Cursor, Claude Code, GitHub Copilot जैसे commercial products भी इसी तरह की संरचना पर आधारित हैं

Workshop overview

Geoffrey Huntley द्वारा संचालित यह free workshop, coding agent को खुद बनाने के तरीकों और उसके सिद्धांतों को hands-on तरीके से समझाती है
Roo code, Cline, Amp, Cursor, Windsurf, OpenCode जैसे मौजूदा commercial AI assistants के साथ इसकी संरचना और सिद्धांत की तुलना करते हुए, इसे खुद implement करने का अवसर देती है
इसे बनाने के अनुभव के जरिए आप केवल AI user से आगे बढ़कर AI का उपयोग करके automation tools बनाने वाले developer के रूप में विकसित हो सकते हैं
इसकी मुख्य संरचना लगभग 300 lines के code में LLM tokens को loop के रूप में इस्तेमाल करके agent features बनाने की है
हर tool के primitive functions (read, file list, execute, edit, code search) जोड़ते हुए वास्तविक working examples और code GitHub repository में सार्वजनिक किए गए हैं

Agent क्या है

हाल के समय में "agent" शब्द का व्यापक उपयोग हो रहा है, लेकिन इसका वास्तविक अर्थ और अंदरूनी working principle स्पष्ट नहीं है
agent बनाना आसान होने के साथ, अब केवल AI consumer बने रहने के बजाय कामकाजी automation को आगे बढ़ाने वाले producer के रूप में विकसित होना संभव है
2025 के हिसाब से, जैसे database की बुनियादी अवधारणाएँ (Primary key) ज़रूरी हैं, वैसे ही agent बनाने के सिद्धांत भी अनिवार्य ज्ञान बनते जा रहे हैं
Canva जैसी कंपनियाँ पहले से ही interviews में AI के उपयोग को प्रोत्साहित कर रही हैं, और AI automation capability hiring का मुख्य तत्व बनती जा रही है
अब पीछे रह जाने की वजह AI नहीं, बल्कि self-development के जरिए नए tools न सीखना है

Coding agent के मूल सिद्धांत

coding agent केवल 300 lines of code और LLM token loop से बनता है, और token inputs की पुनरावृत्ति के जरिए काम करता है
concurrent work की अवधारणा महत्वपूर्ण है
- उदाहरण: Zoom meeting के दौरान भी agent parallel में काम कर सकता है, जिससे काम की efficiency काफी बढ़ जाती है
हर LLM agentic नहीं होता
- 'high-safety' (उदा: Anthropic, OpenAI)
- 'low-safety' (उदा: Grok)
- 'oracle' (summary और high-level reasoning में उपयोगी)
- 'agentic' (action bias, तेज़ iteration और tool calling)
developers को हर model की विशेषताओं को समझकर अपने उद्देश्य के अनुसार model चुनना चाहिए
बिना सोचे-समझे context window बढ़ाना performance को खराब कर सकता है, और यह याद रखना चाहिए कि "कम देने पर बेहतर परिणाम मिलते हैं"
- ज़रूरत से ज़्यादा MCP tools register करना भी performance गिराता है
नियम: “Less is more” → सर्वोत्तम performance के लिए सिर्फ उतने ही tools और data को context में रखना चाहिए जितनी आवश्यकता हो

Coding agent बनाने की प्रक्रिया

1. Tool registration और function calling
- उदाहरण के लिए, LLM में weather lookup tool register किया जा सकता है ताकि उपयुक्त स्थिति में वह function call format में प्रतिक्रिया दे सके
- MCP(Model Context Protocol) किसी "function information banner" जैसा है, और केवल function description register करने से भी automatic calling संभव हो जाती है
2. Primitive tools के मुख्य functions
- File read(ReadFile): path देने पर file content को context में पढ़कर लाता है
- File list(ListFiles): directory के अंदर files और folders की सूची देता है
- Command execution(Bash): LLM system shell commands चलाकर उनका result लौटाता है
- File edit(Edit): चुनी हुई file को create या modify करने की प्रक्रिया को automate करता है
- Code search(CodeSearch): pattern, keyword या function name के आधार पर पूरे codebase में तेज़ी से search करता है (ripgrep का उपयोग)
3. Examples और result flow
- हर tool को LLM में integrate करके सिर्फ natural language prompt से लगातार tasks (जैसे FizzBuzz code generation → run verification, directory exploration → content analysis) automate किए जा सकते हैं
- tool functions user input या scenario के अनुसार क्रम से call होते हैं और उनके results loop के भीतर बार-बार लौटाए जाते हैं
- agent का मुख्य operation sequence: user input → tool call की ज़रूरत का निर्णय → tool execution → result को context में assign करना → repeat

विस्तार की संभावना और open source

वर्तमान में ज़्यादातर coding agents ripgrep जैसे मौजूदा open source tools पर आधारित हैं
GitHub पर SST Open Code, mini-swe-agent जैसे सिर्फ 100 lines में बने सरल लेकिन शक्तिशाली agent projects उपलब्ध हैं, जिनसे performance और structure का संदर्भ लिया जा सकता है
developers को केवल existing products की तुलना करने के बजाय खुद बनाकर उसके सिद्धांतों को समझने और इस्तेमाल करने की सलाह दी जाती है
वास्तविक काम और automation में लागू करने पर, अपने agent बनाना और उन्हें संगठन के भीतर फैलाना प्रतिस्पर्धात्मक बढ़त में बदल सकता है

निष्कर्ष और संकेत

coding agent कोई अत्यधिक जटिल तकनीक नहीं, बल्कि सरल loop structure और tools के संयोजन से बना होता है
coding agent बनाने का मूल है structure की समझ और तेज़ execution की क्षमता, और इसे खुद बनाने का अनुभव AI तकनीक के बदलावों का सक्रिय रूप से सामना करने में मदद करता है
महत्वपूर्ण बात AI स्वयं नहीं, बल्कि लगातार self-development और tool-building capability में निवेश है, जो इस समय व्यक्तिगत विकास की सबसे अहम रणनीति है
“खतरा यह नहीं कि AI आपका काम छीन लेगा, बल्कि यह कि आपका सहकर्मी agent से लैस होकर automation करेगा और आपसे तेज़ काम करेगा”

4 टिप्पणियां

GN⁺ 2025-08-25

Hacker News राय

हमारी Princeton SWE-bench टीम ने लगभग 100 लाइनों के कोड से ऐसा एजेंट बनाया जिसने SWE-bench पर अच्छे नतीजे दिए; दिलचस्पी हो तो इसे देखना अच्छा रहेगा: mini-swe-agent
- यह सच में काफ़ी सरल संरचना है, यह देखकर हैरानी हुई; यह जानकारी साझा करने के लिए धन्यवाद।
  पूरा कोडअसल में इन prompts पर चलता है: एजेंट बेस प्रॉम्प्ट source code
```
Your task: {{task}}. Please reply
with a single shell command in
triple backticks.

To finish, the first line of the
output of the shell command must be
'COMPLETE_TASK_AND_SUBMIT_FINAL_OUTPUT'.
```
- एजेंट sample prompts में “1. कोडबेस में संबंधित फ़ाइलें खोजो और पढ़ो 2. issue reproduce करने के लिए script बनाओ 3. issue ठीक करो 4. script से fix verify करो 5. edge cases test करो” वाला हिस्सा उपयोगी है।
  मैं भी debugging loop में इसी तरह के prompts इस्तेमाल करता हूँ।
  “कोडबेस का विश्लेषण करके संभावित root causes की सूची बनाओ, उन्हें संभावना के क्रम में rank करो, और scripts या debug logging से hypotheses verify करो” — यह तरीका मेरी अपनी problem-solving routine में बहुत मददगार है।
- जब समस्या एक ही फ़ाइल में self-contained हो, तब LLM से fix कराना बहुत आसान होता है।
  लेकिन सामान्य codebase में फ़ाइलें और context इधर-उधर बिखरे होते हैं, इसलिए डेवलपर की structured design intent और organization के हिसाब से उसे समझना आसान नहीं होता।
- इस शानदार कोशिश के लिए बधाई, लेकिन थोड़ा अफ़सोस यह है कि tools ज़्यादा नहीं हैं।
  ज़्यादातर कोड agent framework से जुड़ा है, और सिर्फ SWE के लिए विशेषीकृत कोड उम्मीद से कम है।
  मैंने भी मज़े के लिए एक SWE agent बनाया था, तो autocode भी देख सकते हैं।
- धन्यवाद के तौर पर इसे references में जोड़ दिया है।
Thorsten Ball द्वारा लिखा गया एक बहुत ही मिलता-जुलता “agent build कैसे करें guide” AmpCode How To Guide में भी है।
कुल मिलाकर Amp भी काफ़ी दिलचस्प लगता है।
अब यह कोई रहस्यमय सेवा नहीं रही, लेकिन agent coding से जुड़े tools का लगातार public होना अच्छा लग रहा है।
मुझे लगता है कि आगे चलकर अलग-अलग software में ऐसे agent models default रूप से शामिल होंगे।
- यह काफ़ी ज़्यादा पढ़ने लायक लगा, उसके लिए आभार।
- यह भी बताया गया है कि लेखक खुद Amp में काम करता है।
- Ghuntley भी Amp में काम करता है।
कहते हैं एक तस्वीर 1000 शब्दों के बराबर होती है, लेकिन इस सामग्री में तो तस्वीरों की value पर 99.6% की छूट लगी हुई लगती है।
समझ नहीं आ रहा यह क्या है।
- यह conference workshop के लिए slide material है।
  टेक्स्ट असल presentation में बोले गए शब्दों का dictation है।
क्या कोई यह समझा सकता है कि tools का इस्तेमाल वास्तव में कैसे काम करता है?
मेरी समझ यह है कि Claude, ChatGPT आदि API के ज़रिए “tools” उपलब्ध कराते हैं, और जब tool call request आती है तो responder की तरफ़ से tool सचमुच चलाया जाता है और फिर उसका result वापस दिया जाता है।
लेकिन मॉडल तो तकनीकी रूप से text-based है, इसलिए यह जिज्ञासा है कि API में मॉडल के response को अलग-अलग structured forms में कैसे बदला जाता है।
मुझे लगता है कि fine-tuning के दौरान ऐसे examples दिए गए होंगे जहाँ किसी विशेष tool call को special block के रूप में डाला गया हो, और फिर Claude/ChatGPT servers उसे interpret करते हों।
क्या इससे जुड़ी कोई documentation या internally इस्तेमाल होने वाले special tokens के बारे में जानकारी है, और user input को इन “semantic” tokens का दुरुपयोग करने से कैसे रोका जाता है?
- Anthropic की एक implementation document public है।
  Anthropic Tool Use Documentation
  इससे साफ़ समझ आता है कि मॉडल वास्तव में “text” नहीं बल्कि tokens के स्तर पर काम करता है।
  यह वैसा ही है जैसे compiler source code को parse करके keywords, parentheses, structure आदि की “token” sequence बनाता है।
  Output में असली शब्दों के साथ metadata भी शामिल हो सकता है।
- अवधारणात्मक रूप से आपकी समझ सही है।
  LLM के साथ असली interface सिर्फ “tokens” है; control और data channels अलग नहीं हैं।
  Model API layer tool-calling instructions और उपलब्ध tools की सूची को prompt में inject करती है, और हर tool का description भी देती है।
  जब tool call की ज़रूरत होती है, तो मॉडल response में एक special block डालता है, जिसमें special tokens, tool name और parameters शामिल होते हैं; फिर API layer उसे निकालकर JSON में बदल देती है।
  Tool execution results भी special tokens के साथ encode करके डाले जाते हैं।
  User input से ऐसे tokens inject न हो सकें, यह API layer सुनिश्चित करती है।
  नए SoTA models को tool calling के लिए काफ़ी fine-tune किया गया है; इसमें general tool calling और specific tool cases दोनों शामिल हैं, जैसे Claude Sonnet models का Claude Code tools के लिए विशेष fine-tuning।
  यह हैरानी की बात है कि यह सब इतना अच्छा काम करता है; tool calling में fine-tuning सचमुच बेहद अहम भूमिका निभाती है।
  Fine-tuning के बिना भी यह काम कर सकता है, लेकिन success rate काफ़ी गिर जाती है।
- मुझे लगता है “tool call की ज़रूरत वाले examples को special blocks में return करने के तरीके से fine-tune किया गया” वाली अटकल सही है।
  जब मॉडल को जवाब ठीक से न पता हो, या उसे निर्देश मिले हों, तो उसे tool-call format में उत्तर देने के लिए प्रशिक्षित किया जाता है।
  इसमें format-following tool-call examples, यानी format itself, और कुछ tools के लिए specialized training — दोनों शामिल हैं।
  उदाहरण के लिए gpt-oss, चाहे खास उल्लेख न भी हो, search tool इस्तेमाल करने की तरफ़ झुकता है।
  Anthropic docs में familiar tools, जैसे text_editor और bash, की अलग सूची भी है, और संभव है कि इन tools के इस्तेमाल के गहरे semantics तक अलग से सिखाए गए हों।
  व्यवहार में यह संरचना काफ़ी नाज़ुक होती है, और “special tokens या token sequences” जैसे low-level signals पर चलती है।
“अगर tokens को लगातार loop में डालते रहो तो agent बन जाता है” — इस बात में अगर “tokens” की जगह “पैसा” रखकर देखें, तो यह काफ़ी यथार्थवादी व्यंग्य लगता है।
यानी आख़िरकार, पैसा जलाते रहो तो agent पैदा हो जाएगा।
- मैं यह नहीं कहूँगा कि tokens ही पूरी तरह पैसा हैं।
  Local models भी लगातार बेहतर हो रहे हैं।
  अभी सबसे अच्छे results के लिए tokens (=पैसा) की ज़रूरत पड़ती है, लेकिन भविष्य में यह बदल सकता है।
जब सामग्री सिर्फ images से भरी हो, तो उसे पढ़ना बहुत मुश्किल हो जाता है।
ऐसा लगता है जैसे किसी scroll simulator को देख रहे हों।
bash tool के अलावा और tools की ज़रूरत क्यों है, यह जानने की जिज्ञासा है।
फ़ाइल सूची देखना, repo खोजना और explore करना, फ़ाइल की सामग्री edit करना — क्या यह सब सिर्फ bash से नहीं हो सकता?
या फिर यह ऊपर वाले mini-swe-agent example जैसा मामला है?
- तकनीकी रूप से देखें तो सिर्फ bash से भी तरह-तरह के काम किए जा सकते हैं, और मुझे खुद ऐसा करके सफलता मिली है।
  दिलचस्प बात यह है कि tools जितने सीमित होते हैं, agent उतना रचनात्मक हो जाता है।
  लेकिन अगर कई trained tools उपलब्ध कराए जाएँ, तो मॉडल अक्सर पहले से जानता है कि किस tool का इस्तेमाल कैसे करना है; इससे token usage ज़्यादा efficient होता है और कुल success rate भी बेहतर होती है।
  सिर्फ Bash इस्तेमाल करने पर bashism, argument handling, whitespace handling जैसी चीज़ों में यह अक्सर उलझ जाता है।
- अलग tools का इस्तेमाल करना, सब कुछ एक ही bash tool में ठूँसने से कहीं ज़्यादा सरल है।
  अगर सब कुछ bash से कराना हो, तो जो commands हमेशा सुरक्षित हैं, जैसे file listing, उन्हें तुरंत चलाना होगा, और बाकी जोखिमभरे commands के लिए user approval लेने का अलग सिस्टम बनाना पड़ेगा।
  अगर file listing को अलग tool के रूप में दिया जाए, तो project directory के बाहर की files के exposure को भी रोका जा सकता है।
- व्यवहार में सिर्फ bash tool और Edit tool से coding agent चलाना काफ़ी हद तक संभव है। Edit पूरी तरह अनिवार्य नहीं है, लेकिन उसके बिना inefficiency बहुत बढ़ जाती है।
  हालाँकि code search जैसी चीज़ों में मुश्किल आ सकती है।
  उदाहरण के लिए prompt को इस तरह adjust किया जा सकता है कि bash के भीतर ripgrep इस्तेमाल कराया जाए।
- IDE की ज़रूरत क्यों होती है? Shell में सब कुछ किया जा सकता है, फिर भी लोग उसे क्यों इस्तेमाल करते हैं?
  UI का काम है उसी क्षण आवश्यक जानकारी और actions उपलब्ध कराना।
- bash tool के अलावा और चीज़ें क्यों डाली गईं, इसका जवाब शायद यह है कि शुरुआत में न्यूनतम tools देकर शुरू किया गया, और बाद में चाहें तो bash जोड़ा जा सकता है।
“agent कैसे बनाएँ” यह लंबा समझाने से बेहतर, मैं यह देखना चाहूँगा कि agent ने वास्तव में कौन-सा project बनाया है।
- अगर आप खुद कोई agent बनाकर उसे HN पर “Show HN” के रूप में साझा करें, तो बहुत अच्छा होगा।
क्या कोई समझा सकता है कि Oracle, Agent, high safety, low safety जैसी axes का मतलब क्या है?
मैंने edge और chrome के on-device models (phi4-mini, gemini nano) के साथ इसे सीधे आज़माया, और model size की तुलना में यह काफ़ी अच्छा चला, यह देखकर हैरानी हुई।
how to build an agent on device प्रयोग

crawler 2025-08-25

कहते हैं कि एक तस्वीर की कीमत आमतौर पर 1000 शब्दों के बराबर होती है, लेकिन इस सामग्री में तो तस्वीरों की कीमत 99.6% डिस्काउंट पर लगी हुई लगती है। यह क्या है, जानने की जिज्ञासा हो रही है

बहुत ही मज़ेदार है हाहाहा, पहले समझ नहीं आया कि क्या कहना चाह रहे थे, लेकिन लिंक खोलते ही बात एकदम साफ़ समझ आ गई

savvykang 2025-08-25

ब्लॉग की दूसरी पोस्टों के थंबनेल भी बेकार हैं, उन्हें देखकर बिल्कुल क्लिक करने का मन नहीं करता।

nemorize 2025-08-25

हाहाहाहाहाहाहाहाहाहाहा