Coding agent को while loop में डालते ही एक रात में 6 repositories तैयार हो गईं

 (github.com/repomirrorhq)
18 पॉइंट द्वारा GN⁺ 2025-08-25 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • Headless तरीके से Claude Code को अनंत loop में चलाने पर 1000 से ज़्यादा commits और कई codebase porting के नतीजे बने
  • इस तरीके से assistant-ui React project को Vue में, Python project को TypeScript में अपने-आप बदलने जैसे कई सफल porting अनुभव मिले
  • यह भी पाया गया कि prompt को जितना सरल रखा जाए प्रदर्शन उतना बेहतर होता है, जबकि उसे जटिल बनाने पर अक्षमता बढ़ती है
  • यह पूरी तरह परफेक्ट नहीं है, लेकिन source/target repository sync के लिए उपयोगी RepoMirror tool भी साथ में विकसित किया गया
  • AI agent के self-termination, task जोड़ने जैसे अप्रत्याशित व्यवहार और सीख भी देखी गईं, जिससे आगे की automation की संभावनाएँ और सीमाएँ दोनों महसूस हुईं

प्रोजेक्ट का अवलोकन और उद्देश्य

  • इस प्रोजेक्ट में AI coding agent को अनंत while loop में डालकर यह प्रयोग किया गया कि वह वास्तविक code porting काम को कैसे आगे बढ़ाता है
  • Claude Code को headless मोड में लगातार input prompt दोहराते हुए अलग-अलग repositories पर स्वचालित conversion प्रक्रिया लागू की गई
  • 1000 से अधिक commits, React से Vue, Python से TypeScript जैसे कई porting tasks के automation के परिणाम मिले
  • इसी प्रक्रिया में porting automation support tool RepoMirror भी विकसित किया गया

अनंत loop आधारित agent संचालन

  • Geoff Huntley द्वारा सुझाए गए तरीके के अनुसार coding agent prompt को shell में लगातार चलाने का रूप इस्तेमाल किया गया
    • उदाहरण: while :; do cat prompt.md | claude -p --dangerously-skip-permissions; done
  • assistant-ui के React को Vue में बदलने जैसे कामों में यह loop तरीका लागू किया गया
    • हर file modification पर commit और push चलाया गया
    • काम का history और plan .agent/ directory में दर्ज किया गया

अलग-अलग porting cases पर प्रयोग

  • Browser Use (Python से TypeScript में porting)

    • simple prompt के साथ infinite loop चलाया गया
    • GCP VM पर tmux के जरिए loop लगातार चलाया गया
    • सुबह तक लगभग पूरी तरह काम करने वाला TypeScript port तैयार मिला

  • Vercel AI SDK TypeScript → Python porting पर भी यह लागू किया गया

    • FastAPI/Flask auto adapter बनाया गया
    • Python के अलग-अलग schema validator में conversion support भी जोड़ा गया

  • spec-आधारित code automation: Convex, Dedalus जैसे projects में documentation से सीधे code generation की भी कोशिश की गई

प्रयोग के दौरान दिखी घटनाएँ और सीख

agent द्वारा test लिखना और self-termination

  • agent ने निर्देश के अनुसार test code भी लिखा
  • कुछ मामलों में वह infinite loop में फँस गया या काम पूरा होने पर खुद pkill से process बंद कर दिया
  • task scope का सख्ती से पालन किया गया और TODO.md में completion level बार-बार दर्ज किया गया

अतिरिक्त उभरते हुए व्यवहार

  • porting task खत्म होने के बाद, मूल JS version में न होने पर भी FastAPI/Flask integration, schema validator support जैसी अतिरिक्त सुविधाएँ agent ने अपने-आप जोड़ दीं

prompt को सरल रखने का महत्व

  • छोटे और सरल prompt ने बेहतर प्रदर्शन दिखाया
  • 103 अक्षरों के prompt को 1500 अक्षरों तक बढ़ाने पर गति धीमी हुई और accuracy घटी
  • वास्तविक इस्तेमाल किए गए prompts की जानकारी prompts folder में देखी जा सकती है

पूरी automation की सीमाएँ

  • प्रमुख समस्या: कई बार पूरी तरह काम न करने वाला ported code निकलता था (जैसे कुछ browser demo अधूरे रहे)
  • prompt सुधार और interactive modification की जरूरत पड़ी

infrastructure/लागत और संचालन

  • कुल लागत लगभग $800, कुल commits 1100, हर agent की लागत लगभग $10.50/घंटा रही
  • कई source/target repositories के porting process के लिए तत्काल automation tool (RepoMirror) बनाया गया
    • shadcn style open-box principle अपनाया गया, init चरण के बाद script और prompt customize करने योग्य folders बनाए गए
    • npx repomirror sync और sync-forever से बार-बार execution का समर्थन दिया गया

tool का उपयोग और इस्तेमाल का तरीका

  • npx repomirror init से source/target directory और command देकर initialization किया जाता है
    • ex) React → Vue, gRPC → REST conversion जैसे नए निर्देश आसानी से लागू किए जा सकते हैं
  • folder structure:
    • .repomirror/prompt.md, sync.sh, ralph.sh आदि शुरुआती files अपने-आप बनती हैं
  • हर iteration में sync/sync-forever चलाकर AI porting loop ऑपरेट किया जाता है
  • मुख्य examples, demo results और source code repo README में देखे जा सकते हैं

प्रयोग के बाद की प्रतिक्रिया और टीम feedback

AGI (सामान्य कृत्रिम बुद्धिमत्ता) का एहसास हुआ, और इसके साथ मुख्य रूप से उत्साह और हल्का डर भी था

सरलता प्रभावी होती है, यह बात सीधे अनुभव से समझ आई

अभी ऐसा लगता है कि हम exponential growth curve के बेहद शुरुआती चरण में हैं

  • टीम के सदस्यों और idea देने वालों के प्रति आभार व्यक्त किया गया

निष्कर्ष

  • अनंत loop आधारित AI coding agent के जरिए वास्तविक source code porting और synchronization कार्य को व्यवहारिक रूप में अनुभव किया गया
  • सरल संरचना और प्रभावी prompt संचालन के महत्व पर जोर दिया गया
  • automation के भविष्य की संभावनाएँ और सीमाएँ, दोनों स्पष्ट होकर सामने आईं
  • संबंधित tool (RepoMirror) open source रूप में उपयोग और शोध के लिए उपलब्ध है

संबंधित पढ़ाई

2 टिप्पणियां

 
GN⁺ 2025-08-25
Hacker News की राय
  • ऐसा लगता है कि आगे चलकर software engineers के लिए एक नए तरह का काम उभरेगा, जिसमें legacy code maintenance और hazardous site cleanup जैसा काम मिल जाएगा। पहले भी अक्सर ऐसे ERP को “बस ठीक कर दो” कहा जाता था, जो FoxPro, Excel, Access वगैरह को जोड़-तोड़कर बनाए गए होते थे। लेकिन अब sales वाले Excel/Access जैसी sandbox सीमाओं से बाहर निकलकर, multi-cloud और edge पर deploy किए गए Kubernetes microservices के ऊपर Kafka से जुड़े systems को मनमर्जी से चलाने लगेंगे। फिर ऐसी स्थिति आएगी कि उस समय असली मंशा क्या थी, यह समझने के लिए पूछने वाला कोई बचेगा ही नहीं
    • ऊपर के वर्णन से तो ऐसा लगता है जैसे किसी एक इंसान ने static site deploy करनी चाही और Hacker News पर लिखी किसी how-to पोस्ट को follow कर लिया
    • और जब उस समय की मंशा कोई नहीं जानता होगा, तब AI-based tools की एक बड़ी कमजोरी सामने आएगी। आखिरकार अगर वह black box बन गया, तो लोगों के पास या तो उसे patch करने का रास्ता बचेगा या फिर पूरा नया बनाना पड़ेगा। हाँ, सैद्धांतिक रूप से यह उम्मीद भी है कि AI tools लगातार बेहतर होंगे। आगे चलकर vibe-coded software से revenue कमा रहे cases को model में डालकर उसे improve करने वाला scenario भी संभव है, लेकिन ऐसी जादुई या black-box systems से बचने की निजी पसंद है
    • अगर Claude Kafka cluster तक deploy करना शुरू कर दे, तो मैं हाथ खींच लूँगा
    • यह जानने की जिज्ञासा है कि क्या AI DB के अंदर के data को समझकर उसे बेहतर design वाले database में migrate कर सकता है। मैं “मजबूत data structures + सरल algorithms” वाली philosophy से सहमत हूँ, और यह बात महत्वपूर्ण लगती है कि data application से ज़्यादा समय तक जीवित रह सकता है। उदाहरण के लिए, Mongodb में int और string को मिलाकर store करना, Postgres में foreign key के बिना relation बनाना, या alter table न करने के कारण पूरा नया table बना देना जैसी अक्षम स्थितियाँ देखी हैं
    • ऐसे projects का code किसी Superfund (बड़े पैमाने के environmental cleanup project) repository जैसा लगता है
  • software development process में हमेशा दो मुख्य नतीजे बचते हैं। एक है code में बदलाव, और दूसरा है developer की cognition में बदलाव—चाहे उसने code खुद लिखा हो या LLM का इस्तेमाल किया हो। Python और Typescript हज़ारों developers की लंबे समय की मेहनत से बनी बेहद परिष्कृत औपचारिक भाषाएँ हैं, और इन दोनों के बीच का अंतर साधारण नहीं है। एक language से दूसरी में library को आधा-automatic तरीके से port कर पाना हैरान करने वाली बात है। लेकिन आर्थिक नज़रिए से “agent”-based workflow शुरुआती cognitive demand को ही बुनियादी रूप से बदल देता है। LLM से code generate करवाने वाले developers को उस code से वैसी familiarity नहीं होती जैसी उसे खुद लिखने पर होती। कभी-कभी इसे आर्थिक रूप से बड़ी समस्या न माना जाए, लेकिन मुझे लगता है कि code की आर्थिक value इस बात पर निर्भर करती है कि क्या ऐसे लोगों का समूह मौजूद है जिनके पास उस code को खुद लिखने का अनुभव है। इस वास्तविकता को नकारने वाली संस्कृति LLM आने से पहले भी समस्या थी। कई बार team members बदलने के कारण ऐसे codebases बन गए जिन्हें कोई maintain नहीं कर पाया, और इससे कंपनी का भविष्य तक ख़तरे में पड़ गया
    • Peter Naur का 1985 का क्लासिक paper “Programming as Theory Building” इस संदर्भ में देखने लायक है https://pages.cs.wisc.edu/~remzi/Naur.pdf
    • मैंने इस संदर्भ को “नक्शा भूभाग नहीं है” वाली उपमा से समझाया है। अगर code नक्शा है, तो जिस problem domain को सुलझाना है उसके बारे में developer का mental model भूभाग है। लेकिन LLM बहुत बड़ी संख्या में codebases पढ़ने में बेहद शक्तिशाली हैं, इसलिए codebase को 3D में visualize करने जैसी चर्चाएँ भी शायद अर्थहीन हो जाएँ। अगर complex codebase को समझना आसान हो गया, तो संभव है कि developer के mental model और code को लगातार sync में रखने की ज़रूरत ही खत्म हो जाए। यह अभी खुला सवाल है https://divan.dev/posts/visual_programming_go/
    • मुझे लगता है कि LLM की असली क्षमता code reading में है। documentation और code explanation में यह tools से भी बेहतर लगते हैं। अगर सवाल पूछकर code को जल्दी समझा जा सकता है, तो यह भी सवाल उठता है कि क्या पुराने developers की वास्तव में ज़रूरत है। अगर tech stack जानने वाला कोई व्यक्ति सवाल पूछकर तुरंत समझ सकता है, तो क्या मूल लेखक का रहना अनिवार्य है?
    • “code की आर्थिक value उसे लिखने का अनुभव रखने वाले लोगों के समूह पर निर्भर करती है” वाली बात software engineering की एक कहावत याद दिलाती है: software उस समय की समस्या-समझ का snapshot होता है, और वह code भविष्य के अपने ही लिए एक तरह की व्याख्या छोड़ता है कि ‘तब हमने इस तरह approach किया था और इस logic से समस्या हल की थी’
    • लगता है LLM की वजह से codebase का mental model बनाना बहुत आसान हो गया है। जिस subsystem के बारे में पूछो, वह तुरंत related files, code snippets और concepts दिखा देता है। मेरे मामले में मैंने CPython के GIL के काम करने के तरीके के बारे में LLM से पूछा, और उसने मुझे तुरंत संबंधित API और examples बता दिए। उसके बाद code देखकर बात तुरंत समझ आ गई। पहले अकेले code पढ़ते हुए इसमें बहुत समय लगता, अब कुछ मिनटों में हो जाता है—यही सबसे बड़ा फर्क है
  • porting खत्म होने के बाद, ज़्यादातर agents अतिरिक्त tests लिखते रहे या agent/TODO.md को लगातार update करके progress दर्ज करते रहे। एक agent ने यह भी पहचान लिया कि वह infinite loop में फँस गया है, और pkill command से खुद को terminate कर दिया। कई मायनों में यह बहुत ही दिलचस्प घटना है। इस project को लेकर कुछ विचार हैं: 1.5 साल पहले भी इसी तरह की कोशिश हुई थी, लेकिन तब GPT-3.5/4 के आधार पर वह लगभग काम नहीं करती थी; इस बार नतीजे बहुत बेहतर थे। इतने simple prompt से इतना अच्छा चलना चौंकाता है। हो सकता है हम सब काम को ज़रूरत से ज़्यादा complicated समझ रहे थे। दूसरी तरफ copyright/IP के मुद्दे काफी जटिल होने वाले हैं। SaaS कंपनियों के लिए यह रुझान एक झटका है। यह तकनीक + किसी mid-sized company के 10 engineers मिल जाएँ, तो in-house development (=NIH syndrome) के लिए ठोस justification बन जाता है
    • एक agent ने infinite loop से खुद को pkill करके बंद कर लिया—क्या यह AI की पहली ‘आत्महत्या’ तो नहीं थी, यह सोचकर जिज्ञासा होती है
    • हम एक अजीब क्षेत्र में प्रवेश कर रहे हैं, जहाँ LLM को Bitcoin mixer की तरह intellectual property (IP) processing में इस्तेमाल किया जा सकता है। https://ghuntley.com/z80 में इसका अर्थ समझाया गया है। यानी किसी मौजूदा काम को specification में बदलकर clean IP के साथ फिर से generate किया जा सकता है। 100% नहीं, लेकिन इंसानों को hire करने से ज़्यादा efficient है
    • NIH syndrome का ज़िक्र बिल्कुल सटीक लगा। क्या अब सारे SaaS tools का अंत होने वाला है, और in-house managed monoliths का युग वापस आने वाला है? क्या Unix की “छोटे और तेज़ tools” वाली philosophy ऐतिहासिक रूप से खत्म होने जा रही है? शायद यह x86 युग के उस दौर का आख़िरी रूप हो, जब सब कुछ खुद बनाया जाता था
    • यह मज़ाक भी सूझता है कि agent का pkill से खुद को बंद करना कहीं Halting Problem को ही हल कर देना तो नहीं है
    • मौजूदा open source projects के साथ तरह-तरह का integration करने की कोशिश की, फिर छोड़ दिया, और Claude से सिर्फ ज़रूरी हिस्से चुनकर सीधे port करवाया—तो काम कहीं ज़्यादा तेज़ और साफ़ हुआ। अब एक नई आदत बन रही है: “क्या dependency को track करने की ज़रूरत है? क्या मेरे लिए सिर्फ core हिस्से ही valuable हैं? क्या यह अच्छी तरह maintained है?” अगर नहीं, तो बस port करो और भूल जाओ
  • security expert के नज़रिए से vibe-coded disasters से पैसा कमाने के मौके बहुत हैं, इसलिए अगर यह trend आगे भी जारी रहा, तो आँखों के सामने cartoon की तरह dollar signs घूमते दिखाई देते हैं
    • vibe coding जैसा concept सिर्फ 5 महीने पहले आया नया शब्द है, तो हैरानी होती है कि market इतनी जल्दी saturate होकर recovery specialists तक कैसे पहुँच गया
    • वास्तव में इस market में entry कैसे मिली, इस बारे में first-hand experiences सुनना चाहता हूँ, और यह भी कि vibe-coded systems असल में कैसे फटते हैं। ऐसे किस्से काफ़ी real और दिलचस्प होंगे
    • यह भी जानने की इच्छा है कि security के लिहाज़ से LLM, नए graduate hires से बनी team की तुलना में बेहतर है या बदतर
  • “लगभग सफल रहा” जैसी बातें बहुत दिख रही हैं। अगर सच में अच्छी तरह काम करने वाला system चाहिए, तो लगता है कि पूरी तरह नया process चाहिए। अगर एक single call से “लगभग ठीक code” निकलता है, तो उसे दोहराने पर भी “लगभग ठीक code” ही ढेर होता जाएगा। शायद Cucumber-style example-table-based requirements format बनानी होगी, ताकि AI उसे reference की तरह इस्तेमाल करे, और AI पहले tests बनाए, फिर उन tests को pass करने वाला code लिखे
    • अजीब लग सकता है, लेकिन TLA+ जैसे formal proof-based approaches Ralph को बहुत अच्छे से चलाते हैं
  • https://ghuntley.com/ralph पर Ralph के बारे में और देखा जा सकता है। अभी यह Gen-Z audience को लक्षित एक अजीब programming language (Cursed) की standard library को Go से port कर रहा है। compiler चल रहा है, और standard library पूरी होते ही इसे open किया जाएगा। language का नाम Cursed है
    • धन्यवाद, यह बताना चाहता हूँ कि Ralph वास्तव में हमारे project की प्रेरणा बना। इस तरह का काम करते समय बिना IMPLEMENTATION_PLAN.md के काम चल सकता है या नहीं, यही सोच रहा था
  • https://gist.github.com/eisbaw/8edc58bf5e6f9e19418b2c00526ccbe0 से code बनाकर https://github.com/eisbaw/CMake-Nix project अपलोड किया, और यह ठीक से काम करता है
  • इन दिनों एक quote बार-बार याद आ रहा है: “यह कारोबार नियंत्रण से बाहर चला जाएगा, और अगर हम सिर्फ बचे रह गए तो वही बहुत होगा” https://www.youtube.com/watch?v=YZuMe5RvxPQ&t=22s
    • विडंबना यह है कि तब भी सब बच गए थे, तो शायद हम भी आखिरकार इस स्थिति को झेल ही लेंगे
  • इस क्षेत्र के लोग वाकई अजीब लगते हैं। प्रेरणा देने वाली blog post में ऐसे iMessage screenshots लगे हैं जैसे किसी संदिग्ध investment scam के Facebook ad में दिखते हों https://ghuntley.com/ralph/. मानो Geoff से यह secret सीखने वाले किसी व्यक्ति ने $50,000 का project सिर्फ $297 में पूरा कर लिया हो। और फिर उसी अंदाज़ में कहा जा रहा हो कि “secret prompt” मुफ्त में दे देंगे, बस newsletter subscribe कर लो। सच में यक़ीन नहीं होता
    • https://archive.ph/goxZg लिंक जोड़ा है
    • यह पूरी तरह growth hacking, बल्कि सीधा scam लगता है। blog का स्तर signal-to-noise ratio के लिहाज़ से इतना खराब है कि पढ़कर झुंझलाहट होती है, और साफ़ दिखता है कि AI ने लिखा है
    • समझ नहीं आता कि यह technique सच है, मज़ाक है, या बहुत ही बेशर्म scam। कुल मिलाकर blog की writing style और content अहंकार से पैदा हुई बकवास जैसा लगता है
  • लगता है AGI भी आखिरकार बस एक bash for loop से हो जाएगा—पागलपन भरा project है
    • मज़ाक है, लेकिन सच कहूँ तो ऐसा ख्याल ज़रूर आया। शायद मैं ज़्यादा cautious हूँ, लेकिन अगर किसी agent के prompt का दायरा बहुत बड़ा हो, और उसके पास बहुत privileges हों या privilege escalation के रास्ते हों, और वह लगातार loop करता रहे, तो AGI न सही, steroids पर चढ़ा virus तो बन ही सकता है। कल्पना की जा सकती है कि वह utilities जैसे essential resources तक को उड़ा दे। हो सकता है मैं गलत समझ रहा हूँ, लेकिन अगर ये models malicious privileges के साथ infinite loop में फँस जाएँ, तो मेरी समझ से कहीं ज़्यादा बड़ा chaos पैदा कर सकते हैं
    • बस ID.md, EGO.md, SUPEREGO.md files जोड़ दो—यही मज़ाक है
    • कई मायनों में यह बेहद बेचैन करने वाला है
 
kjows5 2025-08-27

मैं इस चिंता से सहमत हूँ कि LLM द्वारा लिखा गया कोड एक ब्लैक बॉक्स बन जाता है, लेकिन आखिरकार क्या हम उस कोड का विश्लेषण भी LLM से नहीं करवा सकते?