Hello, Curious Coders
Once you understand how AI agents actually work, the next question usually shows up fast:
Which one should I be using?
There are dozens of options now. ChatGPT, Claude, Cursor, Copilot, and new ones every month. It’s tempting to compare features, context windows, and benchmarks.
But that’s usually the wrong question.
The “best” agent depends less on capability and more on where it sits in your workflow. In this post, I’ll show you a simpler way to think about agent choice, and one rule you can use immediately to avoid most bad tool decisions.
🎯 Join Groxio's Newsletter
Weekly lessons on Elixir, system design, and AI-assisted development — plus stories from our training and mentoring sessions.
We respect your privacy. No spam, unsubscribe anytime.
The Mistake Most People Make
When developers compare AI tools, they tend to ask:
Which one is smarter?
Which one has the biggest context window?
Which one writes better code?
Those aren’t useless questions, but they miss what matters most day to day.
Different agents are optimized for different interaction styles. Some are better at extended conversations. Others shine at short, focused edits. A few work best embedded directly in your editor, while some are better kept at arm’s length.
If you pick the wrong tool for the job, even a very strong model will feel frustrating.
A More Useful Framework
Instead of asking “Which model is best?”, it helps to ask:
Where is this agent sitting in my workflow?
AI agents tend to fall into three roles. Most tools mix these to some degree, but they usually have a clear center of gravity. Once you see that, the choices get much easier.
Conversation-First Agents
These are tools like ChatGPT or Claude in their chat interfaces.
They shine when you’re thinking through a problem, exploring tradeoffs, shaping a solution, or looking for explanations rather than just code. They’re good at holding context for a while and reacting to nuance.
They’re also where people get into the most trouble.
Long conversations create the illusion of shared understanding. The model sounds consistent, so you assume it remembers decisions the same way you do. As we saw in the previous post, that assumption breaks down quietly.
Conversation-first agents work best as thinking partners, not as system builders.
Editor-Embedded Agents
Tools like Cursor or Copilot live inside your editor, and that changes the dynamic completely.
Instead of holding everything in chat, these agents see the file you’re working on, see nearby code, react to local structure, and work best on small, concrete changes.
They’re excellent at completing functions, refactoring code, generating tests, and making mechanical edits safely.
They’re much worse at inventing architecture, coordinating changes across many files, or holding long-term intent.
Used well, editor agents feel like very fast juniors who never get tired. Used poorly, they happily generate confident nonsense.
Task-Focused Agents
Some tools are optimized for narrow tasks: reviewing diffs, generating documentation, running static analysis, or answering very specific questions.
These agents usually operate on limited input, have clear boundaries, and produce predictable output. They’re less flashy, but often more reliable.
In Elixir systems, they’re especially useful for code review, invariant checking, test generation, and documentation passes.
They don’t drift — and that’s the point.
“A strong model in the wrong role feels weak. A weaker model in the right role often feels surprisingly effective.”
— Bruce Tate
Why This Matters More Than Model Quality
Most frustration with AI tools comes from role mismatch, not bad models.
If you ask a conversation-first agent to design your system end to end, it will happily do so and quietly make dozens of architectural decisions you didn’t approve.
If you ask an editor agent to reason about your domain, it will struggle because that’s not what it’s built for.
Choosing the right agent is mostly about choosing the right constraints.
One Practical Rule You Can Use Today
Here’s a rule that works well in practice:
Use conversation-first agents to decide.
Use editor-embedded agents to execute.
If you’re still deciding what the system should do, stay in chat. Once the decision is made, move into the editor and let the agent help you implement it — locally, explicitly, and in small steps.
Don’t blur the line.
When people say “AI broke my system,” what they usually mean is that they let a conversational agent slide into an execution role — usually without noticing it until things felt off.
Why This Fits Elixir Especially Well
Elixir rewards small functions, explicit boundaries, and narrow responsibilities. That’s exactly where editor agents shine.
At the same time, Elixir systems need careful upfront thinking about processes, supervision trees, and data flow. That’s where conversation-first agents help you reason before you write.
When you match the agent’s role to Elixir’s strengths, AI feels like leverage instead of chaos.
Closing Thought
There’s no “best” AI agent. There are agents that match the work you’re doing right now, and agents that don’t.
Once you stop treating them as magical coworkers and start treating them as tools with specific roles, the confusion disappears.
In the next post, we’ll get concrete: how to guide AI completions inside your editor without elaborate prompting, and why naming and structure often matter more than anything you type into chat.
See you there.
— Paulo Valim & Bruce Tate
Go Deeper with the Groxio Yearly Subscription
This article is part of Groxio’s ongoing work on AI-augmented Elixir development. The Groxio Yearly Subscription gives you access to our full Elixir curriculum — including Elixir, LiveView, OTP, and our new AI course. The first AI module is already available, with more releasing over time.