Agent-driven development: build, test, and ship with coding agents

Agent-driven development means directing an agent through a software change you can verify. You supply the goal, context, limits, and acceptance checks. The agent edits and runs tools. You review the result and decide what ships.

You’re moving from writing every line to managing the work. You still need to understand the result, notice bad assumptions, and own the decisions. The agent can make mistakes very quickly. Let’s give it a job it can finish correctly.

We’ll add search to the invented Practice Bike Repair service catalog. You’ll leave with a reusable brief, a review checklist, and a small work record for cost and quality. I’m turning this field guide into a hands-on webinar; see the webinar plans for the planned session. No date or price is set yet.

You’ll need: a coding agent and a separate practice folder. Download the teaching pack, read its instructions, and open website/index.html. It is an original, dependency-free starter with three invented services and no real checkout or customer data.

You’ll finish with: working search, proof of the expected behavior, and a reusable brief. The process guide helps you choose an improvement first; it isn’t required for this exercise.

Jump to the brief, acceptance checks, or release review.

1. Name the result before picking the model

“Improve the site” gives the agent too much room. A useful brief says what happens now, what should happen, and how you’ll check it.

Goal:
Current behavior and reproduction:
Expected behavior:
Relevant files and approved evidence:
Must preserve:
Do not touch:
Acceptance checks:
Release boundary:
Report required:

Talk the context through if that helps you think. Then ask the agent to turn your explanation into this brief. Review its assumptions before implementation.

For our practice site:

Add search to the existing services list.
TUNE should match Tune-up without case sensitivity.
zzzz-no-match should show a useful empty state.
Clearing the field should restore every service.
Give the field a visible label and keyboard access.
Keep existing prices and booking links.
No customer data, payment changes, or new dependency.
Check mobile overflow, run the project checks, and show a preview.
Do not publish.

That’s a small change with a visible result. It also gives a reviewer something better than “looks good.”

• Do: use the search brief with the pack’s starter page. Keep work in your copied practice folder.
• Check: the agent identifies the three existing services and the #request link before editing.
• Save: the approved brief and original file so you can compare the change.

2. Inspect the project before broad edits

Start with a read-only tour. Find the repository instructions, source files, actual scripts, current branch, uncommitted work, and deployment rules. Don’t let the agent overwrite another session’s work to make its own task easier.

Stable project instructions should explain ownership, build and test commands, release stages, and data boundaries. Avoid filling them with a history of every failed attempt. Put a repeatable occasional procedure in a skill; keep project facts in the project.

Isolate the change with the repository’s normal feature branch or worktree. For a sensitive system, also isolate its data and credentials. A branch alone doesn’t create a sandbox database.

In our booking work, passing tests didn’t settle every deployment question. The database marker, payment account, webhook, sender, and host still needed separate checks before activation. A green build proves the code built in that environment. It doesn’t prove the environment is the right one.

3. Work in short, complete loops

Use this loop:

Inspect → change → check → review → correct

For service search, first find the existing data and render path. Then add matching and an empty state. Then inspect keyboard behavior and mobile layout. You don’t need a new framework, a search server, or an elaborate test suite for a dozen local services.

Use deterministic code for deterministic behavior. Let the model help with interpretation, implementation, and investigation. Don’t ask it to calculate an invoice by prose when the application can calculate it exactly.

Give feedback about the observed behavior:

Searching TUNE works. Clearing the input leaves the empty state visible. Fix that state transition and keep the existing matches.

That’s better than asking the agent to “make it more robust.” Current Claude guidance also emphasizes concrete verification criteria and working in bounded changes. Claude Code best practices.

4. Check behavior, not confidence

Ask for evidence:

Show the diff and exact checks with their outcomes.
List behavior you did not verify.
Try the unexpected inputs and refresh the page.
Check that unrelated prices and links are unchanged.

For our exercise, test uppercase input, no results, clearing, keyboard focus, and a narrow viewport. Don’t write a test that merely repeats the implementation’s internal steps. Check the behavior the user depends on.

For accounts or money, go further: another customer’s identifier, a replayed request, concurrent changes, forged browser values, provider failure, and recovery. Server-side ownership matters even if the button is hidden in the UI.

Bring in a separate reviewer when consequences justify it. Give that reviewer the requirement and evidence, and ask it to find faults. A second agent agreeing with the builder isn’t independent proof. It needs a different job: try to break the conclusion.

Subagents have their own context and consume usage. They can keep a large investigation organized, but they aren’t free capacity. Parallel work fits independent research or clearly separated files; dependent edits and approvals need coordination. Claude subagents.

• Do: try TUNE, zzzz-no-match, and clearing the field. Then use the keyboard and a narrow window.
• Check: prices remain $75, $25, and $45; the existing request link still works.
• Save: the actual results and any failure before asking for another correction.

5. Use a few skills you understand

Here’s an original teaching example:

---
name: preview-website-change
description: Prepare and verify an authorized website change. Use for a requested preview; do not publish.
---

1. Read repository instructions and inspect Git state.
2. Isolate the requested change.
3. Preserve existing data and unrelated work.
4. Run the relevant checks.
5. Inspect the result on mobile and desktop.
6. Report evidence and unresolved issues.
7. Stop before publication.

A portable SKILL.md includes name and description. Harnesses support different optional metadata and permission fields. Check executable scripts, network calls, licenses, credit, and access changes before installation. Don’t assume a polite instruction can constrain a broadly privileged credential. Agent Skills specification, Codex skills.

The DJH library shows reviewed catalog information and upstream credit. Raw downloads have a separate review boundary. I’d rather have one tested skill that fits the job than a thousand instructions competing for attention.

When you revise a skill, rerun representative cases and negative cases. A shorter file is not evidence that the skill works better. Evaluating skills.

6. Keep context useful

Feed the agent enough to act: the actual error, reproduction, relevant file, screenshot, source of truth, and requirements. More context helps when it resolves uncertainty. A dump of unrelated chats can bury the important part.

When the task grows, ask for a compact handoff: objective, accepted decisions, completed work, current revision, test evidence, unresolved issues, and next step. Keep original evidence accessible by reference.

For a difficult bug, preserve the failing example before fixing it. For a visual revision, compare the same viewport. For provider configuration, record the target without exposing the secret.

These habits are less exciting than buying a new model subscription. They also stop you paying to rediscover the same problem.

7. Spend on accepted results

Choose models by task, then compare results. A cheaper model can work well for bounded extraction with a deterministic check. A general coding model may handle ordinary implementation. Strong reasoning can help with uncertain architecture or sensitive diagnosis. These are starting recommendations, not a measured ranking.

Keep one small task record:

Include reviewer usage and retries. Separate subscription fees, included allowances or explicitly included API credits, extra tool charges, and hosting. A token count multiplied by a list price is a reference estimate, not proof of cash spent or business value.

Claude’s usage/cost reports can help inspect work, but session estimates aren’t authoritative billing for a subscriber. Claude cost management.

I include Muse and Instinct in the operating model even when token figures aren’t available. Accepted work and rework are still worth recording. Missing usage stays unknown.

8. Release a concrete result

Review the preview and exact revision. Run the repository’s required checks. Follow its deployment stages and verify the final URL. Keep code rollback separate from recovery of database writes, emails, or payments.

The same brief should answer what is allowed to ship and what still needs a decision. “Done” means the accepted behavior works, not that the agent ran out of ideas.

• Do: compare the final page and diff with the original brief.
• Check: every acceptance case passes, and any unverified behavior is listed. This exercise needs no public deployment.
• Save: the accepted revision and review record. The speech-to-website guide adds phone input to this same loop.

Video planned, not recorded: a short search demo showing matching, the empty state, clearing, and one real correction if needed. Pause to run the keyboard checks yourself. Read the future shotlists; the written exercise is usable now.

FAQ

Do I still need to read code?

You need enough understanding to assess the result and its risks. Read the changed code where it matters, inspect behavior, and seek qualified review for consequences outside your expertise. Directing agents doesn’t remove accountability.

Should I always use the strongest model?

No. Start with the task’s uncertainty and consequences, then compare cost per accepted result across similar work. Include retries and review. A stronger model can require fewer attempts, but that is something to measure.

Can I start from my phone?

Yes, with a supported authenticated connection to an execution environment. Use dictation to provide context and explicit requirements, then review a preview. The speech-to-website guide walks through that setup; the Claude and Hermes guides cover provider-specific details.