A process that never varies is a tool waiting to exist.
Some work is worth doing. Some work is only the cost of getting to the work, and it comes back every week whether anyone thinks about it or not. This is the method for finding the second kind and turning it into something you own.
Watch it before you read it.
Animation and narration produced in-house with the same toolchain the courses get built with.
Find the fixed process.
Not every annoying task deserves a tool. The ones that do share a shape, and finding them is mostly just watching the work closely. Watch your own for a week, the way you would if you had to hand it to somebody else on Monday, and sort what you see into two piles.
The index card test. If the steps fit on an index card and a patient stranger could follow them without asking anything, it is automatable. If every run needs judgment in the middle, it is not, or the judgment stays human and the grunt work around it gets automated.
The second filter is frequency times pain. A forty-minute task you do twice a year is not a build. A forty-minute task you do every week is more than thirty hours a year. Basically, that is a build.
Write it in plain English before you open any AI.
The usual mistake happens before any code exists. People open the AI and start describing vaguely. Write three lists first, the way you would brief a contractor: what goes in, what comes out, and every rule in between.
Treat the AI as a contractor, not an oracle.
Hand over the spec and you will have something that runs sooner than you expect. But the build is not the prompt. The build is the iteration, and there is a good reason not to skip it.
You cannot feel whether it is working. In a 2025 randomized trial, METR had sixteen experienced developers work through 246 real issues in codebases they maintain, with AI tools allowed on half. They finished 19% slower with the AI, and afterwards still believed it had made them 20% faster. Those were experts, in code they knew, and they could not tell from the inside.
So do not rely on the feeling. Run it against real files. Not made-up examples, the actual messy files colleagues send. Mine broke on answers marked with Word's shading paint bucket instead of the highlighter, which look identical on screen and are stored completely differently, and on a checkmark font that turns into garbage the moment software reads the cell. Every break becomes a new rule in the spec.
Make it fail loudly. When my tools cannot find what they need, they say so and stop. They never guess and produce output that looks finished. A tool that fails loudly gets trusted. A tool that fails quietly gets discovered.
Keep the AI out of the finished tool.
The decision that makes the whole thing durable is the one most people skip. Once the tool works, the AI's job is over. The thing you run every day should be boring and deterministic: no API calls, no model, no subscription in the loop.
Your content never leaves your machine. Cisco's 2025 privacy benchmark surveyed 2,600 privacy and security professionals, and nearly half admitted putting non-public company data or personal employee data into generative AI tools. Nobody attacked them. They were just doing their work. In a regulated environment that is the difference between a tool you can adopt and a governance review you will lose.
It survives policy weather. Researchers at Stanford and Berkeley ran the same prompts against GPT-4 three months apart and watched accuracy on one task fall from 84% to 51%. Same model name, same prompts, different answers. A deterministic tool does not care. If AI access got cut tomorrow, it would keep running for years.
Pilot it like you respect people's time.
A tool nobody trusts is a tool nobody runs. Hand it to the people who do the task, on their own files, and watch what happens without helping. What they get stuck on is the spec's next revision, and what they never touch is a feature you did not need to build.
One workflow, worked end to end.
The method is not theoretical. It came out of replacing a legacy macro that turned fifty-two minutes of copy and paste into twelve seconds, on a task a whole team ran every week. That build is documented separately, screen recordings and all.
Narration EX
The tool the method produced: the problem it solves, the build decisions, and two films of it running on a sixty-four slide deck.
How to turn a recurring problem into a tool you own
The full article, with the research behind step three and step four written out properly.