spinny:~/writing $ vim microsoft-build-2026-agent-native-development.md
1~2Microsoft Build 2026 का सीधा संदेश यह था: software agents का अगला phase कोई prettier chat box नहीं है। असली बात है agents को desk, checklist, sandbox और clear owner देना।3~4Official signals [Microsoft Build 2026 live blog](https://news.microsoft.com/build-2026-live-blog/microsoft-build-2026-live/), Microsoft के post [AI alone won't change your business. The system running it will](https://blogs.microsoft.com/blog/2026/06/02/ai-alone-wont-change-your-business-the-system-running-it-will/) और GitHub की [GitHub Copilot app](https://github.blog/news-insights/product-news/github-copilot-app-the-agent-native-desktop-experience/) announcement से आए। तीनों को साथ पढ़ें तो बात साफ है: agents editor के बगल में accessory नहीं रहेंगे, वे development system का हिस्सा बनेंगे।5~6## Useful हिस्सा boring है, अच्छे तरीके से7~8Patch लिखने वाला agent interesting है। लेकिन isolated worktree में काम करने वाला, checks चलाने वाला, readable trace रखने वाला, pull request खोलने वाला और सही approval gate पर रुकने वाला agent ज्यादा useful है।9~10यही Build 2026 का shift है: कम magic, ज्यादा operating model। GitHub Copilot app agent work के control room जैसी लगती है। Sessions, repositories, issues, pull requests और parallel tasks एक जगह। Worktrees मुझे खास पसंद हैं, क्योंकि हर attempt अपने space में रह सकता है। उसे compare, discard या promote किया जा सकता है बिना अपने files बिगाड़े।11~12## Sandbox side feature नहीं है13~14अगर agent code चला सकता है तो उसे safe जगह चाहिए जहाँ वह गलत हो सके। Local और cloud sandboxes यही देते हैं। Laptop या production को experiment बनाए बिना agent test कर सकता है।15~16यह glamorous नहीं है, लेकिन demo और workflow के बीच फर्क यही है। अच्छा agent tests चलाए, failures पढ़े, retry करे और बताए क्या बदला। साथ ही उसकी boundaries इतनी tight हों कि गलती छोटी रहे।17~18## Foundry और Agent Framework production की भाषा बोलते हैं19~20Foundry और Microsoft Agent Framework updates इसी कहानी का enterprise रूप हैं। Hosted agents, toolboxes, tracing, evaluation, memory, middleware और agent controls infrastructure जैसे शब्द लगते हैं। हैं भी। इसलिए जरूरी हैं।21~22जब company कई agents बनाती है, सवाल यह नहीं रहता कि क्या हम एक बना सकते हैं। सवाल हो जाता है: owner कौन है, access क्या है, evaluation कैसे होगी, improvement कैसे पता चलेगा, और shut down कैसे होगा?23~24## Review bottleneck बन सकती है25~26Agentic development की trap है मान लेना कि ज्यादा agents का मतलब ज्यादा shipped work है। हो सकता है इसका मतलब सिर्फ ज्यादा pull requests हो जो tired reviewers के सामने पड़ी हों।27~28मैं adoption को तीन चीजों से मापता: reviewer time बचता है या खर्च होता है, generated changes कितनी बार checks पास करते हैं, और trace reasoning समझाने लायक है या नहीं।29~30अगर reviewer को सब कुछ zero से reconstruct करना पड़ता है, workflow finished नहीं है। बस burden shift हुआ है।31~32## शुरुआत कहाँ से33~34मैं boring bounded tasks से शुरू करता: dependency updates, test fixes, छोटे refactors, review-comment follow-ups, release notes, strong tests वाली migrations।35~36हर task में isolation, checks, trace और human merge decision चाहिए। Agent legwork करे। Result का owner team रहे।37~38## मेरी राय39~40Build 2026 ने agent-native development को slogan से operations problem बना दिया। Winning teams वे नहीं होंगी जो agents को सब करने देंगी। Winning teams वे होंगी जो ऐसा system design करेंगी जहाँ agents progress करें, पर trace छिपे नहीं।41~42## Sources43~44- [Microsoft Build 2026 live blog](https://news.microsoft.com/build-2026-live-blog/microsoft-build-2026-live/)45- [Microsoft: AI alone won't change your business](https://blogs.microsoft.com/blog/2026/06/02/ai-alone-wont-change-your-business-the-system-running-it-will/)46- [GitHub: Copilot app, the agent-native desktop experience](https://github.blog/news-insights/product-news/github-copilot-app-the-agent-native-desktop-experience/)47~
NORMAL · microsoft-build-2026-agent-native-development.md [readonly]47 lines · :q to close