AI Agents के लिखे Code को Verify करने का 7-Step Pipeline

यह अभी सबसे hot topic है। Agents रोज़ सैकड़ों commits निकाल रहे हैं, और कोई भी उन सबको review नहीं कर सकता।

Peter, OpenClaw के एक developer, कभी-कभी एक ही दिन में 3,000 से ज़्यादा commits push कर देते हैं। यह किसी भी इंसान की processing capacity से कहीं परे है। यह एक ऐसा काम बन गया है जिसे इंसान अकेले नहीं संभाल सकते।

पहले मुझे लगा कि इसका कोई हल नहीं है। फिर मैंने Ryan Carson की “Code Factory” पढ़ी और तस्वीर साफ हो गई। हर चीज़ पढ़ने की कोशिश करने के बजाय, आप एक ऐसी structure बनाते हैं जहाँ machines code को verify करती हैं।

Merge rules को एक JSON file में define करें

High-risk paths कौन से हैं और कौन से checks ज़रूरी हैं: यह सब एक ही file में लिख दें। मुख्य insight यह है कि इससे documentation और scripts एक-दूसरे से अलग नहीं होते।

• High-risk paths के लिए Review Agent और browser-based evidence ज़रूरी है
• Low-risk paths policy gate और CI pass होने के बाद merge हो सकते हैं

CI से पहले qualification checks चलाएं

उन PRs पर builds चलाना जो review भी पास नहीं हुए, यह पैसे जलाना है। CI fanout के सामने एक risk-policy-gate लगाएं। अकेले यही कदम unnecessary CI costs काफी हद तक कम कर देता है।

• Fixed order: policy gate → Review Agent confirmation → CI fanout
• Unqualified PRs test/build stage में जाते ही नहीं

Stale commit के “pass” पर कभी भरोसा न करें

यही वो बात है जिस पर Carson ने सबसे ज़्यादा ज़ोर दिया। अगर पुराने commit का “pass” बना रहे, तो latest code बिना verification के merge हो जाता है। हर push पर reviews दोबारा चलाएं, और अगर वो match नहीं करते तो gate block कर दें।

• Review Check Run तभी valid है जब वो headSha से match करे
• हर synchronize event पर rerun force करें

Rerun requests सिर्फ एक source से जारी करें

जब कई workflows rerun request करती हैं, तो duplicate comments और race conditions आते हैं। यह मामूली लगता है, लेकिन अगर इसे ठीक नहीं किया, तो पूरा pipeline हिल जाता है।

• Marker + sha:headSha pattern से duplicates रोकें
• अगर SHA पहले ही submit हो चुका है तो request skip करें

Fixes भी agents को ही करने दें

जब Review Agent कोई problem ढूंढता है, तो Coding Agent उसे patch करके उसी branch पर push कर देता है। Carson की post की सबसे तेज़ insight: model version pin करें। वरना हर बार अलग-अलग results मिलेंगे और reproducibility खत्म हो जाएगी।

• Codex Action fixes → push → rerun trigger
• Pinned model versions reproducibility ensure करते हैं

सिर्फ bot-to-bot conversations auto-close करें

जिन threads में कोई इंसान शामिल हो, उन्हें कभी न छुएं। इस distinction के बिना, reviewer comments दब जाते हैं।

• Clean current-head rerun के बाद ही auto-resolve करें
• Human comments वाले threads हमेशा open रहते हैं

दिखने वाला, verifiable evidence छोड़ें

अगर UI बदला है तो सिर्फ screenshot मत लीजिए। CI-verifiable evidence की ज़रूरत होती है। Production incidents को test cases में बदलें ताकि वही failure दोबारा न हो।

• Regression → harness gap issue → test case जोड़ें → SLA tracking

Carson के tool choices

Reference के लिए, यहाँ है Carson ने क्या चुना: code review agent के रूप में Greptile, remediation के लिए Codex Action, और तीन workflow files जो असली काम करती हैं: greptile-rerun.yml canonical reruns के लिए, greptile-auto-resolve-threads.yml stale thread cleanup के लिए, और risk-policy-gate.yml preflight policy के लिए।

Correctness से परे: visual verification

ऊपर बताई गई हर चीज़ यह पकड़ती है कि code सही है या गलत। लेकिन व्यवहार में, आपको यह भी verify करना होता है कि output दिखता कैसा है।

दो approaches अलग दिखती हैं।

Nico Bailon का visual-explainer terminal diffs को ASCII की जगह HTML pages के रूप में render करता है, जिससे change sets एक नज़र में तुरंत पढ़े जा सकते हैं।

Chris Tate का agent-browser एक अलग दिशा लेता है। यह actual browser screens को pixel by pixel compare करता है ताकि CSS और layout breakage पकड़ी जा सके। Bisect के साथ मिलकर, यह exactly वो commit pinpoint कर सकता है जिसने regression पैदा किया।

मैं यह सब codexBridge बनाते हुए सोच रहा था। केवल session logs से यह track करना काफी नहीं कि किस agent ने कौन सा code लिखा। आपको एक ऐसी search structure चाहिए जो retrieval आसान बनाए।

निष्कर्ष

“Agents के लिखे code को कौन verify करेगा?” इसका जवाब इंसान नहीं हैं। जवाब एक ऐसी structure है जहाँ machines उस evidence को judge करती हैं जो machines ने ही produce किया। यही उत्तर है।