Claude Code के बिल्ड से पहले Google इंजीनियर प्लान परखते हैं

Google का Elephant-Goldfish Model (EGM) Claude Code का एक फ्री प्लगइन है, जिसमें बिना याददाश्त वाले रिव्यूअर कोई भी कोड लिखे जाने से पहले आपका प्लान पढ़ते हैं। हमने इसे इंस्टॉल किया और अपने ही ऐप का एक असली फीचर प्लान से लेकर चलते हुए कोड तक पहुँचाया: परिवार की गिफ्ट लिस्ट के लिए रिज़र्वेशन सिस्टम, जो Next.js पर बना है, Notion डेटाबेस के साथ, और रेपो की एक कॉपी पर चलाया गया।

प्लानर ने race condition खुद पकड़ ली थी। जो छेद सच में मायने रखते थे, वे दो थे जो उसने कभी नहीं देखे: पैरेंट्स अपने होस्टिंग लॉग में पढ़ सकते थे कि किसने क्या रिज़र्व किया, और ब्राउज़र की सेव की हुई कुकी को दोबारा चलाकर किसी और की रिज़र्वेशन कैंसल की जा सकती थी। इन्हें सिर्फ बिना याददाश्त वाले रिव्यूअर ने पकड़ा। रिव्यू किए हुए प्लान से बने फीचर में, आखिरी गिफ्ट पर तीसों races में एक ही विजेता आया, Notion के एक स्टैंड-इन के सामने। और छोटे फिक्स पर रिव्यू की कीमत फिक्स से कहीं ज़्यादा बैठती है, इसलिए उसे स्किप कर दें।

नीचे का वर्कफ़्लो पाँच स्टेप का है: इंस्टॉल, ब्रेनस्टॉर्म और ड्राफ्ट, रिव्यू, resolve, बिल्ड। आखिरी सेक्शन में वह नियम है कि यह सब कब छोड़ देना चाहिए।

जब आप Claude Code से किसी फीचर का प्लान बनवाते हैं, तो प्लान लिखने वाला एजेंट ही वह होता है जिससे आप उसे जँचवाते हैं, और वह अपने ही अंधे कोने नहीं देख सकता। EGM, यानी Elephant-Goldfish Model, इसी समस्या के लिए Google का फ्री प्लगइन है। रिपॉज़िटरी साफ कहती है कि यह Google का आधिकारिक रूप से सपोर्टेड प्रोडक्ट नहीं है।

हाथी वह एजेंट है जिससे आप बात करते रहे हैं: उसके पास पूरी बातचीत है और वह आपके साथ प्लान लिखता है। गोल्डफिश रिव्यूअर एजेंट हैं जिनकी कोई याददाश्त नहीं होती। वे सिर्फ प्लान और आपका कोड पढ़ते हैं, ठीक वैसे जैसे कोई सहकर्मी डिज़ाइन मीटिंग में बैठे बिना pull request रिव्यू करता है। वे आपका कोड पढ़ सकते हैं पर बदल नहीं सकते, आपके प्रोजेक्ट नोट्स नहीं देखते, और वे जो भी विकल्प उठाएँ, आखिरी फैसला आपका होता है। यह विचार Dave Rensin का है, जिन्होंने लिखा कि अगर हम सावधान नहीं हैं, तो हम सिर्फ कोड तेज़ नहीं लिख रहे, हम अपनी गलतियों का बड़े पैमाने पर उत्पादन कर रहे हैं।

इंस्टॉल आपके प्रोजेक्ट फोल्डर से दो कमांड में होता है:

claude plugin marketplace add google/elephant-goldfish-model
claude plugin install egm@egm --scope project

पहली कमांड Google की रेपो को प्लगइन marketplace की तरह जोड़ती है, यानी वह सूची जिससे Claude Code प्लगइन इंस्टॉल कर सकता है। दूसरी प्लगइन को सिर्फ इसी प्रोजेक्ट के लिए इंस्टॉल करती है। दोनों लगभग पाँच सेकंड में हरा चेक मार्क लौटा देती हैं; प्लगइन लोड होने के लिए नया सेशन शुरू करें। डॉक्स को Claude Code 2.1.271 या उससे नया वर्ज़न चाहिए, क्योंकि रिव्यूअर omitClaudeMd सेटिंग पर निर्भर हैं, जो आपके प्रोजेक्ट नोट्स को उनसे छिपाती है।

फिर अपने CLAUDE.md में एक लाइन जोड़ें, ताकि रिपोर्ट रेपो की रूट में बिखरने के बजाय एक फोल्डर में रहें:

EGM artifact directory: docs/egm

कमांड टाइप करने तक इनकी कोई कीमत नहीं है: इनमें से कोई भी अपने आप आपके सेशन में लोड नहीं होती। सीमा यह है कि गोल्डफिश सिर्फ दस्तावेज़ पढ़ते हैं। वे आपका ऐप नहीं चलाते, और वे वही मॉडल इस्तेमाल करते हैं जो आप करते हैं, इसलिए उसके अंधे कोने साझा कर सकते हैं।

ब्रेनस्टॉर्म उस पल के लिए है जब आप कुछ ऐसा बनाने वाले हों जहाँ गलत फैसला आगे महँगा पड़ेगा। हमारा ऐप एक पारिवारिक गिफ्ट लिस्ट है: रिश्तेदार टिक करते हैं कि उन्होंने क्या खरीद लिया है, और लिस्ट एक Notion डेटाबेस में रहती है। सब कुछ रेपो की कॉपी पर चला, असली लिस्ट तक कोई पहुँच नहीं थी।

फीचर: रिश्तेदार एक गिफ्ट रिज़र्व कर सके ताकि कोई दो लोग एक ही तोहफ़ा न खरीदें, पैरेंट्स न देख सकें कि किसने क्या रिज़र्व किया, और कैंसल करना संभव हो। आप ब्रेनस्टॉर्म कमांड के बाद एक वाक्य में फीचर लिखते हैं:

/egm:egm-brainstorm Let a relative reserve a gift on the list so two people never buy the same one. Parents must not see who reserved what. A reservation can be cancelled.

कुछ भी पूछने से पहले उसने कोड पढ़ा और बताया कि ऐप को पता ही नहीं कि कौन कौन है, क्योंकि सब एक साझा पासवर्ड से लॉगिन करते हैं। फिर वह कई राउंड में सवाल पूछता है, और कोई भी सेक्शन लिखे जाने से पहले गोल्डफिश का एक छोटा झुंड आइडिया को देखता है। आप प्रोडक्ट ओनर की तरह जवाब देते हैं। हमारा: एक साझा पासवर्ड, रिश्तेदार सिर्फ पहला नाम लिखे, और ऐसा कुछ भी जो उन्हें नाम से पहचाने, वहाँ न जाए जहाँ पैरेंट्स देखते हैं। झुंड ने ऐसी बात उठाई जो हमने नहीं सोची थी: पुराना edit route, जो अब भी किसी को हाथ से मात्रा बदलने देता।

प्लानर ने race condition का नाम भी खुद लिया: रिश्तेदार एक ही पल में reserve दबा रहे हैं। race condition तब होती है जब दो requests एक ही पुरानी वैल्यू पढ़ती हैं और दोनों लिखती हैं, जिससे एक अपडेट चुपचाप खो जाता है, और Notion के डॉक्स में कोई संख्या atomically जोड़ने का तरीका नहीं है।

इसके बाद /egm:egm-draft docs/egm/concepts_brief.md डिज़ाइन दस्तावेज़ एक-एक सेक्शन करके लिखता है: कोई भी कोड लिखे जाने से पहले हर फ़ाइल का लिखित प्लान। वह पंद्रह बार पूछने के लिए रुका। आप एक सेक्शन मंज़ूर करते हैं, या आर्किटेक्चर के विकल्पों में से चुनते हैं, जिनमें हर एक के साथ लिखा होता है कि वह कैसे फेल होता है। एक फैसला यह था कि रिश्तेदार की रिज़र्वेशन कहाँ रहे; हमने उनके अपने ब्राउज़र में एक signed कुकी चुनी, ताकि उनके नाम वाली कोई चीज़ सर्वर तक न पहुँचे। ड्राफ्ट ने अपनी known limits में यह भी मान लिया कि race के लिए उसका फिक्स काम नहीं करता, क्योंकि दोनों रिश्तेदार वही वैल्यू पढ़ेंगे। इस स्टेप के अंत में आपके रेपो में एक मंज़ूर डिज़ाइन दस्तावेज़ होता है।

रिव्यू तब के लिए है जब आप और आपका एजेंट दोनों मानते हैं कि प्लान पक्का है, और ठीक तभी आप देख नहीं पाते कि क्या छूट गया है। आप /egm:egm-review docs/egm/gift-reservations.md टाइप करते हैं; वह पूछता है कि रिव्यूअर कुछ और भी पढ़ें क्या, फिर मोड पूछता है। consolidated मोड सभी स्टेज बिना रुके चलाता है और एक्शन की एक मर्ज की हुई सूची लौटाता है।

पाँच स्टेज हैं: Initial Zoom Out Review (क्या डिज़ाइन सही समस्या हल करता है), Comprehension Review (क्या कोई नया आदमी इसे समझेगा), Design Critique (ढाँचा और शब्द), Intermediate Zoom Out Review, और Implementation Readiness, जो आपका असली कोड पढ़कर प्लान के हर कदम को उससे मिलाता है। हर स्टेज ताज़ा गोल्डफिश भेजता है जिन्होंने बातचीत कभी नहीं देखी।

हमारे डिज़ाइन पर उसने 7 मिनट 24 सेकंड में नौ रिव्यूअर चलाए और दस्तावेज़ को छुआ नहीं; उसने सिर्फ रिपोर्टें लिखीं।

रिव्यू का नतीजा	गिनती
रिव्यूअर subagents	9
कच्चे findings	77
Blocker / Major / Nit	1 / 42 / 34
मर्ज किए गए एक्शन आइटम	12

उसे race नहीं मिली: race के बारे में हर finding प्लानर की अपनी स्वीकारोक्ति को ही दोहरा रही थी। उसे दो छेद मिले जो किसी ने नहीं उठाए थे:

• प्राइवेसी। होस्टिंग अकाउंट पैरेंट्स का है, और उसके request लॉग, समय और गिफ्ट के साथ, यह निकालने देंगे कि किसने क्या रिज़र्व किया।
• सिक्योरिटी। ब्राउज़र कुकी की सेव की हुई कॉपी replay करके किसी और की रिज़र्वेशन कैंसल की जा सकती थी।

उसने कोड की ऐसी बारीकियाँ भी पकड़ीं जो बिल्ड के वक़्त सामने आतीं, जैसे फ्रेमवर्क के route parameters का asynchronous होना, और ऐसा बिल्ड जो प्लान के बड़े हिस्से तक टूटा रहता। जिस race के बारे में वह पहले से जानता था, उसका फिक्स लक्ष्य को कमज़ोर करना था, और ऐसी सलाह पर पलटकर बहस करनी चाहिए।

resolve वह स्टेप है जहाँ findings का ढेर एक फैसले में बदलता है। /egm:egm-resolve हर रिपोर्ट को एक तालिका में बदल देता है, हर issue के साथ एक सुझाव: escalate, contest, decline, या fix प्रस्तावित करना। आप फिक्स मंज़ूर करते हैं या अपनी वजह के साथ contest करते हैं, और वह सिर्फ वही लागू करता है जो आप मंज़ूर करें। आप escalate किए गए issues का जवाब खुद दे सकते हैं और बाकी को auto-accept होने दे सकते हैं।

हमारी तालिका में सैंतीस issues थे, और resolve रिव्यूअर को कोड से पहले ही जाँच चुका था: उसने एक finding को गलत बताया, एक फ़ाइल जिसे unused कहा गया था पर लॉगिन पेज अब भी उसे import करता है।

सबसे बड़ा मुद्दा race थी। Blocker ने लक्ष्य को "reduces duplicate purchases, does not prevent them" यानी दोहरी खरीद घटाता है, रोकता नहीं, इस तरह दोबारा लिखने का प्रस्ताव रखा। हमने उसे contest किया और ठीक एक विजेता माँगा, जिसमें Notion ही एकमात्र स्टोर हो और कोई नाम न हो। एजेंट ने दिखावा करने से मना कर दिया: "Notion has no way to do that. It has no conditional write and no atomic increment." यानी Notion के पास इसका कोई तरीका नहीं है, न conditional write, न atomic increment। उसने कुछ रास्ते सुझाए, और हमने claim ledger चुना: गिफ्ट के अपने Notion पेज पर गुमनाम नोट्स की एक सूची, हर रिज़र्वेशन के लिए एक, जिसे क्रम से पढ़कर तय किया जाता है कि गिफ्ट किसे मिला। इसने कुकी वाला छेद भी बंद कर दिया, क्योंकि ब्राउज़र के पास अब सिर्फ आपका अपना claim है, इसलिए आप वही कैंसल कर सकते हैं जो आपने रिज़र्व किया।

सीमा: यह फिक्स रिव्यू के बाद आया, इसलिए इसे किसी गोल्डफिश ने नहीं पढ़ा, और यह इस पर टिका है कि Notion एक साथ आई writes का एक ही क्रम रखता है, जिसका उसके डॉक्स वादा नहीं करते। डिज़ाइन कहता है कि शिप करने से पहले इसकी race जाँच असली डेटाबेस की कॉपी पर चलाएँ।

बिल्ड के वक़्त का जोखिम ऐसा एजेंट है जो बीच में अपनी मर्ज़ी से चलने लगे और आपके तय किए से भटक जाए। एक ताज़ा सेशन खोलें, यानी एक नई बातचीत जो सिर्फ वही जानती है जो आपकी फ़ाइलों में है, और उसे डिज़ाइन दें:

Build the feature exactly to the approved design in docs/egm/gift-reservations.md; add tests.

हमारे वाले ने अकेले 7 मिनट 56 सेकंड काम किया, 24 फ़ाइलें बदलीं, और टेस्ट सूट Tests 216 passed (216) के साथ लौटा। उसने बताया कि वह प्लान से कहाँ हटा (टेस्ट रनर का एक पुराना वर्ज़न, क्योंकि नया वाला एक नए पैकेज की माँग करता था) और अपग्रेड से पहले पूछा। उसे अपने ही सेटअप में एक flaky टेस्ट भी मिला और उसने उसे पूर्वानुमेय बना दिया।

फिर जोखिम वाला रास्ता खुद टेस्ट करें, क्योंकि हरा सूट सिर्फ उतना साबित करता है जितना किसी ने टेस्ट करने की सोचा। दो रिश्तेदार एक ही सेकंड में आखिरी गिफ्ट पर, अलग-अलग टाइमिंग के साथ तीस बार चलाया: हर बार ठीक एक रिज़र्वेशन गया और दूसरे को बताया गया कि गिफ्ट ले लिया गया है। पैरेंट्स के व्यू में गिफ्ट पूरा दिखा, कहीं कोई नाम नहीं था, और कैंसल करने पर वह वापस आ गया।

ये टेस्ट Notion के एक स्टैंड-इन पर चलते हैं जो उसी की तरह बर्ताव करता है, बिना atomic add के और बेतरतीब देरी के साथ। बाहरी सेवाओं के टेस्ट का यही सामान्य नियम है: उन्हें नकली बनाइए, पर नकली को उतना ही बेरहम रखिए जितनी असली है। शिप करने से पहले डिज़ाइन की अपनी race जाँच असली डेटाबेस की कॉपी पर चलाएँ; टेस्ट फ़ाइल तो उस मामले को भी दर्ज करती है जिसमें दोनों रिश्तेदार जीत जाते।

उसी ऐप पर, README में अब भी लिखा था कि लॉगिन बिल्कुल नहीं है, जबकि साइट पर पासवर्ड है: एक लाइन का फिक्स। सादे Claude Code ने कोड जाँचा और कुछ सेकंड में ठीक कर दिया, बिना किसी प्लगइन के।

रास्ता	कीमत (API कीमतें, Sonnet 5.5)	समय
README फिक्स, सादा Claude Code	$0.0455	10 s
EGM ब्रेनस्टॉर्म, ड्राफ्ट, रिव्यू, resolve (कोड से पहले)	$7.10	32 min

Google की README भी यही कहती है: "Use it when a feature needs design decisions before implementation. For a small, clear bug fix, use your normal coding workflow." यानी इसका इस्तेमाल तब करें जब फीचर को लागू करने से पहले डिज़ाइन फैसले चाहिए हों, और छोटे, साफ bug fix के लिए अपना सामान्य कोडिंग वर्कफ़्लो इस्तेमाल करें। उसका FAQ जोड़ता है कि वर्कफ़्लो पूरा करने से productivity में बढ़त साबित नहीं होती, और एक कोडिंग ब्लॉग के छोटे पायलट में उस फीचर पर रिव्यू से कुछ नहीं जुड़ा जिसे सादा प्लान पहले ही संभाल लेता था।

EGM वहाँ काम आता है जहाँ गलती बातचीत के बाहर छिपी हो, जैसे यहाँ पैरेंट्स के लॉग और replay होने वाली कुकी। जिस समस्या को प्लानर पहले से जानता था, उसे हल करने वाला फैसला हमारा था। नियम: बिल्ड प्रॉम्प्ट टाइप करने से पहले पूछें कि क्या यहाँ की गलती किसी और के डेटा, प्राइवेसी, परमिशन या पैसे को छूती है। अगर हाँ, तो बनाने से पहले रिव्यू चलाएँ।