The work I used to accept as fixed

In June, I described my workflow as two recurring conversations with AI. One started with a boring, repetitive task: can you do this for me? The other started with something I wished existed: can you build it?

What kept surprising me was how often the answer was worth pursuing. Tasks I would have treated as a fixed part of the job became things I could question and change. An idea for a tool no longer had to remain an idea until I could justify a separate development project.

But a promising answer in a chat is only the beginning. The larger shift is being able to investigate the work, build a better way, implement it in the real workflow and operate it over time.

That sounds wildly technical. In practice, it often starts with me asking Claude Code or ChatGPT Codex to do it. I describe the task or the thing I want, check what comes back and continue until it works in the real workflow.

Those two questions lead to different kinds of work. It helps to know which one you are asking.

When the task already exists

With repetitive work, there is something concrete to examine. You know where the information comes from, what you do with it and what a useful result should look like, even if some of that knowledge has become habit.

Consider someone who gathers material for a weekly review. Before building a new application, it is worth asking whether an assistant can prepare the material within the existing workflow. The useful test is whether the review becomes easier to conduct. A polished summary that still needs reconstructing from the sources has not removed much work.

There may be no reason to create a product at all. Doing the task well could be the entire point. If it needs to happen every week, however, a successful first attempt still has to become a working part of the process.

When something is missing

The second question opens a different possibility. You can imagine a tool that would make sense for your particular work, but you have never found it in the software you use.

Here, the uncertainty is partly about the idea itself. A working version lets you discover whether the tool belongs in the workflow you imagined. Perhaps the missing view makes a decision easier. Perhaps it duplicates something you already have, or creates another place that needs updating.

Being able to build it makes the question testable. It does not settle whether you should keep it, let other people depend on it or turn it into a business.

From investigation to operation

For someone who knows a field well, the investigation can begin close to the work. You can recognise the tedious handover, the missing context or the recurring question that the current tools handle badly. You can identify the inputs, the exceptions and the decisions that need human judgement.

Building gives the idea a concrete form. The smallest useful version should answer the question you started with. It does not need to become a large application before you can learn whether it helps.

Implementation is where that version meets the actual work. It needs the right sources, permissions, systems and handovers. The people involved need to know what it does, what remains their responsibility and how to recognise a bad result. This is where a convincing demonstration either becomes useful or reveals what it was missing.

Operation is the longer test. The new approach must run when it is needed, surface failures and remain understandable when the work changes. Someone has to own corrections and maintenance. The amount of code produced tells you very little about whether any of this is true.

The part I find exciting is no longer only that I can investigate work I had stopped questioning. I can investigate it, build a better way, implement it in the real workflow and operate it as part of the work. Some things may be delegated. Some may deserve a small tool. Some may become systems that other people can rely on. The opportunity is to make the better version real and keep it working.