डोमेन विशेषज्ञता हमेशा असली moat रही है

 (brethorsting.com)
29 पॉइंट द्वारा GN⁺ 2026-05-31 | 7 टिप्पणियां | WhatsApp पर शेयर करें
  • सॉफ़्टवेयर की कठिनाई कोड टाइप करने से ज़्यादा वेतन, परिवहन जैसी वास्तविक दुनिया के नियमों को समझकर domain model बनाने में थी, और कोड उस समझ का परिणाम था
  • Agentic AI डोमेन समझ के बिना भी सॉफ़्टवेयर बनाना संभव बना रही है और bottleneck को “क्या इसे बनाया जा सकता है” से “क्या यह सही है, इसका निर्णय किया जा सकता है” की ओर ले जा रही है
  • लॉजिस्टिक्स dispatcher, clinical coder, actuary जैसे domain experts को कोड न भी आता हो, फिर भी वे यह पहचान सकते हैं कि output क़ानूनी, billing या operational rules के अनुरूप है या नहीं
  • एक generalist engineer architecture और reliability की जाँच कर सकता है, लेकिन clinical coding जैसे क्षेत्रों में, जहाँ सही उत्तर डोमेन ज्ञान से बँधा होता है, वह भरोसेमंद दिखने वाली ग़लतियों को चूक सकता है
  • सबसे मूल्यवान क्षमता वह निर्णय है जो generated code की मजबूती और output की सत्यता, दोनों को साथ में verify कर सके; इसलिए अनुभवी engineers के लिए डोमेन विशेषज्ञता में निवेश और अधिक महत्वपूर्ण हो रहा है

कोड लिखना नहीं, डोमेन समझना ही मूल बात है

  • सॉफ़्टवेयर विकास में कठिन हिस्सा कोड लिखना नहीं था, बल्कि पहले दिमाग़ में डोमेन के काम करने का मॉडल बनाना था
  • कोड उस समझ की सिर्फ़ transcription था, और उस समझ को हासिल करने की प्रक्रिया ही असली काम थी

  • ठोस उदाहरण

    • payroll system launch करने से पहले garnishment deduction, pre-tax deduction और वे स्थितियाँ समझनी पड़ती थीं जहाँ pay period, wage rate change के समय को overlap करता है
    • public transit app launch करने से पहले यह सीखना पड़ता था कि GTFS feed क्या है, trip और route अलग क्यों हैं, और “on-time” बस कैसे फिर भी ग़लत हो सकती है

Agentic AI ने इस कड़ी को तोड़ दिया

  • Agentic AI ने model building और software production के बीच की कड़ी तोड़ दी है, जिससे model के बिना भी software बनाना संभव हो गया है
  • इससे उस मूल धारणा पर चोट पड़ती है जिस पर पूरा पेशा संगठित था
  • पिछले साल का दृष्टिकोण यह था कि यह टूल judgment रखने वाले senior developers को amplify करता है, और यह बात सही है लेकिन अधूरी है
  • वास्तव में देखा गया बदलाव यह है कि मुख्य constraint “क्या इसे बनाया जा सकता है” से “क्या यह सही है, इसका निर्णय किया जा सकता है” पर शिफ्ट हो गया है

दो तरह के लोगों की तुलना

  • डोमेन विशेषज्ञ (सॉफ़्टवेयर पृष्ठभूमि के बिना)

    • जैसे logistics dispatcher, clinical coder, actuary; जो stack trace नहीं पढ़ सकते और hashmap तथा list का अंतर भी समझा नहीं सकते
    • लेकिन agent द्वारा बनाया गया schedule देखकर वे तुरंत समझ जाते हैं कि कोई भी driver क़ानूनी रूप से यह shift नहीं कर सकता, या उस code के लिए किया गया claim कभी pay नहीं होगा
    • क्योंकि वे 10 साल तक inputs और outputs के बीच काम कर चुके होते हैं, वे दिए गए input के लिए सही output जानते हैं, और agent उनकी कोड-उत्पादन की कमी को ठीक-ठीक पूरा कर देता है
    • वे जो लेकर आते हैं, वह है ground truth, जो agent नहीं दे सकता

  • डोमेन अनुभव के बिना शक्तिशाली generalist engineer

    • वह कुछ भी design कर सकता है, reliability, testing और रात 2 बजे भी system को गिरने से बचाने के तरीके जानता है
    • लेकिन clinical coding में लगाने पर वह सही उत्तर और plausible दिखने वाले ग़लत उत्तर में फ़र्क नहीं कर पाता
    • agent ऐसा billing rule बना देता है जो compile हो जाता है और engineer द्वारा लिखे tests भी pass कर लेता है, लेकिन वह सूक्ष्म और महँगी ग़लती होती है
    • engineer के पास oracle नहीं होता; वह यह verify कर सकता है कि software अच्छी तरह बना है, लेकिन यह नहीं कि वह सही है — क्योंकि correctness उस डोमेन से परिभाषित होती है जो उसके दिमाग़ में मौजूद ही नहीं है

असमानता जहाँ सिर्फ़ एक रास्ता टूटा है

  • agent से पहले engineer के पास वह रास्ता था जो dispatcher के पास नहीं था — expert के साथ काम करते हुए, specs पढ़ते हुए और production environment में ग़लतियाँ झेलते हुए वह धीरे-धीरे domain model सीख सकता था
  • कई क्षेत्रों में यही रास्ता खुद career ladder था, लेकिन domain expert के पास reliable software बनाना सीखने के लिए वर्षों की समानांतर यात्रा नहीं थी
  • Agentic tools ने इन दो रास्तों में से सिर्फ़ एक को तोड़ा है
    • domain model को code में बदलने की engineer की ताकत अब cheap हो गई है
    • क्या सही है, यह जानने वाले domain expert की ताकत cheap नहीं हुई है, और prompt से वहाँ पहुँचा नहीं जा सकता
    • जिसने हज़ारों payroll रन संभाले हों, उसके tacit knowledge को समेटने वाली कोई skill file मौजूद नहीं है

दोनों परतों को verify करने वाला व्यक्ति

  • इस नई दुनिया में सबसे मूल्यवान व्यक्ति वह है जिसके पास दोनों कौशल हों और जो दोनों परतों पर verify कर सके
  • वह जानता हो कि generated code मज़बूत है, और साथ ही यह भी कि उस code का answer सच है
  • नियमों को जानने के कारण वह “driver 11 घंटे से ज़्यादा काम नहीं कर सकता” जैसी बात encode करने वाले tests लिख सकता है, और यह भी समझता है कि वे tests वास्तव में सार्थक हैं
  • agent transcription संभालता है, और इंसान दो बार निर्णय लेता है

अनुभवी engineers के लिए दांव किस पर लगाना चाहिए

  • आने वाले कुछ वर्षों में कहाँ निवेश करना है, यह सोच रहे अनुभवी engineers के लिए यही दांव की दिशा है
  • साफ़ idea को साफ़-सुथरे code में बदलने वाली mechanical skill का मूल्य तेज़ी से गिर रहा है
  • जो अब भी दुर्लभ है, वह किसी वास्तविक डोमेन का गहरा और सत्यापित मॉडल है, और वही हासिल करना चाहिए
    • किसी industry, financial product, regulatory system या physical process में से एक चुनें, और जैसे पहले programming language या framework सीखा जाता था, वैसे ही उस डोमेन को सीखें
    • यही वह हिस्सा है जिसे agent आपके लिए नहीं कर सकता, और अब सबसे अधिक मूल्य भी उसी में है

संबंधित पढ़ाई

7 टिप्पणियां

 
xguru 2026-06-01

स्पष्ट विचारों को साफ़ कोड में बदलने की mechanical skill का मूल्य नाटकीय रूप से गिर रहा है

लेकिन मुझे लगता है कि यह कोड को कुछ ज़्यादा ही कम करके आँकना है।
सॉफ़्टवेयर डेवलपमेंट खुद भी एक domain है, और उसमें अच्छा होना भी एक विशेषज्ञ skill है।
AI जो सॉफ़्टवेयर बनाता है, वह functional स्तर पर समस्या हल कर देता है, लेकिन उसे पूरी तरह polished नहीं बना पाता, और उस कमी को भरने के लिए इंसान की ज़रूरत रहती है।
 
heycalmdown 2026-06-01

यह Hacker News की टिप्पणियों में आई इस राय जैसा ही है।

इस लेख में वर्णित software generalist के पास भी domain expertise है। वह domain software है

यह उसी राय के समान है।
 
roxie 23 일 전

मुझे xguru जी की बात पर थोड़ी असहमति है.

Excel का उदाहरण लेते हैं। आम तौर पर कंपनी के काम के लिए जितने स्तर की ज़रूरत होती है, लोग वहीं तक सीखते हैं और उसके आगे ज़्यादातर लोग खास तौर पर और सीखने की कोशिश नहीं करते। Excel को पागलों की हद तक अच्छी तरह चलाने वाले लोग भी होते हैं, लेकिन वह सच में बहुत अपवाद वाले मामले हैं।

कोड के मामले में भी — अभी तो ऐसा नहीं है — शायद यह दो धाराओं में बंट सकता है। एक, बहुत कम लोग जो बेहद जटिल products बनाते हैं, और दूसरे, बहुत बड़ी संख्या में लोग जो उसे साइकिल चलाने की तरह इस्तेमाल करते हैं।
 
xguru 23 일 전

हूँ? जो लोग Excel को अच्छी तरह संभालते हैं, उन्हें हम कम नहीं आंकते।
लेकिन यह कहना कि coding करने की क्रिया की अपनी value गिर गई है, थोड़ा कमतर आंकने जैसा लगता है।

मेरा मानना है कि सिर्फ इसलिए कि कोई चीज़ साइकिल चलाने की तरह इस्तेमाल की जाती है, जटिल products बनाने वाले लोगों से यह नहीं कहना चाहिए कि आपकी value कुछ खास नहीं है।
 
roxie 23 일 전

मैं आपकी कही बात से सहमत हूँ,

और बात यह थी कि ऐसी तकनीक और कोड, जिन्हें जटिल software कहा जा सकता है, कम होते जाएंगे। अगर AI से हल्के-फुल्के तौर पर लिखी जा सकने वाली चीज़ें बढ़ती जाएँ।

GeekNews सारांश की अभिव्यक्ति उधार लें तो: ऐसा लगता है कि वह कोड, जिसे agent हमारी जगह नहीं कर सकते, दिन-ब-दिन कम होता जाएगा.
 
devpain 2026-06-01

वह हिस्सा अब लगभग ऐसी स्थिति में है जहाँ tacit knowledge लगभग गायब हो चुकी है, और क्योंकि शीर्ष स्तर के domain experts agent डिज़ाइन करके उसे model में embed कर रहे हैं,,, अभी domain knowledge की अहमियत पर ज़ोर दिया जा रहा है, लेकिन पता नहीं 1 साल बाद भी यही बात कही जाएगी या नहीं। आखिरकार tacit knowledge धीरे-धीरे prompt में शिफ्ट हो रही है, और models यूज़र के prompt में जोड़ी गई tacit knowledge को चुनकर फिर से model में inject करेंगे। tacit knowledge से लैस agent models की वैल्यू तो होगी, लेकिन मुझे लगता है कि यह भी market में ट्रेड होगा। उस क्षेत्र में कहीं अधिक domain knowledge से समृद्ध agent।
मेरा अनुमान है कि 1 साल बाद orchestration से आगे बढ़कर agent management (कंपनी की तरह) ही मूल्यांकन का मानदंड बन जाएगा।
 
GN⁺ 2026-05-31
Hacker News की राय

  • यह मानने के लिए और कितना लंबा भाषण चाहिए कि व्यक्तिगत स्तर पर AI का इस्तेमाल कैसे करना है, यह किसी को नहीं पता
    पहले कहा गया कि बस एक अच्छे डेवलपर बनो और AI इस्तेमाल करना सीख लो, फिर कहा गया कि असली बात आर्किटेक्चर डिज़ाइन क्षमता है, फिर कहा गया कि रुचि ही सब कुछ तय करती है, और अब कहा जा रहा है कि सिर्फ domain experts ही मायने रखते हैं
    जब तक AI का सुधार या ठहराव स्थिर और अनुमानित स्थिति में नहीं पहुँचता, तब तक ऐसी व्याख्याएँ लगातार निरर्थक रहेंगी और ज़्यादातर गलत होने की संभावना रहेगी

    • मेरी राय धीरे-धीरे पक्की होती जा रही है कि AI tools software development को और कठिन बनाते हैं
      यह इसलिए कठिन होता है क्योंकि वे जो संभव है उसकी सीमा को बहुत ऊपर उठा देते हैं। अब एक अकेला डेवलपर कहीं अधिक कठिन प्रोजेक्ट उठा सकता है, और अंत में बाधा हमेशा समय ही रही है; AI बस दिए गए समय में ज़्यादा काम करने में मदद करता है
      लेकिन उसी समय के भीतर जो काम अब किया जा सकता है, वह खुद कहीं ज़्यादा कठिन हो गया है। आपको बहुत अधिक चीज़ें समझनी पड़ती हैं, और AI से पहले की अपनी परिचित safe zone से बहुत बाहर जाना पड़ता है
      पहले यह स्वीकार्य था कि किसी अपरिचित system area या नई library को सीखने की वजह से codebase refactoring या किसी छोटे feature को ship करने की तैयारी में कई दिन लग जाएँ
      coding agents की वजह से उस learning curve पर कहीं तेज़ी से चढ़ा जा सकता है, लेकिन चढ़ना फिर भी खुद ही पड़ता है। और आने वाली जानकारी की मात्रा बहुत अधिक हो जाती है
      अगर आपको यह चिंता है कि कोई non-technical vibe coder आपकी नौकरी ले लेगा, तो सही प्रतिक्रिया यह है कि आप उनसे कहीं बेहतर software बनाएँ। उसके लिए ज़्यादा skill, बड़ा ambition, और ज़्यादा experience चाहिए, और यह आसान नहीं है
    • LLM बस हथियारों के भंडार में जुड़ने वाला एक tool है। यह सर्वशक्तिमान नहीं है, और दूसरे tools की तरह इसे भी सावधानी से इस्तेमाल करना चाहिए
      अब तक मुझे जो सबसे उपयुक्त तुलना लगी है, वह modern electric drill driver और screwdriver/hand drill जैसे पुराने उपकरणों की तुलना है
      पुराने उपकरणों की तुलना में यह बहुत कम समय में चौंकाने वाले नतीजे दे सकता है
      उदाहरण के लिए, “जिस फ़र्श को फिक्स करने में पूरा दिन लगता, उसे 1 घंटे में खत्म कर दिया और बीच में कई बार सिगरेट भी पी” जैसी हैरान कर देने वाली बातें संभव हो जाती हैं। अगर nail gun इस्तेमाल की होती तो शायद आधे समय में काम हो जाता, लेकिन बाद में उस फ़र्श को आसानी से उठाना मुश्किल होता और लागत भी शायद लगभग दोगुनी पड़ती
      मैं कई on-premise LLM भी इस्तेमाल करता हूँ और दूसरे models तक भी मेरी पहुँच है, इसलिए लगता है कि किसी दिन इस तुलना को brand के फ़र्क तक भी बढ़ाना पड़ेगा
      लेकिन मुझे नहीं लगता कि यह नया job ढूँढ़ने निकल पड़ेगा। electric drill driver कोई बढ़ई या construction worker नहीं होता, और इंसान के बिना इसका कोई मतलब नहीं है
    • 20 साल पहले का object-oriented hype याद है? GoF की किताब को बस ऊपर-ऊपर पढ़कर, क्यों इस्तेमाल करना है यह जाने बिना, सब लोग patterns का अंधाधुंध इस्तेमाल करते थे; हम आज भी अपने codebase से उसी तरह का code साफ कर रहे हैं
      20 साल बाद मुझे लगता है कि हम Claude के साथ मिलकर लिखे गए कचरे को साफ कर रहे होंगे
      https://mastodon.gamedev.place/@JeremiahFieldhaven/116654345...
    • AI से पहले भी कई बार domain expert होना, बेहतरीन software developer होने से ज़्यादा मूल्यवान था
      2018 में मैंने एक ऐसे व्यक्ति को देखा था जिसे coding का बिल्कुल अनुभव नहीं था, लेकिन वह एक खास niche market को जानता था; उसने एक महीने coding करके ऐसा tool बना लिया जो काफ़ी अच्छा पैसा कमा रहा था
      उसने मुझे code का कुछ हिस्सा दिखाया; वह मेरे पहले program जितना ही बुरा था, लेकिन वह असली समस्या हल कर रहा था
    • यह कुछ वैसा लगता है जैसे दर्शक या आम लोग professional sports का मूल्यांकन करते हैं
      मान लीजिए वे कहते हैं, “खेलों में अच्छा होने के लिए पूर्ण symmetry चाहिए, और इसका fetal development stability से गहरा संबंध है। जितनी अधिक symmetry, उतना अधिक perfect development”
      फिर कुछ साल बाद खबर आती है कि Bruce Lee की एक टांग दूसरी से काफ़ी छोटी थी, और Usain Bolt में भी इसी तरह का asymmetrical development था
      तब वे कहते हैं कि ये तो अपवाद हैं, इसलिए सामान्य नियम पर इसका असर नहीं पड़ता, और इस तरह अपनी पहली बात को पलटकर बचाने लगते हैं
      बस कुछ दिलचस्प बनाइए, और हो सकता है वह सफल भी हो जाए

  • मैंने हाल ही में एक ऐसा app review किया जो लगभग पूरी तरह vibe coding से बना था। मालिक ने कहा कि वह लगभग launch के लिए तैयार है और बस एक जल्दी से check चाहिए
    देखने पर database design पूरी तरह बिखरा हुआ था। कुछ features काम कर रहे थे और कुछ नहीं। मैंने बताया कि क्या-क्या missing है और चीज़ें क्यों टूट रही हैं। मूल पोस्ट की तरह वह व्यक्ति भी domain expert था
    सिर्फ पिछले महीने में उसने अरबों tokens खर्च किए, और tools तेज़ी से बेहतर हो रहे हैं। लेकिन domain expert को AI दे देने से software engineer की ज़रूरत खत्म नहीं हो जाती
    domain expert AI के साथ software बना सकता है, और software engineer AI के साथ domain सीख सकता है। दोनों अलग-अलग तरह की expertise लेकर आते हैं

    • मैं जिस दिशा में बढ़ रहा हूँ, वह आख़िरकार platform engineer के काफ़ी करीब लगती है
      जब domain experts coding agents का इस्तेमाल शुरू करेंगे, तब उनके लिए सुरक्षा देने वाले guardrails, validation, prompt libraries, agents, और manual reviews बनाना ही काम होगा
      यह कुछ हद तक internal T2/T3 customer support या support engineers जैसा है। रोज़मर्रा की समस्याएँ 100% खुद हल करने के बजाय, खतरनाक बिंदुओं, अजीब boundary cases को पकड़ना और यह सुनिश्चित करना कि सारी settings सही हों—यही भूमिका है
      बेशक, इसमें बहुत से cross-cutting concerns भी संभालने पड़ेंगे
    • मेरा अनुभव भी ऐसा ही है। LLM दूसरे domains को खोजना आसान बनाते हैं, लेकिन वे आपको उस domain का उस्ताद नहीं बनाते। विशेषज्ञ domain knowledge की ज़रूरत फिर भी रहती है
      हाँ, नए ideas को जल्दी आज़माने और गहराई में जाने के tool के रूप में यह शानदार है। अगर आपके भीतर जिज्ञासा है, तो यह सीखने की रफ़्तार को बहुत बढ़ाने वाला accelerator बन सकता है
    • “सिर्फ पिछले महीने में उसने अरबों tokens खर्च किए” यह हिस्सा मुझे ठीक से समझ नहीं आता
      मैं पूरा दिन Claude Code (Opus 4.6, maximum effort setting) इस्तेमाल करता हूँ, फिर भी यह कैसे संभव है समझ नहीं आता
      यह भी जानना चाहता हूँ कि क्या इतना usage वास्तव में फायदा दे रहा है
      हो सकता है मुझे ही सही जानकारी न हो, लेकिन सच में समझ नहीं आता कि ऐसा कैसे होता है
    • अगर domain expertise के साथ लगातार बना रहने वाला QA mindset जुड़ जाए, तो शायद software engineer की जगह ली जा सकती है, लेकिन लगातार बना रहने वाला QA mindset दुर्लभ है

  • हाल ही में इसका एक बहुत अच्छा उदाहरण देखने को मिला
    मैं मछली पकड़ने की यात्रा पर था, और मैंने कप्तान से पूछा कि क्या वह देखना चाहेंगे कि जिस मुफ़्त ऐप पर मैं काम कर रहा हूँ (https://oceanconnect.ca) क्या वह उनके काम में मदद कर सकता है
    मुझे अच्छी तरह पता नहीं था कि समुद्र में लोग marine data का इस्तेमाल कैसे करते हैं। वे क्या जानना चाहते हैं, और क्यों जानना चाहते हैं, यह भी ठीक से नहीं पता था। लोगों द्वारा data का उपयोग कैसे किया जाता है, और हम data से क्या कर सकते हैं, इस बारे में सवालों और जानकारी की बौछार आ गई, और मैं उसके लिए बिल्कुल तैयार नहीं था; वह नज़रिया मिलना सचमुच बहुत शानदार और दिलचस्प था
    इसने मुझे फिर याद दिलाया कि model उस system जैसा नहीं होता जिसे वह abstract करता है, और model विकसित करने का ज्ञान, उसे उपयोग करने के ज्ञान से लगभग जुड़ा ही नहीं होता
    इस व्यक्ति के पास पानी पर weather data का उपयोग कैसे किया जाता है, इस बारे में जबरदस्त ज्ञान था। एक अर्थ में वह data को मुझसे बेहतर जानता था, और भले ही उसे इसका एहसास न हो या वह इसकी digital representation को न समझता हो, अगर वह सिर्फ programming कर पाता, तो शायद अपने जैसे लोगों के लिए कहीं बेहतर उपयोगी app बना सकता था
    मैंने सोचा कि अगर ऐसे लोगों के सामने LLM हो और वे अपने ideas को स्क्रीन पर उतार सकें, तो वे सचमुच कमाल की चीज़ें बना सकते हैं। कभी funding मिली तो मैं हर दिन समुद्र में जाने वाले लोगों का interview लेकर product को refine करना चाहूँगा। वह domain knowledge बहुत विशिष्ट है, और जटिल domain में दशकों तक जी चुके लोग ऐसी बातें जानते हैं जिनकी आप कभी कल्पना भी नहीं करेंगे

  • इस लेख में जिस software generalist का वर्णन है, उसके पास भी domain expertise है। उसका domain है software
    अगर आप आज एक बेहतरीन generalist software engineer हैं, तो AI से बचने के लिए किसी भी random domain में नहीं कूदेंगे। software ही आपका domain है, और जब वह domain फैलता और बदलता रहेगा, तब भी आप उसी के भीतर रहेंगे

    • हाँ। और अब AI नाम की नई superpower भी है, जिससे आप लगभग किसी भी domain में गहराई तक जा सकते हैं और तेज़ी से expertise बढ़ा सकते हैं। मुझे तो लगता है कि लेख की दिशा उलटी है

  • शायद अच्छी खबर यह है कि पश्चिम का सबसे बेहतरीन spreadsheet artisan accountant भी validation करने के लिए आखिरकार कुछ न कुछ programming experience की ज़रूरत रखेगा
    आप LLM से पूछ सकते हैं, “यह code क्या करता है, और क्या Y होने पर हमेशा X होगा?”, लेकिन वह सिर्फ validation problem को एक दूसरी validation problem के भीतर रख देना है

  • असली बात शुरू से code नहीं थी
    पिछले 5 साल से venture capital और private equity के लिए software बनाते हुए यह लेख मुझे बहुत गहराई से महसूस हुआ। code लिखना मेरे काम का अब तक का सबसे आसान हिस्सा है, और मुश्किल हिस्सा है financial engineering और सूक्ष्म context को समझना, ताकि पता चले कि हमारी client companies को वास्तव में क्या चाहिए
    हम मज़ाक में कहते थे कि अगर संभव हो, तो हम किसी senior fund accountant को hire करके उसे programming सिखाना चाहेंगे। समस्या यह है कि ऐसे लोग लगभग होते ही नहीं। और engineers को fund accounting की बारीकियाँ इस स्तर तक समझाना भी मुश्किल है कि वे उसे software में ढाल सकें

    • अगर आपके पास सिर्फ domain expertise है और technical skill नहीं, तो एक बिंदु के बाद नतीजा ज़्यादा से ज़्यादा भारी technical debt ही होगा
      सच कहूँ तो मेरे करियर का लगभग आधा हिस्सा ऐसी चीज़ों को संभालने में गया है जिनमें “ticket या epic बंद करने भर की domain knowledge तो थी, लेकिन अंत में बहुत सारा technical debt छोड़ गईं”
      उदाहरण के लिए, domain knowledge होने पर भी लोग गलती करते हैं, बेहतर तरीका नहीं जानते, feedback को शामिल नहीं करते, या उससे भी बुरा, coding agent ने जो लिखा उसे दोबारा जाँचते ही नहीं; इसलिए PR को बहुत बारीकी से review करना पड़ता था
      कई बार “तकनीकी रूप से सही, लेकिन इतना खराब लिखा गया कि timeout हो जाए या manager/DBA चिल्लाने लगे” जैसी चीज़ों को refactor करना पड़ता था
      एक सचमुच अच्छा software engineer domain को सीखने की क्षमता और इच्छा रखता है, लेकिन उसे सीखने का रास्ता होना चाहिए। कुछ कंपनियों, टीमों और सहकर्मियों ने यह संभव बनाया, जबकि कुछ जगहों पर लोग सिर्फ मुँह से इसकी अहमियत बताते थे, और आखिर में आपको सिर्फ JIRA, meetings, और non-IT विभागों के लोगों की इधर-उधर कही बातों से ही अंदाज़ा लगाना पड़ता था
      मुझे लगता है कि पिछले 5 साल का बड़ा paradigm shift यह है कि ज़्यादातर कंपनियाँ लोगों से उनकी सीमा तक काम कराने की उम्मीद करती हैं, और इसी कारण उन महत्वपूर्ण बातचीतों के लिए जगह ही नहीं छोड़तीं जिनकी वास्तव में ज़रूरत होती है
      culture यहाँ बड़ा factor है। कुछ जगहें ऐसी थीं जहाँ पास बैठकर छोटी-सी बातचीत कर सकते थे या आसानी से meeting तय हो जाती थी, और कुछ ऐसी जहाँ ठीक से चर्चा के लिए समय माँगना ऐसा लगता था मानो change.org पर petition ही डालनी पड़े
      फिर भी मूल बात सही है। आखिरकार requirements code से ज़्यादा महत्वपूर्ण हैं। ऐसी जगहें भी थीं जहाँ सारी requirements पूरी हो चुकी थीं और team design decisions को approve भी कर चुकी थी, फिर भी implementation के दौरान ग़ायब रहा कोई व्यक्ति लौटकर सिर्फ इसलिए feature को delay कर देता था कि उसे लिखने का तरीका पसंद नहीं आया
      फिर एक दिन पता चलता है कि “batch process” %numberOfRecord%*10 insert कर रही है, खराब design किए गए data model की वजह से अतिरिक्त lookups भी कर रही है, और SQL upsert सबसे गलत तरीके से कर रही है। यानी पहले DB से fetch करो, फिर अगर न मिले तो insert के लिए record जोड़ो। और उसके बाद data layer के query patterns पर दोबारा सोचने के बजाय “performance improvement” के नाम पर और भी संदिग्ध काम करते रहो। अपने करियर में मैंने यह एक से ज़्यादा बार देखा है

  • जब भी मैं AI से निपटने की सलाह जैसा कोई बहुत सामान्य लेख पढ़ता हूँ, मुझे याद आता है कि software industry construction industry जैसी है
    यह कभी पूरी तरह व्यवस्थित नहीं होती, पूरी तरह optimized भी नहीं होती, और हमेशा किसी न किसी रूप में custom बनी रहती है। क्योंकि इसे ऐसे वास्तविक संसार के हिसाब से ढलना पड़ता है जहाँ पसंद, context और स्थानीयता बेहद अलग-अलग होते हैं
    हाँ, कभी-कभी बेहतर tools या raw materials आ सकते हैं

  • मैं समझता हूँ कि software की असली moat इस बात में नहीं रही कि वह system और domain दोनों के बारे में व्यापक knowledge या experience को प्रभावी रूप से अनिवार्य बनाती है
    taste और network effects की नकल करना कहीं ज़्यादा कठिन है। वास्तव में vibe coding से पहले भी, talent और resources से भरपूर venture-backed startups का बाज़ार में टिक जाना कम ही होता था
    इसलिए 20s में लोग भी कई क्षेत्रों के experts से प्रतिस्पर्धा कर पाते थे। मुझे लगता है कि अभी जो backlash दिख रहा है, वह उन “industry में X साल का अनुभव” वाले लोगों के उभरने जैसा है, जो दूसरे mature industries में आम बात है

  • मैं analyst के रूप में काम करता हूँ, और हमारे group में लगभग 20% analyst ऐसे हैं जिनकी technical capability मज़बूत है, यानी software engineering skills हैं; बाकी पारंपरिक analyst या domain experts हैं
    पिछले 1 साल में मैंने non-technical analysts को development हिस्से में AI models का उपयोग करते हुए internal tools development की productivity बढ़ाते देखा है
    पहले लगभग सब कुछ Tableau में develop होता था। जो लोग developers नहीं थे, उनके लिए काम करने वाला tool बनाने का वह सबसे सुलभ तरीका था
    कुछ दिन पहले भी हमारे group के एक analyst ने अपने बनाए जा रहे tool को प्रस्तुत किया, जो मूल रूप से एक Tableau report को एक अधिक flexible app में port करने जैसा था

    • हमारा group धीरे-धीरे Tableau को अपने बनाए tools से replace कर रहा है, और performance improvement जबरदस्त है
      लगता है ऐसी BI कंपनियाँ बड़ी मुश्किल में पड़ेंगी। खासकर Tableau जैसी कंपनियाँ, जो histogram जैसी सरल चीज़ बनाना भी लगभग असंभव कर देती हैं, उनके लिए तो और भी ज़्यादा

  • मेरा एक दोस्त electrical engineer है और उसने हाल ही में FIDE chess rating 2000 पार की है। वह 30 साल से chess खेल रहा है, और उसने हाई स्कूल में chess club भी बनाया था। कॉलेज में microcontroller के साथ काम करते हुए उसने बस थोड़ी-बहुत programming सीखी थी
    मैं computer science degree वाला, infrastructure/management तरह का generalist हूँ, और 30 साल से शौकिया तौर पर programming करता आया हूँ। मेरा Lichess rating अच्छे दिन में भी 1000 होता है
    हमने chess bot competition किया था। वह open-book था, AI से programming करना भी allowed था, और opening book या endgame table जैसी कोई भी चीज़ इस्तेमाल करने की पूरी छूट थी। मैंने उसे पूरी तरह पछाड़ दिया, लेकिन असली board chess में मैं उसे 20 साल में सिर्फ दो बार ही हरा पाया हूँ
    वह वास्तविक दुनिया में random players के 99% को हरा देगा, और मैं शायद सिर्फ 20% को ही हरा पाऊँगा
    मैं ठीक-ठीक क्या कहना चाह रहा हूँ, यह पक्का नहीं है, लेकिन अब ऐसा लगता है कि domain knowledge शायद सब कुछ नहीं रह गया है। या फिर यह भी हो सकता है कि domain ही बदल गया हो

    • AI के नज़रिए से शायद यह कहना एक संतुलित समझ होगी कि कुछ domain shallow होते हैं, जैसे chess, और कुछ domain deep होते हैं
    • मुझे नहीं पता कि वास्तव में chess खेलने की क्षमता, कुछ सरल सिद्धांतों से आगे बढ़कर, efficient game tree search algorithm लिखने से क्या संबंध रखती है
      तुमने उसे programming competition के लिए चुनौती दी थी, और तुम, जो कहीं ज़्यादा अनुभवी programmer हो, जीत गए। भले ही AI का इस्तेमाल किया जा सकता था, यहाँ तुम्हारी domain knowledge ही निर्णायक थी