This post continues the quest to find the optimal AI-driven development workflow.
Previously I discussed "Slice", the idea of a transferable single-file context description that includes the intention, goal, tasks, and verification description.
In the previous post I outlined the rules for material that belongs to /docs:
as-isMaterial that should go to /work is:
to-beThe changes described in the previous post made the workflow better, but they also made its remaining limits clearer.
This led to a different question: what if the workflow reacted to work appearing, rather than waiting for a person to decide which command to run next? This could work because some daily workflows clearly repeat across tasks.
I drafted an answer by programmatically calling Claude and GitHub Copilot CLI, but eventually went with the Claude Agent SDK. The result is a structured AI workflow that reacts to a change and handles its repetitive parts in a non-blocking way.
The workflow starts when something appears in a watched directory. That is the input; no custom prompt is needed. Each agent has its own system prompt and tools. It automatically analyses and classifies the material, making a best effort to capture the intent.
For example, when the input is only a screenshot of a UI, the agent tries to identify the issue. When the screenshot also includes annotations, it considers both together. It can also separate unrelated issues into files according to the working context: UI issues from different views become separate pieces of work when they do not belong together. This works surprisingly well.
The analysis is saved as a file in /work. The next step is a short interview with the user, whose purpose is to frame the work and clarify exactly what it is about. The agent asks only what it cannot infer itself. The answers become a clear description of the change, which is then turned into a concrete task list. The agent can begin implementation from there and eventually produce a diff for review.
The diagram shows the sequence: input is automatically analysed and classified; the user interview produces a clarification or description; and the workflow automatically turns that into a diff. The interview is the deliberate hand-off point between the automated stages.
Automation does the heavy lifting, while human input arrives at the points where it matters most. This defines a human-in-the-loop process that aims for flexibility, efficiency, and trust.
The workflow is working surprisingly well. The path from an issue or idea to a task list is smooth. The reactive agent uses Opus 5.5 and is effective with remarkably little initial information. The open topic is the cost. Each workflow agent has a cost associated with it.
Another improvement is using AskUserQuestion as much as possible. This reverses the cognitive burden of the interaction. Instead of the user having to describe the need in detail so that the agent can produce a clear outcome, the agent must first work out what it can do and then ask for the missing details. This pattern is not particularly unique and is used elsewhere as well, but I think it is still an underused approach. There is a slight conceptual curveball attached: an interview does not need to model a human-to-human interview. This is, of course, because there is no inherent need for an agent to understand anything. The inversion is a deliberately superficial pattern: it minimises the user's typing and reading, and makes the agent carry the larger share of reading the material it creates.
In practice "reactive AI workflows" are an alternative way to solve what explicit commands do. Fundamentally the approach is different and the expectation now is that the cognitive burden of working with agents gets better. I think that is now the new primary goal.