10 AI Workflows Every Developer Should Automate (I Run 7 of These Daily — 3 Weren't Worth It)

Before the list, the filter I wish I'd had a year ago.

Automate the work that's tedious and verifiable. Never automate the work that's subtle and unverifiable.

Formatting a file is tedious and verifiable — you can see instantly if it's wrong. Deciding your database schema is subtle and the cost of a bad call shows up three months later. AI is brilliant at the first kind and dangerous at the second, and almost every "AI automation gone wrong" story is someone who automated across that line.

Keep that in your head as you read. It's why three of these are marked not worth it.

1. Auto-format and lint on every file the AI touches#

The tedium: the AI writes code, it's 90% right, but the import order is wrong and it used 4 spaces where your project uses 2. Now you're nitpicking a robot.

The setup: a hook. Hooks fire on lifecycle events and run outside the model — so they cost you nothing in context and they can't be talked out of running. In .claude/settings.json:

        1
2
3
4
5
6
7
8
9
10
11
12
        {
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          { "type": "command", "command": "npx prettier --write \"$CLAUDE_FILE_PATH\"" }
        ]
      }
    ]
  }
}
      

Every write gets formatted immediately. You stop reviewing whitespace forever.

Verdict: ✅ Worth it, day one. Genuinely the highest ratio of value-to-effort on this whole list. Five minutes to set up, pays back permanently.

2. Block the dangerous command before it runs#

The tedium: you write "never force-push" in your instructions, and it mostly works. Mostly is doing heavy lifting in that sentence.

The setup: here's the thing worth understanding — instructions in CLAUDE.md are guidance, not enforcement. They're strong guidance and usually followed, but they aren't a wall. If you want something to be genuinely impossible, that's a PreToolUse hook, which can hard-block a tool call before it executes:

        1
2
3
4
5
6
7
8
9
10
11
12
        {
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          { "type": "command", "if": "Bash(git push --force*)", "command": "./scripts/deny.sh" }
        ]
      }
    ]
  }
}
      

Exit code 2 from the hook = blocking error, execution stops.

Verdict: ✅ Worth it, if you have real footguns. This is the difference between "please don't" and "you can't." Every team has two or three commands that should simply never run unattended. Wall them off and stop worrying.

3. Codebase research that doesn't eat your context#

The tedium: "where is auth handled in this repo?" — twenty file reads later, your context is full of stuff you'll never need again, and everything after that is worse for it.

The setup: delegate it to a subagent. Subagents run with their own separate context and hand back a summary. The reading happens in their budget, not yours.

        1
2
3
        Use a subagent to map how authentication works in this repo. Return:
the entry point, the middleware chain, where sessions are stored, and
any file that touches token refresh. File paths + one line each. No prose.
      

Verdict: ✅ Worth it, and underrated. This is the single most underused feature I've seen. Most people burn their context doing exploration inline and then wonder why quality drops an hour in. My rule: more than ~5 files to read and I don't need the details afterwards → subagent.

4. A repeatable workflow you invoke with one word#

The tedium: you type the same six-step instruction every release. Every time. Slightly differently.

The setup: a skill. Drop a SKILL.md in .claude/skills/deploy/ and you get /deploy:

        1
2
3
4
5
6
7
8
9
10
        ---
description: "Pre-release checklist for production deploys"
---

# Deploy checklist
1. Confirm the branch is green in CI
2. Run the smoke tests against staging
3. Check the migration list for anything destructive
4. Tag the release
5. Post the changelog in #releases
      

The clever bit: skills load on demand. Only the short description sits in context at session start; the body loads when it's actually invoked. Ten skills cost you ten one-line descriptions, not ten full documents.

Verdict: ✅ Worth it once you've typed the same thing twice. That's the trigger. Not before — a skill for something you do once is just a file you'll forget.

5. First-pass code review on your own diff#

The tedium: you know there's a dumb mistake in your 400-line diff. You just can't see it anymore.

The setup: /code-review on your working tree before you open the PR.

The honest catch — and this is the part that matters: if you tell it "only report high-severity issues, don't nitpick," modern models take that literally. They'll find the bugs, judge them below your stated bar, and say nothing. Your precision goes up and your measured recall goes down, and you conclude the tool is weak. It isn't — it's obeying you.

Ask for coverage instead, and filter yourself:

Report every issue you find, including ones you're unsure about or consider low-severity. Don't filter for importance — I'll do that. For each finding, include your confidence and an estimated severity.

Verdict: ✅ Worth it — as a first pass, not a gate. It catches the dumb stuff reliably. It will not catch "this design will hurt in six months." Use it to clear the noise before a human looks, not instead of the human.

6. Persistent project memory so you stop re-explaining#

The tedium: every session starts from zero. You re-explain the build command, the conventions, the one weird thing about your setup. Again.

The setup: a CLAUDE.md at your project root. Build commands, conventions, and the two or three rules you're tired of repeating. Run /init to get a first draft from your codebase, then cut it down.

The counterintuitive part: shorter is better. Aim under ~200 lines. Bigger files eat context on every single request and — genuinely — reduce how well the instructions get followed. Mine is about 40 lines.

Got a lot of rules? Don't cram. Path-scope them in .claude/rules/ so they only load when relevant:

        1
2
3
4
5
6
        ---
paths:
  - "src/api/**/*.ts"
---
# API rules
- Every endpoint validates its input.
      

Now those rules cost nothing until an API file is actually opened.

Verdict: ✅ Worth it. Do this before anything else on the list. Nothing else here matters as much. The test for what belongs: did you have to correct the same mistake twice? In it goes. Everything else is noise.

7. Scheduled maintenance that runs while you sleep#

The tedium: dependency checks, flaky-test hunting, stale-branch cleanup. Important, never urgent, therefore never done.

The setup: a scheduled agent — a cron job that files a report instead of doing the work. Nightly: scan for failing tests, group them by suspected cause, open one issue with findings.

Verdict: ⚠️ Worth it, with one hard rule: it reports, it doesn't commit. I let this class of automation find and write up. I do not let it push. Read that back — a scheduled agent with write access to your repo is a thing that can break main at 3am with nobody watching. Reports are safe. Autonomous commits are how you get a bad morning.

8. ❌ Auto-generating your commit messages#

The pitch: why write commit messages when the AI can read the diff?

Why I turned it off: because the diff already tells you what changed. A commit message exists to say why — and the why is the one thing not in the diff. What you get is fluent, professional-sounding restatements of the obvious: "Refactor authentication middleware to improve error handling." Thanks. I can see that. What I needed six months later was "the session store was double-counting retries and blowing the rate limit."

Verdict: ❌ Not worth it. It automates the typing and throws away the thinking. The typing was never the expensive part. (It's fine for chore: bump deps. But you didn't need AI for that either.)

9. ❌ Auto-generating tests for coverage#

The pitch: point it at an untested file, get tests, watch coverage climb.

Why I turned it off: it works, and that's the problem. You get tests that pass, coverage that looks great, and tests derived from what the code does rather than what it should do. If the function has a bug, you now have a test asserting the bug is correct. You've locked it in and given yourself a green dashboard while you did it.

Tests written from the implementation aren't tests. They're a mirror.

Verdict: ❌ Not worth it as automation. Genuinely useful as a collaborator — "here's the spec, what edge cases am I missing?" is a great prompt. But unattended test generation for a coverage number is worse than no tests, because no tests at least tells you the truth.

10. ❌ Auto-replying to issues and PRs#

The pitch: a bot triages your inbox, answers common questions, keeps the queue moving.

Why I turned it off: the failure mode is public. A wrong answer in your codebase is a bug you fix quietly. A wrong, confident answer on someone's issue is your project telling a stranger something false, with your name on it. And people can tell — a plausible non-answer to a real problem is worse than silence, because now they've been dismissed and misled.

Verdict: ❌ Not worth it for anything user-facing. Labeling and routing? Fine — that's tedious and verifiable. Talking to humans on your behalf? That's subtle and unverifiable. Right back to the rule at the top.

The scoreboard#

Seven out of ten. That's a good hit rate, and I'd be suspicious of anyone claiming ten.

FAQ#

What should developers automate with AI first?#

Project memory (CLAUDE.md) and auto-formatting. Both take minutes, both pay back forever, and neither can hurt you. Everything else is a bigger bet.

Can AI actually review my pull requests?#

For a first pass, yes — it catches the obvious things reliably. Just don't tell it "only report high-severity issues," or it'll obey and stay quiet about real bugs. Ask for everything with a confidence score, then filter yourself. And keep a human on design decisions.

How do I automate repetitive coding tasks without losing control?#

Use hooks for anything that must always happen (they run outside the model and can't be reasoned around), and skills for workflows you invoke deliberately. Keep instructions in CLAUDE.md for guidance. The distinction matters: CLAUDE.md is guidance, a PreToolUse hook is enforcement.

What shouldn't I automate with AI?#

Anything subtle and unverifiable. Commit messages (the why isn't in the diff), tests written from implementation (they encode bugs), and public replies to humans (confidently wrong, with your name on it). Also: anything that pushes to a remote unattended.

Do these workflows only work with Claude Code?#

The specific config here (hooks, skills, subagents) is Claude Code. The principles — enforce with hooks not prose, protect your context, automate tedious-and-verifiable only — apply to any AI coding tool. Translate the shapes.

The takeaway#

You don't need ten automations. You need two good ones and the discipline not to add the bad eight.

Write a short CLAUDE.md. Add a format-on-write hook. Live with that for a week. Then add the next one only when you catch yourself doing something tedious for the third time.

And when something tempts you — auto-commits, auto-tests, auto-replies — run it through the filter: tedious and verifiable, or subtle and unverifiable? If it's the second one, you're not automating work. You're automating the part where you'd have noticed it was wrong.

Want the prompts behind these workflows? I logged every one from a real build in Claude Code prompts that actually worked . And if you're wondering how tools like these plug into external systems, start with What is MCP? .

More free developer tools and references: CodeAiKit Tools · Git Commands Cheat Sheet