spinny:~/writing $ vim microsoft-build-2026-agent-native-development.md
1~2Microsoft Build 2026 miał bardzo czytelny podtekst: kolejna faza software agents to nie ładniejszy chat box. Chodzi o to, żeby dać agentom biurko, checklistę, sandbox i odpowiedzialną osobę.3~4Oficjalne sygnały przyszły z [Microsoft Build 2026 live blog](https://news.microsoft.com/build-2026-live-blog/microsoft-build-2026-live/), tekstu Microsoft [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/) oraz zapowiedzi GitHub [GitHub Copilot app](https://github.blog/news-insights/product-news/github-copilot-app-the-agent-native-desktop-experience/). Razem mówią jedno: agents wchodzą do systemu development, nie stoją obok edytora jako dodatek.5~6## Użyteczna część jest nudna, w dobrym sensie7~8Agent, który pisze patch, jest ciekawy. Ale agent, który pracuje w izolowanym worktree, uruchamia checks, zostawia czytelny trace, otwiera pull request i zatrzymuje się na właściwym approval gate, jest dużo bardziej użyteczny.9~10To jest przesunięcie, które widzę w Build 2026. Mniej magii. Więcej modelu operacyjnego. GitHub Copilot app wygląda jak control room dla agent work: sessions, repositories, issues, pull requests i parallel tasks w jednym miejscu. Worktrees są świetnym detalem, bo każda próba ma własną przestrzeń. Można ją porównać, wyrzucić albo promować bez niszczenia swoich plików.11~12## Sandboxy nie są dodatkiem13~14Jeśli agent może uruchamiać code, potrzebuje bezpiecznego miejsca na pomyłki. Od tego są local i cloud sandboxes. Agent może testować bez zmieniania laptopa albo production w eksperyment.15~16To nie jest efektowne, ale to różnica między demo i workflow. Dobry agent powinien uruchamiać tests, czytać failures, próbować ponownie i pokazywać, co zmienił. Powinien też być ograniczony tak, żeby błąd pozostał mały.17~18## Review staje się wąskim gardłem19~20Pułapka agentic development polega na założeniu, że więcej agents automatycznie oznacza więcej shipped work. Może oznaczać tylko więcej pull requests przed zmęczonymi reviewers.21~22Mierzyłbym trzy rzeczy: czy oszczędza czas reviewerów; jak często generated changes przechodzą checks bez babysitting; czy trace tłumaczy reasoning wystarczająco dobrze, żeby zaufać diffowi.23~24Jeśli reviewer musi wszystko odtwarzać od zera, workflow nie jest gotowy. Ciężar tylko zmienił miejsce.25~26## Od czego bym zaczął27~28Zacząłbym od nudnych, ograniczonych tasks: dependency updates, test fixes, małe refactors, follow-up do review comments, release notes, migrations z mocnymi tests.29~30Dla każdego taska wymagałbym isolation, checks, trace i ludzkiej decyzji merge. Agent robi legwork. Team nadal jest właścicielem wyniku.31~32## Moja lektura33~34Build 2026 sprawił, że agent-native development brzmi mniej jak slogan, a bardziej jak problem operacyjny. Wygrają nie zespoły, które pozwolą agents robić wszystko, lecz te, które zaprojektują system, gdzie agents idą do przodu bez ukrywania trace.35~36## Źródła37~38- [Microsoft Build 2026 live blog](https://news.microsoft.com/build-2026-live-blog/microsoft-build-2026-live/)39- [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/)40- [GitHub: Copilot app, the agent-native desktop experience](https://github.blog/news-insights/product-news/github-copilot-app-the-agent-native-desktop-experience/)41~
NORMAL · microsoft-build-2026-agent-native-development.md [readonly]41 lines · :q to close