मेरी AI अपनाने की यात्रा

 (mitchellh.com)
38 पॉइंट द्वारा GN⁺ 2026-02-06 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • HashiCorp से exit करने और Ghostty बना रहे Mitchell Hashimoto ने AI tools को अपने वास्तविक काम में integrate करने तक की प्रक्रिया को संक्षेप में बताया
  • इसे अक्षमता → अनुकूलन → उत्पादकता में सुधार के तीन चरणों में बाँटा गया है, और हर चरण में हुई कोशिशों, गलतियों और सीखने की प्रक्रिया को ठोस रूप से दर्ज किया गया है
  • chatbot-आधारित coding की सीमाएँ पहचानने के बाद, agent-आधारित tools की ओर जाने पर उन्हें असली value मिलनी शुरू हुई
  • पहले manually पूरे किए गए commit को agent से दोबारा बनवाने की practice के जरिए उन्होंने सीखा कि काम को तोड़ना, planning/execution को अलग रखना, और automated verification सबसे अहम हैं
  • दिन के आख़िरी 30 मिनट का उपयोग करके रात में automated work चलाना और दोहराए जा सकने वाले सरल काम agent को सौंपना — इससे वास्तविक उत्पादकता में सुधार मिला
  • अब वे हमेशा एक agent चलाते हैं, और गलती रोकने के लिए 'harness engineering' भी साथ में करते हैं ताकि AI और इंसान के सहयोग की दक्षता अधिकतम हो सके

अपनाने की पृष्ठभूमि और दृष्टिकोण

  • हर नए tool को अपनाने में अक्षमता → अनुकूलन → नवाचार के तीन चरणों से गुजरना पड़ता है
    • मौजूदा workflow की आदत होने के कारण शुरुआती adoption असुविधाजनक होता है, लेकिन लंबी अवधि में यह उत्पादकता बढ़ाता है
  • AI tools को लेकर अति-उम्मीद या अति-आलोचना के बजाय, वास्तविक उपयोग अनुभव पर आधारित संतुलित नज़रिया पेश किया गया है

Step 1: chatbot से बाहर निकलना

  • ChatGPT, Gemini जैसे chatbot interface के ज़रिए coding पहले से सीखी गई जानकारी पर निर्भर करती है, और errors ठीक करना इंसान की बार-बार की feedback पर निर्भर होने से अक्षम होता है
  • Zed के command palette का screenshot Gemini में paste करके उसे SwiftUI में दोबारा बनवाना पहला "हैरान कर देने वाला पल" था, और यही Ghostty के macOS command palette की नींव बना
  • लेकिन brownfield project (मौजूदा codebase) के संदर्भ में chatbot अक्सर खराब नतीजे देता था, और code व output को copy-paste करने की प्रक्रिया सीधे काम करने से भी ज़्यादा अक्षम थी
  • value पाने के लिए agent का इस्तेमाल ज़रूरी है; agent ऐसा tool है जिसमें LLM बार-बार external actions call कर सकता है, और कम-से-कम file पढ़ना, program चलाना, और HTTP request करना आना चाहिए

Step 2: अपने काम को agent से दोबारा बनवाना

  • Claude Code का पहली बार इस्तेमाल करने पर वे उसके output से संतुष्ट नहीं थे, और उसे सुधारने में सीधे खुद करने से ज़्यादा समय लगा
  • हार मानने के बजाय, उन्होंने manual commit को agent से बिल्कुल वैसा ही दोबारा बनवाने की practice बार-बार की
    • एक ही काम दो बार (manual + agent) करना तकलीफ़देह था, लेकिन tool adoption में friction स्वाभाविक है
  • इस प्रक्रिया में उन्होंने तीन मुख्य सिद्धांत पहचाने:
    • session को स्पष्ट और लागू किए जा सकने वाले छोटे कामों में तोड़ें
    • अस्पष्ट request के लिए planning session और execution session अलग रखें
    • agent को काम verify करने का तरीका दें, ताकि वह अपनी गलती खुद सुधार सके और regression रोक सके
  • agent किन क्षेत्रों में अच्छा नहीं है, यह समझकर कब इस्तेमाल नहीं करना है जानना भी दक्षता बढ़ाने का बड़ा कारण बना
  • इस चरण में शुद्ध efficiency gain महसूस नहीं हुआ, लेकिन agent को एक tool के रूप में संतोषजनक ढंग से अपनाया गया

Step 3: दिन के अंत में agent का उपयोग

  • हर दिन के आख़िरी 30 मिनट agent-based काम शुरू करने के लिए तय करने का पैटर्न अपनाया गया
    • यह परिकल्पना थी कि जब वे काम नहीं कर रहे हों तब agent प्रगति करे, तो दक्षता मिलेगी
  • तीन तरह के काम विशेष रूप से प्रभावी रहे:
    • deep research session: किसी भाषा के किसी खास license वाली library की जाँच, उसके फायदे-नुकसान, development activity, community response आदि का multi-page summary बनाना
    • parallel agent से अस्पष्ट ideas की खोज: release के लिए नहीं, बल्कि अगले दिन काम शुरू करने से पहले unknown variables खोजने के लिए
    • issue और PR classification/review: gh (GitHub CLI) का उपयोग करके parallel agent से issue triage, लेकिन agent सीधे जवाब नहीं देता बल्कि अगले दिन देखने के लिए सिर्फ report बनाता
  • agent को रात भर loop में नहीं चलाया जाता था; अधिकांश काम 30 मिनट के भीतर पूरे हो जाते थे
  • दिन के बाद वाले थकाऊ समय को agent work में बदलकर अगले दिन सुबह "warm start" प्रभाव मिला

Step 4: भरोसेमंद कामों का स्पष्ट delegation

  • जब वे ऐसे काम पहचान पाए जिन्हें agent लगभग निश्चित रूप से अच्छी तरह कर सकता है, तो वे काम background agent को सौंपकर खुद दूसरे कामों पर ध्यान देने लगे
  • हर सुबह पिछली रात के triage results को manually filter करके agent के लिए उपयुक्त issue चुने जाते, और उन्हें एक-एक करके चलाया जाता
  • इस समय वे SNS या वीडियो देखने के बजाय AI से पहले वाले तरीके की गहरी सोच वाले काम खुद करते
  • agent desktop notifications बंद करना एक मुख्य बिंदु था: context switching की cost बहुत अधिक है, इसलिए agent इंसान को interrupt न करे; बेहतर है कि स्वाभाविक break के समय ही उसे देखा जाए
  • Anthropic के skill formation research paper के संदर्भ में: agent को सौंपे गए कामों में skill formation छोड़नी पड़ती है, लेकिन जो काम manually जारी रहते हैं उनमें skill formation स्वाभाविक रूप से बनी रहती है
  • इस चरण में वे "अब पीछे नहीं लौटा जा सकता" वाले स्तर तक पहुँचे; सबसे बड़ा लाभ यह था कि वे अपनी पसंद के काम पर ध्यान दे पाए

Step 5: harness engineering

  • agent सबसे अधिक कुशल तब होता है जब वह पहली कोशिश में सही result दे, या फिर बहुत कम संशोधन की ज़रूरत पड़े
  • agent हर बार गलती करे तो उसी गलती को दोबारा न होने देने के लिए समाधान को engineer करना ही "harness engineering" है
  • इसके दो रूप हैं:
    • implicit prompting में सुधार (AGENTS.md): agent गलत command चलाए या गलत API ढूँढे, तो AGENTS.md file में उसे दर्ज करके समस्या सुलझाई जाती है — Ghostty repository में इसका वास्तविक उदाहरण है
    • programmed tools: screenshot capture, filtered test execution जैसी scripts लिखना और AGENTS.md में agent को उन tools के बारे में बताना
  • वे अभी इसी चरण में हैं और agent के खराब व्यवहार को रोकने तथा अच्छे व्यवहार को verify करने में सक्रिय निवेश कर रहे हैं

Step 6: हमेशा agent चलती अवस्था में रखना

  • Step 5 के साथ-साथ लक्ष्य यह है कि हमेशा एक agent background में चलती रहे
  • Amp के deep mode (GPT-5.2-Codex आधारित) जैसे slow model पसंद हैं, जो 30 मिनट से ज़्यादा लेते हैं लेकिन high-quality result देते हैं
  • अभी वे कई agents को parallel में नहीं चलाते, क्योंकि एक agent और manual work के बीच का संतुलन उन्हें उपयुक्त लगता है
  • वास्तव में काम के समय का लगभग 10~20% ही background agent चलती रहती है, और वे इस अनुपात को बेहतर बनाने की कोशिश में हैं
  • agent चलाना खुद लक्ष्य नहीं है; इसे सिर्फ तब चलाना चाहिए जब वह सचमुच मददगार काम करे, और delegate किए जा सकने वाले high-quality workflow बनाना AI हो या न हो, हर हाल में महत्वपूर्ण है

वर्तमान स्थिति और दृष्टिकोण

  • वे AI tools से परिणाम हासिल कर रहे हैं और वास्तविकता पर आधारित संतुलित दृष्टिकोण के साथ आगे बढ़ रहे हैं
  • उनका किसी AI company में नौकरी, निवेश, या advisory संबंध नहीं है; AI रहे या न रहे, software craftsman के रूप में चीज़ें बनाना उन्हें पसंद है, यही उनकी मुख्य प्रेरणा है
  • बुनियादी आधार कमज़ोर वाले junior developers की skill formation समस्या को लेकर वे गंभीर रूप से चिंतित हैं
  • model innovation की गति तेज़ होने के कारण agent क्या नहीं कर सकता, इस बारे में निर्णय को लगातार दोबारा परखना ज़रूरी है
  • AI का उपयोग करना या न करना व्यक्ति की पसंद है, और यह लेख tool exploration और उपयोग के तरीके का एक व्यक्तिगत उदाहरण साझा करने के उद्देश्य से लिखा गया है

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

1 टिप्पणियां

 
GN⁺ 2026-02-06
Hacker News की राय

  • सेशन को साफ़ और कार्रवाई योग्य काम की इकाइयों में बाँटना ही असली कुंजी है
    अगर निर्देश बहुत ज़्यादा बारीक हों तो LLM इस्तेमाल करने की ज़रूरत ही नहीं रहती, और उल्टा अगर “कुत्तों के लिए Facebook ऐप बना दो” जैसी बहुत व्यापक मांग हो तो बस बेकार प्रोटोटाइप निकलते हैं
    आखिरकार, कोड के लिए LLM का सफल उपयोग इसी उचित दायरे को खोजने का काम है

    • AI टूल्स इस्तेमाल करते समय मुझे सबसे ज़्यादा मज़ा इसी इंट्यूशन बनाने वाले हिस्से में आता है
      किस तरह का काम सौंपने पर अच्छे नतीजे आते हैं, इसका अंदाज़ा लगाना और उसी हिसाब से दायरा तय करना, प्रोग्रामिंग में मॉड्यूलराइज़ेशन जैसी खुशी देता है
    • “Facebook for dogs” वाले उदाहरण की तरह मैंने भी बहुत बड़ा अनुरोध देकर असफलता झेली है
      Lovable में तो onboarding से ही असफलता की तरफ धकेले जाने जैसा लगा, लेकिन Claude Code के साथ छोटे हिस्सों में तोड़कर आगे बढ़ना कहीं ज़्यादा सफल रहा
    • LLM को अगर सिर्फ for सिंटैक्स के उदाहरण ढूँढने जैसे काम में इस्तेमाल करें तो कॉन्टेक्स्ट स्विचिंग कम होती है, इसलिए सुविधा रहती है
      शुरुआत में मैंने इसका इस्तेमाल ऐसे ही साधारण कोड-लेखन सहायक के रूप में काफी किया
    • जैसे-जैसे मॉडल बेहतर हो रहे हैं, उस उचित दायरे की ऊपरी सीमा हर 6~8 हफ्तों में ऊपर जाती हुई लगती है
    • कभी-कभी मैंने “output को print कर दो” कहा, तो उसने सचमुच सिर्फ print(output) जोड़ दिया
      नैचुरल लैंग्वेज और कोड के बीच आना-जाना करना उल्टा मनोवैज्ञानिक रूप से ज़्यादा सहज लगता है

  • 2025 वह साल था जब AI coding tools सच में व्यावहारिक चरण में पहुँचे
    पहले GPT-3 जैसे शुरुआती मॉडल सिर्फ संभावनाएँ दिखाते थे, और उसी से बहुत ज़्यादा hype और skepticism पैदा हुआ
    लेकिन अब बहुत से डेवलपर अपने असली workflow में AI को जोड़ रहे हैं
    अगर कोई डेवलपर अब भी सशंकित है, तो उसे Mitchell का लेख पढ़ना चाहिए और Claude Code खुद आज़माना चाहिए

    • मैं भी यही सोचता हूँ। 10 साल बाद हम किस पल को turning point के रूप में याद करेंगे, यह देखना दिलचस्प होगा
      एक समय “data limit” की बात बहुत होती थी, लेकिन Claude Code, Sonnet 4.5, और Opus 4.5 आने के बाद माहौल पूरी तरह बदल गया
    • यह जानने की जिज्ञासा है कि Codex या Gemini के बजाय Claude Code इस्तेमाल करने की कोई खास वजह है क्या
      दोनों मॉडल काफ़ी मिलते-जुलते लगे, लेकिन Claude में plan usage limit जल्दी खत्म होने की बात सुनकर मैंने अभी तक उसे नहीं आज़माया
    • लेकिन अब भी hype-केंद्रित industrial structure चिंता पैदा करता है
      डर है कि management सिर्फ speed और output पर ज़ोर देकर ऐसे कोड के ढेर बनवा दे जो टिकाऊ ही न हों

  • “Don’t draw the owl” वाला approach मेरे अनुभव से भी मेल खाता है
    समस्या यह थी कि LLM धीरे-धीरे वास्तविक सीमाओं से भटकते हुए drift करने लगता था
    इसलिए मैंने chat को design discussion के लिए, और agent को सिर्फ संकीर्ण और सत्यापित किए जा सकने वाले diff कामों के लिए अलग कर दिया
    जब यह loop स्थिर हुआ, तो यह खिलौना नहीं बल्कि सचमुच का leverage बन गया, और मैंने असली प्रोजेक्ट फीचर्स कई बार deploy किए

    • किसी ने कहा कि लेखन शैली LLM जैसी लगती है
      आजकल ऐसे पैटर्न वाले वाक्य ढाँचे लोगों के बीच भी बढ़ रहे हैं, जो दिलचस्प है
    • यह भी लगता है कि यह तरीका दरअसल उस तरीके से अलग नहीं है, जिस तरह हमें मूल रूप से software बनाना चाहिए था

  • Opus 4.5 पर इतनी चर्चा देखकर मैंने भी खुद इसे आज़माया, और महसूस हुआ कि agent paradigm अब सच में उपयोगी हो गया है
    अभी ज़्यादातर सरल कामों तक सीमित है, लेकिन संतोषजनक है

  • LLM मेरे लिए उपयुक्त नहीं है
    इंसानी सोचने की क्षमता और रचनात्मकता ही हमें अलग बनाती है, और इसे मशीन को सौंपना मुझे अपने आपको कमज़ोर करना लगता है
    Rails डेवलपर के रूप में मैंने Zed, Claude Sonnet 4.x, और Opus का इस्तेमाल किया, लेकिन मुझे महसूस हुआ कि मेरी RSpec लिखने की क्षमता धीरे-धीरे घट रही है
    आखिरकार मैं agent के बिना neovim पर लौट आया
    सुविधा अंततः विचार-क्षमता के क्षय को बुला सकती है
    LLM इंसान द्वारा बनाया गया सबसे बेहतरीन convenience tool हो सकता है, लेकिन मैं अपने कौशल और सोच को बनाए रखने वाला रास्ता चुनता हूँ

  • यह लेख frontpage पर आने वाले दूसरे लेखों की तुलना में कहीं ज़्यादा व्यावहारिक और कम बढ़ा-चढ़ाकर लिखा हुआ लगा

    • आखिरकार ऐसा step-by-step guide आया है जिसे संदेह रखने वाले लोग भी आज़मा सकते हैं
      “vibe coding से OS बना लिया” जैसी अतिशयोक्ति की जगह यह एक यथार्थवादी approach है

  • यह दिलचस्प है कि सब लोग लगभग एक जैसी AI उपयोग यात्रा से गुजर रहे हैं
    कई मॉडल साथ-साथ चलाकर codebase के अलग-अलग हिस्सों पर लगाए जाते हैं, और मॉडल एक-दूसरे का cross-check भी करते हैं
    अब भी मैं अक्सर git reset करता हूँ, लेकिन धीरे-धीरे इससे बचने के ज़्यादा प्रभावी तरीके सीख रहा हूँ
    ऐसा लगता है जैसे हम brain autocomplete के युग में जी रहे हैं

  • किसी ने कहा, “agent को files पढ़ना, programs चलाना, और HTTP requests करना आना चाहिए,”
    यह लगभग Simon Willison के बताए ‘fatal trifecta’ के बराबर है

    • इसलिए मैं तो इसे अपनी local machine पर कभी नहीं चलाऊँगा

  • agent को लगातार सुधार के बिंदु बताते रहना चिड़चिड़ा बनाता है
    हर बार agent.md बदलकर feedback देना पड़ता है, अच्छा हो अगर वह खुद सीखकर बेहतर हो जाए

    • लेकिन किसी के लिए जो सुधार है, वह किसी और के लिए code smell हो सकता है
      AGENTS.md में कुछ पंक्तियाँ जोड़ना इतना बड़ा काम भी नहीं है
      अगर /fix कमांड बना दी जाए जो इसे अपने-आप ठीक करे और document भी करे, तो काफ़ी समय बचेगा
    • मुझे तो उल्टा feedback देना अच्छा लगता है
      इससे महसूस होता है कि engineering की बागडोर अब भी मेरे हाथ में है
      खासकर नई फीचर research और implementation को तेज़ी से दोहराने में यह अच्छा लगता है

  • अगर यह देखना हो कि असल में ऐसा approach कैसा दिखता है,
    तो OP की पुरानी ब्लॉग पोस्ट “Non-trivial Vibing” और
    उस पर हुई HN चर्चा देखना उपयोगी होगा