कैसे बन रहा है
एक डेवलपर, एक AI कोडिंग असिस्टेंट, और मशीन से जाँचे जाने वाले ढेर सारे नियम।
लेखक: Nick
Prison Life मैं Claude Code (Anthropic का कोडिंग एजेंट) के साथ मिलकर लिखता हूँ। गेम क्या है और हम कौन-से रास्ते चुनेंगे, यह मैं तय करता हूँ; ज़्यादातर टाइपिंग असिस्टेंट करता है। क्योंकि कोड की समीक्षा मेरे और एक समीक्षक AI एजेंट के सिवा कोई नहीं करता, मैं ऑटोमेशन पर भरोसा करता हूँ: नियम अच्छे इरादों से नहीं, ऑटोमेटिक जाँचों और बिल्ड से लागू होते हैं।
काम सौंपना
मुख्य Claude Code सेशन काम की योजना बनाता है और टास्क ट्रैकर, डिज़ाइन फ़ैसलों का लिखित रिकॉर्ड और बदलावों का इतिहास सँभालता है। वह कोड नहीं लिखता: हर बदलाव, चाहे कितना भी छोटा हो, एक ख़ास AI एजेंट को सौंपता है। हर एजेंट की अपनी लिखित परिभाषा है जो उसकी भूमिका और मॉडल तय करती है।
| भूमिका | मॉडल स्तर | काम |
|---|---|---|
| आर्किटेक्चर | Opus | डेटा मॉडल, टिक, थ्रेड, पाथफ़ाइंडिंग, फ़ैसले |
| सिमुलेशन कोड | Opus | सिमुलेशन सिस्टम, किरदारों का AI, हॉट लूप |
| परफ़ॉर्मेंस | Opus | प्रोफ़ाइलिंग, बेंचमार्क रिग्रेशन |
| समीक्षा (सिर्फ़ पढ़ना) | Opus | diff की समीक्षा; फ़ाइलें नहीं बदल सकता |
| क्लाइंट और टूल | Sonnet | Godot क्लाइंट, UI, टूल |
| टेस्ट | Sonnet | स्वीकृति मानदंडों से टेस्ट |
| कंटेंट डेटा | Sonnet | स्कीमा से JSON परिभाषाएँ |
| खोज, जाँचें चलाना | Haiku | कोड खोजना; जाँचें चलाना और विफलताओं का सार |
कठिन काम सबसे ताक़तवर मॉडल को जाता है, रोज़मर्रा का काम सस्ते मॉडलों को। अगर कोई सस्ता AI एजेंट दो बार जाँचों में फ़ेल हो, तो काम एक स्तर ऊपर जाता है; अगर सबसे ऊपर का स्तर दो बार फ़ेल हो, तो वह रुककर मुझसे पूछता है।
मना करने वाले हुक
Claude Code के हुक ऐसी स्क्रिप्ट हैं जो असिस्टेंट की क्रियाओं के आसपास चलती हैं। मेरे हुक तीन नियम लागू करते हैं:
- लाल पर ख़त्म नहीं. जब कोई सेशन या AI एजेंट कोड बदलने के बाद रुकना चाहे, तो एक हुक तेज़ जाँच चलाता है (बिल्ड और तेज़ टेस्ट)। अगर वह फ़ेल हो, तो रुकना मना हो जाता है।
- मुख्य सेशन कोड नहीं बदल सकता. एक हुक मुख्य सेशन से सोर्स, टेस्ट, कंटेंट और टूल में लिखने को मना करता है।
- समीक्षक सिर्फ़ पढ़ सकता है. उसके एडिट टूल हटा दिए गए हैं और एक हुक उन कमांड को मना करता है जो फ़ाइलें या प्रोजेक्ट का इतिहास बदलें।
ये ग़लतियों से बचाते हैं, जानबूझकर किए गए बाईपास से नहीं: कोई ज़िद्दी शेल तरकीब इन्हें पार कर सकती है, और एक हुक किसी AI एजेंट में लाल जाँच देख तो लेता है पर उसे रोक नहीं पाता (मुख्य सेशन का स्टॉप हुक फिर भी उसे पकड़ लेता है)। मैं यह साफ़ कहना पसंद करूँगा।
लिखित फ़ैसले और जाँचें
- हर ग़ैर-मामूली फ़ैसला लिखा जाता है. टास्क, माइलस्टोन और डिज़ाइन फ़ैसले कोड के बगल में एक टास्क ट्रैकर में सादे टेक्स्ट के रूप में रखे जाते हैं। जब हम ऐसे विकल्पों में से चुनते हैं जो एक से ज़्यादा टास्क पर असर डालें, तो चुनाव उसके संदर्भ और नतीजों के साथ लिखा जाता है।
- जाँचें मेरी मशीन पर चलती हैं. कोई क्लाउड CI नहीं। एक लोकल स्क्रिप्ट के चार मोड हैं:
fast,test,benchऔरfull। स्क्रिप्ट और हुक Windows और macOS दोनों पर PowerShell 7 में हैं। - हर बदलाव पर जाँच. लोकल ऑटोमेशन ऐसे बदलाव को मना करता है जिसका विवरण या फ़ॉर्मेट ख़राब हो। कोड के बदलावों पर वह तेज़ जाँच भी चलाता है; जो बदलाव सिर्फ़ नोट्स या वेबसाइट को छूते हैं, वे बिल्ड छोड़ देते हैं।
- रेफ़रेंस फ़ाइलें सुरक्षित हैं. पक्के किए गए डिटरमिनिज़्म हैश, गोल्डन सेव फ़ाइलें और बेंचमार्क बेसलाइन सिर्फ़ मेरी साफ़ मंज़ूरी से बदलती हैं, कभी चुपचाप नहीं।
- सच का स्रोत ख़ुद प्रोजेक्ट है. एक लोकल मेमोरी टूल खोज के लिए प्रोजेक्ट और पिछली बातचीत को इंडेक्स करता है, लेकिन जो भी मायने रखता है वह एक टास्क, दर्ज फ़ैसला या दस्तावेज़ भी होता है।
डिटरमिनिस्टिक कोर
सिमुलेशन एक सादी .NET लाइब्रेरी में रहता है जिसमें Godot का कोई रेफ़रेंस नहीं; Godot क्लाइंट सिर्फ़ उसकी स्थिति पढ़ता है और कमांड भेजता है। कोर तय नियमों पर चलता है: दुनिया सिर्फ़ कमांड से बदलती है, समय पूर्णांक टिक है, रैंडमनेस सिर्फ़ दुनिया के सीड वाले जनरेटरों से आती है। एक ही सीड और एक ही कमांड लॉग से एक ही दुनिया बननी चाहिए। इन नियमों की जाँच सिर्फ़ समीक्षा से नहीं, कंपाइलर और टेस्ट से होती है; कैसे, यह डेवलॉग #1 में है, और दुनिया, सेव व रीप्ले के लिए डेवलॉग #2 देखें।
- कमांड अंदर आने का इकलौता रास्ता हैं। हर एक की स्थिर टाइप id और बाइनरी एन्कोडिंग है, और हर कमांड उसके नतीजे के साथ लॉग होता है, अस्वीकार किए गए भी।
- टिक के तीन चरण तय क्रम में होते हैं। सिस्टम का क्रम कोड में एक जगह तय है, और उसे बदलने से हर हैश बदल जाता है।
- रैंडमनेस हमारे अपने जनरेटर (SplitMix64 और xoshiro256**) इस्तेमाल करती है। नाम वाली स्ट्रीम दुनिया के सीड से बनती हैं और दुनिया की स्थिति में रखी जाती हैं। डोमेन, की और टिक से चलने वाला एक बिना-स्थिति वाला की-आधारित जनरेटर क्रम से स्वतंत्र काम सँभालता है।
- स्टेट हैश डिटरमिनिज़्म जाँचों के लिए क्रम के प्रति संवेदनशील 64-बिट हैश है। यह क्रिप्टोग्राफ़िक नहीं है।
- दुनिया अलग-अलग स्तरों पर 1×1 मीटर की टाइलों का ग्रिड है; दीवारें, दरवाज़े और फ़र्श सिर्फ़ निर्माण कमांड से बदलते हैं।
- सेव और रीप्ले एक जाँचा हुआ फ़ाइल कंटेनर साझा करते हैं। रीप्ले सीड और कमांड लॉग है, रास्ते में कंट्रोल हैश के साथ, और चलाते समय क़दम-दर-क़दम जाँचा जाता है।
- बेंचमार्क बिना इंटरफ़ेस वाले सिनेरियो रनर से आते हैं, जिसमें हर मशीन की अपनी बेसलाइन और प्रति टिक शून्य मेमोरी की शर्त है।
डिज़ाइन का लक्ष्य 20 टिक प्रति सेकंड पर 1,000 तक क़ैदी और स्टाफ़ है। यह एक लक्ष्य है: अभी किरदार नहीं हैं, इसलिए बेंचमार्क रनर मौजूद है लेकिन उस पैमाने पर अभी कुछ मापा नहीं गया।