बेहतर AI टूल कैसे बनाएं

 (hazelweakly.me)
17 पॉइंट द्वारा GN⁺ 2025-07-25 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • आज के अधिकांश AI टूल मानव-केंद्रित learning process (retrieval·execution·collective iteration) को प्रतिबिंबित नहीं करते — यह अंततः मानव और AI, दोनों के growth loop को बिगाड़ देने वाली उल्टी दिशा की design है
  • मनुष्य ज्ञान नहीं, बल्कि 'प्रक्रिया (process)' सीखता है, और सामूहिक व संचयी पुनरावृत्ति के जरिए innovation करता है। लेकिन अधिकांश AI टूल "button click → AI खुद ही सब कर दे" पैटर्न पर चलते हैं, जिससे मानव के सक्रिय retrieval और learning loop हट जाते हैं
  • वांछनीय AI टूल को “Explain → Demonstrate → Guide → Enhance” चरणों में मानव की सक्रिय भागीदारी और retrieval को प्रेरित करना चाहिए, और automation नहीं बल्कि 'amplification' को लक्ष्य बनाना चाहिए
  • उदाहरण: observability/recovery tools में AI को तुरंत कार्रवाई करने के बजाय, process explanation, action guidance, problem-solving guide, और बाद की improvement suggestions जैसी हर अवस्था में मानव की सोच और सीख को बढ़ावा देना चाहिए
  • जब ऐसे मानव-केंद्रित patterns स्थापित होते हैं, तो सामूहिक ज्ञान वृद्धि और AI की गुणवत्ता दोनों को साथ में मजबूत करने वाला एक positive feedback loop संभव होता है, जो system tooling के पूरे क्षेत्र में innovation ला सकता है

परिचय: मानव learning और AI tooling की मूल समस्या

  • AI टूल मानव सहयोग और learning को support करने की दिशा में नहीं, बल्कि अकुशल और उल्टी दिशा में बनाए जा रहे हैं
  • टूल इस तरह design किए जा रहे हैं कि वे मानव क्षमताओं को बढ़ाने के बजाय, critical thinking और problem solving को बाधित करते हैं
  • इस स्थिति ने पहले ही स्पष्ट दुष्प्रभाव पैदा करने शुरू कर दिए हैं, और अधिक प्रभावी दिशा में बदलाव की जरूरत है

मौजूदा AI टूल की सीमाएं: उल्टी दिशा का development

  • वर्तमान में AI टूल का बड़ा हिस्सा इस पैटर्न का पालन करता है
    • AI button click → जादू की तरह तुरंत result
    • data display और AI suggestions
    • simple prompts और automatic execution
  • यह तरीका समस्या परिभाषा, स्मृति, retrieval, process learning, knowledge transfer, और iterative improvement जैसे मानव learning loop के मुख्य हिस्सों को छोड़ देता है
  • AI मानव की मुख्य ताकतों को replace करने की कोशिश करता है, जबकि AI खुद भी उन्हीं क्षेत्रों में कमजोर है
  • नतीजा: मानव की problem-solving और thinking क्षमता का ह्रास → उच्च-गुणवत्ता वाला data पैदा न होना (जिससे AI का विकास भी बाधित होता है) → विषचक्र

मनुष्य कैसे सीखता है?

  • Retrieval Practice सिद्धांत के अनुसार, मनुष्य केवल जानकारी ग्रहण करके नहीं, बल्कि सक्रिय recall के जरिए सीखता है
  • केवल रटने से नहीं, बल्कि जानकारी को दिमाग से ‘निकालने’ की प्रक्रिया में वास्तविक learning effect पैदा होता है
  • learning में सबसे महत्वपूर्ण चीज ज्ञान से अधिक process का अधिग्रहण है
    • उदाहरण के लिए, baking सीखते समय सामग्री याद करने की तुलना में cake बनाने की प्रक्रिया सीखना अधिक प्रभावी है
  • इसी तरह का व्यावहारिक, process-केंद्रित design collaborative tools के लिए अधिक उपयुक्त है

innovation और सामूहिक growth का सिद्धांत

  • innovation का सार किसी एक व्यक्ति द्वारा नई तकनीक बनाने में नहीं, बल्कि छोटे-छोटे iterative improvements के सामूहिक संचय में है
    — यह कुछ प्रतिभाशाली लोगों की अचानक रचना नहीं, बल्कि मौजूदा ज्ञान पर कई लोगों द्वारा लगातार कुछ जोड़ने और सुधारने की प्रक्रिया है
  • मनुष्य स्वतंत्र, अकेले innovation की तुलना में अनुकरण, पुनरावृत्ति, और मौजूदा उदाहरणों के रूपांतरण के लिए अधिक अनुकूलित है
  • brain-based collective learning theory दिखाती है कि ऐसी सामूहिक innovation मनुष्यों के लिए स्वाभाविक रूप से उपयुक्त है
  • problem solving और innovation को अलग-अलग नहीं देखना चाहिए; problem-solving क्षमता, knowledge transfer, और collective learning ही innovation की असली driving force हैं
  • मुख्य बिंदु हैं: process-केंद्रित learning, उपयुक्त कठिनाई वाला प्रयास, सामूहिक पुनरावृत्ति व reinforcement, और मानव-सहायक AI
  • AI टूल को मानव का ‘thinking assistant’ होना चाहिए; उसे स्वयं निर्णय लेकर मानव का विकल्प नहीं बनना चाहिए

सही AI interaction design

  • AI की तुलना सहकर्मी या intern से अधिक, एक 'भूलने वाला instructor' से की जा सकती है
  • AI का उद्देश्य यह होना चाहिए कि उपयोगकर्ता खुद सीखे, और यह भी सीखे कि कैसे सीखना है
  • design को प्रभावी learning process (EDGE: Explain, Demonstrate, Guide, Enhance) को augment करने की दिशा में होना चाहिए
    • Explain: process guidance, missing steps का संकेत आदि (सिर्फ “button click कीजिए” नहीं)
      • छूटे हुए steps का सुझाव
      • process guide और उसका explanation देना
      • इस बात पर जोर कि मनुष्य खुद process को याद करे और execute करे
      • गलत उदाहरण: तुरंत 'execute' button देना, error tooltip आदि, जहाँ recall process की अनदेखी हो
    • Demonstrate: query transformation, UI demonstration, interactive demo आदि — सीधा “automatic execution” नहीं, बल्कि भागीदारी को प्रेरित करना केंद्र में
      • natural language query को system query syntax में बदलना
      • UI exploration support (मांगने पर सीधे संबंधित screen तक मार्गदर्शन)
      • छोटे 15-second demos और interactive tutorials देना
      • 'automatic execution' से बचना: trust कम होता है, fine-tuning मुश्किल होती है, और मानव क्षमता घटती है
      • data additions और human recall records (pairing, mentoring आदि) को भी AI को learning material के रूप में उपयोग करना चाहिए
    • Guide: सवालों को प्रेरित करना, समस्या वाले हिस्से पर चर्चा, action plan बनाना आदि Socratic questioning/verification
      • यदि उपयोगकर्ता ने plan दिया है, तो next action और guidance सुझाना
      • आवश्यक documents, code owner, और संबंधित resources की ओर मार्गदर्शन
      • observation/learning models और documentation को प्रोत्साहित करना
      • response verification, information cross-checking, clarity की पुष्टि
      • गलत उदाहरण: जवाब तक पहुँचने में मदद किए बिना support देना, बिना मांगे बहुत अधिक जानकारी देना, authoritative रवैया, या उपयोगकर्ता द्वारा 'continue' button का अति-प्रयोग
      • सहायता ऐसी होनी चाहिए जो मानव के तार्किक reasoning की पुनरावृत्ति में बाधा न डाले
    • Enhance: कार्रवाई के बाद सुधार सुझाव, repeated patterns से learning, real-world records को postmortem में बदलना आदि सूक्ष्म learning opportunities देना
      • action के तुरंत बाद या उसके दौरान क्रमिक improvement के सुझाव
      • repeated tasks के लिए shortcuts/additional features का dynamic exposure
      • process स्वयं बेहतर करने के सुझाव: infra pipeline सुधार, alerts में बदलाव, intuition पर निर्भर होने की स्थिति में बेहतर instrumentation की सलाह आदि
      • घटना के बाद notes को learning material में बदलना, observation के जरिए micro-learning बढ़ाना
      • मानव reasoning hub को बनाए रखते हुए, automatic optimization की जगह recall-strengthening prompts को स्वाभाविक रूप से शामिल करना
  • खास तौर पर, हर चरण में मानव के recall, choice, और execution की संरचना को मजबूत रखना चाहिए, और AI को इसे amplify करने वाली भूमिका पर केंद्रित रहना चाहिए
    • वास्तविक उदाहरणों (incident management और observability tools) के आधार पर, हर चरण के लिए अच्छे AI interaction examples और anti-patterns समझाए गए हैं

समग्र सिद्धांत

  • मानव learning को लगातार मजबूत करना
  • teamwork को बढ़ावा देना : सामूहिक सहयोग और information sharing
  • “blank → answer” automation के बजाय, process participation और execution-केंद्रित acceleration (लेकिन automation से सीधे replace नहीं करना)
    • 'शून्य से सीधे result' वाले approach से बचना
  • “effortless usability” नहीं, बल्कि ऐसे टूल जो उचित प्रयास और भागीदारी मांगें
  • team learning और अनुभव परिणामों में प्रतिबिंबित हो, इसके लिए support करना

code writing में लागू होने वाला अच्छा उदाहरण: 'backward' नहीं, 'forward' design

  • AI से सीधे code generation कराने के बजाय,
    • draft document लिखना → architecture diagram → test plan → test code → stub code → code generation
  • code verification के बाद पूरे process को उल्टी दिशा में जाकर tests, documents, और architecture के साथ फिर व्यवस्थित करना
  • हर चरण में सवाल और verification (recall reinforcement) को महत्व देना; जहाँ verification संभव न हो, वहाँ सिर्फ yes/no सवाल नहीं पूछने चाहिए
  • recall-based development उच्च-गुणवत्ता वाले learning/test data पैदा करता है और AI learning को भी बेहतर बनाता है

cross-functional (non-dev, जैसे customer support) विस्तार की संभावना

  • उदाहरण: किसी incident के कारण service disruption होने पर customer support team AI के जरिए dev team से संवाद करे
    • AI पहला draft देता है, और dev team verification के बाद उसकी accuracy बढ़ाती है
    • support team, dev team और अन्य संगठनों के बीच real-time information flow, और context switching का बोझ कम होता है
    • मुख्य experts पर अत्यधिक interruptions डाले बिना, जरूरत पड़ने पर आपसी संचार सहज रहता है
    • dev team के संदर्भ-समृद्ध technical answers को AI आसानी से आम-समझ वाली language में बदल सकता है
  • अगर यह संरचना लागू हो जाए, तो संगठन के भीतर और बाहर collective learning और collaboration efficiency को अधिकतम किया जा सकता है
  • यह multi-layer support/integration tool में विकसित हो सकता है

निष्कर्ष

  • मौजूदा AI टूल मानव की सामूहिक iterative learning और problem-solving क्षमता को कमजोर करने वाले तरीके (उल्टी दिशा) से विकसित किए जा रहे हैं
    • collaboration enhancement और human-led process support पर जोर देने वाले बदलाव की जरूरत है
  • तभी मानव और AI के बीच आपसी amplification के साथ growth वाला एक सकारात्मक चक्र संभव होगा
  • टूल design करते समय यह नहीं भूलना चाहिए कि मानव सिर्फ 'loop में' नहीं है, बल्कि मानव स्वयं ही loop है
  • अब समय आ गया है कि system tools में मानव-केंद्रित innovation लाया जाए
    • collaborative, process-centric, amplification-oriented AI tools ही innovation की कुंजी हैं

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

1 टिप्पणियां

 
GN⁺ 2025-07-25
Hacker News राय

  • इस लेख में कुछ भ्रमित करने वाले हिस्से हैं। Weakly को ऐसे कोडिंग एजेंट की तरह पेश किया गया लगता है जो 2025 के हिसाब से antirez की पसंद जैसा, थोड़ा अधिक passive और सिर्फ सलाह देने वाला हो, लेकिन असल में यह operations issues की जांच और समाधान करने वाले एजेंट की बात कर रहा है। Weakly का तर्क यह है कि एजेंट Clippy की तरह सिर्फ सलाह दें और इंसान को steering wheel पकड़े रहने दें। लेकिन मुझे समझ नहीं आता कि लॉग खंगालकर anomalies ढूँढने और hypothesis बनाने में इंसान की क्या खास वैल्यू है। जिस वजह से कंप्यूटर chess बेहतर खेलते हैं, उसी तरह AI इस तरह के काम में मूल रूप से इंसानों से बेहतर tool है। Weakly सलाह और वास्तविक action के बीच एक स्पष्ट रेखा खींचता हुआ लगता है, लेकिन मुझे नहीं लगता कि वह रेखा सही है। हाँ, कुछ क्षेत्र ऐसे हैं जहाँ AI को पूरी तरह autonomous execution नहीं सौंपा जा सकता (जैसे: Terraform apply चलाना), लेकिन उल्टा बहुत से क्षेत्र ऐसे भी हैं जहाँ उसे रोकने की कोई खास वजह नहीं है। Incident resolution का मकसद आखिरकार incident को हल करना ही है

    • अभी तक किसी के पास ऐसा संतोषजनक AI tool नहीं है जो incidents को ठीक से resolve कर दे। Accountability का मुद्दा भी है, और सही execution सुनिश्चित करने के लिए भी human intervention ज़रूरी है

    • मूल समस्या यह है कि क्या AI को वास्तविक production environment की access permissions दी जानी चाहिए। हाल की उन घटनाओं को देखें जहाँ AI ने “मत करो” जैसे निर्देश के बावजूद database delete कर दिया (क्योंकि not जैसे negative instructions को AI हमेशा सही नहीं समझ पाता), तो यह वास्तविक safety concern वाली स्थिति है

    • यह दिलचस्प सवाल है कि एजेंट को कितनी autonomy दी जा सकती है। DevOps best practices के अनुसार ज़्यादातर changes code commit या कई environments में promotion की प्रक्रिया से गुजरने के बाद ही production में लागू होते होंगे। इसमें सिर्फ application code नहीं, बल्कि infrastructure भी शामिल है। ऐसे में incident response के दौरान एजेंट को किन हिस्सों में autonomous execution की अनुमति दी जा सकती है, यह जानना दिलचस्प है

    • मुझे लगता है कि खुद debugging करने की भी कुछ वैल्यू है। खासकर अगर लक्ष्य programming skill को बेहतर बनाना हो, तो और भी ज़्यादा। chess का उदाहरण लें तो Leela या Stockfish जैसी AI बहुत तेज़ और गहराई से analysis कर सकती हैं, लेकिन असली improvement खुद position का analysis करने के अनुभव से आता है। chess के professional खिलाड़ी भी बार-बार tactics की practice करके अपना दिमाग तेज़ करते हैं। AI और इंसान साथ मिलकर तेज़ सीखेंगे या independently सीखना बेहतर है, इसका जवाब मुझे भी पक्का नहीं पता। और यह skill आगे meaningful भी रहेगी या नहीं, इस पर भी मेरे विचार बँटे हुए हैं

    • anomaly detection और incident management की चर्चा में एक महत्वपूर्ण बात यह है कि सभी समस्याएँ एक जैसी नहीं होतीं, और बहुत सी समस्याएँ कुछ हद तक automate की जा सकती हैं। सीमा रेखा यह है कि कौन सी समस्या कब AI जैसे cognitive processor को देनी चाहिए और कब human engineer को सीधे हस्तक्षेप करना चाहिए। AI बड़े पैमाने पर pattern detection में अच्छा है, लेकिन वह यह लगातार सही नहीं बता पाता कि कौन सा pattern वास्तव में meaningful है। बेशक, इंसान भी हमेशा इन gaps को भर पाएँ, ऐसा नहीं है

  • AI tools/products के नज़रिए से मुझे लगता है कि आगे का रास्ता "Intelligent Workspaces" होना चाहिए। सिर्फ chatbot से आगे बढ़ना होगा
    संबंधित लिंक
    मूल रूप से, ऐसी environment/platform महत्वपूर्ण है जहाँ सारे settings, levers और control इंसान के पास हों, लेकिन AI features गहराई से integrated हों। यह सिर्फ एक VSCode fork बनाने से कहीं कठिन है

    • chatbot बनाना intelligent workspace की तुलना में बहुत आसान है। और AI बिना human interaction के भी अच्छे से काम कर सकता है। मैं चाहता हूँ कि chat के अलावा दूसरे interfaces में AI के उपयोग के और तरीके सामने आएँ

    • मैं हाल ही में Claude Code के साथ एक project पर काम कर रहा हूँ, और अच्छा होगा अगर मेरा instance दूसरे developers के instances से बात करके collaborate कर सके। CLAUDE.md को edit करके documentation maintain की जा सकती है, लेकिन अगर CC में team collaboration features built-in हों तो बहुत बढ़िया होगा। किसी के पास अच्छे सुझाव हों तो साझा करें

  • मुझे लगता है यह लेख अच्छी तरह दिखाता है कि innovation अक्सर outsiders से क्यों आती है। लेखक के भीतर बड़े संगठन के engineering manager या principal engineer का नज़रिया बहुत साफ झलकता है, इसलिए यह मेरे अनुभव से बहुत मेल नहीं खाता। अगर यही style AI tooling की standard approach बन गई, तो मुझे चिंता है कि AI किसी खास human workflow assumptions के आधार पर ठहर जाएगी। मैं 15 साल से (non-programmer) domain experts के लिए assistive ML applications की R&D कर रहा हूँ, और लेखक के principles से कुछ हद तक अलग सोचता हूँ। नज़रिए में यह अंतर दिखाता है कि design space बहुत बड़ा है, और अभी यह निष्कर्ष निकालना जल्दबाज़ी होगी कि कोई एक तरीका ही सही है। AI tooling आगे कहाँ जाएगी, यह अभी किसी को नहीं पता

    • हाँ, एक व्याख्या यह भी हो सकती है कि मैंने जो ML systems बनाए, वे पिछले 15 सालों में लोगों की capabilities को standardize या replace करते रहे हैं। लेकिन मैं इस बात से सहमत हूँ कि अलग-अलग positions के हिसाब से व्याख्या बदलती है। फिर भी, मेरा मानना है कि workflow के केंद्र में इंसान (और उसका ज्ञान/खोज क्षमता) जितना हो सके उतना बना रहना एक अच्छी practice है

  • AI coding को लेकर मेरी स्थायी चिंता यह है कि skills को बनाए रखना कठिन हो सकता है। खुद code टाइप करना (boilerplate सहित) सचमुच Mr. Miyagi की paint-wax training जैसा अभ्यास है। इसी दोहराव वाली practice की वजह से patterns दिमाग में गहराई से बैठ जाते हैं, और बाद में higher-level design decisions लेने में बहुत मदद मिलती है

    • पुरानी technologies (writing, printing आदि) ने शायद handwriting या rhetoric को कमजोर किया होगा, लेकिन उन्होंने सोचने की क्षमता को बढ़ाया भी। Steve Jobs का “Bicycle-for-the-mind” विचार इसका अच्छा उदाहरण है। लेकिन AI पर यही तर्क लागू करते समय फर्क यह है कि पुरानी technologies distribution bottlenecks हटाती थीं, जबकि AI सीधे creative process को target करती है। creative work में AI का उपयोग तभी वांछनीय है जब वह मेरी अपनी creativity के विकास में बाधा न बने। इंसानी self-control और self-awareness की सीमाएँ होती हैं

    • मैं अक्सर रात में या नहाते समय समस्याओं के बारे में मन ही मन सोचता रहता हूँ और “code” की कल्पना करता हूँ। अगर language structures मेरे दिमाग में गहराई से नहीं बैठे होते, तो इस तरह की imagined coding भी मुश्किल होती

    • रोज़मर्रा की ज़िंदगी में भी इसके मिलते-जुलते उदाहरण हैं:

  1. मुझे याद भी नहीं कि आख़िरी बार मैंने हाथ से कोई meaningful चीज़ कब लिखी थी। अब मेरी handwriting सचमुच बहुत खराब हो चुकी है
  2. navigation के बिना मैं ड्राइव करते हुए रास्ता ढूँढने की सोच भी नहीं सकता। map पढ़ना? अब तो वह सपने जैसी बात है

  • एक समय transistor को हाथ से solder करने के दिन भी थे। लेकिन अब technology इतनी आगे बढ़ चुकी है कि पहले की तरह सब कुछ खुद करना भारी पड़ता है। इसी तरह सोच का focus कभी फैलता है, कभी सिमटता है, और फिर भी मुझे coding की कमी महसूस होती है। हालाँकि मैं आज भी काफी coding करता हूँ

  • “Every augmentation is an amputation(हर augmentation किसी न किसी हिस्से का amputation है)” - Marshall McLuhan

  • इसी वजह से मुझे Deep Research बहुत पसंद है। यह हमेशा सवाल से शुरुआत करता है और मुझे यह और स्पष्ट करने पर मजबूर करता है कि मैं वास्तव में क्या सीखना चाहता हूँ। मुझे लगता है कि UX में ऐसा छोटा बदलाव भी सेवा के उपयोगकर्ता की learning पर, या उल्टा बिना critical thinking के tool dependency बढ़ाने पर, बड़ा असर डाल सकता है

    • लेकिन क्या आपने उस सवाल को खुद बहुत ध्यान से देखा है? Deep Research कभी-कभी उपयोगी होता है, लेकिन कई बार वह “सवाल” सिर्फ दिखावे के लिए जोड़ा गया लगता है। मैं जिन बातों को पहले ही ध्यान से साफ-साफ लिख चुका होता हूँ, उन्हें भी वह फिर से पूछता है। वास्तविक search process में यह बहुत मददगार नहीं लगता

    • एक technical writer के रूप में मैं Deep Research का इस्तेमाल नहीं करता। उल्टा यह मेरे काम में बाधा डालता है। research, note-taking और summarization की प्रक्रिया खुद इस बात का मूल हिस्सा है कि मैं किसी विषय को गहराई से समझूँ। लिखित रिकॉर्ड तो बस उसका परिणाम है। अगर AI वह काम मेरे लिए कर दे, तो मुझे notes तो मिल जाएँगे, लेकिन वैसी समझ नहीं मिलेगी। AI द्वारा लिखा दस्तावेज़ पढ़ना सीधे अनुभव की जगह नहीं ले सकता

  • मुझे लगता है यह लेख AI adoption के मूल बिंदु को लेकर भ्रमित है। AI अपनाने का उद्देश्य इंसानों को अधिक बुद्धिमान बनाना नहीं, बल्कि ऐसे दोहराव वाले काम हटाना है जहाँ human creativity को meaningful reward नहीं मिलता, ताकि पूरे process की productivity बढ़ सके

  • मेरे अनुभव में coding के दौरान AI का सबसे अच्छा उपयोग कुछ इस तरह है:

    • एक advanced find/replace की तरह, जैसे struct initialization वाले हिस्सों पर एक साथ “यह सब Y से बदल दो” कहना। (regex बहुत कठिन है)
    • agent workflow में, इसे इंसान की तरह treat करने के बजाय ऊँचे स्तर के chunked tasks step-by-step देना ज़्यादा प्रभावी है। “feature implement करो” कहने के बजाय “नई file बनाओ और stub function define करो” → “पहले function में x behavior जोड़ो” → “दूसरे function में पहले पहले वाले function को call करके Y करो” जैसी breakdown बेहतर काम करती है
    • अनजाने codebase में जानकारी ढूँढना, या किसी खास implementation के बारे में पूछना। जैसे “copilot, app routes सब कहाँ define हैं?” — पहले जिन बातों के लिए बार-बार IRC experts से पूछना पड़ता था, उन्हें अब जल्दी verify किया जा सकता है, इसलिए यह बहुत सुविधाजनक है

  • हाल ही में मैंने अपने पिता की presentation materials तैयार करने में मदद की। उनके पास जानकारी पर्याप्त थी, लेकिन non-designer होने के कारण उन्हें slides को आकर्षक बनाने में दिक्कत थी। हमने कई AI slide generation apps आज़माईं, लेकिन वे देखने में प्रभावशाली होने के बावजूद उपयोगकर्ता जिस तरह की “design improvement” चाहता है, उसमें मददगार नहीं थीं। आखिरकार निष्कर्ष यही निकला कि हाथ से सुधार करना कहीं बेहतर है

  • मैं पूरी तरह सहमत हूँ कि खासकर “architecture और test design से शुरू करके उसे वास्तविक code पर लागू करना” वाला flow 100% अधिक प्रभावी रहा। सिर्फ workflow habits बदलकर भी यह किया जा सकता है (हालाँकि dedicated tools या standard prompts हों तो और अच्छा है)

    • मुझे भी इसकी ज़रूरत इतनी महसूस हुई कि मैंने खुद architecture tool बनाना शुरू कर दिया। अगर architecture रचनात्मक और सही हो, तो implementation को मौजूदा AI के हवाले करना काफी हद तक संभव है। हालाँकि, ये tools अभी भी docker-compose जैसे long-running processes के logs पढ़ने में कमजोर हैं। और असल में जो काम किए जाने चाहिए, वे ये हैं:
      • समस्या की जाँच
      • feature का विवरण
      • API contract की परिभाषा
      • basic implementation plan लिखना
      • authentication/authorization सेट करना
      • test strategy और efficient test setup/teardown तैयार करना
      • library documentation और AI के लिए आधिकारिक docs search करना
      • और AI import जैसी चीज़ों में अक्सर गलती करता है, long-running processes भी एक कमजोरी हैं
    • यहाँ “vibe” शब्द हटाने पर भी वाक्य का सार वही रहेगा, इसलिए यह बात मूल रूप से अहम है

  • इंसान cumulative iteration (लगातार सुधार) में सचमुच बहुत विशेष प्रजाति है। इसी वजह से brainstorming group में खास तौर पर प्रभावी होती है। cognitive psychology में collective learning और innovation की cumulative “culture” theory तक है। हम अक्सर “giants के shoulders पर खड़े होना” जैसी बात कहते हैं, और यह सिर्फ अच्छा मुहावरा नहीं, बल्कि सचमुच इंसानों के काम करने का तरीका है। creativity आखिरकार search है, और वह social search है। यह सिर्फ दिमाग के अंदर की बात नहीं, बल्कि दिमाग और environment की interaction, तथा social/cultural layers के भीतर विकसित होती है। इसलिए मैं इस बात को लेकर चिंतित नहीं हूँ कि LLM सचमुच “समझता” है या नहीं। अगर वह search कर सकता है, ideas बना सकता है और वास्तव में verify कर सकता है, तो मेरे लिए वह काफी है। साथ ही, मेरा मानना है कि substrate कुछ भी हो, search खुद उससे अधिक महत्वपूर्ण है। हाँ, substrate के अनुसार उपलब्ध search space बदल सकता है