Okay, this one blew my mind a bit.

A few weeks ago I was building a POC for a new architecture for an agentic PAS system. I’ve been using Claude for a few months now, and the design part was great. Claude was a genuine thinking partner, and we went back and forth until the design was locked.

Then came the build. The spec was detailed, the coding agent started… and then it kept asking:

“Can I run this command?” Yes.

“This one?” Yes.

“And this?” Yes.

I was basically sitting there all day clicking Yes. And I kept thinking: why can’t this run by itself, and just let me check in from my phone?

Turns out someone at Anthropic was thinking the same thing.

Enter Claude Routines

Last week I tried Claude Routines. I wasn’t too impressed with earlier features like /loop, but this is the one I’d been wishing for.

I set it up on my personal laptop with my own Claude account and kicked it off on a piece of work that would’ve taken me about a week by hand. With a regular agent session, it would’ve been 2 painful days of babysitting.

The Routine did it in about 2 hours. Hands free.

The part I like most: it didn’t stop to ask me things. When it hit something that needed my call, it parked that item, wrote down the question and moved on to the next one. At the end I had working code plus a short list of decisions waiting for me. That’s how I’d want a good teammate to work.

While it ran, I took my daughter to her design class, got some housework done, and had a coffee with my wife. Every time it finished a story, I got a Slack update, and I could check on it from my phone whenever I wanted.

How I set it up

If you want to try it, here’s roughly what I did:

1. Write the work down first. I kept the spec and a backlog of small stories as markdown files in the repo, which was the simplest option for a POC. If your team lives in Jira or Confluence, the Routine can read and update tickets and pages directly through connectors.
2. Give it its own space. I created a separate git worktree and branch, so it never touches my main working copy.
3. Turn on Auto mode so it stops asking. Set the Routine’s permission mode to Auto. On my first run, the first permission prompt also offered “allow and switch to auto”. In Auto, a safety check reviews each action instead of asking you every time. On top of that:
   • I pre-approved the everyday commands (tests, type checks, local commits) in the project settings.
   • I hard-blocked the risky ones (git push, deploy, reading .env files). Auto mode can’t override those.
4. Tell it not to wait on you. In the Routine’s instructions, I told it: if you need a decision, mark the story “needs decision”, write the question down, and carry on with the next story. That one line is what turns it into “come back to a finished batch plus a list of questions”.
5. Create the Routine in Claude Desktop: Code → Routines → New → Local. Point it at the folder and paste in the instructions.
6. Connect Slack so it posts a short summary after every story: what changed, the test results, and any open questions.
7. Keep the laptop awake (there’s a setting for it) and plugged in, and get the Claude app on your phone to check in on the go.
8. Do a test run first. Watch where it gets stuck, fix that, then let it go.

This is just one use case

Routines can run on a schedule, so the same setup works for:

• watching logs every morning and flagging anything unusual
• triaging overnight alerts
• running the full test suite nightly and reporting what broke
• checking dependencies for updates and vulnerabilities
• updating docs or tickets when the code changes

Anything repetitive that you can describe in plain English is fair game. Honestly, the sky’s the limit.

One more thing, and it’s been on my mind

As excited as I am, I’m also genuinely a bit worried. Not as a developer, but as a human being and, I hope, a responsible citizen.

If a week of work becomes 2 hours, what happens to the people whose job was that week of work? The junior developer learning the craft by writing exactly this kind of code? The tester, or the support engineer, whose daily tasks are just what a scheduled Routine is good at?

I don’t have a neat answer. What I’ve seen so far is that the work shifts rather than disappears. Someone still has to understand the problem, design the system, make the judgement calls, review what gets built and own the result. In my run, the most valuable output wasn’t the code. It was the list of questions only a human could answer.

But “the work shifts” is easy to say when you’re the one doing the shifting. Those of us who are early to these tools have a responsibility to bring others along: teach, mentor, share what works, and be honest about what doesn’t, and make sure no one gets left behind. It’s been the same with every industrial revolution before this one. Let’s hope for the best.

---

It’s still early days, and you still review what it builds. But I spent my time on the design and the decisions, not on clicking Yes.

Now go have that coffee. ☕