DEV Community: Daniel Maß

AI agents should not just write code

Daniel Maß — Mon, 03 Aug 2026 05:59:32 +0000

They should be able to use the application they changed.

That sounds obvious, but most coding agent workflows still stop at editing files, running tests, maybe starting a dev server, and reporting back. For web apps, that is not enough.

A human developer does not only inspect diffs. They open the app. They click through the flow. They notice when the wrong tab is open, when a button does nothing, when the page changed unexpectedly, or when the browser is still pointing at yesterday's backend.

AI agents need that same feedback loop.

Browser state becomes coordination state

Once multiple agents are running in parallel, browser state becomes another coordination problem. Without isolation, browser tabs point to the wrong workspace, one agent clicks in another agent's app, authentication state leaks between branches, screenshots no longer match the running process, and the developer cannot tell which agent is doing what.

This is why Agent-Up now treats the browser as part of the workspace runtime.

Each workspace gets its own browser session, application tabs, port mappings, logs, and runtime state. Agents interact with that browser through MCP, so they can navigate to the app, inspect the page, click links and buttons, wait for text or selectors, take screenshots, and record browser activity into the audit history.

The important part is not just that the agent can click. It is that the click belongs to the correct workspace.

When an agent clicks inside its app, Agent-Up can switch the visible application tab for that workspace, move the agent mouse representation, show the click animation, and keep the developer's desktop view aligned with what the agent is actually doing.

The review experience changes

Instead of reading four terminal logs and guessing what happened, you can watch four agents exercise four isolated versions of an app at the same time.

One agent might test the login flow. Another checks pricing. Another walks through checkout. Another validates returns and fulfillment.

Same machine. Same repo.

But different worktrees, different runtime environments, and different browser sessions.

The browser is part of the feedback loop

This is the part of agentic development I think people underestimate: the browser is not just an output surface.

It is part of the feedback loop.

For web applications, an agent that cannot use the browser is missing the place where the product actually exists.

Git isolates the source. Agent-Up isolates the runtime. MCP gives agents control over both.

That makes parallel agent work easier to supervise because you are no longer only reviewing generated code. You are watching each agent operate its own version of the product.

That is what the demo was built to show.

Download Agent-Up:

https://agent-up.themassiveone.net/

Open source repo:

https://github.com/agent-up-oss/agent-up/

AI agents changed my opinion on vertical slices.

Daniel Maß — Tue, 28 Jul 2026 16:38:21 +0000

The old preference

For years, I preferred a traditional layered architecture.

Controllers/
Services/
Repositories/
DTOs/
Models/

It makes navigation straightforward. If I need a repository, I know exactly where to look.

The optimization target changed

Then I started working with multiple AI agents, and suddenly the optimization target changed. Imagine one agent implementing Shipping while another implements Billing.

With a layered architecture, they both end up touching controllers, services, repositories, tests, and dependency injection, even though they are working on different features. The implementation of a single feature becomes scattered across the entire project. So does the code review.

Vertical slices fit agent ownership

The model that worked better was organizing the code around features instead of layers. Shipping and Billing stop being scattered concepts that have to be reconstructed from several folders. They become visible parts of the project structure.

Features/
├── Shipping/
│   ├── Controllers/
│   ├── Services/
│   ├── Repositories/
│   └── DTOs/
│
└── Billing/
    ├── Controllers/
    ├── Services/
    ├── Repositories/
    └── DTOs/

Now each agent owns an entire feature, not just a few files spread across the solution. Reviewing changes becomes opening Features/Shipping instead of searching through controllers, services, repositories, DTOs, dependency injection, and tests in different places.

Tests by feature

The same ownership boundary applies to verification. If the implementation belongs to a feature, the tests that prove it works should be organized by that feature too. Otherwise the review still requires jumping between multiple layers within the test project aswell.

Features/
├── Shipping/
│   ├── HTTP/
│   ├── Repository/
│   └── Unit/
│
└── Billing/
    ├── HTTP/
    ├── Repository/
    └── Unit/

Each agent only owns the implementation and everything required to verify it. That keeps the task boundary clear: the agent changes the feature, updates the relevant tests, and leaves the rest of the system alone. Nothing more.

Observable ownership

I previously argued that event-driven architectures work well with AI because they make behavior observable. I think this is the architectural equivalent.

Vertical slices make ownership immediately observable. You immediately know which agent owns a feature, where to review its changes, and where its tests live.

The existing workflow pays off again

The interesting part is that vertical slices were not designed for AI. They were designed to improve cohesion. Agentic development simply exposes the same problems again: Agents need to coordinate with each other just like humans do.

The less coordination your architecture requires, the better it works for humans and AI alike.

AI-generated changes are easy to create and hard to review.

Daniel Maß — Tue, 28 Jul 2026 05:50:02 +0000

Large tasks rarely produce one logical change. They usually produce several changes that belong in separate commits, but without a dedicated workflow everything accumulates in the same working tree. Unrelated changes get mixed together, logical slices become harder to preserve, staging becomes risky, and reviews become larger than necessary.

A better workflow would preserve each logical slice as soon as it is complete. That slice should include the affected files, a proposed commit message, the relevant test commands, and the exact patch. Once preserved, the working tree should be restored so the agent can continue with the next slice independently.

But preserving slices is only half the problem. The agent should be able to organize the work without controlling Git history. The developer should still review every staged diff and create every commit manually.

That is what Agent-Up commits provides. Agent-Up commits is a local commit proposal queue for agent-assisted development. Agents enqueue proposals instead of creating commits, and each proposal stores its patch and message before restoring the working tree.

Later, the developer runs agent-up commits next. Agent-Up applies and stages exactly one proposal. With the JetBrains plugin, a single button takes the first proposal in the queue and opens it directly in the IDE's commit window. The developer reviews it in the IDE, runs the relevant tests, and commits it manually. Then the next proposal can be reviewed.

Agent-Up does not replace Git. It adds a safety layer between agent-generated changes and human-controlled commits, so agents can preserve logical slices while they work, developers can review one staged proposal at a time, and Git history remains under human control.

Get the JetBrains IDE plugin

https://plugins.jetbrains.com/plugin/33179-agent-up-commit-queue

Download agent-up CLI

https://agent-up.themassiveone.net/

What if MCP could manage your entire development runtime?

Daniel Maß — Sat, 25 Jul 2026 15:49:23 +0000

I created Agent-Up, an open-source desktop app and local server for running multiple coding-agent environments on one machine.

Worktrees isolate source code, not the runtime

The problem is that Git worktrees isolate source code, but they do not isolate the running application.

When several agents work on the same monorepo, each one may need its own:

application processes,
ports,
Docker services,
logs,
runtime state.

Without a shared runtime manager, agents end up coordinating those details through shell commands.

That is fragile.

One agent may reuse a port that another process still owns. A restart may leave an old process alive. Docker services may overlap.

Runtime isolation per workspace

Agent-Up manages those concerns per workspace.

Each workspace gets its own process lifecycle, allocated ports, Docker services, logs, and runtime state. The desktop app also provides one browser session per workspace for reviewing its web applications.

Agents control Agent-Up through MCP

The current MCP interface supports:

starting and stopping workspaces
listing registered workspaces
reading workspace status

The Agent-Up server owns the runtime state behind those operations. That means the agent does not need to independently discover ports, track process IDs, or reconstruct the application topology through shell commands.

The missing runtime layer for parallel coding agents

This is relevant because current coding agents are increasingly used in parallel.

The source-code side of that workflow is already well served by Git branches and worktrees.

The runtime side is not.

Agent-Up is intended to provide that missing runtime layer.

Planned MCP functionality

Planned MCP functionality includes:

browser inspection and interaction,
diagnostics,
screenshots,
health checks,
Playwright flow export.

Same workflow, more control

Git still owns branches, commits, pull requests, and merges.

Agent-Up just owns the local runtime around them.

Agent-Up is open source

You do not need to Dockerize your entire app to run multiple agent workspaces

Daniel Maß — Thu, 23 Jul 2026 07:11:35 +0000

When several coding agents run the same app, Docker looks like the obvious answer: put every frontend in a container, put every API in a container, and put every worker in a container.

It works, but it adds friction. Stale images can serve old code, rebuilds slow down feedback, caches hide what actually changed, images and layers clutter storage, and debugging gains another runtime layer.

With one workspace, that may be fine. With several agents, it gets noisy fast.

Local isolation does not require containerizing every process

Most collisions come from ports, processes, Docker services, browser profiles, logs, and environment state. Agent-Up isolates those directly.

Your apps can still run normally using npm run dev, dotnet run, or ./gradlew bootRun.

Each workspace gets its own ports, and each process receives the full port map. Another agent gets a different range, which means no collisions and no full app image rebuilds.

Docker still has a clear role

Use Docker for databases, queues, caches, and object storage. Keep app code local, and keep infrastructure in Docker.

Let Agent-Up manage both as one workspace

✅ Git isolates the source.

✅ Agent-Up isolates the runtime.

✅ Docker isolates infrastructure.

Check out the open source repo

https://github.com/agent-up-oss/agent-up

Downloads

https://agent-up.themassiveone.net/

Introducing Agent-Up: run multiple agent-built versions of your web app at once

Daniel Maß — Tue, 21 Jul 2026 17:28:32 +0000

Agent-Up is an open-source, cross-platform desktop app for running and reviewing multiple AI coding agent workspaces on the same machine. It is built specifically for web application development, where each agent needs more than just an isolated source tree — it needs an isolated runtime.

Every agent workspace in Agent-Up gets its own processes, stable ports, isolated Docker services, a dedicated browser session, grouped browser tabs, and its own logs and runtime state. Agents manage their environments through MCP. You review them all in one place.

The problem

Git worktrees solve source code isolation well. When you give each agent its own worktree, their changes stay separate and can be reviewed independently. But worktrees do not isolate running applications.

When several agents work on the same web app simultaneously, each may need to run a different version of the full stack at the same time. Without additional tooling, that quickly becomes unreliable:

Ports collide between workspaces
Old processes keep serving previous versions after an agent restarts its stack
Browser tabs point to the wrong workspace
Related frontend and backend tabs are not grouped together
Docker services conflict across workspaces
Authentication and browser state leak between sessions

The worst failure is the subtle one. An agent changes the code successfully and restarts its server — but your browser is still connected to a different agent's process. You are reviewing the wrong version and do not know it.

What Agent-Up changes

Agent-Up treats each workspace as a complete, isolated runtime environment rather than just a directory.

A workspace represents the entire monorepo: multiple web apps, APIs, workers, databases, queues, and Docker services. Each workspace gets stable, pre-allocated ports and its own browser session inside the desktop app. Its web applications appear as a dedicated group of browser tabs. Switching workspaces means switching the complete environment managed by that agent.

You always know which workspace you are reviewing, which frontend and backend versions are running, which browser tabs belong together, and which logs and processes belong to that workspace.

Multiple agents can therefore run different versions of the same full-stack web app simultaneously on one machine, without any of their environments interfering with each other.

How agents use it

An agent finishes its work and starts the new version through the Agent-Up MCP server. The server handles the rest: starting or restarting the required applications, spinning up declared Docker services, allocating conflict-free ports, injecting those ports into each process as environment variables, tracking logs and process state, and exposing the running web apps as browser tabs in the desktop app.

The entire stack does not need to be Dockerized. For many web applications, process and port isolation is already enough to run several versions concurrently without conflict.

One desktop app for all agent workspaces

Stop managing multiple terminals, port assignments, Docker stacks, browser windows, and browser profiles to keep parallel agent work straight.

Agent-Up gives each agent an isolated full-stack environment and puts the controls for all of them in a single desktop app. You can finally stop wondering whether you are looking at the correct version of your app.

Windows and macOS installers are available at agent-up.themassiveone.net.

Agent-Up is open source — view the code, report issues, or contribute at github.com/agent-up-oss/agent-up.