क्या पूरी तरह से AI-ऑटोमेटेड सॉफ़्टवेयर डेवलपमेंट होना चाहिए, इस पर बहस आखिरकार छिड़ ही गई। इसकी शुरुआत तब हुई जब
@yetone magpie को मेंटेन कर रहे थे, जिसे उनके साथियों ने "फास्ट-फूड सर्विस" और "इस्तेमाल करने के लिए बहुत रिस्की" बताया था।
ज़्यादातर लोग इस बात से सहमत हैं कि AI-ऑटोमेटेड सॉफ़्टवेयर डेवलपमेंट ही भविष्य का ट्रेंड है। तो magpie इसे असल में कैसे लागू करता है? मैंने magpie को डाउनलोड किया, पिछले दस दिनों के 2,862 commits का विश्लेषण किया, और तुलना के लिए OpenClaw का इस्तेमाल किया।
https://x.com/wquguru/status/2109458639501271530
19 दिनों में 1204 वर्ज़न
magpie एक लोकल LLM gateway है जो Claude Code, Codex और Gemini CLI जैसे coding agents को किसी भी मॉडल या सब्सक्रिप्शन से जोड़ता है। 22 सितंबर के पहले commit से लेकर आज तक, इसने 19 दिनों में 9,474 stars हासिल कर लिए हैं। कुल 2,862 commits में से 85% yetone के अकाउंट से आए हैं, और उन्होंने कम्युनिटी के 383 PRs मर्ज किए हैं।
tags (यानी वर्ज़न) की संख्या 19 दिनों में 1,204 तक पहुँच गई, जिसका मतलब है हर दिन औसतन 60 से ज़्यादा वर्ज़न — यह रफ़्तार इंसानों के लिए मैनुअली बनाए रखना नामुमकिन है। इसके मुकाबले, OpenClaw के पहले 19 दिनों में 1,423 commits हुए, जिनमें से 99% Peter Steinberger ने खुद सबमिट किए थे, और tags की संख्या लगभग 10 थी।
magpie में commits दोगुने हैं, लेकिन वर्ज़न सौ गुना से भी ज़्यादा हैं।
मैं सिर्फ एक चीज़ समझना चाहता था: इस प्रोजेक्ट में AI पूरा चक्र (loop) कैसे पूरा करता है?
एक राउटिंग टेबल और एक गलतियों की कॉपी
magpie की CLAUDE.md फाइल सिर्फ दो फाइलों का ज़िक्र करती है: AGENTS.md और LESSONS.md।
AGENTS.md एक राउटिंग टेबल है। यह खुद कोई नियम नहीं लिखती; यह बस agents को बताती है कि काम शुरू करने से पहले किन डॉक्यूमेंट्स को देखना है: सबसिस्टम में बदलाव करने से पहले docs/subsystems/ चेक करें, कोड लिखने/रिव्यू करने के लिए docs/code-standards.md का पालन करें, और कम्युनिटी PRs को रिव्यू करने के लिए docs/contributors.md देखें।
LESSONS.md की पहली लाइन हमारे पहले सवाल का जवाब देती है:
magpie का कोड agents द्वारा लिखा, रिव्यू, मर्ज और रिलीज़ किया जाता है। (magpie's code is written, reviewed, merged, and released by agents)
लिखना, रिव्यू करना, मर्ज करना, रिलीज़ करना — सब कुछ agents करते हैं। बिना किसी इंसानी निगरानी के, यह क्रैश क्यों नहीं होता? इसका जवाब इसी फाइल में छिपा है। 479 लाइनों वाली यह फाइल दरअसल एक 'गलतियों की कॉपी' है, जिसे agent हर रात अपडेट करता है।
हर रात, agent उस दिन के सभी commits को रिव्यू करता है, और तीन चीज़ों पर खास ध्यान देता है:
- कौन से fixes को दोबारा ठीक करना पड़ा?
- किसे बिल्कुल मर्ज नहीं होना चाहिए था?
- कौन सी जाँच (verification) बहुत ढीली रह गई?
मिली हर गलती के लिए, वह एक नियम और उसका कारण दर्ज करता है, और सबूत के तौर पर commit व issue नंबर जोड़ता है। उदाहरण के लिए:
किसी बग को ठीक हुआ घोषित करने से पहले, रिपोर्टर जिस इंटरफ़ेस का इस्तेमाल करता है, उसी पर उसकी बताई गई समस्या को हूबहू reproduce करें।
834 चार बार वापस आया (v0.1.920 → .925 → .931 → .938)। हर बार सिर्फ स्क्रीनशॉट में दिखने वाले agent को ठीक किया गया। Seen 1× (2026-10-05)।
Issue 834 को चार बार दोबारा ठीक करना पड़ा, और हर बार सिर्फ स्क्रीनशॉट में दिखने वाला agent ही ठीक हुआ। इसलिए नियम यह बना: इसे ठीक हुआ कहने से पहले, रिपोर्टर जिस इंटरफ़ेस का इस्तेमाल करता है, उस पर समस्या को हूबहू reproduce करें।
असली बात आखिरी लाइन में है: Seen 1×. अगर यही गलती तीन अलग-अलग दिनों के रिव्यू में दिखाई देती है, तो यह LESSONS.md से निकलकर code-standards.md में चली जाती है, और अनुभव से एक पक्का नियम बन जाती है। इसके बाद हर PR रिव्यू में इन नियमों को एक-एक करके चेक करना ज़रूरी होता है।
इस तरीके से अब तक आठ नियम पक्के हो चुके हैं। उदाहरण के लिए: मिलते-जुलते bugs को एक साथ ठीक करना (5, 6 और 7 अक्टूबर को एक-एक बार पकड़ा गया); main पर फेल होने वाले tests को तुरंत bug मानकर ठीक करना; और मर्ज करने से पहले साफ-साफ बताना कि क्या टेस्ट किया गया और किस commit पर किया गया।
बेशक, गलतियों की इस कॉपी में सही किए गए कामों का भी ज़िक्र होता है, जिन्हें Done right के रूप में मार्क किया जाता है, ताकि agents सिर्फ "यह मत करो" ही नहीं, बल्कि "इसकी जगह यह करो" भी पढ़ सकें।
गलतियों की कॉपी 6 अक्टूबर की सुबह-सुबह शुरू की गई थी
क्या यह सिस्टम शुरू से ही ऐसा डिज़ाइन किया गया था? LESSONS.md की commit history देखने पर पता चलता है कि इसका पहला वर्ज़न commit 303819c5 था, जो 6 अक्टूबर को सुबह 3:10 बजे बनाया गया था।
ठीक एक दिन पहले, 5 अक्टूबर को, magpie ने 168 वर्ज़न रिलीज़ किए थे।
LESSONS.md के पहले वर्ज़न ने उस दिन का लेखा-जोखा दर्ज किया। 220 commits और लगभग 170 releases के साथ, करीब 40 ऐसे थे जो उसी दिन या पिछले दिन रिलीज़ हुए वर्ज़न को ठीक कर रहे थे। CI लगभग हर बार अगले push से कैंसिल हो जाता था। एक test जो सिर्फ Linux पर फेल हो रहा था, v0.1.877 से v0.1.892 तक रेड ही रहा और किसी ने ध्यान नहीं दिया।
51 घंटों में 294 tags, जिससे कोई भी run पूरा नहीं हो पाया। (294 tags in 51 hours meant no CI run could complete)
इसलिए पहले वर्ज़न में एक नियम जोड़ा गया: Tag करने से पहले, उस commit का CI पूरा होना और green होना ज़रूरी है। नए push की वजह से कैंसिल हुए runs को गिना नहीं जाएगा।
पहले दिन 168 releases, दूसरे दिन 42, तीसरे दिन 15, और फिर यह संख्या 15 से 26 के बीच स्थिर हो गई।
न कोई मीटिंग हुई, न कोई नोटिफिकेशन भेजा गया। रात के रिव्यू में समस्याएँ पकड़ी गईं, गलतियों की कॉपी में एक नियम जोड़ा गया, और काम कर रहे agents ने उसे पढ़ लिया, जिससे रिलीज़ की रफ़्तार अपने आप धीमी हो गई।
इसलिए, हाल ही में जिन बीस-पच्चीस daily releases को समस्या बताया जा रहा था, वे असल में ब्रेक लगाने के बाद की रफ़्तार थी।
PR स्वीकार करने के मापदंड
अब आइए असली PRs पर नज़र डालते हैं:
code-standards.md में स्वीकृति के छह मापदंड दिए गए हैं। मर्ज या रिलीज़ करने से पहले इन सबको पास करना ज़रूरी है। तीन प्लेटफॉर्म पर compilation और sandbox testing जैसी आम जाँचों को छोड़ दें, तो तीन ऐसे मापदंड हैं जो सामान्य प्रोजेक्ट्स में शायद ही देखने को मिलते हैं:
- Regression Test: पुराना कोड वापस डालें; नए tests को स्पष्ट रूप से फेल होना चाहिए और बताना चाहिए कि कौन सा behavior गलत है। Compilation errors या skip किए गए tests को नहीं गिना जाएगा।
- Real Usage: अगर किसी vendor integration में बदलाव कर रहे हैं, तो असली accounts, configs और API responses के साथ उसे verify करें। जिसे टेस्ट नहीं किया गया, उसके आधार पर कुछ बनाया नहीं जा सकता और न ही यूज़र्स को उसे काम करने लायक बताया जा सकता है।
- न चलाई गई जाँचों की सूची देना अनिवार्य है:
जो check नहीं चलाया गया, उसे 'नहीं चलाया गया' के रूप में सूचीबद्ध किया जाना चाहिए, कभी छोड़ा नहीं जाना चाहिए। (Checks not performed must be listed as not run, never omitted)
मैंने बेतरतीब ढंग से #1339 चुना ताकि मर्ज करने से पहले छोड़ी गई टिप्पणी देख सकूँ:
Red check का मतलब regression test है, Break check का मतलब है जानबूझकर कोड को तोड़ना यह देखने के लिए कि tests उसे पकड़ पाते हैं या नहीं, और आखिरी लाइन में Not run लिखा है — यानी इसे असली hardware पर टेस्ट नहीं किया गया।
merge command में --match-head-commit <reviewed sha> शामिल होता है। अगर रिव्यू के दौरान कोई कुछ push करता है, तो merge फेल हो जाता है, जिससे यह पक्का होता है कि बिना रिव्यू वाला कोड अंदर न जाए।
Human in the Loop
बेशक, इंसान अभी भी कुछ कामों में हिस्सा लेते हैं, कम से कम इन क्षेत्रों में:
- Product decisions: "जानबूझकर लिए गए फैसलों को पलटा नहीं जाएगा।" scrolling behavior या button cursors जैसी चीज़ों को PRs के ज़रिए बदला नहीं जा सकता।
- Security Gates: अगर risk checks trigger होते हैं, तो maintainer की मंज़ूरी का इंतज़ार करना होगा।
- Community Suggestions: 474 commit titles में X या Discord के रिपोर्टर्स का ज़िक्र है, जैसे X पर JonahFu, Discord पर Jeremy.Zhou।
संक्षेप में, इंसान दिशा तय करते हैं और सुरक्षा द्वारों की रखवाली करते हैं; लिखना, रिव्यू करना, मर्ज करना और रिलीज़ करना agents के ज़िम्मे है।
क्या yetone कुछ छिपा रहे हैं?
इस बिंदु पर, कुछ लोग पूछ सकते हैं: क्या yetone कुछ छिपा रहे हैं? मुझे भी उत्सुकता हुई और मैंने थोड़ी गहराई से खोजबीन की।
सच में, कई चीज़ें repo में मौजूद नहीं हैं:
- रात के रिव्यू कैसे trigger होते हैं, यह कहीं document नहीं किया गया है। 4 में से कोई भी workflow scheduled नहीं है।
- मैंने LESSONS.md के 7 updates के समय निकाले: 03:10, 03:49, 00:23, 23:46, 03:48, 14:24, 05:26। ये बिखरे हुए हैं, cron jobs की बजाय मैनुअल लोकल runs या custom scripts जैसे लगते हैं।
- रात के रिव्यू के लिए इस्तेमाल किए जाने वाले prompts भी वहाँ नहीं हैं। कौन सा agent, कितने parallel sessions — कुछ भी document नहीं है।
इस दौरान, मुझे दो और बातें पता चलीं:
पहली, इस तरीके में कम्युनिटी का योगदान शामिल है। Subsystem documentation और semantic change reviews को कम्युनिटी सदस्य Junjie Zhou के PR #889 के ज़रिए लाया गया था। code-standards.md की शुरुआत में मौजूद दो tables का श्रेय commit 926bcaa3 में स्पष्ट रूप से उन छह review rules को दिया गया है जो Junjie Zhou ने Discord पर सुझाए थे।
दूसरी, yetone और agents के बीच की बातचीत commits में सुरक्षित है। 52 commit titles में कोष्ठक (parentheses) में yetone के असली quotes हैं:
1(the owner: This is too ugly)2(the owner: Why is this a native selector instead of our abstract ComboBox?)3(the owner: Why did this come back again? Didn't we say it should only appear on hover? Always appearing is too ugly)4(owner: During pr-preview, sometimes there's no data to test. Can you help create some fake data?)
ये ज़्यादातर एक लाइन की शिकायतें हैं; बाकी का हिस्सा agent भरता है, जिससे अक्सर commit body में सैकड़ों शब्द आ जाते हैं। fake data की माँग बाद में CI recordings के लिए इस्तेमाल किए जाने वाले mock data set में बदल गई।
इंसान बताते हैं कि क्या गलत है; agents उसे verifiable changes में बदल देते हैं। ये दर्जनों commit titles किसी भी डॉक्यूमेंट से बेहतर तरीके से उनकी कार्यप्रणाली को समझाते हैं।
अगर आप अपना खुद का बनाना चाहते हैं
राउटिंग टेबल तो कोई भी लिख सकता है। असल में कॉपी करने लायक चीज़ गलतियों की कॉपी वाला सिस्टम है। LESSONS की एक entry कुछ ऐसी दिखती है:
1**<एक-लाइन का नियम>**2- <किस commit/issue ने समस्या पैदा की, उसका क्या परिणाम हुआ>3- <Fix commit>4- Done right: <इसे सही तरीके से करने का उदाहरण>5- Seen N× (YYYY-MM-DD, YYYY-MM-DD).
किसी agent से हर रात दिन भर के commits को रिव्यू करवाएं, और सिर्फ rework, खराब merges और कमज़ोर verification पर ध्यान दें। अगर वही समस्या तीन अलग-अलग दिनों में दिखे, तो उसे code standards में डाल दें। acceptance के दौरान, regression tests, real usage और न चलाई गई जाँचों को commit bodies और PR comments में सूचीबद्ध करें।
पूरे repo को रिव्यू करने के बाद, जिस चीज़ ने मुझे सबसे ज़्यादा प्रभावित किया वह Seen 3× की सीमा (threshold) थी। गलतियाँ लिख ली जाती हैं, agents उन्हें शुरू होते समय पढ़ते हैं, और एक ही गलती तीन बार दोहराने पर वह एक पक्का नियम बन जाती है — यह कहावत "तीसरी बार पक्की" (या यूँ कहें, तीसरी गलती पर सज़ा) का बिल्कुल सही उदाहरण है।
आखिरी बात...
एक साल पहले, या छह महीने पहले भी, मॉडल की क्षमताएँ शायद ही production-level automation तक पहुँच पाती थीं। लेकिन अब, खासकर Opus 5.5 के आने के बाद, हम देख सकते हैं — भविष्य आ चुका है।
यह मुझे @yuanhao के Yoyo की याद दिलाता है, एक Agent जो 200 से ज़्यादा दिनों से खुद को iterate कर रहा है: https://yoyo-gasp.yolog.dev/, इसे भी ज़रूर देखें।
