इससे पहले कि आप कोर प्रोडक्ट वर्क के लिए AI पर भरोसा करें, इसे पढ़ें
एक डेमो, प्रोडक्शन सिस्टम से अलग तरह से काम करता है। कई AI टूल्स डेमो में तो बेहतरीन होते हैं। जो फाउंडर्स इन दोनों के बीच भ्रमित हो जाते हैं, वे अक्सर तेजी से प्रोटोटाइप तो बना लेते हैं, लेकिन बाद में उन्हें धीमी गति से रीबिल्डिंग (rebuilds) का सामना करना पड़ता है।
AI कोडिंग का उपयोग बढ़ रहा है। 78% से अधिक कंपनियां अपने मुख्य व्यावसायिक कार्यों (core business functions) में AI का उपयोग करती हैं। छोटे स्टार्टअप्स में, इसका उपयोग 60% से अधिक है।
हालांकि, गुणवत्तापूर्ण डेटा जोखिमों को दर्शाता है। CodeRabbit के शोध से पता चला है कि AI द्वारा लिखे गए कोड में मानवीय कोड की तुलना में 1.75 गुना अधिक लॉजिक संबंधी समस्याएं होती हैं। सुरक्षा संबंधी कमियां (Security vulnerabilities) 2.74 गुना अधिक थीं। कुछ अध्ययन बताते हैं कि AI-जनरेटेड Java कोड 70% से अधिक बार सुरक्षा बेंचमार्क में विफल हो जाता है।
समस्या संरचनात्मक (structural) है। जब आप एक अस्पष्ट प्रॉम्प्ट (vague prompt) का उपयोग करते हैं, तो AI एक ही समय में आर्किटेक्चर और कोड दोनों का आविष्कार कर देता है। यह गलत क्रम है।
Spec-Driven Development (SDD) इसका समाधान करता है। आप पहले सिस्टम के नियम निर्धारित करते हैं। कोई भी कोड लिखे जाने से पहले आप API शेप्स, डेटाबेस स्कीमा और सीमाओं (boundaries) को सेट करते हैं। फिर, आप उन नियमों के आधार पर निर्माण करने के लिए AI का उपयोग करते हैं।
यह दृष्टिकोण इसलिए काम करता है क्योंकि AI अनुमान लगाने के बजाय बाधाओं (constraints) के साथ काम करता है।
प्रोडक्शन रेडीनेस (Production readiness) कोई अतिरिक्त चीज़ नहीं है। यह आपके आर्किटेक्चर का एक हिस्सा है। बैकएंड के साथ जनरेट किया गया फ्रंटएंड एक उपयोगी टूल है, लेकिन यह प्रोडक्शन सिस्टम नहीं है। एक वास्तविक सिस्टम को चाहिए:
- Containerized deployment
- Infrastructure-as-code
- Orchestration
- Health checks
- CI/CD pipelines
- Test coverage
- Observability
प्रोडक्शन के लिए AI टूल्स का मूल्यांकन करते समय, ये पांच सवाल पूछें:
- कोड लिखने से पहले टूल क्या करता है? यदि यह कुछ भी नहीं करता है, तो आप आर्किटेक्चरल ऋण (architectural debt) बना रहे हैं।
- कोड के अलावा आउटपुट में क्या है? इन्फ्रास्ट्रक्चर और टेस्ट आउटपुट का हिस्सा होने चाहिए, न कि बाद में सोचने वाली चीज़ें।
- क्या आप निर्णयों का निरीक्षण कर सकते हैं? एक 'ब्लैक बॉक्स' को बनाए रखने से बचने के लिए आपको यह देखने की आवश्यकता है कि AI कैसे काम करता है।
- सिस्टम विफलता (failure) को कैसे संभालता है? एरर हैंडलिंग और अलर्टिंग पहले से ही शामिल होनी चाहिए।
- क्या आप अपने कोड को स्थानांतरित कर सकते हैं? किसी प्रोप्रायटरी प्लेटफॉर्म से जुड़ा कोड एक निर्भरता (dependency) है, संपत्ति (asset) नहीं।
डेमो आउटपुट को देखना बंद करें। उस संरचित सोच (structured thinking) को देखें जो डेमो बनने से पहले हुई थी।
बेहतरीन टीमें आर्किटेक्चर को छोड़ती नहीं हैं। वे आर्किटेक्चर को तेज़ी से करने के लिए बेहतर टूल्स का उपयोग करती हैं। वे इंजीनियरिंग निर्णय (engineering judgment) को लागू करने के लिए AI का उपयोग करती हैं, उसे बदलने के लिए नहीं।
स्रोत: https://dev.to/8080_ai/before-you-trust-ai-with-core-product-work-read-this-2go3