गहराई से सोचने वाले वे दिन याद आते हैं

• AI coding tools के आने से गहराई से सोचने का अनुभव तेजी से कम हो गया है, और एक engineer के रूप में विकास रुक-सा गया है ऐसा महसूस होता है
• मेरे भीतर के 'Builder' और 'Thinker' में से, Builder AI की वजह से संतुष्ट है लेकिन Thinker भूखा रह गया है
• "vibe coding" के ज़रिये ideas को जल्दी reality में बदला जा सकता है, लेकिन creative problem solving के अवसर काफी कम हो गए हैं
• जब AI 70% स्तर का "काफी ठीक-ठाक" solution दे देता है, तो अपनी pragmatic प्रवृत्ति के कारण उसे ठुकराना मुश्किल हो जाता है
• coding के बाहर गहरी सोच से मिलने वाली संतुष्टि खोजने की कोशिश की, लेकिन सफल नहीं हुआ, और क्या दोनों ज़रूरतें एक साथ पूरी हो सकती हैं इस पर अनिश्चितता बनी हुई है

---

सोच की कमी पर सवाल

• यह लेख पढ़ने से पहले "आख़िरी बार आपने गंभीरता से कब सोचा था" इस पर विचार करें
• यह लेख कोई समाधान या सलाह नहीं, बल्कि हाल में महसूस हुई घुटन को व्यक्त करने वाला एक लेख है

Builder और Thinker नाम की दो प्रवृत्तियाँ

• Builder: बनाने, launch करने, और practical नतीजे निकालने की प्रवृत्ति
  • speed और usefulness से प्रेरित
  • सफल deployment से मिलने वाला dopamine, असली समस्याएँ हल करने वाले systems बनाने की संतुष्टि, और यह जानकर खुशी कि कोई आपके tools का इस्तेमाल कर रहा है
• Thinker: गहरी और लंबे समय तक चलने वाली मानसिक जद्दोजहद चाहने वाली प्रवृत्ति
  • physics पढ़ते समय university के दिनों में, औसत कठिनाई से कहीं अधिक कठिन assignment problems मिलती थीं
  • concepts समझ लेने पर भी ऐसे problems होते थे जिनमें approach ही सूझना मुश्किल होता था

कठिन समस्याओं के सामने छात्रों के तीन प्रकार

• प्रकार 1 (बहुसंख्यक): कुछ बार कोशिश करके हार मान लेना और professor या TA से मदद माँगना
• प्रकार 2 (researcher-प्रकार): library में मिलती-जुलती समस्याएँ या hints खोजकर problem को हल करने योग्य बनाना, और आम तौर पर समाधान तक पहुँच जाना
• प्रकार 3 (Thinker-प्रकार): केवल सोचने के ज़रिये problem के पास जाना
  • कई दिनों या हफ्तों तक लगभग पूरा non-I/O brain time समस्या के संभावित समाधान पर लगाना
  • नींद में भी सोच जारी रहना
  • यह तरीका कभी विफल नहीं हुआ, और गहरी, लंबे समय तक टिकने वाली सोच को अपनी ताकत के रूप में पहचानना
  • top 1% जैसी तेज़ी या जन्मजात प्रतिभा नहीं, लेकिन पर्याप्त समय मिले तो किसी भी समस्या को हल कर सकता हूँ—ऐसा विश्वास रखना

AI के साथ टकराव

• software engineering शुरू में इतना संतोषजनक इसलिए था क्योंकि उसमें यही दोहरी संतुष्टि मिलती थी
• Builder (कुछ उपयोगी बनाकर productive और practical महसूस करना) और Thinker (वाकई कठिन समस्याएँ हल करना), दोनों संतुष्ट होते थे
• engineer के रूप में जिन projects में सबसे ज़्यादा विकास हुआ, उनमें हमेशा creative solutions की माँग करने वाली कठिन समस्याएँ बड़ी संख्या में थीं
• लेकिन हाल में कई घंटों से ज़्यादा एक ही समस्या पर टिककर गंभीरता से सोचने के मौके बहुत कम हो गए हैं

• मुझे लगता है कि इस पूरी स्थिति की वजह AI ही है

• पहले से ज़्यादा, और पहले से अधिक complex software लिख रहा हूँ, फिर भी engineer के रूप में बिल्कुल बढ़ नहीं रहा—ऐसा महसूस होता है
• इस "ठहराव" की वजह खोजते-खोजते समझ आया कि मैं Thinker को भूखा रख रहा हूँ
• "vibe coding" निश्चित रूप से Builder को संतुष्ट करता है
  • ideas का बहुत कम समय में सीधे reality में बदल जाना तुरंत सुख देता है
  • दूसरी ओर technical problems के लिए खुद creative solutions सोचने के क्षण बहुत कम हो जाते हैं
• जो लोग पूरी तरह Builder-प्रकृति के हैं, उनके लिए यह माहौल सबसे अच्छा दौर है
• लेकिन मेरे लिए साफ़ तौर पर कुछ कमी है

practical सोच का जाल

• मुझे अंदेशा है कि कोई यह तर्क देगा: "अगर vibe coding से समस्या हल हो जाती है, तो वह मूल रूप से कठिन समस्या थी ही नहीं"
  • लेकिन यह तर्क मूल बात से भटक जाता है
• AI न तो कठिन समस्याओं में खास तौर पर असाधारण है, और न ही आसान समस्याओं में हमेशा अच्छा समाधान देता है
  • अगर मैं उसी module को तीसरी बार खुद फिर से लिखूँ, तो मुझे यक़ीन है कि नतीजा AI के किसी भी output से बेहतर होगा
• लेकिन साथ ही, मैं pragmatist भी हूँ
• अगर समय और मेहनत के बहुत छोटे हिस्से में "काफ़ी क़रीब" समाधान मिल सकता है, तो AI को न चुनना ही उल्टा अव्यावहारिक लगता है
  • असली समस्या यह है कि इस practical प्रवृत्ति को मैं जानबूझकर बंद नहीं कर सकता (अनदेखा नहीं कर सकता)
• मूल रूप से मैं Builder हूँ, और चीज़ें बनाना मुझे अपने-आप में पसंद है। अगर उन्हें तेज़ी से बना सकूँ, तो वही हमेशा बेहतर लगता है
• चाहे मैं AI को ठुकराकर उस दौर में लौटना चाहूँ जब Thinker की ज़रूरत coding के ज़रिये स्वाभाविक रूप से पूरी हो जाती थी, Builder के लिए उस अक्षमता को सहना मुश्किल है
• AI लगभग निश्चित रूप से 100% संतोषजनक समाधान नहीं देता, लेकिन जो 70% स्तर का समाधान वह देता है, वह अक्सर "काफ़ी अच्छा" होने की शर्त पूरी कर देता है

आगे क्या किया जाए?

• सच कहूँ तो अभी तक जवाब नहीं मिला है, और मैं इस पर लगातार सोच रहा हूँ
• मुझे यक़ीन नहीं कि coding के इसी एक क्षेत्र में ये दोनों प्रवृत्तियाँ अब भी एक साथ संतुष्ट हो सकती हैं
• एक विकल्प यह है कि जानबूझकर ऐसे problems खोजे जाएँ जिनमें AI पूरी तरह विफल हो जाए, और उनसे भी कठिन projects को लक्ष्य बनाया जाए
• कभी-कभी ऐसे problems मिलते हैं, लेकिन ऐसा लगता है कि गहरे creative solutions माँगने वाली समस्याएँ तेज़ी से कम हो रही हैं
• coding के बाहर मानसिक विकास का एहसास वापस पाने की कोशिश भी कर रहा हूँ
  • physics से फिर जुड़ने के लिए पुराने textbooks खोलकर देखता हूँ
  • लेकिन उससे ठोस संतुष्टि नहीं मिली
  • जब कुछ बनाया जा सकता हो, तब ऐसे physics problems पर समय और मानसिक ऊर्जा खर्च करना जो न सीधे वर्तमान से जुड़े हों और न ही नए हों, उसे खुद के सामने जायज़ ठहराना मुश्किल है
• Builder-प्रकृति बस बैठकर अनसुलझी समस्याओं से जूझते हुए सोचते रहने की हालत को स्वीकार नहीं करती
• Thinker-प्रकृति, vibe coding जारी रहने तक, लगातार भूखी ही रहती है
• क्या दोनों इच्छाएँ फिर कभी एक साथ संतुष्ट होंगी, इस पर मुझे भरोसा नहीं

"अब हमें इस सत्ता को वह परिचित नाम देने का अधिकार मिल गया है, जिसकी ओर न कल्पना की कोई शक्ति, न सबसे साहसी फैंटेसी की छलांग, न सबसे गहरी धार्मिक आस्था, न कितनी ही गंभीर अमूर्त सोच, और न ही उन्मत्त चेतना कभी पहुँच सकी थी। God. लेकिन यह मूलभूत एकता अतीत की चीज़ है; अब वह मौजूद नहीं है। उसने अपने अस्तित्व को बदलने की प्रक्रिया में स्वयं को पूरी तरह, अंत तक, टुकड़े-टुकड़े कर दिया। God मर चुका है, और उसकी मृत्यु ही संसार का जीवन थी।"
— Philipp Mainländer

[winmain]

1, 2 नंबर वाले प्रकार तो बहुत पहले ही खत्म हो चुके हैं,
वे योग्यता-रहित programmer हैं,
और बस पेशेगत चेतना भर के सहारे टिके रहने वाले लोगों को ही
इससे संकट महसूस हो रहा है... वे तो शुरू से ही सोचने जैसी चीज़ को
झंझट समझने वाले लोग हैं..

लेकिन 3 नंबर वाले प्रकार के लिए यह स्वागतयोग्य तोहफ़ा है।
3 नंबर वाले तो इसका उपयोग पहले से ही अच्छी तरह कर रहे हैं, है न?

नया tool आए तो उत्साह से उसे अच्छी तरह इस्तेमाल नहीं करते क्या?

मैंने शुरुआत में win32 code पर प्रयोग किया था।
लेकिन जैसा सोचा था... वह बस Automation Interface स्तर
का ही था।
मैंने तभी सोचा था कि ऐसी चीज़ से उच्च-गुणवत्ता वाला software design करना तो पहले से ही नामुमकिन है।
फिर मैंने सोचा कि इसका अधिकतम उपयोग कैसे किया जा सकता है।
लेकिन इस स्तर पर भी इस्तेमाल की बहुत-सी जगहें हैं।

यह भी आखिर सोचने-समझने पर हाथ-पैर बढ़ा देने वाली चीज़ है... समस्या यह है कि लोग ऐसा सोचने की कोशिश तक नहीं करते।

[goodnvin]

बस भ्रम पाल रहे हैं। जो चीज़ें जल्दी experiment करके देखी जा सकती हैं, उन्हें करते हुए data जमा करना फ़ायदेमंद है, लेकिन "आह~ मुझे नहीं पता, मैं तो theory वाला हूँ~" कहना उससे अलग क्या है, lol
अब तो बस ऐसा लग रहा है कि वे इस बात पर विलाप कर रहे हैं कि उनकी वह theory, जिसे अब तक हक़ीक़त में उतारा नहीं जा सका था इसलिए साबित भी नहीं किया जा सका, दरअसल बिल्कुल बेकार साबित हो गई है
अगर वे सच में thinker होते, तो इस स्थिति में AI के ज़रिए यह खोज रहे होते कि कौन-सी समस्या हल की जा सकती है, और उससे भी बेहतर समाधान खोजने के लिए "अब भी" सोच रहे होते

[hpark]

मुझे नहीं लगता कि यह सम्मानजनक रवैये वाला कमेंट है।

[savvykang]

काम के 5 दिनों में से एक दिन मैं काम के घंटों के दौरान ही LLM इस्तेमाल नहीं करता, और रविवार को तो बिल्कुल भी LLM इस्तेमाल नहीं करता, फिर भी यह ठीक से हो जाता है।

[ahwjdekf]

क्या AI द्वारा बनाए गए कोड को बेहतर बनाने के लिए अतिरिक्त build और thinking को साथ-साथ चलाया जा सकता है?

[aeolian21]

Enterprise-grade विशाल systems में उपयुक्त processing model चुनने और pipeline approach तय करने की प्रक्रिया में अभी भी AI completeness के मामले में कुछ कमी दिखाता है, इसलिए architecture की तरफ नज़र मोड़ना बेहतर लगता है।
बेशक, वह भी कब तक चलेगा कौन जाने...

मुश्किल algorithm problems हल करके अपनी इच्छा पूरी कर लें और business को practical तरीके से approach करें, वरना कोई और तरीका नहीं है।

[pencil6962]

जैसे मशीनों के कपड़े बुनने के दौर में भी बुनाई मौजूद है, वैसे ही लगता है कि कोडिंग भी एक शौक के रूप में की जा सकती है।

[pluto]

मेरे बहुत ही व्यक्तिगत विचार से
शायद builder और thinker होने की खुशी को cherry-pick किया जा सकता है।

अब बहुत कम लागत (कम समय) में कुछ ऐसा बनाया जा सकता है जो काम करे,
और इस बात से मिलने वाली खुशी भी मिल सकती है कि लोग उसे इस्तेमाल कर रहे हैं, कि उसने असल ज़िंदगी की समस्या हल की है।

अगर बचाए गए समय को गहराई से सोचने वाले सवालों पर उंडेल दिया जाए (और मैं वास्तव में ऐसा कर भी रहा हूँ),
तो उसका भी अपना अर्थ है, और उसमें भी शायद आनंद है।

[GN⁺]

Hacker News की राय

• मार्च 2025 में Aral Balkan की पोस्ट प्रभावशाली लगी
  कोडिंग मिट्टी के ढेले को तराशकर मनचाहा आकार देने जैसी है। इस प्रक्रिया में सामग्री की सीमाएँ और गुण समझ में आते हैं।
  कुछ बनाने से पहले, यही वह समय होता है जब हमें सबसे कम पता होता है कि हम क्या बनाना चाहते हैं। डिज़ाइन सिर्फ समस्या हल करना नहीं, बल्कि सही समस्या को खोज निकालना भी है।
  अगर रचनात्मक प्रक्रिया को छोड़ दिया जाए, तो सीखने और खोज के मानवीय तत्व खो जाते हैं। जिसे हम खुद तराशते हैं, उसे भीतर तक समझते हैं, लेकिन वेंडिंग मशीन से मिला नतीजा बस आकार में मिलता-जुलता नकली संस्करण होता है

  • एजेंट-आधारित टूल्स के साथ प्रोग्रामिंग करते समय लगातार ज़ोर लगाना पड़ता है ताकि आइडिया औसत रूप में ढलकर कमजोर न हो जाए
    जितना नया आइडिया होगा, उतना ही टूल उसे ‘सामान्य’ बनाने की कोशिश करेगा, इसलिए उस प्रतिरोध को पार करने की मेहनत करनी पड़ती है।
    इसी प्रक्रिया में हम साफ़-साफ़ परिभाषित करते हैं कि हमारा आइडिया क्या है और क्या नहीं। जैसे ही यह ज़ोर लगाना बंद होता है, LLM प्रोजेक्ट की मौलिकता को ढक देता है
  • मुझे लगता है कि यह सब abstraction की एक निरंतर श्रृंखला है। OS, compiler या standard library खुद न बनाना भी ठीक है।
    पहले से बने टूल्स को जोड़कर कुछ नया बनाना ही मेरा काम है।
    रचनात्मक प्रक्रिया को छोड़ देने से किसी कृति का मूल्य कम नहीं हो जाता।
    उदाहरण के लिए, Zelda अगर Havok physics engine इस्तेमाल करता है, या Unreal में बना गेम है, तो इससे वह कम शानदार नहीं हो जाता
  • 30 साल में 10 कंपनियों में काम करते हुए, कंपनियों ने मुझसे ‘कोड लिखने’ की नहीं बल्कि business value पैदा करने की उम्मीद की
    पिछले 3 हफ्तों में Codex, Claude और टेस्ट सेशन्स के साथ जो बनाया, उस पर मुझे गर्व है।
    पहले लक्ष्य आइडिया को वास्तविकता में बदलना था, अब लक्ष्य ग्राहक संतुष्टि और समय-सीमा व बजट का पालन है
  • एक स्तर ऊपर भी जाया जा सकता है। खुद मिट्टी गूंथने के बजाय, हर हिस्से को specify करके मशीन से बनवाया जा सकता है
    इससे हज़ारों हिस्सों वाले जटिल सिस्टम बनाए जा सकते हैं।
    पहले यह भूमिका कंपनी का संगठन निभाता था — ऊपर के लोग specification देते थे, नीचे के लोग हिस्से बनाते थे
  • जैसे Michelangelo ने कहा था कि उसने “David नहीं होने वाले हिस्सों को हटा दिया”, वैसे ही काम माध्यम से प्रभावित होता है
    पहले Ruby on Rails से बनी साइट को तुरंत पहचाना जा सकता था।
    अगर माध्यम की प्रकृति समझे बिना किसी इंसान या एजेंट को काम सौंपा जाए, तो साफ़-सुथरे कोड और ऐसे कोड जिसे maintain करना असंभव हो के बीच फर्क पैदा होता है
    आखिरकार ज़िम्मेदारी निर्देश देने वाले की होती है। अगर माध्यम का अनुभव नहीं है, तो आप परिणाम का मूल्यांकन करने के लिए तैयार नहीं हैं

• मेरे लिए बस टाइपिंग कम हुई है, सोच अब भी वही है
  टूल बेहतर हुए हैं, लेकिन प्रोग्रामिंग अब भी प्रोग्रामिंग ही है।
  चाहे ऊँट पर बैठकर रेगिस्तान पार करो या हेलिकॉप्टर से, आखिर यात्रा तो यात्रा ही है।
  टूल्स के आगे बढ़ने से उसका सार नहीं बदला

  • इस पोस्ट के कमेंट्स देखकर हैरानी हुई कि लोग एक-दूसरे के अनुभव को समझने की कोशिश तक नहीं कर रहे
    मानो वे भूल गए हों कि अलग-अलग अनुभव साथ-साथ मौजूद हो सकते हैं।
    “मैं सोचना नहीं चाहता” वाला कमेंट खास तौर पर याद रहा
  • हेलिकॉप्टर से रेगिस्तान के ऊपर उड़ना गलत नहीं है, लेकिन यह खुद पैदल चलने वाले जैसा अनुभव नहीं है
    abstraction के अगले स्तर पर जाना ठीक है, लेकिन इस प्रक्रिया में जो मूल्य खोता है, उसे भी स्वीकार करना चाहिए
  • लेखक की बात समझ आती है। हम उस समय को याद करते हैं जब हम बारीकियों पर सोचते थे
    LLM सिर्फ टूल्स का विकास है, लेकिन सूक्ष्म सोच की प्रक्रिया का गायब होना खलता है
  • लेकिन LLM coding सिर्फ abstraction नहीं है।
    बल्कि यह किसी दूसरे से काम करवाकर उसकी समीक्षा करने जैसा अधिक है।
    जिन्हें प्रोग्रामिंग पसंद नहीं थी, वे इसका स्वागत करेंगे, लेकिन इसे ‘प्रोग्रामिंग’ कहना ठीक नहीं होगा
  • एजेंट coding के बाद मानसिक मॉडल के कमजोर पड़ने का एहसास होता है
    जब मैं खुद कोड लिखता हूँ, तो data structure दिमाग में आकार लेता है, लेकिन एजेंट के करने पर वह संवेदना गायब हो जाती है।
    समझे बिना कोड commit करने का मेरे लिए कोई मूल्य नहीं है

• LLM-आधारित coding को मौजूदा abstraction के बराबर मानना गलत उपमा है
  compiler या framework का लक्ष्य leakage-free abstraction होता है, लेकिन LLM में मूल रूप से leakage है
  आखिरकार bug ढूंढना और ठीक करना अभी भी इंसान का काम है।
  LLM हमारे सामने फिर से वही अनिश्चितता और जोखिम ले आया है, जिनसे हम बचना चाहते थे

  • LLM coding आखिरकार prompt को code में decompress करने की प्रक्रिया है
    अगर prompt में हर variable साफ़ न बताया जाए, तो औसत दर्जे का परिणाम मिलता है।
    इस पर सवाल है कि क्या natural language ऐसी जानकारी ढोने के लिए उपयुक्त है
  • आज का LLM अनाड़ी intern जैसा है। लेकिन अगर मानव विशेषज्ञ leakage-free code बना सकते हैं, तो शायद LLM भी कभी ऐसा कर सके
  • LLM non-deterministic है, इसलिए input नहीं बल्कि output result को version control करना चाहिए
    यह abstraction नहीं, बल्कि non-deterministic code generation है
  • अगर C compiler कभी-कभी काम न करे, तो शायद हम बस build बटन दबाते ही रहेंगे
    इस अर्थ में LLM इंसानी सोच पर भी अलग तरह से असर डालता है
  • लगता है बहुत से developers ‘abstraction’ का अर्थ ठीक से नहीं समझते

• मैं एक ‘thinker’ हूँ, इसलिए AI coding में मेरी खास दिलचस्पी नहीं है
  OS kernel या graphics engine खुद बनाना मुझे आनंद देता है।
  नतीजे से ज़्यादा समस्या हल करने की प्रक्रिया ही मेरा शौक और संतोष है
  इसके विपरीत, ‘builder’ लोग AI से चीजें तेज़ी से बना पाने के कारण उत्साहित हैं

  • लेकिन ‘builder = जो नहीं सोचता’ जैसा विभाजन गलत है
    हर engineer सोचने वाला होता है। फर्क सिर्फ टूल के उद्देश्य का है

• दशकों से coding करने वाले व्यक्ति के नज़रिए से, AI tools आज़ादी देते हैं
  अब ऐसे आइडियाज़ पर भी तेज़ी से प्रयोग किया जा सकता है, जिन्हें पहले आज़माना भी मुश्किल था।
  इसकी वजह से समय के छोटे-छोटे टुकड़ों का इस्तेमाल करके personal projects पर काम किया जा सकता है

  • मोबाइल फ़ोन पर project चलाना दिलचस्प लगा। यह कैसे करते हैं, जानना चाहूँगा
  • परिवार के साथ जीवन में छोटे पलों को प्रगति में बदल देने की क्षमता बहुत बड़ी बात है
  • मैं भी इस राय से सहमत हूँ। ज़्यादातर प्रोग्रामिंग boilerplate की बर्बादी थी
    AI की वजह से अब असली सोच पर ध्यान देना संभव हुआ है।
    अब तो लगता है कि singularity करीब आ रही है
  • एक ही दोपहर में कई approaches आज़माए जा सकते हैं।
    असफलता भी सीख है, और सफलता मिले तो फिर quality validation पर ध्यान दिया जा सकता है

• “सोचने” के भी कई रूप होते हैं
  एक है गहरी एकाग्रता में डूबी सोच, और दूसरा है पृष्ठभूमि में धीरे-धीरे पकने वाली सोच।
  दोनों ही गहरे immersion के रूप हैं, और AI युग में इन्हें खो देना बहुत आसान है

  • मेरे लिए भी ‘hard thinking’ के कई प्रकार हैं
    गणितीय problem solving, दार्शनिक चिंतन, व्यावहारिक काम की जटिल constraints — ये सब अलग-अलग तरह का बौद्धिक तनाव देते हैं
    अंततः महत्वपूर्ण यह है कि किसी भी रूप में गहराई से डूबकर सोचने का अनुभव बना रहे

• मेरे आसपास के senior engineers को देखकर लगता है कि वे दो समूहों में बँटे हैं
  कुछ लोगों को थोड़ी productivity बढ़त मिली है, लेकिन कुछ में सोच की गहराई कम हुई है
  वे अक्सर LLM द्वारा दिए गए जवाबों को ज्यों-का-त्यों copy-paste कर देते हैं।
  असली समस्या है सही सवाल पूछने की क्षमता का अभाव

  • implementation से भी बड़ा मुद्दा communication overhead है।
    सिस्टम जितना mature होता है, यह अनुपात उतना ही 90% से ऊपर चला जाता है

• यह देखकर खेद होता है कि साथी engineers AI पर मोहित होकर अपने पेशे की मूल प्रकृति बेच रहे हैं
  हमारे पास उत्पादन के साधन थे, लेकिन हमने उन्हें खुद ही छोड़ दिया

  • अल्पकाल में बेरोज़गारी हो सकती है, लेकिन software की मांग असीमित है
    AI की वजह से development सस्ता और तेज़ हो जाए तो बाज़ार उल्टा और बड़ा होगा
  • AI पर भरोसा रखते हुए उसका विरोध करना विरोधाभासी है।
    तकनीकी प्रगति हमेशा कुछ पेशों को नुकसान पहुँचाती है, लेकिन समाज की कुल प्रगति भी लाती है
    जैसे पहले हमने automation के ज़रिए दूसरे उद्योगों की नौकरियाँ कम की थीं, अब बस वही बारी हमारी आई है
  • समस्या वे व्यवहारवादी लोग हैं जो मूल्य के बिना सिर्फ दक्षता का पीछा करते हैं
    उसका परिणाम सिर्फ खालीपन है। लेकिन शायद उनके लिए वही उद्देश्य भी था
  • यह तबका कुछ वैसा लगता है जैसे छोटा बुर्जुआ बड़े बुर्जुआ में समा रहा हो
  • यह नैतिकता और दर्शन से खाली तकनीकीवाद का परिणाम है
    “कर सकते हैं, इसलिए करते हैं” वाली सोच इंसानियत को कमज़ोर करती है

• AI सोच को खत्म नहीं कर रहा। समस्या है साधारण कंपनियाँ और साधारण सोच
  जहाँ असली सोच की कद्र हो, ऐसी कंपनी खोजनी चाहिए

• मैं भी LLM के साथ coding करता हूँ, लेकिन अब भी गहराई से सोचता हूँ
  design, risk, constraints, technical debt और alternatives पर विचार करता हूँ

  • लेकिन LLM के साथ की सोच एक अलग तरह की सोच है
    यह कई contexts के बीच आना-जाना और उन्हें संभालना वाली ‘management-type thinking’ के करीब है,
    न कि कई दिनों तक एक समस्या में डूबे रहने वाली वैज्ञानिक सोच के
  • मेरा अनुभव भी ऐसा ही है। LLM की वजह से coding आसान हुई है, लेकिन verification और review कहीं ज़्यादा कठिन हो गए हैं
    खासकर AI इस्तेमाल करने वाले juniors के PR अब लंबे और अधिक जटिल हो गए हैं,
    और अब मेरे काम का अधिकांश हिस्सा review-केंद्रित हो गया है
  • LLM का सबसे प्रभावी उपयोग छोटी-छोटी दोहराव वाली इकाइयों में है
    तेज़ prototyping, helper functions, code autocomplete और library exploration जैसी चीज़ों में यह उपयोगी है
  • Claude Code से 100% code generate करने पर भी गहरी सोच का अनुपात ऊँचा रहता है
    बल्कि साधारण काम कम होने से ज़्यादा सोचने का मौका मिलता है
  • लेकिन LLM के बाद की सोच में code खुद जो feedback loop देता था, वह गायब हो जाता है
    पहले code लिखना ऊपरी स्तर की design thinking को फिर से देखने पर मजबूर करता था,
    अब वह प्रक्रिया कम हो गई है, इसलिए हम ‘कम गहराई’ से सोचते हैं