Claude Code को कितना सौंपें? बिना हादसे के स्वायत्तता की 4-स्तरीय सीढ़ी

शुक्रवार की रात मैंने Claude Code से कहा, “इस ब्लॉग के पुराने आर्टिकल में बस टूटी हुई लिंक ठीक कर दो”, और सो गया। अगली सुबह commit history देखी तो 12 आर्टिकल बदले हुए थे। लिंक सच में ठीक हो गई थीं। लेकिन साथ ही साथ heading की भाषा भी “सुधार” दी गई थी, और जो पुराने शब्द मैंने जान-बूझकर रखे थे, वे भी overwrite हो गए थे।

उसे वापस ठीक करने में मुझे 2 घंटे लगे। इतना समझदार Claude Code ऐसा फालतू काम क्यों करता है? जवाब सीधा है: मैंने उसे कभी बताया ही नहीं कि “कहां तक करना है”।

उल्टा मामला भी है। डर के मारे मैंने ऐसी सेटिंग कर दी कि हर एक लाइन सुधारने पर वह पूछे, “यह चला दूं?” तो 30 मिनट में ही approval बटन दबाते-दबाते थक गया, और आखिरकार खुद लिखना ज्यादा तेज़ पड़ा। या तो बहुत सौंपकर हादसा, या बहुत रोककर थकान। ज़्यादातर लोग इन्हीं दो छोरों के बीच भटकते रह जाते हैं।

यह आर्टिकल उसी भटकाव को खत्म करने वाली “स्वायत्तता की 4-स्तरीय सीढ़ी” के बारे में है। सिर्फ पढ़ना, सुधारना, प्रकाशित करना, और सिर्फ इंसान को छूने देना — ये चार रेखाएं शुरू में ही खींच दें, तो हर बार का फैसला लगभग गायब हो जाता है।

मुख्य बातें

• Claude Code को सौंपने वाले काम को खतरे के हिसाब से 4 स्तरों में बांटें, तो फैसला आसान हो जाता है। सिर्फ पढ़ना / वापस लाने लायक edit / प्रकाशन-deploy / सिर्फ इंसान का।
• हर स्तर के लिए “काम पूरा होने का सबूत” एक ज़रूर तय करें। diff दिखे, build pass हो, public URL सही हो, वगैरह।
• delete, production data, billing और force push को आदत पड़ने पर भी automatic न करें। यहीं हर बार इंसान का बटन दबे।
• स्तरों को एक YAML फ़ाइल में लिखकर CLAUDE.md के पास रखें, तो Claude Code खुद बता सकता है कि “अभी कौन सा स्तर है”।
• शुरुआत एक स्तर नीचे से करें, और जो operation सुरक्षित सिद्ध हो जाए, सिर्फ उसे बाद में ऊपर चढ़ाएं। उल्टा कभी न करें।

“समझदारी” से ज़्यादा “रेखा खींचना” क्यों ज़रूरी है

Claude Code में अटकने वाले ज़्यादातर लोग मॉडल की performance से नहीं, बल्कि काम को बंद करने के तरीके से चूकते हैं। शुरुआत में मैं भी ऐसा ही था। निर्देश खुद बुरा नहीं था। बस “सिर्फ लिंक” वाला दायरा मैंने केवल वाक्य में बताया था। वाक्य में दी गई request व्यस्त सुबह सहकर्मी को मुंहज़बानी दिए निर्देश जैसी होती है — उसका मतलब आसानी से इधर-उधर हो जाता है।

यहीं खतरे के हिसाब से रेखा खींचना काम आता है। क्या करना ठीक है, यह “request के शब्दों” से नहीं बल्कि “स्तर” से तय करें। फिर जब भी Claude Code कुछ करने जाए, आप मिला सकते हैं कि “यह कौन से स्तर का operation है”। धुंधले हिंदी वाक्य की व्याख्या वाली लड़ाई की जगह, एक मशीनी जांच आ जाती है।

यह सोच नई नहीं है। फ़ैक्ट्री में भी सिर्फ देखने आया आदमी, पुर्ज़े जोड़ने वाला, shipping बटन दबाने वाला और तिजोरी खोलने वाला — सबके अधिकार शुरू से ही अलग होते हैं। Claude Code के लिए भी बस वही रेखा खींचनी है।

4 स्तरों के अंदर क्या है

मैं असल में जो 4 स्तर इस्तेमाल करता हूं, वे ये हैं। पहले एक टेबल में पूरी तस्वीर दे देता हूं।

स्तर	क्या करवाना है	पूरा होने का सबूत
0 सिर्फ पढ़ना	फ़ाइल structure समझना, जोखिम छांटना, जांच कमांड सुझाना	आखिरी नोट में “पढ़ी गई फ़ाइलों की सूची” हो
1 वापस लाने लायक edit	एक आर्टिकल का सुधार, एक test का update	diff दिखे और build pass हो
2 प्रकाशन-deploy	build के बाद deploy, public URL की जांच	h1, canonical URL, CTA और rollback तरीका — सब मौजूद
3 सिर्फ इंसान	(Claude Code से नहीं करवाना)	—

स्तर 3 में आते हैं secret key, billing, production data और force push। यहां चाहे जितनी आदत पड़ जाए, automatic नहीं करते। गलती होने पर होने वाला नुकसान, बचने वाली मेहनत के सामने बहुत बड़ा होता है।

हर स्तर में सबसे ज़रूरी है “पूरा होने का सबूत” पहले से तय कर लेना। सबूत न हो, तो Claude Code “हो गया” कह दे फिर भी पता नहीं चलता कि सच में हुआ या नहीं। diff दिखे, build pass हो, public URL खोलने पर h1 सही हो — ऐसी मशीन से जांची जा सकने वाली चीज़ को सबूत बनाएं।

AI को सौंपने का दायरा, और इंसान के तय करने का दायरा

रेखा साफ हो जाए, तो काम का बंटवारा भी अपने आप तय हो जाता है।

Claude Code को वही सौंपें जो हाथ का काम ज़्यादा हो और नतीजा मशीन से जांचा जा सके। ढेर सारी फ़ाइलें पढ़कर सारांश बनाना, तय फ़ॉर्मैट में आर्टिकल सुधारना, test चलाकर log पढ़ना। ये सब इंसान से तेज़ और सटीक होते हैं।

इंसान को वही तय करना चाहिए जो वापस न लाया जा सके और जिसका नुकसान बड़ा हो। क्या यह आर्टिकल सच में प्रकाशित करना ठीक है, क्या यह पुराना शब्द मिटाना ठीक है, क्या यह customer data overwrite करना ठीक है। यहां Claude Code से “सुझाव” तो लें, पर “execute” का बटन इंसान दबाए।

उलझन में एक ही कसौटी है: “गलती हो जाए तो क्या 10 मिनट में वापस ला सकते हैं?” वापस ला सकें तो स्तर 1, न ला सकें तो स्तर 2 या 3। शुरुआत वाला मेरा हादसा, जिसे वापस लाने में 2 घंटे लगे, असल में स्तर 2 की सावधानी मांगने वाला काम था।

कॉपी-पेस्ट करने लायक स्तर की परिभाषा

स्तरों को सिर्फ दिमाग में रखेंगे तो आखिर में डगमगा जाते हैं। उन्हें एक YAML फ़ाइल में लिखकर, project की जड़ में autonomy.yml के नाम से रखें। CLAUDE.md से इसे पढ़वाएं, तो Claude Code खुद कहने लगेगा, “अभी स्तर 1 है, इसलिए प्रकाशन नहीं करूंगा”।

# autonomy.yml — Claude Code को दी जाने वाली स्वायत्तता की रेखा
safe_autonomy_ladder:
  level_0_read_only:
    allowed: ["फ़ाइल structure समझना", "जोखिम छांटना", "जांच कमांड सुझाना"]
    proof: "आखिरी नोट में पढ़ी गई फ़ाइलों की सूची हो"
  level_1_reversible_edit:
    allowed: ["एक आर्टिकल सुधारना", "एक test update करना"]
    proof: "git diff दिखे और build pass हो"
  level_2_publish_or_deploy:
    allowed: ["build के बाद deploy", "public URL की जांच"]
    proof: "h1, canonical URL, CTA और rollback तरीका — सब मौजूद"
  level_3_owner_only:
    allowed: []
    examples: ["secret key", "billing", "force push", "customer data"]

CLAUDE.md में बस यह एक वाक्य जोड़ देना काफ़ी है।

काम शुरू करने से पहले autonomy.yml पढ़ो, और इस बार का काम किस स्तर का है, सबसे पहले घोषित करो।
स्तर 2 या उससे ऊपर का operation execute मत करो, इंसान की approval का इंतज़ार करो।

स्तर को मशीन से जांचने वाली verification script

सिर्फ घोषणा करवाने से भरोसा नहीं होता, इसलिए मैं मशीन से देखता रहता हूं कि “स्तर 2 का operation (प्रकाशन) बिना सबूत के तो नहीं हुआ”। नीचे की script deploy के बाद public URL लाती है, और जांचती है कि h1 खाली तो नहीं और canonical URL आपकी अपनी slug की ओर इशारा कर रहा है या नहीं। Node.js 18 या उससे ऊपर हो तो यह सीधे चल जाती है।

// verify-publish.mjs — स्तर 2 के "पूरा होने के सबूत" को मशीन से जांचो
// उपयोग: node verify-publish.mjs https://claudecode-lab.com/blog/your-slug

const url = process.argv[2];
if (!url) {
  console.error("public URL को argument में दीजिए");
  process.exit(1);
}

const res = await fetch(url);
if (res.status !== 200) {
  console.error(`HTTP ${res.status}: अभी प्रकाशित नहीं हुआ`);
  process.exit(1);
}

const html = await res.text();

// क्या h1 मौजूद है और उसमें कुछ content है
const h1 = html.match(/<h1[^>]*>(.*?)<\/h1>/s);
const hasH1 = Boolean(h1 && h1[1].replace(/<[^>]+>/g, "").trim());

// क्या canonical URL इसी page की ओर इशारा कर रहा है
const canonical = html.match(/<link[^>]+rel=["']canonical["'][^>]*>/i);
const canonicalOk = Boolean(canonical && canonical[0].includes(new URL(url).pathname));

console.log(`h1 मौजूद:        ${hasH1 ? "OK" : "NG"}`);
console.log(`canonical मिला:  ${canonicalOk ? "OK" : "NG"}`);

if (hasH1 && canonicalOk) {
  console.log("स्तर 2 के सबूत पूरे। प्रकाशन पूरा माना जा सकता है।");
} else {
  console.error("सबूत अधूरे हैं। अभी पूरा मत मानिए।");
  process.exit(1);
}

सिर्फ HTTP 200 को सफलता मान लें, तो top page का fallback या पुराना आर्टिकल दिख रहा हो तो भी पता नहीं चलेगा। h1 और canonical URL तक देखकर ही “यह स्तर पूरा हुआ” कहा जा सकता है।

ऐसे मौकों पर यह काम आता है (3)

1. नई repository में घुसते ही structure और कमांड पता न होने की हालत में सीधे edit करवाएं, तो config फ़ाइल टूटने का डर रहता है। पहले सिर्फ स्तर 0 की इजाज़त दें, और फ़ाइल structure, चलने वाले कमांड और छूने पर खतरनाक जगहें report करवाएं। नक्शा बन जाए, तब स्तर 1 पर चढ़ाएं।

2. आर्टिकल की typo ठीक करना इसके लिए स्तर 1 काफ़ी है। diff दिखे और build pass हो जाए तो सबूत पूरा। शुरुआत वाला मेरा हादसा, यहां “सुधार सिर्फ typo का। वाक्य की भाषा मत बदलो” लिखकर दायरा साफ कर देता तो टल जाता। Claude Code को देने वाली request का खाका ऐसा है।

स्तर 1 पर काम करो।
लक्ष्य: content/blog/foo.mdx में सिर्फ साफ़ typo
मत करो: heading की भाषा बदलना, वाक्य का रूप बदलना, दूसरी फ़ाइल का edit
पूरा होने पर git diff दिखाओ, और खुद जांचो कि बदलाव सिर्फ typo सुधार ही है।

3. production प्रकाशन से ठीक पहले स्तर 2 में ज़रूर जांच करवाएं कि build pass होता है या नहीं, environment variable पूरे हैं या नहीं, diff उम्मीद जैसा है या नहीं, और rollback तरीका है या नहीं। आखिर में ऊपर वाली verification script चला दें, तो public URL के अंदर तक जांच हो जाती है।

मेरी की हुई 3 गलतियां

ईमानदारी से कहूं तो इन 4 स्तरों तक पहुंचने में मैं कई बार हादसे का शिकार हुआ।

पहली, स्तरों को एक झटके में छोड़ देना। स्तर 0 छोड़कर सीधे स्तर 1 पर ढेर सारा edit करवाया, तो इतना बड़ा diff बन गया कि जांचना मुश्किल हो गया, और खुद को भी पता न चला कि कहां सही है। अब मैं हमेशा 0 से क्रम में ही ऊपर चढ़ता हूं।

दूसरी, सिर्फ local build से “पूरा” मान लेना। हाथ में pass हो गया, इसलिए प्रकाशित कर दिया। पर production में पुराना page दिख रहा था, और आधे दिन तक पता नहीं चला। उसके बाद से public URL का h1 और canonical देखे बिना मैं पूरा नहीं मानता।

तीसरी, approval के लिए सिर्फ अपनी आंखों पर भरोसा करना। “आखिर में मैं खुद check कर लूंगा” थकी हुई रात में ज़रूर टूट जाता है। शब्द-गिनती, टूटी लिंक, type error जैसी मशीन से पकड़ी जाने वाली जांच को स्तर के “सबूत” में जोड़ने के बाद, रात की चूक बहुत कम हो गई।

शुरू कैसे करें

सीधे पूरी तरह automatic समझदार agent बनाने का लक्ष्य मत रखिए। गलती हो जाए तो वापस लाने लायक छोटा सा काम एक चुनिए। draft की typo जांच, बदलाव की पहली समीक्षा, staging प्रकाशन से पहले की जांच। बस इतना ही ठीक रहता है।

क्रम हमेशा एक ही रहता है। (1) पढ़ने का दायरा छोटा तय करें (2) नतीजा साफ़ करें (3) जांच जितना हो सके कमांड से करवाएं (4) खतरनाक operation (delete, production data, billing, force push) को शुरू में पूरी तरह “इंसान से पूछो” पर रखें। जो operation सुरक्षित सिद्ध हो जाए, सिर्फ उसी को बाद में एक-एक स्तर ऊपर चढ़ाएं। उल्टी दिशा में नीचे उतारना नहीं करते।

permission की बारीक सेटिंग में अटकें तो पहले Claude Code की शुरुआती मार्गदर्शिका देख लें, और CLAUDE.md में स्तर के नियम लिखने का तरीका CLAUDE.md लिखने का तरीका में मिलेगा — फिर ये 4 स्तर सीधे सेटिंग में उतर जाएंगे। अगर इरादा गैर-इंजीनियर साथियों को टीम में जोड़ने का है, तो गैर-इंजीनियर के लिए उपयोग भी साथ में देख लीजिए।

अक्सर पूछे जाने वाले सवाल

Q. स्तर बांटना क्या हर बार हाथ से सेट करना पड़ता है? नहीं। एक autonomy.yml बनाकर CLAUDE.md से पढ़वा दें, तो आगे से Claude Code खुद घोषित करेगा, “अभी स्तर 1 है”। सेटिंग सिर्फ पहली बार की है।

Q. क्या स्तर 2 “प्रकाशन” तक automatic करना ठीक है? अगर सबूत मशीन से पूरे हो जाएं, तो आदत पड़ने पर automatic करना ठीक है। पर ऊपर वाली verification script की तरह public URL के अंदर की जांच का इंतज़ाम ज़रूर बीच में रखें। सिर्फ HTTP 200 पर भरोसा करना सबसे खतरनाक है।

Q. स्तर 3 में डालने लायक operation कैसे पहचानें? “गलती हो तो माफ़ी से काम चल जाएगा, या हर्जाना देना पड़ेगा” से सोचें तो जल्दी पता चलता है। customer data overwrite, billing, production का delete — ये दूसरी श्रेणी में हैं, इसलिए स्तर 3। आदत पड़ने पर भी automatic नहीं।

Q. छोटी टीम में भी रेखा खींचनी ज़रूरी है? उल्टा, जितने कम लोग, उतना ज़्यादा असर। किसने approval दी, यह आसानी से धुंधला हो जाता है, इसलिए स्तर वाली टेबल साझा रखें तो “यह किसकी OK से होने वाला operation है” एक नज़र में दिख जाता है।

Q. prompt अच्छा बना लें तो स्तर बांटने की ज़रूरत ही नहीं? prompt की व्याख्या डगमगाती है। अच्छी request लिखने की कला अलग से प्रॉम्प्ट का व्यावहारिक अभ्यास में बढ़ाते रहिए, पर स्तर बांटना “शब्दों की कुशलता पर निर्भर न रहने वाला सुरक्षा-जाल” है। दोनों साथ हों तो सबसे मज़बूत।

असल में आज़माने पर क्या हुआ

इन 4 स्तरों को अपने ब्लॉग के संचालन में डालने के बाद, शुरुआत वाला “बिना कहे काम कर देने” जैसा हादसा शून्य हो गया। मैंने दो बातें जांचीं।

एक, autonomy.yml को CLAUDE.md से पढ़वाया तो Claude Code काम से पहले खुद घोषित करने लगा, “इस बार स्तर 1 है, इसलिए प्रकाशन नहीं करूंगा”। रेखा को वाक्य की जगह स्तर से देने पर व्याख्या डगमगाती नहीं — यह मैंने महसूस किया।

दूसरा, verify-publish.mjs को प्रकाशन के बाद हमेशा चलाने लगा, तो पहले जिस “पुराना page production में दिखने” वाली समस्या का आधे दिन तक पता नहीं चलता था, वह प्रकाशन के तुरंत बाद पकड़ में आने लगी। बस h1 और canonical URL देख लेने से HTTP 200 का गड्ढा भर जाता है।

समझदार मॉडल ढूंढने से पहले, गिरने पर भी चोट न लगने वाली सीढ़ी तय कर लें। घुमावदार लगता है, पर यही सबसे तेज़ रास्ता है — आज मेरा यही अनुभव है। टीम में Claude Code के permission नियम तय करने की स्थिति में हों, तो प्रशिक्षण और परामर्श में हम साथ मिलकर रेखा design कर सकते हैं। official permission सेटिंग के लिए Anthropic का दस्तावेज़ भी साथ में देख लीजिए।