Codeium or GitHub Copilot for a Ruby on Rails codebase?

Your concern about plugin conflicts is valid. I run a similar VS Code setup on a Mac for Rails work and find Copilot more stable, especially with Solargraph. Codeium's free tier sometimes chokes on large ERB partials and fights with the AWS Toolkit's YAML language server.

If you're committed to staying in VS Code, Copilot's integration is simply tighter. It respects your existing language server more consistently. The memory hit is negligible compared to having Solargraph and the AWS extension running anyway.

For Terraform, neither is great, but Copilot's snippets for AWS provider blocks are slightly more reliable. Test both for a week on a branch, but prioritize stability over a few extra features.

Agree on stability being the main sell. But that "negligible memory hit" adds up once you've got a dozen browser tabs, Docker, and the Rails server all running. On a 16GB Mac, it's not negligible.

Also, if you're using HAML like the OP mentioned, Copilot's suggestions get weirdly literal. It starts generating HTML tags inside the HAML syntax. Ends up being more of a distraction than a help in those files.

16GB should be plenty if you aren't running the whole circus at once. The real drain is having a dozen browser tabs open to begin with. Close some.

The HAML point is valid though. Copilot flailing on template syntax is exactly why I don't trust these things for real work. They're pattern matchers, not understanders. You spend more time rejecting bad suggestions than you save.

Thanks for laying out your setup so clearly. For your specific extension stack - especially with Solargraph and the AWS Toolkit - I've heard fewer reports of weird interference with Copilot. It tends to queue behind the language servers a bit better.

The HAML and ERB concern is real for both tools, honestly. You might find yourself disabling the AI suggestion shortcut in those files and just using it for pure Ruby. It's a trade-off, but the stability for your core Ruby files and Terraform snippets is probably worth it.

Since you're making a decision for the team, the built-in policy controls in Copilot for Business might tip the scale. It lets you manage code matching on private repos, which can ease some security concerns your teammates might raise.

Your concern about plugin conflicts is real, but you're looking at it backwards. The bigger issue with your setup is Solargraph itself. It's a massive resource hog on any non-trivial Rails codebase, and layering an AI tool on top of it is asking for your editor to freeze. Both Copilot and Codeium will fight it for LSP priority.

If you insist on keeping Solargraph active, Copilot tends to fail more gracefully by backing off when the language server is lagging. Codeium has been more aggressive in my experience, leading to more instances of duplicate, conflicting completions, especially in ERB files where you're getting suggestions from the HTML server and the Ruby server simultaneously.

The practical advice is to profile your VS Code with the Activity Monitor. Turn Solargraph off for a day, then turn it back on. The performance delta you see is what you're already sacrificing; an AI assistant will only add a fraction on top of that. Choose based on which one your team will actually use for boilerplate - Terraform resource blocks, repetitive factory or test setups - and disable it entirely for HAML and ERB files. They're not ready for that.

You're right about profiling to see the real cost. I did exactly that last month, and Solargraph was the clear bottleneck before adding any AI.

But for me, the duplicate suggestions you mentioned with Codeium actually helped. Seeing conflicting completions from the Ruby and HTML servers flagged a few ambiguous partials in our old codebase. It was like a free syntax sanity check.

Still, that's only useful if you can tolerate the noise. For team-wide use, quieter failing like Copilot is definitely the safer pick. Have you tried disabling Solargraph's diagnostics but keeping its definitions/completions? That cut my memory use almost in half.

Your worries about plugin conflicts are spot on. Everyone's fixated on the AI assistant, but the real culprit in that stack is Solargraph. Adding *anything* on top of it is asking for trouble.

You'll see more immediate stability gains by tuning Solargraph to only provide definitions, not diagnostics, before you even pick an AI tool. Then, if you're mostly in Ruby files, Copilot's fine. For HAML and ERB? Honestly, you'll probably just end up turning it off in those files. The suggestions get comically bad.

If you're on a team, go with Copilot. Not because it's better, but because its "quieter" failures cause fewer arguments. Codeium's aggressive suggestions are a headache in a shared environment.

Oh, you've got the perfect setup to compare them side-by-side! I ran the same test last quarter with my team's Rails monolith. You're right to be nervous about the extensions fighting each other.

For your specific stack, Copilot definitely plays nicer with Solargraph and the AWS Toolkit. It waits its turn better. But I noticed a real hidden cost: Codeium actually gave me more relevant suggestions for AWS Terraform modules, maybe because it scans public repos more broadly. So you're trading snippet quality for stability.

The HAML and ERB problem is universal, sadly. But in your position, I'd pick Copilot for the team and just add a keyboard shortcut to toggle it off quickly in template files. The mental load of managing constant conflicts is worse than the memory use. Have you considered trying one on your local and the other in a dev container to split the risk?

I generally agree that the "pattern matcher" critique is fair, but I think you're underestimating the productivity loss from constant context switching to close browser tabs or other processes. The real cost isn't the 16GB of RAM, it's the developer's time and attention fragmented across all these tools.

The more telling point is about template syntax. It's not just HAML, ERB presents a similar problem because these tools fundamentally don't parse the rendered context. You're right that you spend time rejecting suggestions, but the deeper issue is the cognitive tax of evaluating them. Each bad suggestion forces a micro-decision, which over a workday adds a real, though often invisible, drag on velocity.

For Rails specifically, the value tends to cluster in pure Ruby files - models, services, libraries. In templates, the signal-to-noise ratio is often so poor that disabling the tool becomes the only cost-effective choice.

You've nailed the hidden tax of those micro-decisions. It's like paying a tiny cognitive toll every few minutes.

I found the same pattern - value in models, noise in templates. But disabling it per-file got annoying. I ended up binding the toggle for `github.copilot.enable` to `Ctrl+Shift+P`. It's become a reflex when I switch to an ERB or HAML file.

Makes you wonder if these tools are pushing us toward architectures that are less template-heavy, just for the better autocomplete.

> "nervous about plugin conflicts"

You're right to worry, but Solargraph is your real problem. Turn off its diagnostics before even testing an AI tool.

Codeium's AWS Terraform snippets are more useful, but it clashes harder with Solargraph. For HAML/ERB, just disable whatever you pick. I use a keyboard shortcut to toggle it instantly.

Good point about the diagnostics toggle. It's often the first place to look. I'd just add that after turning off Solargraph diagnostics, you should also check its "hover" and "formatting" settings. Those can be surprisingly heavy too.

Your shortcut method is the pragmatic solution. I've found it's less about picking the perfect tool and more about having a quick on/off switch for when it's actively in the way.

Your worry about plugin conflicts with that exact setup is totally valid. I ran a similar test last month and the memory usage spike when Solargraph and an AI tool fight over ERB files is real.

For a team decision, Copilot is the less frustrating choice. It's worse at Terraform snippets, but it fails quietly. Codeium's suggestions are sometimes more clever, but it'll constantly throw two competing completions at you in a template, which gets old fast.

Honestly, neither is great for HAML. Just bind a keyboard shortcut to toggle the whole thing off. That's the real pro tip.

The advice to profile with Solargraph off is correct. You're right that its baseline cost is the main factor, not the AI tool.

But your point about AI adding "only a fraction" on top is where I differ based on vendor contracts I've seen. That fraction isn't linear. With a resource-hungry primary LSP already at 80% of a threshold, adding even a lightweight AI agent can push you into constant garbage collection pauses, which feels like freezing. The vendor's spec sheet never mentions this interaction tax.

So the choice isn't just about which fails more gracefully. It's about which vendor's engine has a more predictable resource ceiling under load. In my tests, that's still Copilot, precisely because it backs off. Codeium's "aggressive" mode is a feature until it becomes a contractual problem for team-wide performance.