DEV Community: Everton Kozloski

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

Everton Kozloski — Mon, 28 Sep 2026 17:07:11 +0000

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.

Integration Guard: Safely Merging Parallel Concurrent AI Agents from Git Worktrees into Main

Everton Kozloski — Wed, 26 Aug 2026 15:01:41 +0000

Modern coding-agent workflows often run several agents in parallel. Each
agent works in its own Git worktree and branch, while all changes eventually
need to land on a shared target branch such as main.

This model provides isolation and speed, but introduces a difficult question:

How can multiple agents work concurrently without losing commits,
overwriting changes, or silently creating a semantically broken
integration?

This article presents the design of the Integration Guard, the subsystem implemented in Vibe Kanban Alternative, an independent, self-hosted fork of Vibe Kanban, to coordinate parallel agents and safely integrate their work.

The problem with parallel worktrees

A typical setup looks like this:

Each agent has its own isolated filesystem and branch. This prevents agents
from directly modifying each other’s working directories.

However, the target branch can change while an agent is still working:

Agent A starts at main = H0
Agent B completes and updates main = H1
Agent A finishes using its original branch
Agent A now needs to integrate into H1

A naïve implementation usually chooses one of these approaches:

Force the agent to rebase before merging.
Let the agent update the target branch directly.
Use a temporary filesystem lock.
Compare only filenames.
Assume Git conflicts are the only problem.

Each approach has weaknesses.

A rebase is not always necessary. If Agent A changes auth.rs and Agent B
changes billing.rs, their work can usually be integrated safely even though
main advanced.

A temporary lock such as /tmp/vk-merge-lock does not coordinate separate
backend processes reliably.

A blind reference update can silently overwrite another agent’s commit.

And Git does not detect every semantic conflict. Two agents can modify
different lines in the same function and still produce incompatible behavior.

The Integration Guard architecture

The system separates three responsibilities:

1. Agent Activity Observer

The observer exposes which agents are currently active, what they intend to
change, and which workspaces they belong to.

A declaration can include:

Agent name
Execution owner
Workspace
Intent
Expected files
Expected symbols
Semantic dependencies
Execution ID
Lease expiration time

The UI can then show information such as:

Agent A — implementing merge_changes in crates/git/src/lib.rs
Agent B — updating complete_workspace_card in crates/mcp/src/...

This information is available through the backend and MCP, rather than
relying on Mem0 or an agent’s conversation history.

### 2. Soft reservations

Agent declarations are intentionally soft reservations.

If Agent A declares auth.rs and Agent B declares auth.rs, Agent B is warned,
but is not automatically blocked.

This is important because the developer may know that the two agents are
working on independent sections of the same file.

The system therefore separates:

Awareness during development
Enforcement during integration

Agents can continue working in parallel. The Integration Guard performs the
final validation before writing to the shared target branch.

3. Integration Guard

The Integration Guard is responsible for the short critical section where a
branch is validated and integrated.

It uses a database-backed lease scoped to the repository. This serializes the
validation and Git write across backend processes.

The lease prevents two independent backend requests from simultaneously
validating the same target and then racing to update it.

The HEAD-aware integration algorithm

The central idea is to use the task’s original branch point as the common
ancestor.

Let:

H0 = original common ancestor between the task branch and target branch
Ht = current target branch HEAD
Ha = current agent branch HEAD

The Integration Guard computes:

task_diff = diff(H0, Ha)
target_diff = diff(H0, Ht)

The complete flow is:

The important detail is that an advanced target branch does not automatically
force a rebase.

Independent changes

Suppose:

H0: initial project state
Agent A: changes auth.rs
Agent B: changes billing.rs
Ht: includes Agent B's changes
Ha: includes Agent A's changes

The three-way merge can combine both changes:

H0
├── target_diff: billing.rs
└── task_diff: auth.rs

Result:
├── billing.rs
└── auth.rs

Agent A does not need to rewrite its branch history merely because Agent B
finished first.

Real textual conflicts

If both agents modify the same lines or incompatible hunks, Git reports a
conflict.

The Integration Guard then:

Does not move the target branch forward
Does not mark the card as Done
Returns a structured conflict
Leaves the card open for review

The operator can then decide whether to resolve the conflict manually, rebase
intentionally, or change the task scope.

Semantic conflicts beyond Git

Git detects textual overlap. It does not understand contracts, APIs, or
behavior.

For example:

Agent A changes:
UserService::create_user()

Agent B changes:
API code that depends on the return value of create_user()

These changes may touch different files and different lines, yet still be
incompatible.

The current semantic detector uses declared dependencies:

This is intentionally conservative. It is not a full AST or behavioral
analysis system, but it catches a class of conflicts that file-level
comparison cannot.

A semantic conflict is reported before Git writes to the target branch.

Why Mem0 is not the coordination layer

Mem0 is useful for durable project knowledge:

“The merge API now requires a validation step.”
“This module owns the authentication contract.”

But it is not suitable for real-time coordination because it can be:

Asynchronous
Temporarily unavailable
Stale
Inconsistent with the current transaction state

The system therefore uses:

Sources of truth

Current active agents: Database
Work declarations: Database
Leases and reservations: Database
Merge serialization: Integration Guard lease
Durable architectural decisions: Mem0
Operator visibility: Backend API and UI

Mem0 stores semantic memory. The database stores current state.

The pipeline integration

Previously, a pipeline could instruct an agent to manually:

Rebase its branch
Create a commit
Update the target ref
Use a temporary merge lock
Verify the result by checking the moving branch tip

That approach put repository coordination logic inside an agent prompt.

The new pipeline contract is simpler:

Agent completes implementation and verification
↓
Agent calls complete_workspace_card
↓
Backend invokes Integration Guard
↓
Guard validates and integrates safely
↓
Card moves to Done only after success

The agent no longer needs to know how the target branch is updated.

The pipeline stage is now named:

Integration Guard → Done

The agent is explicitly instructed not to manually rebase, update refs, or
use temporary locks.

The technical result may still be a single integration commit, but the
responsibility belongs to the backend integration layer rather than the
agent.

Concurrency control

The database lease protects the critical integration sequence:

This prevents the classic race:

Request A reads main = H1
Request B reads main = H1
Request A writes main = H2
Request B writes main = H3

Without serialization, the second operation may be based on stale state.

Failure behavior

The Integration Guard follows a strict rule:

A card is marked Done only after the target branch has been successfully updated.

Typical outcomes

Target advanced with independent changes: Three-way integration succeeds.
The same lines changed: Git reports a conflict and the card remains open.
A declared semantic dependency overlaps: The merge is blocked for review.
Another integration is active: The request waits or returns integration_in_progress.
The target worktree is dirty: Integration is refused.
Integration succeeds: The declaration is released and the card moves to Done.

This makes failure visible instead of silently converting an incomplete
integration into a completed card.

Testing strategy

The implementation includes automated Git safety tests for:

Target branch advancing before integration
Independent changes being merged successfully
Delete-versus-modify conflicts
Base reference remaining unchanged after a conflict
Dirty target worktrees
Concurrent integration safety

The repository also contains a manual acceptance runbook for testing with two
real agents:

Start Agent A in Workspace A.
Confirm its declaration appears before the first edit.
Start Agent B in Workspace B.
Confirm both agents are visible in the Active Agents panel.
Declare a semantic dependency conflict.
Attempt integration while both declarations are active.
Confirm the merge is blocked.
Release Agent B’s declaration.
Retry integration.
Confirm the target branch changes only after successful validation.

This manual test is important because it crosses real process boundaries:

Backend
Database
MCP
Executor
UI
Git worktrees

Current limitations

The system is intentionally conservative and local-first.

The semantic detector currently relies on declared files, symbols, and
dependencies. It does not replace:

AST analysis
Type checking
Integration tests
Human review
Product-level reasoning

The UI currently presents active work through a polling activity panel.
Future improvements could include:

Event-driven activity updates
Richer symbol extraction
Automatic dependency discovery
Historical integration timelines
Conflict visualization
Strong reservations for critical symbols

Conclusion

Parallel coding agents are valuable only if their work can be integrated
safely.

The Integration Guard addresses this by combining:

Real-time agent observability
Soft work declarations
Database-backed integration serialization
HEAD-aware diff calculation
Semantic overlap detection
Git three-way integration
Explicit conflict handling

The key design decision is simple:

An advanced target branch is not automatically a reason to rebase. Compare the task against its original branch point, let Git perform a three-way integration, and require review only when there is a real textual or semantic conflict.

This allows multiple agents to work independently while keeping the shared
target branch protected, predictable, and auditable.

The main implementation lives in:

crates/server/src/routes/workspaces/git.rs — Integration Guard flow
crates/git/src/lib.rs — Git diff and three-way integration logic
crates/db/src/models/agent_work.rs — Agent work declarations
crates/db/src/models/integration_guard.rs — Repository integration lease

The complete implementation is available on GitHub.
Feedback and technical discussion are welcome in the repository issues.