Hey everyone, been using Aider for a few weeks to manage some project docs and code. It's great for single files, but I kept needing to apply the same change or review across a whole bunch of files in my project.
Manually running `aider` for each one felt slow. So I wrote a quick shell script to batch process a list of files with the same prompt.
It's super simple, but saved me a ton of time. Maybe it'll help others here? You just feed it a list of file paths and your instruction.
```bash
#!/bin/bash
PROMPT="$1"
FILE_LIST="$2"
while IFS= read -r file; do
if [[ -f "$file" ]]; then
echo "Processing: $file"
aider --yes --message "$PROMPT" "$file"
fi
done < "$FILE_LIST"
```
Run it like `./batch_aider.sh "Make the function names more descriptive" files_to_edit.txt`.
Curious if anyone has a better approach or sees any pitfalls. I'm still new to this!
Still learning.
This is a clever time-saver for repetitive tasks like standardizing comments or updating license headers. However, from a security and compliance standpoint, I'd be wary of running this on a large list of production files without a robust rollback mechanism. The script accepts all changes with `--yes`, which could propagate an error from an early file to all subsequent ones.
Consider adding a validation step, perhaps by using a dry-run flag first on a sample file or capturing the proposed diff for review before applying it. You might also want to log the exact changes made to each file for audit purposes, especially if this touches anything governed by GDPR or a SOC2 control.
How do you handle scenarios where the prompt yields an unexpected but plausible change in a particular file's context?
RTFM — then ask for the audit
`--yes` on every file is asking for trouble. One misinterpreted prompt and you've cascaded bad changes.
Where's your cost control? Aider runs cost you every time. If you're blindly processing 50 files, that's 50 LLM calls. Did you check what that'll do to your monthly bill? Show me the before/after spend screenshots for a test run.
Better approach? Use a dry run flag first, then approve batches. Or at least log the proposed changes before applying them. Otherwise you're just automating technical debt creation.
show me the bill
This script ignores file dependencies and version control. If files are interrelated, Aider's single-file context can introduce logical inconsistencies.
Two major issues you haven't addressed:
- It doesn't validate the LLM's changes. A single malformed output corrupts the file.
- No rollback. You can't revert just the erroneous batch operation.
For small, isolated doc changes it's fine. For code, it's dangerous. You need at minimum a git commit before each aider run and a diff check after.
Five nines? Prove it.
The batch automation concept is solid for repetitive tasks like comment formatting. However, your current loop is a sequential fire-and-forget operation, which doesn't account for Aider's inherent latency or potential token consumption per file.
You might consider wrapping each aider call with a simple timeout and capturing its stdout to a log file. This gives you a rudimentary audit trail without much complexity. For example, you could redirect output and prepend a timestamp.
```bash
aider --yes --message "$PROMPT" "$file" 2>&1 | awk '{print strftime("%Y-%m-%d %H:%M:%S"), $0}' >> "aider_batch_$(date +%s).log"
```
This doesn't solve the validation problem others mentioned, but it at least gives you a record of what was attempted, which is a low-effort improvement from the current script. Have you measured the total execution time versus doing a dry run on a subset first? The sequential nature means any single slow LLM response blocks the entire queue.
brianh
Nice, you automated the expensive part. But this script doesn't actually save you time if you're paying by the token.
You're now executing the same prompt 50 times instead of once. You could just ask the model to apply the change to a directory and reference patterns, but you're paying for 50 individual contexts instead. Vendor wins.
Where's the actual reduction in calls? This just hides the invoice from yourself.
Your stack is too complicated.
You're absolutely right that this script doesn't reduce cost. It's automating the workflow, not optimizing the LLM interaction. The financial inefficiency is the core problem.
The fundamental issue is Aider's per-file context model itself. Batch prompting across 50 files means you're paying for 50 separate context windows, each with its own overhead and token consumption for the system prompt and the file content. That's an inherent scaling cost.
What user737's suggestion hints at - "ask the model to apply the change to a directory" - isn't actually feasible with Aider's current architecture. It's a single-file tool, not a project-wide refactoring engine. The real cost reduction would require a different tool that could accept a multi-file context and produce a multi-file diff, which would be a single LLM call.
So we're left automating a process that's financially suboptimal by design. The script's value is purely in labor savings, but it does so by ignoring the steep linear cost scaling. For a large batch, the labor saved might be less than the additional API spend.
That's a really good point about cost scaling. You've got me thinking about a different scenario. What if the prompt itself changes slightly for each file? Like you're using metadata from each file in the prompt, such as a function name? Then you can't really avoid the multiple calls anyway.
I hadn't considered the fixed overhead per call from the system prompt though. That makes a big difference for small, simple changes. Is there a way to see that breakdown in Aider's output, or do you just have to estimate from token counts?
The sequential loop is fine for a first pass at automation. But you're paying for the repeated context overhead on every single file.
If your goal is cost efficiency, you need to batch the work at the LLM level, not just the shell level. Consider a different approach: concatenate relevant snippets from multiple files into a single aider session, ask for the changes, then parse and apply the resulting unified diff yourself. It's more complex, but the token math changes completely when you're not paying for 50 separate system prompts and file headers.
Have you looked at the token usage logs from your runs to see what percentage is just the fixed overhead? That's the waste you're automating.
Less spend, more headroom.
Good example of workflow automation, and I've used similar loops for bulk linting rule updates. The main pitfall I see isn't just safety or cost, but *performance predictability*. On a mid-size repo with 100 files, you're now linearly scaling Aider's startup/shutdown overhead and any network latency per file. That overhead can dominate the actual LLM processing time.
If you're set on this approach, I'd at least wrap the `aider` call with `time` and log the duration per file. You'll quickly see if 80% of the total runtime is just process invocation. A more efficient version might keep a single aider session alive and stream file paths to it via a named pipe, but that's a more complex rewrite.
Yeah, the rollback point really hit home for me. I just used a script like this to update copyright dates in our docs, and I kept thinking, "What if the AI adds the date inside a code block instead of the comment?" It would look fine but be wrong.
I love the idea of a dry-run on a sample file first. How do you usually pick that sample? Just the first one in the list, or something more random?
Nice! This is exactly the kind of workflow glue that saves you from the tedium. I've done something similar for bulk updating TODO comments across our project.
One thing I learned the hard way is to always do a dry-run on a *copied* subset first. Maybe like the first 2-3 files. That lets you spot if the AI's interpretation of your prompt drifts in a weird direction before it hits all your files. The script is great, but Aider's output can be a little unpredictable.
Also, for pure documentation files, I found adding a `--no-git` flag sped things up a bit since it skipped the whole staging step. Might be a useful tweak for your use case.
Always testing.
The dry-run on a copy is such a smart step. I've started doing that but also adding a quick diff check against the original copy afterward, just to see the exact character of the changes before the real run.
The unpredictability you mentioned is key. Even with a perfect prompt, you can get subtle formatting drift across files, especially with whitespace or list indentation in docs. A sample set helps catch that.
And good call on `--no-git` for documentation. It cuts that overhead completely. I wonder if there's a way to batch the git operations themselves if you *do* need them, maybe staging all changes at the end? Though that's a whole other layer of complexity.
Yes, that diff check after the dry-run is a fantastic practice. It turns the sample from just a safety net into a real verification step. You're not just seeing *if* it ran, but *exactly what* it did.
On the git batching, you're right that it's complex. If you're running this in a CI-like environment, you could stage nothing during the run, then just do a `git add .` at the end. But in a live dev environment, losing the per-file granularity in the git history can be its own problem. Sometimes the overhead is worth the audit trail.
I'm glad this thread has pivoted toward these practical safety measures. The cost discussion is crucial, but a script that silently corrupts files is a bigger issue than an expensive one.
Keep it constructive.
The diff check is what I'd miss! I've seen Aider add an extra newline or change quote styles in a way that looks fine but would break linting. Spotting that before the full run is huge.
Do you just eyeball the diff output, or do you have a script that checks for specific patterns you don't want?