Agentic Engineering
Most of the code I ship is written by agents. None of it is written without a plan, a harness around it, and a deliberate call on how many agents the job actually needs. This is how I run it with Claude Code.
The setup follows the task
Most work is one agent with solid context. It sees every decision it has made, so its decisions agree with each other. I only split work across agents when the split is real, and the process scales with the risk.
One agent, full context Default
Most feature work and refactors. Split it up and two agents that cannot see each other make choices that conflict.
Straight to it
A one line change does not need a PRD. Ceremony is for work where a wrong call is expensive.
A subagent that returns a summary
Keeps the main agent working on decisions, not wading through file dumps.
Parallel subagents, one per set of files
Separate files, no shared decisions, and each writer in its own worktree so nobody edits over anybody else.
A fresh agent that did not write the code
A reviewer that shares the author's assumptions finds the bugs the author already found.
From requirement to merged code
For anything bigger than a quick fix, the same path. Agents are fast, so the expensive mistake is not slow code, it is the right code for the wrong problem. Most of the effort goes in before a line is written.
- Plan
Business requirement
The problem in the words of the person who has it. Not a solution, not a ticket title.
Explore and plan
The agent reads the codebase, the constraints and the earlier decisions before it proposes anything. Questions come back to me here, not halfway through a build.
Product requirements
What is being built, who it is for, and what is out of scope. The PRD is the document every later step is checked against.
Technical design
How it gets built: data model, interfaces, failure modes, and the trade offs taken. Written from the PRD, so a design call can always be traced to a requirement.
Phases
The design cut into slices that each ship and review on their own. A phase that cannot be reviewed alone is two phases.
Tasks
Each phase cut again, into tasks small enough to finish and prove in one go.
- Build
Execute
Connected tasks run in one session that holds the whole phase. Independent ones fan out to subagents. Either way the specification is already written, so the work is execution, and execution is where a cheaper model earns its place.
Which model does what
Planning is where a wrong call costs the most, so it gets the strongest model. Executing a well specified task is where most of the tokens go, so it gets the efficient one.
Exploration, the PRD, the TDD, phase and task breakdown, coordinating the build.
Judgement. A bad plan executed perfectly is still a bad plan.
Executing tasks against the plan, in the main session or as subagents.
Cost efficiency. The thinking is already done, so paying for it twice is waste.
When the work splits: orchestration, not loops
When a phase does break into independent pieces, I do not leave agents looping on it until something passes. One parent agent holds the plan, briefs each subagent, and checks its report before trusting it. The parent reports to me. One point of control, and I can see where every agent is at.
One agent to steer instead of several. A change of direction is one message, not a hunt through parallel sessions.
Every subagent reports to the same place, so the state of the build is always one question away.
Each subagent starts with one task and a full brief, not the whole history, and hands back a short result rather than raw output.
A report is a claim. The parent checks it against the diff and the test results before it reaches me.
The harness
Agent written code is only as good as what checks it. The harness is the part I engineer by hand, and it is why the speed is safe to use.
Code review runs as a skill, with the same checklist every time, before a change reaches me.
Repeated work, from planning to shipping, is written down once as a skill and run the same way each time.
The PRD and TDD are the spec each task is checked against. An agent cannot drift far from a plan it was handed in writing.
Builds, linting, tests and checks in CI. An agent does not get to decide its own work is finished.
Proof
This is not a side project process. At Medallia I rolled this exact flow out with my team, and we use it commercially: shipping features that large enterprise organisations rely on, landing impactful changes faster and at a higher quality than we did before.
This site is a smaller example you can inspect. It was built the same way, from a written brief, and every pull request runs typechecking, linting, the build, width and accessibility checks, an em dash check and Lighthouse CI.
Beyond the codebase
The same tools take repetitive work out of the business, not just out of the engineering. If someone does the same task every week by following the same steps, it is a candidate for a skill, a script or a scheduled agent.
Work that is repeated, rule based and dull enough that people put it off. Reporting, triage, first drafts, and moving data between systems that were never meant to talk to each other.
Written once and run the same way every time, with a person approving anything that leaves the building. An automation that drafts gets a lower bar than one that sends.
My own example. It mines my Claude Code transcripts and drafts the writing I would otherwise never sit down and do.
At NetValue I built a Laravel portal that pulled SEMrush metrics and parsed inbound report emails onto the right client account, removing more than ten hours of manual work a week. Agents make that kind of build much cheaper, so far more of it is worth doing.