Why an IDE Is Not Enough: Building an ADE (Agentic Development Environment)

An IDE organizes one person's work on code: editor, terminal, debugger, Git, and extensions. An Agentic Development Environment (ADE) must also organize the work of autonomous agents — including when they run in parallel, use different models, and build context over days.

That difference sounds semantic until you try to build the product. While turning AuraPunk into an ADE, the question stopped being “how do we put an AI chat inside the editor?” and became:

How do we turn agent execution into engineering work that can be planned, resumed, audited, and reviewed?

This post covers only the local side of that answer: workflow, state, memory, and tool integration.

IDE: a session. ADE: a work system.

In a traditional IDE, much of the state lives in the local session: open files, terminal, current branch, and editor history. Closing a terminal can end the operational context. Opening another machine creates another session.

In an ADE, work needs to outlive the session. A card becomes more than a visual Kanban item; it becomes the unit that connects intent, execution, and evidence:

card / SPEC
  ├── goal and acceptance criteria
  ├── context and decisions
  ├── selected agent and model
  ├── execution, logs, and artifacts
  ├── result and optional review
  └── retrievable memory

This sounds simple, but it changes the entire interface. Users should not need to remember which terminal started an investigation. They should be able to inspect a card and understand what was requested, what the agent did, what failed, and what comes next.

Parallelism is not “running it several times”

Running several prompts at once is easy. Running several agents without losing the relationship between task, context, and result is the real problem.

An ADE needs to split work into units that are independent enough to run in parallel, but connected enough that important decisions do not disappear. In AuraPunk, cards and SPECs give work an identity before execution begins.

The gain does not come from assigning every agent to the same task. It comes from making the split explicit:

• one agent investigates a codebase;
• another proposes or implements a bounded change;
• another writes or validates tests;
• a stronger model handles ambiguous decisions;
• a more economical model handles repetitive, well-specified work.

The ADE's job is to keep those executions connected to the same project without pretending that every agent has the same cost, capabilities, or reliability.

Choosing agents is part of the workflow

An IDE usually integrates tools. An ADE needs to orchestrate them.

AuraPunk ADE is designed to work with Codex, Claude Code, OpenCode, Qwen Code, Gemini CLI, Command Code, and Antigravity CLI. The goal is not to hide their differences behind a generic “AI” button.

Each agent has a profile: reasoning quality, speed, cost, available tools, interaction style, and ability to operate in a codebase. The choice should happen at the card level, based on the task.

Use the right agent and model for the kind of work — not the most expensive agent for everything.

A high-risk refactor, exploratory research, test generation, and a mechanical change do not require the same combination of agent, model, and supervision. An ADE should make that choice visible and recoverable later.

Memory is not a larger context window

A large context window helps, but it does not solve project continuity. It is temporary, expensive, and cannot reliably distinguish an important decision from disposable conversation.

A local ADE needs to preserve memory in layers:

• vector memory to retrieve semantically related material;
• semantic memory for consolidated facts, decisions, and preferences;
• graph memory for relationships between modules, tasks, dependencies, and decisions;
• SPECs and cards as operational memory that both people and agents can read.

These forms of memory do not compete. They answer different questions.

Question	Most useful layer
“Where did we discuss this problem?”	vector
“What did we decide about authentication?”	semantic
“Which components does this change affect?”	graph
“What remains before this task is done?”	card / SPEC

The point is not to save everything. It is to retrieve what matters when an agent starts its next step — and to keep that knowledge close to the project instead of scattering it across ephemeral chats.

Integration Guard: an integration cannot become unrestricted execution

Coding agents do not work in isolation. They need CLIs, Git, repositories, files, models, local tools, and sometimes MCPs. That makes the integration layer a central part of the architecture.

In AuraPunk, we call this boundary the Integration Guard: the rules that turn an integration into an explicit capability instead of an implicit, unlimited permission.

The principle is straightforward:

integration discovered
  → capability verified
  → command/action allowed
  → execution recorded on the card
  → result available for review

In practice, that calls for decisions a conventional IDE can postpone but an ADE should not:

• detect whether a tool is actually installed and ready before offering an action;
• explain missing requirements in useful language instead of exposing a process exception;
• separate tool discovery, configuration, and execution;
• limit actions to the open repository and task scope;
• record which tool and version performed work;
• keep users in control of actions that modify files, Git state, or configuration.

The Integration Guard does not exist to reduce agent autonomy. It exists to make autonomy observable and predictable.

Human review is optional; traceability is not

“Human in the loop” often becomes a mandatory queue and destroys the speed benefit. The alternative is not to remove control. It is to make review optional and contextual.

Some cards can move forward automatically: documentation updates, a test for an isolated component, or a mechanical change. Others deserve an explicit review: architecture changes, contract changes, sensitive code, or decisions that affect more than one agent.

What cannot be optional is traceability. For every execution, an ADE should answer:

• Which agent worked on this card?
• Which model and integration were used?
• What context was available?
• Which files, logs, and results were produced?
• What has already been attempted?
• Where was a decision recorded?

That history is what lets someone stop, return later, and continue the work without restarting the conversation from zero.

What makes an ADE different from an IDE?

An IDE can add autocomplete and remain an IDE. It becomes an ADE when it treats agents as participants in the development process and offers, natively:

• planning through cards and SPECs;
• multiple agent and model choices per task;
• parallel execution with organized context;
• persistent vector, semantic, and graph memory;
• guardrails for local integrations;
• auditable logs and work history;
• human review when it adds value, rather than as a universal requirement.

Building this is harder than integrating a model into an editor. But that is where the real difference appears: moving from a chat session to an environment where people and agents can work together without losing the thread of the project.

The editor remains important. It is simply no longer the center of the system.