The Loop: Batching Hacks for Repetitive Tasks

Welcome to The Loop. Every Wednesday we take one real, repetitive workflow that someone does by hand and unwind it into something you can run yourself. This week is a little different: instead of one workflow, we're taking on a whole shape of workflow. The per-item grind. The afternoon where you do the same tiny action over and over, once per file, once per row, once per message, until the list runs out or your patience does.

Here's the reframe that changes how you see these afternoons. A batch task isn't many tasks. It's one rule, applied many times, and a rule you can state is a specification in disguise. Every time you rename file 23 of 80, you're executing instructions you already wrote in your head at file 1. The moment you can describe the rule and point at the pile, you can hand both to a machine. Describing replaces doing.

So this week's loop is the batch itself: how to take any pile of same-shaped work and run it as one job instead of eighty. We will watch a real one happen, count what it costs, and turn it into a build by the end of the page.

The Loop, in Full

Before you can batch anything, you have to catch yourself doing the un-batched version, so here's what it looks like. Picture a Friday afternoon at a small e-commerce team.

Marketing has a new naming convention for product images. Priya, the coordinator, has a folder of 80 photos named things like IMG_4402.jpg, and a tracking sheet that links each photo to a product page. Her afternoon is one action, eighty times:

1. Open the folder and the naming convention doc side by side.
2. Click the next file and work out its new name from the rule.
3. Rename the file, keeping the spelling and hyphens exact.
4. Find the matching row in the tracking sheet and paste the new name in, so nothing downstream breaks.
5. Repeat until the folder is done, recounting every so often to make sure nothing was skipped.

Swap the nouns and this is also updating 50 CRM records with a new field, resizing 200 images, or sending 30 nearly identical follow-up messages. Nothing in it is hard. Each item takes seconds and zero judgment after the first one. That's precisely the profile of a task a machine should own: the decision was made once, at item 1, and everything after is patience.

The Manual Tax

The real cost of a batch done by hand is never just the clock time. It's the minutes, plus the mistakes that creep in as attention fades, plus the weeks the job waits for a free afternoon. Add them up and you get the manual tax.

The minutes alone are worse than most people guess. In a survey of 4,500 office workers from UiPath, 67% said they're constantly doing the same tasks over and over, and respondents estimated they lose four and a half hours every week to work they believe could be automated. That's more than a full morning, gone to per-item grind.

Then add the two costs hiding behind the minutes:

• Errors. Item 1 is perfect. Item 41 gets a typo in the hyphen, and a product page quietly loses its image. Hand-run batches don't fail loudly; they drift, and the drift surfaces weeks later as a bug nobody can trace.
• Latency. Batches wait for free afternoons, and free afternoons are rare. So the new naming convention stays half-applied for three weeks, and every system that touches the files has to cope with both formats in the meantime.

A batch is not eighty decisions. It's one decision you already made, held hostage by eighty repetitions.

The goal isn't to shave minutes off the grind. The goal is to stop paying the tax entirely: every item transformed correctly, the same day the rule is decided, with a count you can verify at the end.

Unwinding the Loop

Automating a batch starts with description, not code, and for a batch the description is short: one worked example, plus the rule in plain words, plus what to do with the items the rule doesn't cover. Get those three things down and most of the build is already done.

Here's the batch captured as a spec. Notice that the interesting parts are the decisions, not the repetition:

That table is the whole automation, and it's the same conversation BYOBot has with you when it turns a task into a spec: what's the rule, what counts as done, what should never be guessed. If you want to get better at writing these down yourself, our guide on how to write a workflow spec goes deeper into the discipline.

The Build: One Loop, Three Ways to Run It

The same described batch becomes three different builds depending on how hands-off you want it. Start at the top. For a one-time batch, the prompt might be the whole answer.

The Prompt

The prompt build turns one worked example into the full mapping. You paste the item list into any AI chat tool along with the example and the rule, and it hands back the complete old-to-new table, with anything ambiguous flagged instead of guessed. You still apply the changes by hand, but the thinking part of all eighty items is done in one pass.

You are batching a repetitive action for me.

Here is ONE worked example:
  before: IMG_4402.jpg
  after:  tundra-jacket_navy_front.jpg

Here is the rule in plain words:
  [product]_[color]_[angle].jpg, all lowercase, hyphens for spaces.
  Product, color, and angle come from the list I paste.

For each item in the list:
- Apply the same rule.
- Skip any item already in the new format (count it as skipped).
- Flag any item the rule does not clearly cover. Never guess.

Return:
1. A two-column table: current name, new name.
2. A count: applied, skipped, flagged. The three must sum to the list.

Here is the list:
[paste items here]

That prompt works the same in ChatGPT, Claude, or Gemini. The skip rule and the flag rule are what make it safe to trust, and they're the same rails you want when you automate repetitive tasks with AI at any level: never redo finished work, never guess at edge cases.

The Script

The script is where the applying stops being your job too. For files, rows, and anything with an API, the honest build is a plain script with no AI at runtime: it reads the mapping, walks the list, and applies the action with three batch patterns built in. A short pause between items, around 500 milliseconds using setTimeout on MDN, so no app or API gets hammered. A hard stop after a set number of items, so a bug can never run away. And an early exit when an item is already done, so re-running the script is always safe.

// pseudo-shape of the script BYOBot generates for you
const map = readMapping('rename-map.csv');   // the prompt build's output, saved
let applied = 0;

for (const item of map) {
  if (applied >= HARD_STOP) break;           // never run away
  if (isAlreadyDone(item)) continue;         // safe to re-run
  await applyAction(item);                   // rename / update / send
  await pause(500);                          // stay polite
  applied++;
}

await sheet.batchUpdate(map);                // fix the tracker in one call
log(`${applied} applied, ${map.length - applied} skipped`);

The tracker update at the end uses the Google Sheets batchUpdate method, which writes every row in a single call instead of fifty. You don't start from a blank editor: BYOBot generates the full script, the file to save it in, and the commands to run it, the same way it helps you automate your Google Sheets workflows end to end. And when the items live inside a web app with no API at all, the same spec runs as a browser agent instead; our field guide to browser agents covers how those loops click through a UI without breaking.

The Schedule

Some batches happen once and the script is the end of the story. But if new items keep arriving (new photos every week, new records every sprint), The schedule is the smallest leap: the same script on a timer. A cron job or a scheduled GitHub Actions workflow runs it every morning, the early-exit rule skips everything already done, and the batch simply never piles up again.

Here's how the three builds stack up, so you can pick your stopping point:

Steal This Build

Here's the whole batch as a spec you can hand to BYOBot or build yourself this afternoon. Copy it and swap in your own nouns.

• Trigger: a set of items that all need the same small action.
• Capture: one worked example, plus the rule in plain words.
• Map: generate the full before-and-after list; flag anything the rule doesn't cover.
• Apply: run the action item by item with a pause, a hard stop, and a skip for items already done.
• Report: applied + skipped + flagged, summing to the full list.

This week's pile was 80 image files, but the shape is universal: any job you could explain by showing one example and saying "now do that to all of these" fits this exact mold. Once you see it, you'll catch yourself mid-grind and reach for the batch instead, which is the whole trick to automating the repetitive tasks that eat your week.

Frequently Asked Questions

• What makes a task a batch task instead of a workflow? +
  A workflow moves one piece of work through several steps. A batch task applies one step to many pieces of work: renaming 80 files, updating 50 records, sending 30 near-identical messages. The test is simple: if you could explain the whole job by showing someone a single worked example and saying "now do that to all of these," it's a batch task, and it's the easiest kind of loop to automate.
• Do I need to know how to code to run a batch script? +
  No. BYOBot writes the full script for you, including the file to create, the commands to run, and the safety rails already in place. Your job is to run it against three or four items first and check the result. This is the promise of no-code automation: you supply the worked example and the rule in plain language, and you walk away with the implementation.
• Why does the script pause between items instead of going as fast as possible? +
  Two reasons. First, politeness: apps and APIs rate-limit clients that hammer them, so a short pause of around half a second between actions keeps the batch inside every tool's comfort zone. Second, observability: a batch that moves at a readable pace is one you can watch and stop. Speed isn't the goal. Finishing correctly, with a count you can verify, is the goal.
• What if my items live inside a web app with no export and no API? +
  Then the honest hands-off build is a browser agent instead of a plain script: an automation that navigates the app the way you do, applies the action to each item, and uses the same batch patterns of a pause between actions, a hard stop after a set number of items, and an early exit when nothing is left to do. It's slower than an API script but it works anywhere you can click, which makes it the fallback that covers the rest of the repetitive tasks you want to automate.