Where AI fits in a workflow

Start with what you keep avoiding.

The work of writing a case study was slow and shapeless, and every time I sat down to do it I found something else that needed doing first. That is the honest reason I started putting AI into my own work. Not speed for its own sake. There was a thing I was supposed to do, kept not doing, and wanted to stop avoiding.

That turns out to be the right place to start. If you are wondering where AI fits in what you do, the question underneath it is usually: which part of my work do I keep putting off, or keep doing badly, or keep spending more time on than it deserves. Start there.

Know what you are fixing, and how you will know it worked.

There is a failure mode where you add AI because adding AI is the thing to be doing, and afterwards you cannot say whether anything got better. You just have a more complicated process with a model in the middle of it.

The way out is to decide, before you build, two things. What is the problem. And how you will measure whether it is solved.

For the case studies, the problem was that they took so long I never wrote them. The measure was simple and a little crude: do they now get written, and is the version I get faster to a publishable state than doing it by hand. Faster, by my own standard of good, and actually finished. If a workflow with AI in it could not beat that low bar, there was no reason to keep it.

Two situations, two moves.

Once you have a problem worth solving, there are two cases. The workflow already exists and you do it by hand. Or it does not exist yet and you are designing it from nothing. The move is different for each.

Take it apart, then decide what can move.

If you already do the thing, you have a process, even if you have never written it down. So write it down, at the resolution you actually work at, not the tidy version. Then decide, step by step, what a model could hold and what has to stay yours.

Beat 1 — the workflow, as I do it by hand

Before the model, the case study was mine end to end. Here is the honest version, no AI in it. The starting point is not "where does AI go." It is "what do I actually do," written down as six steps.

Six steps, and all six are mine. That is the page you start from.

Beat 2 — how I decide what can move

With the steps on the page, I run each one through three tests. A step has to pass all three before it leaves my hands.

Beat 3 — the same workflow, with the model in it

Now the model goes in, but only where the three tests said it could. The shape is the same as the all-human version. The repeated, substrate steps moved. The two judgment points stayed.

The difference between this and where I started is not that the work got faster, though it did. It is that the reading and the drafting, the parts that were never the point, stopped sitting between me and the two decisions that were. I do the deciding. The model does the substrate. The line between them is the three tests, run once, on paper, before any of this was built.

Work from the outside in.

The harder case is when there is no process to take apart, because you have never done the thing. You cannot deconstruct what you do, because you do not do it yet. So you build the shape from the two ends you already know.

You know the input. You know the output you want. Start with only those. Say the input is a single word and the output is a finished article. Everything interesting is the middle, and the middle is empty. So you fill it in, from the top down, largest steps first.

At the coarsest level: the system has to understand the subject and my style, produce a draft, check that draft against something, revise, and then hand the result to me. Five rough moves, written at altitude. Then you go down a level into each move. Each high-level step, pressed on, reveals what it needs underneath it.

That third column is the one to notice. Decomposing a not-yet-existing workflow tends to surface the documents you are missing more than the tasks. The voice document. The context the model needs. The written-down standard. The workflow cannot run until those exist, and you only learn you need them by breaking the work into pieces small enough to show the gaps.

The judgment does not vanish. It moves.

In both cases there is a step that feels like it must stay yours: the part where you look at what came out and decide if it is good. It feels unautomatable because it feels like judgment, and judgment feels like the opposite of a repeatable step.

But when I reject a draft, I am not rejecting it at random. I am checking it against things I expect, and I could name them if I sat down to. A critique has a shape exactly the way the workflow did. So you do to the checking what you did to the work. Take it apart. Name what you actually look for, the specific failures that mean a thing is not ready.

The judgment goes from a thing you perform every time to a thing you decided once and wrote down, so the routine cases can be checked without you, and you spend your attention only on the drafts that genuinely need it.

Decide where you stay, on purpose.

None of this is an argument for removing yourself from your own work. Taking the checking apart is what lets you be deliberate about the opposite: where you stay in it.

Some decisions are worth your eyes every single time, because getting them wrong is expensive, or because they are the reason the work is yours and not anyone's. Those points you keep. You draw that line yourself, and where you draw it is a matter of what you find acceptable, which is yours to set.

The method does not tell you where the human belongs. It makes the line a choice you make on purpose, instead of a default where you check everything because you never separated the decisions that matter from the ones that only feel like they do.

So the loop runs like this.

Five moves. Run them in order, and where AI fits stops being a guess and becomes something the shape of your own work hands you.

↻ then the next piece of work runs the same loop