AI कोडिंग ने CI को एक बाधा बना दिया है, इसलिए हमने अपने सिस्टम को उसके अनुरूप फिर से बनाया
AI-संचालित कोडिंग code changes की मात्रा और गति को बहुत बढ़ा रही है, जिससे continuous integration (CI) पाइपलाइन एक नई बाधा के रूप में सामने आ रही हैं। डेवलपर्स तेज़ build systems (जैसे Bazel), self-hosted या third‑party runners, आक्रामक caching, और यहाँ तक कि अधिक checks को local या agent loops में shifting का प्रयोग कर रहे हैं ताकि test suites के बढ़ते आकार के बावजूद feedback times स्वीकार्य रहें। कई commenters यह भी सवाल उठाते हैं कि क्या यह अतिरिक्त testing सचमुच product quality सुधारती है, और सुझाव देते हैं कि human QA, product decisions, और user value ही असली constraints बने रहते हैं, भले ही raw coding और CI throughput तेज़ हो जाए।
CI नई बाधा के रूप में
- कई लोग रिपोर्ट करते हैं कि AI एजेंट्स कोड/PR की मात्रा को बहुत बढ़ा देते हैं, जिससे CI पाइपलाइनों की सीमा सामने आ जाती है।
- लंबे बिल्ड (10+ मिनट) इंसानों और एजेंट्स, दोनों की रफ्तार कम करते हैं; लोग 2–5 मिनट से कम के चक्र चाहते हैं, कभी-कभी 60 सेकंड से भी कम।
- कुछ लोगों का तर्क है कि असली बाधा अब QA, उत्पाद सत्यापन, और ग्राहक हैं (adoption, update fatigue), न कि सिर्फ CI।
Bazel, कैशिंग, और बिल्ड सिस्टम
- Bazel की बड़ी बहुभाषी कोडबेस पर warm cache के साथ लगभग 10 सेकंड के incremental builds के लिए प्रशंसा की जाती है; एजेंट्स ने Bazel migrations को पहले से कहीं तेज़ बना दिया है।
- अन्य लोग tradeoffs पर ज़ोर देते हैं: जटिल setup, per-task sandbox overhead, ऐसी ergonomics जिनके लिए parallel “normal” tooling की ज़रूरत पड़ती है, और JS/TS के लिए मिले-जुले नतीजे।
- Remote caching नेटवर्क और disk I/O से सीमित हो सकता है; optimizations में केवल digests fetch करना, बड़े artifacts के लिए content-defined chunking, और container images को hermetically build करना (Dockerfile के बिना) शामिल हैं।
- कुछ लोग Bazel-जैसी लेकिन सरल प्रणालियों (जैसे RWX, custom tools) और unified schedulers की वकालत करते हैं जो build + test को एक ही graph मानते हैं।
CI Infrastructure विकल्प
- Hosted GitHub Actions को धीमा/अविश्वसनीय और scale पर महँगा माना जाता है; कई लोग इनकी जगह ये अपनाते हैं:
- Third-party runners, तेज़ CPUs/NVMe और बेहतर caching के साथ।
- Self-hosted runners (on-prem या सस्ते cloud boxes) warm workspaces, LXD containers, और aggressive parallelization के साथ।
- GitHub तक direct peering / network links फिर भी flaky हो सकते हैं; local caches मदद करते हैं, लेकिन पूरी तरह हल नहीं करते।
Agentic Coding, Tests, और QA
- एजेंट्स बहुत बड़ी संख्या में tests बनाते हैं; कुछ pipelines में test suites लगभग चार गुना हो गए हैं।
- कई commenters AI-लिखे unit tests को trivial या redundant “slop” मानते हैं; end-to-end और characterization tests को अधिक मूल्यवान माना जाता है।
- कुछ टीम्स अब code से ज़्यादा tests review करती हैं, इस भरोसे के साथ कि यदि संबंधित tests pass हो जाएँ, तो बड़े refactors संभवतः सुरक्षित हैं।
- अन्य लोग सवाल उठाते हैं कि क्या 4× अधिक tests 4× अधिक value देते हैं, या बस CI cost बढ़ाते हैं।
SDLC और Architecture पर पुनर्विचार
- सुझावों में शामिल हैं:
- अधिकतर lint/unit checks को agent loop में ले जाना और CI को heavy/irreplicable checks के लिए रखना।
- developer machines पर अधिक CI work की अनुमति देना, signed artifacts के साथ, हालांकि supply-chain risk का उल्लेख किया जाता है।
- छोटे, contract-oriented services या modular monoliths डिज़ाइन करना ताकि agents bounded contexts के भीतर तेज़ी से iterate कर सकें।
क्या AI उत्पादकता लाभ उत्पादों को बेहतर बनाते हैं?
- कुछ लोग स्पष्ट फायदे बताते हैं: बड़े refactors और migrations जो महीनों की बजाय दिनों में पूरे हो गए, performance gains, infra cleanups, accessibility improvements, और अधिक महत्वाकांक्षी solo/indie projects।
- अन्य लोग ज़्यादातर अधिक code, अधिक trivial apps, अधिक buggy software, और flagship products या macro productivity में बहुत कम दृश्य सुधार देखते हैं, और AI-accelerated coding का अधिकांश हिस्सा “more code, not more value” के रूप में फ्रेम करते हैं।