Microsoft Build 2026 এবং agent-native development-এর নীরব বদল
· 2 min read · Filippo Spinella · AI, GitHub Copilot, Microsoft Build, Developer Tools
Microsoft Build 2026-এর বার্তাটা পরিষ্কার ছিল: software agents-এর পরের ধাপ সুন্দর chat box নয়। agents-এর দরকার desk, checklist, sandbox এবং একজন responsible owner।
Official signals এসেছে Microsoft Build 2026 live blog, Microsoft-এর AI alone won't change your business. The system running it will post, আর GitHub-এর GitHub Copilot app announcement থেকে। একসাথে পড়লে দিকটা স্পষ্ট: agents editor-এর পাশে accessory না থেকে development system-এর ভেতরে ঢুকছে।
Useful অংশটা ভালো অর্থে boring
Patch লিখতে পারে এমন agent interesting। কিন্তু isolated worktree-তে কাজ করে, checks চালায়, readable trace রাখে, pull request খোলে এবং ঠিক approval gate-এ থামে—এমন agent অনেক বেশি useful।
Build 2026-এ আমি এই shift-টাই দেখি। কম magic, বেশি operating model। GitHub Copilot app agent work-এর control room-এর মতো: sessions, repositories, issues, pull requests এবং parallel tasks এক জায়গায়। Worktrees detail-টা ভালো, কারণ প্রতিটি attempt নিজের জায়গায় থাকে। compare, discard বা promote করা যায় নিজের files নষ্ট না করে।
Sandbox side feature নয়
Agent যদি code run করতে পারে, তাহলে safe জায়গা দরকার যেখানে সে ভুল করতে পারে। Local বা cloud sandbox সেই জায়গা দেয়। laptop বা production-কে experiment না বানিয়েই agent test করতে পারে।
এটা flashy নয়, কিন্তু demo আর workflow-এর পার্থক্য এখানেই। ভালো agent tests চালাবে, failures পড়বে, retry করবে এবং কী বদলেছে দেখাবে। আবার boundary এমন হবে যাতে ভুল ছোট থাকে।
Foundry এবং Agent Framework production-এর কথা বলে
Foundry এবং Microsoft Agent Framework updates একই গল্পের enterprise version। Hosted agents, toolboxes, tracing, evaluation, memory, middleware, agent controls—সবই infrastructure-এর শব্দ। ঠিক তাই। তাই এগুলো গুরুত্বপূর্ণ।
Company যখন অনেক agents বানায়, প্রশ্ন আর থাকে না আমরা কি একটা বানাতে পারি। প্রশ্ন হয়: owner কে, access কী, evaluation কীভাবে, improvement বোঝা যাবে কীভাবে, আর দরকার হলে বন্ধ করব কীভাবে?
Review bottleneck হয়
Agentic development-এর trap হলো ভাবা, বেশি agents মানেই বেশি shipped work। বাস্তবে এর মানে হতে পারে tired reviewers-এর সামনে আরও pull requests।
আমি adoption মাপতাম তিন জিনিসে: reviewer time বাঁচছে না খরচ হচ্ছে; generated changes কতবার checks পাস করছে; trace reasoning বোঝায় কি না যাতে diff বিশ্বাস করা যায়।
Reviewer যদি সব কিছু zero থেকে reconstruct করে, workflow শেষ হয়নি। শুধু burden সরেছে।
কোথা থেকে শুরু
আমি boring bounded tasks দিয়ে শুরু করতাম: dependency updates, test fixes, ছোট refactors, review-comment follow-ups, release notes, strong tests-সহ migrations।
প্রতিটি task-এ isolation, checks, trace এবং human merge decision চাই। Agent legwork করবে। Result-এর owner থাকবে team।
আমার পড়া
Build 2026 agent-native development-কে slogan-এর চেয়ে operations problem বানিয়েছে। জিতবে না সেই team যারা agents-কে সব করতে দেবে। জিতবে যারা এমন system design করবে যেখানে agents progress করতে পারে কিন্তু trace লুকায় না।