Name the layer before you open the comparison table

aicoolies — Fri, 21 Aug 2026 12:29:39 +0000

This is a follow-up to Choosing an AI coding tool is now a graph problem. That piece argued the stack is a graph. This one is the working method I use when I actually write a comparison on aicoolies.

I am Raşit Akyol. The public catalog is a hand-tested knowledge graph of 1280+ AI developer tools. It is free. It is not a coding agent.

A comparison is an edge, not a trophy

That is a different sentence from Claude Code vs GitHub Copilot, where the layer is "terminal agent vs plugin" and the pick is Claude Code for deep multi-step repo work.

Same Copilot node. Two edges. Two verdicts. If a directory gives Copilot one row and one score, it has thrown the graph away.

Live pages:

What I will not do on the page

I will not invent traffic. I will not paste a benchmark I did not read in context. I will not call a catalog a coding agent. I will not ask you to upvote this.

If a comparison is wrong, say so on the page. A correction is an edit to an edge. Another listicle is not.

Catalog: https://aicoolies.com

A useful "vs" page is a claim about two nodes that share a layer. Claude Code vs GitHub Copilot is a real edge: terminal agent versus IDE plugin. Claude Code vs Docker MCP Gateway is not. Those jobs do not sit on the same edge, even if both have "AI" in the marketing.

Before I open a table I write one sentence:

Layer: ___ . Job: ___ . If I pick A, what has to change next to it?

If I cannot fill that, I do not publish the page.

One walkthrough

Cursor vs GitHub Copilot is the boring, high-traffic pair. The layer is "daily coding assistance." The job is "write and ship in an editor." Copilot stays a plugin in the editor you already use and starts cheaper. Cursor is a standalone IDE when you regularly move many files at once. Our written pick on that page is Copilot as the starting point.

Choosing an AI coding tool is now a graph problem

aicoolies — Mon, 17 Aug 2026 07:58:59 +0000

Picking an AI coding tool used to mean opening a list, scanning logos, and hoping the top row was still current. That stopped working the moment the stack split into layers. You now choose a CLI agent, an editor agent, an MCP gateway, a registry, an inference runtime, and a review loop. Those pieces connect. Change one layer and the others move.

That is a graph problem, not a list problem.

I built aicoolies as a Developer Tools Knowledge Graph for that reason. I am Raşit Akyol, a developer in İzmir, and I got tired of directories that treat Claude Code, Docker MCP Gateway, and a vector extension as the same kind of "AI tool." They are not. One writes patches. One isolates MCP servers in containers. One sits inside Postgres. If you flatten them, you pick the wrong default.

What aicoolies is

The public site is a hand-tested catalog of 1280+ AI developer tools, plus written comparisons, reviews, and curated stacks. It is free on the web. It is not a coding agent. It will not edit your repo. It is the map I open before I install something that can.

The homepage is the catalog and the recommended set. The useful work lives one click deeper:

Tool pages with pricing model, platforms, open-source status, and telemetry notes
Side-by-side comparisons that end in a verdict, not a feature grid with no conclusion
Reviews from a local run when I actually installed the thing
Stacks that show how tools sit together for a job, a role, or a budget
Public stacks from other developers, so you can see what people actually keep

I do not treat this as another AI-tools dump. A dump answers "what exists." A knowledge graph answers "what sits next to what, and which one should I start with."

Two pages I keep sending people

Grok Build vs Claude Code

Grok Build vs Claude Code exists because both are terminal-friendly coding agents. That pairing is closer than Grok Build versus Cursor. Claude Code is Anthropic's established workflow for reading a codebase, editing files, running commands, and moving across terminal, IDE, and web. Grok Build is newer, xAI-native, and built for TUI and headless use, plan mode, parallel subagents, best-of-N attempts, and controlled command execution.

The page does not call them interchangeable chatbots. Claude Code is the stronger default today: clearer docs, a more mature workflow, and a better fit for careful codebase reasoning. Grok Build earns a seat when you want competing implementations, scriptable headless runs, or an xAI lane next to Anthropic and OpenAI. The trial I recommend is the same bounded bug fix or refactor in both, then compare the diff, the tests, the commands, and the cleanup. Our pick on that page is Claude Code.

Docker MCP Gateway vs Smithery

Docker MCP Gateway vs Smithery is a layer mistake people make constantly. Docker MCP Gateway is an execution control plane. Clients connect once. The gateway starts approved servers as Docker containers, injects credentials, applies restrictions, routes the call, and can log it. Smithery sits higher: discovery, publishing, and managed connections, especially OAuth-heavy SaaS tools.

Smithery wins the managed connect and OAuth carve-out. Docker wins the secure-runtime decision, and that is the harder thing to retrofit. The combined design on the page is explicit. Use Smithery for registry and authorization where that helps. Run approved self-managed servers behind Docker Gateway when isolation matters. Our pick is Docker MCP Gateway because runtime control is the dependency you do not want to add later.

I also ran Docker MCP Gateway locally and wrote the review. On Docker Desktop it started digest-pinned catalog servers, exposed tools through a profile, denied a tool I had removed from the allowlist, and cleaned up ephemeral containers when the client disconnected. It is strong local orchestration for teams already on Docker. It is not a full enterprise authorization layer. Container flags are not RBAC.

A third live page that uses the same method is MCP Registry vs Glama. The official MCP Registry is the vendor-neutral publication layer: canonical names, namespace proof, package metadata, a sync API. Glama consumes that data and adds search, tool schemas, health signals, sandbox analysis, and an operating surface. Publishers should use the official Registry. Buyers who need to find, test, and run servers usually get more from Glama. Complementary, not clones.

How to use it

Name the job, not the category. "I need a terminal agent for a messy repo" is a job. "AI tools" is not.

Open a comparison that already frames the layer. CLI agent versus CLI agent. Gateway versus managed connect. Official registry versus discovery marketplace. Read the verdict and the workflow-fit section before the table. The table is evidence. The verdict is the decision.

If the tool can edit files or run commands, read the review or run the same bounded trial yourself. Only then look at a stack, so you see the surrounding pieces: review, CI, isolation, observability.

What I will not claim

I will not paste traffic charts. I will not score a tool I have not used. I will not pretend aicoolies replaces Futurepedia, There's An AI For That, Toolify, AlternativeTo, StackShare, or G2. Those products are broader directories or review markets. aicoolies is narrower: developer tools, hand-tested, written as a graph of comparisons, reviews, and stacks.

If you want the catalog, start at aicoolies.com. The two comparisons above are live. So is the Docker MCP Gateway review. If a page is wrong, say so in a comment on the page. A correction is more useful than another upvote.

I keep the catalog because I need it for my own stack. If it helps you pick a safer default, that is enough. Short updates go to x.com/aicoolies.

DEV Community: aicoolies