Your IDE isn't where you build anymore

A small feature shipped this month that I think marks a bigger turn than its announcement suggested. Mistral rebranded its chat app to Vibe and gave it a "Code Mode" where you connect a GitHub repo, start a coding session that runs in an isolated cloud sandbox, and — this is the part — the agent works, opens a pull request, and notifies you, "so you review the result instead of every keystroke that produced it." The sessions run in parallel, keep going while your machine is off, and can be triggered from Slack, not just an editor.

Read that last bit again. You can kick off real software work from a Slack message. The place where building happens just stopped being the IDE.

The editor was never sacred — it just felt that way

For our entire careers, "where you code" had an obvious answer: the editor. It's where you typed, where the work lived, the cockpit. Vibe, and Cursor's Automations, and a wave of background agents are quietly demoting it. Cursor's version spins up an isolated cloud VM, clones your repo, works on its own branch, and hands you a PR to review. A tool called Tembo makes Slack the primary interface — describe a task in a channel, get a production-ready PR back in the same thread.

The common shape across all of them: the build runs somewhere else, in the cloud, in parallel, and comes back to you as a diff to judge. The editor becomes one place you might review that diff — not the place the work happened. The cockpit turned into a notification.

This is "directing, not typing" reaching its conclusion

I've written that my own work shifted from typing code to directing agents that write it. What this month makes concrete is the next step: once you're directing rather than typing, you don't need to be sitting in the editor to do it. If the real work is specifying the task and judging the result, then the trigger can be anywhere — a Slack message, a CLI, an issue tracker, a timer — and the output is always the same thing: a change for you to approve.

That reframes the whole job. The unit of work stops being "an afternoon in the editor" and becomes "a task I handed off and a diff I reviewed." It's the same move as going from approving every step to reviewing the outcome, pushed all the way down to how you physically work: you launch, the agent grinds in the cloud, you come back to a result. The keystrokes that produced it are no longer your concern, the same way you don't read the assembly your compiler emits.

What actually changes for you

A few consequences fall out of this, and they're worth getting ahead of:

• The spec becomes the real interface. When you trigger from Slack and get a PR back, the only thing you actually authored is the description of what you wanted. The clearer that is, the better the diff. This is the spec being the artifact, made literal — what you type into the channel is the work.
• Reviewing becomes the main skill. If the agent writes and you judge, then your throughput is capped by how fast and well you can read a diff, not how fast you type. The bottleneck moved from production to evaluation — invest there.
• Parallelism becomes normal, and dangerous. Sessions run at once, while your laptop sleeps. That's leverage, but five agents opening five PRs you skim at midnight is exactly how unreviewed, subtly-wrong code reaches main. More parallel build means you need more review discipline, not less.
• Non-developers get a trigger too. When the interface is Slack, a PM or support engineer can kick off a change by tagging the agent. That's powerful and it's a governance problem — someone still has to own what reaches production.

The takeaway

Don't over-read this: the IDE isn't dead, and there's plenty of work that still wants you in the editor, hands on the code. But the center of gravity is moving. The default mental model — "building software means sitting in my editor typing" — is becoming one option among several, and increasingly not the main one.

The shift worth internalizing is that where you build is decoupling from the editor, and what you do is sliding from producing code to specifying and judging it. The people who adapt fastest will be the ones who get comfortable launching work from anywhere and, more importantly, reviewing what comes back like it matters — because the one thing that didn't move to the cloud is the responsibility for what ships. That stayed exactly where it always was: with you.