मोटा नियम: AI को वहाँ लिखने दें जहाँ गलतियाँ सस्ती और स्पष्ट हों, और जहाँ गलतियाँ महंगी या सूक्ष्म हों वहाँ इसका उपयोग review/refactor के लिए करें। निर्णायक कारक यह है कि output को verify करने में आपको कितना खर्च होता है।
मोटा नियम: AI को वहाँ लिखने दें जहाँ गलतियाँ सस्ती और स्पष्ट हों, और जहाँ गलतियाँ महंगी या सूक्ष्म हों वहाँ इसका उपयोग review/refactor के लिए करें। निर्णायक कारक यह है कि output को verify करने में आपको कितना खर्च होता है।
इन मामलों में bug की कीमत कम होती है और आप परिणाम को ऊपर से नीचे तक पढ़ सकते हैं।
यहाँ आप AI को दूसरी नज़र के रूप में रखते हैं: वह सुझाव देता है, आप निर्णय लेते हैं।
Cost of a bug LOW Cost of a bug HIGH
New code ✅ let AI write ⚠️ AI drafts, you verify hard
Existing code ✅ AI refactors ✅ AI reviews, you write the change
Scratch से लिखना तेज़ है पर AI APIs गढ़ सकता है (hallucination) या ऐसा context चूक सकता है जिसे वह नहीं देख सकता। Reviewing सुरक्षित है पर धीमी है और केवल उतनी ही अच्छी है जितना context आप देते हैं। किसी भी तरह, आप ही जवाबदेह author हैं — AI एक tool है, commit पर हस्ताक्षर करने वाला नहीं।
इसका गलत आकलन करना ही वह जगह है जहाँ AI-assisted dev गलत होता है: लोग AI से critical logic generate करवा लेते हैं जिसे वे फिर पूरी तरह verify नहीं कर पाते, या वे हाथ से तुच्छ boilerplate लिख लेते हैं जिसे AI सेकंडों में बना सकता था। mode (लिखना बनाम review/refactor) को गलत होने की कीमत से मिलाना आपको सस्ती चीज़ों पर तेज़ और खतरनाक चीज़ों पर सावधान रखता है। जो skill परखी जा रही है वह यह judgment है कि अपना verification प्रयास कहाँ खर्च करें — न कि यह कि आप किसी AI को prompt कर सकते हैं या नहीं।