Your Next Step in Agentic Engineering Is a Custom Software Factory
Coding agents already make developers more effective and productive. The next step comes when you can start trusting what they hand back. A custom software factory—a predefined workflow shaped to your own projects—is how you get there.
Checking everything by hand doesn't scale
Handing an agent one task at a time works most of the time. Some of the time it gets it wrong. And some of the time it does something else entirely: builds around a structure you wouldn't have chosen, or solves a slightly different problem.
You can't tell in advance which one you'll get. That leaves two options. You check everything. You double-check the results and re-read the agent's own code reviews, because you're not sure you trust those either. The agent is fast, but now your review is the bottleneck.
Or you accept what slips through. A random bug here, a structure you didn't expect there. Agents build new work on top of old work, so it compounds: slower progress, random mistakes and weird behaviour. Neither gets you more speed.
What is an agentic workflow?
An agentic workflow is installed into the harness you use to work with the agent, such as Claude Code. It's a collection of skills, plugins, hooks and commands that push the agent to work in a certain, repeatable way. A skill defines how a step like planning or review is done. A hook fires at a set point so a step doesn't quietly get skipped. A command runs the sequence. A custom agentic workflow is also known as a software factory.
You can describe the same process in global instructions, such as a project's instruction files. The agent treats those more as suggestions. A workflow leans on the agent hard to enforce a specific behaviour—ideally one customised to your needs and your projects.
Consistent results are what you can trust
A single task handed to an agent is a roll of the dice. A predefined workflow runs the same way every time, so over the long run its results are consistent. And because it's the same every time, you learn what to expect from it: where it's reliable, where it slips, where you still need to look closely.
Think of it this way: you trust a coworker because you've watched how they work and the results have been predictable, not because you've re-read every line they've ever written. When something unusual turns up, you notice, because you know the normal pattern.
Predictable output earns your trust over time. Unpredictable output you have to check. Every time.
The catch: each task gets slower
A rigorous workflow does more work in the background to be reliable. Planning, specialised review and capturing lessons all take time, so each task takes longer on the wall clock. Adopt one and keep working one task at a time, and you get slower.
The gain comes from what trust lets you do next: run several tasks at once. When the results are consistent enough to trust, you don't have to babysit one task to completion before starting the next. Several pieces of work move through the same steps in parallel, and you step in where your attention actually matters.
That's where one task at a time stops scaling. And that's where the velocity comes from.
An example: compound engineering
Compound engineering is Every's workflow, and it ships as a plugin. This isn't a how-to, just what its parts are and why they matter.
Planning before code
The agent plans before it writes code, and you read the plan. Reading the agent's plans catches problems all the time. Architecturally, the agent might be heading the wrong way, and the plan is where you see it, while the fix is still an edit to a document rather than untangling code.
Every's guide suggests about 80% of the engineer's time on planning and review and 20% on execution and capturing lessons. Execution is the part the agent is already fast at.
Specialised review
The code doesn't go through one vague "look for problems" pass. Specialised reviewers each check the change from one angle. A reviewer with one clear job has something concrete to check against, and over time you learn what each one reliably catches.
This step has saved my bacon many, many times. When agents write more code than you can read, a human carefully reading all of it stops being a plan. I've written about that in Code Review Is Dead.
Capturing lessons
After the work is done, the compound step records what was learned so later work can use it. Of all the steps, it's the one I trust least. It updates documentation, but it could be more thorough. At least it does something.
Automation chaining the steps
Automation chains plan, work, review and compound so they run in sequence without you prompting each stage. That only pays off because each step underneath is solid. Automate a sloppy process and you get sloppy results, faster.
Make it your own
A workflow is meant to be adapted. I have my own, built on compound engineering, with additions my work kept needing:
Brainstorming when an issue is created. The important information gets filled in when the issue is written, and the agent works out right then whether it needs anything else before the work starts.
Test requirements. Unit tests run while the agent writes code, because that's when fast feedback matters most. End-to-end tests run once a bigger chunk of work is done, the agent only commits when they pass, and the same tests run in CI.
Risk assessment. Every pull request gets a risk assessment. Low-risk ones merge automatically, and risky ones wait for me.
Coordination across the whole project. Work is tracked as issues on a project board: one shared UI where the agent and I decide together what gets prioritised and what doesn't. It keeps agents off conflicting or duplicate work, and planning checks dependencies and ongoing work before a feature is built.
I've produced four-digit number of pull requests and issues with this setup with high level of accuracy and quality. You can find a high level description of the current version from here: my current agentic development workflow.
With client teams, I usually start by recommending Compound Engineering as one of the workflows to start from. And in that work I've seen productivity, accuracy, developer satisfaction and developers' trust in the results go up as workflows are established.
Your version don't need to look like mine. Nor should it. Watch what your own work keeps missing and add a skill or a hook for it. If review keeps missing the same kind of bug, give a reviewer that job. If a step keeps getting skipped when things get busy, put it in a hook so nobody has to remember it.
