कोड रिव्यू और PR जाँच के लिए सैंडबॉक्स: मंज़ूरी देने से पहले साबित करें कि पैच काम करता है

diff दिखाता है कि पैच क्या करने का दावा करता है। यह नहीं दिखाता कि बग सच में चला गया या नहीं, if की नई शाखा कभी चलती भी है या नहीं, या डिपेंडेंसी का नया संस्करण साफ़ इंस्टॉलेशन पर import तोड़ देता है या नहीं। रिव्यूअर यह जानते हैं, इसीलिए इतने रिव्यू "LGTM, अगर टेस्ट पास हो जाएँ" पर ख़त्म होते हैं।

AI के लिखे पैच के साथ यह अंतर और बढ़ जाता है। मॉडल जल्दी से विश्वसनीय दिखने वाला कोड बना देता है, और विश्वसनीय दिखने वाला कोड ही थके हुए रिव्यूअर की नज़र से फिसल जाता है। सस्ता उपाय है कि किसी के मंज़ूरी देने से पहले बदलाव को चलाया जाए — ऐसी जगह जहाँ वह कुछ नुक़सान न कर सके।

जाँच: base, head, टेस्ट

कोई पैच जो सबसे भरोसेमंद सबूत दे सकता है, वह है ऐसा दोहराव जो पुराने कोड पर असफल हो और नए पर पास हो। सैंडबॉक्स इसे 20 लाइन की स्क्रिप्ट बना देता है। यह Python 3.12, Node.js 22, git और curl वाला Firecracker microVM है, जो लगभग एक सेकंड में शुरू होता है:

import os
from eqvps import Sandbox

REPO, BASE, HEAD = os.environ["REPO_URL"], os.environ["BASE_SHA"], os.environ["HEAD_SHA"]

def repro(sb, ref):
    sb.exec(f"cd /root/app && git checkout -q {ref}", timeout=55)
    return sb.exec("cd /root/app && python3 /root/repro.py", timeout=55).exit_code

with Sandbox.create(tariff="standard", ttl=1800) as sb:
    sb.exec(f"git clone -q {REPO} /root/app", timeout=55)
    sb.exec("cd /root/app && pip install -q -r requirements.txt", timeout=55)
    sb.upload("/root/repro.py", open("repro.py").read())
    before, after = repro(sb, BASE), repro(sb, HEAD)
    tests = sb.exec("cd /root/app && python3 -m pytest -q", background=True).wait()
    print(f"repro on base: {before}, on head: {after}; tests: {tests.state}, exit {tests.exit_code}")

repro.py बग रिपोर्ट का कोड टुकड़ा है। अगर यह base पर शून्य से अलग कोड और head पर शून्य के साथ ख़त्म होता है, तो पैच वही ठीक करता है जिसका वह दावा करता है। वह लाइन और टेस्ट का सारांश pull request पर टिप्पणी के रूप में डालें, और रिव्यूअर तथ्यों से शुरुआत करेगा।

टेस्ट सूट बैकग्राउंड टास्क के रूप में चलता है क्योंकि एक सिंक्रोनस कमांड 55 सेकंड पर रुक जाती है। 30 मिनट का TTL तय करता है कि अटका हुआ रन ज़्यादा से ज़्यादा कितनी देर तक बिल बना सकता है।

कोड चलाने वाले रिव्यू एजेंट

यही विचार AI रिव्यूअर पर भी लागू होता है। MCP सर्वर से जुड़े एजेंट के पास सैंडबॉक्स टूल होते हैं: सैंडबॉक्स बनाना, कमांड चलाना, फ़ाइलें अपलोड और डाउनलोड करना। "यह Python 3.8 के साथ संगतता तोड़ सकता है" लिखने के बजाय वह ब्रांच लाता है, कोड चलाता है और traceback उद्धृत करता है — या बताता है कि सब ठीक है।

ऐसे एजेंट को ख़र्च की सीमा और सिर्फ़-पढ़ने वाला टोकन दें, और तय करें कि वह बिना पूछे कौन-से टूल बुला सकता है। MCP सुरक्षा उपाय हर टूल को जोखिम के स्तर के हिसाब से सूचीबद्ध करते हैं।

कौन-सा टैरिफ़

अस्थायी सैंडबॉक्स का बिल प्रति सेकंड बनता है, कम से कम 60 सेकंड। अगर रिव्यूअर कुछ दिनों तक उसी वातावरण में लौटना चाहता है, तो उसे persistent के रूप में बनाएँ: वह अपनी डिस्क 30 दिन तक रखता है और हर शुरू हुए घंटे का बिल बनता है, इसलिए दो दिन के रिव्यू के लिए रखा गया standard सैंडबॉक्स लगभग $3.17 का पड़ता है। pull request मर्ज होने पर उसे मिटा दें।

जानने लायक़ सीमाएँ

• हर खाते में एक समय पर दो कमांड। एक के बाद एक होने वाले रिव्यू के लिए काफ़ी। अगर आप दर्जनों pull requests एक साथ जाँचते हैं, तो वे कतार में लगेंगे।
• अंदर आने वाले पोर्ट नहीं। आप ऐप को ब्राउज़र में नहीं खोल सकते। उसे अंदर शुरू करें और दूसरी कमांड से curl localhost से टेस्ट करें।
• अंदर Docker नहीं। कंटेनर चलाने वाले टेस्ट VPS पर runner में होने चाहिए।
• बाहर जाने वाला इंटरनेट खुला है। इसी से pip install काम करता है। सैंडबॉक्स में ऐसा कुछ न रखें जो आप पैच के लेखक को न देते।

शुरुआत कैसे करें

नए खातों को $1 का सैंडबॉक्स समय मिलता है, जो standard टैरिफ़ पर सौ से ज़्यादा रिव्यू के लिए काफ़ी है। सैंडबॉक्स पेज पर टैरिफ़ हैं, SDK संदर्भ में ऊपर इस्तेमाल हुई हर विधि, और 5 मिनट में Python SDK में सेटअप।

संबंधित: पूरी पाइपलाइन के लिए अलग CI टेस्ट रन, और कोड लिखने वाले एजेंटों के लिए AI एजेंटों के लिए सैंडबॉक्स।