spinny:~/writing $ cat microsoft-build-2026-agent-native-development.md

Microsoft Build 2026 dan pergeseran tenang menuju agent-native development

· 2 min read · Filippo Spinella · AI, GitHub Copilot, Microsoft Build, Developer Tools

Microsoft Build 2026 punya subteks yang jelas: fase berikutnya dari software agents bukan chat box yang lebih cantik. Agents butuh meja kerja, checklist, sandbox, dan orang yang bertanggung jawab.

Sinyal resminya datang dari Microsoft Build 2026 live blog, tulisan Microsoft AI alone won't change your business. The system running it will, dan pengumuman GitHub tentang GitHub Copilot app. Dibaca bersama, arahnya sama: agents masuk ke sistem development, bukan hanya aksesori di samping editor.

Bagian berguna itu membosankan, dengan cara baik

Agent yang bisa menulis patch itu menarik. Tapi agent yang bekerja di worktree terisolasi, menjalankan checks, menyimpan trace yang bisa dibaca, membuka pull request, dan berhenti di approval gate yang tepat jauh lebih berguna.

Itulah pergeseran yang saya lihat di Build 2026. Lebih sedikit magic. Lebih banyak operating model.

GitHub Copilot app terasa seperti control room untuk agent work: sessions, repositories, issues, pull requests, dan parallel tasks dalam satu tempat. Detail yang saya suka adalah worktrees. Setiap percobaan punya ruang sendiri. Bisa dibandingkan, dibuang, atau dipromosikan tanpa menginjak file sendiri.

Sandbox bukan fitur sampingan

Jika agent bisa menjalankan code, ia butuh tempat aman untuk salah. Di situlah sandbox penting. Local atau cloud sandbox memungkinkan agent mencoba tanpa menjadikan laptop atau production sebagai eksperimen.

Ini tidak glamor, tapi inilah perbedaan demo dan workflow. Agent yang baik harus bisa menjalankan tests, membaca failures, mencoba lagi, dan menunjukkan apa yang berubah. Ia juga harus cukup dibatasi agar kesalahan tetap kecil.

Foundry dan Agent Framework bicara production

Update Foundry dan Microsoft Agent Framework adalah versi enterprise dari cerita yang sama. Hosted agents, toolboxes, tracing, evaluation, memory, middleware, dan agent controls terdengar seperti infrastructure. Memang begitu. Karena itu penting.

Ketika perusahaan membuat banyak agents, pertanyaannya bukan lagi bisakah kita membuat satu. Pertanyaannya menjadi: siapa ownernya, apa aksesnya, bagaimana dievaluasi, bagaimana tahu ia membaik, dan bagaimana mematikannya.

Review menjadi bottleneck

Jebakan agentic development adalah mengira lebih banyak agents otomatis berarti lebih banyak work shipped. Bisa jadi hanya lebih banyak pull requests menunggu reviewer yang lelah.

Saya akan mengukur adoption dengan tiga hal: apakah menghemat atau memakan waktu reviewer; seberapa sering generated changes lulus checks tanpa babysitting; dan apakah trace menjelaskan reasoning cukup baik untuk mempercayai diff.

Jika reviewer harus membangun ulang semuanya dari nol, workflow belum selesai. Bebannya hanya pindah tempat.

Dari mana saya mulai

Saya mulai dari tasks membosankan dan jelas batasnya: dependency updates, test fixes, refactor kecil, follow-up review comments, release notes, migrations dengan tests kuat.

Untuk tiap task saya ingin isolation, checks, trace, dan human merge decision. Agent melakukan legwork. Team tetap memiliki hasilnya.

Pandangan saya

Build 2026 membuat agent-native development terasa lebih seperti masalah operations daripada slogan. Team yang menang bukan yang membiarkan agents melakukan semuanya. Team yang menang adalah yang mendesain sistem agar agents bisa maju tanpa menyembunyikan trace.

Sumber

spinny:~/writing/microsoft-build-2026-agent-native-development $
try:
spinny:~/writing/microsoft-build-2026-agent-native-development·microsoft-build-2026-agent-native-development.md
·
·--:--:--
    Microsoft Build 2026 dan pergeseran tenang menuju agent-native development | Filippo Spinella - Insinyur Perangkat Lunak