𝗕𝘂𝗻 𝗦𝗵𝗶𝗽𝗽𝗲𝗱 𝗨𝗻𝘀𝗮𝗳𝗲 𝗔𝗜 𝗖𝗼𝗱𝗲
Bun ने हाल ही में अपने कोर को Rust में फिर से लिखा है। उन्होंने प्रायोगिक मल्टीथ्रेडिंग भी जोड़ी है। ये बड़े कदम हैं। हालाँकि, इन लक्ष्यों तक पहुँचने के लिए इस्तेमाल किया गया तरीका चिंताजनक है।
Bun टीम ने स्वीकार किया कि Rust रीराइट का अधिकांश हिस्सा Claude AI ने लिखा था। इस बदलाव ने कोडबेस में 13,000 से अधिक unsafe blocks जोड़ दिए। इसे बिना किसी concurrent garbage collector के भी शिप किया गया।
सिस्टम प्रोग्रामिंग में, unsafe कोड मेमोरी सुरक्षा (memory safety) को दरकिनार कर देता है। एक unsafe block भी एक जोखिम है। AI द्वारा लिखे गए तेरह हजार blocks एक बड़ी लायबिलिटी (liability) हैं।
मैं गति की आवश्यकता को समझता हूँ। Node.js और Deno के साथ प्रतिस्पर्धा करने के लिए छोटी टीमों को तेज़ी से आगे बढ़ना होगा। लेकिन बिना सावधानी के गति खतरनाक है।
हर unsafe block वैध मेमोरी एक्सेस का एक वादा है। जब AI कोड लिखता है, तो उस वादे पर हस्ताक्षर कौन करता है?
जोखिम स्पष्ट हैं:
- AI कोड में मेमोरी मैनेजमेंट के लिए मानवीय तर्क (human reasoning) की कमी होती है।
- High-velocity generation के लिए high-velocity review की आवश्यकता होती है।
- Concurrent garbage collector की कमी मल्टीथ्रेडेड वर्कलोड को अस्थिर बनाती है।
एक रनटाइम कोई साधारण लाइब्रेरी नहीं है। यह आपके पूरे एप्लिकेशन की नींव है। आप भरोसे के आधार पर रनटाइम चुनते हैं। जब इंफ्रास्ट्रक्चर प्रायोगिक महसूस होता है, तो डेवलपर्स Node.js जैसे स्थिर टूल्स की ओर वापस लौट जाते हैं।
मैं हर दिन AI टूल्स का उपयोग करता हूँ। मैं AI कोड के साथ वैसा ही व्यवहार करता हूँ जैसा मैं एक जूनियर इंजीनियर के कोड के साथ करता हूँ। इसे ऐसी समीक्षा की आवश्यकता है जो इसके प्रभाव के अनुरूप हो।
एक रनटाइम के भीतर मल्टीथ्रेडिंग का प्रभाव बहुत बड़ा होता है। तेरह हजार unsafe blocks के लिए तेरह हजार ठोस कारणों की आवश्यकता है। उन्हें तेरह हजार रबर स्टैम्प (बिना सोचे-समझे मंजूरी) की ज़रूरत नहीं है।
महत्वाकांक्षी होना अच्छा है। सिस्टम कोड के साथ लापरवाह होना एक जोखिम है।
क्या आप अपने प्रोडक्शन ऐप में 13,000 AI-जनरेटेड unsafe blocks चलाएंगे? इंफ्रास्ट्रक्चर के लिए AI पर भरोसा करने की आपकी सीमा क्या है?
वैकल्पिक लर्निंग कम्युनिटी: https://t.me/GyaanSetuAi