Is this actually helping?

Count the whole job, then decide what to keep.

The assistant gave you a draft in five minutes. That feels fast.

How long until you could actually use it?

That second question matters because drafting is only one part of a task. Setup, checking, correcting, and fitting the result into your work can take time too.

Here’s an illustrative example, not a measurement from our work. Suppose a familiar task usually takes 30 minutes without AI, including review. With AI, it looks like this:

The first draft took five minutes. The whole job took 33. Compared with that 30-minute baseline, this particular example used three more minutes.

The arithmetic is easy. Choosing a fair comparison is harder.

What makes a comparison fair?

First, both routes need to reach an acceptable result. A fast but unusable answer hasn’t completed the same task. If the AI-assisted version is better, record what improved rather than pretending time is the only thing that matters.

Second, compare reasonably similar work. An easy task on a quiet morning and a difficult task during constant interruptions won’t tell you much about the tool’s effect.

Third, distinguish active time from elapsed time. Active time is the attention you spend working. Elapsed time includes waiting. If a process runs while you do something else, adding all of that waiting to your personal effort would misdescribe your day. You might care about both measures; keep their meanings clear.

The comparison you really want is what would have happened on the same task without AI. Researchers call that missing alternative the counterfactual. You can’t observe both versions of the same first attempt, so comparisons need some care.

Even formal studies run into this. In its February 2026 research update, METR described difficulty estimating AI’s effect on developer productivity when participation and task selection were influenced by whether people expected AI to help. That creates selection bias: the work you get to measure may differ systematically from the work you wanted to understand. Those findings concern their developer study, not our workflow.

Keep the conclusion close to what you observed

In a September review of our own work, I reported that the two responses I reviewed were useful, needed no correction, and took less overall effort than earlier work. That’s meaningful feedback. It isn’t a measured time saving or proof that the benefit will last.

For your own task, a small note may be enough:

What did I finish? How much attention did it take, including review? Was the quality good enough? What would I use again?

If you want a stronger picture, keep the same notes across several comparable tasks, including the frustrating ones. Don’t let only the impressive results make it into your judgment.

You may find that AI helps with one part of the work and creates more effort somewhere else. That gives you something specific to adjust. You may also find that you learned something, got unstuck, or finished work you weren’t managing before. Those outcomes deserve a place in the review too.

We’ve spent this week giving AI a clearer job and ourselves a clearer way to judge it. Next week, we’ll put that foundation into creating and improving something useful.

What part would you keep?