Same tools. Same codebase. Same tasks.

My own output on parts of my work went up enormously. For some people working alongside me, it barely moved.

Ask how much work AI can take over and the answer comes back as a percentage. Thirty per cent of coding. Half of customer support. The number gets quoted as though it were a property of the job.

Across people doing similar work I have seen it range from under ten per cent to over ninety. Several things explain that spread. The one I keep returning to is the one you can build.

In the last issue I wrote that the code was never the bottleneck. What took months was everything the one-page specification had left out. You cannot reliably delegate work you do not understand well enough to communicate.

But a task can be perfectly described and still be unsafe to automate.

Consider a production database migration. Document the sequence, expected outcome, even the rollback procedure. None of that guarantees it will behave as expected against real production data.

The question is no longer whether the AI understands the instructions. It is whether you can recognise a mistake before it becomes consequential.

Before handing over a decision I ask three things. How likely is the system to be wrong? How easily can I detect the mistake? What happens if it escapes?

A generated report with a wrong number can be checked against the data. A recommendation that quietly shapes hundreds of downstream decisions is much harder to verify. Same model, same accuracy, different risk.

Delegate freely where mistakes are cheap and easy to catch. Where they are costly or hard to detect, build the checks before handing over the work.

Two delegation boundaries drawn on a plane. The horizontal axis runs from mistakes that are easy to detect to mistakes that are hard to detect. The vertical axis runs from low to high cost if the mistake escapes. A dark line separates the work you can delegate today from the work you keep. A gold line sits further out, and the band between them is what becomes delegable once the checks are built.
The boundary is not fixed by the model. It moves when you build the means to catch what the model gets wrong.

Nothing new in that. Engineering has always validated inputs and reconciled outputs. A checkpoint does not prevent failure. It changes what happens when failure occurs.

Now return to that gap.

One hands over a task, checks the result, corrects mistakes, repeats. Eventually checking costs as much as doing. The other defines acceptable outcomes and builds a way to spot failures. Routine results pass. Exceptions get attention.

The second can delegate more. Not because the model is better, but because the system around it is.

And more is not automatically better. Automating ninety per cent while letting critical mistakes escape is worth less than automating fifty and catching the exceptions reliably.

So I have stopped treating the percentage as a target. It tells me where I am.

The boundary tells me what to build next.