The Work Behind AI That Looks Like Wasted Time

A few weeks ago, my wife asked me a fair question.

"What exactly are you doing all this time with AI?"

Some weeks, I spend three or four days changing the system: testing a model, rewriting an instruction, fixing a broken workflow, changing how context is retrieved, or finding out why something that worked perfectly in a demo fails on the work I need it to do.

Then there are weeks when a large amount of actual work moves through that system.

From the outside, the first kind of week can look unproductive. It can look like somebody avoiding the work by building a more complicated way to do it.

Sometimes it is.

But I have become convinced that this is the wrong way to measure all system-building time. The important question is not whether an improvement helps with today's task. It is whether the next hundred tasks start from a better position because that improvement exists.

That is where the productivity gain is.

The work that looks like no work

When people talk about AI productivity, they usually talk about speed.

Can a model finish this in ten minutes instead of two hours? Can an agent do one day of work while you are asleep? Can a team reduce a process from five people to two?

Speed matters. But it is an incomplete test.

A task completed in twenty minutes is not productive if it creates forty minutes of checking, correcting, rebuilding context, and explaining what the model should have understood in the first place.

The more useful question is this: did the system help produce a better result with less unnecessary human effort, and did it leave the next run better than the last one?

That second part matters more than it sounds.

I wrote earlier that a better model will not fix unclear thinking. The same principle applies to the system around the model. A better model can make a weak workflow look more convincing. It cannot turn a vague process into dependable work by itself.

The demo is not the workflow

The version of AI that spreads online is usually the clean version.

Find a repository. Install a package. Add an API key. Run a command. Watch an agent complete a task. The demonstration is often impressive. It may even be genuinely useful.

But a demo proves that something can happen once. A workflow has to survive the day after the demo.

It has to survive incomplete context, bad inputs, conflicting sources, tool failures, model mistakes, provider changes, and the day you do not have time to sit beside it correcting every output.

That is the difference between a working demonstration and a dependable system.

Once you depend on a workflow, the questions become less glamorous:

• What information does the system need before it starts?
• Which sources should it trust?
• What can it decide on its own?
• What should trigger a human review?
• How does it recover when a tool fails?
• How do you know that the final answer is finished, rather than merely fluent?

These are not problems solved by calling something an agent. They are design decisions. They are also where most of the useful work begins.

If you still need to supervise every output, you have not created leverage. You have created a new supervisory role for yourself. I wrote about that problem in If You Still Babysit Every Output, You Do Not Have an Agent.

The asset is not the prompt

The prompt is visible, so people overvalue it.

What is harder to see is everything around it: the context, the source preferences, the templates, the quality checks, the permissions, the escalation rules, the examples, and the corrections made after previous failures.

I have started thinking of that accumulated layer as workflow capital.

Workflow capital is the reusable knowledge embedded in how work gets done. It is not one clever instruction. It is the collection of small decisions that stop the system from making the same mistake twice.

Some of it is obvious. A better research template. A clearer brief. A checklist that catches a common error.

Some of it is less visible. Knowing when the model needs more context. Knowing which task does not need an agent at all. Knowing when a result looks polished but should not be trusted yet.

Every failure can add to that asset, if the lesson is captured.

Work. Observe the failure. Change the system. Let the next task inherit the correction.

That is a different kind of productivity from saving thirty minutes once. It is a process that can keep improving after the original task is gone.

The system I built was better at being mine

Recently, I used a mature external harness for a task I needed to complete. It produced a good result. It is a product I consider reliable.

Then I ran similar work through the system I have been building for myself.

For that workflow, my system performed significantly better.

This was not because I built a better foundation model. I did not. The underlying intelligence may have been the same or similar.

The difference was the surrounding system.

My workflow had more of the relevant context. It understood the structure I wanted. It had been adjusted after previous failures. It knew what information mattered, what could be ignored, and what I would need to check before calling the work finished.

The external harness was probably the better generic product. My system was the better system for my workflow.

That distinction changed how I think about ownership. I do not need to own the intelligence. I am comfortable using models and infrastructure built by other companies. But I increasingly want to own the layer that makes that intelligence useful to me.

Models will change. Prices will change. Providers will change. The accumulated understanding of how I work should not disappear each time they do.

Not everything deserves a system

There is a bad version of this idea.

It is possible to spend three hours automating a task that takes five minutes once a month. It is possible to build five agents for a job one good prompt could handle. It is possible to mistake technical complexity for progress.

I have done versions of all three.

System-building can become avoidance wearing an agent diagram.

The guardrail is simple: does this improvement meaningfully improve future work?

If the answer is no, the simpler solution is better. A normal prompt may be enough. A script may be better. A manual decision may be the correct design.

This is also why I do not think the answer is maximum automation. The objective is better work.

As I argued in First Build the Machine. Then Add the AI Engine., AI is useful when it strengthens a process you understand. It becomes expensive when it is used to hide the fact that the process was never clear.

The question has changed

The question used to be: what can this model do for me?

I still ask that question. It matters.

But the question I find more useful now is: what can I improve once so that every future piece of work starts from a better position?

That is why the time spent testing, rebuilding, and correcting is not always overhead. When the improvement becomes reusable, it is an investment in the work that comes after it.

The model provides intelligence. The workflow determines whether that intelligence becomes useful work.