Overview
The AI tooling landscape changed quickly. A flat list of products and config folders is no longer the most useful way to understand it. What matters more is how these tools fit into a real workflow: IDE-first coding, terminal agents, MCP-heavy local setups, or cloud-native builders.
This guide groups the tools that way. The goal is not to pretend every product exposes the same config model, but to give a more practical map of the ecosystem as it exists in 2026.
How I Group These Tools
AI IDEs
These tools live primarily inside an editor or desktop development environment. They are usually the best fit when you want code completion, in-context edits, chat, and workflow assistance without leaving the IDE.
CLI Coding Agents
These tools work best in the terminal. They tend to fit developers who prefer shell-first workflows, scripted automation, or tighter control over how an agent reads, edits, and executes.
MCP and Extension Ecosystems
Some tools matter less because of the chat box itself and more because of how they connect to local tools, editors, APIs, or agent skills. In practice, this is where MCP and plugin ecosystems become important.
Cloud-Only Builders
These products are primarily browser-based. They are useful for quick prototyping, product ideation, and lightweight app generation, even if they are not always the best home for a serious local development workflow.
2026 Tool Overview
| Tool | Category | Official Docs | Global Path | Project Path | Notes |
|---|---|---|---|---|---|
| Cursor | AI IDE | docs.cursor.com | Not documented | N/A | Official docs are the right source, but I am not asserting a canonical global config path here. |
| Windsurf | AI IDE | docs.windsurf.com/windsurf | Not documented | N/A | IDE product with growing docs around plugins and web search, but no single global path is asserted here. |
| Gemini Code Assist | AI IDE | cloud.google.com/gemini/docs/codeassist/overview | Platform-dependent | Platform-dependent | IDE setup depends on client and platform rather than one universal path. |
| Gemini CLI | CLI Coding Agent | developers.google.com/gemini-code-assist/docs/gemini-cli | ~/.gemini/settings.json | .gemini/settings.json / GEMINI.md | Official docs describe both user-level and project/workspace config, plus GEMINI.md context files; extension docs add commands, skills, hooks, and MCP. |
| Claude Code / Claude Desktop | MCP and Extension Ecosystem | code.claude.com/docs/en/plugins | ~/.claude/ | .claude/ | Claude docs distinguish standalone configuration from reusable plugins with .claude-plugin/plugin.json. |
| Cline | AI IDE | github.com/cline/cline | Editor-managed | Editor-managed | Mostly extension-based rather than centered on one documented filesystem path. |
| Continue | MCP and Extension Ecosystem | docs.continue.dev | Not documented | Not documented | Extension + config driven, but exact path layout varies by editor and setup. |
| GitHub Copilot | AI IDE | docs.github.com/en/copilot | Editor-managed | Editor-managed | Strong IDE integration; local state depends on editor and OS. |
| Aider | CLI Coding Agent | aider.chat/docs | ~/.aider.conf.yml | .aider.conf.yml | Terminal-first coding workflow with both user-level and project-level config files. |
| Cody | AI IDE | sourcegraph.com/docs/cody | Not documented | Not documented | Editor and Sourcegraph ecosystem integration; I am not asserting a canonical local path here. |
| Tabnine | AI IDE | docs.tabnine.com | Not documented | N/A | Completion-first tool with product-specific config, but no exact path is asserted here. |
| Tabby | CLI Coding Agent | tabby.tabbyml.com/docs | ~/.tabby/ | N/A | Self-hosting and local model workflows are part of the appeal. |
| Replit Agent | Cloud-Only Builder | docs.replit.com/replitai/agent | Cloud-only | Cloud-only | Web-native workflow rather than local config heavy. |
| Supermaven | AI IDE | supermaven.com/docs | Not documented | N/A | Editor-assistant workflow; no exact global path is asserted here. |
| Amazon Q Developer | AI IDE | docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/ | Platform-dependent | Platform-dependent | AWS-integrated setup details depend on client, platform, and sign-in flow. |
| v0.dev | Cloud-Only Builder | v0.dev | Cloud-only | Cloud-only | UI/app generation in the browser. |
| Bolt.new | Cloud-Only Builder | bolt.new | Cloud-only | Cloud-only | Browser-first app generation workflow. |
| OpenCode | CLI Coding Agent | opencode.ai/docs/ | ~/.opencode/ | N/A | Open-source coding agent with official docs. |
| Codex | CLI Coding Agent | developers.openai.com/codex/plugins | ~/.codex/config.toml | N/A | Official docs confirm the user-level config file at ~/.codex/config.toml; I am not claiming a separate project config path here. |
| Antigravity | AI IDE | antigravity.google/docs | Not documented | Not documented | Official Google docs position Antigravity as an IDE/agentic development environment; explicit config paths were not confirmed in the docs I checked. |
What Actually Matters in Practice
If you spend most of your day inside an editor, AI IDEs are usually the center of gravity. If you prefer shell-first workflows, CLI agents are often more transparent and easier to script. If you care about custom tools, local automation, and agent interoperability, MCP and extension ecosystems matter more than the chat UI itself. And if you are sketching ideas quickly, cloud-only builders are often the fastest place to start.
A practical setup in 2026 usually mixes categories instead of picking one winner. Many developers use an IDE assistant for editing, a CLI agent for repo-wide changes and verification, and a cloud builder only for fast prototypes or UI exploration.
MCP and Local Configuration Notes
One reason these tools are easy to miscompare is that they do not expose configuration in the same way. Some have obvious top-level config folders. Some hide most of the behavior inside editor extensions. Some are cloud-native and barely have a local footprint. Treat the paths in this post as typical entry points, not universal truth, unless the official docs say otherwise.
MCP support also varies in practice. In some tools it is a first-class part of the product. In others it is only one extension path among several. Local configuration can also be split across app settings, editor state, environment variables, auth files, and project-level instructions, so a single path rarely tells the full story.