Six jobs worth staffing a company for
A multi-agent hierarchy with cost-aware routing is not better than a single agent at everything. It is better at work that has a decision in the middle of it, where being wrong is expensive and being slow is not — reading before writing, arguing about a seam, and checking the result against something other than the author’s opinion.
Each case below says what the problem actually is, how the hierarchy and the router address it concretely, what comes out, and — in its own section — where it would not be the right tool. That last part is the one that makes the first three usable.
What each one is really about
Ordered roughly by how much of the value comes from the reading and deciding stages rather than from writing code — which is also roughly the order in which the hierarchy pays for itself.
Legacy codebase modernisation
Understand the seams before you start cutting along them
A migration of a service nobody fully remembers — a framework upgrade, a module split, a runtime change — cut into reviewable steps that each land as real files and are checked by someone other than the author.
A feature in a service nobody on the team owns
Add the endpoint without first reading the whole service
Land a feature in a codebase you have not worked in — where the real risk is not writing the code, it is putting it in the wrong layer and inventing an abstraction that does not match the house style.
Technical documentation that is generated from the repository
Write docs against files that exist, on the turn they are read
Produce and refresh reference documentation — module maps, API surfaces, decision records — from the source itself, with the generated pages landing as markdown in a workspace you review before it merges.
Dependency and security upgrade sweeps
Ordered batches with a reviewer, not one hopeful auto-fix
Work through a dependency backlog in ordered, reviewable batches: what depends on what, what has to move together, what the upgrade breaks, and what the run could not prove.
Backfilling tests on untested code
Tests that fail when the behaviour breaks, not when it is refactored
Find the behaviour boundaries in code that has never been exercised, write tests against them, and have the run prove that each test actually detects a change.
Cutting model cost on routine work
Pay frontier prices for the decisions, not for the summaries
Move the routine turns of an agent workflow onto the cheapest models that can do them, and keep the expensive ones where being wrong is expensive — with a recorded reason for every route decision.
The pattern behind all six
They are not six different features. They are one shape of work, described in six settings, and the shape is what decides whether the hierarchy helps.
- The work needs reading before writing. If the correct change depends on what the code already does, the research stage is doing real work rather than ceremony.
- There is a decision in the middle. Where a change belongs, which upgrade order is safe, whether a branch is a contract — a decision with a wrong answer is worth a debate stage and worth a strong model.
- The result can be checked inside the workspace. QA can only falsify what it can run or read there, which is why build-and-test sweeps fit better than anything requiring a live environment.
- Being wrong is expensive and being slow is not. A bounded run that costs a few dollars to avoid a wrong migration is a trade; a run that costs the same to answer a question you knew is not.
Where none of this is the right tool
- When the change is fully specified and mechanical. A codemod or a scripted migration is cheaper, faster and deterministic; a hierarchy adds cost to something that had no decision in it.
- When the codebase already fits in one context window and one person owns it. The reading stage exists to solve a scale problem you do not have.
- When the real question is what the behaviour should be. Agents can document a disagreement beautifully; they cannot decide your product.
- When the work cannot be executed or read inside the run workspace. QA cannot falsify what it cannot reach, and a review loop with nothing to check produces agreement rather than evidence.
- When the requirement is invoice-accurate accounting. The catalog prices are routing estimates, not billing truth.
Every one of these runs on mock
With no provider keys configured the whole pipeline still runs against scripted employees, so you can walk the shape of a use case — the stages, the debate, the file writes, the review loop — before deciding whether to point it at a paid model.
The one thing that does not carry over is how a real model behaves on your brief. That is what the first paid run is for.
Bring one job, not a platform decision
The cheapest way to evaluate dev3d is to pick the use case closest to your backlog, run it against your repository in mock mode, and read the transcript. If the plan and the review are useful with scripted employees, they will be more useful with real ones.