पुराने repo में Claude Code का पहला दिन: कुछ तोड़े बिना पहली task कैसे चुनें

नौकरी के तीसरे दिन मुझे payment से जुड़ा करीब 150 file का codebase थमा दिया गया। documentation लगभग शून्य। जिससे भी पूछो, सब यही कहते — “चल रहा है, ज्यादा मत छेड़ो।” मैंने सोचा चलो Claude Code से ही कह देता हूं: “इस repo को समझ लो और जो ठीक करने लायक लगे, ठीक कर दो।”

10 मिनट बाद Claude ने बड़े भरोसे से जवाब दिया — “20 files साफ कर दीं।” diff खोलते ही मेरे होश उड़ गए। migration वाली SQL file का formatting बदल दिया था, .env.example को दोबारा sort कर दिया था, और payment retry का wait time खुद से “optimize” करके आधा कर दिया था। code चल तो रहा था। पर अगर यह production में चला जाता, तो double-charge की शिकायतों से फोन बजना बंद नहीं होता।

दिक्कत Claude की समझदारी में नहीं थी। दिक्कत बस यह थी कि पहले दिन मैंने जो दायरा दिया, वह बहुत बड़ा था। किसी और के बड़े code को सुरक्षित रूप से सौंपना है, तो समझदार AI ढूंढने से पहले 30 मिनट में यह तय कर लो — “क्या पढ़ना है, क्या नहीं छूना है, पहली छोटी task क्या है, और हो गया कैसे पता चलेगा।” इतना भर कर लें तो पहले दिन के हादसे लगभग खत्म। आज उसी 30 मिनट की पूरी रेसिपी, copy-paste लायक रूप में।

मुख्य बातें

• पुराने code का पहला दिन: “सब देखकर ठीक कर दो” सबसे खतरनाक निर्देश है, क्योंकि दायरा धुंधला रहता है।
• पहले 30 मिनट में बनाना है design document नहीं, बल्कि पहली task सुरक्षित रूप से चुनने के लिए एक पन्ने की memo।
• memo में सिर्फ चार चीजें: पढ़ने का क्रम, न छूने वाली जगहें, पहली छोटी task, और “हो गया” तय करने वाली जांच commands।
• पहली task को “आसानी से वापस लौटने लायक” जगह तक सीमित रखें — text, button का label, test का नाम बढ़िया रहते हैं।
• AI को सौंपें “पता लगाना और draft बनाना” तक। production DB, billing, delete और publish बटन इंसान दबाए।

पहले निर्देश पर ही क्यों लड़खड़ाते हैं

Claude Code तेज है। तेज है इसीलिए, शुरू में जो जानकारी आप दें वह जितनी चौड़ी होगी, बेकार से बेकार diff भी यह पूरी ताकत से बना देगा।

इंसान नया कर्मचारी होता तो पूछता “यह छूना ठीक है क्या?” AI नहीं पूछता। मदद के जोश में दायरा खुद बढ़ा देता है। “साफ कर दो” कहो तो सचमुच कोने-कोने तक साफ करता है। migration का formatting भी, payment retry का “optimization” भी — उसे लगता है वह भला ही कर रहा है।

इसलिए पहले दिन का काम पूरा code पढ़ना या शानदार improvement plan बनाना नहीं है। पहले दिन का काम है सीमा खींचना। कहां तक खुद से करना ठीक है, कहां से इंसान से पूछना है। यह लकीर पहले खींच दें तो Claude को दी जाने वाली request “जो ठीक लगे करो” से बदलकर “इस दायरे में करो और सबूत छोड़ो” हो जाती है। लकीर खींचने में 30 मिनट लगते हैं। पूरा code समझने की जरूरत नहीं।

30 मिनट में बनने वाली, पहले दिन की एक-पन्ने memo

कागज़ हो या notepad, कोई फर्क नहीं। बस नीचे की चार चीजें भरनी हैं। क्रम भी मायने रखता है।

1. पढ़ने का क्रम तंग रखें। सीधे सारी files नहीं, सिर्फ README और package.json। इतने से पता चल जाता है कि कौन सी भाषा है, कैसे चलता है, और कौन-कौन से tools इस्तेमाल हो रहे हैं। फिर 2-3 मुख्य screen या route। इतना काफी है।
2. न छूने वाली जगहें लिखें। billing, login authentication, environment variables, database की migration। इन पर साफ लिखें — “पढ़ना ठीक है, पर बदलना मना है।” न लिखो तो Claude इन्हें भी आम edit का हिस्सा मान लेता है।
3. पहली छोटी task एक चुनें। ऐसी जगह जहां से आसानी से लौटा जा सके। article के अंत का text, button का label, उलझाने वाला test का नाम। गलती हो भी जाए तो तुरंत वापस।
4. “हो गया” तय करने वाली जांच लिखें। build pass होती है क्या, diff अंदाजे के दायरे में है क्या, screen बिगड़ी तो नहीं। माहौल से नहीं, command के नतीजे से तय करें।

ये चार भर दें तो पहले दिन की आधी से ज्यादा घबराहट गायब हो जाती है। क्योंकि अब आपको “Claude क्या गुल खिलाएगा” नहीं, बल्कि “Claude को कहां तक सौंपा है” — यह खुद पता होता है।

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

लकीर को शब्दों में लिख रखें तो हर बार दुविधा नहीं होती। मैं जो बंटवारा इस्तेमाल करता हूं वह यह है।

काम	Claude को सौंपें	इंसान तय करे
code पढ़कर structure का सार बनाना	○ draft बनवाएं	अंतिम समझ खुद जांचें
न छूने वाली जगहें सुझाना	○ candidates निकलवाएं	billing/auth इंसान ही पक्का करे
text या label सुधारना	○ सौंप सकते हैं	diff देखकर approve करें
production DB में लिखना	×	इंसान हाथ से चलाए
delete/publish/billing	×	इंसान बटन दबाए

मुख्य बात यह है कि खतरनाक operations को शुरू से ही “इंसान से पूछो” वाली तरफ रखें। जो operation सुरक्षित साबित हो जाए, बस उसी को बाद में automatic में bढ़ाएं। उल्टा मत करें। पहले सब छूट देना और हादसे के बाद कसना — यह क्रम उल्टा है।

इस सोच को और बारीकी से समझना हो तो Claude Code का पहला कदम गाइड और Claude Code पहले 30 मिनट का checklist साथ पढ़ें — तो पहले दिन की चाल जुड़ जाती है।

copy-paste लायक request का template

सबसे पहली बात — सीधे edit मत करवाएं। शुरू में सिर्फ “पढ़ो और table में बनाओ” कहें।

मैं इस repo को पहली बार छू रहा हूं। अभी कुछ भी edit मत करना।
नीचे दिए क्रम में पढ़ो और नतीजा table में दो।

1. README और package.json पढ़कर बताओ — कौन सी भाषा, चलाने का command, और मुख्य dependencies
2. छूने में खतरनाक जगहें (billing/auth/env vars/DB migration) file path के साथ गिनाओ
3. आसानी से लौटने लायक "पहली छोटी task" के 3 candidates, कारण समेत दो
4. हर candidate के लिए, पूरा होने की जांच का command (build/diff आदि) लिखो

दोहरा रहा हूं — इस चरण में एक अक्षर भी edit मत करना।

table आ जाए तो अपनी आंखों से देखें कि “न छूने वाली जगहें” में कुछ छूट तो नहीं गया। छूटा हो तो जोड़ दें, और तब जाकर सिर्फ एक task सौंपें।

अभी जो candidates दिए, उनमें से सिर्फ ◯◯ (article के अंत का text सुधारना) करो।
billing/auth/env vars/migration को बिल्कुल मत छूना।
edit के बाद `npm run build` चलाओ और diff को `git diff --stat` से दिखाओ।
कुछ टूटे तो कारण और सुधार एक लाइन में बताकर रुक जाओ।

CLAUDE.md में “न छूने वाली जगहें” शुरू से लिख रखें तो हर बार यह चेतावनी चिपकानी नहीं पड़ती। लिखने का तरीका CLAUDE.md best practices में दिया है।

जांच को मशीन से करवाने वाली छोटी सी code

“ठीक से तैयार होकर ही सौंपूंगा” — इसे अपनी याददाश्त के भरोसे छोड़ें तो व्यस्त दिन में जरूर छूट जाएगा। इसलिए memo कम-से-कम पूरी है या नहीं, यह मशीन से जंचवाएं। नीचे की code Node.js में सीधे चलती है।

// पहले दिन की एक-पन्ने memo "Claude को सौंपने लायक" है या नहीं, मशीन से जांचें
const repoMap = {
  goal: "आसानी से लौटने लायक एक पहली task चुनना",
  readFirst: ["README.md", "package.json", "src/routes/"],
  protectedAreas: [".env", "billing/", "migrations/", "wrangler.toml"],
  firstTask: "article के अंत का text सुधारना (payment code नहीं छूना)",
  proofCommands: ["npm run build", "git diff --stat"],
};

function isReady(map) {
  const reasons = [];
  if (map.readFirst.length < 2) reasons.push("पढ़ने का क्रम बहुत तंग/अधूरा है");
  if (map.protectedAreas.length === 0) reasons.push("न छूने वाली जगहें खाली हैं");
  if (!map.proofCommands.some((c) => c.includes("build"))) {
    reasons.push("build जांचने वाला command नहीं है");
  }
  if (!map.firstTask) reasons.push("पहली task नहीं चुनी");
  return { ready: reasons.length === 0, reasons };
}

const result = isReady(repoMap);
console.log(result.ready ? "सौंपना OK" : "अभी मत सौंपो: " + result.reasons.join(", "));

चलाने पर ऐसा आता है।

node check-repo-map.mjs
# => सौंपना OK

आजमाने के लिए protectedAreas को खाली array बनाकर चलाएं तो “अभी मत सौंपो: न छूने वाली जगहें खाली हैं” आता है। बस इतनी सी चीज, पर “न छूने वाली जगहें लिखना भूलकर पूरी automation चला देना” — यह सबसे आम हादसा सौंपने से पहले ही रोक देती है। इस memo को CLAUDE.md या issue में वैसे ही चिपका दें, तो अगले दिन का आप या साथी भी वही फैसला दोबारा इस्तेमाल कर सकते हैं।

जहां सच में काम आया, ऐसे 3 मौके

1. blog चलाते वक्त, कमाई देने वाले article की link बचाना लोकप्रिय article के अंत की link भर सुधारनी हो और Claude से “text बेहतर करो” कहो, तो वह product link का URL तक छेड़ देता है। इसलिए “text सुधारो, पर link का URL एक अक्षर भी मत बदलो। बदलाव के बाद build और diff दिखाओ” — दायरा बंद कर देता हूं। इससे बिक्री से जुड़ी link तोड़े बिना, सिर्फ text चमक जाता है।

2. SaaS में, billing के पास तक न जाना settings screen का विवरण उलझाने वाला हो, तो सुधार का target सिर्फ दिखने वाला text है। billing या plan change की logic नहीं छूने देता। memo की “न छूने वाली जगहें” में billing/ डाल रखें तो Claude मदद के जोश में retry logic में हाथ नहीं डालता।

3. internal tool में, सिर्फ output का column नाम सुधारना CSV output के column नाम उलझाने वाले हैं — ऐसी शिकायत आई। सुधारना है सिर्फ column नाम का text, aggregation logic अलग बात है। “सिर्फ column का दिखने वाला text। formula मत छूना। sample data से output दिखाओ” — कहते ही जांच पल भर में पूरी।

तीनों में एक बात साझा है — गड़बड़ Claude की कमजोरी से नहीं, बल्कि सीमा पतली होने से होती है। सीमा जितनी साफ लिखें, AI उतनी सुरक्षित और तेज चलता है।

अक्सर हो जाने वाली गलतियां और उनका सुधार

गलती 1: शुरू में ही सारी files पढ़वाना। कम जरूरी formatting में समय और token खर्च होते हैं, और असली बदलाव पतला रह जाता है। सुधार — पढ़ने का दायरा README और package.json plus 2-3 मुख्य route तक सीमित करें। पूरी समझ एक task पूरी होने के बाद धीरे-धीरे बढ़ाएं।

गलती 2: न छूने वाली जगहें न लिखना। Claude billing/auth/deploy config को आम edit target मानता है। सुधार — file path के साथ protect list लिखें और CLAUDE.md में स्थायी रखें। मुंहजबानी चेतावनी भूल जाती है, लिखी चीज रह जाती है।

गलती 3: जांच command तय किए बिना “हो गया” पर यकीन कर लेना। हर बार इंसान को अंदाज़ा लगाना पड़ता है कि completion report सही है या नहीं। सुधार — request में शुरू से ही “build करके diff दिखाओ” डालें। HTTP 200 या भरोसेमंद-सा जवाब सफलता का सबूत नहीं। सचमुच चलाए जाने का नतीजा ही मानें।

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

Q. पूरा code समझकर सौंपना ज्यादा सुरक्षित नहीं? आदर्श तो यही है, पर पहले दिन पूरी समझ नहीं बनती। उसके पूरा होने का इंतजार करें तो कुछ आगे नहीं बढ़ता, इसलिए पहले “न छूने वाली जगहें” बंद करें और आसानी से लौटने लायक एक task से शुरू करें। समझ काम करते-करते बढ़ाना ज्यादा तेज पड़ता है।

Q. पहली task कितनी छोटी होनी चाहिए? एक file, एक text, एक command में निपट जाए — यह माप है। बड़ा सौंपो तो Claude मदद के जोश में दायरा बढ़ा देता है। build और screenshot जांचकर आगे बढ़ें तो रफ्तार घटाए बिना वापसी का समय कम रहता है।

Q. न छूने वाली जगहें कहां लिखना बेहतर है? CLAUDE.md में लिखना सबसे टिकाऊ है। हर बार prompt में चिपकाने वाला तरीका व्यस्त दिन में चिपकाना भुला देता है। project का नियम बनाकर एक जगह रखें तो नए काम में भी अपने आप लागू रहता है।

Q. “मत छूना” कहा था फिर भी Claude ने छू दिया। ज्यादातर protect target file नाम तक रह जाता है, पूरी directory नहीं बताई जाती। सिर्फ billing.js नहीं, billing/ की तरह दायरे से लिखें। फिर भी लांघे तो request की शुरुआत में “edit से पहले target file घोषित करके आगे बढ़ो” एक कदम जोड़ें — रुकने की संभावना बढ़ती है।

Q. क्या यह memo हर बार दोबारा बनानी पड़ती है? हर repo के लिए एक बार बनाएं, फिर दोबारा इस्तेमाल। CLAUDE.md और issue में चिपका रखें तो अगले दिन का आप और साथी भी वही फैसला आगे बढ़ाते हैं। नया protect target मिले तो बस जोड़ते जाएं।

मैंने असल में आजमाकर क्या पाया

शुरू वाले payment-code कांड के बाद, मैंने एक दूसरे पुराने repo में यही तरीका आजमाया। पहले edit बिल्कुल नहीं करवाया, ऊपर वाली request से सिर्फ table निकलवाया — तो billing/ और migrations/ को protect candidate के रूप में ठीक से गिना दिया। हां, environment variable वाली file छूट गई थी, इसलिए मैंने खुद .env जोड़ा। यह जगह इंसान देखेगा, इसी भरोसे पर आगे बढ़ना जरूरी है — यह फिर महसूस हुआ।

पहली task को article के अंत का एक text सुधार तक सीमित रखा, और npm run build व git diff --stat तक जांचकर पूरा किया। diff बस 7 लाइन का था, payment code को एक अक्षर भी नहीं छुआ था। जांच वाली code भी सचमुच चलाई, और protectedAreas खाली करने पर “अभी मत सौंपो” कहकर रुकना पक्का कर लिया। समझदार AI ढूंढने से बेहतर है — गिरने पर तुरंत लौट सकें, ऐसा छोटा दायरा पहले तय कर लेना। किसी और के code को सौंपने के पहले दिन, सबसे ज्यादा यही काम आया।

कंपनी के पुराने code में Claude Code कैसे लाएं, इसका team-level ढांचा तय करने के चरण पर हों, तो training/consultation में असली repo देखते हुए सीमा खींचने का तरीका साथ में बनाया जा सकता है। official baseline के लिए Anthropic Claude Code getting started भी देख लें तो निश्चिंति रहती है।