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. Агентам нужны рабочее место, checklist, sandbox и ответственный владелец.
Официальные сигналы пришли из Microsoft Build 2026 live blog, поста Microsoft AI alone won't change your business. The system running it will и анонса GitHub про GitHub Copilot app. Вместе они говорят одно: agents становятся частью системы разработки, а не аксессуаром рядом с редактором.
Полезная часть скучна, и это хорошо
Agent, который пишет patch, интересен. Но agent, который работает в изолированном worktree, запускает checks, хранит понятный trace, открывает pull request и останавливается на нужном approval gate, намного полезнее.
Именно это я вижу в Build 2026. Меньше магии. Больше операционной модели.
GitHub Copilot app выглядит как control room для работы agents: sessions, repositories, issues, pull requests и параллельные задачи в одном месте. Worktrees — удачная деталь. Каждая попытка живет в своем пространстве. Ее можно сравнить, выбросить или продвинуть, не ломая свои файлы.
Sandboxes — не второстепенная функция
Если agent может запускать code, ему нужно безопасное место, где можно ошибаться. Для этого нужны sandboxes. Локальные или cloud sandboxes позволяют тестировать, не превращая laptop или production в эксперимент.
Это не выглядит эффектно, но это разница между demo и workflow. Хороший agent должен запускать tests, читать failures, пробовать снова и показывать, что изменилось. И он должен быть достаточно ограничен, чтобы ошибка оставалась маленькой.
Foundry и Agent Framework говорят о production
Foundry и Microsoft Agent Framework — корпоративная версия той же истории. Hosted agents, toolboxes, tracing, evaluation, memory, middleware и agent controls звучат как инфраструктура. Так и есть. Поэтому это важно.
Когда компания создает много agents, вопрос уже не в том, можем ли мы создать одного. Вопросы другие: кто владелец, к чему есть доступ, как оценивать, как понять улучшение и как выключить при необходимости.
Review становится узким местом
Ловушка agentic development — думать, что больше agents автоматически значит больше shipped work. Иногда это просто больше pull requests перед уставшими reviewers.
Я бы измерял adoption тремя вещами: экономит ли это время reviewer; как часто generated changes проходят checks без babysitting; и объясняет ли trace reasoning достаточно хорошо, чтобы доверять diff.
Если reviewer должен все восстанавливать с нуля, workflow не готов. Нагрузка просто переехала.
С чего начать
Я бы начал со скучных ограниченных задач: dependency updates, test fixes, небольшие refactors, ответы на review comments, release notes, migrations с сильными tests.
Для каждой задачи нужны isolation, checks, trace и человеческое merge decision. Agent делает тяжелую рутину. Команда остается владельцем результата.
Мой вывод
Build 2026 сделал agent-native development не лозунгом, а операционной задачей. Победят не команды, которые отдают agents все. Победят те, кто строит систему, где agents двигаются вперед, не пряча след.