ChatGPT, GitHub Copilot, Cursor और उनके जैसे अन्य टूल्स अब आपके प्रॉम्प्ट टाइप करने से पहले ही एक React component तैयार कर सकते हैं। Next.js रूट को Supabase से जोड़ना है? कुछ ही सेकंड में हो जाएगा। उस उलझे हुए TypeScript utility को रिफैक्टर करना है? यहाँ type guards के साथ तीन विकल्प दिए गए हैं। आधुनिक वेब स्टैक पर काम करने वाले किसी भी व्यक्ति के लिए, यह अनुभव लगभग जादुई लग सकता है।
मैं इन टूल्स का रोज़ाना उपयोग करता हूँ। मेरा स्टैक Next.js, TypeScript और Supabase है, और AI सीधे मेरे एडिटर में मौजूद रहता है, जो custom hooks बनाने, डेटाबेस क्वेरीज़ जनरेट करने या उलझे हुए conditional logic को साफ़ करने के लिए तैयार रहता है। छोटे स्तर पर, यह एक बहुत तेज़ जूनियर डेवलपर की तरह काम करता है। इसे सिंटैक्स की पूरी जानकारी है। इसे वे API surface areas याद रहते हैं जिन्हें मुझे Google करना पड़ता है। यह boilerplate लिखने से थकता नहीं है।
लेकिन सॉफ्टवेयर में खामियां आती रहती हैं। ऐप्स धीमे महसूस होते हैं। कस्टमर डैशबोर्ड लैग करते हैं। Edge cases की वजह से फॉर्म क्रैश हो जाते हैं। अगर AI ने कोडिंग को इतना आसान बना दिया है, तो सॉफ्टवेयर का उपयोग करना कुछ साल पहले की तुलना में अब बुरा क्यों महसूस होता है?
इसका जवाब यह है कि सिंटैक्स जनरेट करना और सॉफ्टवेयर बनाना, दोनों एक ही काम नहीं हैं।
सिंटैक्स आर्किटेक्चर नहीं है
AI टोकन्स को बहुत अच्छी तरह से संभालता है। यदि आप इसे एक useEffect hook लिखने के लिए कहें जो Supabase real-time channel को सुनता हो, तो आपको ऐसा कुछ मिलेगा जो कंपाइल हो सके। यह एक untyped JavaScript फ़ाइल को strict TypeScript में बदल सकता है, या आपके कॉफी पीने से पहले ही Zod validation के साथ एक फॉर्म component तैयार कर सकता है।
जो यह नहीं कर सकता, वह है आपके विशिष्ट एप्लिकेशन की बारीकियों को समझना। अच्छे सॉफ्टवेयर के लिए सोच-समझकर किए गए state management, race conditions के सावधानीपूर्वक प्रबंधन और इस बात के स्पष्ट मानचित्र की आवश्यकता होती है कि डेटा कहाँ रहता है और कहाँ केवल प्रदर्शित किया जाता है। AI केवल तात्कालिक फ़ाइल को देखता है, पूरे सिस्टम को नहीं। यह आपके codebase को एक जीवित संरचना (जिसमें भार सहने वाली दीवारें हों) के बजाय एक सपाट टेक्स्ट कॉरिडोर की तरह मानता है।
इसे एक ऐसे आर्किटेक्ट की तरह समझें जिसने कभी वास्तव में किसी घर में निवास नहीं किया है। वे सुंदर फ्लोर प्लान बना सकते हैं। उन्हें पता है कि एक बेडरूम में कितनी खिड़कियाँ होनी चाहिए। लेकिन उन्हें यह नहीं पता कि फरवरी में पाइप कहाँ से लीक होने की संभावना है, या गर्मियों की गर्मी में कौन सा गलियारा अनुपयोगी हो जाता है। वह व्यावहारिक अनुभव ही है जो किसी इमारत को खड़ा रखता है। कोड भी इसी तरह काम करता है।
दो मुख्य समस्याएँ
जब मैं बिना किसी सख्त नियंत्रण (guardrails) के AI को कोड के बड़े हिस्से लिखने देता हूँ, तो मैं बार-बार एक ही दो समस्याओं को उभरते हुए देखता हूँ।
पहली बात यह कि, यह उन design patterns को नज़रअंदाज़ कर देता है जिन्हें आपने पहले ही स्थापित कर लिया है। हो सकता कि आपकी टीम डेटा फेचिंग (data fetching) के सभी कार्यों को custom hooks के एक समर्पित लेयर में निकालती हो। हो सकता कि आपके पास इस बात का एक सख्त नियम हो कि Supabase RLS policies को frontend helpers के साथ कैसे मैप किया जाए। AI को इसकी परवाह नहीं है। यदि इससे तात्कालिक प्रॉम्प्ट का समाधान होता है, तो वह सीधे एक बटन के onClick में एक कच्चा supabase.from().select() डाल देगा। कोड चलता है। यह साफ-सुथरा भी दिखता है। लेकिन यह आपके codebase में एक विसंगति (outlier) है, और हर विसंगति भविष्य में रिफैक्टरिंग का बोझ (tax) बनती है। छह महीने बाद, किसी को उस सुई को ढूँढना होगा, यह समझना होगा कि वह क्यों मौजूद है, और उसे वापस सही ढंग से व्यवस्थित करना होगा।
दूसरी बात, जब सादगी से काम चल सकता है, तब यह जटिलता की ओर भागता है। इस टूल को ऐसे रिपॉजिटरीज़ पर प्रशिक्षित किया गया है जो इतने बड़े हैं कि उन्हें abstract factories, जटिल reducer patterns और multi-layered higher-order components की आवश्यकता होती है। जब आप इसे एक साधारण संपर्क फ़ॉर्म (contact form) बनाने के लिए कहते हैं, तो यह आपको एक state machine, एक context provider और एक custom hook abstraction दे सकता है जो तीन फ़ाइलों में फैला हो। समाधान तकनीकी रूप से गलत नहीं है। यह बस भारी है। प्रत्येक अनावश्यक लेयर 'कॉग्निटिव डेट' (cognitive debt) बढ़ाती है। आपने काम को छोड़ा नहीं है; आपने इसे ब्याज के साथ टाल दिया है।
वेलोसिटी ट्रैप
यहाँ एक खतरनाक फीडबैक लूप है। AI आपको दोगुनी तेज़ी से फीचर्स बनाने की अनुमति देता है, लेकिन मानवीय ध्यान उसी तरह नहीं बढ़ पाता। यदि आप आधे समय में काम पूरा कर रहे हैं, तो क्या आप कोड रिव्यू पर दोगुना समय बिता रहे हैं? क्या आप अधिक टेस्ट लिख रहे हैं, या कम?
व्यवहार में, जनरेट किए गए कोड पर भरोसा करना बहुत आसान है क्योंकि यह आधिकारिक (authoritative) लगता है। यह आधुनिक सिंटैक्स का उपयोग करता है। कमेंट्स बिल्कुल सही जगहों पर दिए गए होते हैं। वेरिएबल के नाम पेशेवर लगते हैं। उस चमक-धमक के पीछे सूक्ष्म बग (subtle bugs) छिपे होते हैं। जैसे किसी hook में एक dependency array जो setter को छोड़ देता है। एक TypeScript type जो तकनीकी रूप से सही है लेकिन एक ऐसे null state की अनुमति देता है जिसे आप संभालना भूल गए थे। एक Supabase क्वेरी जो आपके विशिष्ट स्कीमा में soft-deleted rows का हिसाब रखना भूल जाती है। आप हर लाइन को पढ़ने के बजाय उसे सरसरी तौर पर देखते हैं, क्योंकि डिलीवरी की गति इसकी मांग करती है। सोमवार को गति बहुत अच्छी लगती है। शुक्रवार का डिबगिंग सेशन आधी रात तक चलता है।
असली लागत
जो लोग इसकी कीमत चुकाते हैं, वे डेवलपर्स नहीं हैं। वे एंड-यूज़र्स (end users) हैं।
सॉफ्टवेयर अधिक बोझिल महसूस होता है क्योंकि जटिलता टीमों द्वारा उसे संभालने की क्षमता से अधिक तेजी से बढ़ रही है। हम छोटे समूहों के साथ बड़े एप्लिकेशन बना रहे हैं, जो हमें अजेय महसूस कराने वाले उपकरणों से लैस हैं। जब एक डेवलपर एक दोपहर में पूरा डैशबोर्ड तैयार कर सकता है, तो संगठन बुधवार तक तीन डैशबोर्ड की अपेक्षा करता है। बिना सावधानी के किया गया विस्तार नाजुक प्रणालियों को जन्म देता है। स्टेट (state) बढ़ता जाता है। बंडल का आकार बढ़ता जाता है। रेस कंडीशंस (race conditions) बढ़ती जाती हैं। इंटरफ़ेस आधुनिक दिख सकता है, लेकिन जब कोई उपयोगकर्ता बैक बटन दबाता है तो यह खुद को रीसेट कर लेता है, या इसे हाइड्रेट (hydrate) होने में चार सेकंड लगते हैं क्योंकि किसी के पास AI-जनरेटेड डेटा फेच (data fetches) के वॉटरफॉल को प्रोफाइल करने का समय नहीं था।
मशीन के साथ काम करें, उसके लिए नहीं
इसका मतलब यह नहीं है कि आपको अपने एडिटर से AI को बाहर निकाल देना चाहिए। इसका मतलब है कि आपको सीमाओं की आवश्यकता है।
इसका उपयोग उसी के लिए करें जिसमें यह कुशल है। इसे उबाऊ काम करने दें: दोहराव वाले TypeScript interfaces, बॉयलरप्लेट Supabase queries, Jest setup