In 2024 the unit of work in an editor was a file. In 2026 the unit of work is a task you hand to an agent, and often several tasks at once. A tool for that work needs a different shape. The name the industry is settling on for it is the ADE, the agentic development environment.
Leon is one. We build it, so read the definition below with that in mind, but the definition is not ours to invent: it describes tools from several vendors now, and the criteria are checkable against any of them.
The short definition
An ADE is a workspace built around agents instead of files. Its job is to run several coding agents in parallel, keep their work isolated from each other, and show you, from one place, what each one is doing.
That is the whole idea. Everything else in a given ADE is detail: whether it embeds a terminal, a browser or an editor; whether it is native or a web app; whether it costs money.
01
[ Repos ]
The projects you already work on. No imports, no new home for code.
02
[ Worktrees ]
One isolated checkout per task, so parallel agents cannot collide.
03
[ Agents ]
Claude Code, Codex, opencode, anything with a CLI. Side by side, not either/or.
04
[ Machines ]
This laptop, a workstation, a server. One tree, real terminals.
The parts every ADE shares
Implementations differ. The category has four working parts, and every serious ADE has some form of each:
- Isolation. Each task runs on its own checkout, almost always a git worktree, so two agents never write the same file. This is what makes parallelism safe rather than exciting.
- A session model. Agents are long-running and interruptible. An ADE remembers what each session is, on which repo and branch it works, and lets you resume it later without duplicates.
- Supervision. One surface that answers: is anything working, is anything waiting on me, is anything stuck or failed. Real terminals usually sit inside this, because most agents are CLI tools.
- A review path. The changes come back to you: diffs, or at least the terminals and git commands to inspect them. Where an ADE is weak, you review with plain git, which works but costs attention.
Speed and platforms are the tiebreakers in practice. A workspace started dozens of times a day should open instantly and weigh little, and it should run wherever your projects are.
ADE vs IDE: the table
| IDE | ADE | |
|---|---|---|
| Built around | The file you edit | The agents you run |
| Unit of work | A file, a symbol | A task, a session |
| Parallelism | One cursor (or a few splits) | Many agents at once, isolated |
| Isolation story | Branches, usually by hand | One worktree per task, by default |
| You look at | The editor | The fleet, then the diffs |
| Replaces | Your editor | The pile of terminals around your editor |
This is why the question ADE or IDE is the wrong question. Cursor, VS Code, Zed and JetBrains still edit code well. An ADE sits beside them, or inside them, and supervises the agents your editor was not built to herd.
Where the term comes from
The phrase agent development environment circulated first, then agentic development environment overtook it as agents became the thing being developed with, not just the thing being built. Terminal makers picked it up for their own products, and tools from Stably AI, Conductor, Superset and others now share the same shape: worktree per task, sessions in a tree, agents in terminals.
The category settled quickly on one convention. One worktree per task. It appears in almost every tool because it is the smallest change that makes parallel agents safe, and it uses nothing but git.
Do you need one?
You probably do not need an ADE if one agent at a time, in one repo, in one terminal, is working well for you. That setup is excellent and free.
The signals that the setup is outgrowing itself:
- You run two or more agents, and at least once a week you forget which terminal is doing what, or which is waiting on you.
- Two agents have touched the same file, or you switched branches under a running agent and paid for it.
- You work across repos, or across a laptop and a server, and assembling SSH plus tmux by hand has stopped being fun.
- You want the history of what you asked and what agents answered to be searchable, not scattered across scrollback.
How to choose one
Six questions, in the order that usually decides it:
- Is it agent-neutral? A workspace tied to one vendor stops being useful the day you add a second agent. This is the one that hurts most when it goes wrong.
- Does it run where you work? macOS only rules out whole machines. macOS, Linux and Windows, from one codebase, is unusual and worth noticing.
- What does it do about review? Diff-first tools and terminal-first tools both work; a tool with no story at all pushes you back to plain git.
- What is the licence? Open source (Apache-2.0, MIT) is forkable and auditable. Source-available and closed tools can still be excellent, but check what you are allowed to do.
- How does it handle remote machines? SSH is table stakes. A relay that pairs machines with a code, end-to-end encrypted, is the newer, kinder option.
- How fast and how big is it? A workspace you open all day should be small and instant. Published, measured numbers beat adjectives.
Where Leon fits
Leon is a native ADE: Rust, a GPU-rendered UI, a 23 to 27 MB download, on macOS, Linux and Windows. It runs Claude Code, Codex, opencode and 40 more built-in terminal agents, plus custom ones, each in a real terminal on its own worktree, in one tree across projects and machines. History for Claude Code, Codex and opencode is searchable in 1 to 2 ms over about 14,700 messages, measured on one M1 Pro.
It is Apache-2.0 and free. Bring the agent subscriptions you already pay for. The review loop and orchestration are planned, not shipped; today you review in the terminal and with git, as usual. We will keep saying that out loud.
If you are evaluating the category, compare Leon against Orca, Conductor, Superset and others, or download it and run your next two tasks side by side. The difference between an IDE and an ADE is easier to feel than to read about.