Agent Based Software Development: An Engineer's Guide

More agents create a handoff problem

At 09:17, four terminal windows are open. One agent adds tests. Another refactors a module. A third updates documentation. The fourth waits for input. Then a test fails. The refactor changed its target. Documentation still names the old interface. The developer copies fragments between prompts, checks diffs, and tries to remember which process changed the repository.

Better prompts might help. They do not repair a missing handoff. Adding agents without controlling handoffs can reduce delivery quality, because the failure sits between agents rather than inside individual prompts. Each agent may finish a sensible task while the combined change becomes harder to test, review, or even explain.

One coding assistant keeps the work inside one conversation. A fleet splits it across processes. That creates new questions. Which agent needs attention? Did the last command fail? What did the next agent receive? Which requirements changed while another process was running? The coordination layer must answer those questions from evidence, not from an agent's confident summary.

In a controlled 2022 GitHub Copilot study, developers completed a defined programming task about 55% faster than a control group, as summarized in the software engineering productivity benchmark report.

That result measures one bounded task. It does not price the cost of reconciling four processes on one changing repository. Fleet productivity depends on accepted changes and clean handoffs, not keystrokes or simultaneous terminals.

What does AuricIDE show while agents work?

AuricIDE shows each agent as a separate local process, then brings the run needing attention to the front. The attention list ranks failed agents first, then agents waiting on input, then possibly stalled ones. A developer can spot a failed command before opening every terminal.

Start several tasks, and the workspace shows one tile per agent with its terminal state. When a process fails, its tile moves to the top of that list. Open that tile. The terminal shows the evidence. Fix the cause or answer the prompt, then return to the other runs.

Each agent runs as a PTY child process on the developer's machine. That keeps normal terminal behavior: input, signals, screen output, and completion. One crash does not take every agent with it. The coordinator reads the child's exit status and maps it to success or failure. It does not accept a cheerful final line as proof.

The terminal remains visible. Permission prompts stay actionable. Environment errors stay inspectable.

AuricIDE places these mechanisms inside a desktop workspace, a design described in more detail in how an agentic IDE can coordinate local coding work.

How does a chain hand work forward?

A chain hands work forward by running skills in order and giving each step a short, cleaned record of the one before it. A skill combines four choices: prompt, provider, model, and permission mode. The prompt defines the job. The provider selects the CLI. The model names the requested model. Permission mode sets the boundary for changes.

A combo runs those skills in order. One skill can inspect a ticket. The next can edit code. Another can run checks. A final skill can review the patch. The next skill starts with its own prompt, so its job stays explicit instead of inheriting a growing conversation from earlier steps.

The next step also receives the previous step's cleaned terminal tail. This is not raw stdout. AuricIDE strips ANSI codes, filters terminal chrome, removes duplicates, and caps the result at 2000 characters. That tail gives the receiving agent a compact account of the last run without feeding it an entire terminal session.

The cap has consequences. Old lines fall outside the cap. Earlier terminal output may be absent. Important details must also appear in the project record or repository, where the next skill can inspect them directly. A skill that ends with a precise result creates a better handoff than one that narrates every action.

Failure stops the chain. The next skill does not start after a failed step. That is annoying when a harmless tool error blocks later work. Continuing would turn one known failure into several uncertain changes. The developer can inspect the terminal, fix the cause, and restart with evidence.

The design separates two jobs. The terminal tail says what the prior process reported. The repository and project record show what remains true. A review step needs both.

What does local coordination cost?

Running everything locally costs portability and unattended runtime. It also takes time to set clear task boundaries before several agents can help. AuricIDE keeps goals, tickets, requirements, tests, and dependencies in a SQLite file inside the project folder and tells git to ignore it. That file does not arrive with a fresh clone. A second developer sees the code, but not the local goals, tickets, test records, or chain history. Moving that record requires a separate choice.

Local processes also inherit local problems. Missing tools, shell setup, credentials, and permission prompts can block a run. AuricIDE keeps those failures visible, but visibility does not remove them. There is no remote service to finish work after the machine sleeps or closes.

More agents also create review work. Parallel steps are a poor fit when they edit the same files or depend on one undecided interface. Sequence is safer there. Independent documentation and test work may run side by side once their inputs are fixed. The split must come from the work, not from an available agent slot.

Model benchmarks leave that review cost out. METR defines a 50% time horizon as the amount of expert time for tasks an agent can finish autonomously with 50% probability. In its software task evaluations, that solvable task length doubled about every seven months (METR's task-duration analysis).

On a 500-task SWE-Bench Verified subset, one model reached 49% resolution versus a previous 45% (Anthropic's benchmark description).

Those benchmarks describe model performance under defined evaluations. They do not decide whether two agents should touch the same branch today. Repository coupling, verification cost, and the clarity of each handoff still decide whether a fleet saves time.

What still applies in another tool?

The portable lesson is simple: make every handoff small, inspectable, and able to stop. Process status should come from the process. A success message is weaker evidence. The next agent should receive a bounded summary plus access to durable requirements and current files. Failed verification should block dependent work.

Keep three records distinct. The terminal explains what happened during the run. The repository diff shows what changed. The project record shows what the work was meant to satisfy. When those records disagree, another agent should not guess.

Permission boundaries belong in the handoff too. A reviewer needs to know which task ran, which provider and model handled it, and what that step could change. Otherwise a passing test can hide a much wider edit than the task allowed.

This scales down as well. Two shell sessions need the same discipline as a fleet when each acts on the other's output. Name the step. Bound its inputs. Check its exit status. Inspect the diff. Stop on failure. Coordination earns its cost only when it makes the work easier to understand.

Visit AuricIDE to examine how its process supervision and handoff design can support agent based software development without hiding failure points.