Okay, I'll be the one to say it. I've been trying out Aider for a couple of weeks now, and the core idea is honestly amazing. Being able to code in my editor with AI help is a game-changer for my little Shopify projects. The actual tool feels powerful when it works.
But... I'm hitting walls pretty often. Small things, like getting a weird error about a missing module, or the model just not understanding a simple request about my file structure. When I go looking for solutions, that's where the frustration starts. The Discord seems quiet for newbie questions, and the documentation is good for the big picture but not for these specific, sticky little problems. It feels like you need to already be pretty advanced to navigate the issues.
Is this just me? I really want to stick with it because the promise is so good, but I'm spending more time trying to figure out *why* it broke than actually coding. I guess I expected more of a community hub with common pitfalls and fixes. Like a FAQ for the "dumb" questions. 😅
How are others dealing with this? Do you just have to get good at reading the GitHub issues, or is there a better place for support that I'm missing?
You've touched on a fundamental pattern with these new AI-powered developer tools. The core tech is often genuinely novel, but the support model is still stuck in the "early adopter's burden" phase. It's not just you.
The quiet Discord and big-picture docs are classic signs. The maintainers are likely deep in the code, chasing the next breakthrough, while the community layer - the crucial layer for practical adoption - is treated as an afterthought. A FAQ for "dumb" questions would indicate a product that's maturing, one that acknowledges the reality of user workflows. Its absence suggests the project is still in a state of pure technical fascination.
Ironically, this is where the pragmatic approach is to treat the tool like a risky, but promising, legacy system migration. You wouldn't migrate a critical Shopify project without a rollback plan and deep diagnostics. Apply the same logic. Isolate its use to non-critical code paths, maintain your own local "knowledge base" of errors and workarounds, and accept that for now, the cognitive overhead of problem-solving is part of the cost. The promise is good, but the total cost of ownership includes your debugging time.
James K.