Yuval Avidani
Author
"Turns out GitHub didn't build us a code editor anymore — they built us a command center." That's the sentence that kept running through my head when I read about the GitHub Copilot app that was unveiled at Microsoft Build 2026 and went GA (General Availability, meaning available to everyone, not just beta testers) on June 17, 2026, for Windows, macOS, and Linux.
In my eyes, this is one of those moments where the tool itself gives away where the profession is headed. Let's break it down slowly, and without the buzzword soup.
What even is the "Copilot app," and why isn't it just another code editor
Let's start with a clean definition. The GitHub Copilot app is an agent-native desktop experience that lets you launch, supervise, verify, and ship AI agent code runs for developers juggling multiple tasks at once.
Now, what does "agent-native" mean? Think about the difference between a car with cruise control and a traffic control room. A regular code editor is built on the assumption that there's one programmer typing line by line, with a smart assistant on the side. An agent-native app flips that on its head: the basic assumption is that several agents are working in parallel, and the human developer is the one supervising, approving, and steering them. The agent isn't a plugin anymore — it's the actual unit of work.
Here's the cool part: GitHub isn't hiding this. They built a single view called "My Work" that centralizes all active sessions, all the issues (open tasks and bugs), the pull requests, and even background automations — across every connected repo (repositories, code storage). Instead of jumping between ten tabs, we get one command screen.
worktree: why two agents don't trample each other
Here's the engineering detail I loved the most, because it's smart and quiet. Every session runs in its own git worktree.
What's a worktree? Without diving into git's guts, let's keep it simple. When we work on code, we work on a "branch" — an isolated working version. In short, a worktree is an isolated copy of the branch, a completely separate working folder, sitting alongside the others. Think of it like separate stations in a professional kitchen: each chef has their own counter with their own ingredients, so two people cooking different dishes never trip over each other's tools.
Why does this matter to us? Because without this kind of isolation, two agents working in parallel on the same repo would simply trample each other's files — what we call a conflict. The worktree-per-session is exactly what turns "parallel agents" from a theoretical headache into something you can actually run.
Agent Merge and Canvases: where the human enters the picture
Now that we have a team of agents at work, we need to merge their output back into the main code. That's where Agent Merge comes in.
Let's nail down a basic concept first. A PR (Pull Request) is a request to merge a code change from one branch into the main codebase — like submitting an article to the editorial desk before it goes live on the site. A merge is the act of the actual combining. Agent Merge is the feature that automatically runs a PR through three gates: review (code review), tests (code that checks the code works), and merge conditions we define ourselves. Only if everything's green does it go in.
And there's another layer that I think is the human heart of this whole story: "Canvases." These are bidirectional surfaces where human developers and agents intervene directly in the same piece of work. It's not "give the agent an instruction and go to sleep" — it's standing in front of the same board and drawing on it together. To me, this is GitHub's most honest admission that the human stays in the loop — not as a spectator, but as an active partner.
Sandbox: why we let agents run without being afraid
There's a question that everyone who's heard "AI that runs code on its own" asks immediately: what if it deletes my stuff? GitHub's answer is the sandbox.
What's a sandbox? An isolated, restricted environment with policy enforcement, where code can run without touching the rest of the system. Think of it like an actual sandbox at a playground: the kid can dig, build, and destroy as much as they want, but the mess stays inside the box. The app offers two flavors: local sandboxing (on our own machine, with enforcement policies) and ephemeral cloud environments — temporary Linux environments from GitHub that spin up, do the job, and disappear.
Why does this matter to us? Because isolation is what lets us take our hands off the wheel. Without a sandbox, "let the agent run" is a gamble; with a sandbox, it's a calculated engineering decision.
The SDK: this isn't just an app, it's infrastructure
One last important point, because it changes the scale of the whole story. Alongside the app, the Copilot SDK also went GA.
What's an SDK? Stands for Software Development Kit — a toolkit that lets us, the developers, build on top of GitHub's engine ourselves instead of just using the ready-made app. And this SDK dropped all at once for Node/TypeScript, Python, Go, .NET, Rust, and Java. Your language is probably already supported.
The meaning of this, according to CPO (Chief Product Officer) Mario Rodriguez, is that GitHub isn't just selling a product anymore — they're selling a platform. Anyone can build their own "command center."
So what does this mean for us — in my view
Bottom line, and I'm saying this as someone who tested these features one by one: our role is shifting. We're moving from "code writers" to "agent team managers."
Think of it like being a dev team lead. A good team lead doesn't necessarily type the fastest — they know how to split up tasks, set clear acceptance criteria (which is exactly what Agent Merge does), give everyone their own workspace (worktree), make sure nobody breaks the environment (sandbox), and sit with the team in front of the whiteboard at the critical moments (Canvases). The new skill isn't typing speed — it's the quality of your supervision and your definitions.
And I have to be fair and add a caveat. One new app, launched less than two weeks ago, is not proof that the world has changed — it's a calculated bet by one big company on a particular direction. There are other approaches to the same challenge (terminal-based agents, cloud-only agents, agents built into existing editors), and each one strikes a different balance between control and autonomy. It's still too early to say who's right. What is clear to me: the tools already assume we're managers, not just typists. And that skill — of supervision, definition, and controlled trust in agents — is one we should start training right now.
So I'll ask you: when the agents are writing the code, what still makes us good programmers — and what are you practicing this week?