Okay, I have to get this off my chest. I've been using Aider for a few months now, mainly for scripting tasks and tweaking our marketing automation logic. The functionality is incredible—truly. But I've hit a wall with the core interface.
For quick, one-off fixes, the chat is perfect. However, when I'm trying to refactor a complex lead scoring module or build a new integration pattern, the back-and-forth in a single chat thread feels… chaotic. I lose my place. I find myself scrolling up constantly to remind myself of a decision we made five messages ago. It breaks my flow state completely.
I'm comparing it to my work in our CRM or CDP, where I have a structured view of the object model, the workflows, and the code. Here, it's just a stream of consciousness.
Am I using it wrong? Has anyone else felt this? I'd love to hear how you all structure your "deep work" sessions with Aider. Maybe there are tricks I'm missing?
Some specific points:
* Do you start a fresh chat for every major task, even if it's related to the same codebase?
* Do you keep a separate note-taking app open to track decisions and prompts you've used?
* Or do you just embrace the stream and have a different way of managing the context?
Maybe I'm just too used to traditional IDEs, but I feel a hybrid approach would be magic. Keen to compare notes!
~Jen
Always testing the next best thing.
Totally feel you on the stream of consciousness problem. I've started treating the chat like a dev log for specific changes. So yeah, I'll start a fresh chat for each new feature or refactor, even in the same project. It keeps the context clean.
But I also have a plain text file open to paste key prompts or decisions. It's messy, but it helps when I need to retrace steps later.
Do you think having a way to "bookmark" or pin certain messages in the chat would fix the scrolling issue?
Containers are magic, but I want to know how the magic works.
Nope, you're definitely not the only one. That "stream of consciousness" feeling is real when you're knee-deep in a refactor. I hit the same thing when working on complex CloudFormation or Terraform modules.
I've adopted a split approach that helps. For a clearly defined feature or refactor, a fresh chat is essential - it's like a new branch. But I also have my IDE open on one side for the structured view, and Aider on the other just for the conversation. I'll paste important context, like the current module's interface, right into my prompt so it's in the thread. It creates a snapshot for that part of the work.
The separate notes app is a lifesaver, though. I keep a simple markdown file per project where I log the successful prompt patterns and architectural decisions. It's extra work, but it saves so much scrolling later. Maybe the dream is a hybrid interface where the chat lives alongside a persistent project scratchpad.
cost first, then scale
Yeah, that structured view comparison hits home. When I'm working on Zendesk ticket field logic, having the object model right there is key. In a chat, that context just... evaporates.
You mentioned starting a fresh chat for every major task. I've been forcing myself to do that, even when it feels wrong to "reset" a conversation. It helps, but then I'm managing five different chats for one project. Have you found a good way to name them so you can actually find the right one later?
That stream of consciousness feeling is exactly why I'm hesitant to use these tools for anything beyond small scripts. For my SaaS integrations, the context is everything - the field mappings, the authentication flow, the error states. When I look at a chat, I can't "see" that structure.
> a fresh chat for each major task
I've tried this too. But my issue is with the naming - if I call one "webhook setup," how do I later know which part of the webhook flow it covers? The retry logic? The payload transform? It just becomes a list of vague chats.
Do you ever copy the final, working prompt from a successful session and paste it into a project doc as a reference? I'm thinking of doing that, but I'm not sure if it's worth the overhead.
Still learning.
You're definitely not using it wrong - the interface is built for conversation, not project management. It's like trying to do complex CRM data modeling entirely in a support ticket system.
I hit the exact same thing comparing it to our HubSpot workflows. When I'm refactoring an email automation sequence, I need to see the trigger logic, the wait steps, and the branch conditions all at once. In a chat, you only see the last step you discussed.
I've found that for a complex module, I absolutely start a fresh chat. But here's my trick: the first message isn't a prompt. It's a spec. I paste in the current module's structure, list the 3-4 specific goals for the session, and only then start asking for changes. It creates a mini "project charter" at the top of the thread. Still not a structured view, but better than diving straight in.
Do you find you're pasting the same module context repeatedly, or does your process change each time?
Benchmarking my way to better decisions
That hybrid interface idea is spot on. I'm in the middle of evaluating some sales ops tools, and that "persistent scratchpad" sounds like the perfect middle ground.
But I'm curious about something you said. You keep a markdown file for successful prompt patterns. Does that mean you're treating Aider less like a coding partner and more like a library you're documenting? I'm wondering if the extra work to document the prompts pays off when you return to a project after a few weeks. Does it actually save time, or does it just feel like good housekeeping?