All Journal entries

Journal #15 · 28 October 2026 · 2 min read

One blocked task shouldn't stop the AI workflow.

A blocked task can be a legitimate stopping point without stopping unrelated, authorized work across the AI workflow.

AI-assisted developmentAI workflowsHuman oversight
A hand-drawn railway station with four branching tracks: two blocked by barriers and debris, and an orange train continuing along a clear track.

In my recent AI-assisted development work, I've repeatedly had to redirect attention after a task became blocked. The workflow would pause and wait for my next instruction, even though other work remained on the roadmap or in the backlog. Sometimes the blocker was entirely legitimate. What I kept questioning was why I had to be the one to make the workflow look beyond it.

I don't want an AI system to push through a failed check, invent missing evidence, or make a decision that still belongs to me. Those are real stopping points. But they apply to the affected work; they don't necessarily mean the rest of the development effort has nowhere to go. Stopping safely and stopping everything are not the same decision.

The pattern changed what I paid attention to. I had been looking at what AI could accomplish within an assigned development task: investigate a problem, make a change, test it, and prepare the result for review. Now I was spending time on what happened between tasks. After an interruption, I was back to scanning outstanding work and redirecting attention, rather than concentrating on the decisions that genuinely needed my judgment.

There is an important catch. A backlog full of tasks doesn't mean every task is ready to start. Some depend on the blocked work. Others might be outside the current scope, require approval, lack necessary information or resources, or simply belong further down the priority list. Choosing something at random to avoid idle time could create more problems than it solves.

The distinction I needed was straightforward. A blocked task should remain blocked until the reason for stopping has been resolved. But unrelated work that is independent, appropriately prioritized, and authorized shouldn't inherit that blocker. If nothing else qualifies, waiting is still the correct outcome.

I eventually solved that recurring interruption in my own workflow. I no longer need to keep redirecting attention simply because one task has stopped. What mattered wasn't keeping AI busy. It was allowing useful work to continue without weakening the boundaries that still needed to hold.

I still care whether an AI-assisted task is completed correctly. But I now pay just as much attention to what happens when it cannot continue. A blocked task should remain blocked when necessary; the rest of the workflow should not stop by default.