It's not "rewriting correct code." It's failing to recognize that the current code already satisfies the prompt's implicit requirements. The AI sees a prompt, builds a plan, and executes it without a perfect diff of the existing logic.
Main reasons:
* **Poor context from the prompt.** Vague prompts force the LLM to guess intent, leading to unnecessary changes.
* **Overly broad hunks.** If the relevant code section is too large, the AI might not correctly isolate the exact change needed.
* **The AI's "plan" is flawed.** It decides a refactor is needed when a simple tweak would do.
Example: You have a function that filters a list correctly. You ask, "Make it handle empty lists."
**Before:**
```python
def filter_active(items):
return [item for item in items if item.status == "active"]
```
**After (unnecessary rewrite):**
```python
def filter_active(items):
if not items:
return []
active_items = []
for item in items:
if item.status == "active":
active_items.append(item)
return active_items
```
The original already handled empty lists (returns `[]`). The AI constructed a plan to "add empty list check" and implemented it verbatim, ignoring the existing behavior.
Fix: Write prompts that are surgical and reference the exact current behavior. "The `filter_active` function already returns an empty list for empty input. Ensure it still does, but also add a log line for that case."
You nailed the three main culprits, especially the "flawed plan" one. I've seen that exact pattern where the AI decides a refactor is necessary, and then it just plows ahead with a verbatim implementation of its plan, even if the original code was perfectly fine.
One thing I'd add: sometimes the AI's plan is actually *reasonable* in isolation, but it fails to check that the existing code already covers the edge case. Your empty list example is perfect - the list comprehension already handles it, but the AI's internal plan says "add guard clause for empty list" and it does that without looking back at the original logic. It's like it's designing from scratch rather than editing in place.
I wonder if this is partly a chunking issue from the tool's side. When Aider sends a diff, does it always include the full function context? If the chunk is too tight, the AI might not see the original return statement at all before it starts writing its new version. That would explain why it sometimes "forgets" what the code already does.
So the fix might be less about the prompt itself and more about how we structure the edits - maybe keep the relevant lines visible and tell the AI to only change the specific part, not the whole block. Have you tried explicitly saying "keep the existing list comprehension, just add a condition before it" or something like that?
customer first
You've got the root cause. The AI's "plan" is brittle because it's built on a shallow parse of the prompt and a shallow scan of the code. It treats the prompt as a specification for a *new* piece of software, not an edit to an existing one.
The underlying issue is the diff context window. If Aider sends a chunk that's too big, the model gets lost in the noise and defaults to its own blueprints. If the chunk is too small, it lacks the surrounding structure to see the existing logic. Getting that balance right is where the tool often fails, leading to these unnecessary refactors.
It's less about intelligence and more about the model being given a bad map of the territory.
Trust but verify – and audit