Aider-AI
Add option to force the AI to ask the user to confirm each change before doing it
Issue
Sometimes it is necessary to supervise each atomic change to the code or to the project configurations. Aider already shows us every atomic change like a diff. It would be great if, when specifically asked by the user, each change would be first shown and vetted by the user and only applied if approved. Something like a “SUPERVISED MODE” to enable when there is the need.
Version and model info
No response
Thanks for trying aider and filing this issue. Right now the recommended approach is just to use /undo to revert a change if you don't like it. Or you can turn off auto commits with --no-auto-commits.
I'm going to close this issue for now, but feel free to add a comment here and I will re-open or file a new issue any time.
Please open this improvement request. I consider it very important to have the option to validate changes before applying them, and that it can be an option that can be enabled or disabled. AI tools are still not entirely accurate and always require human review whenever possible before making a change or accepting a suggestion. @paul-gauthier
@danielorozco06 See my comment above. Is there a reason one of those solutions doesn't work for you?
@paul-gauthier While using /undo to revert changes or disabling auto commits with --no-auto-commits are useful options, having the ability to validate changes before applying them is very important for several reasons:
- Error Prevention: Validating changes beforehand can prevent errors that might not be immediately obvious and could cause issues later.
- Time Saving: Reviewing changes before applying them saves time and avoids the tedious process of undoing and correcting errors.
- Quality Control: Ensures that changes meet project standards and requirements before implementation.
- Risk Reduction: Minimizes the risk of introducing inconsistencies or errors into the code, providing an extra layer of security.
- Tool Confidence: Increases user confidence in the tool by giving them more control and peace of mind through pre-validation of changes.
I recommend doing aider --show-diffs. This way you will automatically see unified diffs for each chance as it is applied. If you don't like the diffs, simply type /undo and they will be reverted. I think that addresses all of your points?
Using aider --show-diffs to automatically see unified diffs for each change as it is applied is useful. However, from a user experience (UX) perspective, I believe validating changes before applying them is simpler and more efficient. This approach allows for corrections if necessary and provides greater ease in an iterative process of developer-suggested corrections. Additionally, it will be a feature that can be easily enabled or disabled according to each developer's preference.
Additionally, reviewing changes before applying them reduces cognitive load by eliminating the need to remember and undo incorrect changes.
Additionally, while the /undo command is useful for discarding the last commit, it doesn't fully address scenarios where multiple changes are made consecutively. If a mistake is found after several commits, relying on /undo would require reverting each commit one by one, which can be time-consuming and error-prone. Pre-validating changes allows for immediate corrections, providing a smoother and more efficient workflow.
And the/undocommand is useful for discarding the last commit, it only works if the changes have been committed. If a developer prefers to accumulate several changes before committing, finding an error in any of the changes would require a more complex rollback process.
I completely agree with @danielorozco06. The unified diffs and commits make it harder to supervise the code changes. A big batch of changes applied altogether will make it too easy to miss errors and too cumbersome to rollback everything after the commit when the error is discovered later. The most productive, secure, and effective way to do this is to let the user review and APPROVE/REJECT every single modification to the code atomically just before committing it. That will improve Aider workflow immensely.
I would even go further, and give the user the option to ask the AI to make slight modifications to each proposed atomic code change, so that, in those frequent cases when the code proposed by the AI is not completely wrong but just slightly wrong and can be fixed by changing only a few things, it would be possible to continue executing the AI planned changes instead of interrupting the workflow.
In other words, the ideal would be for the user to be presented with 5 options when each proposed atomic change is shown to him:
- APPLY - apply this atomic change as is.
- MODIFY - ask the AI to make some modifications to this atomic change and let me review it again.
- SKIP - discard this atomic change and continue with the other planned atomic changes.
- STOP - discard this atomic change, stop the application of the planned changes but keep all the already applied atomic code changes.
- REVERT - discard this atomic change, stop the application of the planned changes, and use git to revert to the original code as it was before, discarding all previous atomic changes that have already been applied.
IMHO this would be the best way to handle code changes or code generation when they need particular attention. Those 5 actions should be the standard paradigm for all AI code copilots when making changes in supervised mode. Since Aider is currently the best open-source AI copilot for coding, it would be only appropriate for it to be the first to establish this paradigm, so the others would follow.
Two other important things:
- always let the AI print a full list of all the planned changes (summarizing each in one or two short sentences) before proceeding to apply them, and let the user decide if he wants the AI to: A) proceed applying those changes unsupervised; B) proceed applying those changes step by step in supervised mode, consulting with the user before committing each atomic change; C) check again the list of planned changes for errors and possible improvements; D) discard this list of planned changes altogether.
- once the supervised mode is started, let the AI display more diff code before and after each atomic change, so that the user can better evaluate the context.
+1 to all of the above. I'll unfortunately discontinue using aider for the simple reason that LLM models can get stuck in a loop.
Now I have 3 commits of it just looping over itself and suddenly my IDE's undo commit functionality isn't working because I have pending changes elsewhere in the file.
A simple "did this work for you, before I commit it?" would improve the UX a thousand-fold.
Also your suggestions to just ~"review the unified diff" seem very out-of-touch in that they aren't easy to read which either suggests we have completely different use-cases, you have a much better styling to my default aider styling and can actually, or you're somehow in a situation where a diff output on a CLI is enough for you -- I personally need a side-by-side diff tool such as those in Webstorm or github.com
I am surprised that the option to approve each change before Aider applies it is not available. I gave Aider a fair try, but as with any AI based tool today, some results are not accurate or completely wrong. While this is expected, the inability to carefully vet each change is not. Undo is not a good solution either, as it makes approval of partial changes cumbersome and error prone, as others already mentioned.
Without this ability, I find that I'm unable to use this tool efficiently, especially on big production code where extra carefulness is needed, and so for me at least, Aider may be a cool tool for demoing what AI can do, but no more than that unfortunately.
The upside is that adding such an option should be easy, if you decide to listen to the feedback that multiple people have given you regarding this gap.
I also want this change. I use Aider quite a lot and this minor issue would not stop me from using it. I'm a bit confused at the people who have auto-commits turned on yet want Aider to walk through the diff step by step. You have the commits. Review them.
In my case the problem is related to having auto-commits turned off. I prefer to make my own commits that contain closer to a working feature/functionality, rather than having 30 or more small commits from Aider I need to squash down. I'm perfectly fine that I can't atomically "undo" any change, but I would really prefer an option that lets me review the code before applying the diffs. I'm also using Architect mode which adds another layer of indirection, since my editor-model is actually getting instructions from the architect-model. The user is already prompted with "Edit the files" when using Architect mode, I'd love it if it worked more like this:
- Submit prompt to Architect
- Prompted "Write the code?"
- Editor model gets prompt and generates the diffs, these are printed for quick review
- Prompted "Apply the changes?"
- Continue, respecting the choice
Like someone else mentioned, the ability to enter a short additional prompt based on the diffs would be fantastic as well.
Right now I just ctrl+c once I notice a diff going off the rails, and add some more text to my prompt. This isn't super efficient for a few reasons tho (uses more requests/tokens in architect mode, pollutes the chat context with duplicate / unnecessary crap, if I get distracted it will apply the code automatically, etc) and I'd prefer it if I could just say "hey let me review this code before we apply it".
Note: I personally do NOT want confirmation on every separate code block. I would much prefer being asked once per set of diffs (i.e., one /code prompt). If I answer affirmatively, it will apply all diffs. If I don't, it won't. No other changes in expected behavior. Basically something like:
# aider.py
diffs = generate_diffs(prompt)
apply_diffs(diffs)
becomes:
# aider.py
diffs = generate_diffs(prompt)
# prompt user and bail if they don't answer yes
result = input("Are you sure?")
if not check_result(result):
print("Not applying diffs")
return
apply_diffs(diffs)
that would really help save a little time for people who aren't using auto-commit. It's still not a huge problem tho, more of a nice-to-have. Aider rocks!
I use the helix editor and just found out about this. Its a killer tool combined with zellij. It basically makes helix an ai editor. I just found out about this tool so I am still trying to figure out my own workflow. But I am noticing that changes do feel very final. Currently I am using zigglings to learn zig. I open helix on the left pane, start aider on the right pane. I've been using aider with the --dry-run, --no-auto-commits, and --watch-files flags. This mainly because I have remapped my helix keybindings so that when I switch to normal mode it also saves the file, no need to run an extra command. I've noticed its easier to ask questions from within the files with AI? than using the repl(?). Id feel more confident not using the --dry-run flag if I can see the diff, make sure it is doing what it told me is doing, and accepting the changes. Then either commit changes automatically or wait until I want to commit changes manually. Anyways, I am just very excited about this tool, this is incredible for learning. Learning zig and being able to get answers, mainly clarifications, about the code or documentation just puts me on that flow state. Thank you!
This is the workflow that claude code uses. I was hoping aider might be an alternative to claude code, but I can't without this feature. The workflow where claude code asks to confirm each change before saving it, and at any point I can hit escape and provide clarification or tell it to change how it's done something, or even ask questions about the proposed change is very natural. Aider's way of running through and making changes that I have to retroactively review is just harder to use.
The authors of Aider should have a look at Aideremacs, a popular Emacs package that implements an interface for Aider. Aidermacs, by default, disables Aider`s auto commits - it captures AI changes before committing them and then uses the Emacs ediff feature for vetting modifications. This feature is enabled by default.
See here https://github.com/MatthewZMD/aidermacs?tab=readme-ov-file#diff-and-change-review.
In addition, see https://github.com/MatthewZMD/aidermacs?tab=readme-ov-file#re-enable-auto-commits:
Aider automatically commits AI-generated changes by default. We consider this behavior very intrusive, so we've disabled it.
If by default a popular Aider interface changes Aider's behavior in such a fundamental way, I believe that this option should be seriously considered to be implemented in Aider itself.
This feature is so useful in Claude Code. For each proposed small change, you get the opportunity to correct Claude if it's going down the wrong path. This collaborative approach is much more powerful than just going through all the changes made at the end, undoing them all and trying again if it got it wrong.
Another datapoint for how useful people find this workflow, OpenAI's codex tool uses the same process.
Plus one for this, integral for this to compete with the likes of Claude Code.
Just as another data point on this... I am a brand new user of Aider (as of a few hours ago). I was rather surprised to find it made some changes to files without asking me first. That I found my way to this issue within hours of using Aider for the first time I think says something.
I think having an ask-permission mode is important psychologically -- it takes time to build trust in a tool (especially when AI is involved!!) and being able to work with it in a "safe" mode goes a long way to making that trust building process less anxiety producing. "safe" to me does not mean being able to undo changes, it means NO changes unless I've explicitly allowed them.
I am a little bit confused about discussion in this thread.. would be great someone to help me clarify this: I thought aider already support the code review? My workflow for code review is:
For relative certain change: /architect , review change suggested, type y to accept the change. (start with --no-auto-accept-architect)
For relative uncertain change / relative large: /ask , given change suggestion from aider, provide refinement on more /ask . Use go ahead to accept the change. We can change the directory during discussion.
Also I don't think it is safe to let aider suggest a huge complex change, even with review. I prefer to let aider suggest / make small change step by step (and validate them through test, step by step). We can discuss with aider to figure out the step by step plan. This prompt might also be helpful: https://github.com/tninja/aider.el/blob/main/aider-software-planning.el#L25
For small / middle size change, I feel the current way to review the code change as a whole, make more sense than review individual diff one by one, cause change blocks could be relevant each other.
In claude code way, if I accept part of code it suggested, but then I changed my mind and refused other part of change. What I got is a partially change (and it might mess up with existing manual change). I might have to manually revert these stuff (is there a good way for this?). In my mind this is worse than the auto-commit way. That way is atomic and can easily reverted.
Agree that /undo might not be sufficient to manage commits. I personally manage them with emacs and magit. I believe that there are lots of other GUI / CUI based git tool can be helpful on this.
BTW, Claude Code have a full-time team backup with sufficient amount of funding. However it is commercial, and can only use Claude model, which is expensive. Aider is mostly supported by @paul-gauthier (and community) with less resource. But it is open source / free, and support all kinds of model, people can use it and deepseek model with very low cost. So that I feel it might be better if people be more patient to it's growth.
Struggling against Aider's clunky /undo workflow sent me through hours of researching if this feature was an option. Now I'm here, subscribed and +1!
Very clunky and poor UX, Claude Code is miles better for this feature alone. Wish I could cheer on Open Source, but not if they refuse to learn and listen.
The workflow of Claude Code gives full control to the developer. Each file change can be previewed in your editor of choice, you can change the code, reject the change or tell the Claude what to do different. This is a big game changes. I fully agree to @tskj - the Claude Code way of doing things is a big game changer.
If you think about it, what difference is there between writing /undo when you think the AI generated the wrong code versus writing something like /accept when you do think the generated code is right? Especially when you have the --show-diffs option so that you can be sure you know exactly what is being changed? The only real difference I can see is that one would be more common to type than the other depending on how often the AI makes the right or the wrong generation.
However, the /undo-way has the added benefit of putting everything into git, making even an /undo undoable, whereas a discarded change is much trickier to get back. You can also do things like running tests before discarding the change. Using git you have all the power of git at your disposal, so it becomes really easy to take back a whole list of changes at once.
I typically make a new git-branch every time I start working on something together with Aider on a change, so I can easily squash into a neat commit history as well, or discard the whole branch if the idea turns out to be unworkable.
