Replies: 2 comments 1 reply
|
This was intended to mimic Aider's behavior when using commands like Since then, Aider has added support for staying in That said, I agree it might be better to remove the Lock feature altogether and allow seamless switching between modes without requiring a lock. I’ll look into updating that. |
0 replies
|
The behavior was changed in v0.11.0. |
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
I understand that the system is working as intended, but let me say: if you’re used to working with Aider, it’s extremely confusing when you switch to “Architect,” post something, and—even before you receive the response— aider-desk automatically switches back to code.
A typical user (like me) would assume that’s a bug. I noticed the “lock” option, and I get its purpose… but honestly, for someone who’s used Aider for a long time, it feels completely disorienting—because with Aider, you are in control, not the software. 😏
@wladimiiir, I’m sure you had the best intentions when you implemented the auto-switch, but I’m frustrated by having to lock and unlock everything constantly. If I switch to Architect, I want to remain in that mode until I decide to change it—it should be my choice when to switch. 😏
At first, I genuinely thought this was a frustrating bug because it kept switching back. To be honest, I can’t see any reason for this behavior. If I switch to a mode, it should be my decision to stay there—so why switch back automatically? Moreover, when I switch to Agent mode, it remains in that mode, which makes this inconsistent.
My suggestion: remove the auto-switch feature. If a user changes the mode, they intend to stay there—that’s the whole point of these modes. Auto-switching feels like an unnecessary extra that I have to keep track of.
Thanks! 🙈
All reactions