I’ve been doing agentic coding seriously for about six months now. In that time, I’ve developed some opinions about what works and what doesn’t. I’ve also started to get conviction on what my ideal development environment would look like, a setup that doesn’t fully exist today, but that I find myself wishing for constantly.

The core insight I keep coming back to is this: the development environment itself should be disposable, but the session, the ongoing collaboration between me and the agent, needs to be durable. We’ve got this backwards in most current setups.

The Environment as a Template

Every project I work on has a specific shape. There’s an OS, a set of dev tools and their configurations, an AI agent with its own configuration and MCP tools, credentials for git and our build system, and hardware requirements. For the complex systems I work on, I often want beefy instances: 96 Graviton4 cores and 192GB of memory isn’t unusual when running integration tests that spin up an entire system locally.

I’ve started thinking of all this as a template. A declarative spec that defines what "a dev environment for Project X" means. Version controlled, reproducible, and something I never have to think about when I’m starting work on a new feature.

One Feature, One Environment

For each feature or change set I’m working on, I want to spin up a fresh instance of that template. I’m an EC2 guy, so launching a new instance per feature feels natural to me. Some folks might prefer containers - that’s fine, as long as we all remember that containers aren’t a security boundary.

The property I care about is isolation. My work on Feature A shouldn’t be able to interfere with Feature B, and neither should affect what my teammates are doing. This becomes especially valuable when you’re running multiple workstreams in parallel. I might kick off an agent on a refactoring task, then spin up a separate environment to explore an alternative approach to something tricky.

Sessions That Survive Reconnects

Once the environment is up, I start a session to interact with the agent. A web interface makes the most sense to me, though SSH could work too. What matters is that the session survives reconnects, laptop sleeps, and network hiccups. I shouldn’t need screen or tmux as a workaround.

Crucially, the agent should keep working on its current task even when I’m disconnected. If I kick off a refactoring job and close my laptop, I expect to come back and find progress, not an agent waiting for me to reconnect. The session is durable in both directions: I can pick up where I left off, and the agent doesn’t stop just because I walked away.

If I close my laptop Friday afternoon and open it Monday morning, I want to see what the agent accomplished, review the work, and continue from there.

Full Access, No Abstractions

Within the session, I want the full agent, including plan mode, MCP tools, sub-agents, context management commands, whatever it supports. Not a simplified interface. The most productive sessions happen when I can move fluidly between interaction modes: sometimes autonomous execution, sometimes collaborative thinking, sometimes using specialized tools.

Most features I work on span multiple commits and multiple sessions over hours or days. The session needs to handle that.

Building Up Memory

As the session continues, it should accumulate memory of the work. What files we’ve touched, what approaches didn’t pan out, what constraints we discovered. Context windows have limits, but a session layer could maintain structured summaries that get fed back to the agent. Deep into the session, the agent should still have memory of the original goal wet set out to achieve in this session.

Rollback

This is something I haven’t seen done well anywhere: rollback. At any point, I want to revert to a previous state. Not just the git repo, but the agent’s context too. Sometimes you spend an hour on an approach that turns out to be a dead end. Today, unwinding is painful. You can git reset, but the agent still carries all that context about the abandoned path.

I want checkpoints where I can go to the previous state of the session and have both code and context snap back. Ephemeral state like build artifacts or temp files can stay - I’m talking about the meaningful state.

IDE Access via SSH

At any point, I want to jump into my IDE (RustRover, in my case) and browse the code. Not through a chat interface or web diff viewer, but my actual IDE, where I can navigate symbols, build the project, run and debug tests, and understand what’s happening.

Sometimes I want to take over and make changes myself. Maybe I spot a subtle bug, maybe I have strong opinions about a particular function. The environment should support this seamlessly: I make changes, commit, hand control back to the agent.

Most IDEs support remote development via SSH, which is one reason I favor EC2 instances. SSH is the universal adapter.

Parallel and Quiescable

I want multiple sessions running in parallel, each on its own instance, fully isolated. This isn’t just about multiple features - it’s about experimentation. Sometimes I want to try two approaches to the same problem and see which pans out.

A nice-to-have: quiescing idle sessions. If I haven’t touched one in a few hours, snapshot it, shut down the instance, restore when I come back. Good for costs without sacrificing durability.

Commit as Ceremony

At some point, I’m happy with the work and ready to push. This should be deliberate. When I decide to commit, the agent creates a summary. That summary, including all the prompts, and the diffs get archived and linked to the git commit.

As an added bonus, I’d love for that summary to be cryptographically signed and stored in a way that can’t be altered by the user. This creates an immutable record of the development process that becomes valuable down the line. Code review agents or security scanners could use it to understand not just what changed, but why and how. You could even imagine extensions to code browsing tools that let you ask about "history behind this line" and get back the full context of the session that produced it, the problem being solved, the alternatives considered, and the reasoning behind the final approach.

Only after archival does the environment get permission to git push. Once the push succeeds, the environment can be deleted. It served its purpose.

What Exists Today

Bits and pieces of this workflow exist in various forms, but I haven’t seen anyone put the whole thing together yet. The durable session that spans environment and agent, rollback across both, the signed commit ceremony with immutable history, that integrated experience isn’t available as far as I know.

In the meantime, I’ve been automating parts of this myself with scripts and workarounds. Spinning up environments from templates, checkpointing context, archiving session summaries. It works, but it’s held together with duct tape. And I’d really like for our tooling to start heading in that direction!