How I Stopped AI Workflows From Sprawling

By mid-2024 I was juggling several AI tools at once across my own projects. The work was useful, but the coordination overhead started eating into the time the tools were supposed to save. Every extra prompt, every follow-up question, every half-finished idea added friction rather than removing it. That is the point at which "AI speeds things up" quietly turns into "AI generates more things to manage."

So I changed the shape of the work rather than adding more tools to fix the tool problem. Ideas became tracked issues. Research happened before code. Code changes went through review. Nothing moved forward without a human looking at it first.

The workflow

Idea -> tracked issue -> research -> code -> review -> deploy

The diagram is not the interesting part. The discipline behind it is:

• Every item carried an explicit priority and a budget — in time, in tokens, or both.
• The review step stayed human, always, no exceptions for "obviously fine" changes.
• The system ran scheduled batches overnight so I reviewed output in the morning instead of reacting to it in real time, which is a very different cognitive load.

Why budgets matter more than model choice

Most AI workflow problems I see — in my own projects and in client environments — are not model-quality problems. They are budget and boundary problems. A workflow with no limit on how many tokens, how much runtime, or how many parallel branches it can spawn will eventually spawn all of them, because nothing is telling it not to.

Setting an explicit budget per task does two things. It caps the worst case, so a runaway loop costs you an hour and some spend rather than a weekend. And it forces you to decide, up front, how much a given task is actually worth — which is a question most people skip entirely when the per-task cost looks small.

Human review points: where they actually belong

Not every step needs a human in the loop, and treating every output as equally risky just slows everything down without adding safety. The useful places to put a mandatory human checkpoint are:

• Before anything is deployed or merged into a shared branch.
• Before any output leaves the system — an email sent, a public post published, a file shared externally.
• Before a budget is increased mid-run, rather than letting the system quietly extend its own limits.

Everywhere else — intermediate drafts, research summaries, first-pass code — can run without a person watching every step, provided the three checkpoints above are non-negotiable.

Scheduled runs and cost visibility

Running batches on a schedule rather than interactively changed more than my sleep pattern. It meant every run produced a cost and output I could review as a single unit, rather than a stream of small decisions I was making continuously throughout the day. That is what actually made cost visible: a single number per batch, attributable to a specific set of tasks, rather than a vague sense that "AI tools cost something" at the end of the month.

For an SME running several AI-assisted workflows, the equivalent discipline is simple: know, for each workflow, what it costs per run and who approved the budget. If nobody can answer that question for a given automation, that automation does not have governance yet — it has permission.

What it changed — for this one project

On this specific personal project, the shift produced a clear before-and-after. I want to be precise about what this is: a single example from my own workflow, not a general claim about what any team should expect.

| Metric | Before | After | |--------|--------|-------| | Code hours per week | 20h | 4h | | Monthly token spend | £120 | £12 | | Projects shipped per month | 1 | 4 | | GitHub commits per month | 45 | 200+ |

Those numbers held for this project, with this workload, under this structure. They are not a benchmark to hold any other team to — the point is the shape of the change, not the specific multiples.

What made it work

1. Keep the routing local when you can — it removes a cost variable and a data-boundary question in one move.
2. Keep write access scoped tightly, task by task, rather than granting broad access up front "to save time."
3. Treat the repository — or whatever your system of record is — as the single source of truth, not the chat history with the AI tool.

That combination is what made the setup durable, not the specific tools involved. The tools will change. The rules, if they are good ones, tend not to need to.

The real lesson

AI does not remove the need for process. It makes the absence of process more obvious, faster, and more expensive. The teams that get real value out of AI workflows are not the ones with the cleverest prompts — they are the ones who decided, before scaling anything, what the budgets, review points, and cost visibility were going to look like.

If you are trying to get AI-assisted workflows under control in your own organisation — budgets, review gates, and genuine cost visibility rather than a vague sense of spend — that is the kind of structural work covered on my services page, so get in touch if you want a second pair of eyes on yours.