हेडलाईन्स सतत सांगत आहेत की AI मुळे सॉफ्टवेअर डेव्हलपर्सची गरज संपून जाईल. मला तसे वाटत नाही. खरा धोका असा नाही की यंत्रे इंजिनिअरिंगवर ताबा मिळवतील. खरा धोका असा आहे की इंजिनिअर्स विचार करण्याचे कठीण काम करणे थांबवतील.
सॉफ्टवेअर म्हणजे केवळ सिंटॅक्स (syntax) टाईप करणे कधीच नव्हते. ते नेहमीच तुमच्या डोक्यात गुंतागुंत (complexity) साठवणे, अपयशाची शक्यता (failure modes) समजून घेणे आणि जेव्हा कोणताही पर्याय परिपूर्ण नसतो तेव्हा तडजोड (trade-offs) करणे याबद्दल होते. AI ने आपण कोड तयार करण्याचा वेग बदलला आहे, परंतु मानवी सहभागाची (human in the loop) गरज का आहे, हे त्याने बदललेले नाही. उलट, यामुळे स्पष्ट विचार करण्याची क्षमता अधिक मौल्यवान आणि दुर्मिळ झाली आहे.
पहिला मसुदा म्हणजे इंजिनिअरिंग नाही
मी पाहतोय की अनेक ज्युनियर डेव्हलपर्स ChatGPT किंवा Claude कडे शेजारी बसलेल्या सिनियर इंजिनिअरप्रमाणे वागतात. ते तिकीटचे वर्णन पेस्ट करतात, प्रतिसाद कॉपी करतात, टेस्ट्स रन करतात आणि कमिट (commit) करतात. जर कोड कंपाईल (compile) झाला, तर काम पूर्ण झाले असे समजतात. ही प्रक्रिया वेगवान, अडथळामुक्त आणि धोकादायक आहे.
AI वापरणे ही समस्या नाही. मी ते वापरतो. मला माहित असलेले बहुतेक उत्पादक (productive) इंजिनिअर्स ते वापरतात. समस्या तेव्हा सुरू होते जेव्हा AI हे खोलीतील एकमेव इंजिनिअर बनते. एखादा उपाय काम करतोय म्हणून तो सहज स्वीकारणे म्हणजे इंजिनिअरिंग नाही. ते तुमच्या वापरकर्त्यांना, तुमच्या व्यवसायातील मर्यादांना किंवा तुमच्या स्टॅकचा (stack) रात्री २ वाजता झालेला मागील बिघाड समजून न घेणाऱ्या मॉडेलकडे तुमचे निर्णय घेण्याचे अधिकार सोपवणे (outsourcing of judgment) आहे.
लार्ज लँग्वेज मॉडेल्स (Large language models) पूर्णपणे चुकीचे असतानाही कमालीच्या आत्मविश्वासाने उत्तरे देतात. एका इंजिनिअरने AI ला स्केलेबल आर्किटेक्चर (scalable architecture) डिझाइन करण्यास सांगितले. मॉडेलने एक सविस्तर आणि अधिकृत प्रस्ताव दिला जो पूर्णपणे अशा फीचरवर आधारित होता जे प्रत्यक्षात प्रॉडक्टमध्ये अस्तित्वातच नव्हते. ते दिसायला बरोबर होते. ते अंतर्गतदृष्ट्या सुसंगत होते. पण ते निरुपयोगी होते. धोका केवळ AI हॅल्युसिनेट (hallucinate) करते यात नाही. धोका असा आहे की आता खूप लोक त्या हॅल्युसिनेशन्सवर विश्वास ठेवतात कारण त्यांच्याकडे खोटेपणा ओळखण्यासाठी आवश्यक संदर्भ (context) उरलेला नाही.
तुम्ही संघर्षातून शिकता
जेव्हा मी विचार करतो की मला एका ज्युनियर डेव्हलपरपासून सिस्टमची जबाबदारी घेण्याइतपत प्रगल्भ बनवणारी गोष्ट कोणती होती, तेव्हा मला मी पाठ केलेले सिंटॅक्स आठवत नाहीत. मला सिस्टममधील बिघाड (outages) आठवतात. मला हाताने शोधलेले स्लो क्वेरीज (slow queries), प्रोडक्शन लोडमध्येच दिसणारे रेस कंडिशन्स (race conditions) आणि माझ्या लोकल एन्व्हायरमेंटमुळे (local environment) बिघडलेले डिप्लॉयमेंट्स (deployments) आठवतात.
डीबगिंग (Debugging) ही अशी जागा आहे जिथे खरे शिक्षण मिळते. जेव्हा तुम्ही कोड मॅन्युअली स्टेप-बाय-स्टेप तपासता, तेव्हा सिस्टम प्रत्यक्षात का फेल होते हे तुम्हाला समजते. बॉटलनेक्स (bottlenecks) कुठे येतात हे तुम्हाला कळते. जेव्हा तुम्ही १० वापरकर्त्यांच्या डेमोमधून १०,००० समवर्ती विनंत्या (concurrent requests) हाताळणाऱ्या प्रोडक्शन सिस्टमकडे वळता, तेव्हा आर्किटेक्चर कसे वागते हे तुम्ही शिकता. प्रोडक्शन आणि व्यवस्थित स्क्रिप्ट केलेला डेमो यामध्ये काय फरक असतो, हे तुम्ही तुमच्या अनुभवातून आत्मसात करता.
हे सर्व ज्ञान तयार केलेल्या उत्तरांतून मिळत नाही. ते समस्येशी झुंज दिल्याने मिळते. जर AI ने प्रत्येक संघर्ष काढून टाकला, जर त्यानेच कोड लिहिला, बग्स फिक्स केले आणि अपयशाची कारणे स्पष्ट केली, तर डेव्हलपर्सची पुढची पिढी त्यांची सिनिअरिटी (seniority) कशी मिळवेल? अनुभव म्हणजे तुम्ही डाउनलोड करता तसे कोणतेही प्रमाणपत्र नाही. तो प्रोडक्शनमधील घटना आणि बिघडलेल्या डिप्लॉयमेंट्समधून तयार झालेला तुमचा अनुभव आहे. जर तुम्ही संघर्ष काढून टाकला, तर तुम्ही प्रगती देखील काढून टाकता.
निर्मितीपेक्षा निर्णयक्षमता श्रेष्ठ आहे
काही काळ उद्योगाने 'प्रॉम्प्ट इंजिनिअरिंग' (prompt engineering) हे रिझ्युमेवर लिहिण्यासारखे एक नवीन कौशल्य मानले. पण यामुळे मूळ मुद्दाच सुटला. AI च्या युगात सर्वात मौल्यवान क्षमता म्हणजे पर्याय तयार करणे ही नाही, तर कोणते पर्याय नाकारायचे हे माहित असणे ही आहे.
मी ज्या सर्वोत्तम इंजिनिअर्ससोबत काम करतो, ते सर्वाधिक प्रॉम्प्ट्स लिहीत नाहीत. ते सर्वात कठीण प्रश्न विचारतात. रिफॅक्टरिंगमुळे (refactor) एखादे छुपे डिपेंडन्सी (dependency) निर्माण होते का, हे त्यांना माहित असते. एखादा तयार केलेला टेस्ट केस 'हॅपी पाथ' (happy path) कव्हर करतो पण ग्राहकाचा डेटा खराब करू शकणाऱ्या 'एज केस' (edge case) कडे दुर्लक्ष करतो, हे ते ओळखतात. ते अगदी योग्य वाटणाऱ्या कोडकडे पाहूनही म्हणू शकतात, "हा कोड बरोबर आहे, पण आर्किटेक्चर चुकीचे आहे."
हे शेवटचे वाक्य दोन अतिशय भिन्न संस्कृतींमधील विभाजक रेषा आहे. AI-असिस्टेड (AI-assisted) इंजिनिअरिंग म्हणजे तुम्ही तुमचे मेंदू निर्णय घेण्यासाठी वापरता आणि मशीनचा वापर स्केफोल्डिंग (scaffolding) तयार करण्यासाठी, पॅटर्न शोधण्यासाठी किंवा बॉयलरप्लेट (boilerplate) ऑटोमेट करण्यासाठी करता. AI-डिपेंडंट (AI-dependent) इंजिनिअरिंग म्हणजे तुम्ही मशीनवर पूर्णपणे अवलंबून राहता. अनेक संस्था नकळत अवलंबनाकडे (dependency) झुकत आहेत कारण अल्पकाळात ते वेगवान वाटते. वेगवान असणे म्हणजे बरोबर असणे नव्हे.
मानवाकडे असलेले काम
AI can accelerate almost every part of the development lifecycle, yet there are core practices that should remain firmly human. System design requires holding competing constraints in balance: cost, latency, reliability, and future maintainability. Architecture reviews depend on institutional memory and the ability to project second-order effects. Mentorship requires someone who has actually suffered through the failure modes they are warning you about. Deep product understanding comes from talking to users and watching behavior in the wild, not from reading training data.
Engineering judgment is the sum of those experiences. It is the quiet voice that tells you a migration is too risky to ship on a Friday afternoon, even if the code review passed. It is the intuition that a performance optimization now might create a security hole later. An LLM has no intuition. It has patterns. Patterns are useful, but they are not judgment.
Companies hiring right now need to stop optimizing for people who are merely good at using AI tools. Hire people who can challenge AI. Look for candidates who will pause, read the generated output carefully, and explain why they disagree with it. Those are the engineers who will keep your systems healthy when the generated code meets the messy reality of production.
Acceleration Without a Compass
Think of AI as an accelerator pedal. In a car with a