Every team has a list of these. The repetitive jobs nobody wants, that everyone agrees should be automated, but never quite make it onto the roadmap. The ones where the right thing to do is build a proper UI, a proper pipeline, a proper anything. But the right thing costs three weeks, and the wrong thing (a human doing it 40 times a month) costs less. So we hire a student. We delegate it to an intern. We rotate it around the team. We grumble.
I don't think we noticed the moment the math changed.
The configuration drawer
We have one of these on a platform we work on at Bobcats Coding. The team needs to produce a configuration for the application based on client input, every time a campaign goes live. The proper solution would be a configuration UI on the admin site, where the client could create the configs themselves through a structured form. We have wanted to build it for a long time. But you know how it goes: the client wants the configs immediately, and other features always end up higher on the list than automating the day-to-day workflow.
So creating each configuration takes about 15 minutes. Read the client input, figure out the not-quite-trivial mappings to values in our DB, deal with the exceptions (every config has at least one), produce the JSON seed. Fast for an experienced dev. Painful when there are 30 of them in a queue. Familiar?
We hired a student to do it. Cheapest solution. And for years, that math made sense.
The math changed and we almost missed it
Here is what is different now. The cost of "automating" this kind of task collapsed. Not by 10%, not by half. It went from "three weeks of dev time we don't have" to "one focused afternoon with Claude in plan mode."
That is a different threshold. And once the threshold moves, the list of things worth automating expands. Suddenly the boring 15-minute task is on the table. Suddenly the messy one-off, the script you would never have committed to, the thing you used to delegate to the cheapest pair of hands you could find. All of it is a candidate.
This is the part I keep coming back to. The mindshift is not "AI writes code now." Plenty of people have written that already. The mindshift is: the set of problems where automation is worth it just got dramatically bigger.
What it actually looks like
For our configuration task, we did this:
- Wrote down the onboarding material. The same thing we would write for a new student joining the team.
- Opened Claude Code in plan mode. Threw in the onboarding doc, a few previous client inputs paired with the hand-made outputs, and the bits of code and documentation that the task touches.
- Asked Claude to turn all of it into a slash command. Asked it to ask back if anything was unclear. (It always has questions. Usually good ones.)
- Specified the input arguments for the command, including a final freeform argument for "any custom instructions for this specific config."
What came out the other side is a
/create-configurationcommand we can call like a function:
/create-configuration <client input spreadsheet url> <optional additional instructions>
Two things worth noting. First, Claude wrote a better description of the task than we ever had on paper. The command file is, in effect, a human-readable functional spec for a process that lived in our heads for years. Second, because the output is a JSON object, the command also writes a test that checks the output values against the input spreadsheet. So we got testable automation, not a nice-looking script that fails silently.
Time per config: from 15 minutes to about 2. Across the volume we run, that is roughly 70% of what the student was doing.
The bit I did not expect
I asked the student to automate the remaining 30%. He did. We have another command now, for another use case, written by the person who actually understood the corners and the exceptions.
He still works with us. He runs the commands every day. But the work he does on top of them is the interesting part now: the cases the commands cannot handle yet, the edges, the new clients, the things that need judgment. He likes his job more. And we get more value out of his time.
This is the part that does not show up in the AI-replaces-jobs takes. When the threshold moves, the people who used to do the repetitive 70% do not disappear. They move up the stack. The work they do becomes the work that actually needs a human. Which, it turns out, is more interesting work.
A mental model
I have started running a quick check on tasks I used to skip past. Roughly:
If I can onboard a new colleague to a task that they could solve in front of a computer, I can probably onboard Claude to it. Without the forgetting, the typos, the inconsistent output, or the bad day on Tuesday.
Not just code. Anything that fits the shape of "structured input, defined process, evaluable output." Configurations. Reports. Data cleanup. Migrations. The boring layer of work between the interesting tickets.
Your homework
Pick one task on your team that nobody wanted to automate because it was not worth it. Then:
- Imagine onboarding a new colleague to it. Write that down.
- Collect a few previous executions and any related docs.
- Decide how you would evaluate the output.
- Open Claude in plan mode, throw all of it in, and ask for a command.
- Try it. Iterate. Ship it. If you have done this already, I would love to hear what you put on your list. We are running our own at Bobcats Coding, and I suspect we are not done finding things that used to be "not worth it."
Top comments (0)