Amp responds to "anyone can push to main": how a 21-person team uses culture to block slop

Amp responds to "anyone can push to main"

@AmpCode the team doesn't rely on mandatory PRs to block "junk" code in the AI era, but on a small team, skin in the game, public feedback, and shared taste; major architecture changes can be finalized in a single Slack thread and one customer site visit; once adapters become cheap, customers use agents to fill in the last 20% themselves; don't use headcount growth to dodge priorities, don't fetishize unit tests, use videos and screenshots as evidence; tokens aren't a cheat code, they're new infrastructure.

Polarized feedback, and "don't cater to the status quo" After the last episode on how a 21-person company works, some people actually stopped PRs, put the whole company on Amp, and went all-in on Orbs; others said their security team mandates PRs, or criticized "you shouldn't drop PRs, you should accommodate user habits." Their response was blunt: if you cater to the status quo in 2026, your product will be dead in six months, and you'll fall behind along with it, wasting customers' time. Their promise is to walk the frontier together; the road will be bumpy, but far ahead of those who stopped six months ago.

Big architecture changes don't need an RFC: Self-hosted Orbs Someone asked: if everyone just goes off and works after Monday's meeting, how do big architecture changes happen? The example is shipping self-hosted Orbs. Thorsten first drew the interface: the customer spins up a service that listens for Amp's "start Orb / pause / delete"; how to start it is left for the customer to fill in. Hitesh took over, flew with Karl, Jesse, and Alex to the customer site to prototype; the security team wouldn't allow inbound connections, so on site they revised the plan in Slack, posted whiteboard diagrams, and settled the new architecture. The news post served as the design doc, iterated repeatedly, bringing in design partners while changing things, and it shipped in a week. Quinn breaks it down: a high-trust small team, decision-making authority on site, no layers of approval; and agents turned "customers write adapters" into a viable bet—people used to fear writing code, now writing an adapter costs almost nothing.

Adapters got cheap: leave the last 20% to customers The interface was deliberately made into three requests—"spawn / pause / delete"—and customers hook it up to their own infrastructure. People used to want YAML and blessed providers; now Andrew (Amp Labs) spent half a day with docs and had an agent one-shot an adapter for their own hypervisor. Quinn says: if you still need sales, marketing, PM, and finance each owning a slice, the product and experience only get worse.

"You're only 21 people"—that's the reason, not an excuse Customers don't care how many people you have; they care whether you can fix it in 30 minutes. If more people can't outrun fewer people, change the org structure. The two compare "only 21" to the two-pizza team of yesteryear: the ideal size is itself a design goal; if a big company is both slow and can't please customers, it needs to re-explain "why be this big."

Follow the energy: a secret Android app Someone asked whether "follow the energy" is just marketing. On Friday Quinn told no one and had an agent try building an Android app; with no tablet, he first hid the URL and sent out an APK to collect feedback, then bought a Samsung tablet on Instacart to verify; if he'd first held a meeting to prove "this is the most important thing," the energy would have been drained. There's also the daily "sluggishness": renaming things, figuring out how to post the news—and the energy comes back. Adults don't shirk blame, but the goal is still to give the work that must be done as much energy as possible.

macOS Satellites and Agile with a capital A Users wanted to do iOS/macOS on Orbs. Full "Morbs" is expensive, scarce, and Docker is slow; in practice Mac time is often only 35%–40% of agent time. Jesse proposed a sidecar (later called Satellites), Hamish prototyped it in half a day, tested it behind a feature flag, then wrote a news post and iterated; Quinn/Thorsten barely looked at the code. They call themselves truly Agile with a capital A: small steps, hit reality, collect feedback; agents don't just speed up writing code, they change "how you ship, how you roll out." Same for sensitive-data scenarios: first ask "what tools and processes would let you ship 50 times a day," and the shadow copies and better rollbacks that used to be big-company-only can now be built with agents yourself.

Culture blocks junk: skin in the game The core question: with anyone able to push to main and no mandatory review, how do you avoid flooding in junk? Quinn: you don't hire superhumans who "never ship junk"; put Amp people in a different incentive and culture and they'd ship junk too. The key is not wanting to ship junk and knowing what junk is: being directly accountable to customers, having to maintain it yourself, everyone being the external face ("21 co-founders"), and under high trust being willing to say to someone's face "this is junk." Thorsten: culture is what you reward and what you fire for; real-time praise and call-outs in channels work better than passive-aggressive PR comments. If you're afraid to say another team is shipping junk, the root cause is usually management and fear, not a lack of process.

No PM in the middle: adopting a customer means really adopting them Hitesh's background is machine learning, but because he lives in customer channels, he built "personal self-hosted Orbs" over the weekend, proactively notified interested customers on Monday, with no PM in the middle, and the fruits of the labor are visible. Adopting a customer isn't enough: you have to change the product on the agent timescale, sometimes fixing things in 15–30 minutes; in their eyes you're the ambassador for the whole company.

Don't become a do-everything app; don't use hiring to dodge priorities Fixing small issues feels great, and big things (self-hosted Orbs, macOS) easily get squeezed out. At Monday meetings someone's entire task list gets cleared to do deep work. Hiring "someone dedicated to that important thing nobody does" is often a signal: you haven't actually prioritized it. The container-ship metaphor: throw the secondary cargo overboard, don't outsource the most important work to a new hire. Shared sense of urgency: you can't just polish the same car, you have to push it forward; cutting features is normal too—Quinn cut Thorsten's experimental sidebar and the other was relieved. Agents are good at zero-to-one, one-to-many, deleting things, and migrating compatibility; what they're bad at is cross-department persuasion meetings, so eliminate as many of those as possible.

"Why should we trust you": the causality is reversed Some say people selling agents naturally hype agents. Thorsten: I'm not hyping AI because I'm at Amp; I joined Amp because I believe AI is changing software development. Quinn uses the analogy "of course you'd say you love your wife, because you married her": the causality is reversed.

Proof over unit tests; see the hidden cost of review Thorsten hasn't looked at unit tests in a long time; he looks at the UI, images, and whether end-to-end works; he trusts the model and the intuition that "smells wrong." GitLab integration example: give an agent a machine to install GitLab, implement against the GitHub flow, produce videos, screenshots, and a clickable MR; matching filenames is enough, no need to nitpick unit tests. Architecture going off track, migrations botched? Rollback costs are also falling, but still watch high-risk actions like production migrations. Quinn: historically when agent migrations were bad, they added constraints like "create/alter must be checked against production query plans"; the goal is to let agents do it, not to give up on agents. Niko fixed redundant requests; Thorsten accidentally deleted a column that was still being written, causing a brief 500: human review might not have caught it, but could have delayed it five days; apply Bastiat's "seen and unseen"—bugs blocked by strict review are seen, the initiative and speed killed are unseen.

Closing: go get tokens "You're only doing this because tokens are unlimited," they say—they pay for subscriptions too, and usage is far from astronomical. More important: sorry, accept it; if you're only willing to spend $50 a month on tokens while competing with others, it was never a fair playing field. It's like complaining in 2003 that your opponent has better internet—what you should do is get online. No professor grades you on a "how many tokens did you spend" curve; only output counts. So go get tokens. Price relative to intelligence is falling; this isn't optional.