AI Agent के PR की समीक्षा करके अनावश्यक बदलाव कैसे हटाएँ

AI coding agent तेज़ी से त्रुटियाँ ठीक कर सकता है या फीचर बना सकता है, लेकिन साथ में असंबंधित फ़ाइलों को format कर सकता है, अतिरिक्त abstraction जोड़ सकता है, configuration बदल सकता है या आवश्यकता से अधिक code rewrite कर सकता है। Merge से पहले लक्ष्य केवल कम lines वाला diff नहीं होना चाहिए। लक्ष्य ऐसा change set है जिसमें हर महत्वपूर्ण बदलाव स्पष्ट requirement से जुड़ा हो, maintainer उसे समझा सके और team उसे tests या अन्य प्रमाण से सत्यापित कर सके।

एक developer ने X पर अपना व्यक्तिगत तरीका बताया: agent के PR खोलने के बाद वे fresh context में दूसरा agent चलाते हैं और उससे पूछते हैं कि क्या काटा या हटाया जा सकता है। लेखक ने इसे अतिरिक्त मेहनत और tokens वाला तरीका कहा, कोई guaranteed समाधान नहीं। एक अन्य user ने बताया कि Codex ने कई errors ठीक किए, पर code इतना व्यापक रूप से बदल गया कि वह उसे समझ नहीं पाया। ये अनुभव समस्या को दिखाते हैं; वे यह सिद्ध नहीं करते कि दूसरा agent हर PR को बेहतर बना देगा।

नीचे की प्रक्रिया में दूसरा agent संदेह करने वाला reviewer है, authority नहीं। Scope, evidence, risk और merge decision की जिम्मेदारी human maintainer की रहती है।

सात चरणों में पूरी प्रक्रिया

1. Acceptance contract लिखें: expected behavior, जो नहीं बदलना चाहिए, allowed scope, risks और validation commands।
2. PR Conversation, Commits, Checks, Files changed और local Git commands से वास्तविक बदलावों की सूची बनाएँ।
3. Fresh-context agent को केवल review करने दें; first pass में edit करने से रोकें।
4. हर finding को keep, simplify, remove, split या human decision में रखें और evidence माँगें।
5. केवल human-approved trimming छोटे, reversible batches में लागू करें।
6. बदलाव घटाने से पहले और बाद में समान relevant tests तथा checks चलाएँ।
7. Final diff शुरुआत से फिर पढ़ें और तभी merge करें जब maintainer पूरे change को समझा सके।

1. दूसरी समीक्षा से पहले acceptance contract लिखें

“इस PR को साफ़ कर दो” पर्याप्त लक्ष्य नहीं है। इससे दूसरा agent भी subjective rewrite शुरू कर सकता है। एक छोटा contract कम से कम यह बताए:

• समस्या और observable outcome: user या caller क्या देखेगा।
• Preserve किया जाने वाला behavior: existing interfaces, failure behavior, compatibility और data semantics।
• Allowed scope: कौन-से modules, APIs, schemas, configuration या tests बदलने की अपेक्षा है।
• Explicit non-goals: framework upgrade, global formatting, unrelated rename, speculative abstraction या बिना जरूरत configuration migration नहीं।
• Risk constraints: security, permissions, migration, performance, observability, rollback और backward compatibility।
• Validation: repository की वास्तविक format, lint, type-check, unit, integration, build, migration या E2E commands।

यदि सही परिणाम स्पष्ट नहीं है तो अनावश्यक code की पहचान भी विश्वसनीय नहीं होगी। पहले contract स्पष्ट करें, फिर trimming करें।

2. Agent के summary के बजाय पूरा diff स्थापित करें

GitHub PR का evidence अलग-अलग views में रखता है। Conversation में description और discussion, Commits में branch का इतिहास, Checks में automated validation और Files changed में actual diff होता है। Official review flow line comments, suggestions, per-file Viewed status और अंतिम Comment, Approve या Request changes decision देता है।

Local testing या modification के लिए GitHub का documented तरीका है:

gh pr checkout <PR_NUMBER>
git fetch origin

origin/main को वास्तविक base branch से बदलें और common ancestor से HEAD तक बदलाव देखें:

git diff --stat origin/main...HEAD
git diff --name-status origin/main...HEAD
git log --oneline origin/main..HEAD

Git के अनुसार git diff A...B, A और B के merge base से B तक का diff दिखाता है। पहले summary और file status देखें, फिर full diff और संदिग्ध path पढ़ें:

git diff origin/main...HEAD
git diff origin/main...HEAD -- path/to/suspicious-file

इस inventory pass में code न हटाएँ। Files को पाँच groups में रखें:

Group	पूछने वाला प्रश्न
Core implementation	क्या यह acceptance contract की किसी requirement को सीधे पूरा करता है?
Necessary support	क्या test, docs, migration या configuration वास्तव में core change के लिए आवश्यक है?
Suspected scope expansion	क्या global formatting, बड़े rename, unrelated abstraction या dependency upgrade जुड़ा है?
Generated output	क्या generated file source के साथ commit होना चाहिए या गलती से आया है?
Uncertain/high risk	क्या security, data, compatibility या unfamiliar domain छुआ गया है?

केवल complexity redundancy का प्रमाण नहीं है। Defensive checks, migration और compatibility paths लंबे हो सकते हैं, फिर भी आवश्यक हों।

3. Fresh context में first pass केवल review हो

Fresh context का लाभ यह नहीं कि दूसरा agent स्वभाव से अधिक सही होगा। लाभ यह है कि उसे implementation पूरा करने के बजाय scope और evidence को challenge करने का अलग objective दिया जा सकता है। यह practitioner technique है, GitHub requirement या measured guarantee नहीं।

Reviewer को acceptance contract, complete diff, relevant callers, tests और repository instructions दें। यह prompt उपयोग कर सकते हैं:

आप इस pull request के second-pass maintainer reviewer हैं। आपका लक्ष्य code को फिर से लिखना नहीं है। Acceptance contract को बनाए रखते हुए सबसे छोटा explainable change set खोजें।

पहला pass केवल review है। किसी file को edit न करें।
PR goal, complete diff, relevant callers, tests और repository constraints पढ़ें।

हर finding के लिए दें:
1. file और exact hunk या symbol;
2. वह requirement जिसे change पूरा करता है;
3. evidence: caller, test, interface contract, documentation या missing evidence;
4. remove या simplify करने का risk;
5. action: KEEP / SIMPLIFY / REMOVE / SPLIT / HUMAN DECISION;
6. change के बाद चलने वाली exact validation।

Rules:
- केवल code लंबा या style अलग होने से deletion न सुझाएँ;
- passing tests को requirements सही होने का एकमात्र प्रमाण न मानें;
- unrelated formatting, duplicate abstractions, unused helpers, out-of-scope refactors और unexplained dependency/config changes को प्राथमिकता से जाँचें;
- स्पष्ट विरोधी evidence न हो तो security, compatibility, migration, error handling और observability बनाए रखें;
- uncertainty लिखें, business rules न गढ़ें;
- अंत में low-to-high-risk trim plan दें। अभी code न लिखें।

Report-first approach दूसरे agent को “cleanup” के नाम पर नया बड़ा rewrite करने से रोकता है। हर recommendation file, hunk और evidence से जुड़ी होनी चाहिए।

4. Evidence के आधार पर human classification करें

Decision	कब उपयोग करें	Maintainer किस evidence की पुष्टि करे
Keep	Code contract या जरूरी security, compatibility, migration, operations पूरा करता है	Requirement mapping, call path, test, interface या documented constraint
Simplify	Behavior आवश्यक है, implementation में duplicate branches, wrappers या layers हैं	Behavior equivalence और important edge coverage
Remove	Change unrelated, unused, unsupported या accidental format/rename है	Repository search, build और relevant tests dependency नहीं दिखाते
Split	काम उपयोगी है लेकिन वर्तमान contract के बाहर है	उसे अलग describe, test, review और revert किया जा सकता है
Escalate	Unfamiliar domain, security boundary, migration या hidden rule है	Code owner, domain maintainer या characterization test चाहिए

इन signals की जाँच करें, पर automatic deletion न करें: एक call site के लिए कई generic layers; बिना compatibility plan के old और new paths; unrelated formatting या file moves; unexplained dependency/lockfile/config change; implementation details पर आधारित tests; सभी exceptions को चुपचाप swallow करना; बिना caller वाले helpers; “भविष्य में शायद” वाला code।

इसके उलट, test न होना यह सिद्ध नहीं करता कि code बेकार है। यह coverage gap हो सकता है। Uncertain behavior हटाने से पहले characterization test जोड़ें या module owner से पूछें।

5. छोटे batches में trim करें और recovery point रखें

Edit से पहले working tree जाँचें और local backup reference बनाएँ:

git status --short
git branch backup/ai-pr-before-trim

यदि पूरी file base state में लौटानी है:

BASE=$(git merge-base origin/main HEAD)
git restore --source="$BASE" -- path/to/unrelated-file

Selected hunks के लिए interactive restore:

git restore -p --source="$BASE" -- path/to/file

Git documentation बताती है कि restore source में tracked path न हो तो path source से match करने के लिए हट सकता है। इसलिए $BASE और path verify करें, फिर तुरंत diff देखें। Manual edit भी ठीक है; महत्वपूर्ण बात है कि नया unrelated refactor न जोड़ें।

एक approved group को एक बार में process करें:

git diff
git add -p
git diff --cached
git commit -m "Remove unrelated changes from AI-generated PR"

Small commits बताते हैं कि क्या हटाया गया, क्यों और किस validation से जाँचा गया। Review के दौरान destructive history rewrite से प्रक्रिया न छिपाएँ।

6. Trimming से पहले और बाद में comparable validation चलाएँ

Testing का उद्देश्य smaller diff सिद्ध करना नहीं, accepted behavior बचा रहना सिद्ध करना है। जब संभव हो original PR का baseline record करें और हर batch के बाद वही relevant commands चलाएँ:

<format-check-command>
<lint-command>
<typecheck-command>
<targeted-unit-test-command>
<relevant-integration-test-command>
<build-or-e2e-command>

Commands repository docs या CI configuration से लें, agent से अनुमान न लगवाएँ। Normal path, important boundaries, failures, permissions, empty values, concurrency, timeout, retry, public interfaces, serialized formats, migrations, build, types, lint, security और latest commit के required GitHub Checks cover करें।

यदि trim से test टूटता है, उस batch को revert करें या backup से recover करें और कारण खोजें। केवल green बनाने के लिए test और implementation दोनों साथ न बदलें, जब तक contract स्पष्ट रूप से पुरानी expectation को गलत न बताए और human approval न हो।

Green tests आवश्यक evidence हैं, लेकिन suite incomplete हो सकती है। Maintainer की समझ फिर भी जरूरी है।

7. Final diff को फिर review करें और स्पष्ट निर्णय दें

Trimming के बाद Files changed दोबारा खोलें और शुरुआत से सभी files पढ़ें। GitHub viewed file बदलने पर Viewed marker हटा देता है, इसलिए बदली files फिर review होंगी। Commits और Checks देख कर सुनिश्चित करें कि validation latest revision की है।

Final diff पर एक और fresh-context review किया जा सकता है, लेकिन stop condition तय करें: केवल evidence-backed issues; endless style refactor नहीं। फिर human review submit करे:

• Approve: contract पूरा, changes explainable, risks handled और required checks pass।
• Request changes: scope expansion, opaque logic या failed checks बाकी हैं। Merge block होना repository rules और branch protection पर निर्भर है।
• Comment: feedback देना है, पर approve या formal block नहीं करना।

Pre-merge checklist

• हर changed file current requirement, necessary test या explicit support से जुड़ी है।
• Maintainer हर important hunk को agent summary दोहराए बिना समझा सकता है।
• Unexplained dependency, config, permission, migration और generated-file changes हटाए, split या escalate किए गए हैं।
• Original और trimmed PR पर comparable validation set चला।
• Relevant local tests, build और latest commit checks project requirements पूरी करते हैं।
• Security, data और compatibility uncertainty सही owner ने review की।
• Diff अभी भी बड़ा है तो independent work अलग PR में गया।
• Review decision और follow-up work record हुए।

Failure modes और recovery

दूसरा agent module फिर rewrite करने लगता है

Run रोकें, review-only report पर लौटें, accessible files सीमित करें और हर सुझाव के लिए hunk, requirement और validation माँगें। Evidence के बिना aesthetic rewrite reject करें।

Agents असहमत हैं

Vote न करें। Callers, interface contracts, failure paths, tests और historical constraints compare करें। Evidence कमजोर हो तो code रखें, coverage जोड़ें या domain maintainer बुलाएँ।

Tests pass हैं, code फिर भी समझ नहीं आता

Coverage understandable design के बराबर नहीं है। PR split करें, documentation जोड़ें या critical path की explanation माँगें। केवल green CI के कारण opaque code merge न करें।

Reliable tests नहीं हैं

Preserved behavior के लिए minimal characterization test बनाएँ या repeatable manual verification record करें। High-risk code में missing evidence pause करने का कारण है, agent के अनुमान का नहीं।

PR बहुत बड़ा है

Core behavior, refactoring, dependency upgrades, formatting और migrations को independently reviewable changes में बाँटें। छोटे units verify और revert करना आसान है।

Approved findings लागू करने का prompt

केवल ये approved finding IDs लागू करें: [LIST]।
Approved list के बाहर कोई file न बदलें और opportunistic refactoring न करें।
हर logical group के लिए:
1. actual diff दिखाएँ;
2. assigned validation commands चलाएँ;
3. command, exit status और failure summary report करें;
4. remaining uncertainties लिखें।
यदि कोई item acceptance contract, public interface, security या migration behavior बदलता है तो रुकें और human decision माँगें।

मुख्य विचार “और agents जोड़ना” नहीं है। Generation और review अलग होते हैं: पहला context implementation प्रस्तावित करता है, दूसरा scope और evidence चुनौती देता है, और human निर्णय तथा acceptance का मालिक रहता है। सही परिणाम shortest diff नहीं, बल्कि task को पूरा करने वाला सबसे छोटा explainable और verified change set है।

स्रोत और सीमा

• Practitioner report: fresh-context trimming पर Arnav Gupta का X post और replies; यह anecdotal है।
• User report: Codex के broad rewrite के बाद code न समझ पाने वाला original post; repository, diff या test data उपलब्ध नहीं।
• GitHub docs: Reviewing proposed changes, Checking out PRs locally, Pull requests reference।
• Git docs: git diff और git restore।