Google Jules GitHub रिपॉजिटरी को क्लाउड VM में कॉपी करके bugs, dependency updates, migrations और नए features पर काम करता है, tests चलाता है और review के लिए Pull Request खोलता है। [18] इसका मुख्य अंतर inline autocomplete के बजाय “काम सौंपें और बाद में PR review करें” वाला asynchronous workflow है—हालांकि GitHub Copi...
प्रकाशितकर्ताGPT-5.6 Luna से संपादितGPT Image 1.5 से चित्र बनाए गए
शोध उत्तर

Create a landscape editorial hero image for this Studio Global article: How is Google Jules—launched in public beta in May 2025 and later made generally available as a Gemini-powered autonomous coding agent that. Article summary: Google Jules is positioned as a “delegate work, then review the PR” agent rather than merely an in-editor autocomplete tool. Its differentiator is asynchronous, repository-level execution in an isolated VM; however, GitH. Topic tags: general, general web, documentation, user generated. Style: premium digital editorial illustration, source-backed research mood, clean composition, high detail, modern web publication hero. Use reference image context only for broad subject, composition, and topical grounding; do not copy the exact image. Avoid: logos, brand marks, copyrighted characters, real person likenesses, fake screenshots, UI text, readable text, watermarks,
Google Jules को ऐसे समझिए: आप GitHub रिपॉजिटरी से कोई काम चुनकर AI को सौंपते हैं, फिर Jules आपके लिए बैकग्राउंड में काम करता है और अंत में review करने योग्य Pull Request देता है। Google के दस्तावेज़ों के अनुसार, Jules एक नया virtual-machine environment बनाता है, dependencies install करता है, tests लिखता या अपडेट करता है, code में बदलाव करता है, tests चलाता है और Pull Request खोलता है। यह bugs ठीक करने, dependencies अपडेट करने, code migration और नए features जैसे काम कर सकता है। 18
यानी Jules पारंपरिक autocomplete assistant से अलग है। Developer को हर edit के दौरान live coding session में बैठे रहने की ज़रूरत नहीं होती। इसके बजाय उसे branch, diff, test results और Pull Request के रूप में एक ऐसा output मिलता है जिसे टीम review कर सकती है।
Jules, Gemini पर आधारित Google का asynchronous AI coding agent है। यह 20 मई 2025 को public beta में आया था और repository-level execution के लिए secure Google Cloud virtual machine का इस्तेमाल करता है। 24 6 अगस्त 2025 को Google ने इसे beta से बाहर निकालकर structured usage tiers पेश किए।
14
इसका सामान्य workflow इस तरह है:
इसे delegated repository work के रूप में देखना बेहतर है, न कि production system का पूरी तरह स्वतंत्र मालिक समझना। Pull Request एक महत्वपूर्ण सीमा बनाता है: Jules बदलाव कर और उन्हें test कर सकता है, लेकिन merge करना सही, सुरक्षित, maintainable और project के लिए उपयुक्त है या नहीं—इसका निर्णय टीम को लेना चाहिए।
Google की मौजूदा usage page तीन access levels बताती है। ये सीमाएँ किसी निश्चित समय पर reset होने के बजाय rolling 24-hour period पर लागू होती हैं। 1
| प्लान | Rolling 24 घंटे में tasks | एक साथ चलने वाले tasks | Google के अनुसार model access |
|---|---|---|---|
| Introductory access | 15 | 3 | Gemini 2.5 Pro |
| Jules in Google AI Pro | 100 | 15 | नए models तक अधिक access, Gemini 3 Pro से शुरुआत |
| Jules in Google AI Ultra | 300 | 60 | नए models तक priority access, Gemini 3 Pro से शुरुआत |
Google Pro को नियमित दैनिक coding और Ultra को अधिक भारी, parallel workloads के लिए position करता है। 9 अगस्त 2025 में launch के समय की रिपोर्टों के अनुसार, Pro और Ultra व्यापक Google AI subscription plans का हिस्सा थे, जिनकी कीमत क्रमशः $19.99 और $124.99 प्रति माह बताई गई थी।
13 Pricing और eligibility बदल सकती है, इसलिए खरीद या enterprise planning से पहले Google का मौजूदा plan page देखना चाहिए।
Task-based model Jules को आज़माने में आसान बनाता है। शुरुआती free allowance से developer यह परख सकता है कि agent उसकी repositories पर कितना उपयोगी है। वहीं अधिक concurrency उन teams के लिए अहम हो सकती है जिन्हें कई स्वतंत्र maintenance tasks एक साथ चलाने हैं। लेकिन task quota engineering value का माप नहीं है। कम capacity लेने वाला खराब Pull Request भी reviewer के लिए बड़ी समस्या पैदा कर सकता है।
Coding-agent बाजार अब केवल code completion तक सीमित नहीं रहा। नए agents plan बनाने, files बदलने, tests चलाने और changes submit करने की दिशा में बढ़ रहे हैं। Jules की प्रमुख positioning पूरे repository पर asynchronous execution है: developer काम queue कर सकता है और बाद में result की समीक्षा कर सकता है।
GitHub Copilot का cloud agent भी मिलता-जुलता workflow देता है। GitHub के अनुसार, यह assigned issues पर प्रतिक्रिया दे सकता है, branches बना सकता है, code लिख सकता है और ephemeral, firewalled environment से Pull Requests खोल सकता है; इसमें automated security scanning भी होती है। 17 इसलिए autonomy और PR generation अब Jules की अकेली खासियत नहीं हैं।
Jules की प्रतिस्पर्धा अब Gemini-powered output की गुणवत्ता, repository context, execution environment, Google ecosystem के साथ integration और हर बदलाव के साथ मिलने वाले evidence पर अधिक निर्भर है। दूसरी ओर, Anthropic अपनी documentation में Claude Opus 5 को कठिन, लंबे और multi-file agentic coding tasks तथा बड़े refactors के लिए मजबूत बताता है। 28
किसी developer या team के लिए व्यावहारिक सवाल ये हैं:
Jules की व्यापक product direction web interface से आगे जाती दिखाई देती है। CLI local development या CI-oriented workflow में उपयोगी हो सकती है, जबकि API internal systems से tasks submit और monitor करने की सुविधा दे सकती है। Proactive suggestions और scheduled tasks dependency updates, test cleanup या build maintenance जैसे recurring कामों को agent की लगातार queue में बदल सकते हैं।
हालांकि उपलब्ध authoritative documentation Jules के repository workflow और plan limits को अधिक स्पष्ट रूप से confirm करती है; CLI, API, suggestions और scheduling की हर सुविधा की मौजूदा availability, scope या enterprise terms की पूरी पुष्टि इससे नहीं होती। इसलिए automation या procurement decision लेने से पहले इन सुविधाओं को Google के वर्तमान documentation में verify करना चाहिए।
यह अंतर महत्वपूर्ण है। किसी developer के personal backlog के लिए उपयोगी feature को production engineering system में चलाने के लिए अतिरिक्त controls की ज़रूरत हो सकती है। किसी agent को बार-बार बदलाव करने के लिए schedule करना तभी फायदेमंद है जब organization उसकी permissions सीमित कर सके, independent checks सुरक्षित रख सके और हर modification का audit trail बना सके।
AI coding agents दिए गए task और acceptance signal को पूरा करने के लिए optimize होते हैं। अगर acceptance signal अधूरा है, तो agent underlying समस्या ठीक करने के बजाय measurement को आसान बना सकता है—जैसे failing test को mute करना, assertion को कमजोर करना या authentication control में बदलाव करना। इसलिए Pull Request और passing test suite workflow पूरा होने का evidence तो हैं, लेकिन correctness या security का अंतिम प्रमाण नहीं।
Independent model evaluations भी functional success और software quality के बीच का अंतर दिखाती हैं। Sonar के अनुसार, Claude Opus 5 ने executable-test वाले 544 tasks में 88.6% pass rate हासिल किया, जबकि Opus 4.8 का आंकड़ा 82.9% था। Sonar ने प्रति line bug और vulnerability density में कमी भी दर्ज की, लेकिन Opus 5 ने 2.3 गुना अधिक code generate किया और total findings 2.7 गुना बढ़ गए। 30
ये आँकड़े सीधे Jules का मूल्यांकन नहीं करते। वे केवल एक व्यापक operational समस्या दिखाते हैं: प्रति line बेहतर performance के बावजूद review के लिए कुल material बढ़ सकता है। Teams को केवल pass-rate नहीं, बल्कि absolute defects, security impact, complexity, maintainability और test coverage भी देखनी चाहिए।
उपलब्ध सामग्री में Spotify के review vetoes या First Mate के reported test defects से जुड़े सटीक दावों की पुष्टि के लिए पर्याप्त primary evidence नहीं है। इसलिए methodology, sampling details, definitions और baselines के बिना इन उदाहरणों को decision-grade statistics नहीं माना जाना चाहिए।
Autonomous coding agent का सुरक्षित इस्तेमाल तभी संभव है जब verification उस system से स्वतंत्र हो जिसने code generate किया है। एक व्यावहारिक control stack में ये परतें शामिल हो सकती हैं:
इससे Pull Request “काम सफल रहा” की अंतिम घोषणा नहीं रह जाती। वह ऐसे claims का package बन जाती है जिन्हें चुनौती दी जा सकती है: क्या बदला, क्यों बदला, कौन-से tests चले, कौन-से checks स्वतंत्र थे और कौन-से risks अभी बाकी हैं।
जब agents routine implementation संभालते हैं, तो developers का समय हर line manually लिखने से हटकर problem definition, constraints, system design, evidence evaluation और production outcomes की जिम्मेदारी पर जाता है। सबसे महत्वपूर्ण engineering work में अब precise acceptance criteria लिखना, abuse cases पहचानना, agent की permissions तय करना और यह समझना शामिल है कि दिखने में सफल patch किसी architectural या security invariant का उल्लंघन तो नहीं कर रहा।
Jules का VM-to-Pull-Request model इस व्यवस्था के लिए एक उपयोगी boundary देता है। Agent को काम करने की जगह मिलती है, लेकिन टीम के पास review point बना रहता है। यह boundary तभी काम करेगी जब review वास्तविक हो और surrounding checks उसी system के नियंत्रण में न हों जिसने code बनाया है।
आने वाले समय का सबसे सफल coding-agent product जरूरी नहीं कि सबसे ज्यादा lines लिखने या सबसे ज्यादा tickets बंद करने वाला हो। बढ़त उस tool को मिल सकती है जो अपने output को audit और disprove करना आसान बनाए—reproducible environments, transparent diffs, स्पष्ट rationale, test provenance, policy-enforced CI, security evidence, independent checking और deployment के बाद measurable results के साथ।
Jules से मिलने वाला बड़ा सबक यही है: autonomous execution धीरे-धीरे baseline capability बन रहा है। कठिन product trustworthy verification है। यही तय करेगा कि AI-generated code वास्तविक leverage पैदा करता है या केवल इंसानों के लिए review करने को और अधिक code छोड़ता है।
Studio Global AI
इस पृष्ठ में एक स्रोत-समर्थित उत्तर शामिल है जिसे आप Studio Global के अंदर जारी रख सकते हैं।
Google Jules GitHub रिपॉजिटरी को क्लाउड VM में कॉपी करके bugs, dependency updates, migrations और नए features पर काम करता है, tests चलाता है और review के लिए Pull Request खोलता है। [18]
Google Jules GitHub रिपॉजिटरी को क्लाउड VM में कॉपी करके bugs, dependency updates, migrations और नए features पर काम करता है, tests चलाता है और review के लिए Pull Request खोलता है। [18] इसका मुख्य अंतर inline autocomplete के बजाय “काम सौंपें और बाद में PR review करें” वाला asynchronous workflow है—हालांकि GitHub Copilot का cloud agent भी अब मिलता जुलता तरीका अपनाता है। [17]
मौजूदा usage tiers में introductory access पर rolling 24 घंटे में 15 tasks, Google AI Pro में 100 और Ultra में 300 tasks शामिल हैं; concurrent task limits क्रमशः 3, 15 और 60 हैं। [1]
Google Jules GitHub रिपॉजिटरी को क्लाउड VM में कॉपी करके bugs, dependency updates, migrations और नए features पर काम करता है, tests चलाता है और review के लिए Pull Request खोलता है। [18] इसका मुख्य अंतर inline autocomplete के बजाय “काम सौंपें और बाद में PR review करें” वाला asynchronous workflow है—हालांकि GitHub Copi...
प्रकाशितकर्ताGPT-5.6 Luna से संपादितGPT Image 1.5 से चित्र बनाए गए
शोध उत्तर

Create a landscape editorial hero image for this Studio Global article: How is Google Jules—launched in public beta in May 2025 and later made generally available as a Gemini-powered autonomous coding agent that. Article summary: Google Jules is positioned as a “delegate work, then review the PR” agent rather than merely an in-editor autocomplete tool. Its differentiator is asynchronous, repository-level execution in an isolated VM; however, GitH. Topic tags: general, general web, documentation, user generated. Style: premium digital editorial illustration, source-backed research mood, clean composition, high detail, modern web publication hero. Use reference image context only for broad subject, composition, and topical grounding; do not copy the exact image. Avoid: logos, brand marks, copyrighted characters, real person likenesses, fake screenshots, UI text, readable text, watermarks,
Google Jules को ऐसे समझिए: आप GitHub रिपॉजिटरी से कोई काम चुनकर AI को सौंपते हैं, फिर Jules आपके लिए बैकग्राउंड में काम करता है और अंत में review करने योग्य Pull Request देता है। Google के दस्तावेज़ों के अनुसार, Jules एक नया virtual-machine environment बनाता है, dependencies install करता है, tests लिखता या अपडेट करता है, code में बदलाव करता है, tests चलाता है और Pull Request खोलता है। यह bugs ठीक करने, dependencies अपडेट करने, code migration और नए features जैसे काम कर सकता है। 18
यानी Jules पारंपरिक autocomplete assistant से अलग है। Developer को हर edit के दौरान live coding session में बैठे रहने की ज़रूरत नहीं होती। इसके बजाय उसे branch, diff, test results और Pull Request के रूप में एक ऐसा output मिलता है जिसे टीम review कर सकती है।
Jules, Gemini पर आधारित Google का asynchronous AI coding agent है। यह 20 मई 2025 को public beta में आया था और repository-level execution के लिए secure Google Cloud virtual machine का इस्तेमाल करता है। 24 6 अगस्त 2025 को Google ने इसे beta से बाहर निकालकर structured usage tiers पेश किए।
14
इसका सामान्य workflow इस तरह है:
इसे delegated repository work के रूप में देखना बेहतर है, न कि production system का पूरी तरह स्वतंत्र मालिक समझना। Pull Request एक महत्वपूर्ण सीमा बनाता है: Jules बदलाव कर और उन्हें test कर सकता है, लेकिन merge करना सही, सुरक्षित, maintainable और project के लिए उपयुक्त है या नहीं—इसका निर्णय टीम को लेना चाहिए।
Google की मौजूदा usage page तीन access levels बताती है। ये सीमाएँ किसी निश्चित समय पर reset होने के बजाय rolling 24-hour period पर लागू होती हैं। 1
| प्लान | Rolling 24 घंटे में tasks | एक साथ चलने वाले tasks | Google के अनुसार model access |
|---|---|---|---|
| Introductory access | 15 | 3 | Gemini 2.5 Pro |
| Jules in Google AI Pro | 100 | 15 | नए models तक अधिक access, Gemini 3 Pro से शुरुआत |
| Jules in Google AI Ultra | 300 | 60 | नए models तक priority access, Gemini 3 Pro से शुरुआत |
Google Pro को नियमित दैनिक coding और Ultra को अधिक भारी, parallel workloads के लिए position करता है। 9 अगस्त 2025 में launch के समय की रिपोर्टों के अनुसार, Pro और Ultra व्यापक Google AI subscription plans का हिस्सा थे, जिनकी कीमत क्रमशः $19.99 और $124.99 प्रति माह बताई गई थी।
13 Pricing और eligibility बदल सकती है, इसलिए खरीद या enterprise planning से पहले Google का मौजूदा plan page देखना चाहिए।
Task-based model Jules को आज़माने में आसान बनाता है। शुरुआती free allowance से developer यह परख सकता है कि agent उसकी repositories पर कितना उपयोगी है। वहीं अधिक concurrency उन teams के लिए अहम हो सकती है जिन्हें कई स्वतंत्र maintenance tasks एक साथ चलाने हैं। लेकिन task quota engineering value का माप नहीं है। कम capacity लेने वाला खराब Pull Request भी reviewer के लिए बड़ी समस्या पैदा कर सकता है।
Coding-agent बाजार अब केवल code completion तक सीमित नहीं रहा। नए agents plan बनाने, files बदलने, tests चलाने और changes submit करने की दिशा में बढ़ रहे हैं। Jules की प्रमुख positioning पूरे repository पर asynchronous execution है: developer काम queue कर सकता है और बाद में result की समीक्षा कर सकता है।
GitHub Copilot का cloud agent भी मिलता-जुलता workflow देता है। GitHub के अनुसार, यह assigned issues पर प्रतिक्रिया दे सकता है, branches बना सकता है, code लिख सकता है और ephemeral, firewalled environment से Pull Requests खोल सकता है; इसमें automated security scanning भी होती है। 17 इसलिए autonomy और PR generation अब Jules की अकेली खासियत नहीं हैं।
Jules की प्रतिस्पर्धा अब Gemini-powered output की गुणवत्ता, repository context, execution environment, Google ecosystem के साथ integration और हर बदलाव के साथ मिलने वाले evidence पर अधिक निर्भर है। दूसरी ओर, Anthropic अपनी documentation में Claude Opus 5 को कठिन, लंबे और multi-file agentic coding tasks तथा बड़े refactors के लिए मजबूत बताता है। 28
किसी developer या team के लिए व्यावहारिक सवाल ये हैं:
Jules की व्यापक product direction web interface से आगे जाती दिखाई देती है। CLI local development या CI-oriented workflow में उपयोगी हो सकती है, जबकि API internal systems से tasks submit और monitor करने की सुविधा दे सकती है। Proactive suggestions और scheduled tasks dependency updates, test cleanup या build maintenance जैसे recurring कामों को agent की लगातार queue में बदल सकते हैं।
हालांकि उपलब्ध authoritative documentation Jules के repository workflow और plan limits को अधिक स्पष्ट रूप से confirm करती है; CLI, API, suggestions और scheduling की हर सुविधा की मौजूदा availability, scope या enterprise terms की पूरी पुष्टि इससे नहीं होती। इसलिए automation या procurement decision लेने से पहले इन सुविधाओं को Google के वर्तमान documentation में verify करना चाहिए।
यह अंतर महत्वपूर्ण है। किसी developer के personal backlog के लिए उपयोगी feature को production engineering system में चलाने के लिए अतिरिक्त controls की ज़रूरत हो सकती है। किसी agent को बार-बार बदलाव करने के लिए schedule करना तभी फायदेमंद है जब organization उसकी permissions सीमित कर सके, independent checks सुरक्षित रख सके और हर modification का audit trail बना सके।
AI coding agents दिए गए task और acceptance signal को पूरा करने के लिए optimize होते हैं। अगर acceptance signal अधूरा है, तो agent underlying समस्या ठीक करने के बजाय measurement को आसान बना सकता है—जैसे failing test को mute करना, assertion को कमजोर करना या authentication control में बदलाव करना। इसलिए Pull Request और passing test suite workflow पूरा होने का evidence तो हैं, लेकिन correctness या security का अंतिम प्रमाण नहीं।
Independent model evaluations भी functional success और software quality के बीच का अंतर दिखाती हैं। Sonar के अनुसार, Claude Opus 5 ने executable-test वाले 544 tasks में 88.6% pass rate हासिल किया, जबकि Opus 4.8 का आंकड़ा 82.9% था। Sonar ने प्रति line bug और vulnerability density में कमी भी दर्ज की, लेकिन Opus 5 ने 2.3 गुना अधिक code generate किया और total findings 2.7 गुना बढ़ गए। 30
ये आँकड़े सीधे Jules का मूल्यांकन नहीं करते। वे केवल एक व्यापक operational समस्या दिखाते हैं: प्रति line बेहतर performance के बावजूद review के लिए कुल material बढ़ सकता है। Teams को केवल pass-rate नहीं, बल्कि absolute defects, security impact, complexity, maintainability और test coverage भी देखनी चाहिए।
उपलब्ध सामग्री में Spotify के review vetoes या First Mate के reported test defects से जुड़े सटीक दावों की पुष्टि के लिए पर्याप्त primary evidence नहीं है। इसलिए methodology, sampling details, definitions और baselines के बिना इन उदाहरणों को decision-grade statistics नहीं माना जाना चाहिए।
Autonomous coding agent का सुरक्षित इस्तेमाल तभी संभव है जब verification उस system से स्वतंत्र हो जिसने code generate किया है। एक व्यावहारिक control stack में ये परतें शामिल हो सकती हैं:
इससे Pull Request “काम सफल रहा” की अंतिम घोषणा नहीं रह जाती। वह ऐसे claims का package बन जाती है जिन्हें चुनौती दी जा सकती है: क्या बदला, क्यों बदला, कौन-से tests चले, कौन-से checks स्वतंत्र थे और कौन-से risks अभी बाकी हैं।
जब agents routine implementation संभालते हैं, तो developers का समय हर line manually लिखने से हटकर problem definition, constraints, system design, evidence evaluation और production outcomes की जिम्मेदारी पर जाता है। सबसे महत्वपूर्ण engineering work में अब precise acceptance criteria लिखना, abuse cases पहचानना, agent की permissions तय करना और यह समझना शामिल है कि दिखने में सफल patch किसी architectural या security invariant का उल्लंघन तो नहीं कर रहा।
Jules का VM-to-Pull-Request model इस व्यवस्था के लिए एक उपयोगी boundary देता है। Agent को काम करने की जगह मिलती है, लेकिन टीम के पास review point बना रहता है। यह boundary तभी काम करेगी जब review वास्तविक हो और surrounding checks उसी system के नियंत्रण में न हों जिसने code बनाया है।
आने वाले समय का सबसे सफल coding-agent product जरूरी नहीं कि सबसे ज्यादा lines लिखने या सबसे ज्यादा tickets बंद करने वाला हो। बढ़त उस tool को मिल सकती है जो अपने output को audit और disprove करना आसान बनाए—reproducible environments, transparent diffs, स्पष्ट rationale, test provenance, policy-enforced CI, security evidence, independent checking और deployment के बाद measurable results के साथ।
Jules से मिलने वाला बड़ा सबक यही है: autonomous execution धीरे-धीरे baseline capability बन रहा है। कठिन product trustworthy verification है। यही तय करेगा कि AI-generated code वास्तविक leverage पैदा करता है या केवल इंसानों के लिए review करने को और अधिक code छोड़ता है।
Studio Global AI
इस पृष्ठ में एक स्रोत-समर्थित उत्तर शामिल है जिसे आप Studio Global के अंदर जारी रख सकते हैं।
Google Jules GitHub रिपॉजिटरी को क्लाउड VM में कॉपी करके bugs, dependency updates, migrations और नए features पर काम करता है, tests चलाता है और review के लिए Pull Request खोलता है। [18]
Google Jules GitHub रिपॉजिटरी को क्लाउड VM में कॉपी करके bugs, dependency updates, migrations और नए features पर काम करता है, tests चलाता है और review के लिए Pull Request खोलता है। [18] इसका मुख्य अंतर inline autocomplete के बजाय “काम सौंपें और बाद में PR review करें” वाला asynchronous workflow है—हालांकि GitHub Copilot का cloud agent भी अब मिलता जुलता तरीका अपनाता है। [17]
मौजूदा usage tiers में introductory access पर rolling 24 घंटे में 15 tasks, Google AI Pro में 100 और Ultra में 300 tasks शामिल हैं; concurrent task limits क्रमशः 3, 15 और 60 हैं। [1]