पूछें HN: प्रोग्रामिंग पेशा किस दिशा में जा रहा है?
बड़े भाषा मॉडल सॉफ्टवेयर काम को तेज़ी से नया रूप दे रहे हैं, जिससे हाथ से कोड लिखने के बजाय आर्किटेक्चर, सीमाएँ, और इरादा तय करने तथा AI-जनित कार्यान्वयन की निगरानी करने में अधिक मूल्य जा रहा है। टिप्पणीकार गति और प्रोटोटाइपिंग में लाभ देखते हैं, लेकिन “cognitive debt,” नाज़ुक सिस्टम, और घटती कोड गुणवत्ता को लेकर चेतावनी देते हैं, खासकर जब टीमें एजेंट्स को अचूक मानकर चलती हैं या सावधानीपूर्वक समीक्षा और परीक्षण छोड़ देती हैं। बहुतों का मानना है कि निम्न-कौशल और नियमित प्रोग्रामिंग भूमिकाएँ स्वचालित हो जाएँगी, जबकि माँग उन कम लेकिन अत्यधिक कुशल इंजीनियरों पर केंद्रित होगी जो AI टूल्स को ज़िम्मेदारी से संभाल सकें और वास्तविक-विश्व समस्याओं को मज़बूत सॉफ्टवेयर में बदल सकें.
समग्र भावना
- व्यापक सहमति है कि LLMs ने पहले ही सॉफ्टवेयर काम को बदल दिया है, लेकिन यह कितना दूर जाएगा और कितनी तेजी से, इस पर तीखा मतभेद है।
- चर्चा में विशाल उत्पादकता लाभों को लेकर उत्साह के साथ-साथ गुणवत्ता, जवाबदेही, नौकरियों के सिकुड़ने, और “वाइब कोडिंग” को लेकर चिंता भी शामिल है।
प्रोग्रामरों की बदलती भूमिका
- बहुतों का मानना है कि “कोड लिखना” काम का आसान/यांत्रिक हिस्सा बनता जा रहा है; शेष मूल्य यहाँ है:
- समस्याओं, उपयोगकर्ताओं, और डोमेनों को समझना।
- आर्किटेक्चर, सिस्टम डिज़ाइन, सीमाएँ, समझौते।
- AI एजेंट्स का प्रबंधन करना और उनके आउटपुट की समीक्षा करना।
- कुछ का तर्क है कि भूमिका “प्रोग्रामर” से “इंजीनियर/आर्किटेक्ट/एजेंट मैनेजर” की ओर विकसित हो रही है, कुछ हद तक वैसे ही जैसे ऐतिहासिक “analyst + programmer” मिलकर “software engineer” बने।
- अन्य लोग आशंका जताते हैं कि स्वयं कोड न टाइप करने से समझ कमजोर पड़ती है, जैसे छात्र सिर्फ पाठ्यपुस्तक पढ़कर गणित करने की कोशिश करें।
गुणवत्ता, जटिलता, और ‘cognitive debt’
- यह चिंता कि LLMs अक्सर:
- अत्यधिक-इंजीनियर्ड समाधान, अनावश्यक अमूर्तीकरण, और बड़े स्कोप की ओर झुकते हैं।
- बड़ी मात्रा में औसत दर्जे के PRs और आंशिक माइग्रेशन पैदा करते हैं।
- “cognitive debt” का नया विचार: जब सत्य का स्रोत निर्धारक कोड के बजाय प्रॉम्प्ट्स, योजनाएँ, और अस्पष्ट एजेंट बन जाते हैं।
- कुछ टीमों में थकान के कारण:
- एजेंट्स के लिए भारी अग्रिम योजना बनाना।
- AI-जनित PRs की बड़ी समीक्षा-लोड।
- यह महसूस करना कि वे “टूल्स से लड़” रहे हैं, बिना शुद्ध उत्पादकता लाभ के।
LLM क्षमताएँ, सीमाएँ, और वर्कफ़्लोज़
- मजबूत अपनाने वाले दावा करते हैं कि अग्रणी मॉडल अधिकांश कार्य लागू कर सकते हैं, यहाँ तक कि बड़े लेगेसी कोडबेस में भी, यदि:
- काम को छोटे-छोटे हिस्सों में विभाजित किया जाए।
- विस्तृत स्पेक्स, योजनाएँ, और टेस्ट हों।
- आलोचक रिपोर्ट करते हैं:
- बुनियादी डिज़ाइन/लॉजिक की गलतियाँ और कल्पित APIs/docs।
- भारी निगरानी के बिना खराब प्रदर्शन/मजबूती।
- बहस इस पर है कि क्या ऐसी विफलताएँ अंतर्निहित हैं या “skill/usage” की समस्याएँ।
- कुछ लोग कोड को “assembly” की तरह मानते हैं: वे स्रोत की बजाय उच्च-स्तरीय इरादा, जनरेटेड डॉक्स, डायग्राम, और टेस्ट की समीक्षा करते हैं।
अंगीकरण के पैटर्न और उद्योग विभाजन
- छोटी/तेज़ कंपनियाँ: LLMs को आक्रामक रूप से इस्तेमाल करने का अधिक दबाव; “वाइब कोडिंग” आम।
- बड़ी/नियंत्रित कंपनियाँ: धीमा अपनाना, मानव-स्वामित्व वाला कोड, अनिवार्य समीक्षाएँ; AI की अनुमति है लेकिन मजबूरी नहीं।
- चर्चा में संभावित विभाजन:
- उच्च-स्तरीय, सुरक्षा/प्रदर्शन-गंभीर काम: कम लेकिन अधिक कुशल इंजीनियर जो AI को पावर टूल्स की तरह इस्तेमाल करते हैं।
- मध्यम/निम्न-स्तरीय कोडिंग, प्रोटोटाइप, और सरल बिज़नेस ऐप्स: भारी स्वचालन या प्रतिस्थापन।
दीर्घकालिक दृष्टिकोण और अनिश्चितता
- कुछ लोग भविष्यवाणी करते हैं कि प्रोग्रामिंग CNC मशीनें चलाने जैसी हो जाएगी: कम मनुष्य, अधिक कमोडिटाइज़्ड कौशल।
- अन्य उम्मीद करते हैं कि AI, पूर्ण “dark factories” की बजाय, बेहतर IDE-जैसे सहायक (स्थानीय मॉडल, दृश्य/कोड मैप्स) के रूप में स्थिर होगा।
- कई इस बात पर ज़ोर देते हैं: असल में कोई नहीं जानता; मॉडल और टूलिंग के विकास की गति किसी भी आत्मविश्वासी पूर्वानुमान को संदिग्ध बनाती है।