Delegated execution is the fourth rung. You stop watching each step. You give an agent a goal, and it plans, edits files, installs what it needs, runs the tests, reads the failures, tries again, and comes back with a change for you to review. It often runs somewhere other than your machine, and you do something else while it works.
One category sits here: autonomous coding agents.
That is deliberate. Testing, code review and cloud development environments matter more on this rung than on any below it, but they apply on every rung, so they live under Cross-cutting practices instead. What defines this rung is one thing: whether you are present while the work is done.
What this rung is for
Tasks you can describe completely in advance and check mechanically afterwards. A behaviour with its acceptance criterion. A bug with a failing test that reproduces it. A mechanical change across many files that the type checker or the test suite can confirm.
When it works, it is startling. When it does not, you have a large diff and no memory of how it got there.
Who it suits
Engineers who already review an agent's changes well on the rung below and work from written requirements. Codebases with a test suite that can judge a change without you in the room.
It does not suit work whose requirements are still in your head. An agent does not ask what you meant. It decides, plausibly and without saying so, and the decision arrives in the diff.
How to tell you are on this rung
- You start a task and then work on something else.
- What comes back is a finished change, and your question is whether it is right, not what to do next.
- You have reviewed a diff and wondered why the agent made a choice nobody asked for.
If several of these are running at once and you are losing track of them, you are on the rung above.
What it costs you later
- Every gap becomes a decision. A brief that leaves out the schema, the state names or the order of writes gets all three invented. The result can pass every test and still be wrong in a way no test you wrote could see. Designing a feature an AI coding agent cannot improvise shows how that happens.
- Review becomes the bottleneck. An agent produces change faster than you can judge it, and a diff too large to review in one sitting tends to be approved on trust. Code review is the new bottleneck is about keeping that queue honest.
- Stand-ins nobody mentions. When a task needs something that does not exist yet, an agent will often build a stand-in and carry on. You find it later, when the real thing arrives and disagrees with it.
- Long tasks lose their early instructions. The further into a large task an agent gets, the more it holds at once, and the constraints stated at the start are the first to slip.
- Debugging without a history. When a delegated change breaks something weeks later, the conversation that produced it explains little. What helps is a record of the task, the criterion it was built against and the checks that ran.
- Discarded attempts still count. Each run counts against your usage whether you keep the result or not, and an agent retrying a failing approach can use a lot of it before you look.
Sizing a task you can hand over
Most of those costs shrink with one habit. A task is the right size when the build is green the moment it lands and the diff is small enough to review in one sitting. Size by what has to be true when it is done, not by how much effort it feels like, and slice by behaviour, end to end with its test, rather than by layer. Sizing tasks an AI coding agent can finish works through an example.
A task with its own check cannot leave a broken build for the next one, and a diff you can hold in your head cannot hide a decision for long.
The step up
The rung above is Orchestration, where several tasks, agents or tools are in flight at once and your job becomes keeping them coherent. Take that step only once one delegated task at a time is reliably uneventful. Several agents scale a method you already have. They do not replace one.