AI घटनाओं को संभालता है, इंजीनियर अपने सिस्टम्स से संपर्क खो देते हैं
जैसे-जैसे AI systems production incidents का निदान और remediation अधिक करने लगते हैं, कई engineers को डर है कि वे जटिल software को समझने और सुरक्षित रूप से चलाने के लिए ज़रूरी hands-on intuition खो रहे हैं। Commenters aviation की “ironies of automation” से समानताएँ खींचते हैं, और कहते हैं कि जब machines routine काम संभालती हैं, तो humans को कम अभ्यास मिलता है और वे दुर्लभ, उच्च-दांव failures के लिए तैयार नहीं रह सकते—खासकर जब नई पीढ़ियाँ अपने करियर की शुरुआत AI-mediated दुनिया में करती हैं। दूसरे जवाब देते हैं कि सही ढंग से उपयोग करने पर AI operational “floor” को ऊपर उठा सकता है, troubleshooting तेज़ कर सकता है, और experts को architecture तथा guardrails पर ध्यान केंद्रित करने के लिए मुक्त कर सकता है, लेकिन केवल तभी जब organizations प्रशिक्षण, simulation, और automated actions के लिए स्पष्ट सीमाओं में जानबूझकर निवेश करें।
घटनाओं और संचालन में AI की भूमिका
- कई लोगों का मानना है कि अवलोकनीय, मानकीकृत सिस्टम्स (जैसे Kubernetes, cloud infra) में triage के मामले में LLMs पहले ही इंसानों से बेहतर प्रदर्शन कर रहे हैं, और root causes को तेज़ी से संकुचित कर रहे हैं।
- दूसरे तर्क देते हैं कि AI द्वारा बनाया गया कोई भी बदलाव फिर भी एक information system है जिसे इंसान जाँच सकते हैं; सचमुच कठिन घटनाओं के लिए फिर भी सक्षम operators की ज़रूरत होगी।
- चिंता यह है कि “AI आसान tickets निपटा देता है,” और मानवों के पास केवल दुर्लभ, गंभीर घटनाएँ बचती हैं, जिनमें पर्याप्त वास्तविक अभ्यास नहीं होता—यह aviation की automation समस्याओं की याद दिलाता है।
कौशल का क्षरण और system intuition का नुकसान
- बार-बार सामने आने वाला विषय: AI का उपयोग “quicksand” जैसा लगता है — जितना अधिक यह लिखता/debug करता है, उतनी ही कम intuitive समझ engineers को अपने systems और code की रह जाती है।
- वरिष्ठ engineers बताते हैं कि उनके सहकर्मी पीछे जा रहे हैं: सीधे AI पर कूद पड़ना, error messages पर brute-force करना, debugging discipline और architectural thinking खो देना।
- सबसे अधिक चिंता juniors को लेकर है, जो शायद कभी मूलभूत बातें ही न बना पाएँ, खासकर समय के दबाव में और “AI इस्तेमाल करो वरना slow हो” वाली संस्कृति में।
AI-जनित code और debugging की गुणवत्ता
- शिकायतें: over-engineered, verbose, duplicated, और inconsistent code; अस्थिर “libraries” जो हर generation के साथ बदलती हैं; tech debt का विस्फोट।
- दूसरे जवाब देते हैं कि कई मौजूदा codebases में LLM output पहले ही औसत human code से बेहतर है और guided होने पर refactors/ports के लिए उत्कृष्ट है।
- benchmark परिणाम और अनुभव बताते हैं कि models “spiky” हैं: कुछ bugs पर शानदार, दूसरों पर बहुत खराब या hallucination-prone। Trust अभी भी एक मूल समस्या है।
संगठनात्मक प्रोत्साहन और संस्कृति
- कई टिप्पणियाँ management को दोष देती हैं: OKRs स्पष्ट रूप से भारी AI उपयोग, low-code tooling, और समझ या reliability पर shipping speed को प्रोत्साहित करते हैं।
- कुछ का तर्क है कि यह उद्योग के लंबे समय से चले आ रहे पैटर्न (outsourcing, RPA, “scripts के ज़रिए ops”) जैसा है, न कि कुछ बिल्कुल नया।
- developers को craftspeople बनाम interchangeable delivery labor के रूप में देखने के बीच तनाव है; AI उस टकराव को और बढ़ा देता है।
उपशमन और प्रस्तावित अभ्यास
- सुझाव: drills/chaos engineering, tabletop incident simulations, स्पष्ट guardrails (AGENTS.md), RPI/SDD loops, और tool use में मध्यस्थता करने वाली “AI chef” भूमिकाएँ।
- humans को architecture, boundaries, और high-risk क्षेत्रों पर नियंत्रण में रखने पर ज़ोर, और AI को chisel की तरह देखने पर, autopilot की तरह नहीं।
- कुछ लोग professionalization/licensing (pilots के समान) की वकालत करते हैं ताकि incident training बाध्य हो और shortcut लेने से रोका जा सके।
दीर्घकालिक दिशा और खुले प्रश्न
- दृष्टिकोणों में विभाजन:
- एक पक्ष भविष्यवाणी करता है कि equilibrium बनेगा जहाँ abstraction levels स्थिर हो जाएँगी और AI “बस एक और tool” होगी।
- दूसरे deep dependency की आशंका देखते हैं: इंसान underlying systems को समझना छोड़ देंगे, जबकि AI opaque stacks को भी बनाएगी और उनकी babysitting भी करेगी।
- AI-first दुनिया में experts को कैसे प्रशिक्षित किया जाए, यह अब भी अनसुलझा है।