A Hacker News post for a project called Claude Code Routines climbed to 686 points — the kind of number that usually means the title hit a nerve, not that everyone read the README. The nerve is familiar. Most developers run the same handful of multi-step tasks over and over: bumping dependencies, drafting release notes, triaging a flaky test, prepping a PR description. An agent that can sort of do each of those still has to be re-explained from scratch every single time. Routines are a bet that the re-explaining is the real cost, and that the fix is packaging the workflow once.
We didn't run a multi-week trial, so treat what follows as a map of the idea and a checklist for evaluating it — not a benchmark. The questions below are the ones we'd want answered before wiring any routine tool into a real repository.
What a "routine" actually is
A routine is a saved, repeatable workflow: a named sequence of steps you hand to the agent so it runs the same way each time instead of improvising from a cold prompt. The unit is the point. A one-line slash command saves keystrokes; a routine saves a decision tree — which files to touch first, what to check before moving on, when to stop and ask you.
Claude Code already ships the primitives this builds on. Custom slash commands store a prompt under a name. Hooks fire shell commands before or after tool calls. Headless mode (claude -p) runs the agent non-interactively, so it can sit inside a script or a CI job. Subagents let one run hand a scoped task to another. A routine, in the sense this project pushes, is the layer that stitches those into a single durable artifact you can version, share, and trigger — instead of a workflow that lives in your head and degrades a little every time you retype it.
Hold onto that distinction, because it is also the thing to stay skeptical about.
Where it fits in the agentic dev-tools landscape
The agentic coding space has spent the past year moving from "autocomplete that finishes your line" to "an agent that finishes your task." Cursor put the agent inside the editor. Terminal agents like Claude Code put it next to your shell. The next axis of competition is repeatability: not just whether the agent can do the task, but whether it does it the same way on Tuesday that it did on Monday, with you out of the loop.
Routines land squarely on that axis. They are less a new capability than a packaging decision — and packaging is where both real value and quiet lock-in tend to hide. A routine you can read, diff, and check into the repo is an asset your team shares. A routine that is an opaque blob tied to one vendor's runtime is a liability dressed as convenience. Ask which one you are getting before you depend on it.
Automating a workflow you don't fully understand only makes the misunderstanding run faster. Before you turn a task into a routine, do it manually with the agent two or three times and read every step it takes. A routine is never more trustworthy than the workflow you already trust by hand.
The honest failure mode for any automate-your-repetitive-work tool is that it rewards you for skipping the step where you would have caught the workflow being wrong. A dependency-bump routine that quietly merges a breaking change is worse than no routine, because it ran while you weren't watching. The teams getting value here are the ones automating workflows that already have a verification step built in: tests that must pass, a diff a human signs off on, a dry-run mode.
Whether it earns a slot in your daily loop
Use a short rubric. A workflow is a good routine candidate when it is repetitive enough to matter — you run it weekly or more — deterministic enough that "correct" is checkable rather than a matter of taste, and bounded enough to have a clear stopping point and a verification gate. Release-note drafts, changelog assembly, issue triage, and dependency reviews tend to qualify. "Design the feature" does not.
The cost side of the rubric matters too. A routine has to be maintained: when the codebase shifts, a stale routine fails in ways a fresh prompt would not. If a workflow changes shape every month, the routine is overhead rather than leverage. Automate the stable middle of your work, not its moving edges.
If most of your repetitive work happens inside an editor rather than a terminal, the terminal-first framing of Claude Code routines may not be the closest fit. An editor-native agent loop can be lower-friction when the work lives in files and diffs.
The 686-point thread is a signal that the problem is real, not a verdict that this one tool solves it. Treat routines as a discipline first and a product second: write down a single workflow you repeat, give it explicit checks, and run it that way for a week. If the written-down version beats the in-your-head version — and it usually does — then the tooling that stores and triggers it is a small, swappable detail.
Originally published at pickuma.com. Subscribe to the RSS or follow @pickuma.bsky.social for new reviews.
Top comments (0)