The Company of the Future

Quinn Slack and Thorsten Ball describe how Amp's 21-person team coordinates work, reviews agent-generated changes, and ships small updates without mandatory peer code review. Their argument is that agents change the organization around software development, not only the act of writing code. The episode offers concrete operating practices, but its claims about productivity and the future of companies are the hosts' account, not an independent evaluation.

Source basis: This summary was checked against the video's English (en-US) YouTube captions, reported as caption rather than auto-generated. Timestamp links use the captured captions. Amp's published English transcript(opens in a new tab) is also available. No translation or original-audio check was performed.

Key Points Covered

• Align on current priorities, then write individual weekly goals: Most team members attend one fixed meeting each week; Quinn and Thorsten repeat it across time zones. Thorsten's Sunday post and shared business metrics frame the discussion. After discussing priorities, everyone writes goals silently in a shared document, then states what they intend to do and when they expect to release it. Stalled goals prompt help, reassignment, or reconsideration. The hosts reject fixed quarterly planning for their fast-changing market, but still use revenue, adoption, and usage dashboards to guide decisions. 02:48–09:58(opens in a new tab), 32:12–35:46(opens in a new tab)
• Give people responsibility across customer contact, implementation, and support: The hosts describe a stable team without departmental boundaries, where people choose work that interests them and help customers directly. Specialists still emerge: model releases need responsive owners, and some people concentrate on infrastructure or design. Those associations guide consultation rather than prohibit others from changing the code. Quinn attributes the arrangement to trust, shared incentives, and a team that has already worked together, not simply to keeping headcount low. 01:50–02:48(opens in a new tab), 09:06–13:37(opens in a new tab), 15:16–17:49(opens in a new tab)
• Make unfinished work visible before it becomes a release surprise: A work-in-progress channel carries plans, prototypes, feedback requests, and draft announcements. Thorsten asks people to write announcements early so they must explain the user problem and proposed solution before committing further effort. Feature flags expose changes to teammates, while separate positive- and negative-feedback channels collect reactions. A shipped channel records both releases and removals. These practices provide ongoing feedback without routing every decision through a formal approval chain. 19:42–28:02(opens in a new tab)
• Preserve intent so another person can repair a change: Shared agent threads retain the original request, investigation, and deployment context. Quinn says teammates can use that record to distinguish an experiment from a critical fix and decide whether to repair or revert it while its author is asleep. Thorsten describes an overnight performance patch followed by a fuller fix in a shared thread. Architectural and business invariants also live in repository Markdown and AGENTS.md files; he reviews and updates agent-written documentation so fresh sessions can recover the concepts. 30:04–32:12(opens in a new tab), 43:27–45:06(opens in a new tab)
• Review evidence of behavior, then inspect code according to risk: Thorsten asks agents for end-to-end demonstrations, screenshots or recordings, test matrices, and explanations of data flow. He distinguishes a simple CLI subcommand from code on a frequently executed path: performance-sensitive work gets measurements and closer code inspection. Teammates still consult each other in shared threads when uncertain. This is selective review supported by evidence and experience with their agent, not a claim that tests or screenshots eliminate the need for judgment. 35:46–41:52(opens in a new tab)
• Use small production steps to test assumptions before a larger rollout: Amp pushes to main without mandatory pull requests or another human's code review, and green CI triggers deployment on service-specific schedules. Quinn describes first shipping instrumentation, observing logs for an hour or a day, then using feature flags and phased changes. Database changes must accommodate old and new application versions during deployment. The hosts argue that frequent small integrations reduce the risk of large, stale branches; the episode does not establish that removing mandatory review is safe for every team. 44:19–46:49(opens in a new tab), 47:47–52:03(opens in a new tab)
• Give agents bounded production visibility rather than general access: The team describes isolated orbs with time-limited, task-limited permissions, read-only production logs, and a limited read-only database subset in BigQuery. Additional access requires permission. Quinn distinguishes server logs from private thread data, which the team cannot see unless users send diagnostics. This access lets agents check rollout behavior while keeping the described data and permission boundaries explicit. 46:49–48:35(opens in a new tab)
• Connect bug fixing to deployment and customer follow-up: Internal plugins let agents fetch bug reports, inspect user status, manage feature flags, and watch builds and deployments. A reported bug can start an investigation using diagnostics and logs, but Quinn says the fix does not ship automatically. After a human ships it, the agent can wait until the fix is live before preparing customer email and credits; humans inspect and can edit those emails. The hosts note that their integrated tooling avoids coordination costs that separate support and accounting systems could reintroduce. 51:14–56:28(opens in a new tab)
• Treat the organizational forecast as conditional: The hosts argue that wider individual capabilities can make old team boundaries restrictive, while finite markets mean not every function should grow its output tenfold. They also acknowledge that Amp operates in a particular software and AI market, and that other businesses may need different planning structures. Quinn explicitly says he does not know how to reproduce their established team's setup from a two-person startup or transition a much larger company into it. Their revenue-per-headcount comparisons are self-reported, not independently verified results. 34:54–36:33(opens in a new tab), 57:30–1:00:00(opens in a new tab), 1:05:18–1:09:05(opens in a new tab)

Full video: https://www.youtube.com/watch?v=deiLxNZH_DM(opens in a new tab)

Episode page and transcript: https://ampcode.com/podcast/season-02/episode-06(opens in a new tab)