Just migrated a team to Aider and we're hitting a snag. The speed is fantastic for boilerplate and refactors, but twice now it's inserted completely plausible-looking function calls that don't exist in our libraries. One was a subtle bug that almost made it to a PR.
For mission-critical modules, we're back to double-checking every single line it writes, which defeats the purpose.
What's your practical workflow for this? I've started:
- Using it only for non-critical, well-tested areas first.
- Giving it the exact function signatures we use in a prompt.
- Running a tighter test suite immediately after.
But I feel like I'm missing a trick. How are you all managing the risk/reward balance on important code? Any specific prompting strategies or review steps that catch these without slowing to a crawl?
—j
Trust the trial period.
I'm a data engineering lead at a ~200 person logistics company, and we've been using Aider in production for about six months to assist with our Python data pipelines and SQL transformations.
Here are the specific patterns we've settled on to manage hallucinations, ranked by impact on our workflow.
1. **Strict context anchoring with linting output:** We run `pylint` or `flake8` on the current file and paste the *exact* output into the chat before any edit command. This gives Aider a snapshot of the real symbols and their line numbers. It cuts down on invented function calls by about 70% in my estimate.
2. **Incremental prompting for new logic:** We never prompt for a whole new module. We write the function signatures and docstrings ourselves, then use Aider to fill in the implementation in steps. For example, we'll commit the stub `def calculate_route_efficiency(waypoints: List[Dict], depot: Point) -> float:`, then prompt "implement this function using the `haversine` function from our `geo_utils` module and the `optimize` function from `routing.core`."
3. **Automated guardrails with pre-commit:** We added a lightweight pre-commit hook that runs a script to check for imports of modules not in our project's `requirements.txt` or `pyproject.toml`. It's not foolproof, but it catches the "imports non-existent lib" class of hallucination instantly.
4. **The code review sandwich:** We use Aider to generate the first draft and initial tests. A human writes the review. Then, we use Aider *again* to implement the requested changes from the review. This keeps the speed benefit while inserting a human sanity check at the most critical point.
My pick is to stick with Aider, but only for the "first draft" and "revision" phases, never for the final say. If your team's pain point is speed of initial code generation, it's still a net win. If your main need is 100% correct code without review, the tool isn't there yet.
Data is the new oil - but it's usually crude.