AI कोडिंग सहायक की गलतियाँ और उनसे कैसे बचें

अधिकतर AI कोडिंग सहायक की गलतियाँ कोड बनने से पहले शुरू होती हैं: कार्य अस्पष्ट होता है, सीमाएँ छिपी होती हैं, या कोई यह तय नहीं करता कि परिणाम कैसे सत्यापित होगा। बचाव AI से दूर रहना नहीं है। बचाव सहायक को हल करने के लिए बेहतर इंजीनियरिंग समस्या देना है।

यहाँ वे विफलता पैटर्न हैं जो तकनीकी रूप से वैध बदलावों को जोखिमपूर्ण बनाते हैं, साथ ही हर एक को रोकने वाली ठोस आदत भी दी गई है।

“बटन को sidebar में ले जाएँ” सहायक को केवल यह बताता है कि कुछ कहाँ रखना है, यह नहीं कि मौजूदा जगह क्यों विफल है।

बचाव: पहले उपयोगकर्ता की समस्या और परिणाम बताएँ।

समस्या: topic switcher global navigation से प्रतिस्पर्धा करता है, लेकिन लोग इसका
उपयोग एक course के lessons की तुलना करते समय करते हैं।

परिणाम: navbar की global actions बदले बिना course navigation के पास
topic switching को ढूँढना आसान बनाएँ।

अब सहायक जगह के चुनाव पर सवाल उठा सकता है, अगर अलग small-screen pattern अधिक सुरक्षित हो।

“auth flow साफ़ करें” बड़े diff को आमंत्रित करता है। सहायक providers, routes, tests और API calls को छू सकता है, क्योंकि उसे कोई सीमा दिखाई नहीं देती।

बचाव: पहली boundary और गैर-लक्ष्यों का नाम दें।

केवल sign-in callback और उसके सीधे tests जाँचें। account
linking, billing या route guards तब तक न बदलें, जब तक साक्ष्य न दिखाए कि callback
को अलग से ठीक नहीं किया जा सकता।

यदि काम सचमुच सीमा पार करता हो, तो विस्तार करने से पहले सहायक को कारण समझाना चाहिए।

सहायक किसी component से हर product rule नहीं जान सकता। वह static app में server-only path ला सकता है, locale-preserving route तोड़ सकता है या state writer को दोहरा सकता है।

बचाव: आवश्यक invariants प्रॉम्प्ट या स्थायी project guidance में रखें।

static export, active-locale navigation, मौजूदा analytics event
names और notification preferences के वर्तमान single writer को सुरक्षित रखें।

सूची छोटी और विशिष्ट रखें। कुछ लागू किए जा सकने वाले contracts की तुलना में लंबी wish list कम उपयोगी होती है।

जनरेट किया गया कोड compile हो सकता है और फिर भी उसमें गलत state transition, error path, accessibility behavior या security boundary हो सकती है।

बचाव: कार्यान्वयन से पहले validation plan माँगें।

वे focused tests, type check और manual scenario सूचीबद्ध करें जो इस
बदलाव को सिद्ध करेंगे। बताएँ कि हर जाँच किस व्यवहार को कवर करती है और क्या असत्यापित रहता है।

जाँच चलाएँ। diff की समीक्षा करें। उपयोगकर्ता path को इस्तेमाल करें। AI output प्रस्ताव है, release criterion नहीं।

बड़ा diff छिपा देता है कि वास्तविक bug ठीक हुआ है या नहीं। उसकी समीक्षा कठिन होती है और सुरक्षित rollback लगभग असंभव होता है।

बचाव: छोटे checkpoints का क्रम माँगें।

पहले विफलता को पुन: उत्पन्न करें और समझाएँ। फिर केवल state fix करें और
regression test जोड़ें। focused test के पास होने और diff की समीक्षा होने तक
संबंधित components का रिफ़ैक्टर न करें।

छोटा बदलाव बता सकता है कि नियोजित रिफ़ैक्टर की आवश्यकता ही नहीं थी।

“इस page को तेज़ करें” caching, memoization या code splitting पैदा कर सकता है जो असली bottleneck छिपा दे और नए invalidation risks बना दे।

बचाव: measurement और alternatives माँगें।

पहचानें कि धीमापन network, computation या rendering में है। optimization प्रस्तावित करने से पहले
measurement, baseline और expected impact बताएँ।
freshness और invalidation परिभाषित होने तक persistent caching न जोड़ें।

performance work को मापी हुई लागत बदलनी चाहिए, केवल परिचित तकनीक नहीं जोड़नी चाहिए।

सहायक mobile layout बेहतर करने के लिए desktop sidebar हटा सकता है, या लोगों के भरोसे वाले flow को सरल कर सकता है। कोड साफ़ हो सकता है जबकि उत्पाद बदतर हो जाए।

बचाव: वे लोग, workflow और व्यवहार बताएँ जिन्हें बने रहना है।

mobile learners को अधिक horizontal space चाहिए। desktop learners course navigation के लिए
sidebar पर निर्भर हैं। desktop workflow और उसके keyboard path को सुरक्षित रखते हुए
mobile layout बेहतर बनाएँ।

यह “sidebar हटाएँ” को वास्तविक design constraint में बदल देता है।

production incidents से तात्कालिकता बनती है, लेकिन तात्कालिकता किसी सहायक को लक्षण से अनुमान लगाने देने का कारण नहीं है।

बचाव: evidence-to-validation sequence का उपयोग करें:

साक्ष्य -> परिकल्पनाएँ -> सत्यापन -> सबसे छोटा fix -> regression test ->
सुरक्षित rollout जाँच

संवेदनशील मान हटाए गए logs, reproduction steps, environment, हाल के बदलाव, अपेक्षित व्यवहार और देखा गया व्यवहार शामिल करें। जनरेट किए गए patches को बिना जाँचे production में लागू न करें।

समस्या: [कौन प्रभावित है और क्या हो रहा है?]
दायरा: [पहले क्या जाँचा जाना चाहिए?]
परिणाम: [कौन-सा देखा जा सकने वाला नतीजा चाहिए?]
बाध्यताएँ: [क्या नहीं बदलना चाहिए?]
साक्ष्य: [Test, log, screenshot, command output या reproduction.]
स्वीकृति मानदंड: [हमें कैसे पता चलेगा कि यह काम कर गया?]
सत्यापन: [Tests, manual checks या measurements.]

संपादन से पहले धारणा पर सवाल उठाएँ। यदि माँगा गया समाधान साक्ष्य से
समर्थित नहीं है, तो अधिक सुरक्षित विकल्प समझाएँ।

इस संरचना के विस्तृत विश्लेषण के लिए बेहतर AI प्रॉम्प्ट कैसे लिखें पढ़ें। रोज़मर्रा के कार्यान्वयन पैटर्न के लिए डेवलपर्स के लिए प्रॉम्प्ट इंजीनियरिंग का उपयोग करें। जब कोई incident शामिल हो, तो production issues को डीबग करने के प्रॉम्प्ट टेम्पलेट का पालन करें।

terminal output भी साक्ष्य है। उसे bug report, test या automation prompt में डालने से पहले ब्राउज़र में command-line workflow का अभ्यास करें।