- कोडिंग एजेंट अभूतपूर्व गति से कोड जनरेट करते हैं, लेकिन सख्त विवेक के बिना उनका उपयोग करना गलत मान्यताओं को सीधे production में deploy करने का एक बेहद कुशल रास्ता बन सकता है
- एजेंट द्वारा जनरेट किया गया कोड PR विवरण, static analysis पास, और test coverage तक के साथ ऐसा दिख सकता है मानो किसी अनुभवी engineer ने लिखा हो, लेकिन यह वास्तविक production environment के traffic pattern, failure mode, और infra constraints को बिल्कुल भी प्रतिबिंबित नहीं करता
- AI का उपयोग (leveraging) करना और उस पर निर्भर (relying) होना मूल रूप से अलग बातें हैं; सच्चा उपयोग का मतलब है एजेंट के output कैसे काम करते हैं और उनमें क्या जोखिम हैं, इसे पूरी तरह समझना और उसकी जिम्मेदारी लेना
- Self-driving deployments, continuous validation, और executable guardrails — इन तीन सिद्धांतों के जरिए ऐसा सुरक्षित environment बनाया जा सकता है जहाँ एजेंट उच्च स्तर की autonomy के साथ काम करें
- यह अब ऐसा दौर है जहाँ सबसे ज़्यादा कोड जनरेट करने वाला engineer नहीं, बल्कि क्या deploy किया जाना चाहिए इस पर ठंडा और स्पष्ट निर्णय बनाए रखने वाला engineer टिकेगा
समस्या: Green CI अब सुरक्षा का प्रमाण नहीं है
- CI pass होना सिर्फ इस बात को दिखाता है कि एजेंट pipeline को convince कर सकता है; इसका वास्तविक infra safety से कोई सीधा संबंध नहीं
- ऐसा query deploy हो सकता है जो tests पास कर ले लेकिन production में पूरी row scan करे
- सामान्य दिखने वाला retry logic downstream service पर Thundering Herd पैदा कर सकता है
- TTL के बिना cache चुपचाप Redis को ठप कर सकता है
- एजेंट यह नहीं जानते कि Redis instance की capacity की स्थिति क्या है, DB में कोई खास region hard-code है या नहीं, या feature flag rollout downstream system के load profile को बदल देता है
- "यह PR सही दिखता है" और "यह PR सुरक्षित रूप से deploy किया जा सकता है" — इन दोनों के बीच का अंतर हमेशा से मौजूद था, और एजेंट इस अंतर को और बढ़ा देते हैं
मुख्य फर्क: उपयोग बनाम निर्भरता
- निर्भरता (Relying): एजेंट ने लिखा और tests पास हो गए, इसलिए मान लिया कि deploy करने के लिए सब तैयार है
- लेखक बदलावों का mental model ही नहीं बनाता
- लेखक और reviewer, दोनों यह समझे बिना कि कोड वास्तव में क्या करता है, छिपी मान्यताओं से भरा एक विशाल PR बना देते हैं
- उपयोग (Leveraging): एजेंट को तेज़ iteration के लिए इस्तेमाल करना, लेकिन output पर पूरा ownership बनाए रखना
- कोड load के तहत कैसे व्यवहार करेगा, यह ठीक-ठीक समझना
- जुड़े हुए risks को समझना और उन्हें स्वीकार करने की तैयारी रखना
- PR पर अपना नाम डालने का मतलब है: "मैंने इसे पढ़ा है और समझता हूँ कि यह क्या करता है" — यही engineering process का baseline है
निर्णय का मानदंड: लिटमस टेस्ट
- सरल टेस्ट: "क्या मैं इस PR से जुड़े production incident की ownership लेने में सहज हूँ?"
- PR उठाने से पहले खुद से पूछे जाने वाले तीन सवाल
- यह कोड क्या करता है? rollout के बाद यह कैसे व्यवहार करेगा?
- production या customers पर इसका क्या नकारात्मक असर हो सकता है?
- क्या मैं इस कोड से जुड़े incident की ownership लेने में सहज हूँ?
- अगर जवाब "हाँ" है, तो आपने AI का उपयोग किया है — deploy करें; अगर "नहीं" है, तो अभी और काम बाकी है
समाधान: production सुरक्षा के लिए तीन सिद्धांत
- Self-driving deployments: हर बदलाव gated pipeline के जरिए धीरे-धीरे rollout होता है, और performance गिरने पर canary deployment अपने-आप rollback कर देता है
- यह engineers के dashboard देखते रहने पर निर्भर नहीं करता
- समस्या होने पर पूरा traffic नहीं, सिर्फ उसका एक हिस्सा isolate किया जाता है
- Continuous validation: सिर्फ deploy के समय नहीं, बल्कि लगातार infra का self-test किया जाता है
- load testing, chaos experiments, और disaster recovery drills लगातार चलती रहती हैं
- इसी वजह से Vercel द्वारा पिछली गर्मियों में production में rehearse किया गया database failover, वास्तविक Azure outage के समय customers पर बिना असर के काम कर गया
- Executable guardrails: operational knowledge को documents में नहीं, बल्कि executable tools में encode करना
safe-rollout skill, feature flag के काम करने का तरीका समझाने वाला कोई Notion page नहीं, बल्कि ऐसा tool है जो flags को wire up करता है, rollback conditions के साथ rollout plan बनाता है, और expected behavior को verify करने का तरीका बताता है- जब guardrails executable होते हैं, तो एजेंट उन्हें autonomously follow कर सकते हैं और लोगों को उन्हें याद रखने की ज़रूरत नहीं पड़ती
Vercel किन चीज़ों में वास्तविक निवेश कर रहा है
- deployment pipeline के हर चरण में runtime validation लागू करके shared infra guardrails को मज़बूत करना
- PR चरण में, खासकर feature flags से जुड़े static checks को सख्त करना
- staging environment में production mirroring end-to-end tests शुरू करना
- production में system invariants को लगातार verify करने वाले read-only agents चलाना, और code-generating agents की मान्यताओं का audit करने के लिए विशेष agents का उपयोग
- पूरे platform पर risk बढ़ रहा है या नहीं, इसे समझने के लिए defect commit बनाम defect escape ratio जैसे metrics लाना
निष्कर्ष: निर्णय क्षमता वाले engineers ही प्रतिस्पर्धी रहेंगे
- implementation अब प्रचुर मात्रा में उपलब्ध है; अब दुर्लभ संसाधन है यह निर्णय कि क्या सुरक्षित रूप से deploy किया जा सकता है
- वह दौर खत्म हो गया है जब low-quality code, low-quality दिखता था; AI tools और शक्तिशाली होंगे, diff और बड़े होंगे, और output पर आँख मूंदकर भरोसा करने का प्रलोभन भी बढ़ेगा
- लक्ष्य ऐसा संसार नहीं है जहाँ हर बदलाव पर असाधारण कठोरता लागू करनी पड़े, बल्कि ऐसा संसार है जहाँ infra स्वयं कठोर हो — ताकि तेज़ deployment डिफ़ॉल्ट रूप से सुरक्षित हो
अभी कोई टिप्पणी नहीं है.