Hey everyone! 👋 I've been living in Aider for the last few months, and it's completely changed my prototyping workflow. But I kept running into a specific, nagging issue: sometimes, in its enthusiasm to solve my prompt, Aider would suggest changes that inadvertently broke something else—like removing a crucial null-check or changing an API call in a way our backend wouldn't accept.
I wanted a safety net that worked *with* Aider's iterative flow, not against it. So, I built a simple "safety linter" that acts as a gatekeeper *after* Aider generates its proposed changes but *before* the commit is made.
The core idea is straightforward:
* Aider writes the proposed edits to the files.
* My script runs a set of fast, project-specific checks on the changed lines.
* If any checks fail, it blocks the commit, outputs a clear error, and rolls back the changes so Aider can try again with better context.
Here’s a taste of the kind of rules I’m running (they're just shell commands/scripts):
* **No missing validation:** Scan changed lines for specific functions and ensure a companion null/empty check is still present.
* **API contract compliance:** For our particular backend, verify that any changed API call still includes required headers.
* **Internal convention enforcement:** e.g., Ensuring new logging uses our structured format.
It’s not fancy AI, just simple pattern matching and diff parsing. But the impact on my confidence is huge. I can now give Aider more ambitious prompts without that sinking feeling of "what did it just break?"
I'm curious if others have built similar guardrails. What kind of project-specific safety checks would make the most sense for your workflow? I’m thinking of adding a simple config file to make it easier for others to adapt.
happy evaluating!
This is a great solution to the specific problem. I hook a similar check into my CI pipeline, but running it pre-commit is smarter for the iterative loop.
How are you capturing the diff to run the checks against? I found git diff --cached to be unreliable in the middle of Aider's process. I ended up having Aider write to a temporary branch first.
Also, do your checks run unit tests, or just static pattern matching?
Proof in production.
That's such a neat hack! The rollback on failure is a genius detail - it keeps the loop tight with Aider.
> How are you capturing the diff to run the checks against?
I'm curious about this too. I tried something similar using git diff but ran into edge cases where staged and unstaged changes got messy. My janky workaround was to have Aider write to a parallel `_temp` directory and run my checks there before copying over, but I love the temp branch idea, it's cleaner.
For my checks, they're a mix:
* Static patterns for "obvious" stuff (like missing null checks on certain methods).
* A lightweight script that pings a local mock of our API with the new signatures to catch contract drift - it's not a full unit test suite, but it's fast enough for this pre-commit hook.
What kind of shell commands are you using for your API compliance check? I'm always looking for simpler patterns to steal