Claude Code को आज कहाँ तक काम सौंपें? approval lines तय करने की 4-स्तरीय worksheet

शुक्रवार की शाम थी। मेरा इरादा बस staging environment में एक छोटा सा सुधार डालने का था।

मैंने सिर्फ़ इतना कहा — “documentation की एक typo ठीक कर दो, और साथ में देख लेना कि build पास होती है या नहीं।” Claude Code ने typo तो ठीक कर दी, लेकिन उसके बाद उसने अपने आप दो dependency packages update कर दिए, और .env.production के reference तक बदल डाले। Local build पास हो रही थी, इसलिए AI ने बेफ़िक्र होकर कहा — “हो गया।”

मेरे दिल में धक्का तब लगा जब मैंने आख़िर तक diff देखे बिना यह सब नोटिस ही नहीं किया। ग़लती AI की नहीं थी — असली वजह यह थी कि “कहाँ तक करना ठीक है” यह मैंने एक बार भी शब्दों में नहीं कहा था।

इसका उल्टा भी होता है। एक और दिन “allow करें? Yes/No” का सवाल लगातार 30 बार आया, और सिर्फ़ एक commit बनाने में ही मेरी सारी हिम्मत निकल गई। दायरा ज़्यादा खोलो तो हादसा, ज़्यादा बाँधो तो काम आगे ही न बढ़े। यह लेख उसी बीच में सही line खींचने वाली एक worksheet के बारे में है।

मुख्य बातें

• Claude Code को सौंपे जाने वाले काम को “सिर्फ़ पढ़ना”, “सिर्फ़ सुधारना”, “publish करना”, “secret जानकारी छूना” — इन 4 स्तरों में बाँटें।
• हर स्तर के लिए पहले से तय करें कि “आख़िरी OK कौन देगा” और “क्या देखकर हम इसे safe कह सकते हैं (यानी proof)।”
• स्तर 0 और 1 AI को सौंपें, स्तर 2 पर इंसान जाँचे, स्तर 3 पर सिर्फ़ ज़िम्मेदार व्यक्ति ही हाथ लगाए।
• सुबह एक वाक्य में “आज यहाँ तक” घोषित करके काम शुरू करें — approval की संख्या एकदम घट जाती है।
• copy-paste करने योग्य ledger code और हर सुबह 1 मिनट में फ़ैसला करने वाला template नीचे दिया है।

“approval का बजट” पहले से क्यों तय करें

approval में थकान की वजह Claude Code की performance नहीं है। असली वजह है — आज कहाँ तक छूट देनी है, यह तय किए बिना ही दौड़ना शुरू कर देना।

जब तय नहीं होता, तो इंसान दो में से किसी एक तरफ़ झुक जाता है। झंझट लगती है तो हर चीज़ पर “allow” दबाते रहो, और किसी दिन कोई ख़तरनाक operation भी पास हो जाए। या फिर इतने सावधान हो जाओ कि typo सुधारने तक पर पुष्टि माँगो और काम रुक जाए। दोनों में एक बात समान है — फ़ैसला “उस वक़्त के mood” पर छोड़ देना।

यहीं “approval का बजट” वाली सोच काम आती है। पैसों के बजट की तरह — आज इस lane तक छूट, उसके आगे इंसान तय करेगा — यह दायरा पहले से बना लो। दायरा हो तो AI के हर जवाब पर दिल धड़कने की ज़रूरत नहीं रहती। तब देखना यह नहीं होता कि “AI कितना समझदार है”, बल्कि यह कि “वह किस lane पर रुका।”

फ़ैसले की कसौटी शब्दों में लिखी हो तो team में भी झगड़ा नहीं होता। “बस यूँ ही डर लगा इसलिए रोका” के बजाय “यह स्तर 2 है, इसलिए अब इंसान के जाँचने की बारी है” कहा जा सकता है। permission design की मूल सोच पर Claude Code शुरुआती गाइड में भी बात की है, पर यहाँ हम ज़्यादा ज़मीनी “आज की line” पर ही ध्यान देंगे।

सौंपे जाने वाले काम को 4 स्तरों में बाँटें

सबसे पहले, Claude Code से कराए जाने वाले कामों को ख़तरे के हिसाब से 4 स्तरों में छाँट लें। ज़्यादा सोचने की ज़रूरत नहीं — सिर्फ़ तीन बातें देखें: “क्या इसे वापस पलटा जा सकता है”, “क्या यह सार्वजनिक होगा”, “क्या यह पैसे या secret को छूता है।“

स्तर	काम का उदाहरण	आख़िरी OK कौन दे	safe कहने का proof
0	फ़ाइल पढ़ना, structure समझना	AI को सौंपें	पढ़े गए हिस्से की सूची
1	पलटने योग्य 1 फ़ाइल सुधारना	AI (इंसान diff देखे)	diff और build परिणाम
2	live साइट पर लागू करना	इंसान तय करे	public URL और rollback तरीका
3	secret, billing, customer data छूना	सिर्फ़ ज़िम्मेदार व्यक्ति	लिखित approval

इस तालिका का असली दम दाईं दो columns में है। “OK कौन देगा” और “क्या देखकर safe कहा जाए” — ये दोनों काम शुरू करने से पहले तय कर लें। बाद में तय करोगे तो AI के “हो गया” वाले जोश में बहकर जाँच छोड़ बैठोगे।

स्तर 1 का “पलटने योग्य” वाला हिस्सा अहम है। typo सुधार या comment जोड़ना — ग़लती हो भी जाए तो तुरंत वापस लाया जा सकता है। इसलिए AI को सौंपो, इंसान बस diff पर एक नज़र डाल ले, बस। दूसरी ओर, dependency package update को स्तर 2 पर चढ़ा दो। देखने में छोटा लगे, पर उसका असर कहाँ तक फैलेगा यह पढ़ा नहीं जा सकता। शुरुआत में जो हादसा मुझसे हुआ, उसकी जड़ यही थी कि मैंने इसे स्तर 1 मान लिया था।

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

line को थोड़ा और साफ़ करते हैं। AI को वही सौंपा जा सकता है जो ग़लती होने पर तुरंत पता चले और तुरंत वापस लाया जा सके। इंसान को वही तय करना चाहिए जो एक बार चलने पर बाहर तक असर डाले।

• AI को सौंपें: पढ़ना, जाँचना, draft बनाना, पलटने योग्य 1 फ़ाइल सुधारना, test चलाना
• इंसान आख़िर में तय करे: publish करना, production data बदलना, बाहरी service में register करना, dependency update करना, delete करना

संदेह हो तो स्तर एक चढ़ा दो। बस इतना याद रखो तो बड़ी चूक नहीं होगी। जिस operation पर पक्का भरोसा हो जाए, सिर्फ़ उसे बाद में एक-एक स्तर नीचे लाकर automate करते जाओ। शुरू से ही पूरी तरह automatic की ओर मत भागो — यही असली तरकीब है। यह “धीरे-धीरे ऊपर चढ़ाना” वाली सोच project के नियम लिखने वाली CLAUDE.md लिखने का तरीका के साथ भी अच्छी बैठती है, इसलिए तय की हुई line को फ़ाइल में दर्ज कर रखो तो उसे दोबारा दोहराया जा सकता है।

copy-paste करने योग्य approval ledger

सिर्फ़ शब्दों में रहे तो भूल जाते हैं। इसलिए चारों स्तरों को मशीन के पढ़ने लायक रूप में डालकर, “आज कहाँ तक” को filter से निकाल सकें — ऐसा बना लेते हैं। Node.js हो तो यह सीधे चल जाता है।

// approval ledger: हर काम के साथ "ख़तरे का स्तर", "ज़िम्मेदार" और "proof" रखें
const approvalBudget = [
  { action: "फ़ाइल पढ़ना",              level: 0, owner: "AI",            proof: "पढ़े गए हिस्से की सूची" },
  { action: "पलटने योग्य 1 फ़ाइल सुधारना", level: 1, owner: "AI (इंसान जाँचे)", proof: "diff और build परिणाम" },
  { action: "live साइट पर लागू करना",     level: 2, owner: "इंसान",         proof: "public URL और rollback तरीका" },
  { action: "secret या billing छूना",    level: 3, owner: "सिर्फ़ ज़िम्मेदार",  proof: "लिखित approval" },
];

// आज की सीमा। 0 हो तो सिर्फ़ पढ़ना, 1 हो तो पलटने योग्य सुधार तक AI को सौंपें
const todayMax = Number(process.env.APPROVAL_MAX ?? 1);

const allowedToday = approvalBudget.filter((item) => item.level <= todayMax);
const needsHuman   = approvalBudget.filter((item) => item.level > todayMax);

console.log(`आज AI को सौंपने की सीमा: स्तर ${todayMax}`);
console.table(allowedToday);
console.log("इंसान के तय करने वाले काम:");
console.table(needsHuman);

चलाना बस इतना ही है। environment variable से “आज की सीमा” बदली जा सकती है।

# आज "पलटने योग्य सुधार" तक सौंपें
APPROVAL_MAX=1 node approval-budget.mjs

# आज सिर्फ़ पढ़ने तक सीमित रखें
APPROVAL_MAX=0 node approval-budget.mjs

field के नाम वैसे ही रखकर, action और proof के अंदर का हिस्सा अपने project के हिसाब से बदल लें। Claude Code को यह code देकर “मेरी repository के लिए values भर दो” कहें तो एक शुरुआती ढाँचा तुरंत बन जाता है।

हर सुबह 1 मिनट में तय करने वाला prompt template

ledger बन जाए तो काम शुरू करने से पहले AI को “आज का दायरा” बता दें। नीचे का वाक्य copy करके बस ख़ाली जगहें भरनी हैं।

आज के काम का दायरा पहले तय कर रहा हूँ।

- आज का मक़सद: (जैसे: एक blog लेख की typo और टूटे link ठीक करना)
- पढ़ने की छूट: सिर्फ़ site/src/content/blog/
- सुधारने की छूट: ऊपर में से सिर्फ़ 1 फ़ाइल (केवल पलटने योग्य बदलाव)
- चलाने की छूट वाले command: npm run lint, test चलाना
- मत छूना: .env, production deploy, dependency update, delete

नियम:
- स्तर 2 या उससे ऊपर (publish, production data, dependency update, delete) पर हमेशा मुझसे पूछकर रुकना।
- सुधारने के बाद बदलाव का diff और build परिणाम "proof" के रूप में आख़िर में दिखाना।
- सिर्फ़ "हो गया" कहकर मत रुकना; किस command से जाँचा यह भी लिखना।

बस इतना एक वाक्य होते ही AI “सब कुछ कर डालता हूँ” वाली आदत छोड़कर दायरे के अंदर काम करने लगता है। आदत पड़ जाए तो यही बात CLAUDE.md लिखने का तरीका के मुताबिक project की rule फ़ाइल में डाल दो, तो हर सुबह paste करने की झंझट भी ख़त्म।

ऐसी जगहों पर काम आता है (3 उदाहरण)

1. Blog या material की thok जाँच सिर्फ़ “लेख ठीक कर दो” कहो तो AI body, image path और link — सबको एक साथ बदल डालता है। approval ledger में “body की typo स्तर 1, publish करना स्तर 2” बाँट रखो तो लिखाई AI को सौंपते हुए भी publish वाला बटन अपने हाथ में रहता है। diff और build परिणाम proof के रूप में निकलवा लो तो रात की दोबारा जाँच काफ़ी आसान हो जाती है।

2. आई हुई पूछताछ की छँटाई आई हुई पूछताछ पढ़कर वर्गीकृत करना स्तर 0 है, AI को सौंपा जा सकता है। लेकिन customer ledger में entry करना स्तर 3 है। AI भले “यह सौदे में बदल सकता है” तय कर ले, production database में लिखना तब तक रुका रहे जब तक ज़िम्मेदार व्यक्ति ख़ुद बटन न दबाए। यह ledger से लागू करवा दो तो ग़लत वर्गीकृत customer को अपने आप register कर देने वाला हादसा ख़त्म।

3. deploy से पहले एक साँस publish वाला काम हमेशा स्तर 2 पर रखो। सिर्फ़ local build पास होने पर “हो गया” मत मानो — public URL, heading और rollback तरीका जाँचने तक रुको। शुरुआत में मुझसे हुआ “dependency का अपने आप update हो जाना” भी, स्तर 2 साफ़ लिखा होता तो ज़रूर इंसान की जाँच पर रुकता।

आम ठोकरें और उनका इलाज

सबसे आम ठोकर यह है — सब कुछ एक ही अनुरोध में निपटाने की कोशिश करना और इतना बड़ा diff बना देना जिसे कोई verify ही न कर सके। इलाज सीधा है: अनुरोध को “एक बार में एक नतीजा” तक सीमित करो। एक लेख, एक PR, एक setting जगह। छोटा-छोटा बाँटो तो diff आख़िर तक पढ़ा जा सकता है।

दूसरी आम ठोकर — सिर्फ़ local build सफल होने को ही पूरा मान लेना। live साइट पर तो कोई और page या home दिख रही हो, और तुम सिर्फ़ HTTP 200 देखकर निश्चिंत हो जाओ। proof वाले column में “public URL और heading की जाँच” डाल रखो तो यहीं रुक जाओगे।

तीसरी ठोकर — क्या आज़माया, यह दर्ज न करना। अगले दिन वही फ़ैसला शुरू से दोहराना पड़ता है। नीचे बताई गई note की बस एक line दर्ज कर दो तो अगले दिन का तुम्हारा रूप उलझता नहीं। Claude Code से माँगने का तरीका ही बेहतर करना हो तो advanced prompt design भी साथ पढ़ लो, तो दायरा बताने का अंदाज़ एक कदम और निखर जाएगा।

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

Q. approval के स्तर और बारीकी से बाँटूँ तो बेहतर है? शुरू में 4 स्तर ही काफ़ी हैं। जितना बढ़ाओगे, संचालन उतना उलझेगा और आख़िर में कोई पालन ही नहीं करेगा। चलाकर देखो, और जहाँ “यहाँ मोटापन है” लगे, सिर्फ़ वहीं बाद में शाख़ें फोड़ना।

Q. स्तर 1 का “पलटने योग्य” है या नहीं, कैसे पहचानूँ? दो बातों से तय करो: “क्या git के एक command से वापस लाया जा सकता है” और “क्या बाहर असर पड़ता है।” फ़ाइल edit वापस आ सकती है, पर deploy, billing, mail भेजना और delete वापस नहीं आते। संदेह हो तो स्तर 2 पर चढ़ा दो।

Q. team में इस्तेमाल करते समय स्तर कौन तय करे? काम शुरू करने वाला सुबह घोषणा करे, और स्तर 2 या ऊपर के फ़ैसले लेने वाला पहले से तय हो। ज़िम्मेदार व्यक्ति मौजूद न हो तो उस दिन स्तर 3 का काम न करें — यह तय रखो तो safe रहेगा।

Q. हर बार prompt paste करना झंझट लगता है। दायरा पक्का हो जाए तो उसे project की rule फ़ाइल (CLAUDE.md) में डाल दो। AI हर बार उसे पढ़ लेता है, इसलिए paste करने की ज़रूरत ख़त्म।

Q. क्या non-engineer भी यह worksheet इस्तेमाल कर सकता है? हाँ। code चलाए बिना भी, 4 स्तरों की तालिका और prompt template से line खींची जा सकती है। engineer के अलावा उपयोग के लिए non-engineers के लिए Claude Code भी काम का है।

handoff के लिए note

उस दिन का फ़ैसला एक line में दर्ज कर रखो तो अगले दिन तुम या team वही उलझन दोबारा नहीं दोहराते। नीचे का रूप copy करके बस भरना है।

- तारीख़: 2026-06-07
- आज का मक़सद: एक blog लेख की typo और टूटे link का सुधार
- आज की सीमा: स्तर 1 (पलटने योग्य सुधार तक)
- proof: diff, npm run build का log, public URL की heading जाँच
- इंसान ने कहाँ रोका: dependency update (स्तर 2 होने से रोका)
- अगली बार के लिए संदेश: dependency update अलग दिन इकट्ठा स्तर 2 में करें

यह note हो तो publish के बाद की जाँच भी आसान। सिर्फ़ HTTP 200 काफ़ी नहीं — public URL पर heading, canonical URL, hero image और body की शुरुआत वाक़ई इसी लेख की हैं या नहीं, यहाँ तक देखो। कोई और लेख या home दिखे तो उसे unpublished मानकर build और deploy दोबारा करो। permission design की आधिकारिक सोच Anthropic आधिकारिक documentation में भी देखी जा सकती है।

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

मैंने यह worksheet अपने blog के संचालन पर 2 हफ़्ते लागू करके देखी।

सबसे ज़्यादा असर इस बात का हुआ कि सुबह “आज स्तर 1 तक” वाला एक वाक्य paste करने लगा। बस इतने से ही प्रति commit “allow करें?” की संख्या महसूस में आधी से भी कम हो गई। AI जब स्तर 2 या ऊपर में घुसने की कोशिश करता, तो template के नियम के मुताबिक ठीक से रुककर मुझसे पूछता। शुरुआत वाला “नज़र हटते ही dependency update हो गया” जैसा हादसा उसके बाद से शून्य रहा।

उल्टा यह भी समझ आया कि स्तरों की तालिका सिर्फ़ बना लेने से इस्तेमाल नहीं होती। ledger वाला code सचमुच चलाकर “आज सौंपने वाला काम” स्क्रीन पर निकालकर शुरू करो तो पालन होने की संभावना बढ़ जाती है। समझदार AI ढूँढने के बजाय, गिरने पर भी वापस लाने योग्य दायरा पहले खींच लो। बात फीकी सी है, पर अभी मेरा यही अनुभव है कि बिना तनाव सबसे ज़्यादा भरोसे से काम यही सौंपने देता है।

इस line को पूरी team या production संचालन तक फैलाना हो तो training एवं consultation में ठोस lane design साथ बैठकर तय किया जा सकता है। फ़िलहाल कल सुबह “आज स्तर 1 तक” वाला एक वाक्य paste करने से शुरुआत करके देखो।