AI coding agents: direct and verify, don't ask and paste

The gap is the operator, not the model

Two developers can use the same model and get very different results. Prompt wording explains very little of that difference. Most of it comes from how the work is run. An AI coding agent is more than autocomplete and more than a chat window. It plans a task with many steps, edits several files, runs shell commands, runs the test suite, and reads its own errors. That autonomy is why people want one. It is also what changes the risk. With autocomplete you read a line before you accept it. With an agent you review work you never watched happen.

DevTools Academy's practical guide to AI coding agents puts the framing I keep coming back to. Move from ask and paste to direct and verify. Stop treating the model as a source of answers you copy. Treat it as a junior engineer who never gets tired, takes every word you say literally, and never says "I am not sure about this". A junior like that does real work when someone sets direction, splits the task up, and checks the output. So does an agent. The rest of this guide is that management discipline, in the order the work happens. Plan, delegate, review, test. Only then decide whether to run more than one agent.

Plan before the agent touches code

Planning is the step almost everyone skips. It is also the step that pays back the most. When I trace a failed agent run backwards, I almost always find the same cause. Someone wrote the prompt in ten seconds, and asked for an outcome nobody had defined. The model itself is rarely the limit.

A plan that is ready for delegation answers four questions:

• What changes, and why. "Add Google login" is not enough. Say which flows change, what stays untouched, and what the change is for.
• Where. Which files, components, and boundaries the work should touch. If you do not know, find that out first. Do not leave it to whatever the agent happens to retrieve.
• What can go wrong. The edge cases and the failure scenarios. Code that only handles the case where everything works will skip them unless someone names them.
• What proves it is done. The tests or checks that make "finished" a fact instead of a feeling.

The agent is genuinely useful inside this step, before any code exists. I ask it to outline what would have to change, given how the current code works. I ask it to list the edge cases I have missed, and to name the files it would touch. Those answers sharpen the plan. The decisions stay mine. All of the judgment goes into the plan, and judgment is the one thing I never hand over.

My working rule: if I cannot state the plan in a few plain sentences, the agent cannot carry it out reliably. Vague instructions produce confident nonsense. The opposite mistake is real too. A plan only has to give me and the agent the same picture of the work. When the plan takes longer than the change itself, I have stopped planning and started avoiding the work.

Scope the delegation, not the dream

"Build the whole feature" is the prompt behind both the impressive demos and the expensive messes. The agent will finish something, because finishing is what agents do. Whether it finishes the thing you wanted depends on how the work was scoped.

I delegate in slices that map to the plan: one migration, one endpoint, one component wired to the real backend. Each task names the part of the plan it implements. That keeps the agent anchored to decisions already made, instead of re-deciding them halfway through a file. Between slices I look at what came back. Drift caught at step two costs one sentence of redirection. Drift found at the end can cost the whole branch.

Knowing what not to hand over matters just as much:

• The thirty-second edit. Explaining it takes longer than typing it.
• Logic where the domain lives in your head. If the correct behavior exists only in your understanding of the business, the agent is guessing, and it will guess fluently.
• Anything you cannot verify. If no test, type check, or review would catch a wrong answer, you are gambling.

For the hard middle ground I use a hybrid. I write the tricky function or the pseudocode myself, and I delegate the scaffolding, the wiring, and the tests around it. I also watch for the sunk-cost trap, the urge to keep repairing work only because time already went into it. A half-finished agent branch feels like progress, so patching it again is tempting. If the second round of patches is undoing the first, the scope was wrong. Throw the branch away and slice the work again. The code was cheap. That is the point.

Review it like a confident stranger wrote it

Agent-written code needs more scrutiny than human-written code, not less. The reason is fluency. A tired human writes code that looks tired. An agent writes wrong code with the same polish as right code. So the way a diff looks tells you nothing about whether it works. The formatting is clean, the naming is plausible, and the bug sits in the part that matters.

What I actually check, in order:

1. Does the diff solve the stated problem, or a nearby one? Agents drift toward the problem that is easiest to finish.
2. Data flow. Where values come from, where they end up, and whether the change fits the existing architecture or works around it.
3. The unhappy paths. Error handling, timeouts, empty states. Generated code assumes everything works.
4. Sensitive surfaces. Anything touching auth, payments, input validation, or concurrency gets read twice. A wrong answer costs the most in those places.
5. What changed that nobody asked for. Silent extras, helpful refactors, and edited tests are where the work quietly grows past what you asked for.

The agent presents all of it with total confidence, because it cannot tell you how sure it is. The doubt has to come from the reviewer. AI review tools can sort a diff and point at likely problems, and I use them. But they miss the same things the agent missed. The judgment call stays human. I wrote up what a month of this rhythm did to my throughput in my AI-assisted development experience report.

Trust tests, not confidence

In review, the doubt has to come from me. Tests apply the same doubt automatically, at almost no cost. An agent's assessment of its own work is worth nothing, and that stays true however much you delegate. The only verification that grows with delegation is proof you can run. The suite passed, the type check passed, the bug no longer reproduces.

Two practices do most of that work. First, I ask the agent to propose edge-case tests from the plan. Then I read those tests as carefully as the implementation. A weak test is worse than no test, because it turns "unverified" into "falsely verified". Second, I never let an agent resolve a failing test on its own. The worst failure mode in agentic coding shows up here. It is called test overfitting. The test and the code both get edited until they agree with each other. Told to turn a red test green, an agent will sometimes change correct code to satisfy a wrong test. Sometimes it quietly edits the test to accept wrong code. Both runs end green. Both are regressions hidden behind a passing test.

The fix has to be structural. The agent that wrote a change does not get to decide what the test means. Author and judge stay separate. On any diff that edits a test, a human reads the test before the code.

Parallelize for isolation or coverage, never for speed

One well-directed agent handles far more than most people expect, so my default is one. Multi-agent setups are worth the extra complexity only when they solve a specific problem, and I have found exactly two of those.

The first reason is context isolation. A single agent carries one growing context through every subtask. By the time it reaches the migration, that context is still full of details from the UI work. The fix is to split the work into focused agents. Each one gets a narrow set of tools and only the context its own task needs. This has nothing to do with speed. It keeps each piece of reasoning clean. The second reason is coverage. When a problem has independent parts, separate agents can explore them at the same time. A lead agent then combines the results. The DevTools Academy guide, as it stands today, puts the cost of that thoroughness at several times the tokens of a single run. My own bills agree, so I pay it only when missing one of those parts would cost more than the compute.

Two rules keep parallel work from turning into chaos. The first rule is that dependent steps stay sequential. Parallelizing work that shares state just produces merge conflicts. The second rule is one writer per checkout. Two agents editing the same working copy at the same time produce changes nobody can explain. If the coordination layer itself is what interests you, I mapped the patterns in multi-agent systems.

The failure modes I catch early now

After enough delegated runs, the failures stop being surprising and turn into a checklist:

• Plausible and wrong. The diff reads well and fails at runtime. Tests catch it. Skimming never does.
• Wrong-file confidence. In a large repo, retrieval finds a near-match and the agent edits it without hesitation. Caught by asking for the file list at planning time.
• Conventions violated politely. Every repo has rules nobody wrote down, and the agent breaks them in perfectly formatted code. Fixed by writing the conventions somewhere the agent reads.
• Self-review blindness. An author judging its own work shares the assumptions that produced the bug. Fixed by a separate reviewer.
• Green-but-wrong. Test overfitting, covered above. Fixed by keeping humans on every edited test.
• The zombie branch. Half-finished work that keeps absorbing patches because deleting it feels wasteful. Fixed by re-scoping early.

None of these are unusual. They are what happens when direct and verify slips back into ask and hope.

How delegated coding work runs in an Aldena room

I built Aldena because this discipline works and I got tired of enforcing every step of it by hand. A room is an isolated workspace with its own server. The loop above, plan, delegate, review, test, is built into how a room runs. Inside it, the structure does the enforcing instead of me.

The agents clone the repository onto that server, install what the project needs, and run the real test suite there. Into the room you hire named roles, and the boundaries between those roles are what enforce the loop. Vera, the analyst, asks her clarifying questions before she writes a spec with acceptance criteria. That makes the planning step mandatory. Atlas slices the approved spec into work items, and waits for explicit approval before creating a single ticket in Jira or Linear. Magnus, the engineering manager, delegates the build down the org chart, the reporting line you draw between the roles. Everyone in the room works on the one checkout that room's server holds. So he hands work to a single report and waits for the reply before starting the next. That is what keeps two agents off the code at the same time. Then he commits, pushes, and opens the pull request. He never writes the code himself, and he leaves his own request open for you to merge.

The review discipline is structural too. Argus, the staff engineer, checks the diff for several different kinds of problem and reports findings without ever editing the code. That is the author-and-judge separation built into the product, instead of a rule someone has to remember under deadline. When something breaks, Orion reproduces the failure first, fixes the root cause, and adds a regression test so it cannot come back.

Verification gets the same treatment. Every tool an agent can call carries an allow, ask, or deny policy. Anything set to ask pauses the run and shows me the exact call before it happens. That makes human in the loop a setting I control per tool. Memory closes two failure modes from my list. Room memory holds the default branch and the conventions nobody wrote down, so agents stop breaking them politely. Reviewers record which failures existed before the change, so the team stops re-diagnosing the same broken test.

Parallel work follows the two-constraint rule from above. Rooms are the isolation boundary. Two rooms can work on the same repository. Each one clones onto its own server and opens its own pull requests, with separate credentials and separate memory. That is parallel coverage without shared state, and it is the only kind that is worth the cost.

Start with one task you can verify

The way into all of this is one bounded task this week with a result you can check. A reproducible bug with a failing test works. So does a small endpoint with a written spec. Plan it in four sentences and delegate it in slices. Review the diff without trusting how good it looks, and let the suite say whether it worked. If the loop holds, widen the scope. If you want the version where a whole team of agents runs this loop, I wrote a setup walkthrough for building an AI agent team.

The software developers getting real work out of coding agents are not better prompters. They are better managers of this loop. Delegate one verifiable task today, and let the results, not the confidence, decide what you delegate next.