Summary
Amp Code operates a 21-person software company in which AI agents are used across development, deployment, production operations, customer support, and incident response rather than only for code generation. Team members use Amp agents to investigate codebases, plan changes, implement and test features, inspect logs and production data, manage feature flags, monitor rollouts, diagnose incidents, and draft customer communications. The company combines this agent-enabled workflow with trunk-based development, small changes, automatic deployment, feature flags, production observability, and human approval for consequential actions. Amp Code reports shipping roughly 90 times per day, reaching production in about 7.7 minutes on average, and maintaining unusually high output per employee, although these results are internal claims from a small, highly experienced team and may not generalize to larger or less integrated organizations.
In Production
Four LLMOps case studies like this one, in your inbox every Tuesday and Thursday.
On this page
Overview
Amp Code describes an AI-native operating model in which a small software company uses LLM-powered agents as an integrated layer across the entire product lifecycle. The objective is not simply to replace an editor or accelerate isolated coding tasks. Agents participate in discovery, design, implementation, testing, rollout, monitoring, debugging, incident response, and customer follow-up. A 21-person team uses a shared agent product, Amp, to work across a large codebase and to access carefully scoped engineering and operational tools.
The company reports that this model enables very high shipping velocity and revenue per employee. Its stated operating metrics include approximately 90 deployments to the main application per day and an average of 7.7 minutes between a change reaching the main branch and becoming live for users. These figures are presented as company experience rather than independently validated benchmarks. They also reflect a small, experienced, tightly coordinated team with unusually broad ownership, so the approach should be treated as a case study in organizational and technical integration rather than proof that every company can obtain the same multiplier.
Problem and Operating Model
Amp Code rejects a conventional structure of specialized departments, long planning cycles, and large pull requests reviewed by multiple people before release. Each team member is expected to understand the overall business, interact directly with customers, fix bugs, and take ownership of work from conception through production. Weekly priorities are discussed in a small all-hands meeting, while individuals choose and publish ambitious goals. Ownership is fluid: particular people may have strong familiarity with infrastructure, model releases, billing, design, or model routing, but they are not exclusive gatekeepers for those areas.
This organizational design is important to the LLMOps implementation. The agents are used by people who have direct access to customer feedback, product metrics, source code, deployment systems, logs, and incident channels. The company believes this avoids the context loss that occurs when an engineer receives a filtered ticket from a product or support organization. Shared work-in-progress, shipped, positive-feedback, and negative-feedback channels provide team visibility and create a lightweight review loop around agent-assisted changes.
Agent-Assisted Development
Amp is used as an active collaborator rather than only as a code-completion tool. Team members ask the agent to inspect an unfamiliar area, explain data flow, identify relevant documentation, propose a sequence of shippable changes, and implement the change. When someone is stuck among several possible designs, they can describe the desired user-visible result and ask the agent to analyze the existing system and produce a more practical decomposition. Architectural intent is maintained in repository Markdown files, including agents.md files that capture business invariants and conventions usable by both humans and agents.
Code review is often expressed as evidence-oriented interaction with the agent. Instead of relying on a formal human approval workflow, developers ask for end-to-end proof, a test matrix, an explanation of the changed data flow, screenshots or videos of the resulting interface, and evidence that important performance properties hold. A representative request is to show that a feature works across its intended states and to identify the exact requests or production paths involved. Humans still inspect code when a change affects a hot path, data structure, security boundary, or other sensitive area, but the amount of line-by-line review is adjusted to the risk of the change.
The team also uses multiplayer agent threads. A developer can tag a colleague with domain expertise in the same thread, ask for an assessment, and have the agent incorporate the revised direction. The resulting thread preserves more context than a detached pull-request description: it can show what the agent changed, why it changed it, which user or incident motivated it, and whether the change was exploratory or corrective. This shared context supports asynchronous collaboration across time zones, although it depends on disciplined communication and on the reliability of the agent’s summaries and tool use.
Deployment, Evaluation, and Rollout
Amp Code uses trunk-based development. Small changes are pushed to the main branch, pass CI, and are automatically deployed; the main application is said to deploy whenever the branch is green, while some services use a slower release cadence. Feature flags are used to separate deployment from user exposure. The team may first add instrumentation, deploy it, observe behavior, and only then implement or enable the larger change. Experimental functionality can be exposed to the internal team, selected users, a percentage of users, or individual workspaces.
This workflow makes production observation part of evaluation. Agents can inspect logs, deployment status, feature-flag state, and selected read-only production data. Developers ask the agent to compare actual behavior with the expected data flow, identify affected users, and monitor new logs after a release. Internal channels collect both positive and negative feedback before a feature is made generally available. Features can be revised or removed without treating rollback as a failure, which reduces the pressure to defend an already-built design.
The approach also favors staged database and service changes. The agent can decompose a schema migration into compatible phases so old and new application versions can coexist during deployment. This is intended to reduce the risk of a large, synchronized release and to make cleanup of temporary compatibility code more feasible. The transcript does not provide formal error-rate, regression-rate, or user-satisfaction measurements, so the effectiveness of these controls is supported primarily by the company’s described operating experience rather than by a published evaluation study.
Tools, Permissions, and Production Access
Amp is extended with plugins that expose narrowly defined company operations to the agent. Examples include retrieving bug reports, checking user status, granting a feature flag, viewing deployment state, triggering a release action, and querying build or deployment systems. The agent can also access infrastructure information such as logs, Grafana data, and Kubernetes cluster status. These integrations turn operational procedures that previously required scripts and manual navigation into actions that can be requested in a shared engineering thread.
The access model described is deliberately more constrained than giving an agent unrestricted access from a developer laptop. Orb environments provide compartmentalization, while production logs and a limited read-only subset of production data are available for investigation. Additional access is granted temporarily through permission mechanisms described as PAM grants, and service integrations can use secrets or OIDC-based authentication. Sensitive data remains encrypted or inaccessible when it is not required for the task. The transcript presents this design as safer than local development environments where a developer session may retain broad production access, but it does not provide a formal threat model, audit results, or incident statistics.
A practical control is that agents do not automatically send customer communications or ship every proposed fix. For bug handling, an agent can examine a diagnostic bundle, correlate it with server logs, produce a fix, wait for deployment, and draft an email confirming that the fix is live. A human reviews the drafted message and initiates the final action. The system can identify other affected users and prepare similar outreach, including service credits, but the team retains a human checkpoint for the communication and release decision.
Incident Response and Customer Operations
During an incident, the team asks Amp to assess system health, inspect error rates and logs, retrieve Kubernetes or Grafana information, and help identify the scope of impact. Engineers collaborate in Slack channels and shared agent threads while the agent performs investigation and repetitive operational queries. After recovery, the agent can locate affected users and prepare individualized or group communications. This makes incident response and customer support part of the same agent-accessible workflow as development.
The main operational benefit is reduced friction. A previously unattractive task—finding every affected account, checking deployment status, composing transactional messages, and applying credits—can be performed from the same context as diagnosis and remediation. The tradeoff is that the quality of the outcome depends on plugin correctness, access boundaries, data freshness, accurate agent interpretation, and human validation. A tool that can query production or send email should have explicit authorization, logging, rate limits, reversible actions, and clear ownership, even when the team is small and highly trusted.
Results and Tradeoffs
Amp Code attributes its reported velocity to the combination of capable models, consistent use of one agent environment, shared context, direct customer exposure, small changes, feature flags, and broad individual ownership. It argues that agents increase each engineer’s effective reach across the codebase and organizational boundaries. The company also reports that the product itself helps reinforce the operating model: employees use it continuously, see one another’s work, and can repair problems without waiting for a specialized team.
There are significant limitations. The model relies on a small group with shared history, strong product judgment, high trust, and a culture that tolerates direct feedback. It may be difficult to reproduce in a 200-person organization without changing team boundaries, incentives, access controls, and accountability structures. The absence of mandatory human pull-request review can reduce coordination overhead, but it also removes a familiar safety mechanism; compensating controls must therefore include automated tests, deployment gates, observability, feature flags, rollback paths, scoped permissions, and meaningful human review for high-impact changes. Likewise, screenshots, test reports, and agent explanations are useful evidence but are not substitutes for independent validation when correctness, security, privacy, or financial impact is material.
Overall, the case demonstrates a broad LLMOps pattern: the largest gains come when the model is connected to the software system’s real feedback loops and operational tools, not when it is used only to generate code. Amp Code’s experience suggests that agent deployment requires simultaneous redesign of engineering workflow, production access, evaluation practice, incident response, and organizational structure. Its productivity claims remain company-reported and context-dependent, but the technical pattern—small continuously integrated changes, evidence-based agent interaction, staged rollout, scoped tool access, production observability, and human approval for consequential actions—is a concrete blueprint for experimenting with LLMs in production software operations.