Amp: Build the Agent, Keep the Scaffolding Disposable

A tool-calling experiment outgrows Cody

When Thorsten Ball returned to Sourcegraph in February 2025, he and Quinn Slack tried an experiment: give Claude 3.7 tools and broad freedom to act. Cody, their existing assistant, centered on chat and an editor sidebar. The new agent could inspect and interact with the filesystem. That raised an immediate product problem: how could they introduce this behavior to enterprise customers who had agreed to a different workflow and price?

The answer became [Amp](https://ampcode.com/), a separate product with separate expectations. In this September 2025 Latent Space conversation, Sourcegraph CEO Quinn Slack and Amp lead engineer Thorsten Ball explain the separation. Ball defines an agent as a model, a system prompt, tools and their prompts, plus permissions to interact with the development environment. He says that product could not work as a $20 subscription or simply be inserted into Cody’s long-running enterprise contracts.

The engineering separation mattered just as much. Cody followed the Sourcegraph platform’s cloud and on-premises release cycles. Amp could ship independently; Ball reports roughly 15 releases a day over the preceding six months. Slack sees the new brand as permission to change direction without carrying every earlier commitment forward. Their governing principle is preserve the ability to react to the next model, even after the current product starts working.

Slack reports growth above 50% month over month, without specifying whether that means revenue, usage, or developer count. He also describes two- or three-person teams spending at annualized rates in the hundreds of thousands of dollars—not completed-year spending or measured productivity gains. His larger ambition is asynchronous agents working concurrently around the clock, with ten to a hundred times as many agents consuming inference and producing output. That expansion remained a forecast.

Stable infrastructure, replaceable application

Amp’s iteration speed depended on an organizational arrangement. Slack says Sourcegraph’s existing business supplied revenue and customer trust for experimentation. The division of responsibilities gave a core team of roughly eight people room to focus: - Security and infrastructure teams maintained the foundation, handling security and cloud operations. - The Amp team concentrated on clients and user experience, keeping the application layer easy to tear down and rebuild.

Ball recalls that he and Slack initially pushed directly to main without formal reviews. Experienced engineers owned their changes, and whoever broke continuous integration fixed it. The team continued direct pushes and frequent shipping as it grew, using Amp throughout the day to build Amp. That internal use supplied a short feedback loop.

The underlying assumption was that product-market fit would not make the design stable. A new model could overturn it even after the product scaled. Ball describes repeated judgment calls between improvised personal-project practices and more formal engineering. Experienced owners, platform support, and immediate feedback were supporting conditions for that approach.

What the terminal supplies for free

Amp began as a VS Code extension because the marketplace handled distribution and updates, while the editor supplied cursor and selection context. Integration stayed deliberately shallow. Adding a command-line interface, or CLI, established a useful boundary between the shared agent core and client-specific code.

The clients offered different advantages: - The CLI inherited session management. Remote execution, terminal tabs, split panes, working directories, and environment variables already had established workflows. - The editor supported richer interaction. Images, diagrams, rendered content, and shortcuts such as Command+Return were easier to accommodate there. - A standalone application had to rebuild those conveniences. An internal desktop experiment helped with multiple agents but exposed the cost of recreating tabs, splits, and per-session environments.

A company-meetup poll reportedly split evenly between CLI and VS Code use; no sample size or segmented analysis was given. About three weeks before the conversation, the team had leaned toward removing the extension. Possible web and phone interactions for asynchronous agents, together with an undisclosed planned capability, reversed that decision.

Keeping both clients imposed a continuing cost: even with shared code, updating one client is faster than updating two. A requested diagnostic-fix button illustrates the team’s restraint. Amp already received selections and diagnostics, so a short message could usually request the same action. Every convenience adds behavior to maintain, reducing the team’s capacity to respond to a new model.

Tune the model and harness together

The same tradeoff shaped requests for bring-your-own-key support, model selectors, subscriptions, and daily spending caps. Amp focused on customers who prioritized agent quality and accepted changes in how the product worked. According to the team, explaining how a requested feature would slow development sometimes led customers to withdraw it.

A coding agent’s performance depends on the model and its harness together. The harness is the system prompt, tools, and surrounding software through which the model acts. A model’s benchmark ranking does not necessarily predict its behavior inside a particular editor. The conversation uses Gemini 2.5 as a hypothetical example: exposing it quickly would be easy, but without adapting prompts and tools to its training, the integration could give users a misleading impression of its capabilities.

Amp kept model identities out of its interface and documented them in an owner’s manual after users asked. The proposed next abstraction was choosing a way of working rather than a model version. A less capable but much faster model might enable a useful constrained interaction beyond linear chat; the suggested tenfold speed difference was illustrative.

At the time, roughly half the internal team reportedly used an unnamed alternative to Sonnet as their primary model, coupled to a more constrained interaction mode. They described speed as making this a different way to work, rather than a reluctant downgrade. The model was unnamed, the preference could change, and no comparative measurements were offered.

When the host raised first-party releases preceding API access, an Amp participant accepted providers’ explanation that early releases helped them gather data and iterate publicly. Advance coordination would be welcome if it did not delay releases. Amp also reportedly used models from Anthropic, OpenAI, and Google, with a fast open-source subagent close to shipping. Different model families could contribute different strengths.

Scaffolding can conceal uncertainty

Amp’s Toolbox lets users expose executables as tools without defining an MCP server—the tool-server integration discussed in the episode. But extensibility does not make every addition worthwhile. The team’s preferred metaphor is disposable scaffolding: supporting software should be easy to remove when a stronger model absorbs its function. Spending three months on a separate model for applying edits could be wasted if the next primary model performs those edits itself.

There is also a reliability argument for restraint. Using Jira as a shopping list may be unconventional, but the list still works. Asking a language model for camera specifications can produce a plausible answer that is wrong. Elaborate chains of slash commands, subagents, tool calls, and further inference can similarly look deterministic while retaining uncertain behavior. Products should not imply reliability those workflows cannot deliver.

A more basic failure occurs when users delegate engineering judgment along with implementation. An Amp participant describes people leaving an agent to build a whole application, then returning to code nobody understands. The prescription is to retain knowledge of the application, architecture, deployment, and desired outcome. Generating code does not remove responsibility for understanding it.

That responsibility also shapes which features the team accepts: - Prompt rewriting cannot recover missing intent. Useful prompts contain constraints and knowledge from the user’s head; rephrasing alone cannot supply them. - Custom agent chains complicate debugging. The team declined custom subagents at that point because of extra tokens, convoluted handoffs, and doubts about model support for those workflows. - More tools can worsen the experience. MCP received credit for encouraging products to expose actions to agents, but authentication friction and overly granular tool collections could increase latency, cost, and misuse.

Even apparently obvious context integrations had to earn their place. The team built access to Google Docs, Notion, Linear, and GitHub Issues, then removed it. They could not explain why they were not using it themselves and wanted that question resolved before revisiting it.

Restart from intent, not accumulated confusion

Conversation compaction compresses a long exchange into material for a new context window. Amp had the feature, but an Amp participant was considering removing it because the apparent fresh start concealed lost information and fidelity. The analogy was a word processor that sometimes italicized text when asked to bold it: a familiar interface can imply predictability the underlying system does not deliver.

One participant used Linear issues as canonical task prompts, allowing a restart after an agent followed an unproductive path. Carrying forward the troubleshooting history might preserve the failed approaches that made restarting desirable. The proposed alternative was to add selected lessons to the original issue, improving the next attempt’s starting point.

Another participant did not trust the model to select those lessons automatically. Amp’s advice was to start many small threads and strictly control what entered context. Context selection remained a human judgment task; a compaction button did not make it disappear.

Verbose command output creates a related problem. Showing a summary or exit code for a long Bazel result can make the visible conversation diverge from what the model actually received, complicating diagnosis. The team also expected command-line tools themselves to adapt to agents, potentially making today’s workarounds obsolete. A future Bazel wrapper was a hypothetical example.

Useful tools close a feedback loop

A participant’s GPT-5 tool-building experiment made the limits of extensibility concrete. They asked the model to propose roughly ten tools that would improve its software engineering, then implement them. When repeating an earlier task, the model reported using none: it said it could complete the work without them. This single experiment illustrates the gap between a tool sounding useful and an agent actually using it.

The discussion identified firmer candidates for tooling: test execution and explicit descriptions of runtime and deployment environments. A Dockerfile, for example, can describe what the environment provides. These tools help establish whether the generated program works and where it must run.

Curated subagents have a specific role here, distinct from arbitrary user-defined chains. Amp’s subagents were described as separate context windows with curated tool sets. A proposed testing specialist would select relevant tests and invoke them correctly, avoiding noisy full-suite runs and fragile shell commands. A participant informally estimated that Amp got test invocation right about 90–95% of the time even with good agents.md guidance; wrong commands and escaping errors remained. No benchmark or sample size accompanied that estimate.

The testing proposals combined several mechanisms: - Deterministic selection for familiar structures: reproduce the editor behavior that runs only the test block containing the cursor. - Smaller or specialized models for common stacks: handle framework-specific test invocation. - A stronger-model fallback for unusual setups: preserve flexibility where standard approaches do not apply. - Browser execution for application flows: let a specialist exercise a natural-language scenario against a running app, potentially in parallel.

Those proposals still required usable infrastructure. One participant was bottlenecked by Playwright execution time; another pointed to browser tests that could not reliably log into the application. A testing agent needs a working route through the system it is supposed to assess.

Make runtime evidence accessible

The codebase and its tools can adapt along with the agent. A participant described teams combining client, browser, and database logs into one unified stream, making application behavior accessible in one place. Verbose JSON Lines output could be useful even when it was inconvenient for humans to read.

Another example was recording complete HTTP interactions in a Vitest suite, including inference and classification responses. Saved responses gave a later agent actual fields and content to inspect while implementing a feature. The test artifacts preserved useful API behavior for subsequent work.

Richer runtime evidence competes with context cost. Adding many logging statements could help explain execution while also filling the source the model needed to read. Framework-integrated agents, error-page context, and copying exceptions or documentation to Markdown were discussed as ways to reduce manual transfer. Whole-page exports remained too coarse when only selected sections mattered.

These changes imply a different adoption bargain. A speaker with Sourcegraph experience argued that customers historically expected tools to fit existing code and processes. Seeing an agent succeed could persuade them to modify the codebase instead. Participants differed on how readily that happens: - Some companies generalize success into experimentation, trying agents on more tasks after one useful result. - Others treat uneven performance as a reason to stop, especially when frontend success does not extend to a Java service.

Launchable, which used machine learning to select tests affected by a pull request, supplied an earlier example of that resistance. A participant who had served on its board recalled successful proofs of concept that still left customers questioning whether the approach would work across their full suite.

A practical adoption test emerged: keep four or five tasks whose end-to-end completion would change your mind. One participant repeatedly tested a feature that switched a tool-integration playground between automatic execution and approval. The difficulty was pausing inference for approval, then resuming it. They reported that GPT-5 Codex with Codex CLI was the first combination to implement the whole feature in one attempt. This was a personal task result, without formal evaluation details, but it made the threshold for adoption concrete.

The next bottleneck is catching up

Once agents can complete individual tasks, review and coordination become more pressing. One participant described launching five or six agents, leaving for dinner, and returning unable to remember which was doing what. Another admitted forgetting to check agents entirely. Starting parallel work is easier than recovering its context.

The proposed interaction resembles simultaneous chess: visit a task, regain orientation, make a decision, and move on. Interfaces could support that cycle by showing tasks, changes, and blockers at a glance. Consistently available deploy previews would make behavior inspectable, while semantic review would foreground consequential changes instead of directing attention only by file order.

The earlier claim about skipping formal reviews has an essential qualification. An Amp participant reports that Amp wrote 80–90% of the codebase, with each developer expected to inspect the agent’s output. Human review had moved into the author’s workflow. The team questioned whether GitHub’s separate-reviewer model adequately represented that work.

Parallel agents also create coordination costs: - Overlapping edits produce merge conflicts. Agents independently change convenient locations without the cross-task awareness a developer might maintain. - Shared task state can expose collisions. A participant built a CLI-first task manager where agents recorded touched files and inspected one another’s diffs. - Watching intermediate work consumes tokens. Those changes may never become final, making continual cross-agent inspection wasteful.

Whether version control itself needs to change remained open. A more immediate argument concerned TypeScript: its type checker supplies feedback a model can use to improve its output. As with tests and deploy previews, useful feedback helps turn generated code into something assessable.

Power users need clear intent and quality control

Generated applications could also change what software people choose to build. Company-specific expense workflows illustrate the possibility: generate an interface around a team’s categorization needs and existing data stores. A participant reported enterprises already letting employees create simple internal tools, sometimes for a single user. Another suggested that cheaper, faster, more personalized software could change which imperfections users tolerate, such as an awkward loading state.

Amp’s proposed audience boundary is the ability to specify an outcome and learn the tool, rather than prior coding experience alone. An Amp participant cited a board member with little coding experience who reportedly built an internal fund-tracking application that replaced expensive existing software. The anecdote offered no implementation or validation details, but explained the team’s interest in motivated newcomers as well as experienced programmers.

That broader audience still needs strong feedback. The desired builder understands a problem closely, can start an agent during a customer conversation, and cares enough to make the result work. An Amp participant rejects the version of “vibe coding” characterized by weak feedback loops and poor quality control. The ambition is a shorter path from the customer’s problem to working software.

Product judgment when implementation gets cheaper

The closing leadership discussion applies that idea inside the company. Ball is credited with grounded judgment, engineering skill, communication, and selectively retaining useful enterprise practices. Giving him broad authority was described as both a way to accelerate Amp and a signal that others could attempt ambitious experiments. Engineers, designers, and product managers increasingly needed to understand one another’s disciplines as implementation became easier.

Amp had no established coding-agent evaluation suite at the time. The explanation was opportunity cost: covering many codebases, prompts, and task types would take time the team chose to spend elsewhere. The speaker supported evaluations and had used model fine-tuning and language models as judges. This was a decision about Amp’s development process, not a rejection of evaluation.

All-day internal use supplied rapid qualitative feedback. A hypothetical example made the mechanism clear: change a system prompt, cause excessive tool calls, and teammates might notice that evening. Frequent shipping shortened the path from a change to an observed problem, while broad evaluation coverage remained deferred.

As code becomes easier to produce, deciding when and why to use it becomes more important. The closing argument connects software experience and business understanding: identify what the business needs, then organize engineering toward it. The team invites engineers experimenting with agentic programming to share what works and what fails, expresses interest in hiring exceptional people committed to that shift, and asks users to try Amp and send feedback.