उबाऊ तकनीक चुनें, Revisited (2025)

• "Choose Boring Technology" सिद्धांत, जो सत्यापित की जा सकने वाली तकनीकी स्टैक पर ध्यान देता है, AI coding tools के युग में और भी अधिक महत्वपूर्ण हो गया है
• कंपनियों को अपने सीमित "innovation tokens" का रणनीतिक उपयोग ऐसी तकनीकों पर करना चाहिए जिनकी विश्वसनीयता सिद्ध हो चुकी हो
• आधुनिक AI coding tools लगभग हर तकनीकी स्टैक के लिए विश्वसनीय दिखने वाला कोड बना देते हैं, लेकिन जब उपयोगकर्ता दो या अधिक ऐसी तकनीकों को जोड़ता है जिन्हें वह नहीं जानता, तो त्रुटियों का सत्यापन असंभव हो जाता है
• जिन तकनीकी स्टैक्स को आप पहले से अच्छी तरह जानते हैं, उनमें AI coding tools force multiplier(क्षमता बढ़ाने वाला उपकरण) की तरह काम करते हैं, लेकिन अनजान तकनीकों में वे सिर्फ निर्भरता का साधन बनकर रह जाते हैं
• AI द्वारा बनाए गए कोड की गुणवत्ता जितनी बेहतर होती जाती है, समस्याओं को पकड़ना उतना ही कठिन हो जाता है, इसलिए तकनीक की गहरी समझ का महत्व और बढ़ जाता है

---

Choose Boring Technology सिद्धांत की पुनर्पुष्टि

• 10 साल पहले Dan McKinley के लेख "Choose Boring Technology" से जो सहमति थी, वह 10 साल बाद भी नहीं बदली है
  • नया प्रोजेक्ट शुरू करते समय पहले यह सोचें: "क्या यह कुछ नया सीखने का बहाना है, या मैं किसी समस्या को हल करना चाहता हूँ?"
  • अगर नया सीखना है, तो अज्ञात तत्वों को एक तक सीमित रखें; अगर समस्या हल करनी है, तो उन्हीं तकनीकों पर टिके रहें जिन्हें आप पहले से जानते हैं
• LLM और agentic AI coding tools के आने से यह सिद्धांत और भी critical हो गया है

McKinley का मुख्य तर्क

• कंपनियों के पास सीमित "innovation tokens" होते हैं, और उन्हें इनका रणनीतिक उपयोग अपरीक्षित लेकिन रोचक तकनीकों पर नहीं, बल्कि स्थापित और अच्छी तरह समझी गई तकनीकों पर करना चाहिए
• उबाऊ तकनीकों में ज्ञात failure modes, अच्छी तरह समझी गई क्षमताएँ, और सिद्ध operational reliability होती है
  • जब रात 3 बजे outage हो, तब किसी अनजान क्षेत्र में रास्ता खोजने से बेहतर है ऐसी तकनीक को debug करना जिसके लिए Stack Overflow पर जवाब मौजूद हों
• यह सिद्धांत 2015 में भी सही था और आज भी सही है

AI coding tools: एक नया चर

• आधुनिक AI coding tools लगभग हर कल्पनीय तकनीकी स्टैक के लिए विशेषज्ञ-स्तर का दिखने वाला कोड बना सकते हैं
  • अगर आप Claude या Copilot से Kubernetes-आधारित microservices, GraphQL federation, या किसी आधुनिक JavaScript framework का implementation माँगें, तो वे नियमों का पालन करने वाला और चलने योग्य कोड लौटा देंगे
• लेकिन अगर आप दो या अधिक ऐसी तकनीकों का इस्तेमाल कर रहे हैं जिन्हें आप नहीं जानते, तो यह जाँचने का कोई तरीका नहीं बचता कि AI गलत परिणाम दे रहा है या नहीं
  • प्रभावशाली क्षमताओं के बावजूद LLM तकनीकी विवरणों में hallucinate(मतिभ्रम) कर सकते हैं
• ऐसे मामले देखे गए हैं जहाँ इंजीनियरों ने AI द्वारा बनाए गए समस्याग्रस्त कोड को ज्यों का त्यों स्वीकार कर लिया
  • deprecated API का उपयोग, security anti-patterns का implementation, और ऐसी सूक्ष्म performance समस्याएँ जो केवल production load पर सामने आती हैं
  • कोड सही दिखता था, naming conventions का पालन करता था, और उसमें उचित error handling भी थी, लेकिन वह उन तरीकों से गलत था जिन्हें केवल उस तकनीक से परिचित व्यक्ति ही पकड़ सकता था

अनजान तकनीक + AI कोड = अनिश्चितता का गुणन

• अपरिचित तकनीक और AI-generated code को मिलाने पर अज्ञात तत्व जुड़ते नहीं, बल्कि गुणा हो जाते हैं
  • यह नहीं पता चलता कि framework का चयन उचित है या नहीं
  • यह नहीं पता चलता कि AI implementation best practices का पालन कर रहा है या नहीं
  • यह नहीं पता चलता कि बने हुए कोड में क्या boilerplate है और क्या मुख्य business logic
  • यह नहीं पता चलता कि किन failure modes पर नज़र रखनी चाहिए
• यह सिर्फ cargo-culting नहीं, बल्कि "cargo-culting times 2,356" स्तर की समस्या है

जहाँ उबाऊ तकनीक और AI मिलकर synergy बनाते हैं

• जब आप आधारभूत स्टैक को समझते हैं, तब AI coding tools बहुत शक्तिशाली हो जाते हैं
  • Rails को अच्छी तरह जानने की वजह से Claude के संदिग्ध सुझावों को पकड़ा जा सकता है (context7 की मदद से)
  • JavaScript की प्रकृति समझने की वजह से Copilot के सुझावों का fact-check किया जा सकता है
• AI उन तकनीकों में force multiplier बनता है जिन्हें आप पहले से समझते हैं, और जिन तकनीकों को आप नहीं जानते उनमें वह dependence crutch बन जाता है

AI युग के लिए व्यावहारिक दिशानिर्देश

• नई तकनीक का मूल्यांकन करते समय पहले खुद से पूछें: "अगर AI इस तकनीक का implementation code बनाए, तो क्या मैं उसकी ठीक से review कर सकता हूँ?"
  • अगर जवाब "नहीं" है, तो उस तकनीक को mission-critical जगहों पर इस्तेमाल नहीं करना चाहिए
• अगर आपने कुछ नया सीखने का फैसला किया है (और innovation token सिर्फ एक है), तो AI सुझावों का fact-check कर सकें, इतनी गहराई से समझने में सचमुच समय लगाएँ
  • copy-paste करके बस उसके चल जाने की उम्मीद न करें
• AI tools को बहाना बनाकर कई नई तकनीकों को एक साथ अपनाने के प्रलोभन का विरोध करें
  • AI ऐसा महसूस कराता है कि आप नई language, नया framework, और नई infrastructure को एक साथ संभाल सकते हैं, लेकिन उनमें से किसी का भी ठीक से सत्यापन नहीं हो पाता

AI युग में बढ़ा हुआ जोखिम और निष्कर्ष

• मूल "choose boring technology" तर्क का उद्देश्य operational complexity और cognitive load को कम करना था, और यह चिंता आज भी वैध है
• AI युग में एक अतिरिक्त जोखिम है: किसी भी स्टैक के लिए विशेषज्ञ-जैसा दिखने वाला कोड बनाने वाले AI से मिलने वाला false confidence(झूठा आत्मविश्वास)
• AI-generated code की गुणवत्ता के कारण समस्याओं को ढूँढना उल्टा और कठिन हो गया है
  • पहले खराब कोड खराब दिखता था, अब सूक्ष्म समस्याओं को पहचानने के लिए domain की पर्याप्त समझ जरूरी है
• समस्या हल करते समय वही इस्तेमाल करें जिसे आप पहले से जानते हैं; नया सीखते समय सीखने पर ध्यान दें; और AI-generated code को समझ के साथ भ्रमित न करें
• आपके स्टैक की सबसे उबाऊ तकनीक शायद वही हो सकती है जिसे आप इतना अच्छी तरह समझते हैं कि AI के गलत होने पर उसे पकड़ सकें
  • ऐसे समय में जब AI किसी ऐसी तकनीक के लिए, जिसे आपने कभी इस्तेमाल नहीं किया, आत्मविश्वास के साथ हज़ारों पंक्तियों का कोड बना देता है, उस समझ का मूल्य पहले से कहीं अधिक है