Tool landscape¶

This page is a comparison framework, not a buyer's guide. It does not rank tools. It does not pick a winner. It does not promise to stay current — vendor offerings shift every quarter, and the categories themselves drift as the market matures.

The goal is to give a procurement, security, or platform team a durable structure for evaluating tools as they come up, anchored to the vendor & tool standards and vendor selection worksheet.

Currency disclaimer

Examples below reflect the market as of 2026-Q2. Specific products, pricing tiers, and feature sets change rapidly. Treat the categories as durable; treat the exemplars as illustrative.

The five categories¶

Most AI coding tools sit in one of five categories. A team usually picks one tool per category at most, and frequently fewer.

Category	What it does	Where it sits
IDE assistants	Inline suggestions, chat, light agentic actions in-editor.	In the developer's editor.
Code agents	Multi-step autonomous action across the repo: edit, run, open PRs.	In a terminal, an editor, or a hosted environment.
Coding-focused chat / browser	Conversational coding help outside the IDE.	Browser, desktop app, or chat UI.
Self-hosted / on-prem	Open-weight or licensed models served from infrastructure the company controls.	Internal compute.
Specialized	Adjacent tools that govern, route, or harden the categories above.	Network edge, gateway, or test infrastructure.

The categories are not exclusive — most teams end up with at least one tool from the IDE assistant category, sometimes paired with one from the code-agent or chat category, and (in regulated or large organizations) at least one specialized gateway.

IDE assistants¶

Tools that integrate into editors and IDEs to provide inline completion, chat, and limited agentic actions scoped to the open workspace.

Exemplar tools (2026-Q2): GitHub Copilot, Cursor, Windsurf (formerly Codeium), Sourcegraph Cody, Tabnine, Continue.dev (open source).

Selection criteria — what to evaluate:

Editor coverage. Does it support the editors your developers actually use, including JetBrains, Neovim, and Visual Studio if relevant?
Model choice. Single-vendor model only, or a choice of model backends (including bring-your-own)?
Data residency. Where do prompts and code snippets travel? Customer-managed regions, sub-processors, retention windows.
Repo grounding. Can it index a private repo, and if so, where does the index live and how is it secured?
Telemetry surface. What does the vendor collect by default — prompts, completions, edits, accepted/rejected events? Can it be disabled at the tenant level?
License of generated code. What does the vendor's contract say about ownership and indemnification for generated output?
Open-source provenance filtering. Does the tool offer a "do not emit verbatim training data" filter, and does it work?
Enterprise controls. SSO, SCIM, audit log export, policy enforcement (e.g. blocking specific repositories or file globs).

Sizing guidance:

Sizing guide

Small (< 50): Pick one IDE assistant for the team. Do not over-engineer the choice; it is reversible.
Mid (50–500): Standardize on one for the majority, allow a sanctioned alternate for power users.
Enterprise (500+): Procurement and security treat IDE assistants as a class. Approve at most two; route via SSO and a common AI gateway.
Regulated: Data residency, sub-processor list, and contractual indemnification are gating criteria, not nice-to-haves.

Code agents (more autonomous)¶

Tools that take multi-step actions: read the repository, edit files, run commands, open pull requests. The line between "agentic IDE assistant" and "code agent" is blurry; what matters operationally is how much the tool does between human approvals.

Exemplar tools (2026-Q2): Claude Code, OpenAI Codex CLI / Codex IDE, Aider, Devin, Replit Agent, AWS Q Developer.

Selection criteria — what to evaluate:

Action surface. What can the agent do without human approval? File edits, shell commands, network calls, package installs, git operations, repository writes?
Approval model. Per-step, per-task, per-session, or all-or- nothing? Configurable?
Reversibility. Can the agent be sandboxed in an environment that is reset between sessions? Does it commit to branches by default?
Audit trail. Does the agent log every action with enough detail to reconstruct what happened? Where do those logs go?
Tool calling and MCP. Does the agent expose its tool surface in a documented way? Does it support MCP or a comparable protocol?
Rate of fabrication. How does it behave when asked to do something it cannot — does it stop and ask, or invent?
Concurrency safety. What happens when the agent operates on a repo while a human is also pushing?

Agents inherit privilege

A code agent runs with the credentials of whoever launched it. If a developer runs an agent locally with their full git, cloud, and package-manager credentials, every one of those is in scope of any prompt-injected instruction the agent reads. See S.H.I.E.L.D..

Sizing guidance:

Sizing guide

Small (< 50): Permit on local branches with human review of every commit. Defer agent-driven CI/CD changes.
Mid (50–500): Sanction one agent. Restrict its network and filesystem reach in policy. Require branch-only writes.
Enterprise (500+): Treat agents as privileged automation. Network-segregated runners, scoped service accounts, mandatory audit-log export.
Regulated: Default-deny; allow only in scoped sandboxes for low-risk workflows. Re-evaluate as the threat surface stabilises.

Coding-focused chat / browser¶

Conversational AI tools used for coding help outside the IDE — design discussions, debugging by paste, documentation drafting, learning.

Exemplar tools (2026-Q2): Anthropic Claude (web/app), ChatGPT, Gemini Code Assist, Perplexity Labs.

Selection criteria — what to evaluate:

Tenant model. Personal accounts vs. company-tenant accounts. Only the latter is acceptable for company work; see acceptable use policy.
Training opt-out. Is content excluded from model training by default for enterprise tenants? In writing?
Data residency. Region selection, sub-processor list.
Conversation retention. Default retention, ability to disable, ability to export.
Plugins / connectors. What can the chat tool reach into — Drive, email, calendar, code repos? Each connector is a separate data-handling decision.
Grounding sources. Does the tool ground responses in a known corpus (web search, internal docs)? How does it cite?

Sizing guidance:

Sizing guide

Small (< 50): A single team-tenant account, no personal accounts for company work.
Mid (50–500): SSO-fronted enterprise tenant, training opt-out verified in writing.
Enterprise (500+): Procurement, DPA, sub-processor review, audit-log export.
Regulated: Restrict by data class — chat tools are usually acceptable for non-confidential design discussion only.

Self-hosted / on-prem¶

Open-weight or licensed foundation models served from infrastructure the company controls — useful when data residency or air-gapped operation is a hard requirement.

Exemplar tools (2026-Q2): Ollama, LM Studio, vLLM-served open-weight models (Qwen Coder, DeepSeek Coder, Llama variants).

Selection criteria — what to evaluate:

License of model weights. Truly permissive (Apache, MIT-style), source-available with restrictions, or research-only? Read the license; the headline name is not enough.
Provenance of training data. Vendor-disclosed corpus details, known leak/contamination history, jurisdiction of training.
Hardware footprint. GPU class and memory required for the parameter sizes you plan to run. Total cost of ownership including power and rack space.
Inference stack maturity. Stability of the serving layer (vLLM, TGI, llama.cpp, etc.), upstream activity, security posture.
Quality envelope. Benchmark results are an input, not a verdict. Run your own evaluation on your code.
Update cadence. Who is maintaining the model and the serving stack? What is your migration plan when the upstream stops?

Sizing guidance:

Sizing guide

Small (< 50): Self-hosted is rarely worth the operational cost unless data residency forces it.
Mid (50–500): Worth piloting alongside a managed tool to compare quality and cost honestly.
Enterprise (500+): Often runs as a parallel offering to managed tools, governed by the same vendor-standards process.
Regulated: Frequently the only viable option for sensitive workloads. Treat the model and its hosting as one bundle for audit purposes.

Specialized — gateways, red-team, evaluation¶

Adjacent tools that do not produce code themselves but make the other categories safer to run.

Exemplar tools (2026-Q2):

AI gateways: LiteLLM, Helicone, Cloudflare AI Gateway, vendor- specific gateways from hyperscalers.
Prompt-injection / red-team tools: open-source benchmarks and commercial red-team platforms.
Evaluation harnesses: open-source eval libraries and vendor observability tooling.

Selection criteria — what to evaluate:

Coverage. Which model providers does the gateway speak to? Does it support BYOK (bring-your-own-key)?
Policy enforcement. Can it block prompts by content class (PII, secrets, credentials)? Can it enforce per-user, per-team rate limits?
Logging and audit. Where do logs land? How long are they retained? Are prompts redacted before storage?
Latency overhead. A gateway that adds multi-hundred-millisecond overhead is a usability tax that drives shadow-IT around it.
Failure mode. When the gateway is down, does the underlying tool fail closed (safer) or open (faster)?

Sizing guidance:

Sizing guide

Small (< 50): Often deferred until there are multiple tools and multiple providers in play.
Mid (50–500): Worth standing up once tool count exceeds two providers; otherwise the policy lives in the AUP and SSO.
Enterprise (500+): Effectively required for unified policy and audit.
Regulated: Often a non-negotiable component of the control set — gateways carry a meaningful share of the audit evidence.

How to use this page in a procurement decision¶

Identify which categories you actually need. Most teams need fewer than they think.
For each category, pull the selection criteria above into the vendor selection worksheet.
Score candidate tools against the criteria, not against each other. The right answer is the tool that meets your minimum bar, not the one with the highest absolute score.
Document the choice and the rejected alternatives in a Decision Record — see the Decision Record template.
Set a re-evaluation date in the DR. The market changes faster than your contract cycle.

What this page does NOT do

It does not rank tools.
It does not declare a winner.
It does not stay current — vendor offerings change every quarter and entire categories appear and merge. Treat any specific tool name as illustrative, not endorsed. Verify current offerings directly with vendors and against your own evaluation.
It is not a substitute for the security review, data-handling review, or contractual review described in vendor & tool standards.

Next¶

Vendor & tool standards — the governance process this page feeds into.
Vendor selection worksheet — the meeting that turns this framework into a decision.
Acceptable Use Policy — where the chosen tools land in policy.