मुझे लगता है कि टूल हमेशा सोच का विस्तार भी लाते हैं और साथ ही सोच को तोड़ते भी हैं। सोच के इस विघटन के ज़रिए हमें उच्च-स्तरीय सोच के विस्तार की ओर बढ़ पाना चाहिए, लेकिन जब ऐसी तैयारी नहीं होती, तब इस तरह की समस्याएँ हमेशा साथ आती दिखती हैं.

इसलिए, आखिरकार टूल के इस्तेमाल के साथ इस तरह की चिंताएँ हमेशा जुड़ी रहती हैं। मुझे लगता है कि ये एकदम ज़रूरी प्रक्रियाएँ हैं। बस इसे ठुकरा देना या अंधाधुंध इस्तेमाल करना सही नहीं है; बल्कि यह सोचना बेहतर है कि इस टूल का अच्छा उपयोग कैसे किया जाए, और ऐसे टूल की मदद से मूल रूप से अधिक महत्वपूर्ण हिस्सों पर resources कैसे लगाए जा सकते हैं। मेरा मानना है कि इसी फ़ोकस के साथ इसका इस्तेमाल करना उचित है.
(cursor का usage महीने में 1,000 बार से ऊपर जाते हुए...)

AWS से तो किसी न किसी तरह निकल जाएंगे, लेकिन pypi, crates.io, npm का कोई जवाब नज़र नहीं आता :(

श्री किम। मैं हिम्मत करके एक सलाह देना चाहता हूँ। और कुछ नहीं, बस Excel function? का बहुत ज़्यादा इस्तेमाल मत कीजिए। अगर सुविधा है, तो जोखिम भी बढ़ता है। गाय को काटने के लिए वैसी ही धार होती है, लेकिन मुर्गी काटने के लिए क्या सच में चाकू चाहिए? आसान तरीका ही सही जवाब हो सकता है।

कहने का अंदाज़ भले ही थोड़ा सख्त है, लेकिन बात पूरी तरह गलत भी नहीं है। जैसे कि अच्छे सवालों से अच्छे जवाब निकलते हैं, उसी तरह...

मैं अब फिर कभी chatGPT का इस्तेमाल नहीं करूँगा
मैंने भी इसी तरह की एक पोस्ट लिखी थी।

यह साफ़ है कि productivity बढ़ती है, लेकिन मेरा मानना है कि अपने दिमाग़ को पूरी तरह इसके हवाले कर देने जैसी आदत से बचना चाहिए।

मैं अब भी Cursor और Anthropic का बड़ा समर्थक हूँ, लेकिन किसी बिंदु पर मैंने देखा कि जिस agent mode को लेकर मैं बहुत उत्साहित था, उसे धीरे-धीरे कम इस्तेमाल कर रहा हूँ। अब मैं पहले ask mode में architecture और implementation method के बारे में पूछता हूँ, और जब पूरी तरह आश्वस्त हो जाता हूँ तभी AI के change suggestions को एक-एक करके स्वीकार करता हूँ।
ऐसा इसलिए बदला, क्योंकि बहुत बड़ा नहीं होने वाला एक मॉड्यूल — लेकिन हमारे काम के project में काफ़ी महत्वपूर्ण — को 2 engineers ने अपने-अपने agent mode का इस्तेमाल करके refactor किया और उसमें नई संरचना जोड़ी, और फिर एक समय ऐसा आया जब architecture को व्यवस्थित करने के इरादे से लिखा गया code वास्तव में readability और structure दोनों को और ज़्यादा खराब कर बैठा।

AI डेवलपर्स को बेवकूफ़ बना रहा है, ऐसा कहने से ज़्यादा…
बेवकूफ़ डेवलपर, AI इस्तेमाल करके भी बेवकूफ़ डेवलपर ही रहता है…
Garbage in Garbage out

नाम से Core 2 Duo सुनकर Intel याद आ जाता है।

समर्थन करता हूँ। LinkedIn पर जहाँ-जहाँ यह दिखता है, वहाँ-वहाँ मैं like दबा रहा हूँ।

सहमत हूँ. ^^

> Randy Komisar की The Monk and the Riddle

बाकी सब छोड़िए। मैं इस किताब की सिफारिश करता हूँ।

https://paint.js.org/

आजकल Paint बहुत ही मुश्किल लगने लगा है.. मुझे लगता है कि मेरे लिए पुराना Paint ही काफ़ी है

उदाहरण काफ़ी निराशाजनक है।
कमांड को echo करने के बजाय, एक echo कमांड बनानी चाहिए थी...

अब यह operating system है या platform~

मुझे लगता है कि लेखक अंधाधुंध सिर्फ़ AI टूल्स पर निर्भर होकर उनका इस्तेमाल करने की बात कर रहे थे।

मेरी व्यक्तिगत राय यह है कि अगर AI के उपयोग से काम की दक्षता बढ़ी है,
तो उसका सक्रिय रूप से इस्तेमाल करके दोहराए जाने वाले कामों को कम करना,
और इस तरह मिले समय को बड़े दायरे वाले क्षेत्रों में (जैसे: backend डेवलपर का frontend या app development तक विस्तार)
या architecture design जैसी अधिक विकासोन्मुख दिशा में लगाना बेहतर होगा।

पूरे लेख की बात देखें तो लगता है कि लेखक भी इस राय से सहमत होंगे,
लेकिन कभी-कभी ऐसे डेवलपर्स भी होते हैं जो AI को ही पूरी तरह नकार देते हैं, इसलिए कुछ पंक्तियाँ जवाब में लिख दीं.. हा हा
.

Google की Wiz अधिग्रहण डील रद्द, Wiz IPO की तैयारी में

लग रहा था कि यह नहीं होगा, लेकिन वे फिर से कोशिश कर रहे हैं।

Apple iPhone पर Pebble की सुविधाओं को सीमित कर रहा है

लगता है कि यह Apple की तुलना में Android के साथ ज़्यादा बेहतर मेल खाएगा।

लगता है Algumon ने कुछ कर दिखाया है। एक अच्छी साइट के बारे में पता चला।

मैं अभी SRE के तौर पर काम कर रहा हूँ, और सुबह जो काम प्लान करता हूँ उनमें से उसी दिन सच में कर पाता हूँ, ऐसे मामले उंगलियों पर गिनने लायक ही हैं, हाहा

Site Reliability Engineering, SRE