Developer Experience | The .NET Blog

Visual Studio के अंदर pull requests review करना ठीक उसी तरह का friction reduction है जो मुझे पसंद है

Emiliano Montesdeoca — Sun, 21 Jun 2026 00:00:00 +0000

यह पोस्ट स्वचालित रूप से अनुवादित है। मूल लेख के लिए यहाँ क्लिक करें.

Browser ने code review workflow से बहुत ज़्यादा हिस्सा बहुत लंबे समय से छीन रखा है।

इसलिए मुझे बहुत खुशी है कि Visual Studio IDE के अंदर end to end pull request review की दिशा में और आगे बढ़ रहा है।

यह उन features में से एक है जो शायद बड़े headlines न बनाएं, लेकिन daily development को वाकई बेहतर बना सकते हैं।

मुख्य value सरल है: context switching कम

जब आपका review loop आंशिक रूप से IDE में और आंशिक रूप से browser में रहता है, friction बढ़ती जाती है:

PR को कहीं और खोलो
changes को एक tool में देखो
deeper investigation के लिए solution पर लौटो
comment या approve करने के लिए फिर switch करो

यह catastrophic नहीं है। बस inefficient है।

अगर Visual Studio आपको उसी working environment से PR खोलने, inspect करने, comment करने, approve करने, और merge करने दे, तो यह एक असली productivity win है।

“review without checkout” विकल्प खास तौर पर अच्छा है

एक चीज़ जो मुझे विशेष रूप से पसंद है, वह है PR branch को checkout किए बिना review करने की सुविधा।

यह छोटा लग सकता है, लेकिन यह इनके लिए बिल्कुल सही है:

quick review passes
interrupt-driven feedback requests
अपनी current branch और local state को intact रखना

यही वह flexibility है जिसकी अच्छे code review tools को ज़रूरत होती है।

मेरी राय

यह कोई revolutionary feature नहीं है।

यह उससे बेहतर है: एक practical feature।

जो teams अपना ज़्यादातर दिन Visual Studio में बिताती हैं, उनके लिए PR review support को tight करना workflow breaks कम करता है और inspection से action तक का रास्ता smooth बनाता है।

मेरे हिसाब से यह एक worthwhile improvement है।

मूल लेख: Visual Studio छोड़े बिना pull requests की समीक्षा करें

Agent Harnesses इसलिए मायने रखते हैं क्योंकि प्रॉम्प्ट ही पर्याप्त नहीं हैं

Emiliano Montesdeoca — Sat, 20 Jun 2026 00:00:00 +0000

एजेंट डेवलपमेंट में सबसे आसान गलतियों में से एक यह सोचना है कि प्रॉम्प्ट ही उत्पाद है।

ऐसा नहीं है।

Microsoft Agent Framework टीम का नया एजेंट हार्नेस और क्लॉ वॉकथ्रू इसलिए मूल्यवान है क्योंकि यह उस हिस्से पर ध्यान केंद्रित रखता है जो वास्तव में निर्धारित करता है कि एजेंट उपयोग योग्य लगता है या नहीं: मॉडल के चारों ओर का रनटाइम शेल।

इसमें शामिल है:

टूल्स
प्लानिंग
सेशन स्टेट
मेमोरी
एक्ज़ीक्यूशन मोड
पुनरावृत्ति के लिए एक उपयोग योग्य कंसोल या इंटरफ़ेस

यह वह जगह है जहाँ एजेंट चतुर डेमो होना बंद करके सॉफ्टवेयर जैसा महसूस होने लगते हैं।

हार्नेस पैटर्न एक व्यावहारिक है

मुझे यहाँ जो पसंद है वह यह है कि यह विचार कितना सुलभ है।

आप एक चैट क्लाइंट से शुरू करते हैं।

फिर आप इसे निर्देशों और टूल्स के साथ एक हार्नेस में लपेटते हैं।

फिर आप इसे एक शेल के माध्यम से चलाते हैं जो प्लानिंग, टूडू, सेशन और स्ट्रीमिंग इंटरैक्शन का समर्थन करता है।

यह एक स्वस्थ पैटर्न है क्योंकि यह चिंताओं को स्पष्ट रूप से अलग करता है:

मॉडल तर्क को संभालता है
हार्नेस रनटाइम व्यवहार को संभालता है
ऐप तय करता है कि कौन से टूल और अनुभव मायने रखते हैं

यह .NET डेवलपर्स के सिस्टम बनाने के तरीके के साथ अच्छी तरह फिट बैठता है

हार्नेस विचार .NET मानसिकता से भी अच्छी तरह मेल खाता है।

हम通常 बेहतर करते हैं जब रनटाइम व्यवहार स्पष्ट और रचना योग्य होता है। मिडलवेयर, पाइपलाइन, विकल्प, प्रोवाइडर और एडॉप्टर सभी इस दुनिया में स्वाभाविक लगते हैं।

यही कारण है कि मुझे लगता है कि Agent Framework के .NET डेवलपर्स के साथ उतरने की अच्छी संभावना है। यह सभी को एक जादुई एब्स्ट्रैक्शन में मजबूर नहीं कर रहा है। यह आपको संरचित रनटाइम टुकड़े दे रहा है जिन्हें आप एक साथ जोड़ सकते हैं।

मेरी राय

इस पोस्ट का सबसे उपयोगी हिस्सा यह अनुस्मारक है कि एजेंटों को एक अच्छे मॉडल और एक चतुर इंस्ट्रक्शन स्ट्रिंग से अधिक की आवश्यकता होती है।

उन्हें एक रनटाइम शेल चाहिए जो उन्हें संरचना, मेमोरी, टूल एक्सेस, प्लानिंग और एक कार्यशील डेवलपर लूप दे।

यही हार्नेस आपको देता है।

और ईमानदारी से, यही कारण है कि यह पैटर्न ध्यान देने योग्य है।

मूल पोस्ट: Meet your agent harness and claw

VS Code 13.4 में Aspire सभी सही तरीकों से डेवलपर लूप को कसता है

Emiliano Montesdeoca — Tue, 16 Jun 2026 00:00:00 +0000

VS Code 13.4 में Aspire सिर्फ एक फीचर अपडेट नहीं है। यह बेहतर डिबगिंग, संसाधन दृश्यता, पैनल एकीकरण और TypeScript AppHost समर्थन के साथ दैनिक विकास लूप में एक वास्तविक सुधार है।

Visual Studio में नया Plan agent एक बहुत वास्तविक AI workflow समस्या को हल करता है

Emiliano Montesdeoca — Thu, 11 Jun 2026 00:00:00 +0000

यह पोस्ट स्वचालित रूप से अनुवादित है। मूल लेख के लिए यहाँ क्लिक करें.

AI coding workflow में सबसे frustrating चीज़ों में से एक तब होती है जब implementation बहुत जल्दी शुरू हो जाती है।

कई बार code तकनीकी रूप से ठीक भी होता है, लेकिन वह समस्या के उस version को हल कर रहा होता है जो आपके मन में था ही नहीं।

आप refactor चाहते थे। उसने rewrite शुरू कर दी। आप scoped improvement चाहते थे। उसने project का आधा हिस्सा छू लिया। आप options पर बात करना चाहते थे। वह सीधे file changes पर चला गया।

इसीलिए Visual Studio में नया Plan agent एक बहुत उपयोगी addition है।

यह एक असली workflow problem हल करता है, सिर्फ cosmetic problem नहीं

मूल पोस्ट एक बहुत familiar situation का वर्णन करती है: “Code गलत नहीं है… बस वह नहीं है जो आप चाहते थे.”

यह line बहुत बढ़िया है।

क्योंकि AI-assisted development की कमजोरी यह नहीं है कि model code बना सकता है या नहीं। असली सवाल यह है कि क्या workflow implementation शुरू होने से पहले काम के intended shape पर सहमत होने के लिए पर्याप्त space देता है।

यह खास तौर पर इन मामलों में मायने रखता है:

बड़े features
unfamiliar codebases
non-trivial refactors
architecture-sensitive changes
ऐसा काम जिसे editing शुरू करने से पहले team review चाहिए

ऐसी स्थितियों में सीधे implementation में कूदना अक्सर गलत कदम होता है।

जब task real हो, तब planning overhead नहीं होती

मुझे लगता है teams कभी-कभी यह कम आँकती हैं कि बहुत जल्दी implementation शुरू करने से वे कितना समय खो देती हैं।

अगर agent:

गलत files छू ले
गलत approach चुन ले
कोई key constraint मिस कर दे
कोई जरूरी edge case ignore कर दे

तो “fast” start अंततः धीमा workflow बन जाता है।

इसलिए मुझे यह feature पसंद है।

यह जगह बनाता है:

स्पष्ट करने वाले सवालों के लिए
प्लान का मसौदा तैयार करने के लिए
प्लान को सीधे संपादित करने के लिए
कोड में बदलाव शुरू होने से पहले प्लान साझा करने के लिए

यह bureaucracy नहीं है। अक्सर यह बस good engineering होती है।

Markdown plan file एक smart choice है

एक detail जो मुझे खास तौर पर पसंद है, वह यह है कि हर plan .copilot/plans/plan-{title}.md में save होता है।

इससे planning step tangible बन जाता है।

यानी plan chat transcript के अंदर बंद नहीं रहता। वह ऐसी चीज़ बन जाता है जिसे आप:

review कर सकते हैं
edit कर सकते हैं
mentally version कर सकते हैं
teammates के साथ discuss कर सकते हैं
implementation में अधिक deliberate तरीके से hand off कर सकते हैं

इससे feature temporary preamble से कहीं ज़्यादा serious लगता है।

यहीं से AI workflows team process का सम्मान करना शुरू करते हैं

मुझे लगता है यह इस बात के सबसे strong संकेतों में से एक है कि ये tools mature हो रहे हैं।

सबसे अच्छे AI developer workflows वे नहीं होते जो हर intermediate step हटा दें। वे होते हैं जो सही intermediate steps को बेहतर करें।

और planning उन्हीं steps में से एक है।

अगर plan मजबूत है, तो implementation आसान हो जाती है। अगर plan कमजोर है, तो implementation noisy हो जाती है।

यह feature इसे सीधे स्वीकार करता है।

मेरी राय

यह सिर्फ AI nicety नहीं है।

यह workflow improvement है।

और real features और refactors के लिए, यह ठीक वही सुधार है जो unnecessary churn, review noise, और “यह मेरा मतलब नहीं था” वाले rework को बहुत कम कर सकता है।

मुझे लगता है आगे चलकर और भी agent experiences को ऐसी किसी चीज़ की ज़रूरत होगी।

Visual Studio वहाँ जल्दी पहुँच गया, और वह भी उपयोगी तरीके से।

मूल लेख: बिल्ड करने से पहले plan करें: Visual Studio में Plan agent का परिचय

आपका dev loop tribal knowledge से भरा हुआ है - और Aspire इसका सही जवाब देता है

Emiliano Montesdeoca — Mon, 01 Jun 2026 00:00:00 +0000

यह पोस्ट स्वचालित रूप से अनुवादित है। मूल लेख के लिए यहाँ क्लिक करें.

यह Aspire की सबसे महत्वपूर्ण posts में से एक हो सकती है, यह समझने के लिए कि यह product क्यों मायने रखता है।

इसलिए नहीं कि यह कोई बड़ा नया feature घोषित करती है।

बल्कि इसलिए कि यह उस समस्या का नाम देती है जो लगभग हर engineering team ने महसूस की है, और हर team ने उसे अच्छे से describe नहीं किया है:

dev loop tribal knowledge से भरा हुआ है।

यह phrase इसलिए असर करती है क्योंकि यह सच है।

समस्या tools की कमी नहीं है

source article का core argument बहुत अच्छा है: teams के पास अक्सर infrastructure, scripts, dashboards, या commands की कमी नहीं होती।

उन्हें जो कमी होती है, वह एक coherent model की होती है जो application के आसपास मौजूद hidden operational knowledge को कुछ visible और repeatable चीज़ में बदल दे।

कई apps की असली architecture यहाँ रहती है:

shell history
बिखरी हुई scripts
README के टुकड़े
Slack threads
वह एक senior engineer जिसे operations का क्रम पता होता है

यह humans के लिए sustainable dev loop नहीं है।

और agents के लिए तो बिल्कुल भी नहीं।

वह quote जो मुझे लगता है पूरे post को पकड़ती है

source article में एक line है जो पूरे point को बहुत अच्छी तरह पकड़ती है:

“Applications already exist as systems. Aspire makes those systems explicit, because explicit systems scale better than tribal knowledge.”

यही पूरी case एक line में है।

और honestly, Aspire की अब तक की सबसे strong one-line explanations में से एक यही है।

यह अब एक साल पहले से ज़्यादा क्यों मायने रखता है

मुझे लगता है यह post खास तौर पर अभी अच्छी लगती है क्योंकि AI-assisted development ambiguity की cost बदल देता है।

Humans incomplete systems की भरपाई surprisingly अच्छी तरह कर लेते हैं।

हम याद रखते हैं:

कौन-सी script पहले चलानी है
कौन-सा environment variable छिपे तौर पर चाहिए
कौन-सी terminal आमतौर पर useful logs दिखाती है
कौन-सी service को दो बार restart करना पड़ता है, ऐसे कारणों से जिन्हें किसी ने document नहीं किया

Agents इस तरह के hidden operational folklore में बहुत कमजोर होते हैं।

तो अगर हम चाहते हैं कि agents real repositories में meaningful रूप से useful बनें, तो हमें system को और explicit बनाना होगा, कम नहीं।

यही वजह है कि मुझे Aspire का framing महत्वपूर्ण लगता है।

Aspire की असली value सिर्फ orchestration नहीं है

एक common mistake Aspire को सिर्फ distributed app launcher या local orchestration helper की तरह देखना है।

यह बहुत छोटा lens है।

ज़्यादा मजबूत value proposition यह है कि Aspire application को देता है:

एक model
एक shape
named resources
explicit dependencies
health और operations surfaces
ऐसे commands जिन्हें humans और automation दोनों समझ सकें

यह development loop को लोगों की सोच से कहीं ज़्यादा बदल देता है।

क्योंकि जैसे ही app implicit conventions का ढेर नहीं रहती और एक real model वाला system बन जाती है, कई चीज़ें एक साथ आसान हो जाती हैं:

onboarding
debugging
repeatable setup
CI consistency
AI-assisted workflows

यह एक design choice से बहुत बड़ी leverage है।

मुझे खास तौर पर “commands as first-class operations” angle पसंद है

source post की एक और बात, जिस पर और ध्यान जाना चाहिए, वह है README instructions से resource-attached commands की तरफ shift।

यह deceptively बड़ा बदलाव है।

यह कहने के बजाय:

इस script को चलाओ, फिर उस वाले को, और अगर पहला fail हो जाए तो शायद यह दूसरा भी

आप operations को app context के अंदर सीधे model कर सकते हैं।

इससे humans उन्हें आसानी से discover कर सकते हैं।

और इसका मतलब है कि agents को prose से intent guess नहीं करनी पड़ती।

यही चीज़ application को “अगर आप इसे पहले से जानते हैं तो operable” से “by design operable” में बदलती है।

एक team lead के तौर पर मैं इससे क्या लूंगा

अगर मैं अपनी टीम के dev loop को इस angle से देखूँ, तो मैं कुछ सीधे सवाल पूछूँगा:

हमारी setup कितनी memory पर निर्भर है?
कितनी critical dev actions सिर्फ docs या chat threads में मौजूद हैं?
new contributors कितनी बार invisible system behavior पर अटकते हैं?
क्या कोई automation tool या coding agent हमारे app topology को repo से समझ सकता है?

अगर आख़िरी सवाल का जवाब “बहुत दूर” है, तो इस post को एक useful nerve छूनी चाहिए।

मेरी राय

यह Aspire की real value का बहुत मजबूत framing है।

यह सिर्फ orchestration नहीं है।

यह app model को इतना explicit बनाना है कि system को operate, understand, और automate करना आसान हो जाए।

यह humans के लिए मायने रखता है। यह teams के लिए मायने रखता है। और अब और भी ज़्यादा, जब modern development का बहुत हिस्सा agent-assisted workflows की ओर जा रहा है, तब यह और ज़रूरी है।

यह बिल्कुल उसी तरह की article है जो समझाती है कि Aspire सिर्फ .NET marketing label से कहीं ज़्यादा relevant क्यों लगता है।

मूल लेख: आपका dev loop tribal knowledge से भरा हुआ है— title: “आपका dev loop छुपे हुए ज्ञान से भरा है, और Aspire के पास सही जवाब है” date: 2026-06-01 author: “Emiliano Montesdeoca” description: “Aspire की एक नई पोस्ट एक बहुत मजबूत बात कहती है: कई teams के पास tools की कमी नहीं होती, उनके पास एक ऐसा consistent application model नहीं होता जो छुपे हुए operational knowledge को ऐसी चीज़ में बदल दे जिसे इंसान, scripts और agents सच में इस्तेमाल कर सकें।” tags:

Aspire
Developer Experience
AI
Dev Loop
.NET

यह लेख स्वचालित रूप से अनुवादित है। मूल लेख के लिए यहाँ क्लिक करें.

यह Aspire के सबसे महत्वपूर्ण लेखों में से एक हो सकता है, यह समझने के लिए कि क्यों यह product मायने रखता है।

इसलिए नहीं कि यह कोई बहुत बड़ा नया feature घोषित करता है।

बल्कि इसलिए कि यह उस problem का नाम देता है जिसे लगभग हर engineering team ने महसूस किया है, लेकिन हर टीम ने अच्छी तरह describe नहीं किया:

dev loop छुपे हुए ज्ञान से भरा है।

यह line इसलिए असर करती है क्योंकि यह सच है।

समस्या tools की कमी नहीं है

मूल लेख का core argument बहुत अच्छा है: teams के पास अक्सर infrastructure, scripts, dashboards, या commands की कमी नहीं होती।

जो चीज़ उनकी कमी होती है, वह है एक coherent model जो application के चारों ओर के hidden operational knowledge को कुछ ऐसा बना दे जो visible और repeatable हो।

कई apps की असली architecture यहाँ रहती है:

shell history
बिखरे हुए scripts
README के टुकड़े
Slack threads
वह एक senior engineer जो operations का क्रम जानता है

यह humans के लिए sustainable dev loop नहीं है।

और agents के लिए तो बिल्कुल नहीं।

वह quote जो, मुझे लगता है, पूरे post को समेट देता है

मूल लेख में एक वाक्य है जो मुझे पूरे point को बहुत अच्छी तरह पकड़ता हुआ लगता है:

“Applications पहले से systems के रूप में मौजूद हैं। Aspire उन systems को explicit बनाता है, क्योंकि explicit systems, tribal knowledge से बेहतर scale करते हैं।”

यही पूरी बात एक लाइन में है।

और honestly, Aspire की सबसे मजबूत one-line explanations में से एक यही है जिसे मैंने अब तक देखा है।

यह आज एक साल पहले से ज़्यादा क्यों मायने रखता है

मुझे लगता है यह post खास तौर पर अभी सही बैठती है, क्योंकि AI-assisted development ambiguity की cost बदल देता है।

Humans अधूरे systems को surprising तरीके से compensate कर लेते हैं।

हमें याद रहता है:

कौन सा script पहले चलाना है
कौन सा environment variable secret रूप से चाहिए
कौन सा terminal आमतौर पर useful logs दिखाता है
किस service को दो बार restart करना पड़ता है, और किसी ने यह document नहीं किया

Agents इस तरह की hidden operational folklore में कहीं कमजोर होते हैं।

तो अगर हम चाहते हैं कि agents real repositories में सच में useful बनें, तो हमें system को less नहीं, more explicit बनाना होगा।

इसीलिए मुझे Aspire का यह framing महत्वपूर्ण लगता है।

Aspire की असली value सिर्फ orchestration नहीं है

Aspire के साथ एक आम गलती यह है कि इसे सिर्फ एक distributed app launcher या local orchestration helper माना जाए।

यह framing बहुत छोटी है।

ज़्यादा मजबूत value proposition यह है कि Aspire application को देता है:

एक model
एक shape
named resources
explicit dependencies
health और operations surfaces
ऐसे commands जिन्हें humans और automation दोनों समझ सकें

यह development loop को उससे कहीं ज़्यादा बदल देता है जितना लोग कभी-कभी समझते हैं।

क्योंकि जैसे ही app implicit conventions का ढेर नहीं रहती और एक real model वाले system में बदलती है, कई चीज़ें एक साथ आसान हो जाती हैं:

onboarding
debugging
repeatable setup
CI consistency
AI-assisted workflows

यह एक design choice से बहुत बड़ा leverage है।

मुझे “commands as first-class operations” वाला angle खास तौर पर पसंद है

मूल लेख का एक और point जिसे मेरी राय में ज़्यादा ध्यान मिलना चाहिए, वह है README instructions से resource-attached commands की ओर जाना।

यह deceptively बड़ा बदलाव है।

यह कहने के बजाय:

पहले यह script चलाओ, फिर वह, और अगर पहले वाला fail हो जाए तो शायद यह दूसरा

आप operations को सीधे app context में model कर सकते हैं।

इसका मतलब है कि humans उन्हें ज़्यादा आसानी से discover कर सकते हैं।

और इसका मतलब है कि agents को prose से intent guess नहीं करनी पड़ती।

यही वह चीज़ है जो application को “अगर आप इसे पहले से जानते हैं तो operable” से “by design operable” बनाती है।

अगर मैं team lead होता तो इससे क्या निकालता

अगर मैं अपनी team के dev loop को इस lens से देखता, तो मैं कुछ सीधे सवाल पूछता:

हमारी setup कितनी memory पर निर्भर है?
कितनी critical dev actions सिर्फ docs या chat threads में मौजूद हैं?
नए contributors कितनी बार invisible system behavior पर अटकते हैं?
क्या कोई automation tool या coding agent हमारे app topology को repo से ही समझ सकता है?

अगर आख़िरी सवाल का जवाब “ज़रा भी नहीं” है, तो यह post एक useful nerve छुएगा।

मेरी राय

यह Aspire की real value का बहुत मजबूत framing है।

यह सिर्फ orchestration नहीं है।

यह application model को इतना explicit बनाने के बारे में है कि system को operate, understand, और automate करना आसान हो जाए।

यह humans के लिए महत्वपूर्ण है। यह teams के लिए महत्वपूर्ण है। और यह अब और भी ज़्यादा महत्वपूर्ण है, क्योंकि modern development का बहुत सा हिस्सा agent-assisted workflows की ओर जा रहा है।

यह ठीक उसी तरह का article है जो समझाता है कि Aspire .NET marketing label से आगे क्यों लगातार ज़्यादा relevant लगता है।

मूल लेख: आपका dev loop छुपे हुए ज्ञान से भरा है

Aspire के हर्मेटिक एंड-टू-एंड टेस्ट वह पैटर्न हैं जिसे और टीमों को अपनाना चाहिए

Emiliano Montesdeoca — Sat, 30 May 2026 00:00:00 +0000

इस लेख का स्वचालित रूप से अनुवाद किया गया है। मूल संस्करण के लिए, यहां क्लिक करें.

फ्लैकी एंड-टू-एंड टेस्ट उस तरह महंगे होते हैं जो हमेशा डैशबोर्ड पर दिखाई नहीं देता।

वे सिर्फ़ फेल नहीं होते। वे धीरे-धीरे टीम को फ़ीडबैक लूप पर भरोसा करना बंद करने के लिए प्रशिक्षित करते हैं।

यही कारण है कि Azure Chaos Studio + Aspire वाला यह लेख मुझे तुरंत पसंद आया। यह कोई चमकदार प्रोडक्ट घोषणा नहीं है। यह एक ठोस इंजीनियरिंग कहानी है कि एंड-टू-एंड टेस्ट को किस तरह भाग्य से जूझने जैसी चीज़ महसूस होने से रोका जाए।

और सच कहूं? मुझे लगता है कि और टीमों को यह पैटर्न अपनाना चाहिए।

मूल विचार सरल है, लेकिन फायदा बहुत बड़ा है

मुख्य चाल यह है कि हर टेस्ट को उसका अपना हर्मेटिक, अस्थायी वातावरण दिया जाए, जिसमें असली सेवाएं, असली निर्भरताएं और स्पष्ट, health-आधारित स्टार्टअप हो।

एक वाक्य में पढ़ने पर यह साफ लगता है। असल सिस्टम में यह कहीं ज्यादा कठिन है, खासकर जब क्लाउड डिपेंडेंसी, साझा वातावरण और वितरित सेवाएं सामने आती हैं।

मूल लेख समस्या को बहुत साफ ढंग से बताता है: साझा टेस्ट वातावरण “क्रॉस-टॉक, फ्लेक, और ‘staging किसने तोड़ा?’ वाले ग्रुप चैट संदेशों” को काम करने की लागत बना देते हैं।

यह लाइन मज़ेदार है क्योंकि यह बहुत हद तक सच है।

बहुत सी टीमें इस समझौते को सामान्य मान लेती हैं। मुझे नहीं लगता कि उन्हें ऐसा करना चाहिए।

यह पैटर्न टेस्टिंग से आगे क्यों मायने रखता है

मुझे यहां सबसे ज़्यादा यह बात पसंद है कि लेख सिर्फ यह नहीं कहता: “हमने अपने टेस्ट अधिक विश्वसनीय बना दिए”।

यह वास्तव में इससे बड़ा कुछ कहता है:

अगर आपका वितरित सिस्टम पुन: उत्पन्न करना, अलग करना, और सत्यापित करना मुश्किल है, तो आपका पूरा इंजीनियरिंग लूप धीमा हो जाएगा।

यह सिर्फ CI को प्रभावित नहीं करता।

यह असर डालता है:

डेवलपर्स कितने आत्मविश्वास से refactor करते हैं
regressions कितनी जल्दी diagnose होते हैं
बड़े architectural बदलाव कितनी सुरक्षित तरह से आज़माए जा सकते हैं
automated validation पर टीम कितना भरोसा करती है

और 2026 में यह इस बात को भी प्रभावित करता है कि AI-सहायित विकास कितना उपयोगी हो सकता है।

पोस्ट का सबसे महत्वपूर्ण उद्धरण

लेख में एक पंक्ति है जिसे मुझे लगता है कि दोहराया जाना चाहिए:

“Agents को perfect होने की ज़रूरत नहीं है। उन्हें checkable होना चाहिए।”

यह बहुत अच्छा framing है।

लोग काफी समय इस बात पर बहस करते हैं कि क्या AI coding agents गैर-तुच्छ काम में मदद करने के लिए पर्याप्त विश्वसनीय हैं। मुझे लगता है बेहतर सवाल यह है कि क्या हमारे सिस्टम उस काम को सही तरीके से आंकने के लिए पर्याप्त testable हैं।

अगर कोई agent एक meaningful refactor सुझाता है और आपकी एकमात्र safety signal एक shared environment पर चलने वाले fragile, semi-random end-to-end checks का ढेर है, तो समस्या सिर्फ agent में नहीं है।

समस्या आपके validation model में है।

यह Aspire पैटर्न इसे काफी बेहतर बनाता है।

इस implementation को खास तौर पर अच्छा क्या बनाता है

मूल कहानी के कई हिस्से इसे सिर्फ “हमने अपने टेस्ट सुधार दिए” वाले धुंधले पोस्ट से कहीं आगे ले जाते हैं।

1. असली service graph, fake theater नहीं

टेस्ट disconnected mocks के ढेर पर नहीं बने हैं जो end-to-end validation का दिखावा करते हों।

वे असल binaries चलाते हैं, जहां संभव हो वहां emulators जोड़ते हैं, और वही application model इस्तेमाल करते हैं जो local development में होता है।

यह मायने रखता है।

क्योंकि जैसे ही end-to-end tests mock-against-mock theater बन जाते हैं, वे वास्तविक composition के बारे में भरोसेमंद कुछ बताना बंद कर देते हैं।

2. magical sleeps के बजाय readiness-based startup

यह हिस्सा जितना दिखता है उससे बड़ा है।

लेख साफ कहता है कि टेस्ट WaitForResourceHealthyAsync के साथ असली health का इंतज़ार करते हैं, न कि मनमाने timing guesses पर भरोसा करते हैं।

यह बहुत बड़ा फर्क है।

एक टेस्ट suite जो कहता है “30 सेकंड सो जाओ और best की उम्मीद करो” असल में uncertainty document कर रहा है। जो suite real readiness का इंतज़ार करता है, वह system intent document कर रहा है।

3. वही model local dev और test दोनों चलाता है

मुझे यह बहुत पसंद है क्योंकि यह Aspire की सबसे मजबूत कहानियों के साथ अच्छी तरह बैठता है।

वही app model चलाता है:

local development
service wiring
emulated dependencies
health checks
hermetic test orchestration

इससे drift कम होता है, और drift भरोसे के सबसे खामोश killers में से एक है।

डेवलपर अनुभव में ऐसा निवेश कम आंका जाता है

मैं चाहता था कि यह पोस्ट सिर्फ़ एक quick reaction से लंबी हो, क्योंकि मुझे लगता है कि इस तरह के engineering सुधारों को अक्सर कम आंका जाता है।

ये flashy नहीं होते।

ये नई AI feature की तरह demo नहीं होते।

और ये हमेशा ऐसा एक स्लाइड भी नहीं बनाते जो executives को उत्साहित कर दे।

लेकिन समय के साथ ये कुछ बहुत कीमती बनाते हैं: एक ऐसी टीम जो quality के बारे में खुद से झूठ बोले बिना तेज़ी से आगे बढ़ सकती है।

यह बड़ी बात है।

लेख में कहा गया है कि वे अब लगभग 90 hermetic tests चलाते हैं, जिनमें zone outage, DNS failure, और geo-replication failure जैसे scenarios शामिल हैं। यह सिर्फ बेहतर test hygiene नहीं है। यह distributed platform के लिए बहुत मजबूत confidence model है।

अगर मैं कोई distributed .NET system चला रहा होता तो मैं इससे क्या लेता

अगर आप आज distributed services, Aspire, और CI/CD pipelines के साथ काम कर रहे हैं, तो मैं इससे तुरंत ये बातें लेता:

shared environments की flakiness को normal मानना बंद करें
जहाँ संभव हो health-based startup gates पर जाएं
AppHost को production-grade orchestration code मानें
ऐसे end-to-end checks बनाएं जो services की composition को validate करें, सिर्फ individual service correctness को नहीं
अगर आप AI-assisted development अपना रहे हैं, तो automation breadth के पीछे भागने से पहले checkability में निवेश करें

यही आख़िरी बिंदु है जिसे और टीमों को सुनना चाहिए।

मेरी राय

यह इस बैच के सबसे मजबूत Aspire posts में से एक है क्योंकि यह एक बहुत व्यावहारिक समस्या को हल करता है।

यह आपको abstraction से impress करने की कोशिश नहीं करता। यह दिखाता है कि end-to-end tests को एक real distributed system में अधिक deterministic, अधिक useful, और अधिक trustworthy कैसे बनाया जाए।

और जैसे ही agent-assisted development से इसका संबंध दिखता है, यह पैटर्न और भी convincing हो जाता है।

अगर आपका end-to-end test story अभी भी shared environments, hidden setup knowledge, और थोड़ी प्रार्थना पर निर्भर है, तो यह देखने लायक है।

Original post: How Azure Chaos Studio ships with hermetic Aspire end-to-end tests