The Missing Layer Between AI Sessions: ADEs and Beyond

There’s a shift happening in how software gets built at AI-forward companies and if your company constrains your AI budget you might not see it. It’s not the shift we read about in X posts, the one where an agent writes a whole feature from a single prompt. That shift is real, but it obscures a more immediate, more human problem: the cognitive cost of managing the increasing work that AI is doing on our behalf.

More Sessions, More Context, More Switches

If a company has successfully made the shift into tools like Claude Code then the number of concurrent tasks individual developers are managing has gone up. It’s not because they’re writing more code (in many cases we’re writing less), it’s because the bottleneck has moved. We’re no longer the person implementing a fix. We’re the person who scopes the fix, launches the session, reviews the output, provides the judgment call when the agent deviates from the plan, and then we switch to the next task and do it all again. Multiply that by 2 or 3 because we’re doing it in parallel with other tasks, not sequentially.

Each of these tasks carries its own context and in my case, can even operate across multiple codebases. The database migration for the API service has a different set of constraints than the design system refactor, which has a different set of constraints than the flaky e2e test investigation. As the agents get better and they take on larger, more architecturally significant work, the context per task gets heavier, not lighter.

The tools reduce implementation time, but they increase the cognitive overhead of orchestration. We’re running a small team of agents, and I’m the only project manager.

The Factory Floor, Eventually

I think the industry is heading toward what some are calling software factories (I don’t like the dystopian imagery this term creates). That said, if we attempt to tier the kinds of tasks that engineering teams handle (critical bug fixes to read paths, fixes that mutate state, minor enhancements, configuration changes, dependency bumps) there’s a tier at the bottom where a well-configured agent with the right guardrails can ship a change end-to-end without a human in the loop. The agent reads the ticket, understands the codebase, writes the fix, runs the tests, and opens the PR. Automatic quality gates provide confidence. New novel checks such as plan deviation flag risk. A human might then review it, or another agent might.

However this upcoming shift is deeply contextual to the project. It requires mature test suites, well-documented conventions, stable APIs, and a level of codebase legibility that many production systems don’t have. Not all companies have the sophistication Stripe has. As of August 2026, for most real-world production codebases, we’re not there yet. We’re in the messy middle: agents are powerful enough to do serious work, but they still need a human to steer, to prioritize, and — critically — to context-switch between them.

The Missing Project Management Layer

What struck me was that there’s no good answer to a simple question: what are all my active Claude sessions doing right now, and which ones need me?

I find myself with 3-5 terminals open. One finished ten minutes ago and I didn’t notice. Another is waiting for permission to proceed. A third is running fine but I’ve lost track of what I asked it to do. It’s a project management problem dressed up as a terminal management problem.

I started reading and following projects called Agent Development Environments (ADEs), but to understand the bounds, I opted to first build something myself: Claude Todo.

The idea is deliberately simple: a native desktop app that gives developers a to-do list view of their Claude Code sessions. Not a dashboard, not a workflow engine… just a to-do list. It’s the most basic representation of “here’s what needs to get done”. The developer can add tasks, configure them with a project directory and CLI flags, and launch Claude Code sessions directly from the app. The app tracks which sessions are running, which have finished, and which need attention. When a session requires input, it propagates the notification. When the developer is ready to switch context, they can focus the right terminal window with a click.

It’s a continuous stream. Developer completes tasks and adds more. They pause sessions and resume them later without starting from scratch. They control their environment through a project management layer instead of through raw terminal juggling.

Why You Should Build a Stateful Management System for Your Tasks

The data model behind Claude Todo is intentionally minimal, and in hindsight it mattered more than anything about the app around it. Tasks live in a markdown file with three sections — Not Started, In Progress, Done — and metadata is stored inline as pipe-delimited key-value pairs. That’s it. But it means the data is human-readable, version-controllable, and recoverable even if the app disappears entirely. The app was never the point. The state was.

That state is what made the tool worth using day to day. A status indicator shows which sessions are running right now, so “what is my agent actually doing” stops being a question I have to reconstruct from memory. If I stop a task instead of finishing it, the app preserves the session ID, so resuming later means picking up exactly where I left off instead of re-explaining context to a fresh session. None of that required a clever interface. It required the state to outlive the terminal window it started in.

The first goal was narrow: model the states a terminal can be in. Running, waiting on me, finished, stopped. That’s a small enough problem to finish in a weekend, and it’s genuinely the thing I thought I needed — I stopped losing track of terminals almost immediately.

But modeling terminal state kept sliding into modeling something else. A session isn’t really “running”, it’s mid-implementation. It isn’t “waiting on me”, it’s waiting on a scoping decision, or sitting in review, or ready to open a PR. Those are statements about where the work is in my process, not about a process on my machine. What I had actually started building, without meaning to, was a way to model the states of my own SDLC.

What I was optimizing for the whole time was concentration, in a system where I still drive everything. I wasn’t trying to remove myself from the loop. But once the work was laid out as state rather than as five terminal windows, the repetition got hard to ignore. The same moves, in the same order, task after task — how I do code review is the clearest example. I run the same checks, in the same sequence, and ask the same questions, and I had been re-performing that by hand every single time because nothing in my tooling knew that it was a sequence at all.

Hooks and skills are the right primitives for this, and they’re powerful. But neither of them is a workflow. A hook fires at a point in time. A skill is available when it’s relevant. Neither one says: this is the sequence, these are the states, this is where this piece of work is in it right now.

I haven’t released anything that does that yet. But that’s the leap I think nobody has made.

Enter the ADE

Which brings me back to the projects I’d been following before I built any of this. The industry has settled on Agent Development Environment, and I’ll admit some fatigue at yet another three-letter acronym arriving to name a problem that, a year ago, didn’t have a name because it didn’t really exist yet. But this one earns its acronym, so I’ll grant it.

The IDE was built around a single assumption: there’s a human, and the human types. Syntax highlighting, breakpoints, autocomplete — all of it is in service of one person writing text into a file, one keystroke at a time. It’s a good assumption, and it produced decades of genuinely useful tooling. It’s also increasingly not what’s happening at my desk.

The ADE starts from a different assumption: the human isn’t typing, they’re orchestrating. There might be several sessions running against several tickets in several repos at once, and the job is to launch them, watch them, catch the ones that need a human, and stay out of the way of the ones that don’t. Claude Todo, in hindsight, was the smallest possible version of an ADE — a to-do list and a focus button, built for an audience of one, with none of an actual development environment attached to it. It was proof that even that stripped-down a tool was worth building. It wasn’t proof that a to-do list was the ceiling.

ORCA: Ergonomics, Not Magic

The concrete instance of an ADE I’ve actually been living in is ORCA. Stripped to what it actually does, the feature list is short: it gives you ergonomic ways of managing terminals, and it automatically picks up tickets from Linear so a session can start against a real piece of work instead of me pasting a ticket description into a prompt by hand. That’s it. No workflow engine, no agent marketplace, no dashboard promising to replace your engineering org.

Described that plainly, it can sound underwhelming — surely the future of software development is more than a nicer way to manage terminal windows and a Linear integration. But that reaction undersells how much of the pain I described above was exactly that: mechanical, ergonomic, solvable by better tooling around the terminal rather than by anything clever. ORCA solves the problem Claude Todo was solving, properly, as a first-class part of the environment instead of a weekend app bolted onto the side of it.

The size of that boost scales directly with how many concurrent projects you’re running. On one project, ergonomic terminal management is a nicety — you’d probably survive without it, the way I survived without Claude Todo before I built it. Run three or four projects concurrently, each with its own set of agents at different stages of different tickets, and the terminal-hunting problem stops being a minor irritation. It becomes the difference between orchestrating and drowning. Automatically picking up tickets from Linear closes the loop further — I’m not even the one performing the mechanical step of turning a ticket into a session anymore. That’s the same gap Claude Todo was poking at with a markdown file and a native app. ORCA just closes it properly.

ORCA isn’t the only shape this can take. KiroCrew comes at it from spec-driven development: instead of modelling the SDLC as a workflow you sit down and define, the workflow is generated from the spec itself. I’m not ready to buy into Kiro right now — that’s a larger commitment than I want to make, and I’d want to watch it work on a codebase that wasn’t written with it in mind. But the underlying idea is the most interesting counter to everything I’ve described here. If the spec is the source of truth, a workflow derived from it beats one I hand-modelled, because the one I model goes stale the moment the work changes shape and the generated one doesn’t. That part I’m genuinely excited about, whoever ends up getting it right.

The Software Factory Needs More Than Ergonomics

Ergonomics alone is a productivity tool. It makes the same work less annoying to do, and given how much of my day used to go to finding the right terminal window, I don’t want to undersell that. But it’s not what turns a stack of concurrent agent sessions into a software factory. It’s what makes the stack survivable.

What actually gets you there is coupling the ADE with an opinionated SDLC — an actual encoded way of working, not a vibe or a wiki page nobody reads. In practice that means two things working together: strong skills, which carry the conventions and the house style that used to live in a senior engineer’s head and nowhere else, and hooks, which enforce the gates so quality isn’t a matter of the agent remembering to check something under pressure. Skills answer how something should be done. Hooks answer whether it actually got done. Miss either one and you’re back to babysitting — either the agent doesn’t know your conventions, or it knows them and skips them anyway, and you find out three files later in review.

I also don’t think the first version of this runs where people assume it will. The default picture is a fleet of agents in the cloud, working unattended overnight against a backlog, and I do expect we get there for some tier of work. But the step before that — the one I think we actually see first — still runs on local machines, with a person sitting next to it. Same laptop, same repos, same human making the calls, just with far more of the process encoded than any of us have encoded today.

Goose provides the closest thing I’ve seen to that intermediate step. Their recipes model deterministic workflows, which is the right instinct and more than most tools even attempt. But a recipe runs into the things that actually characterise SDLC work. It can’t express complex decision criteria. It isn’t especially durable. And human-in-the-loop steps sit awkwardly inside something designed to run start to finish — a recipe has no good answer for the gap where the work stops for two hours because a human needs to answer questions about a plan.

I said earlier that I’m not fond of the dystopian imagery the phrase “software factory” conjures, and I still am not. I also said the shift is deeply contextual — it needs mature test suites, well-documented conventions, stable APIs, and a level of codebase legibility that most production systems don’t have yet. None of that has changed. What’s changed is that I now think I know what closes the gap. Not a more capable model, not a friendlier terminal, but the combination: an ADE that makes orchestration ergonomic, running on top of an SDLC opinionated enough that the skills and the hooks do the remembering for you. Put those together and the tier of work I described earlier — the well-guardrailed agent that reads the ticket, writes the fix, and opens the PR without a human in the loop — stops being aspirational for the parts of the codebase where the guardrails are real.