AI अपने दम पर सबसे बड़ा कौन-सा सॉफ्टवेयर प्रोजेक्ट पूरा कर सकता है?
डेवलपर्स यह जानने की कोशिश कर रहे हैं कि वर्तमान AI मॉडल स्वायत्त रूप से सॉफ्टवेयर बनाने में कितनी दूर तक जा सकते हैं—shells, compilers, retrieval engines से लेकर full apps और OS-जैसे environments तक। कई लोगों का कहना है कि AI, मजबूत tests और मानव-डिज़ाइन की गई architecture के साथ, पर्याप्त मात्रा में काम करने वाला code बना सकता है और अच्छी तरह specified systems की clone भी कर सकता है, लेकिन अगर उसे बिना निगरानी छोड़ दिया जाए तो वह जल्दी brittle, duplicated, या incoherent designs की ओर बढ़ जाता है। उभरती हुई सहमति यह है कि AI मानव-नेतृत्व वाले workflows में एक शक्तिशाली junior engineer के रूप में सबसे प्रभावी है, और असली कठिन समस्या raw code generation से अधिक long-term maintenance, architectural coherence, और requirements definition है।
“AI-complete” सॉफ्टवेयर का दायरा
- कई टिप्पणियों में कहा गया है कि “सबसे बड़ा प्रोजेक्ट” गलत सवाल है; उससे भी कठिन और दिलचस्प सवाल यह है कि AI समय के साथ कितने बड़े सिस्टम को उसकी सुसंगत आर्किटेक्चर, परफॉर्मेंस, और सुरक्षा बनाए रखते हुए मेंटेन कर सकता है।
- दूसरों का कहना है कि स्पष्ट स्पेक/टेस्ट वाले मौजूदा सॉफ्टवेयर को दोबारा बनाना, धुंधली आवश्यकताओं वाले नए प्रोडक्ट डिज़ाइन करने से कहीं आसान है।
वास्तविक-विश्व AI प्रोजेक्ट अनुभव
- रिपोर्ट किए गए AI-भारी प्रोजेक्ट्स का दायरा शामिल करता है:
- Rust में एक Bash clone, जिसमें हज़ारों tests और एजेंट्स द्वारा ठीक की जाने वाली सैकड़ों issues छोड़ी गईं।
- एक 180k-LOC investigative retrieval engine, जिसमें custom WAL, hybrid retrieval, ACLs, और लगभग 3,000 tests थे; इसका मूल्यांकन सरकारी एजेंसियों ने किया।
- लगभग 2 हफ्तों में बना एक full Linux distro, जिसे Mac app के रूप में पैक किया गया।
- Portfolio management tools, FHIR/SNOMED prototypes, caching proxies, game clones, compiler experiments, और ~2M+ LOC वाला multi-language codebase।
- सामान्य पैटर्न: AI अधिकांश implementation करता है; इंसान architecture, specs, और reviews संभालते हैं।
आर्किटेक्चर, गड़बड़ियाँ, और दीर्घकालिक स्वास्थ्य
- कई लोगों का कहना है कि बिना निगरानी के या “vibe-coded” प्रोजेक्ट जल्दी ही spaghetti में बदल जाते हैं:
- सबसे छोटे-रास्ते वाले fixes, जुगाड़ वाले patches, duplication, load-bearing hacks।
- AI अपने आप शायद ही कभी पीछे हटकर बड़े architectural refactors करता है।
- कुछ लोग कहते हैं कि यह जूनियर इंजीनियरों जैसा है जिन्हें दिशा की ज़रूरत होती है; अन्य लोग ज़ोर देते हैं कि मनुष्य जटिल सिस्टम को स्वतंत्र रूप से इस तरह डिज़ाइन और मेंटेन कर सकते हैं, जैसा वर्तमान मॉडल नहीं कर पाते।
Testing, harnesses, और guardrails
- व्यापक सहमति है कि सफलता इस पर निर्भर करती है:
- व्यापक unit/integration tests, invariants, और reference implementations के साथ end-to-end comparisons।
- छोटे-छोटे, incremental tasks और निरंतर human review।
- ऐसे harnesses/loops जो agents को सख्त test suites के तहत कई iterations चलाने दें।
- इस पर असहमति है कि क्या “बहुत सारे tests” बिना मनुष्यों की गहरी समझ के पर्याप्त हैं, जब वे यह भी नहीं समझते कि वास्तव में क्या test किया जा रहा है।
क्षमताएँ, सीमाएँ, और उपयोग के मामले
- मॉडल इन पर अच्छा प्रदर्शन करते हैं:
- छोटे से मध्यम components (जैसे ~500-line React components, endpoints)।
- अच्छी तरह specified ports/clones जिनमें समृद्ध मौजूदा tests हों।
- इन्हें कठिनाई होती है:
- नवीन architectures, बड़े अनोखे domains (जैसे CAD kernels), और global consistency।
- समय-समय पर human course correction के बिना पूरी तरह autonomous operation।
Benchmark और डेटा से जुड़ी चिंताएँ
- कुछ लोग उन benchmarks पर सवाल उठाते हैं जो केवल text-based programs को कवर करते हैं और संभवतः training के दौरान देखे गए code पर निर्भर करते हैं।
- कई लोग इस बात पर ज़ोर देते हैं कि बहुत छोटे budgets वाले benchmarks अवास्तविक हैं; गंभीर evaluations में बड़े search spaces और लंबे runs की अनुमति होनी चाहिए।