How the Amp team operates with 21 people and Agents replacing processes

What does the Amp team do?

21 people, one meeting a week, no quarterly goals, almost no titles, no PRs, no mandatory code review, direct pushes to main, about a hundred deploys a day, bugs fixed in minutes, relying on trust and Agents rather than process.

From the @sqs and @thorstenball podcast "The Company of the Future," they treat @AmpCode itself as part of the way of working: small and familiar, no departmental turf, everyone writes their weekly goals after Monday alignment, syncing via the WIP / shipped / orb good / orb bad channels and feature flags; quality comes from "first having the Agent provide end-to-end evidence" and everyone using the product, not from mandatory PRs. The precondition is stressed repeatedly: few people, mutually calibrated, motivated by shared success in revenue and product; this is not a template that can be replicated by taking a 250-person organization from 2019 and multiplying it by AI.

Audio: https://t.co/ZPGkDbWP0Z Video: https://t.co/TPYWgjiy5U

Amp team profile About 21 people, in this shape for roughly a year; after hiring Hamish in February they have basically stopped hiring (they want to hire an FDE in New York). No departments, no stack of executive layers, "everyone can do almost anything"; there is ownership, but no "only I can touch this patch of ground." They claim good revenue per person, and can reach a similar scale even against competitors with many times the headcount. Quinn was formerly CEO of Sourcegraph, and Thorsten went from about 19 people to about 300 as it expanded; they stress that Amp was spun out of Sourcegraph precisely to preserve this size and speed.

What a week looks like · Weekend: fix bugs, listen to feedback; Thorsten often writes a Sunday post (about twenty-some a year), pointing out the most important thing or "keep doing this"; Alex posts the weekly numbers. · Monday: the same meeting twice, at about 8:30 a.m. Europe time (including about 5 people in Australia), and again about 8–9 hours later for the San Francisco session. Apart from Quinn / Thorsten attending both, this is the only fixed weekly meeting for everyone else. About an hour: first free-form discussion of priorities (no scripted departmental reports), then at the end everyone silently writes their goals for the week in a Google Doc and reads the headline aloud; the meeting presses on press releases and which day they plan to ship. · No quarterly themes to force-fit; the motivation is to get the product out and make money, not to "align with a slogan leadership set two months ago." Division of labor falls out naturally from "what gives you energy"; someone watches model launches, someone goes deep on infrastructure, but mostly as dotted lines, not territory. Hamish doing native iOS / macOS was not one of the three roadmap items, but rather spike first and then convince the team.

Collaboration channels and "daring to cut features" Four key channels: work in progress (raise your hand about what I'm doing, ask for feedback, post press release drafts), shipped (already live), orb good / orb bad (internal positive/negative feedback; bad feedback should be stated directly, don't look for the silver lining first). Big changes often require writing the external press release before shipping—if you can't write it clearly, the problem or the plan isn't right yet. Features mostly go behind feature flags first, everyone tries them, then decide to roll out fully, change, or delete; deletions are also announced in shipped, and often celebrated. Everyone reads customer feedback; infrastructure people also read the customer channel directly to find pain points. Thorsten was once "kicked out of the bug channel" for fixing too many bugs, and Nicolay took over triage.

How they review and how they ship A mantra-like prompt: first have the Agent provide "end-to-end irrefutable evidence"—test matrix, data flow, screenshots / screen recordings; then decide whether to look at the code. Only hot paths get performance and structure scrutiny. Use Amp multi-person Threads to pull colleagues into the same thread to revise a plan.

No mandatory PRs / human code review; you can review it yourself or ask someone for help. Trunk development: push to main, CI green means automatic deploy, the website service ships almost every time it's green, averaging about 90 times a day; from entering main to being available to everyone is about 7.7 minutes (they want to compress it further). Some things like the CLI ship in two-hour batches. Risk is reduced through small commits + feature flags + logging first and then changing the implementation; Agents can read production logs (OIDC / time-limited authorization), and some read-only databases go into BigQuery. Fixing a bug: one click in Slack opens a Thread → look at the diagnostic bundle and logs → a human confirms before shipping → the Agent waits for the rollout to finish and then emails the user "fixed + credits."

How they see larger companies Once Agents widen engineers' "wingspan," turf drawn along 2019 headcount lines will collide; not every function should be multiplied by 10. For people stuck in private complaint groups: turn off the gossip and talk directly to the CEO who is willing to change; even a little process friction feels much worse. Both admit: 21 already-meshed "co-founders" is a historical accident, and the path from a cold start with two people, or from 300 people down to high agency density, is still unclear.