Claude Code के साथ Pair Programming: AI से तेज काम, पर नियंत्रण आपके पास

Claude Code के साथ pair programming का मतलब यह नहीं है कि पूरा code AI को सौंप दिया जाए। बेहतर तरीका यह है कि goal, boundary और acceptance criteria इंसान तय करे, और Claude Code को codebase पढ़ने, छोटा diff बनाने, tests चलाने और review summary तैयार करने का काम दिया जाए।

Official Claude Code overview बताता है कि Claude Code codebase पढ़ सकता है, files edit कर सकता है, commands चला सकता है और development tools से integrate हो सकता है। यानी यह सिर्फ chatbot नहीं है। लेकिन जितनी शक्ति बढ़ती है, उतना ही साफ prompt और verification जरूरी हो जाता है।

यह guide Claude Code getting started guide के बाद पढ़ने के लिए है। इसमें छोटे bugs, tests, refactor और pull request review के लिए repeatable workflow दिया गया है।

पहले roles साफ करें

Claude Code तेज है, लेकिन product intent, security boundary और merge decision इंसान के पास ही रहने चाहिए।

Area	Human की जिम्मेदारी	Claude Code की जिम्मेदारी
Goal	क्या बदलना है और क्या नहीं	relevant files और paths ढूंढना
Research	पढ़ने का scope तय करना	code, tests, diff, logs पढ़ना
Implementation	diff size और risk approve करना	small focused edits करना
Verification	pass/fail signal define करना	tests, lint, build, screenshots चलाना
Review	merge decision लेना	risks, missing tests, alternatives बताना

इस split से Claude Code एक supervised teammate बनता है, uncontrolled replacement नहीं। Beginner के लिए भी यही बेहतर है। पहले एक bug, एक test file या एक component से शुरू करें।

पहले 10 मिनट में setup करें

Claude Code best practices का मुख्य संदेश है: Claude को verify करने का तरीका दें और exploration, planning, implementation, verification को अलग रखें।

पहला rule: main पर सीधे काम न करें, branch या worktree use करें। दूसरा: छोटा CLAUDE.md रखें। Memory documentation के अनुसार CLAUDE.md हर session की शुरुआत में persistent instruction की तरह load होता है। तीसरा: project के check commands लिखें।

# CLAUDE.md

## Project rules
- Before editing, summarize the files you plan to inspect.
- Prefer small diffs and explain risky changes before applying them.
- After code edits, run `npm run lint` and the narrowest relevant test.
- Do not read `.env*` files or change deployment settings without approval.

## Common commands
- `npm run lint`
- `npm run test`
- `npm run build`

CLAUDE.md बहुत लंबा न बनाएं। अगर कोई repeatable process लंबा है, उसे Skills में रखना बेहतर है, क्योंकि skill जरूरत पड़ने पर ही load होती है।

Core loop: explore, plan, implement, verify

सबसे common mistake है सीधे “implement this” कहना। बेहतर loop यह है:

flowchart LR
  A[Goal बताएं] --> B[Relevant files explore करें]
  B --> C[Plan review करें]
  C --> D[Small edits करें]
  D --> E[Checks चलाएं और diff देखें]
  E --> F{Pass?}
  F -- No --> C
  F -- Yes --> G[PR summary बनाएं]

पहला prompt छोटा हो सकता है, पर इसमें goal, scope, forbidden actions और verification होना चाहिए।

Goal: Login के बाद profile page पर आने वाला 500 error fix करना है।
Scope: पहले `src/auth` और `src/pages/profile` देखें।
Do not: auth strategy न बदलें, DB schema न बदलें, `.env` न पढ़ें।
Process: relevant files पढ़ें, 3 likely causes बताएं, edit से पहले plan दें।
Verification: existing auth tests और `npm run lint` चलाएं।

अगर plan बड़ा लगे, तो उसे छोटा करें।

Plan ठीक है, लेकिन पहले सिर्फ reproduction test लिखें।
Confirm करें कि test fail होता है।
उसके बाद production code changes file by file propose करें।

यह TDD, यानी test-driven development, के साथ अच्छी तरह काम करता है। पहले failing test लिखने से bug visible होता है और review आसान होता है।

छोटा runnable example

Practice के लिए production code से शुरुआत न करें। यह pair-check.test.ts file Claude Code के risk mode को decide करती है। इसे Vitest से चला सकते हैं।

import { describe, expect, it } from "vitest";

type ClaudeMode = "direct" | "plan-first" | "human-review";

export function decideClaudeMode(input: {
  changedFiles: number;
  touchesSecrets: boolean;
  hasReliableTests: boolean;
}): ClaudeMode {
  if (input.touchesSecrets) return "human-review";
  if (input.changedFiles > 3) return "plan-first";
  if (!input.hasReliableTests) return "plan-first";
  return "direct";
}

describe("decideClaudeMode", () => {
  it("allows direct work for small, well-tested changes", () => {
    expect(
      decideClaudeMode({
        changedFiles: 1,
        touchesSecrets: false,
        hasReliableTests: true,
      }),
    ).toBe("direct");
  });

  it("requires a plan for broad changes", () => {
    expect(
      decideClaudeMode({
        changedFiles: 5,
        touchesSecrets: false,
        hasReliableTests: true,
      }),
    ).toBe("plan-first");
  });

  it("requires human review for secret-related work", () => {
    expect(
      decideClaudeMode({
        changedFiles: 1,
        touchesSecrets: true,
        hasReliableTests: true,
      }),
    ).toBe("human-review");
  });
});

npm install -D vitest typescript
npx vitest run pair-check.test.ts

अब Claude Code से कहें: “billing touch हो तो human-review चाहिए।” पहले test add कराएं, fail confirm कराएं, फिर implementation और दोबारा test। यही discipline API handler, React component और migration scripts में भी काम आती है।

4 practical use cases

पहला use case है existing feature में छोटा condition जोड़ना, जैसे free plan users के लिए CSV export hide करना। इसमें UI, permissions और tests तीनों देखने पड़ते हैं, पर architecture नहीं बदलती।

दूसरा use case bug investigation है। Error message, reproduction steps और expected behavior साथ दें। Official Common workflows भी reproduction command और stack trace देने की सलाह देता है।

तीसरा use case tests बढ़ाना है। Claude को पहले existing test style पढ़ने दें, फिर success, unauthorized, invalid input और empty data cases जोड़ने को कहें। Structured approach के लिए testing strategies guide देखें।

चौथा use case PR से पहले self-review है। Claude को git diff पढ़ाकर security, backward compatibility, missing tests और naming issues पर focus करने को कहें। GitHub की pull request review documentation बताती है कि comments, approvals और change requests quality protect करते हैं। Claude Code human review की तैयारी कर सकता है, replacement नहीं।

Common pitfalls और बचाव

Pitfall	क्या होता है	बेहतर habit
“इसे बेहतर बना दो”	unwanted refactor आ जाता है	scope, non-goals, acceptance लिखें
बहुत बड़ा diff	review मुश्किल हो जाती है	one task, one diff, one plan
verification नहीं	change सिर्फ दिखने में done लगता है	tests, lint, build, screenshot मांगें
बहुत लंबा CLAUDE.md	important rules दब जाते हैं	procedures को Skills में रखें
wide permissions	secrets या production actions risk में आते हैं	permissions और hooks use करें

सबसे छिपा हुआ risk approval fatigue है। हर action पर approval मांगेंगे तो लोग बिना पढ़े approve करने लगेंगे। लगभग सब allow करेंगे तो गलत prompt बहुत दूर तक चला जाएगा। Practical rule है: reversible काम में high trust, irreversible काम में high friction। Details के लिए approval and sandbox guide देखें।

Session को reviewable PR में बदलें

Team workflow में chat को PR summary में बदलना जरूरी है।

इस diff को pull request description में summarize करें।
Include:
- change क्यों किया गया
- main files changed
- verification commands और results
- risks जिन्हें reviewer ध्यान से देखे
- intentionally unchanged scope

Claude draft बना सकता है, लेकिन final wording इंसान को edit करनी चाहिए। Security, payments, privacy और data deletion में model confidence evidence नहीं है। Evidence है diff, test output, logs और review discussion।

वास्तव में आजमाने से सीख

Masa ने छोटे Next.js fix में यह loop use किया। “बस implement करो” की तुलना में review जल्दी हुई, क्योंकि पहले prompt ने files limit कीं, forbidden changes लिखे और lint plus tests मांगें। Claude Code ने कम irrelevant files छुए और verification output conversation में छोड़ा। लेकिन weak tests वाले UI change में human visual review अब भी जरूरी था। निष्कर्ष साफ है: Claude Code pair programming responsibility छोड़ना नहीं, responsibility boundary design करना है।

अगली session में एक छोटा task चुनें और explore, plan, implement, verify loop चलाएं। Team prompts और review rules चाहिए हों तो ClaudeCodeLab training देखें।