Summary

Amp exists because Quinn Slack and Thorsten Ball concluded that a tool-calling agent is a different product—and economic model—from Cody. Starting with Claude 3.7, they stripped away constraints, gave the model tools and permissions, and found something that could not fit a $20 subscription or Sourcegraph’s enterprise release cycle. The separate brand lets Amp disrupt its parent while resetting customer expectations: “The only thing that matters is building the best coding agent.”
The operating thesis is that every apparent winner in coding tools may be obsolete within six to twelve months. Copilot yielded attention to Cursor and WinServe, then Amp and Claude Code arrived, and developers began comparing Codex against Claude Code; Quinn says no tool has stayed dominant for long. Amp therefore optimizes for reaction speed—roughly 15 releases a day—rather than defending today’s interface, feature set, or contracts.
Early commercial signals suggest a high-value power-user market even before asynchronous agents multiply consumption. Amp is growing more than 50% month over month, while some teams of only two or three people represent annualized spending in the hundreds of thousands of dollars; Amp also says it maintains positive gross margins. Thorsten expects background agents running 24/7 and concurrently to create “10 or 100 times as many” agents, potentially dominating both inference demand and software output.
Amp’s eight-person core team operates like a personal project atop Sourcegraph’s mature infrastructure. Engineers push directly to main, skip formal code review, dogfood Amp, and ship throughout the day, while existing security and cloud teams stabilize the platform underneath. Thorsten’s image is an iceberg whose visible tip can “melt and be rebuilt” while the structure below the waterline remains dependable.
The model is becoming an implementation detail, but model-specific optimization remains decisive today. Amp hides model choice in the product, tunes its system prompt and tools “with the grain of the model,” and combines models from Anthropic, OpenAI, and Google rather than treating one provider as a permanent winner. Roughly half the internal team was already using something other than Sonnet as its primary Amp model, while faster models could enable new workflows without feeling like a cheaper “mid” agent.
Amp’s contrarian product stance is that many popular agent features create complexity or false confidence rather than durable capability. Prompt enhancers cannot invent missing information, MCP servers can expose 50 low-level tools while consuming context and failing unpredictably, custom sub-agent chains are expensive and hard to debug, and compaction makes long conversations “blurry.” The governing metaphor is “wooden scaffolding” that should fall away when the next model absorbs today’s workaround.
The next bottleneck moves outside code generation into context, testing, review, and agent-native infrastructure. Thorsten still rejects “outsourcing the thinking but not the typing,” while Quinn sees targeted test sub-agents, working Playwright environments, unified machine-readable logs, deployed previews, and rapid orientation across parallel agents as open territory. Their end market is not the median developer made 30% faster, but power users close enough to a problem to create entirely new software—or replace a $250,000-a-year product themselves.

Deep dive

1. Amp was built to disrupt Cody, not preserve it

Thorsten returned to Sourcegraph in February and began experimenting with Quinn around Claude 3.7: give the model tools, broad filesystem and editor permissions, and “let it go nuts.” The repeated reaction during that first San Francisco week was simply, “Quinn, you’ve got to see this. This is crazy.”
Cody had been built around RAG, an assistant sidebar, and the Sourcegraph platform; Amp’s tool-calling agent—defined as a model, system prompt, tools, and tool prompts—required different user behavior, pricing, and release mechanics. It could not simply become another Cody mode without confusing customers bound by large, long-running contracts.
The new identity deliberately separates Amp from Sourcegraph: some users do not know Cody’s creators built it. Thorsten calls that separation “so good” because the team can change the product without dragging forward a brand, customer contracts, and assumptions from an earlier product.
Quinn’s categorical framing: “The only thing that matters is building the best coding agent. Nothing else matters.” He immediately adds that nobody has built that yet; every current leader remains on a treadmill whose next step can invalidate the previous product.

2. Volatility is Amp’s central business assumption

The observed succession—Copilot, Cody’s chat and RAG, Cursor and WinServe, then Amp, Claude Code, and Codex—suggests developer loyalty may last only six to twelve months. Thorsten’s recurring axiom is “everything is changing,” potentially with every major model release.
Cursor began the year as the perceived king and “the biggest, fastest-growing site of all time”; months later, someone could describe a newer tool as making Cursor “look like GitHub Copilot”—old, boring, and enterprise-oriented. Copilot itself had been state of the art only around two years earlier.
Amp’s response is not to forecast the final interface but to make its brand, expectations, architecture, and team capable of turning quickly. Thorsten argues that even successful scaling must preserve readiness for a new technology to “pull the rug” and shift the whole category.
Current growth is more than 50% month over month, with some two- or three-person teams annualizing at hundreds of thousands of dollars. Yet the prospective discontinuity is asynchronous agents working concurrently in the background, potentially producing 10 or 100 times as many agents and dominating inference and output.

3. A tiny product team rides on a stable enterprise base

Sourcegraph’s profitable existing product, revenue, and customer trust fund Amp’s experimentation. That trust lets Amp defer features such as predictable pricing, user-controlled model choice, and every security, compliance, or legal checkbox that could otherwise consume nine months.
The core team is roughly eight people. It still has no formal code-review process, pushes directly to main, ships about 15 times daily, and expects whoever breaks CI—or whoever is awake—to fix it.
Thorsten describes 15 daily judgment calls between “duct tape personal project mode” and “this is how they do it at Google mode.” The skill is knowing which standards carry value and which merely fossilize a product that may soon need reconstruction.
Sourcegraph’s security and infrastructure teams absorb durable concerns such as cloud operations and scaling. That leaves Amp’s application and UX layer free to behave like the tip of an iceberg: it can “melt and be rebuilt” while the platform beneath the waterline remains stable.

4. Neither the editor nor the terminal has won

Amp began as a VS Code extension because the marketplace handled distribution and rapid updates while placing the agent beside selections, diagnostics, and the editor cursor. The team intentionally avoided deep integration so that the product surface remained small and replaceable.
Claude Code overturned Thorsten’s assumption that developers would reject a CLI. A terminal supplies SSH, directories, environment variables, tabs, panes, and multiple concurrent sessions for free; a standalone desktop application must painstakingly reinvent that operating environment.
After rebuilding its CLI twice, Amp found an internal 50/50 split between CLI and VS Code usage. The editor renders diagrams, images, and rich controls more naturally, while the terminal travels across editors and remote environments; Thorsten tentatively sees younger developers leaning toward the editor.
Three weeks before the conversation, Thorsten thought Amp would painfully kill its VS Code extension. Then he reconsidered: likely web-, phone-, or WhatsApp-based asynchronous agents might need a different interface, and an undisclosed project made him think Amp should keep the VS Code UI. They are keeping both clients, though “there’s always a hand hovering over the button” to shed complexity.

5. Winning today’s UI interaction is not the objective

Alessio presses on the awkwardness of embedding Amp inside an AI-native editor such as Cursor, whose own “fix” and chat buttons compete for attention. Quinn’s answer is that winning that specific interaction today “frankly…doesn’t really matter” if developers will interact differently in six or twelve months.
Users request bring-your-own-key, model selectors, $100 subscriptions, or spending caps after $30 per day. Amp’s response is to ask whether a feature used 2% of the time is worth slowing improvement of the agent those customers actually value.
Alessio asks whether a market exists for the “mid coding agent.” Thorsten concedes that someone will pay for a cheaper product literally today, but argues that six months of churn into the next product cannot support a durable software business: “Zero of the software business models work if that happens.”
Amp’s one head-to-head loss involved competitors discounting one product 100% for two years and another 85%. Amp refused; it prefers serving the trusted 20% of developers who need maximum power while Copilot or Cursor covers the other 80%, preserving permission to remain “bold and crazy.”

6. The best harness is specific, but the model will recede

The old launch ritual—announce every new model as instantly available—has lost meaning because performance depends on the system prompt, tools, and surrounding scaffolding. Thorsten could insert Gemini 2.5 in ten minutes, but without tuning “with the grain of the model,” users would receive the wrong signal about its capability.
The host says Amp uses Sonnet 4 for the agent and o3 for Oracle. Thorsten says Amp does not expose model names in the product and documents them only because users asked; he predicts that versions will increasingly disappear behind modes of interaction.
A model less capable than Sonnet 4 might still be 10x faster. In a constrained workflow or different harness, that speed can feel like a genuinely different interaction rather than a discounted “mid model”—an abstraction closer to choosing the job than choosing the engine.
Amp already combines Anthropic, OpenAI, and Google models and was nearing a fast open-source sub-agent. Thorsten cites open-source models including Qwen3-7B-Chat and Kimiko; different model families have distinct strengths, making single-provider purity increasingly artificial.

7. Model-provider leadership remains radically unstable

Thorsten says it took eight or nine months after Claude 3.5 Sonnet’s release the previous June for users to discover what tool-calling agents could do. Once Claude Code and related tools exposed that capability, billions of dollars flowed into models and harnesses whose benefits were arriving by September 2025.
Roughly half Amp’s internal team was using a non-Sonnet model as its main workflow—previously something they did only begrudgingly for testing. Thorsten calls it “an incredibly pessimistic outcome” to assume all the people and capital entering model development could produce nothing better than Sonnet.
Delayed API access to GPT-5 Codex does not make Thorsten assume hostile foreclosure. He takes model companies at their word that first-party release gathers data faster, granting them the same latitude Amp asks from customers while iterating publicly.
His hedge is sharper on provider economics: within “one or two months,” a possible news cycle could claim foundation-model companies spent billions in CapEx and hired aggressively only to lose leadership and trigger a stampede away. He does not predict it outright; he invokes Anthropic’s pre-Sonnet reversal as evidence that it is plausible.

8. Durable products use scaffolding designed to disappear

Thorsten prefers “scaffolding” to “harness”: a wooden structure around the model that falls away when a better model remembers more, edits reliably, or absorbs a workaround. Spending three months on a separate apply model may be wasted when version “0.7 or 0.8” performs those edits directly.
That logic eliminates a conventional six-month roadmap. The design-product-engineering triangle becomes an undefined block because nobody yet knows the models’ full uses, and a feature planned today may address a capability boundary that vanishes before delivery.
The deeper complication is nondeterminism. Thorsten compares the LLM to “this orb from outer space” inside a Pentium-era computer: imagine Word occasionally italicizing text when asked to bold it. A workflow that appears to work 98% or 95% of the time may still fail in the remaining cases.

9. Popular agent features often manufacture false confidence

The clearest failure mode is vibe coding as “outsourcing the thinking but not the typing.” Engineers still need to understand the application, architecture, deployment, and desired outcome; otherwise hours of apparently productive generation culminate in spaghetti code nobody understands.
Prompt enhancers fail at the premise level: useful prompts contain information held in the user’s head, and another LLM cannot “magically conjure that up” or narrow the search space without receiving it.
User-configured MCP often adds painful authentication, perhaps 50 low-level tools, huge token overhead, latency, expense, and verbs models were not trained to select. Custom sub-agent chains compound the same problem: more context boundaries, model calls, nondeterminism, and outputs that are harder to debug.
Alessio’s GPT-5 experiment lands the critique: the model proposed ten tools that would make it a better engineer, implemented them, then used none on the repeated task because it decided it did not need them. Today’s clever tooling may solve a limitation the model itself is already learning to bypass.

10. Context quality beats rescuing an exhausted conversation

Amp includes compaction, but Thorsten’s hand is again “hovering over the rip it out button.” Compressing 50 back-and-forth messages does not restore a clean context; it removes fidelity and turns the thread “blurry,” especially when its length records repeated failures.
Thorsten proposes feeding the genuine learning from a failed conversation back into a canonical Linear issue before restarting. Quinn warns that the model may not know which detail is load-bearing, so Amp encourages many small threads and strict control of what enters each context.
Tool-output abstraction poses the same risk. Hiding verbose Bazel output behind a summary can break “what you see is what you get,” giving the model different evidence from the user; building a permanent wrapper may also age badly as CLIs adapt their output for agents.
Thorsten’s “go with the grain” principle applies to memory, too. Most people had used coding agents for fewer than three months, while model teams need time for fine-tunes and can run only so many experiments—perhaps getting half wrong—so persistent context failures may ultimately require training, not another local workflow.

11. Tests and observability are becoming agent-facing infrastructure

Tests remain one of the strongest durable tools because they close the feedback loop. Amp’s present agent follows even good agent.md testing instructions only perhaps 90–95% of the time, sometimes invoking the wrong command or escaping it incorrectly.
Quinn sees targeted testing as a natural sub-agent: use editor position and project structure to run only the relevant test instead of an entire noisy suite. Scale could support optimized deterministic-plus-model behavior for standard Go tests, Vitest, and popular frameworks, with a stronger general model covering the long tail.
Playwright is a bigger practical bottleneck. Most web developers using agents either lack it or have authentication configured so poorly that an agent cannot enter the application; a parallel sub-agent able to execute a natural-language end-to-end flow against a running application could materially improve verification.
Codebases will adapt around agents: combine browser, client, database, and application output into one JSON-lines log; record HTTP and inference interactions so tests reveal actual response shapes; integrate agents into frameworks so a failing application can provide context. Quinn’s question shifts from human readability to “How can we optimize this for agentic consumption?”

12. The outer loop will reward power users, not median adoption

Parallel agents create an orientation problem before they create effortless leverage. Quinn says he forgets agents he launched and cannot comfortably control five tasks at once; Thorsten compares the desired workflow to a person in Central Park playing against ten chess tables—sit down, understand the position, make one move, and continue.
The Amp team uses Amp to write 80–90% of its codebase. The team skips formal reviews but expects someone to inspect agent output, meaning code is reviewed by at least one person; GitHub’s reviewer model does not capture two agents producing code that a human has already examined three times.
Quinn rejects “non-technical” as the key segmentation. A board member with perhaps one computer-science class used Amp to replace software costing roughly $250,000 annually because he could specify requirements unambiguously; the target is the motivated power user, whether or not that person previously identified as a coder.
Thorsten has no fixed coding-agent eval suite despite having built and championed evals before. Breadth across codebases, prompts, and tasks makes the investment incompatible with Amp’s speed; instead, 15 daily releases and intensive dogfooding expose prompt regressions within the day. Their destination is not today’s benchmark winner but what Quinn calls “the coding agent god”; Thorsten calls building it “the final boss” of programming.

NVIDIA: OpenAI, Future of Compute, and the American Dream | BG2 w/ Bill Gurley and Brad Gerstner From Vibe Coding to Vibe Researching: OpenAI’s Mark Chen and Jakub Pachocki