Can you do this for me? Can you build it?
Wow, it can do that as well. Cool.
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.
A promising answer in a chat is only the beginning. The bigger change is that I can 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.
The two questions lead to different kinds of work, and it helps to know which one you are asking.
When you ask AI to do a repetitive task
With a repetitive task, the first question is whether an assistant can do it within the existing workflow. 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. If an assistant prepares that material, 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 you ask AI to build a missing tool
The second question is about a tool you can imagine for your particular work but have never found in the software you use. A working version lets you discover whether the tool belongs in the workflow you imagined.
Here, the uncertainty is partly about the idea itself. 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.
Taking a tool from investigation to operation
A tool you decide to keep needs to work in the real workflow, with someone responsible for corrections and maintenance.
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 puts that version into 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, show when it fails 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.
I still find it exciting that I can investigate work I had stopped questioning. Now I can also 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, and some may become systems that other people can rely on.