Amp: The Emperor Has No Clothes

Episode Summary

Executive Summary: Sourcegraph’s Quinn and AMP lead engineer Thorsten explain why they spun AMP out as a fast-moving coding-agent product distinct from Cody: the model frontier changes too quickly for legacy processes, contracts, and feature expectations. They prioritize a small team, rapid shipping, strong models, and early adopters, while arguing that agent workflows, developer tools, and software teams must evolve alongside AI.

Main Topics: Why AMP was separated from Cody: AMP emerged from experiments with tool-calling models and was treated as a distinct product because its permissions, user expectations, pricing, and pace of change differed from Cody’s established enterprise product. A separate brand and codebase let the team move quickly without disrupting existing customer commitments. Speed, team structure, and operating principles: The AMP team keeps its core group small, ships frequently, dogfoods the product, and avoids formal code reviews. Sourcegraph’s platform teams provide security and infrastructure support, while the product team can rebuild its application layer as models and user needs shift. Product focus: early adopters and the best agent: The speakers favor users who want to experiment with the frontier over trying to satisfy every enterprise request or mainstream user. They argue that optional features such as model choice, prompt enhancers, and extensive customization can slow development and distract from building a more capable coding agent. Interfaces, models, and the agent harness: AMP supports both a VS Code extension and a CLI, recognizing that each has different strengths and that future asynchronous agents may require web or mobile interactions. The speakers expect model identity to become less visible and stress that performance depends on tuning tools and scaffolding to each model, not merely offering model selection. Reliability, context, and practical limits: Agents still require human direction and review: delegating typing is useful, but outsourcing engineering judgment can produce poorly understood code. The team is cautious about complex sub-agents, MCP setups, and conversation compaction because they can consume tokens, behave unreliably, or discard useful context. How development workflows and teams may change: Coding agents may drive changes to test tools, logs, frameworks, codebases, and review practices so they are easier for agents to use. The speakers anticipate developers working closer to customers and envision capable nontraditional users building useful software when they can specify outcomes clearly. Async agents and the outer development loop: Running many agents concurrently could multiply output, but creates new challenges: staying oriented, reviewing changes, coordinating edits, handling merge conflicts, and understanding results. The speakers see this as an open design space requiring better summaries, previews, and ways to inspect agent work.

Key Arguments: The coding-agent market changes so quickly that a product successful today may be outdated within months; teams should optimize for adaptability rather than preserving current assumptions. Separating AMP from Cody allowed the team to avoid legacy enterprise contracts and release constraints while using Sourcegraph’s existing trust, revenue, security, and infrastructure. The team believes the best coding agent matters more than broad feature coverage. Requests for pricing controls, model choice, and customization should be weighed against whether they slow progress toward that goal. A model’s capability depends on the full system—system prompt, tools, and harness—not just the underlying model. Different models may need different interaction patterns and configurations. Agents do not remove the need for engineering knowledge. Users must understand the desired outcome, architecture, and application, and must review generated work rather than handing over all judgment. Fast feedback from dogfooding, customer conversations, and frequent releases can be more useful for AMP’s changing product than building formal evaluations that are costly to maintain across diverse tasks and codebases. Asynchronous agents may increase output substantially, but value depends on effective human orientation and review; parallel execution alone does not solve coordination or attention limits. The speakers expect agent adoption to reshape surrounding software practices, from test execution and logging to codebase design and developer tools, rather than leaving the existing environment unchanged.

Data Points: AMP usage growth: More than 50% month over month - Quinn described AMP’s growth as exceeding 50% month over month, with some weeks growing faster. Annual run rate for small teams: Hundreds of thousands of dollars for teams of 2–3 people - Quinn said some small teams using AMP were reaching annual run rates in the hundreds of thousands of dollars. AMP release frequency: About 15 releases per day - The team described shipping roughly 15 times daily, enabled by its lightweight development process. AMP core team size: About 8 people - Thorsten estimated the AMP core team was around eight people at the time of the conversation. Potential async-agent scale: 10–100 times as many agents - Quinn predicted that concurrent, always-on background agents could increase the number of agents used relative to today’s typically single interactive agent. AMP code produced with agents: 80–90% - Quinn said the AMP team uses AMP to write roughly 80–90% of its codebase, while still expecting people to review it. Internal CLI versus VS Code usage: 50–50 split - Thorsten cited an internal poll showing an even split between CLI and VS Code users. Test-command success: About 90–95% of the time - Quinn estimated that the agent gets test execution right at this rate, even with guidance, motivating better test-specific tools. Enterprise discounting in a lost head-to-head deal: 100% for two years and 85% for two years - Quinn described competitors discounting their products at these levels; AMP declined to match, questioning whether such a deal would provide useful learning. Example of replacing software spend: About $250,000 per year - Quinn said a board member with limited coding experience built an AMP tool that replaced an internal fund-tracking product costing about this amount annually.

Pivotal Quotes: "The only thing that matters is building the best coding agent. Nothing else matters because if you can build that, that's way bigger than anything else that came before." — Quinn: This captures AMP’s central product priority and why the team is willing to reject features or customer requests that could slow development. "You still have to know engineering. Have to know how to program. You still have to know your application and its architecture, how it's deployed." — Quinn: The speakers distinguish useful delegation of implementation from the risky assumption that an agent can replace the user’s technical judgment. "We have to assume that this stuff will change too, and we have to stay nimble." — Thorsten: Thorsten applies AMP’s adaptability principle not only to models but also to codebases, developer tools, and established workflows.

Implications: Coding agents are likely to reshape both software products and the workflows around them. Teams may need to trade feature breadth and legacy processes for speed, while developers retain responsibility for clear goals, sound engineering judgment, and review. The next challenge is managing and evaluating parallel agent work.