DEV Community

Nithin
Nithin

Posted on

The best AI workbench is not an IDE

#ai #productivity #tooling

There is a common beginner mistake in AI-assisted development: picking a single tool and asking it to do everything.

That is how people end up defending editors as if they were operating systems.

An editor is not a strategy. It is a window.

What matters is the execution surface behind the window: authentication, tool access, agent reliability, MCP support, and whether team knowledge can survive a change of shell.

After using Cursor, Cursor CLI, IntelliJ IDEA with AI Assistant wired to external providers, IntelliJ with Kilo Code, and Codex CLI, I arrived at a conclusion that is not fashionable but is practical:

IntelliJ should remain the workbench. Codex should become the primary agent. Cursor should be mined for what it does well, mostly skills and rules. Kilo Code should be demoted to utility work such as autocomplete and commit message generation.

This is not a benchmark of clever demos. It is a benchmark of operational friction.

This is also a personal conclusion, not a team mandate. The point is not to move the team to a new stack. The point is to build a personal workbench that works best for me while still adapting cleanly to the team's existing Cursor-based conventions.

Short verdict

If the goal is a practical daily setup rather than a vendor bet, the cleanest arrangement is:

  • IntelliJ IDEA for editing, navigation, refactoring, and inspections.
  • Codex CLI as the primary agent runtime.
  • Cursor rules and skills preserved through AGENTS.md.
  • Kilo Code used narrowly for autocomplete and commit-message assistance.

That conclusion is not based on abstract model preference. It is based on where authentication, MCP access, and team workflow actually held up under daily use.

Cursor is strongest when you stay inside Cursor

Cursor has one undeniable advantage: if your team has already invested in Cursor rules and skills, the product rewards conformity.

That matters.

Institutional knowledge beats raw model quality surprisingly often. A mediocre prompt with strong team conventions can outperform a brilliant model used in a vacuum.

Cursor authentication also keeps you inside the ecosystem where those skills are first-class citizens. If the team works through Cursor-native skills, Cursor the IDE feels coherent. The tool, the auth model, and the team workflow all point in the same direction.

But this coherence has a price: it is local to Cursor.

The moment you try to separate the agent from the IDE, the promise weakens.

Cursor's own CLI documentation says MCP in the CLI uses the same configuration as the editor and that configured servers should work in both surfaces. In theory, that is elegant. In practice, the theory leaks. In a Cursor forum thread from January 21, 2026, a team member explicitly acknowledged a known issue: cursor-agent could not handle OAuth correctly for remote MCP servers such as Figma, even though the IDE could. The same thread was still receiving reports on March 18, 2026.1 2

For workflows that depend on remote OAuth-backed MCPs, that limitation is enough to keep Cursor CLI out of the primary slot.

That matters because an increasing amount of useful agent work now sits behind authenticated remote tools rather than local prompts alone.

The real test is OAuth, not chat quality

The market is still pretending that model selection is the hard problem.

It is not.

The hard problem is whether the agent can reach the systems that matter without turning your desk into a museum of half-working clients.

Figma is the cleanest example.

Figma's remote MCP server requires OAuth. Their official documentation says so directly and includes a Codex CLI flow that prompts for authentication after codex mcp add figma --url https://mcp.figma.com/mcp.3

There is also no useful escape hatch through personal access tokens. In a Figma community thread opened on November 18, 2025, a user asked for PAT-based auth for the remote MCP endpoint. A quoted reply from Figma Support said the remote MCP server does not support authentication using personal access tokens and that this cannot be enabled; OAuth is the recommended path.4

That closes the usual loophole.

If a client does not handle OAuth correctly, the integration is not merely inconvenient. It is functionally unavailable.

This is why Cursor CLI is disqualified for my primary workflow today.

Not because Cursor is weak.

Because Figma is unforgiving.

Notion belongs in the same category. Remote MCP access is valuable only when the client can complete the auth dance cleanly and repeatably. A tool that supports MCP on a slide but fails during OAuth is doing theater, not engineering.

IntelliJ is still the best room in the house

IntelliJ IDEA remains the best physical workspace.

It is still the superior editor for large codebases, code navigation, inspections, refactors, and plain old concentration. I do not want to keep both Cursor IDE and IntelliJ open just to preserve one niche capability from each.

That setup is not power-user sophistication. It is a tax.

JetBrains has moved aggressively on AI Assistant and MCP. Their current documentation shows AI Assistant can connect to MCP servers over STDIO, Streamable HTTP, and SSE.5 JetBrains also allows third-party providers and OpenAI-compatible endpoints, but this path is explicitly API-key driven, and feature coverage varies by provider.6

That distinction matters.

An IDE feature that can consume a model is not automatically equivalent to a first-class agent runtime. The former is a panel. The latter is an operating surface.

Figma's own remote MCP installation page is a useful reality check here. As of March 22, 2026, it provides setup documentation for Claude Code, Codex by OpenAI, Cursor, and VS Code. IntelliJ is not listed among the supported client setup guides.7

That does not prove IntelliJ can never be made to work with remote MCP. It does show where official support and documentation currently concentrate.

In my setup, IntelliJ AI Assistant wired to external providers did not become the stable answer for OAuth-backed remote MCP workflows. The practical result was still inferior to using a dedicated agent client that treats authentication and tool invocation as primary concerns rather than attached features.

So IntelliJ stays.

But it stays as the cockpit, not as the pilot.

Codex CLI solves the right problem

Codex CLI succeeded where the supposedly more "native" combinations became awkward.

The decisive point was simple: OAuth-backed MCP worked.

Figma remote MCP worked properly. Notion MCP worked properly. The boring but essential part of the stack, sign-in, token flow, callback handling, tool availability, simply held together.

That is what maturity looks like in agent tooling: fewer broken rituals between intention and execution.

Once Codex handled remote MCP cleanly, the rest of the architecture became obvious.

Use IntelliJ as the IDE.

Use Codex as the primary agent runtime.

Keep Cursor knowledge without keeping Cursor as the center of gravity.

The bridge matters more than the model

The most expensive part of switching tools is not the subscription.

It is the loss of team memory.

That is why the AGENTS.md bridge is the most important piece of this workbench.

By teaching Codex to treat .cursor/rules/*.mdc and .cursor/skills/**/SKILL.md as source-of-truth instructions, the setup stops being ideological and becomes mechanical. Cursor skills remain usable. Cursor rules remain usable. Team conventions survive. My workbench changes; the shared operating doctrine does not.

This is the right way to personalize AI tooling inside a team without forcing the team to follow.

Do not rewrite every rule because a vendor changed.

Do not ask the team to learn a second set of rituals.

Move the execution engine locally. Preserve the doctrine globally.

That is exactly why Codex is a better primary workflow than Cursor IDE in this setup: it can inherit the team's Cursor knowledge while also handling the remote MCP reality that Cursor CLI still fumbles.

The bug that weakens trust

There is another reason not to make Cursor IDE the center of the system: reliability debt.

I have seen occasional cases where agent changes do not appear correctly in the Git changelist inside Cursor. There are workarounds, restarts, and folklore. I have not found a permanent fix worth trusting a primary workflow to.

Intermittent bugs are how tools slowly lose authority. A development surface must be boring when it comes to source control visibility. If the user has to wonder whether a file changed or merely failed to appear, the editor has ceased to be infrastructure and has become weather.

Comparison in practice

Setup What worked What broke or stayed weak Verdict
Cursor IDE Cursor-native rules and skills, coherent in-product workflow Git changelist visibility sometimes unreliable, requires staying in Cursor to get the full benefit Useful, but not my center of gravity
Cursor CLI Reuses Cursor MCP configuration and team skills in principle Remote MCP OAuth remained unreliable for the workflows that mattered most Not suitable as primary runtime
IntelliJ + AI Assistant with external providers Excellent IDE, strong editing and refactoring environment, growing MCP support Not listed in Figma's official remote MCP client setup docs; also did not become the most reliable home for remote OAuth-backed MCP workflows in my setup Best editor, not best agent runtime
Codex CLI Remote MCP with OAuth worked cleanly for Figma and Notion; agent workflow felt dependable Less value from Cursor-native ecosystem unless bridged deliberately Best primary runtime
Kilo Code Helpful for lightweight assistance Not the tool I would trust for heavy MCP-centric workflows Keep it narrow

The resulting workbench

The final arrangement is not elegant in the way marketing teams prefer. It is elegant in the way a good wrench is elegant.

The workbench is:

  • IntelliJ IDEA for editing, navigation, refactoring, and staying in flow.
  • Codex CLI as the primary agent for serious work, especially when remote MCP with OAuth is involved.
  • Cursor CLI as a secondary utility when team-specific Cursor workflows are still useful, but not as the foundation.
  • Kilo Code for lightweight assistance such as autocomplete and commit message generation through OpenAI auth.

This division of labor is healthy.

Each tool is forced to do only the job it is actually good at.

That is rare in modern AI tooling, where every vendor wants to be your editor, shell, browser, memory layer, and therapist at the same time.

Conclusion

The winning setup is not Cursor versus Codex versus IntelliJ.

That framing is too small.

The real contest is between two philosophies.

One philosophy wants a single branded surface to own the whole experience.

The other treats the development environment as a federation: one editor, one primary agent runtime, a few specialized helpers, and a thin compatibility layer to preserve team knowledge.

The second philosophy wins because it respects reality better.

Today, that means IntelliJ IDEA as the room, Codex CLI as the worker, Cursor rules and skills as inherited doctrine, and Kilo Code as a useful but limited assistant.

The best AI workbench is not the one with the most features.

It is the one that authenticates, executes, and gets out of the way.

Sources

  1. Cursor documentation says the CLI shares MCP configuration with the editor and exposes cursor-agent mcp login for authentication. ↩

  2. Cursor staff acknowledged on January 21-22, 2026 that cursor-agent had a known OAuth issue for remote MCP servers such as Figma and GitHub, with additional user reports still appearing on March 18, 2026. ↩

  3. Figma's remote MCP documentation says the remote server requires OAuth and includes a Codex CLI setup path that prompts for authentication. ↩

  4. This relies on a quoted support reply in the Figma community thread, so treat it as support guidance surfaced through the forum rather than a standalone product-spec page. ↩

  5. JetBrains AI Assistant documentation currently lists STDIO, Streamable HTTP, and SSE as supported transports for MCP servers. ↩

  6. JetBrains documents third-party provider integration through API keys and notes that some feature availability depends on provider and model support. ↩

  7. On March 22, 2026, Figma's remote MCP installation page listed setup guides for Claude Code, Codex by OpenAI, Cursor, and VS Code, but not IntelliJ. ↩

Top comments (0)