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

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

सॉफ़्टवेयर का bottleneck implementation से validation की ओर खिसक रहा है

  • सॉफ़्टवेयर लिखने का कठिन हिस्सा code टाइप करना नहीं था, बल्कि पहले अपने दिमाग़ में domain model बनाना था
    • payroll system में garnishment, pre-tax deduction, और उस स्थिति की handling शामिल होती है जब pay period वेतन परिवर्तन के समय को overlap करे
    • transit app में GTFS feed, trip और route के बीच का अंतर, और वह कारण शामिल होता है कि “on-time” बस भी फिर भी गलत क्यों हो सकती है
    • code इस समझ का अनुवादित परिणाम था, और इस समझ को हासिल करना ही वास्तविक काम था
  • Agentic AI डोमेन समझ और सॉफ़्टवेयर उत्पादन के बीच के संबंध को कमज़ोर कर रहा है
    • अब domain model को सीधे बनाए बिना भी सॉफ़्टवेयर बनाया जा सकता है
    • इससे वह आधार हिल रहा है जिस पर पूरा सॉफ़्टवेयर पेशा निर्भर रहा है
  • पिछले साल के दृष्टिकोण की तरह यह कहना सही है कि ऐसे tools निर्णय-क्षमता वाले senior developers की क्षमता बढ़ाते हैं, लेकिन यह पर्याप्त नहीं है
    • अधिक ठोस बदलाव यह है कि bottleneck “क्या इसे बनाया जा सकता है?” से “क्या यह सही है, इसका निर्णय किया जा सकता है?” की ओर खिसक गया है

कौन लोग agentic tools का अच्छी तरह उपयोग करेंगे

  • डोमेन विशेषज्ञ code जाने बिना भी सही उत्तर पहचान सकते हैं

    • लॉजिस्टिक्स dispatcher, clinical coder, insurance actuary जैसे लोग शायद stack trace न पढ़ सकें और hash map तथा list का अंतर न समझा सकें
    • लेकिन agent द्वारा बनाए गए schedule को देखकर वे तुरंत जान सकते हैं कि कौन-सा driver क़ानूनी रूप से वह shift नहीं कर सकता
    • वे यह भी पहचान सकते हैं कि किसी विशेष code combination का insurance claim भुगतान नहीं पाएगा
    • उन्होंने input और output के बीच 10 साल बिताए हैं, इसलिए वे दिए गए input के लिए सही output जानते हैं
    • agent उन्हें वह code उत्पादन क्षमता देता है जो उनके पास नहीं थी, और वे agent को वह ground truth देते हैं जो उसके पास नहीं है

  • सामान्य-purpose engineers अच्छी तरह बनाए गए सॉफ़्टवेयर और सही सॉफ़्टवेयर में फर्क न कर पाएँ

    • एक मज़बूत सामान्य-purpose engineer architecture, reliability, testing और यह जानता है कि सिस्टम को रात 2 बजे ढहने से कैसे बचाया जाए
    • लेकिन clinical coding जैसे डोमेन में वह भरोसेमंद दिखने वाले लेकिन गलत उत्तर और सही उत्तर में फर्क न कर पाए
    • agent ऐसा code बना सकता है जो compile हो, engineer द्वारा सोचे गए tests पास करे, लेकिन subtle और महँगी billing rule errors पैदा करे
    • engineer यह verify कर सकता है कि सॉफ़्टवेयर अच्छी तरह बना है या नहीं, लेकिन जब correctness पूरी तरह उस डोमेन से परिभाषित होती है जो उसके दिमाग़ में मौजूद नहीं है, तब accuracy verify करना कठिन हो जाता है

  • agent से पहले engineers के लिए सीखने का एक अनुकूल रास्ता था

    • engineers experts के साथ काम करते हुए, specifications पढ़ते हुए, और production environment में गलतियाँ करते हुए धीरे-धीरे डोमेन सीख सकते थे
    • कई क्षेत्रों में यह प्रक्रिया career ladder का मुख्य हिस्सा थी
    • domain experts के लिए इसका कोई सममित रास्ता नहीं था
    • भरोसेमंद सॉफ़्टवेयर बनाना सीखने में वर्षों लगते हैं, और यह ऐसा रास्ता था जिस पर उनके लिए चलना वास्तव में कठिन था

  • agentic tools ने केवल एक तरफ़ का रास्ता तोड़ा है

    • engineers की बढ़त, यानी domain model को चलने वाले code में बदलने की क्षमता, सस्ती हो गई है
    • domain experts की बढ़त, यानी क्या सही है यह जानने की क्षमता, सस्ती नहीं हुई है
    • केवल prompt से यह क्षमता हासिल नहीं की जा सकती, और न ही ऐसा कोई skill file है जिसमें हज़ारों payroll runs को सही करने वाले व्यक्ति का tacit knowledge भरा हो

  • सबसे मूल्यवान व्यक्ति वह है जो दोनों स्तरों पर verify कर सके

    • जो यह जानता हो कि generated code technically sound है, और यह भी कि उस code का उत्तर सच है, वही सबसे महत्वपूर्ण हो रहा है
    • “driver 11 घंटे से अधिक काम नहीं कर सकता” जैसा test लिख पाने का कारण नियम को जानना है
    • और यह तय कर पाने का कारण कि वह test खुद अर्थपूर्ण है, यह जानना है कि वास्तव में क्या test किया जा रहा है
    • agent नकल-लेखन का काम करता है, और इंसान code तथा domain, दोनों स्तरों पर निर्णय करता है
    • अनुभवी engineers के लिए सबसे महत्वपूर्ण निवेश किसी वास्तविक डोमेन का गहरा और सत्यापित मॉडल हासिल करना है
    • किसी स्पष्ट विचार को साफ़-सुथरे code में बदलने की यांत्रिक क्षमता का मूल्य काफ़ी कम हो गया है
    • जो अब भी दुर्लभ है, वह है वास्तविक industries, tools, regulatory systems और physical processes की गहरी समझ
    • जैसे पहले programming language या framework सीखा जाता था, वैसे ही अब किसी एक डोमेन को चुनकर सीखना चाहिए
    • वह हिस्सा जिसे agent बदल नहीं सकता, और जिसकी आज सबसे अधिक क़ीमत बढ़ गई है, वही domain expertise है

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

1 टिप्पणियां

 
GN⁺ 4 시간 전
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 ही निर्णायक थी