Claude Code और Android का सीएलआई की मदद से एजेंटिक इंजीनियरिंग

नमस्ते, मैं बेन हूं. मैं Android डेवलपर रिलेशंस टीम का सदस्य हूं.

मैं स्टीवन हूँ, प्रॉडक्ट मैनेजर.

आज हम Claude Code और Android का सीएलआई की मदद से, एजेंटिक तरीके से ऐप्लिकेशन बनाने के बारे में बात करेंगे.

इसलिए, मुझे लगता है कि डेवलपर के तौर पर हमारी भूमिका थोड़ी बदल रही है और चीज़ें बहुत तेज़ी से आगे बढ़ रही हैं. इतनी तेज़ी से कि ईमानदारी से कहें, तो इस बातचीत का कॉन्टेंट शायद पहले ही पुराना हो चुका है. खास तौर पर, अगर इसे ऑनलाइन देखा जा रहा है.

इसलिए, हमने जो कुछ भी लिखा और जो जानकारी पेश की उसमें हमने आगे की सोच रखी. हालांकि, आज जो डेमो दिखाए गए हैं वे असलियत पर आधारित हैं. इसलिए, अब उन पर भरोसा किया जा सकता है.

दूसरी बात यह है कि हमने इस बातचीत के लिए Claude Code का इस्तेमाल किया है. हालांकि, यह जानकारी किसी एजेंट पर निर्भर नहीं करती.

यह एक तरह की मानसिकता है. इसलिए, ऐप्लिकेशन बनाते समय आपको जो भी इस्तेमाल करना पसंद हो उस पर यह लागू होना चाहिए.

इसलिए, हम चाहते हैं कि आप एक ऐसी दुनिया के बारे में सोचना शुरू करें जहां आपको ऑटोनॉमस एजेंट की टीमों को मैनेज करना है. साथ ही, उन्हें सफलता के लिए कैसे सेट अप करना है.

जब वे किसी सुविधा या ऐसी ही किसी चीज़ को लागू नहीं कर पाते, तो हार मानकर यह कहने के बजाय कि "ओह, एआई अभी ऐसा नहीं कर सकता," हमें पीछे हटकर सोचना चाहिए कि कौनसी जानकारी मौजूद नहीं थी. साथ ही, हमें इसे उसी तरह ट्रीट करना चाहिए जैसे हम आज बग को ट्रीट करते हैं.

अगर आपने Claude Code, Codex, Antigravity जैसे एआई एजेंट के लिए फ़्रेमवर्क बनाने वाली टीमों के बारे में कुछ पढ़ा है, तो आपको पता चलेगा कि उनकी टीमें इन फ़्रेमवर्क को इसी तरह डेवलप करती हैं. अगर हम इन्हें आने वाले समय की झलक के तौर पर देखें, तो शायद हम सभी इसी दिशा में आगे बढ़ रहे हैं.

इसलिए, Android डेवलपर के तौर पर, कुछ नया बनाने के लिए इससे बेहतर समय शायद ही कभी रहा हो. हालांकि, अगर आप मेरी तरह हैं, तो आपको यह जानने में मुश्किल हो सकती है कि आपको किस चीज़ पर फ़ोकस करना चाहिए.

डेवलपर के तौर पर, हमें ऐसे टूल और वर्कफ़्लो की ज़रूरत होती है जो इंटेलिजेंस के साथ काम कर सकें. इससे, जब कोई नया मॉडल नई सुविधाओं के साथ आता है, तो हमारी मेहनत बेकार नहीं जाती.

हम चाहते हैं कि मॉडल में होने वाले हर सुधार से, हमारे एजेंट के लिए ज़्यादा इंटेलिजेंट वर्कफ़्लो तैयार हों. इससे हमारे उपयोगकर्ताओं को बेहतर नतीजे मिल पाएंगे.

आज हम चार विषयों पर बात करेंगे.

सबसे पहले, हम यह बताएंगे कि एजेंट को सफल बनाने के लिए, उन्हें सही एनवायरमेंट में सेट अप करना क्यों ज़रूरी है.

इसके बाद, हम आपको कॉन्टेक्स्ट के बारे में जानकारी देंगे. साथ ही, इसे मैनेज करने का सबसे सही तरीका बताएंगे.

इसके बाद, हम एजेंट के साथ काम करने वाले Android डेवलपर के लिए उपलब्ध कुछ बेहतरीन टूल के बारे में बात करेंगे. आखिर में, हम आपके एजेंटिक वर्कफ़्लो में लूप जोड़ने के बारे में बात करेंगे.

चलिए, शुरू करते हैं.

इसलिए, एनवायरमेंट.

लेकिन इसका असल में क्या मतलब है?

जैसा कि मैंने कहा, हम एक ऐसा स्पेस बनाने की कोशिश कर रहे हैं जहां हमारा एजेंट सफल हो सके. इसके लिए, आपको वहां बैठकर उसे लगातार प्रॉम्प्ट देने और उसे ट्रैक पर वापस लाने की ज़रूरत नहीं है. ऐसा करने पर, आपको एक साथ कई एजेंट चलाने की सुविधा मिलती है. इससे आपको असल में फ़ायदा मिलता है. ऐसा तब होता है, जब आपके पास एजेंट की ऐसी टीमें हों जो आपके लिए काम कर रही हों.

हालांकि, यह सिर्फ़ कोड के ऐक्सेस तक सीमित नहीं है.

उन्हें सटीक दस्तावेज़ों का ऐक्सेस चाहिए. इनमें प्रोजेक्ट की खास जानकारी और उस प्रोजेक्ट में काम करने के नियम शामिल हैं.

यह तो ज़ाहिर सी बात है.

लोग कुछ और चीज़ें भी कर रहे हैं. जैसे, वे अपने एजेंट को टीम चैट स्पेस से जोड़ रहे हैं. ऐसा सिर्फ़ एजेंट को शुरू करने के लिए नहीं, बल्कि यह बताने के लिए किया जा रहा है कि फ़ैसले कैसे लिए गए. इससे उन्हें उस सुविधा के बारे में पता चलता है जिसके लिए उन्हें काम दिया गया है. ऐसा इसलिए, क्योंकि डेवलपर के तौर पर, समस्याओं को हल करते समय इस तरह की जानकारी का इस्तेमाल किया जाता है. इसलिए, यह आपके एजेंट के लिए भी मददगार हो सकता है.

साथ ही, फ़ैसले का पिछला इतिहास और पुल के अनुरोध भी शामिल हैं.

उन्हें आपके पुल अनुरोधों पर मिलने वाली टिप्पणियां दिखनी चाहिए. साथ ही, उन्हें उन चीज़ों के बारे में पता होना चाहिए जिनके लिए उन्हें पिंग किया जाता है. इसके बाद, वे काम कर पाएंगे और समस्या को ठीक कर पाएंगे.

साथ ही, किसी डिवाइस या एम्युलेटर के ऐक्सेस के बिना, Android कोड लिखने की उम्मीद नहीं की जा सकती. इसलिए, आपको अपने एजेंट से भी ऐसा करने की उम्मीद नहीं करनी चाहिए.

मुझे पता है कि ये शानदार लगते हैं और इनसे कुछ भी किया जा सकता है. हालांकि, एम्युलेटर से काफ़ी मदद मिलती है.

प्रोफ़ाइलर के साथ भी ऐसा ही है.

अगर आपको उनसे परफ़ॉर्मेंस पर काम कराना है, तो उनके पास प्रोफ़ाइल बनाने की सुविधा होनी चाहिए. इसके लिए, उनके पास असली डिवाइस का ऐक्सेस होना चाहिए.

आपका एजेंट, आपके ऐप्लिकेशन में इस्तेमाल होने वाली किसी भी बैक-एंड सेवा से भी बात कर सकता है.

ऐसे में, Android का सीएलआई आपकी मदद कर सकता है.

अगर आपने इसके बारे में नहीं सुना है, तो बता दें कि इसके बारे में'टूल में नया क्या है' सेशन में भी बताया गया था. Android का सीएलआई, इंटरफ़ेस के लिए हमारा नया सीएलआई है. यह Android के अलग-अलग टूल के साथ काम करता है.

यह अपने-आप में कोई एआई प्रॉडक्ट नहीं है. यह सिर्फ़ एक सीएलआई यानी कमांड-लाइन इंटरफ़ेस है.

इसलिए, यह आपको Android SDK Manager, एम्युलेटर शुरू करने की सुविधा, और कई अन्य चीज़ों का ऐक्सेस देता है.

साथ ही, यह Crashlytics जैसे टूल और बैक एंड से भी कनेक्ट होता है.

यह आपके इस्तेमाल किए जा रहे किसी भी एजेंट के साथ काम करता है. यह आपके शेल स्पेस में मौजूद रहता है.

तो, हां.

इसे इस लिंक पर जाकर इंस्टॉल किया जा सकता है. हालांकि, मुझे लगता है कि इसे इस्तेमाल करके देखना ज़्यादा आसान है.

ठीक है।

इसलिए, एजेंट को सफलता के लिए सेट अप करना क्यों ज़रूरी है, यह बताने के बजाय, हम इस सिद्धांत को Sideline नाम के प्रोडक्शन ऐप्लिकेशन पर लागू करना चाहते थे.

Sideline, टेनिस खिलाड़ियों के लिए एक Android ऐप्लिकेशन है. यह उन्हें बॉल, खिलाड़ी, और कोर्ट की जगह की रीयल-टाइम जानकारी देता है.

यह वीडियो रीप्ले के ज़रिए, ऑफ़लाइन कोचिंग फ़ीडबैक देता है. साथ ही, सबसे तेज़ स्पीड, तय की गई दूरी, और सबसे लंबी रैली जैसी चीज़ों के लिए फ़िटनेस डेटा उपलब्ध कराता है.

यह सब, Android डिवाइस पर सीधे तौर पर काम करने वाले कस्टम TF Lite मॉडल की मदद से होता है.

सबसे पहले, हम यह कहना चाहते हैं कि हम उन समस्याओं को हल नहीं कर सकते जिनके बारे में हमें पता ही नहीं है.

इसलिए, हमने Android का सीएलआई का इस्तेमाल करके, अपने डेवलपमेंट एनवायरमेंट में Firebase Crashlytics को जोड़ा. इससे हमें ऐसी समस्याओं का पता चला जिनके बारे में हमें जानकारी ही नहीं थी.

पहली समस्या यह थी कि Pixel 11 Pro Fold डिवाइस पर, ऐप्लिकेशन काम नहीं कर रहा था या ANR वाली गड़बड़ी हो रही थी. हालांकि, एम्युलेटर में यह गड़बड़ी नहीं दिख रही थी.

इसलिए, Android का सीएलआई में Android डिवाइस स्ट्रीमिंग की सुविधा काम करती है.

जब हमने एजेंट को इस समस्या को ठीक करने के लिए कहा, तो उसने उस डिवाइस से कनेक्शन बनाया जिस पर एएनआर की समस्या आ रही थी. यह मेरे लिए काफ़ी मददगार था, क्योंकि उस समय मेरे पास Pixel 11 Pro Fold नहीं था, जिससे मैं यह पुष्टि कर सकूं कि समस्या ठीक हुई है या नहीं.

इसलिए, एजेंट को उस डिवाइस का ऐक्सेस देकर जिसकी ज़रूरत उसे समस्या को ठीक करने के लिए थी, हम आखिरकार यह तय कर पाए कि क्या-क्या किया जा सकता है.

समय बचाने के लिए, मैंने सभी एक्सपेरिमेंट पहले ही कर लिए हैं और उनकी खास जानकारी यहां दी है.

ज़्यादा जानकारी में जाए बिना, हम आपको बता दें कि हमें Android 17 के साथ अफ़िनिटी कॉल की समस्या आ रही थी.

यह दो लाइन का एक छोटा सा फ़िक्स था, जो मुझे सही लगा.

setenv("KMP_AFFINITY", "disabled", 1);
setenv("KMP_INIT_AT_FORK", "false", 1);

इसलिए, मैंने पुल का अनुरोध किया, उसे मर्ज किया, और Play पर सबमिट किए गए नए बिल्ड के साथ अपडेट किया.

इसलिए, अगर हमने कोडिंग एनवायरमेंट को उन क्षमताओं के साथ सेट अप नहीं किया होता जिनकी ज़रूरत उसे सफल होने के लिए थी, तो हम असल समस्या की पहचान नहीं कर पाते. साथ ही, हम समस्या को ठीक करने के तरीके की पुष्टि भी नहीं कर पाते.

इसलिए, 1.0 बिल्ड के साथ, आपको दिखेगा कि समस्या हल हो गई है.

हालांकि, नई समस्याएं सामने आई हैं और हम उन पर बाद में काम करेंगे.

ठीक है।

अगला मॉड्यूल: कॉन्टेक्स्ट.

करीब डेढ़ या दो साल पहले, जो कि बहुत ज़्यादा समय नहीं है, लेकिन एआई के क्षेत्र में यह एक लंबा समय है, बड़ी से बड़ी कॉन्टेक्स्ट विंडो बनाने की होड़ मची हुई थी. इसके पीछे यह थ्योरी थी कि हम मॉडल को जितना ज़्यादा डेटा देंगे, हमें उतने ही बेहतर नतीजे मिलेंगे. हमने कई अजीब चीज़ें भी कीं. जैसे, हमने प्रॉम्प्ट में developer.android.com को शामिल करने की कोशिश की, लेकिन इससे कोई फ़ायदा नहीं हुआ.

हालांकि, कॉन्टेक्स्ट विंडो की क्षमताएं अब ज़्यादा नहीं बढ़ रही हैं, लेकिन मॉडल की क्षमताएं अब भी बढ़ रही हैं.

तो यह है Android Bench 1.0.

Android Bench हमारा मानदंड है, जो Android कोड लिखने की एआई की क्षमता को मापता है.

इसमें दिए गए टास्क असली जैसे हों.

ये ऐसी चीज़ें हैं जिन पर आप काम करते हैं. हम देख सकते हैं कि कॉन्टेक्स्ट विंडो 10 लाख के मार्क पर रुकी हुई हैं, लेकिन मॉडल की क्षमता लगातार बढ़ रही है.

हालांकि, बजट तय होता है और आपको इसे ज़रूरी चीज़ों के लिए बचाना होता है.

आपको उसमें ऐसी चीज़ें नहीं चाहिए जो उस समस्या को हल करने में मदद न करें जिस पर आप काम कर रहे हैं.

साथ ही, एआई मॉडल के लिए कई फ़्रेमवर्क, आपको 10 लाख टोकन वाली पूरी कॉन्टेक्स्ट विंडो नहीं दिखाते. इसकी वजह यह है कि उन्हें लगता है कि इसका कोई फ़ायदा नहीं है.

ऐसा करने से, नतीजे और खराब हो जाते हैं.

एक सही रेंज होती है, जो मॉडल के हिसाब से बदलती रहती है. अगर आपकी बातचीत 1,50,000 टोकन तक सीमित है, तो आपको मॉडल की पूरी क्षमता का फ़ायदा मिलेगा. साथ ही, कॉन्टेक्स्ट रॉट की समस्या भी नहीं होगी.

हालांकि, कॉन्टेक्स्ट का मतलब सिर्फ़ यह नहीं है कि आपने क्या टाइप किया है.

[
  {
    "role": "system",
    "content": "You are an expert Android engineering agent..."
  },
  {
    "role": "workspace_context",
    "content": { "project_root": "/workspace/android-app", "build_system": "Gradle (Kotlin DSL)", "target_sdk": 35 }
  },
  {
    "role": "available_tools",
    "content": [ { "name": "read_file" }, { "name": "edit_file" }, { "name": "bash" }, { "name": "skill_android_cli" } ]
  },
  {
    "role": "user",
    "content": "ProfileViewModelTest is failing when loading errors. Fix the ViewModel and verify with unit tests."
  },
  {
    "role": "assistant",
    "tool_calls": [ { "name": "read_file", "arguments": { "path": "app/src/main/.../ProfileViewModel.kt" } } ]
  },
  {
    "role": "tool",
    "content": "class ProfileViewModel(...) : ViewModel() { ... // full file contents + Gradle output appended here }"
  }
]

इसके पर्दे के पीछे काफ़ी कुछ ऐसा होता है जो आपको नहीं दिखता.

यह कई हिस्सों से मिलकर बना है.

पहला है, सिस्टम को निर्देश देना.

सिस्टम से जुड़े निर्देश, आपके एजेंट ने दिए हैं.

यह एक तरह का प्रॉम्प्ट है, जो एजेंट को बताता है कि उसे कैसे काम करना चाहिए और उसका व्यवहार कैसा होना चाहिए.

इसके अलावा, वर्कस्पेस की जानकारी भी शामिल होती है. जैसे, आपकी मौजूदा वर्किंग डायरेक्ट्री, आपके पास कौनसे एसडीके हैं, और इंस्टॉल की गई कौनसी स्किल हैं. हम इस बारे में थोड़ी देर में बात करेंगे. साथ ही, एमसीपी टूल और आपके एजेंट से मिले टूल भी शामिल होते हैं.

मॉडल को यह पता होना चाहिए कि वह उन्हें कॉल कर सकता है. इसलिए, इसमें कॉन्टेक्स्ट की ज़रूरत होती है.

हालाँकि, सबसे बड़ा बदलाव यह है कि अब हर प्रॉम्प्ट और हर नए मैसेज के साथ, मैसेज और टूल कॉल का पूरा इतिहास एजेंट को भेजा जाता है.

इससे, खास तौर पर Gradle के साथ, बहुत ज़्यादा समय लग सकता है.

जैसा कि हम सभी जानते हैं, Gradle लॉग बहुत लंबे होते हैं. इनमें बहुत ज़्यादा जानकारी होती है.

इनमें से ज़्यादातर की ज़रूरत नहीं होती.

इसलिए, इस बात का ध्यान रखने के लिए यहां एक सलाह दी गई है.

Gradle को शांत मोड में चलाया जा सकता है.

./gradlew assembleDebug --quiet

इसके अलावा, एआई मॉडल के लिए बड़े फ़्रेमवर्क, आपके लिए इसे छोटा कर देते हैं.

इसलिए, Claude Code और Android Studio, हम पूरा Gradle लॉग नहीं भेज रहे हैं.

हालांकि, अगर किसी मिनिमल एजेंट का इस्तेमाल किया जा रहा है, तो वह सारा डेटा मॉडल को भेज देता है. ऐसा इसलिए, क्योंकि उसका मानना है कि मॉडल को सब पता है. इसलिए, mini-SWE-agent पूरा Gradle लॉग भेज देता है. इससे बहुत जल्दी बहुत ज़्यादा खर्च हो सकता है.

लेकिन हम इस 1,50,000 की सीमा के अंदर कैसे रहें?

इसके लिए, वर्कफ़्लो का इस्तेमाल करना ज़रूरी है.

इसके लिए, कई तरह के वर्कफ़्लो उपलब्ध हैं.

मुझे मैट पोकॉक का वीडियो सबसे ज़्यादा पसंद है. उन्होंने इन सेशन को मैनेज करने के लिए कई तरह की स्किल बताई हैं.

इसलिए, इसकी शुरुआत "grill-me" नाम की स्किल से होती है.

जब आप कोई नया प्रोजेक्ट या किसी प्रोजेक्ट में कोई नई सुविधा शुरू करें, तो इस स्किल को चलाएं. इससे आपका एजेंट आपसे कई सवाल पूछेगा.

इसलिए, हो सकता है कि आप कहें, "grill-me.

मुझे अपने ऐप्लिकेशन में एक नया टाइम अलार्म मैनेजर बनाना है."

इसके बाद, यह आपसे सवाल पूछना शुरू करेगा. जैसे, हमें इसे किसमें लागू करना चाहिए, यह किससे जुड़ा है.

इससे समस्या को लेकर आपके मन में जो भी भ्रम होता है वह दूर हो जाता है. साथ ही, समस्या को हल करने में मदद मिलती है.

इसके बाद, हम अगली स्किल का इस्तेमाल करते हैं. यह स्किल, एक बड़ा स्पेक दस्तावेज़ लिखने जैसा है.

इसके बाद, एक अन्य स्किल उस ट्रांसक्रिप्ट को समस्याओं में बांटती है. इसके बाद, हम उन समस्याओं को आपके पसंदीदा इश्यू मैनेजर में दर्ज करते हैं.

इसके बाद, हर समस्या को करीब 1,50,000 की विंडो में फ़िट किया जाना चाहिए.

इसके बाद, आपको एक समस्या चुननी होगी. इसके लिए, टर्मिनल या आईडीई में से अपनी पसंद का कोई भी विकल्प चुनें. इसके बाद, कोड बनाएं और उसकी जांच करें. आखिर में, हम कॉन्टेक्स्ट को मिटा देते हैं. इससे बातचीत का कोई इतिहास नहीं बचता और हम विंडो के अंदर ही रहते हैं.

ठीक है।

चलिए अब AGENTS.md के बारे में बात करते हैं.

AGENTS.md में जाकर, अपने एजेंट को अतिरिक्त जानकारी दी जा सकती है. यह जानकारी, इस प्रोजेक्ट या आपके पूरे वर्कस्पेस में मौजूद किसी भी समस्या पर लागू होती है. हालांकि, ऐसा तब ही होगा, जब आपने यह विकल्प चुना हो.

हालाँकि, सिस्टम प्रॉम्प्ट हर प्रॉम्प्ट के साथ दिया जाता है. इसलिए, इसमें सिर्फ़ ऐसी चीज़ें शामिल करें जो हर समय लागू होती हों.

इसलिए, आर्किटेक्चर और मॉड्यूल के नियम जैसी चीज़ें काम करती हैं.

ये ऐसी चीज़ें हैं जिनके बारे में आपके एजेंट को शायद ही पता हो. खास तौर पर, तब जब क्लोज़्ड सोर्स ऐप्लिकेशन पर काम किया जा रहा हो.

हालांकि, इन्हें समझना बहुत ज़रूरी है, ताकि आपको शुरुआत में ही यह पता चल सके कि यह सुविधा किस तरह काम करती है.

इसलिए, यूज़र इंटरफ़ेस (यूआई) कॉम्पोनेंट जैसी चीज़ों को डिज़ाइन सिस्टम मॉड्यूल में रखा जा सकता है. इसके अलावा, कोड रिव्यू के दौरान होने वाली आम गलतियों को भी इसमें रखा जा सकता है. इसके अलावा, ऐसी सामान्य चीज़ें भी इसमें रखी जा सकती हैं जिन्हें आपको बार-बार टाइप करना पड़ता है.

# AGENTS.md

- UI components belong in :core:designsystem

- Never use java.util.Date;
  always use kotlinx.datetime

## General guidance
- Avoid changing public API signatures. Anything under an `internal` directory
  is not part of the public API and may change freely.
- The SDK code is written for Java 8.

इसलिए, इस प्रोजेक्ट में हम kotlinx.datetime जैसी चीज़ों का इस्तेमाल करना पसंद करते हैं.

मैं आपको ऐसे सबसे सही तरीके बताना चाहता था जो हमेशा काम आएं. हालांकि, हकीकत यह है कि हर नए मॉडल के साथ ये तरीके बदलते रहते हैं.

ज़्यादा संदर्भ देने पर, अलग-अलग मॉडल अलग-अलग तरह से काम करते हैं.

उदाहरण के लिए, Opus 4.6 के दिनों में, बड़े अक्षरों में "ऐसा कभी न करें" लिखना बहुत आम था.

इसके बाद, जब Opus 5 रिलीज़ हुआ, तो Anthropic ने एक बयान जारी किया. इसमें कहा गया, "दरअसल, अब कैपिटल लेटर उतने अच्छे से काम नहीं करते.

सिर्फ़ अंग्रेज़ी के छोटे अक्षरों का इस्तेमाल करें."

मेरा मतलब है कि आपको इस पर नज़र रखनी होगी.

हालांकि, कुछ बातें हमेशा से एक जैसी रही हैं. जैसे, वीडियो को छोटा रखना.

इसलिए, इसे 250 लाइनों से कम रखें.

अगला तरीका थोड़ा अलग है, क्योंकि मुझे पता है कि बहुत से लोगों को यह करना पसंद है. हालांकि, इस साल फ़रवरी में एक स्टडी आई थी, जिसमें बताया गया था कि अगर एजेंट को अपने AGENTS.md में बदलाव करने की अनुमति दी जाती है, तो उसकी परफ़ॉर्मेंस में करीब 2 से 3% की गिरावट आती है. हालांकि, यह कोई बड़ी बात नहीं है.

हालांकि, सबसे अहम बात यह थी कि इससे लागत में 20% की बढ़ोतरी हुई.

इसलिए, हमें परफ़ॉर्मेंस में थोड़ी गिरावट देखने को मिली और हमारी लागत बढ़ गई. ऐसा इसलिए हुआ, क्योंकि हमने एजेंट को अपना AGENTS.md लिखने की अनुमति दी थी.

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

इसलिए, हमने Sideline ऐप्लिकेशन के लिए जो AGENTS.md बनाया है, वह यहां दिया गया है.

यहां मैं दो चीज़ों के बारे में बताना चाहता हूं.

पहला, साफ़ तौर पर तय किए गए आर्किटेक्चर से टोकन और कॉन्टेक्स्ट की लंबाई को बचाया जा सकता है.

इससे आपके एजेंट को आपके कोड बेस को बार-बार देखने और ज़्यादा से ज़्यादा अनुमान लगाने की ज़रूरत नहीं पड़ती.

इससे एआई को साफ़ तौर पर निर्देश मिलते हैं कि उसे क्या करना है.

दूसरी बात, क्लोज़्ड सोर्स ऐप्लिकेशन के बारे में है.

ज़ाहिर है कि अगर आपका कोड क्लोज़्ड सोर्स है, तो कोई भी एजेंट आपके कोड बेस पर एलएलएम को ट्रेन नहीं कर पाएगा.

इसलिए, ऐसे मामलों में यह ज़रूरी है कि आप ज़्यादा समय दें. साथ ही, अपने AGENTS.md को लगातार साफ़ करने, उसकी समीक्षा करने, उसे बेहतर बनाने, और उसमें सुधार करने में समय लगाएं. इससे आपको लंबे समय में फ़ायदा मिलेगा.

अगर हमें AGENTS.md में सब कुछ नहीं डालना चाहिए, तो हम एजेंट या मॉडल के व्यवहार को कैसे बदलें?

पहला है हुक. हुक उन चीज़ों के लिए बहुत अच्छे होते हैं जिन्हें लोग AGENTS.md में डालते हैं. जैसे, कोड लिखने के बाद हमेशा लिंटर चलाएं.

// settings.json

"hooks": {
  "Stop": [{
    "command": "./gradlew lintDebug"
  }]
}

यह एक हुक हो सकता है.

हुक क्या है? आपका एजेंट इन सभी इवेंट को एक्सपोज़ कर रहा है, जिनकी सदस्यता ली जा सकती है. साथ ही, ऐसे इवेंट भी हैं जिनके बारे में आप सोच सकते हैं. हालांकि, मुख्य इवेंट हैं: सेशन शुरू करना, सेशन रोकना, फ़ाइलें पढ़ना, और लिखना.

इसलिए, अपने AGENTS.md के सबसे नीचे, "हमेशा लिंटर चलाएं" या "यह कहने से पहले कि आपका काम हो गया है, हमेशा मेरा टेस्ट सुइट चलाएं" लिखने के बजाय, आपके पास एक स्टॉप हुक होता है. यह डिटरमिनिस्टिक स्क्रिप्ट चला सकता है. इससे एआई के रैंडम तरीके से काम करने की संभावना कम हो जाती है.

इसके अलावा, अगर आपके पास ऐसी फ़ाइलें हैं जिन्हें आपको अपने एजेंट को पढ़ने या लिखने की अनुमति नहीं देनी है, तो आपके पास कुछ सीक्रेट फ़ाइलें होंगी. आपको उन्हें सर्वर पर नहीं भेजना है या AGENTS.md, आपको अपने एजेंट को उनमें लिखने की अनुमति नहीं देनी है, तो आपके पास इसके लिए एक हुक हो सकता है.

इसलिए, अगर आपके पास रीड या राइट हुक है, तो आपको वह फ़ाइल पास कर दी जाती है जिसमें बदलाव करने की कोशिश की जा रही है. इसके बाद, आपके पास यह जवाब देने का विकल्प होता है कि "नहीं, ऐसा नहीं किया जा सकता."

यह डिटरमिनिज़्म जोड़ने का एक तरीका है.

अगला सेक्शन, स्किल का है.

अब AGENTS.md को हुक में बदलने के लिए, कुछ स्किल की ज़रूरत होती है.

यह बिलकुल अलग बात है.

हालांकि, स्किल का इस्तेमाल करके, सिर्फ़ काम का संदर्भ जोड़ा जा सकता है.

इसलिए, AGENTS.md का इस्तेमाल ऐसे कॉन्टेंट के लिए किया जाता है जो हमेशा काम का होता है.

स्किल का इस्तेमाल, कुछ खास स्थितियों में किया जाता है. मुख्य रूप से, दस्तावेज़ों के लिए.

स्किल के तीन हिस्से होते हैं: नाम, ब्यौरा, और बॉडी. ब्यौरा सबसे अहम हिस्सा होता है. इसमें ज़्यादा से ज़्यादा 1,024 वर्ण हो सकते हैं.

---

name: android-cli
description: >
  Loaded into context (≤1024 chars)
---
# Skill Body

साथ ही, मुख्य हिस्सा बहुत बड़ा हो सकता है. इसमें अन्य स्क्रिप्ट भी शामिल हो सकती हैं. ऐसा होना आम बात है.

स्किल की मदद से कई काम किए जा सकते हैं.

आइए, एक उदाहरण देखते हैं.

यह Android के सीएलआई की जानकारी है.

आपको यह सब पढ़ने की ज़रूरत नहीं है.

बस यह जान लें कि यह एक छोटा विवरण है जो बताता है कि Android का सीएलआई कब प्रासंगिक है.

इसके बाद, यह बॉडी है.

यह बहुत बड़ा है, इसलिए हम इसे हर समय लोड नहीं करना चाहते, है न?

हम इसे सिर्फ़ तब लोड करना चाहते हैं, जब हम Android का सीएलआई का इस्तेमाल करने की कोशिश कर रहे हों. स्किल की मदद से, हम ऐसा कर पाते हैं.

हालांकि, यह ज़रूरी है कि आप सोच-समझकर स्किल इंस्टॉल करें.

हम ऑनलाइन दिखने वाले उन रिपॉज़िटरी को आंखें बंद करके इंस्टॉल नहीं करना चाहते जिनमें एजेंटिक इंजीनियरिंग की सैकड़ों स्किल मौजूद हैं.

पहला, यह सुरक्षा के लिहाज़ से काफ़ी जोखिम भरा है.

आपको नहीं पता कि उन स्किल में क्या है. ऐसा हो सकता है कि वे आपके एजेंट को कुछ भी करने के लिए कहें.

हमारे पास Android से जुड़ी स्किल का एक सेट है. हमने उनकी जांच की है और वे ऐसा नहीं कहते.

दूसरी बात, 1,000 वर्णों वाले 100 ब्यौरे का मतलब है कि आपने कोडिंग शुरू करने से पहले ही 1,00,000 वर्ण जोड़ दिए हैं.

इसलिए, आप पहले से ही उस विंडो पर नज़र बनाए हुए हैं.

इसलिए, Android की स्किल के लिए, हमारा सुझाव है कि Android का सीएलआई की बुनियादी स्किल इंस्टॉल करें. इसके बाद, Android का सीएलआई उपलब्ध स्किल खोज सकता है और आपके ऐप्लिकेशन के लिए सही स्किल इंस्टॉल कर सकता है.

> android init

✓ Installed base skill: android-cli

# Audit & add skills only when needed:
> android skills find compose
> android skills add edge-to-edge

अगर आपको देखना है, तो यह जानना अच्छा है कि कौनसी स्किल उपलब्ध हैं. आपके पास मैन्युअल तरीके से उन स्किल को जोड़ने का विकल्प है जो आपके प्रोजेक्ट के लिए सही हैं. जैसे, Compose स्किल, एज-टू-एज स्किल. ये स्किल काफ़ी यूनिवर्सल हैं.

बेशक, स्किल का ऑडिट करने के लिए भी स्किल की ज़रूरत होती है.

इसलिए, Claude Code में /skill-doctor है. यह आपको बताएगा कि आपने ऐसी कौनसी स्किल शामिल की हैं जो कभी चालू नहीं होतीं. इससे आपको पता चलेगा कि आपने एक हज़ार वर्णों के ब्यौरे को बर्बाद कर दिया है.

अगर Claude Code का इस्तेमाल नहीं किया जा रहा है, तो ज़्यादातर एआई मॉडल के लिए फ़्रेमवर्क में, आंकड़ों या ऑडिट की स्क्रीन होती है. इससे भी यही काम किया जा सकता है.

इसलिए, Android का सीएलआई का लिंक फिर से दिया गया है.

हालांकि, इसमें स्किल की सूची वाला कमांड होता है. इसके बाद, मान लें कि आपके प्रोजेक्ट में Navigation 3 है.

android skills list
android skills add navigation-3

Navigation 3 एक नई लाइब्रेरी है. इसलिए, इस पर अभी ज़्यादा ट्रेनिंग नहीं हुई है. हालांकि, Navigation 3 स्किल को जोड़ा जा सकता है.

हम अक्सर, ओह, माफ़ करें.

अगला है एमसीपी.

हालांकि, हमसे अक्सर पूछा जाता है कि हमने Android का सीएलआई को एमसीपी सर्वर के बजाय सीएलआई क्यों बनाया?

हम एआई और माउस के आने से पहले से ही सीएलआई बना रहे हैं. ये तेज़ और कंपोज़ेबल होते हैं. साथ ही, ये आपके शेल सेशन में स्थानीय तौर पर चलते हैं. इसलिए, इन्हें चलाने के लिए कोई शुल्क नहीं देना पड़ता.

साथ ही, सॉफ़्टवेयर इंजीनियरिंग के मामले में, Terminal Bench जैसे मानदंड सबसे बड़े मानदंड बन गए हैं. इसलिए, मॉडल बनाने वाली कंपनियां, टर्मिनल के इस्तेमाल को लेकर काफ़ी आक्रामक तरीके से आगे बढ़ रही हैं. इसलिए, आजकल वे सीएलआई का इस्तेमाल करने में काफ़ी माहिर हो गई हैं.

हालांकि, इसका यह मतलब नहीं है कि एमसीपी का कोई फ़ायदा नहीं है.

एमसीपी सर्वर, उन बाहरी सेवाओं के लिए बहुत अच्छे होते हैं जिनका इस्तेमाल पहले से किया जा रहा है. खास तौर पर, अगर वे पहले से ही कोई एमसीपी सेवा होस्ट कर रही हैं.

इससे सीधे तौर पर कनेक्ट किया जा सकता है. साथ ही, अपने एजेंट को ज़्यादा कॉन्टेक्स्ट देने के लिए, इसे इंस्टॉल करने की ज़रूरत नहीं पड़ती.

GitHub, Figma, और Slack जैसे प्लैटफ़ॉर्म अब एमसीपी सर्वर उपलब्ध करा रहे हैं.

इसके बाद, जो चीज़ें हम हमेशा शेल में चलाते हैं वे शेल में ही रह सकती हैं. जैसे, Android का सीएलआई के ज़रिए Android कमांड. हालांकि, Perfetto और Gradle को लोकल तौर पर रखना ही सही है, जहां उनके पास उन सभी चीज़ों का ऐक्सेस होता है जिनका इस्तेमाल डेवलपमेंट के लिए किया जाता है.

मैं परफ़ॉर्मेंस पर काम करता था.

मैं हमेशा कहता था कि Perfetto एक ऐसा टूल है जिसकी मदद से परफ़ॉर्मेंस से जुड़ी किसी भी समस्या को हल किया जा सकता है.

हालांकि, इसे सीखना काफ़ी मुश्किल था. जैसा कि हमने राहुल की पिछली बातचीत में देखा.

आइए, देखते हैं कि एआई की मदद से परफ़ॉर्मेंस को कैसे बेहतर बनाया जा सकता है.

धन्यवाद, बेन.

इसलिए, हमारे ऐप्लिकेशन Sideline को काम करने के लिए, 30 फ़्रेम प्रति सेकंड और रीयल टाइम में चलना ज़रूरी है.

जैसा कि आप इस Pixel 10 Pro Fold पर देख सकते हैं, हमें सिर्फ़ 20 से 22 फ़्रेम प्रति सेकंड मिल रहे हैं.

ड्रॉप किए गए ये फ़्रेम एक समस्या बन जाएंगे, क्योंकि इसका मतलब है कि ऐप्लिकेशन, विज्ञापन के मुताबिक काम नहीं करेगा. इसलिए, हमें इसे ठीक करना होगा.

Android के सीएलआई में, Android प्रोफ़ाइलर के कमांड मौजूद हैं.

जब हम इसे अपने कोडिंग एजेंट में जोड़ते हैं और इसे 30 फ़्रेम प्रति सेकंड की इस ज़रूरत को पूरा करने का निर्देश देते हैं, तो दो दिलचस्प चीज़ें होती हैं.

पहला तरीका यह है कि Android प्रोफ़ाइलर कमांड का इस्तेमाल करके समस्या को ठीक किया जाए.

इसने अटैच किए गए Pixel 10 Pro Fold डिवाइस पर सिस्टम ट्रेस रिकॉर्ड किए. इससे पता चला कि इसके एआई थ्रेड, डिवाइस के सबसे धीमे कोर पर चल रहे थे.

दूसरा यह कि इसने Android दस्तावेज़ों की खोज का इस्तेमाल किया. दिलचस्प बात यह है कि हमने इसे ऐसा करने के लिए साफ़ तौर पर नहीं कहा था. इसने परफ़ॉर्मेंस हिंट एपीआई के लिए आधिकारिक दिशा-निर्देशों को खोजा.

एजेंट ने सिस्टम शेड्यूल को ऑप्टिमाइज़ करना सीखा. ऐसा करके, वह 30 फ़्रेम प्रति सेकंड की ज़रूरी शर्तों को पूरा कर पाया.

इसका मतलब है कि समस्या को ठीक करने के लिए, दिशा-निर्देशों का पालन किया गया.

Android का सीएलआई की मदद से, एजेंट को हुक किया जा सकता है. इससे आपको सही टूल ढूंढने में मदद मिलती है. भले ही, आपको उस टूल के बारे में जानकारी न हो. इससे आपको अपना काम पूरा करने में मदद मिलती है.

इसलिए, इसे चलाने के बाद, आपको दिखेगा कि Sideline, उपयोगकर्ताओं की 30 फ़्रेम प्रति सेकंड की ज़रूरत को पूरा करता है. साथ ही, अब यह Pixel 10 Pro Fold पर काम करता है.

ठीक है।

अब हम इन सभी को लूप के साथ जोड़ेंगे.

मुझे यकीन है कि हम सभी ने ऐसा किया है. आपने अपने एजेंट से कोई बड़ा बदलाव करने के लिए कहा और उसने वापस आकर कहा कि काम हो गया.

अगर इसे इंस्टॉल किया जा रहा है और ऐप्लिकेशन पर मैन्युअल तरीके से क्लिक किया जा रहा है और बग टाइप किए जा रहे हैं, तो हमें ऐसा करना बंद करना होगा.

हमें अपने एजेंट के लिए QA टेस्टर की तरह काम करना बंद करना होगा. साथ ही, हमें पहले से यह तय करना होगा कि हमारे लिए 'काम पूरा हो गया' का क्या मतलब है.

यहां एक उदाहरण दिया गया है.

हम पूरे प्रोजेक्ट को Nav3 पर माइग्रेट करना चाहते हैं. इसके बाद, एजेंट कुछ समय के लिए चला जाता है. इसमें कुछ समय लगता है, लेकिन वह पूरे भरोसे के साथ वापस आता है और कहता है, "माइग्रेशन पूरा हो गया.

मैं सबसे अच्छा हूं."

लेकिन फिर, ज़ाहिर है कि फ़ोन को घुमाने पर ऐप्लिकेशन क्रैश हो जाता है, यह सभी स्लाइड ट्रांज़िशन को मिस कर देता है, और अपनी Gradle फ़ाइल को साफ़ नहीं करता.

यह कुछ-कुछ उस दुनिया की तरह है जिसमें हम अभी हैं.

हमें ऐसा नहीं करना चाहिए, लेकिन मौजूदा समय में ऐसा करना ज़रूरी है.

इसलिए, हमें पहले ही यह तय कर लेना चाहिए था कि हमें क्या चाहिए. इससे एजेंट तब तक लूप में रहता, जब तक कि वह सभी ज़रूरी शर्तें पूरी नहीं कर लेता.

इसे ही पुष्टि करने का लूप कहते हैं.

हमारे पास इस बात का डेटा है कि यह तरीका कितना असरदार है.

यह Android Bench 2.0 है. यह हमारे एआई बेंचमार्क का नया वर्शन है, जिसके बारे में मैंने बातचीत की शुरुआत में बताया था.

फ़िलहाल, पास होने की दर करीब 40% है.

ये टास्क वाकई मुश्किल हैं. ये बहुत बड़े और असल ज़िंदगी से जुड़े हैं. इनमें से एक टास्क, Nav2 से Nav3 पर माइग्रेट करना है. ये ऐसे टास्क हैं जो फ़िलहाल आपके प्रोजेक्ट में किए जा रहे हैं.

अगर हम Fable 5.1 को लें, तो इसका पास रेट 22% है. यह रेट इसे सिर्फ़ नैचुरल प्रॉम्प्ट सेट अप के साथ मिलता है, जैसे कि "Nav2 को Nav3 पर माइग्रेट करें."

हालांकि, अगर हम इसे पहले से ही एक ऐसा टेस्ट सुइट देते हैं जो फ़ेल हो रहा है, तो इससे इसे जवाब नहीं मिलते. हम इसे यह नहीं बता रहे हैं कि Nav3 पर कैसे माइग्रेट करना है. हम इसे सिर्फ़ एक ऐसा टेस्ट सुइट दे रहे हैं जो पहले से ही फ़ेल हो रहा है और इन सभी चीज़ों के पूरा होने पर पास हो जाएगा. पूरे मानदंड पर इसके पास होने की दर 90% तक बढ़ जाती है.

इससे हमें पता चलता है कि ये मॉडल अब Android पर हमारे सोचे गए ज़्यादातर टास्क पूरे कर सकते हैं. हालांकि, इन्हें हमेशा यह नहीं पता होता कि "पूरा हो गया" का क्या मतलब है.

इसलिए, आपको पहले से ही ऐसा टेस्ट सुइट लिखने की ज़रूरत नहीं है जो फ़ेल हो जाए.

पुष्टि करने के लूप, प्रॉम्प्ट जोड़ने जितने आसान हो सकते हैं.

मान लें कि यूज़र इंटरफ़ेस (यूआई) पर काम किया जा रहा है. ऐसे में, इससे Compose की झलक रेंडर करने और यह पक्का करने के लिए कहा जा सकता है कि वह Figma की खास जानकारी से मेल खाती हो. साथ ही, नतीजे दिखाने के लिए कहा जा सकता है.

ऐसा लगता है कि यह सुविधा तब वाकई काम करती है, जब Gemini से नतीजे दिखाने और यह साबित करने के लिए कहा जाए कि काम पूरा हो गया है. सिर्फ़ "मैंने काम पूरा कर लिया है" जैसा टेक्स्ट जवाब स्वीकार करने के बजाय, Gemini से नतीजे दिखाने के लिए कहें.

अगर आपको कारोबारी नियम पर काम करना है, तो Gemini से यूनिट टेस्ट चलाने के लिए कहा जा सकता है. इसके अलावा, अगर आपको क्रैश की समस्या ठीक करनी है, तो Gemini से यह पुष्टि करने के लिए कहा जा सकता है कि क्रैश की समस्या ठीक हो गई है. इसके लिए, Gemini उस असली डिवाइस का इस्तेमाल करेगा जिस पर क्रैश की समस्या हुई थी. इसके लिए, वह रिमोट टेस्ट लैब का इस्तेमाल करेगा.

Claude Code में एक ऐसी सुविधा मौजूद है जो पुष्टि करने वाले लूप बनाने में आपकी मदद करती है.

इसलिए, इसे ज़रूर देखें.

अगर Android Studio में काम करते समय, अपना एजेंट इस्तेमाल किया जा रहा है, तो Android Studio कई ऐसे टूल उपलब्ध कराता है जिनका इस्तेमाल करके, अपने काम के हिसाब से लूप बनाए जा सकते हैं.

इसलिए, लिंटर की तरह ही, इसे तब तक न रुकने के लिए कहा जा सकता है, जब तक कि लिंट की सभी गड़बड़ियां ठीक न हो जाएं. इसके अलावा, मुझे जो सुविधा सबसे ज़्यादा पसंद है वह है जर्नी. इसमें, इसे अपनी जर्नी चलाने के लिए कहा जा सकता है और यह पक्का किया जा सकता है कि वे अब भी काम कर रही हैं.

इसके अलावा, अगर आपने कोई जर्नी लिखी है, तो उसे चलाने के लिए कहा जा सकता है. जर्नी लिखना काफ़ी आसान होता है. ये सिर्फ़ उस सुविधा के बारे में प्रॉम्प्ट होते हैं जिस पर काम किया जा रहा है. साथ ही, यह पक्का किया जा सकता है कि जर्नी पूरी होने से पहले, वह पास हो जाए.

हालांकि, जर्नी को चलने में कुछ समय लगता है.

इसके अलावा, पुष्टि करने के लूप के लेवल को टियर किया जा सकता है.

इसलिए, हम इसे सबसे पहले यह पक्का करने के लिए कह सकते हैं कि यूनिट टेस्ट और Compose की झलकें सही तरीके से रेंडर हो रही हैं.

इसके बाद, जब यह टेस्ट पास हो जाए, तो कृपया हमारे कनेक्ट किए गए टेस्ट और Android Journeys चलाएं. जब यह टेस्ट भी पास हो जाए, तब ही रिमोट डिवाइस टेस्ट लैब जैसा पूरा टेस्ट सुइट चलाएं. इसमें घंटों लग सकते हैं.

अगर आपने अतिरिक्त जानकारी दी है, तो हमें पता चलता है कि यह हर रन पर हर चरण को पूरा करने की कोशिश करने के बजाय, हर टियर के हिसाब से लूप करता है.

क्योंकि मॉडल काफ़ी कॉन्फ़िडेंट होते हैं.

इसलिए, उन्हें हमेशा लगता है कि उनका ऐप्लिकेशन पूरी तरह से तैयार है और वह पहली बार में ही सभी टेस्ट पास कर लेगा.

आइए, Sideline में इस पर एक नज़र डालते हैं.

इसलिए, चलिए इस आइडिया को अपने Sideline ऐप्लिकेशन पर लागू करते हैं. इसके लिए, हम एक नई सुविधा जोड़ते हैं. खास तौर पर, एक्सआर ग्लास के लिए, जो जल्द ही आने वाले हैं.

फ़िलहाल, हमारे पास हार्डवेयर नहीं है. इसलिए, हम XR एम्युलेटर का इस्तेमाल करेंगे और अपने कोडिंग एजेंट को निर्देश देंगे कि वह Sideline को नए फ़ॉर्म फ़ैक्टर के लिए एक्सटेंड करे.

ऐसा करने पर, हम अपने एजेंट से खास तौर पर कहेंगे कि वे जेवीएम टेस्ट, Compose की झलक वाले टेस्ट, और एम्युलेटर टेस्ट को इसी क्रम में चलाएं.

हर लूप को पिछले लूप के आधार पर बनाया जाता है.

ऐसा करने पर, हमें सबसे पहले यह पता चलता है कि पहले और दूसरे लूप के बीच, जेवीएम टेस्ट का इस्तेमाल करके, Compose की झलक की छह स्थितियों को तय किया जाता है.

ज़ाहिर है कि किसी एम्युलेटर को कॉल नहीं किया गया था, इसलिए यह बहुत तेज़ी से चलता है.

इसी तरह, दूसरे और तीसरे लूप के बीच, लंबी स्ट्रिंग जैसी समस्याओं का पता लगाया जाता है और उन्हें ठीक किया जाता है. इसके लिए, एम्युलेटर को चलाने की ज़रूरत भी नहीं पड़ती.

आखिर में, एम्युलेटर लूप चलने के बाद, उसे ऐसी गड़बड़ियां मिलती हैं जिन्हें जेवीएम टेस्ट और Compose की झलकें ठीक नहीं कर सकीं.

हालांकि, हर लूप के साथ हम अपने ऐप्लिकेशन को और बेहतर बनाते हैं. हम सबसे तेज़, लेकिन कम असरदार लूप को पहले चलाना चाहते हैं. इसके बाद, सबसे धीमे, लेकिन सबसे असरदार लूप को चलाना चाहते हैं.

इसका नतीजा यह रहा.

इसमें दिखाया गया है कि चश्मे में अब स्विंग का टाइप और रैकेट से टकराने के बाद बॉल की स्पीड दिखती है. इससे टेनिस खेलते समय, बॉल से नज़र हटाए बिना ही रीयल टाइम में अपने गेमप्ले के बारे में सुझाव/राय दी जा सकती है.

मैंने पहले बताया था कि हम Crashlytics से जुड़ी उन दो समस्याओं के बारे में बात करेंगे जो पहले आई थीं.

हमने पहले ही पुष्टि कर ली है कि यह तरीका काम करता है. इसलिए, हम Claude Code में /schedule निर्देश का इस्तेमाल करके, इसे लूप में चला सकते हैं. साथ ही, हम अपनी पसंद के मुताबिक कोई भी फ़्रीक्वेंसी सेट कर सकते हैं. इससे अब हमारे पास एक ऐसा ऐप्लिकेशन है जो खुद ही गड़बड़ियां ठीक कर सकता है. यह सभी गड़बड़ियों को ठीक करता है और पुष्टि करता है कि वे ठीक हो गई हैं. इसके बाद, यह उन्हें हमारे इंजीनियर को पुल का अनुरोध के तौर पर भेजता है, ताकि वे उन्हें देख सकें और मर्ज कर सकें.

चलिए.

आज के लिए बस इतना ही.

अगर आपको एक अहम बात याद रखनी है, तो वह यह है कि हमें इस दुनिया के बारे में सोचना शुरू करना होगा. यहां हम अपने एजेंट के लिए एक ऐसा माहौल बना रहे हैं जहां वे सफल हो सकें. साथ ही, हम इसे उसी तरह ट्रीट कर रहे हैं जैसे हम आज सॉफ़्टवेयर डेवलपमेंट और गड़बड़ियों को ट्रीट करते हैं.

इस तरह, हम एक साथ कई एजेंट इस्तेमाल कर सकते हैं.

आपको इस विषय पर ऑनलाइन बहुत सारी सलाह मिलेंगी. इनमें से कई सलाह एक-दूसरे से अलग होंगी.

तेज़ी से बदलती इस दुनिया में, यह एक सच्चाई है.

इसलिए, सबसे अच्छा तरीका यह है कि आप अपने प्रोजेक्ट के लिए खुद ही इवैल लिखें.

इसके बाद, जब कोई नई सलाह या नया मॉडल सामने आता है, तो उसे मेज़र किया जा सकता है और देखा जा सकता है कि उससे आपको मदद मिलती है या नहीं.

साथ ही, हर काम के लिए एक स्किल मौजूद है.

Claude Code में इवैल बनाने के लिए, एक स्किल उपलब्ध है.

/claude-api build-eval

हमारा सुझाव है कि आप इसे ज़रूर देखें.

आज मैंने Android Bench के बारे में बात की.

Android Bench, हमारा इवैलुएशन है.

इससे हम यह मेज़र करते हैं कि चीज़ें बेहतर हो रही हैं या नहीं.

अगर आपको इस बेंचमार्क को बनाने के दौरान मिले हमारे अनुभवों के बारे में जानना है, ताकि आप वे गलतियां न करें जो हमसे हुईं, तो Android Bench के बारे में बातचीत देखें.

इसमें दो पैनल भी हैं.

एक अमेरिका में है और एक लंदन में.

ये दोनों वीडियो ऑनलाइन अपलोड किए जाएंगे. इनमें कम्यूनिटी में इस तरह के कॉन्सेप्ट को लागू करने के बारे में बताया गया है.

इसलिए, हमने Android Dev कम्यूनिटी के सदस्यों को पैनल में शामिल किया है. वे बताएंगे कि वे अपने काम में इसे कैसे लागू कर रहे हैं.

हमें आपके सुझाव, शिकायत या राय का भी इंतज़ार है.

हम यह जानना चाहते हैं कि हम जो चीज़ें बना रहे हैं उनसे आपको वाकई मदद मिल रही है या नहीं.

इसलिए, कृपया सर्वे में दिए गए सवालों के जवाब दें.

मैं इसे स्क्रीन पर ही रहने देता हूं.

और हां.

सुनने के लिए धन्यवाद.

धन्यवाद.