लेख
AI के इस्तेमाल की सीमा आपकी महत्वाकांक्षा है: गति, ऊँचाई, गहराई और विस्तार के चार आयाम
Anthropic के इंजीनियरिंग लीड Felix Rieseberg ने "AI के साथ ज़्यादा महत्वाकांक्षी होने" को चार आयामों में बाँटा है: गति, ऊँचाई, गहराई और विस्तार। इस लेख में उनके तरीके और उदाहरण समेटे गए हैं, साथ में मेरे अपने प्रैक्टिकल नोट्स भी हैं: लक्ष्य-केंद्रित निर्देश दें, और Multi-AI Agents की विशेषज्ञ टीम को अलग-अलग नज़रियों से क्रॉस-रिव्यू के लिए लगाएँ, ताकि काम की गुणवत्ता बढ़े।
· 1 मिनट में पढ़ें
Anthropic के इंजीनियरिंग लीड Felix Rieseberg ने अपने लेख "How to be more ambitious: A tutorial for humans with models" में लिखा है कि जब वे दूसरों को AI से हैरान करने वाले नतीजे निकालते देखते हैं, तो उनकी और उनके आसपास के लोगों की एक ही प्रतिक्रिया होती है: "हम काफ़ी महत्वाकांक्षी नहीं हैं।"
मेरी समझ यह है: इंसान के AI इस्तेमाल की सीमा अक्सर मॉडल नहीं, बल्कि उसकी अपनी महत्वाकांक्षा और कल्पनाशक्ति होती है।
उन्होंने "महत्वाकांक्षा" को चार आयामों में बाँटा है:
- गति (Speed): वही काम कम समय में पूरा करना।
- ऊँचाई (Altitude): अमूर्तता का स्तर ऊपर उठाना और किसी एक टास्क की जगह अंतिम नतीजे को देखना।
- गहराई (Depth): क्षेत्र के शीर्ष विशेषज्ञों के मानकों, टूल्स और तरीकों से काम करना।
- विस्तार (Range): किसी एक क्षेत्र से बाहर निकलकर अलग-अलग क्षेत्रों में समाधान खोजना।
निष्कर्ष पहले ही: लक्ष्य-केंद्रित निर्देश सटीक ढंग से दें, और Multi-AI Agents की विशेषज्ञ टीम को अलग-अलग नज़रियों से सहयोग और क्रॉस-रिव्यू के लिए लगाएँ, तभी काम की गुणवत्ता पूरे तौर पर ऊपर उठती है।
एक: गति, सबसे बुनियादी और सबसे कम अटकाने वाली#
वही काम कम समय में पूरा करना। Felix के मुताबिक़ यह सबको पहले से पता है, इसलिए उन्होंने लेख में इसे सीधे छोड़ दिया।
मेरा नज़रिया: गति AI का सबसे सीधा दिखने वाला फ़ायदा है, लेकिन सिर्फ़ गति के पीछे भागने से सहयोग का तरीका ज़्यादा नहीं बदलता। असली फ़र्क़ आगे के तीन आयामों से पड़ता है।
दो: ऊँचाई, "लक्ष्य के पीछे का लक्ष्य" पूछें#
मुख्य सवाल: मुझे अगला असली नतीजा क्या चाहिए? इस लक्ष्य के पीछे का लक्ष्य क्या है?
Felix के उदाहरण:
- एक Crash ठीक करने से, App को Crash-मुक्त बनाने तक। पहले वे Claude से सिर्फ़ एक Crash ठीक करवाते थे, फिर माँग बदलकर App को ज़ीरो Crash पर रखने की कर दी। इसे लगातार अपने आप चलाने के लिए उन्हें पहले अपना प्रोसेस बदलना पड़ा: Crash रिपोर्ट आसानी से मिलें, App के वर्शन को Git Commit से जोड़ा जाए, और Claude Windows, macOS और Linux मशीनों पर फ़िक्स को दोबारा चलाकर जाँच सके।
- तिमाही बिज़नेस रिव्यू (QBR) के तीन चरणों में अपग्रेड:
- जहाँ तक हो सके कच्चे डेटा का इस्तेमाल करके बताएँ कि इस तिमाही में क्या बदला, क्यों बदला और आगे क्या करना चाहिए।
- सबसे ज़रूरी 3 फ़ैसले छाँटें और हर एक के पक्ष-विपक्ष के तर्क लिखें।
- ऐसा वैकल्पिक तंत्र डिज़ाइन करें जो तिमाही प्रेज़ेंटेशन से पहले समस्या पकड़ ले, उसे पुराने डेटा पर परखें, और एक तिमाही तक मौजूदा प्रोसेस के साथ-साथ चलाएँ।
उन्होंने सीमा भी बताई: 2026 में "Claude, जाकर मेरे लिए पैसे कमाओ" जैसे धुंधले लक्ष्य अभी काम नहीं करते, लेकिन उन्हें उम्मीद है कि मॉडल जितना अमूर्त स्तर सँभाल सकते हैं वह बढ़ता जाएगा।
तीन: गहराई, क्षेत्र के शीर्ष विशेषज्ञों के स्तर की माँग#
Felix का तरीका:
- वही टूल्स इस्तेमाल करें जो उस उद्योग में सचमुच इस्तेमाल होते हैं। मॉडल अक्सर सिर्फ़ शब्द बदलता है, तरीका नहीं, और एक Markdown टेबल थमाकर छुट्टी पा लेता है। डेटाबेस और स्टैटिस्टिकल मॉडल जैसे असली विश्लेषण टूल्स पर अड़े रहें।
- ऐसा लक्ष्य रखें जो बेतुका लगे, और मॉडल को बताएँ कि यह हल हो सकता है। उनका उदाहरण: वेबसाइट की लोडिंग 10 सेकंड से 5 सेकंड करने के बाद 200 मिलीसेकंड की माँग। जब मॉडल पीछे हटे, तो डटे रहें कि यह हासिल हो सकता है।
- अपनी मानी हुई धारणाओं को चुनौती दें। मॉडल को कच्चा डेटा दें और विरोधी नज़रिए से जाँच करवाएँ। जैसे: "हमें लगता है कि churn की वजह onboarding है; कच्चे डेटा से यह निष्कर्ष दोबारा निकालकर दिखाओ।"
- नया ज्ञान पैदा करें। Logs से सिमुलेशन बनाएँ, churn का वह सबसे शुरुआती संकेत खोजें जो आपको अभी पता नहीं है, और फिर ऐसे डेटा पर जाँचें जो पहले देखा नहीं गया।
- बाहरी जज (Outside Judge) रखें। मॉडल से ख़ुद अपनी जाँच न करवाएँ। सबसे अच्छा है कि कोई ऐसा टूल जोड़ें जिसे मॉडल सीधे चला सके और तुरंत फ़ीडबैक पा सके।
उनका Prompt सूत्र है: माँग "ज़्यादा गहरा संस्करण" की हो, "ज़्यादा बड़ा संस्करण" की नहीं। मॉडल से कहलवाएँ कि शीर्ष पेशेवर और क्या करेगा, सबसे मूल डेटा कहाँ है, कौन से तरीके और टूल इस्तेमाल होंगे, और मॉडल या आपके अपने फ़ैसले के अलावा और क्या साबित कर सकता है कि नतीजा सही है।
चार: विस्तार, संज्ञा की जगह क्रिया, और विशेषज्ञों की टीम बनाएँ#
- संज्ञा की जगह क्रिया। यह अवधारणा Felix ने The Art of Innovation से ली है। QBR "एक प्रेज़ेंटेशन" होने की बजाय "30 मिनट में व्यस्त लोगों को कारण-परिणाम समझाना और अनिश्चितता के बीच फ़ैसला लेने लायक बनाना" है। लक्ष्य को क्रिया से परिभाषित करने पर दिख जाता है कि किन-किन क्षेत्रों की क्षमताएँ चाहिए।
- टीम बनाएँ। अच्छा प्रेज़ेंटेशन बनाने के लिए विश्लेषक, पत्रकार और संपादक लें; मंच पर पेश करने के लिए मोशन और साउंड डिज़ाइनर भी जोड़ें। विरोधी समीक्षा के लिए शॉर्ट-सेलिंग फ़र्म के शोधकर्ता और फ़ॉरेंसिक अकाउंटेंट लें।
- बेमतलब रोल-प्ले न करें। मॉडल से यह न कहें कि "शॉर्ट-सेलिंग फ़र्म के लहजे में लिखो"; कहें कि शॉर्ट-सेलिंग फ़र्म के शोध का कोई हिस्सा उसी के तरीके से सचमुच करके दिखाओ। सिर्फ़ लहजा बदलने से नतीजा बेहतर नहीं होता।
शर्त यह है: मॉडल के पास सॉफ़्टवेयर इंस्टॉल कर सकने वाला कंप्यूटर हो, और MCP कनेक्टर जैसे तरीकों से उसे संबंधित डेटा तक पहुँच मिले।
पाँच: मेरे प्रैक्टिकल नोट्स, "डेटा ट्रांसफ़र" से "इरादे की पूर्ति" तक#
नीचे का हिस्सा सॉफ़्टवेयर आर्किटेक्चर और इंजीनियरिंग व्यवहार को जोड़कर किया गया मेरा अपना विस्तार है, मूल लेख की सामग्री नहीं।
1. Jobs to be Done और Intent-Based#
- "क्या करना है" मत पूछिए, "क्या हासिल करना है" पूछिए। डिज़ाइन को
generate_deck_pdf() जैसी निष्क्रिय डेटा-ट्रांसफ़र पाइपलाइन पर नहीं रुकना चाहिए, उसे resolve_leadership_uncertainty_and_commit_budget() जैसे स्टेट-ट्रांज़िशन के इरादे तक उठाना चाहिए।
- असली loss function तय करें। सिर्फ़ आउटपुट माँगने पर मॉडल बाहर से परफ़ेक्ट दिखने वाला खोखला पाठ बना देगा; फ़ैसले की अनिश्चितता सुलझाने की माँग करने पर ही मॉडल और Sub-agent ख़ुद तर्क की ख़ामियाँ और जोखिम की सीमाएँ भरेंगे।
2. खोज में फैलाव, स्वीकृति में समेटना#
- खोज के समय पहले फैलाकर संभावनाएँ खोजें, फिर समेटें।
- स्वीकृति के समय दोबारा न फैलाएँ। "इसे और किन तरीकों से किया जा सकता है?" जैसे बिना सीमा वाले सवालों से बचें, उनसे सिर्फ़ ढीले-ढाले जवाब मिलते हैं।
- लक्ष्य का दायरा, बंदिशें और वस्तुनिष्ठ जाँच के टूल साफ़ लिखें (ख़ास टेस्ट स्क्रिप्ट, बिज़नेस मेट्रिक की सीमा), ताकि Multi-Agent टीम केंद्रित ढाँचे में स्ट्रेस टेस्ट करके उच्च गुणवत्ता का नतीजा दे सके।
नोट्स का सार#
- लक्ष्य-केंद्रित: संज्ञा की जगह क्रिया। समस्या हल करने वाला नतीजा सौंपें, सिर्फ़ खानापूरी वाला आउटपुट नहीं।
- खोज और समेटना: खोज में फैलाकर संभावनाएँ ढूँढें, स्वीकृति में सख़्ती से समेटकर सीमाएँ जाँचें।
- अमूर्तता पर फ़ोकस: मुख्य सवाल से शुरू करें और पूरे टास्क-फ़्लो को नए सिरे से गढ़ें।
- विशेषज्ञ गहराई: सिर्फ़ विशेषज्ञ के लहजे की नक़ल नहीं, बल्कि मॉडल को शीर्ष विशेषज्ञों के टूल्स और तरीकों से समस्या हल करने पर मजबूर करें।
मूल लेख: How to be more ambitious: A tutorial for humans with models (Felix Rieseberg, 2026-10-13)