How to Stop Wasting Time on Repetitive Coding Tasks

The short answer: Write down what you repeat for a week. Decide what deserves automation using more than a stopwatch. Then give each chore to the right layer: formatters and linters for style, CI for tests and builds, bots for dependency updates, and AI assistants only for the fuzzy work that rules can't handle.

The scale is real. Sourcegraph, citing a McKinsey study, says developers can spend 30% or more of their time on routine, manual work. That figure comes secondhand through a vendor blog, so treat it as a rough signal. The cost is not only hours. In a survey cited by TeamDynamix (an IT service vendor, so the context is IT operations, not pure software development), 90% of respondents said repetitive manual tasks contribute to low morale and attrition. Even if your numbers differ, the pattern is familiar: skilled people end up doing mechanical work.

What counts as a repetitive coding task?

Anything you do the same way, on a trigger, with little thinking. Most of it falls into a handful of buckets:

Sourcegraph's list of candidates is similar: formatting, tests, deployments, API documentation, routine code review checks, and database migrations. One caution from it is worth keeping. Automation handles the routine part of a code review (style, consistency, simple bugs), and humans should keep the judgment part.

Step 1: Find the tasks (it takes a week)

You can't automate what you haven't noticed. For five working days, keep a plain text file open. Every time you catch yourself doing something you've done before, add one line: what it was, how long it took, and how annoying it was.

Don't trust your memory. The tasks that hurt most are often small and frequent, so they never feel big enough to fix.

Step 2: Decide if it's worth automating

Most people use one test: will I save more time than I spend building it? That test misleads in both directions.

Developer Marc Gauthier gives a clean example. Writing 10 numbers into a spreadsheet takes one minute a day. Automating it would take about ten hours. On time alone, you'd need roughly 600 working days to break even, so you'd never bother. But he points out that time is only one factor. Four others matter:

• Energy. A short task can still drain you if it demands careful concentration.
• Frustration. Annoyance builds with repetition and eventually costs more than the minutes.
• Focus. Stopping other work to do a one-minute chore costs far more than one minute, because of context switching.
• Growth. Automating something is often how you learn a new skill.

The warning runs both ways: automate too early and you waste time, too late and you pay the same cost. So use this quick filter. If a task is frequent, error-prone, or breaks your concentration, automate it even when the stopwatch math looks bad. If it's rare, changes shape every time, or takes seconds with no mental cost, leave it manual.

Step 3: Match the task to the right layer

This is where most people go wrong. They reach for an AI tool when a ten-line config file would be faster, cheaper, and predictable.

Layer 1: Rules (deterministic). Formatting, linting, import sorting. The result should be identical every time. Use a formatter and a linter, run on save and before commit.

Layer 2: Pipelines. Tests, builds, deployments, security scans. Use CI so nobody has to remember to run them.

Layer 3: Bots. Dependency updates arrive as small pull requests. Dependabot is built into GitHub, and Renovate offers more configuration and supports more package managers, according to the DevOps.dev roundup.

Layer 4: AI assistants (fuzzy work). Boilerplate, first-draft tests, repetitive refactors across many files. Here the output varies, so a human must review it.

Practical setup: three working examples

Example 1: Auto-fix style before every commit

The standard JavaScript approach pairs Prettier and ESLint with lint-staged and a pre-commit hook (Husky is the common choice). The lint-staged part goes in package.json:

json

"lint-staged": {
  "*.{js,jsx,ts,tsx}": [
    "prettier --write",
    "eslint --fix"
  ]
}

This formats and fixes only the files you staged, so commits stay fast. Install the packages with npm install --save-dev prettier eslint husky lint-staged, then wire lint-staged into a Husky pre-commit hook by following Husky's current setup docs, since the exact steps change between versions.

Example 2: Run tests on every push

Create .github/workflows/tests.yml:

yaml

name: Tests
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
      - run: npm ci
      - run: npm test

Version note: some popular tutorials still show actions/checkout@v2. The checkout action's release notes show v6 as the current major version at the time of writing, so use that or a newer one and check the repository for updates. This file runs your install and test commands on every push and pull request, which removes "did you run the tests?" from code review.

Example 3: Auto-format when Claude Code edits a file

If you use Claude Code, hooks let you run your own shell commands at set points in its workflow. According to the official hooks reference, you define them in a settings file: ~/.claude/settings.json for all projects, or .claude/settings.json for one project you can commit and share. This hook runs a script after Claude writes or edits a file:

json

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/check-style.sh",
            "args": []
          }
        ]
      }
    ]
  }
}

What each part does:

• PostToolUse fires after a tool call succeeds.
• matcher: "Edit|Write" limits it to file edits and writes.
• ${CLAUDE_PROJECT_DIR} points at the project root, so the script path works from any directory.
• Your script (check-style.sh, which you write and make executable) receives JSON about the call on stdin.

Exit codes matter. For a post-tool hook, exit code 2 shows your script's error output to Claude so it can fix the problem. The docs warn that exit code 1 is treated as a non-blocking error for most events. If you want a hook to enforce something, use exit 2. Also, the official docs recommend putting instructions that never change (like "use pnpm, not npm") in CLAUDE.md instead of a hook. Hooks are for actions, and CLAUDE.md is for static conventions.

Using AI for repetitive work without creating new work

AI assistants are very good at the tedious middle of coding. Anthropic's own data shows how far this has gone. In a piece published on its site, the company reports that as of May 2026 more than 80% of the code merged into its codebase was authored by Claude, and the typical engineer was merging about 8× as much code per day as in 2024. Anthropic itself says lines of code is an imperfect measure and likely overstates the true productivity gain.

The more useful finding for your workflow is the side effect. Anthropic reports that human code review became a new bottleneck once more code was being produced. That is the trap for individual developers too: you remove the typing but add reviewing. A few habits help:

• Give the AI a verifiable target. "Make this function pass these tests" is checkable. "Improve this file" is not.
• Keep your deterministic layer. Let formatters and tests judge AI output, so you aren't judging style by eye.
• Review before you merge, not after. Anthropic's retrospective analysis found that an automated Claude review of every change would have caught roughly a third of the bugs behind past incidents. That supports using AI review as a first pass, not as a replacement for you.
• Watch for complacency. One developer essay on Medium argues that tools which automate the dull parts can leave people just going through the motions. If you can't explain a generated change, don't merge it.

A four-week rollout that doesn't overwhelm you

Don't automate everything at once. Sourcegraph's advice is to start with the most repetitive tasks and expand gradually, and a roadmap like this follows that idea:

1. Week 1: Formatter and linter on save. Fix one project first.
2. Week 2: A basic CI workflow that runs tests on pull requests.
3. Week 3: Pre-commit hooks so bad formatting never reaches the repository.
4. Week 4: Dependabot or Renovate for dependency updates.

After that, look at your task log again. Whatever still annoys you is your next candidate, whether that's a Docker Compose environment, a no-code workflow, or an AI-assisted refactor.

Keep your automation healthy

Automation is also code, and it rots. Sourcegraph's maintenance advice holds up: keep scripts modular so one part can change without breaking the rest, document each command so teammates can use it, and test and monitor your automations so failures don't go unnoticed. TeamDynamix adds a warning about homegrown scripts: they look like a quick fix but can carry security risks and become hard to maintain as an organization grows. That is a vendor's view, since they sell the alternative, but the maintenance risk is real. A script nobody remembers is its own kind of repetitive task.

When NOT to automate

• The process is still changing. Automating a moving target means rewriting it every week.
• The task takes seconds and costs no focus. Not everything needs a pipeline.
• You don't understand the manual version yet. Do it by hand a few times first.
• The automation touches money, production data, or credentials and you haven't built in a safety check.
• The setup will take longer than the task's remaining life. If the project ends next month, skip it.

FAQ

How do I know if a task is worth automating?

Use the five factors above: time, energy, frustration, focus, and growth. If a task is frequent, error-prone, or interrupts deep work, it usually earns automation even if the time math is close.

Should I use AI or a script?

If the result should be identical every time, use a script, formatter, or CI job. If the work needs interpretation (boilerplate, test drafts, refactors across many files), use AI and review the output.

Won't automation make me a worse developer?

It can, if you stop understanding what runs on your behalf. Automate tasks you already know how to do, and keep reviewing what the tools produce.

Conclusion

You won't stop all repetitive work, and you shouldn't try. Your goal is to move the mechanical, error-prone parts to systems that never get tired, and keep the thinking for yourself. This week, keep the task log. Next week, automate the single most annoying item on it with the simplest tool that works. That one change tends to pay for itself, and it shows you what to automate next.