AI का इस्तेमाल करके बेहतर कोड और भी धीरे लिखना
(nolanlawson.com)- AI coding का इस्तेमाल सिर्फ कम-गुणवत्ता वाला कोड तेज़ी से बड़े पैमाने पर बनाने के लिए ही नहीं, बल्कि PR की गहराई से समीक्षा करके उच्च-गुणवत्ता वाला कोड धीरे-धीरे बनाने के लिए भी किया जा सकता है
- LLM agents codebase में bug detection में मजबूत होते हैं, लेकिन असली कठिनाई मिली हुई चीज़ों की प्राथमिकता तय करने और उनकी पुष्टि करने में होती है
- कई models को साथ इस्तेमाल करने वाली Claude skill, Claude sub-agent, Codex, और Cursor Bugbot से PR की समीक्षा कराती है और false positives कम करके अंतिम रिपोर्ट बनाती है
- प्रक्रिया का flow critical/high समस्याओं को बार-बार ठीक करने, लागत के मुकाबले लाभ कम होने वाले items को छोड़ने, और बहुत ज़्यादा गंभीर समस्याएँ होने पर PR को छोड़ देने पर आधारित है
- यह तरीका गति से ज़्यादा codebase health को महत्व देता है और failure modes तथा मौजूदा bugs को समझने वाली सावधान programming को मजबूत करता है
AI coding को धीमे तरीके से इस्तेमाल करना
- AI coding को सिर्फ कम-गुणवत्ता वाला कोड तेज़ी से बड़े पैमाने पर बनाने के उपयोग तक सीमित करके देखना, LLM की लचीलापन क्षमता को कम आँकना है
- LLM का उपयोग सिर्फ तेज़ code generation के लिए नहीं, बल्कि उच्च-गुणवत्ता वाला कोड और भी धीरे लिखने के लिए भी प्रभावी ढंग से किया जा सकता है
- slop cannons की तरह बिना सत्यापन वाले बड़े PR उगलने के तरीके के उलट, PR की और गहराई से समीक्षा करने और संभावित विफलताओं को लगातार परखने वाला तरीका भी संभव है
Bug detection से ज़्यादा महत्वपूर्ण है verification और prioritization
- Mythos दिखाता है कि LLM agents codebase में bugs बहुत अच्छी तरह ढूँढ सकते हैं
- दूसरे उदाहरणों में भी, Mythos के अलावा अन्य models बिना समीक्षा वाले codebase में बहुत से bugs ढूँढ सकते हैं
- नवीनतम सार्वजनिक Anthropic और OpenAI models में सूक्ष्म bug detection और false positives से बचने की क्षमता में अंतर है, लेकिन वे पर्याप्त संख्या में bugs ढूँढ सकते हैं
- वास्तविक कठिनाई bug ढूँढने से अधिक prioritization और verification में है
कई models के साथ PR की समीक्षा करने वाली Claude skill
- कई models को तुलना और बहस में शामिल करने वाला AI code review approach इस बात पर केंद्रित है कि अलग-अलग models को ज़्यादा शामिल करने से hallucination या गलत bug reports की संभावना घटती है
- उपयोग में लाई जा रही Claude skill, PR review के लिए Claude sub-agent, Codex, और Cursor Bugbot चलाती है
- हर tool PR के bugs को critical/high/medium/low के रूप में grade करता है, और फिर परिणामों को मिलाकर false positives हटाई गई अंतिम रिपोर्ट बनाता है
- “bug” की परिभाषा को project standards के अनुसार व्यापक किया जा सकता है
वास्तविक workflow और निर्णय मानदंड
- यह तरीका PR में बहुत से bugs ढूँढ सकता है, और false positive दर को भी लगभग 0 के करीब ला सकता है
- मिलने वाली समस्याएँ security और correctness से जुड़े critical bugs से लेकर performance issues तक, और “comments भ्रामक हैं” जैसे कम गंभीरता वाले मुद्दों तक फैली हो सकती हैं
-
सामान्य प्रक्रिया flow
- critical और high grade वाली समस्याएँ agent से ठीक कराई जाती हैं, लेकिन उचित समाधान के लिए इंसान मार्गदर्शन देता है
- critical/high समाप्त होने तक यह प्रक्रिया दोहराई जाती है
- जिन high/medium समस्याओं को ठीक करने की लागत के मुकाबले लाभ कम हो, उन्हें छोड़ दिया जाता है
- इसका एक प्रतिनिधि उदाहरण है, किसी संकीर्ण edge case को ठीक करने के लिए 100 lines of code की ज़रूरत पड़ना
- अगर critical समस्याएँ इतनी ज़्यादा हों कि पूरा approach ही गलत लगे, तो PR छोड़ दिया जाता है
उत्पादकता से अधिक codebase health पर फोकस
- यह तकनीक ज़रूरी नहीं कि development speed बढ़ाए
- review प्रक्रिया में PR से पहले से मौजूद existing bugs भी मिल सकते हैं, जो unit tests लिखने और सूक्ष्म defects ठीक करने तक ले जा सकते हैं
- यह अक्सर “vibe coding” से जुड़ी “10x productivity” वाली development शैली के लगभग उलट है
- जटिल architecture में सामान्य paths की तुलना में failure modes ज़्यादा दिलचस्प हो सकते हैं, और उन failure points को समझना व ठीक करना codebase को सीखने का एक तरीका बन सकता है
- पूरे codebase की health सुधारते हुए उसके कम-ज्ञात हिस्सों को सीखने में यह उपयोगी है
slow vibe coding के लिए व्यावहारिक तरीके
- अगर आप agents की मदद से ऐसे सैकड़ों lines वाले PR बना रहे हैं जिन्हें आप खुद भी पूरी तरह नहीं समझते, तो आप धीमा तरीका आज़मा सकते हैं
- आप agent से पूछ सकते हैं कि PR कैसे काम करता है और कहाँ विफल हो सकता है
- ज़रूरत पड़ने पर उससे Mermaid charts वाले Markdown दस्तावेज़ भी लिखवाए जा सकते हैं
- PR को शुरू से अंत तक समझने तक आप Matt Pocock के
/grill-meskill का इस्तेमाल कर सकते हैं - lines of code के हिसाब से “productivity” शायद न बढ़े, और बहुत सारे tokens खर्च करने के बाद यह निष्कर्ष भी निकल सकता है कि शुरुआती योजना ही गलत थी
- यह तरीका LLM से पहले से जिस सावधान, व्यवस्थित, और quality के प्रति जुनूनी programming की दिशा थी, उसी को और अधिक शक्तिशाली बनाता है
2 टिप्पणियां
Hacker News की राय
AI के साथ काम करते-करते यह अब एक साधारण एक-बार की प्रक्रिया नहीं रहा, बल्कि लंबा आगे-पीछे वाला review loop बन गया है
मध्यम आकार के, कई क्षेत्रों में फैले फीचर के लिए पहले AI से implementation design बनवाता हूँ, फिर details की समीक्षा करता हूँ, और उसके बाद धीमा लेकिन बेहतर नतीजे देने वाला Claude 4.7 Max implementation करता है
उसके बाद implementation की समीक्षा कराकर Codex GPT 5.5 xhigh fast से दोबारा review करवाता हूँ, और वह लगभग हमेशा edge cases ढूँढ लेता है। Fixes मैं Claude से करवाता हूँ, क्योंकि Codex bug ढूँढने और review में मजबूत है, लेकिन code को overengineer कर देता है या shortcuts मिला देता है, जबकि Claude ज़्यादा intuitive और maintainable code लिखता है
फिर नए Claude/Codex instance से staged changes की दोबारा समीक्षा करवाता हूँ, feedback लागू करता हूँ, और उसके बाद tests भी जोड़ता हूँ। हाथ से लिखने की तुलना में यह अब भी तेज़ है, लेकिन ज़्यादातर समय review और edge cases संभालने में जाता है, और नतीजे में v1 feature भी पहले से कई बार iterate किए गए v3 जैसी implementation की तरह लगता है
इससे productive महसूस होता है, AI का output भी अच्छा आता है, और code की समझ भी आम तौर पर मेरे पास बनी रहती है। पूरा दिन robots के साथ design और architecture पर बहस करते-करते मुझे लगता है कि AI revolution ने मुझे बेहतर engineer बनाने में सबसे ज़्यादा इसी हिस्से में मदद की है
मेरा तरीका यह है कि research/planning/test plan के 5 rounds चलाता हूँ, और हर important decision पर मैं खुद loop में रहता हूँ। बड़े shape से शुरू करके details तक जाता हूँ, और planning ही मेरे समय के 2~3 दिन ले सकती है, जबकि implementation agent (Opus 4.7) कई घंटे लेता है
Implementation कई stages/commits में बँटी होती है, और हर stage पर code review fix loop होता है। आख़िरी deep code review भी 1~2 घंटे ले सकता है, और PR खोलने पर Gemini review करता है, जिसे पढ़कर मैं issues हल करता हूँ
Project अब भी कई दिन या कई हफ्ते लेता है, लेकिन सब कुछ अकेले करने की तुलना में 5 गुना तेज़ है
अतिरिक्त: वह skill https://github.com/scosman/vibe-crafting में है
कुछ मामलों में मैंने AI द्वारा बनाया गया सब कुछ फेंक दिया और बस खुद कर लिया। मेरा मानना है कि यह एक कौशल है जो लोगों को सीखना चाहिए। एक बिंदु पर नुकसान काटना आना चाहिए। खासकर simple changes में मैंने साथियों को LLM के साथ लगातार बहस करते देखा है, जैसे किसी तरह उससे काम निकलवाना हो
AI को लगातार सँभालते रहने से थोड़ी speed तो मिलती है, लेकिन क्या इससे AI ने क्या किया इसकी जानकारी और नियंत्रण कम नहीं हो जाते
LLMs को एक-दूसरे के code review की आलोचना करवाने वाला लेख[1], magpie tool[2], और Cloudflare का हालिया code review stack वाला लेख[3] काफ़ी convincing हैं
मैं AI को लेकर skeptical हूँ, लेकिन वजह “क्या यह काम करता है” से ज़्यादा “क्या यह दुनिया के लिए अच्छा है” वाली है। ऐसे review tasks बहुत कम मामलों में ऐसे लगते हैं जहाँ thinking को outsource नहीं किया जा रहा या workers की क्षमता कम नहीं की जा रही। AI से code लिखवाना, या AI द्वारा ढूँढी गई समस्या AI से ही ठीक करवाना, वैसा ही alarm नहीं बजाता। बेशक environment और दूसरी ethical concerns अब भी बहुत बड़े हैं
हाल के AI code review quality से मैं प्रभावित हुआ हूँ, लेकिन GitHub PR में 3 AI reviewers के साथ अलग-अलग interact करने का अनुभव भयानक है। काश कोई ज़्यादा local-oriented review round हो जो jj/rebase को समझता हो
संदर्भ: काफ़ी बड़ा PHP/Laravel backend और Vue frontend
[1]: https://milvus.io/blog/ai-code-review-gets-better-when-model...
[2]: https://github.com/liliu-z/magpie
[3]: https://blog.cloudflare.com/ai-code-review/
LLM review/fix loop में लगने वाला समय औसतन हाथ से सीधे code लिखने से ज़्यादा लगता है
इसकी एक वजह यह भी है कि जब मैं flow में होता हूँ तो बहुत तेज़ी से code लिखता हूँ, और कभी-कभी code मेरी उम्मीद से भी तेज़ निकलता है। और LLM शुरू की कुछ बार में जो code देता है, वह आम तौर पर सचमुच बहुत खराब होता है
फिर भी दिलचस्प बात यह है कि अगर मैं खुद review करूँ और कई बार review व fixes के निर्देश दूँ, तो औसतन नतीजा उस code से बेहतर quality का निकलता है जो मैं उसी समय में खुद लिखता। किसी और के code को कई बार iterate होते देख कर लगता है कि मैं उस goal को, जिसे पाना चाहता हूँ, अपनी deep focus वाली state से निकले नतीजे की तुलना में अधिक समग्र रूप से समझ पाता हूँ
यह लेख AI से code लिखवाने की नहीं बल्कि सिर्फ़ code review की बात करता है
Agentic coding में मेरी समस्या यह है कि programming करते समय मैं countless microscopic architectural decisions लेता हूँ। बहुत कम मामलों में शुरुआत से पूरी specification होती है; आम तौर पर लिखते-लिखते specification बनती जाती है
Claude Code या Codex इस्तेमाल करने पर वह प्रक्रिया गायब हो जाती है। Claude Code में target तक पहुँचने की चाहत इतनी ज़्यादा है कि उसके साथ coding करने का अनुभव बुखार वाले सपने जैसा लगता है। आखिर में edge cases या project के architecture/design goals से यह कितना मेल खाता है, इस पर अपना confidence कम हो जाता है
इसके अलावा, मुझे programming, reverse engineering वगैरह पसंद हैं। LLM किसी समस्या को हल कर सकता है या कोई feature deliver कर सकता है, लेकिन ऐसा लगता है कि वह उस मज़े को छीन लेता है। मैं ऐसा flow ढूँढने की कोशिश कर रहा हूँ जिसे confidence के साथ इस्तेमाल कर सकूँ, लेकिन डर है कि आख़िरकार वह flow बस chat, search, और मेरी सोच के लिए rubber duck की भूमिका तक ही सीमित न रह जाए
इसके उलट, कुछ कंपनियाँ इस बात पर ज़ोर दे रही हैं कि engineers को self-evaluating agent pipeline को इतना मजबूत बनाना चाहिए, जिसमें human feedback loop में हो, ताकि agents production code का अधिकांश हिस्सा लिखें।
Creao के CEO ने कहा कि इस साल जनवरी में उन्होंने पूरे production system को सिर्फ 2 हफ्तों में re-architect किया। उन्होंने यह भी दावा किया कि agents ने बहुत सारी functionality बहुत तेज़ी से implement कर दी, इतना कि business development टीम को उनके साथ कदम मिलाने का इंतज़ार करना पड़ा।
यह देखना दिलचस्प है कि AI के ज़रिये output को 100 गुना बढ़ाने वाले विकल्प और AI के ज़रिये अपनी skill को निखारने वाले विकल्प का आकलन कैसे किया जा सकता है।
दूसरी ओर, AI से productivity बढ़ना वास्तविक है। उदाहरण के लिए, Snowflake की एक engineering organization ने कंपनी के इतिहास में पहली बार Q1 में सभी OKR समय से पहले हासिल कर लिए। आम तौर पर plan किए गए OKR का 70% हासिल करना भी अच्छा performance माना जाता था, इसलिए ऐसे नतीजे देखकर engineers पर कैसा stress होगा, इसकी कल्पना की जा सकती है।
इस लेख का शीर्षक ऐसा लगा जैसे इसमें और गहराई होगी, और मुझे सच में code examples की उम्मीद थी।
लेकिन यह भी दूसरे opinion posts जैसा ही निकला। लेखक बस अपने लिए काम करने वाले prompts सुझाता है, यानी AI से bugs ढूंढने को कहने का तरीका, और फिर सबको वैसा ही करने की सलाह देता है।
मैं काम और अपने personal side projects में ऐसे tools इस्तेमाल करता हूँ, इसलिए कुछ देखकर सीखने की उम्मीद थी, लेकिन examples के बिना opinion posts अब बहुत ज़्यादा हो गए हैं।
लेखक इसके लिए code harness बना सकता है या जल्दी से जोड़ सकता है, लेकिन अभी इस तरह की tooling ज़्यादा आपके जैसे practitioners के क्षेत्र की चीज़ लगती है। अगर आप इसे automate करके experiment करना चाहते हैं, तो जो चाहिए उसे खुद specify करना, ईमानदारी से कहें तो, उसके code को संभालने से शायद ज़्यादा तेज़ होगा।
यह पढ़ते समय मैं एक काफ़ी dense feature पर काम कर रहा था, और इसमें काफ़ी iteration की ज़रूरत पड़ी।
अंतिम नतीजा तो बीच में मौजूद code की तुलना में बहुत कम code निकला। इसलिए मुझे यह सवाल आया कि क्या AI ने सच में मदद की। जिस समय iteration में गया, उतने में मैं शायद खुद code लिख सकता था।
लेकिन AI की वजह से मैं जल्दी से feature के 4 variants का एक rough version बना पाया, और उतनी ही जल्दी उन्हें फेंक देने में भी कोई हिचक नहीं हुई।
पहले किसी नई feature implementation में उतरने से पहले मुझे योजना पर बहुत ज़्यादा सोचना पड़ता था, और existing code के साथ mismatch अक्सर तब दिखता था जब implementation का काफ़ी हिस्सा लिखा जा चुका होता था। अब मैं AI से detailed implementation plan माँग सकता हूँ और ऐसे छोटे-छोटे detail issues कुछ घंटों में, या उससे भी कम समय में, पकड़ सकता हूँ।
पिछले कुछ वर्षों में मेरे लिए दिलचस्प बात यह रही है कि मैं अपनी coding laziness की सीमा को ट्रैक कर रहा हूँ।
एक coder के रूप में मुझे boilerplate code से नफ़रत है। न उसे लिखना पसंद है, न maintain करना। इसलिए मैं अक्सर उसी पसंद के आधार पर design और architecture तय करता रहा हूँ; कभी वह समझदारी भरा निकला, कभी नहीं। पर वह मेरी अपनी पसंद थी, और मैं ऐसे कामों से बचता था जो मेरे लिए कठिन थे।
कुछ साल पहले जब LLM coding में कुछ हद तक उपयोगी होने लगे, तो मुझे समझ आया कि वे boilerplate में असाधारण रूप से अच्छे हैं, और 2023 के आसपास तो लगभग बस उसी में अच्छे थे। इससे मैंने सोचना शुरू किया कि design और system architecture में हम अपने साथ काम करने वाले लोगों की strengths और weaknesses को कितनी गहराई से अनकहे रूप में समझते और accommodate करते आए हैं।
नवीनतम models में इंसानों की तुलना में बहुत अलग strengths और weaknesses हैं, और उन्हें तैनात करना एक दिलचस्प अभ्यास है, जिसमें अलग तरह की architecture और engineering skills चाहिए। मुझे यह पसंद आ रहा है, और उम्मीद है कि आगे भी ऐसा ही रहेगा।
LLM को prompt देकर यह न जानने से कि क्या निकलेगा,
django-admin startproject,npm init,meteor createसे deterministic output पाना कहीं बेहतर है।mature web ecosystem में boilerplate पहले ही न्यूनतम हो चुका है। अब जब यह काम LLM को सौंप दिया गया है, तो चिंता है कि
startprojectजैसे CLI और अच्छे defaults बनाने की developer मेहनत कहीं कम न हो जाए।यह मुझे पसंद आया। मैं भी इसी तरह का ralph-loop approach इस्तेमाल करता हूँ।
approved plan से शुरू करके coordinator को सौंपता हूँ, और सरल शब्दों में इसे build और review की 2 sessions में चलाता हूँ, जहाँ हर session के लिए अलग model लगा होता है।
coding agents इस्तेमाल करने में मेरे लिए एक बड़ी रुकावट यह है कि इसमें paid external services पर निर्भर होना पड़ता है।
क्या coding के लिए पर्याप्त अच्छे local models हैं?
यह भी मददगार हो सकता है: https://hnup.date/hn-sota
Qwen models इस हफ्ते मेरे रोज़मर्रा के models हैं।
Lobste.rs की राय
मेरे कार्यस्थल पर हमने AI से और तेज़ चलने का सपना छोड़ दिया है। हमारे मामले में coding bottleneck नहीं है
फिर भी coding agent की अच्छी बात यह है कि वह हमें हमेशा जैसा engineer बनना चाहते थे वैसा काम करने देता है
उदाहरण के लिए, ऐसा ठीक-ठाक test harness बनाना जिससे code को थोड़ा और आगे तक push किया जा सके, generated code मूल से मेल खाता है या नहीं इसकी जाँच के लिए CI चरण जोड़ना, और change deployment की सही तरह से monitoring करना
पहले ऐसे काम schedule के हिसाब से संभव नहीं थे, क्योंकि GitLab CI manual पढ़ना पड़ता, conditions कैसे मिलानी हैं यह समझना पड़ता, और हमारी कंपनी के उलझे हुए तरीकों को भी पकड़ना पड़ता था; अब यह संभव हो गया है, और मुझे लगता है कि यही भविष्य है
LLM को API जानने वाले spike partner या mechanical refactoring device की तरह इस्तेमाल करने पर काफ़ी सफलता मिली, खासकर strongly typed languages में। यह test लिखने में भी अच्छा है, लेकिन यह पक्का करने के लिए कि वे tests सच में बाध्यकारी हैं, कई परतों वाली प्रक्रिया होनी चाहिए
mutation testing काफ़ी मददगार रही, और जैसा मूल लेख ने सुझाया, कई बार review करना भी ज़रूरी है
पहले मैं LLM के प्रति कहीं ज़्यादा नकारात्मक था, और पीछे मुड़कर देखता हूँ तो लगभग अतार्किक रूप से, लेकिन उसका बड़ा कारण यह था कि LLM बहुत निम्न-गुणवत्ता वाला software उगलते थे
खुद गहराई से देखने पर समझ आया कि इसे cardboard prototyping tool और बहुत तेज़ typist की तरह लेना सही है। जैसे अगर मैं कहूँ, “इस Lean project की सभी theorems में यह pattern ढूँढो, उसे उस pattern से बदलो, और जहाँ तुरंत न हो सके उन्हें चिह्नित करके बाकी की सूची दो,” तो यह 100 से ज़्यादा theorems को chunk के हिसाब से ठीक कर देता है, उतने समय में जितने में मैं vim, sed, awk और अस्थायी जुगाड़ मिलाकर पहली एक-दो कोशिशें करता
Lean में language की प्रकृति और मेरे काम की वजह से “compiled” और “working” के बीच की दूरी कम है, इसलिए यह खास तौर पर अच्छा है; Rust में भी अच्छा test suite और mutation testing जोड़ दूँ तो वैसा ही एहसास होता है
मुझे लगता है कि इन tools की long tail “button दबाओ और product निकल आए” वाली नहीं है, बल्कि यह है कि अच्छे engineers इन्हें अपनाएँ, अपनी ऊर्जा महत्वपूर्ण कामों पर केंद्रित करें, और पहले के काफ़ी सारे छोटे-मोटे काम machine को सौंप दें
उदाहरण दिलचस्प है; पहले जब मैं JavaScript framework टीम में काम करता था, तो upgrade या migration जैसे कामों के लिए खुद codemod लिखता था। AST बदलना बड़ा मेहनत वाला काम था
आजकल होता तो लगता है LLM को देकर लगभग 90% तक पहुँचा जा सकता था
यह नज़रिया अच्छा लगा। यह तो स्वाभाविक लगता है कि tools लचीले होते हैं और ज़रूरी नहीं कि वे सिर्फ़ low-quality output ही बनाएँ, लेकिन समर्थन करने वाले और पूरी तरह ठुकराने वाले, दोनों पक्ष अक्सर इस नज़रिए को नज़रअंदाज़ करते हैं
अभी तक मैंने LLM से code review नहीं करवाया है, लेकिन इसे अपनी to-do list में डालना चाहिए। अब तक मैं इसे idea generation, SQL या VimScript में मदद जैसी चीज़ों के लिए इस्तेमाल करता हूँ और code खुद लिखता हूँ
एक ख़तरा यह है कि code review भी एक skill है, इसलिए अगर model पर ज़्यादा निर्भर हो जाएँ तो वह क्षमता कमज़ोर पड़ सकती है। हालाँकि commercial environment में सबसे अच्छा code review भी आम तौर पर “उचित समय” और “क्या इस व्यक्ति पर भरोसा है” का मिश्रण होता है, गणितीय शुद्धता के क़रीब नहीं
जटिल bugs के मामले में मैं अब भी खुद अंत तक सोचता हूँ, क्योंकि 1) hallucination अभी भी बीच में घुस आती है, और 2) वैसे भी system को end-to-end समझने का मूल्य है
यह meta बात है, लेकिन इस पोस्ट पर लगे flags समझ नहीं आते। off-topic 1 और spam 3 होना अजीब है
पहले पेज के सबसे ऊपर की पोस्ट भी LLM के इस्तेमाल पर है, और वह सामान्य writing पर है, इसलिए coding पर केंद्रित इस पोस्ट की तुलना में शायद कम topical लगती है, फिर भी उस पर flags नहीं दिखते
Lobsters पर ऐसा नज़रिया देखना ताज़गी भरा है। एकरूप anti-AI sentiment अब धीरे-धीरे थकाने लगा है। इस बात पर तो सब सहमत हो सकते हैं कि किसी को low-quality output पसंद नहीं है
लेकिन जिन्होंने AI का पूरी तरह बहिष्कार कर दिया है और कट्टर रुख अपना लिया है, उनके लिए भविष्य को स्वीकार करना उन लोगों की तुलना में कठिन होगा जिन्होंने ज़्यादा व्यावहारिक रुख चुना है
मैं शुरू से कहता आया हूँ कि AI कुछ-कुछ power tools के आविष्कार जैसा है। अगर आप हाथ वाले wrench से tire बदलना चाहते हैं तो ठीक है, लेकिन impact drill आने पर mechanics ने उसका बहिष्कार नहीं किया था। इस लेख के संदर्भ में यह सबसे बेहतरीन उपमा नहीं है, फिर भी मुझे यह बात सही लगती है
दस्तावेज़ पढ़ने की तुलना में AI इस्तेमाल करते हुए मैंने ज़्यादा सीखा है। क्योंकि docs से आप अतिरिक्त context, explanation, या examples चाहिए हों तो सवाल नहीं पूछ सकते। आप उससे “कुछ बनाओ, गलती मत करना” भी कह सकते हैं, लेकिन सच में सीखने के लिए मैं धीमा तरीका पसंद करता हूँ
मैंने जो देखा, वह LLM से एक ही बार में लाखों lines के code में बदलाव करके, बिना human review के deploy करने जैसी प्रवृत्ति की आलोचना थी। खास तौर पर Bun की Zig से Rust porting thread जैसे मामले
यह लेख भी उसी की आलोचना कर रहा है