AI Foundry | The .NET Blog

Azure SDK अप्रैल 2026: AI Foundry 2.0 और .NET डेवलपरों को क्या जानना चाहिए

Emiliano Montesdeoca — Sat, 25 Apr 2026 00:00:00 +0000

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

मासिक SDK releases को अक्सर छोड़ देना आसान होता है। इस बार कुछ ऐसी चीज़ें हैं जिन पर ध्यान देना चाहिए — खासकर अगर आप AI Foundry, Java में Cosmos DB, या .NET code से infrastructure provisioning कर रहे हैं।

Azure.AI.Projects 2.0.0 — ऐसे breaking changes जो मायने रखते हैं

Azure.AI.Projects NuGet package कुछ बड़े architectural changes के साथ stable 2.0.0 तक पहुंचता है। अगर आप पहले से preview इस्तेमाल कर रहे हैं, तो ये बदलाव हुए हैं:

Namespace splits: Evaluations Azure.AI.Projects.Evaluation में चले गए हैं, और memory operations Azure.AI.Projects.Memory में। आपको अपने using statements अपडेट करने होंगे।
Renamed types: Insights → ProjectInsights, Schedules → ProjectSchedules, Evaluators → ProjectEvaluators, Trigger → ScheduleTrigger
Naming conventions: अब boolean properties लगातार Is* convention का पालन करती हैं

यह वही तरह के breaking changes हैं जो एक बार चोट पहुंचाते हैं और फिर हमेशा सही लगते हैं। अगर आपने preview पर build किया है, imports अपडेट करें और compiler को बाकी बदलाव बताने दें।

अच्छी खबर: यह अब stable है। आप इस API पर अब भरोसा कर सकते हैं।

Cosmos DB Java: गंभीर सुरक्षा fix (RCE)

यह गंभीर है। Java Cosmos DB library (azure-cosmos) version 4.79.0 में Remote Code Execution vulnerability (CWE-502) के लिए critical security fix शामिल है।

समस्या CosmosClientMetadataCachesSnapshot, AsyncCache, और DocumentCollection में Java deserialization थी। fix Java deserialization को JSON-based serialization से बदल देता है, जिससे deserialization attacks की पूरी श्रेणी खत्म हो जाती है।

अगर आपके पास Azure Cosmos DB इस्तेमाल करने वाली कोई Java services हैं, तो तुरंत 4.79.0 पर अपडेट करें। यह वैकल्पिक नहीं है।

.NET के लिए नई Provisioning libraries

इस महीने कई stable Provisioning libraries 1.0.0 पर पहुंचीं — ये वो libraries हैं जो आपको ARM templates या Bicep की जगह C# code में Azure infrastructure परिभाषित करने देती हैं:

कई और beta.1 में हैं, जिनमें API Management, Batch, Compute, Monitor, MySQL, और Security Center शामिल हैं। अगर आप .NET से infrastructure-as-code कर रहे हैं — खासकर Aspire deployments के साथ — तो ये libraries आपका entry point हैं।

Azure AI Agents Java: 2.0.0 GA

Java Azure AI Agents library भी इस महीने general availability तक पहुंचती है। मुख्य breaking changes:

कई enum types को ExpandableStringEnum-आधारित classes में बदला गया है (नए values के लिए अधिक लचीला)
*Param model classes का नाम बदलकर *Parameter किया गया है
MCPToolConnectorId → McpToolConnectorId (consistent casing)
beginUpdateMemories के लिए नया convenience overload

Wrap Up

इस महीने .NET developers के लिए headline यह है कि Azure.AI.Projects 2.0.0 stable हो गया है — अगर आप AI Foundry के साथ build कर रहे हैं, तो अब stable पर pin करने और imports अपडेट करने का समय है। Cosmos DB इस्तेमाल करने वाले Java shops के लिए security update urgent है।

Full release notes aka.ms/azsdk/releases पर हैं। Original post: Azure SDK Release (April 2026).

क्या Copilot को हर दिन 68 मिनट कोड फिर से समझाने में लग रहे हैं? इसका हल है

Emiliano Montesdeoca — Thu, 23 Apr 2026 00:00:00 +0000

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

क्या आप वह पल जानते हैं जब आपकी Copilot session /compact पर पहुँचती है और agent पूरी तरह भूल जाता है कि आप क्या कर रहे थे? अगले पाँच मिनट आप file structure, failing test, और वे तीन approaches फिर से समझाते हैं जिन्हें आप पहले ही आज़मा चुके हैं। फिर यह सब दोबारा होता है। और फिर दोबारा।

Desi Villanueva ने इसे time किया: 68 minutes per day — सिर्फ़ re-orientation में। कोड लिखने में नहीं। PRs review करने में नहीं। बस AI को वह याद दिलाने में जो वह पहले से जानता था।

असल में ऐसा क्यों होता है, और इसका एक ठोस हल भी है।

कॉन्टेक्स्ट विंडो की झूठी कहानी

आपके agent के बॉक्स पर एक बड़ा नंबर लिखा होता है। 200K tokens. बहुत बड़ा लगता है। व्यवहार में यह एक ceiling है, कोई गारंटी नहीं।

असल गणित यह है:

200K कुल context
लगभग 65K MCP tools के लिए जो startup पर लोड होते हैं (~33%)
लगभग 10K instruction files के लिए, जैसे AGENTS.md या copilot-instructions.md

इससे आपके पास लगभग 125K बचते हैं, उससे पहले कि आप एक शब्द भी लिखें। और हालात और खराब हैं — LLMs context भरते जाने पर शालीनता से degrade नहीं होते। वे लगभग 60% capacity पर दीवार से टकरा जाते हैं। मॉडल 30 turns पहले कही गई बातें खोने लगता है, पहले दिए गए जवाबों का विरोध करता है, और 10 मिनट पहले जिन file names को बहुत आत्मविश्वास से बताया था, उन्हें भी hallucinate करने लगता है। उद्योग इसे “lost in the middle” problem कहता है।

प्रभावी सीमा: 45K tokens उसके बाद quality गिरने लगती है। यानी शायद 20-30 active conversation turns, फिर agent drift करने लगता है। इसी वजह से आप हर 45 मिनट में /compact कर रहे हैं — इसलिए नहीं कि आपने 200K tokens भर दिए, बल्कि इसलिए कि model पहले ही 120K पर खराब होने लगा है।

कॉम्पैक्शन टैक्स

हर /compact आपका flow state छीन लेता है। आप एक deep debugging session में हैं। shared context 30 मिनट से बन रहा था। agent को file structure, failing test, और hypothesis पता है। फिर warning आ जाती है।

अनदेखा करें → agent धीरे-धीरे बेवकूफ होता जाता है, पुरानी state hallucinate करता है
/compact चलाएँ → agent को 30 मिनट की investigation का दो पैराग्राफ़ का सार मिल जाता है

दोनों ही हालात में नुकसान होता है। दोनों ही हालात में आप अपने project को किसी नए join किए हुए employee की तरह दोहरा रहे होते हैं।

कड़वी बात? Memory पहले से मौजूद है। Copilot CLI हर session को ~/.copilot/session-store.db नाम की local SQLite database में लिखता है — हर touched file, हर turn, हर checkpoint. सब disk पर मौजूद है. Agent बस उसे पढ़ नहीं सकता.

auto-memory: एक recall layer, memory system नहीं

auto-memory के पीछे यही मुख्य विचार है: नया memory system मत बनाइए — जो पहले से है, उसके ऊपर एक read-only query layer बनाइए।

pip install auto-memory

करीब 1,900 lines of Python। Zero dependencies. 30 seconds में install.

Context को grep results से भरने के बजाय, आप agent को उस चीज़ तक surgical access देते हैं जो सच में मायने रखती है:

ऑपरेशन	Tokens	आपको क्या मिलता है
`grep -r "auth" src/`	~5,000–10,000	500 results, जिनमें से ज़्यादातर irrelevant हैं
`find . -name "*.py"`	~2,000	सभी Python files, बिना context के
Agent re-orientation	~2,000	आप उसे वह समझा रहे हैं जो उसे पहले से पता होना चाहिए
`auto-memory files --json --limit 10`	~50	कल आपने जिन 10 files पर काम किया था

यह 200x improvement है। Agent archaeology dig छोड़ देता है और सीधे उस चीज़ पर पहुँच जाता है जो मायने रखती है।

Recommended flow: जब आप 50-70% context usage के पास पहुँचें, /clear चलाएँ और फिर prompt करें: “उन पिछली sessions की समीक्षा करो जिनमें हमने विषय X पर बात की थी”। Blind searches पर 12K tokens जलाने के बजाय, auto-memory relevant context को 50 में निकाल लेता है।

यह .NET developers के लिए क्यों मायने रखता है

अगर आप GitHub Copilot CLI का इस्तेमाल .NET work के लिए कर रहे हैं — services scaffold करना, EF Core queries debug करना, Blazor components पर iterate करना — तो context rot की समस्या उतनी ही तेज़ी से आती है। Multiple projects, shared libraries, और deep call chains वाली complex solutions वही codebases हैं जहाँ agent सबसे जल्दी track खो देता है।

Install guide बताती है कि Copilot CLI को इसकी ओर कैसे point करना है। यह एक one-time setup है।

सच कहें तो? 68 minutes a day वापस पाना कोई छोटा quality-of-life tweak नहीं है। यह लगभग 6 hours a week है।

समापन

Context rot एक वास्तविक architectural constraint है, कोई ऐसा bug नहीं जो बस patch होकर ठीक हो जाएगा। auto-memory आपका agent expensive, noisy re-exploration करने के बजाय cheap और precise recall mechanism देकर इस सीमा को bypass करता है। अगर आप GitHub Copilot CLI के साथ serious AI-assisted development कर रहे हैं, तो 30-second install वाकई क़ीमती है।

देखिए: GitHub पर auto-memory. Original post by Desi Villanueva: I Wasted 68 Minutes a Day Re-Explaining My Code.