Amp

What it is

Amp is Sourcegraph's coding agent, available as a CLI and as an editor extension. The company's previous decade of work was code search at organisational scale, and Amp is that asset pointed at an agent: the loop's answer to "where is this defined, who calls it, and where else does this pattern appear" comes from a real index rather than from grep and hope.

That is the whole positioning, and it is a coherent one. Most agents are excellent in a repository that fits in a context window and mediocre in a monorepo with fifteen years of history. Amp is built for the second case.

How the loop works

The cycle is the usual read-edit-run-check, with search promoted from a fallback to the primary way the agent orients itself. Before editing, it locates the relevant code through the index; after editing, it can find the other places that need the same change — which is exactly the task where naive agents produce a confident half-migration. It runs commands and tests, and the CLI has a non-interactive mode for scripted use.

The models field says multiple, and the vendor picks. Amp routes work to models it has chosen rather than exposing a dial, so quality follows their routing decisions rather than yours. Whether that is a feature depends on whether you enjoy tuning; it does mean model upgrades arrive without you doing anything, and it also means you cannot pin behaviour.

Isolation and permissions

Workspace-scoped, in the same sense as the editor agents: edits are confined to the project you have open and surfaced for review, and command execution is gated by approval. There is no OS-level sandbox as a default, so the practical boundary is the account the agent runs under. Put it in a container or a worktree if the work is risky.

The question specific to Amp is indexing. Deep search means your code is read and indexed, and where that index lives — local, Sourcegraph's cloud, or your own self-hosted instance — is the question to settle before rollout, not after. Sourcegraph has long sold to enterprises with exactly this concern, so the options generally exist; the details differ by plan and deployment and are not something this page should assert. Ask, and get the answer in writing.

Who it is for

Teams working in genuinely large codebases — monorepos, long-lived services, anything where onboarding takes a month — and especially organisations already running Sourcegraph, where the index is in place and the marginal cost of adopting the agent is small. It is overkill for a small repository, where a general-purpose agent reading the whole tree will do fine for less.

Limits

• Proprietary and vendor-routed. Closed source, and you do not choose the model. Two lock-ins for the price of one.
• The advantage is scale-dependent. On a 5,000-line project, deep search buys you nothing that a plain agent does not already have.
• Usage-based pricing. Agentic work billed by consumption is hard to forecast; set budgets before you hand it to a team.
• Indexing has to be lived with. Freshness, coverage and data residency are operational concerns, not setup steps.
• Smaller ecosystem. Fewer third-party integrations, fewer people writing about failure modes, less community knowledge to borrow when something goes wrong.

Alternatives on this board

• Gemini CLI — the other approach to large codebases: a very large context window instead of an index, and Apache-2.0.
• Claude Code — stronger general loop and context management; you supply the search discipline.
• Editor agents — the same workspace boundary with language-server context, if your repository is a normal size.
• OpenCode — open source with language-server integration, when you want to keep control of the model.