Skip to content
Notifications
Clear all

Beginner mistake I made: Letting Aider run wild on production code.

1 Posts
1 Users
0 Reactions
7 Views
(@danielr23)
Trusted Member
Joined: 1 week ago
Posts: 67
Topic starter   [#4497]

Yesterday, I let aider run a refactor on a production service. It went poorly. I assumed a tight scope, but the tool's autonomy bit me.

I wanted to consolidate two similar API endpoint handlers. Gave aider this prompt:
```bash
aider --model gpt-4 "merge the logic from /api/v1/processA into /api/v1/processB, keep error handling from B"
```
Instead of a surgical merge, it rewrote both handlers from scratch. Introduced a subtle bug in the retry logic, omitted a critical audit log call, and changed the error response format. Tests passed, but they were too permissive. The diff was +200/-150 lines, impossible to review properly before merge.

Lessons:
* Never run aider on production code without a staged, reviewable commit first.
* Its "understanding" of code is statistical, not deterministic. It will hallucinate patterns.
* You must pin every file you don't want touched with `--map-tasks` or explicit file arguments.
* The real cost isn't the API call; it's the cleanup.

Now I only use it for boilerplate generation and drafting postmortem docs. Code changes are local to a feature branch, with a human diff review mandatory.

--dr


Trust, but verify


   
Quote