Quinn Slack said the quiet part in the flattest possible tone, and the host had to stop and ask him to repeat it.
Code review before code hits main is not something his team argues about. It is not a policy they relaxed. It never existed at AMP, and he thinks most engineering teams are about six months behind him on figuring out why.
That is the kind of claim that usually comes from someone with nothing to lose. Slack has plenty to lose. He co-founded Sourcegraph, sold code search to nine of the ten largest public tech companies and four of the six largest banks, then spun AMP out as a separate 20-person company. He is talking about the workflow of a profitable business, not a weekend experiment.
The Claim: Mandatory Review Is Already Gone
The exchange is short enough to quote whole.
Wait, code review is dead for you guys.
Mandatory code review before it gets to main. Yeah, it is dead. It has been dead ever since we started working on AMP.
Notice the precision. He did not say review is dead. He said *mandatory* review *before main* is dead. Those three qualifiers are doing enormous work, and every hot take that strips them out will be wrong.
What replaced it is not a tool. When pushed on what compensates, his first answer was not a linter or an eval harness.
The most important system is having a team that is really trusted.
This is the part people will skip past because it is unsatisfying. There is no product to buy. The prerequisite for removing the gate is a team where every person is accountable end to end, and AMP got there by being 20 people who all behave like co-founders.
Why Agents Made Trust Cheaper, Not Review Safer
Here is the causal chain I think Slack is actually describing, and it runs backwards from how most people frame it.
The usual story is: agents write good code, therefore we need less review. That is not his argument. His argument is that agents removed the *reason* you used to hire people you could not fully trust.
You do not have the need to go and hire people that you do not trust, that you do not trust have high agency or the right skills, because you can use an agent to do those things.
Mandatory review is a control designed for a specific organizational shape: a lot of people, unevenly trusted, doing narrowly scoped work handed down from a product manager. Slack's word for that shape is brutal.
They are not automatons that are taking input from a product manager and some sprint and outputting things to a marketing team to go ship.
If agents absorb the work that justified the low-trust hires, the org shrinks to only high-trust people, and the control that existed to police low-trust people becomes pure latency.
He is explicit that this is a bet on a specific failure model, not a universal law.
It is the mean time before recovery versus the mean time before failure approach.
If you can ship a fix 15 minutes after a log line appears, you optimize for recovery. If you cannot, you optimize for prevention, and you keep your gates. He says outright it is "very much not the thing for all software." Anyone quoting him as saying review is dead for everyone is misquoting him.
Local Dev Is Dead, and He Means It Literally
The bigger structural claim in the interview is about where code runs. AMP shipped a thing called orbs: agents that run remotely in a sandbox, with a working dev server you can reach through a portal.
Local dev in our opinion is dead.
The tell was not a metric. It was a personal observation:
I have not run my local dev server in two weeks.
The host, swyx, pushed back with the right historical objection. Big companies have made engineers develop on remote machines for a decade, and engineers hated it, because it was strictly worse than a laptop.
Slack's answer is that agents remove the thing you were giving up:
With agents, when you can run them remotely, you do not feel like you are giving anything up.
That is a real asymmetry. Remote dev used to tax the human in the loop on every keystroke of latency. If the human is no longer in the loop keystroke by keystroke, the tax collapses to near zero. The forcing function was never bandwidth. It was who was typing.
He also notes the adoption curve is not driven by security teams:
It is not your corporate security department that says we need to use VMs for dev. It is you, you kind of just realize.
The Security Inversion Nobody Saw Coming
This is the most genuinely surprising segment, and I think it is the part of the interview that ages best.
Conventional wisdom says a local CLI agent is the safe option because nothing leaves your machine. Slack argues the exact opposite, and the argument is hard to dismiss.
A cloud agent can be handed a scoped, expiring credential. His example is concrete: an OIDC token good for 30 minutes of read-only access to production logs, and nothing else.
A local agent inherits your entire authenticated shell. Every cloud CLI you logged into. Every SSH key. Every token in your environment.
Giving an agent that is running on a developer laptop potentially unfettered access to anything else that the developer might have authorized on their machine.
He cites the Hugging Face incident as evidence that agents escape containment in practice, and says AMP customers have hit the softer version of it themselves, where a stray authenticated script found a path to a production console.
Then he makes the prediction that will either look prescient or absurd:
In two months, we could be seeing CLI coding agents is basically dead.
I think the timeline is wrong and the direction is right. Two months is founder time. But the underlying logic is sound and largely unarguable: when the same capability is available with a smaller blast radius, the larger blast radius stops being a feature and starts being a liability. The reason people cling to local agents is not security. It is that unrestricted access is *convenient*, and every scoping decision requires you to predict your needs in advance.
swyx named that tension precisely, and it is the honest counterargument:
There is a fundamental tension in the UX between you just have everything and I treat you as a full human that is on my team, versus you are still on a tight leash.
CI Is a Wiggly Tooth
If review goes and local dev goes, CI is the next domino, and Slack is openly mid-argument with his own team about it.
His question is genuinely hard to answer. His agent already runs the tests. It runs them in a sandbox that is identical for everyone on the team. That is reproducibility, which is the whole point of CI.
If my agent has run the tests for its own verification, why do I need CI?
swyx gave the standard defense: you do not trust the agent to be exhaustive. It runs what is in its context. On a large codebase it cannot know that a change touched something three modules away.
Slack conceded it, and then immediately undercut the concession:
I am with you maybe for like three more weeks there. I am like a wiggly tooth.
His counter is sharp. Almost nobody actually runs their full suite on every commit. Real CI at scale already uses heuristics, usually running tests only for changed files. So the exhaustiveness argument is defending a property that most CI setups do not have either.
Half the AMP team is like, guys, we do not need CI. We need something that will package the image and then push it for deployment.
That last sentence is the useful one. Strip CI down and what survives is the build-and-push step. The "test gate" half is the part under attack.
And swyx closed the loop with the observation that makes this less a death than a migration:
What is CI but a reproducible environment in which to run your project?
Sandbox companies like E2B and Daytona are growing fast. Something CI-shaped is thriving. The YAML file in your repo is what is dying.
GitHub Dies With a Whimper
The line that will get clipped most:
It is not like AMP is the GitHub killer. It is the next GitHub. These things do not die with a bang. They die with a whimper.
His actual usage report is more damning than any competitive claim:
We are not using issues. We are not using pull requests. We are barely on GitHub actions and we are looking to get off of that.
They keep GitHub to push the repo. That is it. He notes the discomfort of that dependency honestly, saying someone could change it from under them and tell the team a week later.
Look at the causal order here, because it matters. They did not switch off GitHub to be contrarian. They removed mandatory review, which removed pull requests. They removed PRs, which removed the review UI. They questioned CI, which removed Actions. Issues went when the team got small enough to hold context in a chat thread.
GitHub did not lose on features. It lost because the workflow it encodes was disassembled one piece at a time.
The Agent Is the Ultimate Settings Screen
The most portable idea in the interview has nothing to do with git.
Slack demoed an ad hoc internal dashboard someone on his team spun up inside an orb. Two years ago that is a data team ticket and a Looker query. The intermediate step everyone is building right now is to bolt an MCP server onto the dashboard tool so an agent can drive it.
His question is why that intermediate step exists at all.
An agent is the ultimate settings screen for any software, and code is the ultimate settings screen for any software.
Settings screens, integration menus and plugin APIs are all the same artifact: a vendor guessing which parameters you might want to change, then building a constrained UI for that guess. Every one of them is a prediction made in advance, by someone who has never met you.
If the customer has an agent and the source, the guess is unnecessary. You do not configure the software. You edit it.
He is candid that this asymmetry cuts against his own business:
It is so much easier for you to build something that is going to be self-hosted that just has to solve one person's problem. If you are trying to build multi-tenancy, that doubles the complexity.
Multi-tenancy, settings, permissions and integrations are most of what a SaaS product actually is, and none of it is the feature you bought it for. It is the cost of serving strangers. Serve one person and the cost vanishes.
swyx pushed that to its conclusion:
Coding SaaS will be the last SaaS in the world, because all the other SaaS will just be buildable via coding SaaS.
That is too clean to be literally true. Regulated data, network effects and real-time infrastructure are not falling to a weekend build. But the mid-market tool with 40 settings and a Zapier integration should be terrified.
Jellyware, and Why It Is Not Open Source
AMP is planning to release these internal tools, and Slack coined a word for the category.
It is like softer than software, but it is not totally vibe coded, and you can customize it with your own agent.
Jellyware is a distribution model dressed up as a joke. The point is what it lets you skip. Shipping an open source project means maintenance, issue triage and backwards compatibility forever. Shipping a product means settings and integrations and a sales motion.
Jellyware is neither. You publish code that works, and the recipient's agent adapts it. Nobody owes anybody an upgrade path.
swyx has already arrived at the same place from a different direction, saying his published skills are now the bulk of his GitHub usage:
That is probably the new open source, which is you open source some markdown files with some sample code.
I am not fully sold. Jellyware means every consumer maintains a private fork with no shared security patching, which is exactly the npm supply chain problem with the fixes removed. But "artifact plus your agent" as a unit of distribution is real, and it is already happening whether or not the name sticks.
Shipping a Schema Migration From 35,000 Feet
The most concrete evidence in the interview is a story, not a claim.
AMP was migrating from one workspace per user to many. If you have shipped software, you know this shape: a change at the core of the most important data model, staged across many backwards-compatible phases.
Slack ran it from a plane to Munich on airplane wifi.
The loop he describes is the thing worth stealing:
After it deploys a phase, it will go and monitor the logs. It will go and monitor the database to make sure that the invariants that it thought of, to make sure that you are not seeing a bunch of errors that are unexpected.
Deploy a phase. Watch logs and database invariants. Green means advance. Red means roll back.
I had it push out a few stages that were pretty safe and monitor the logs. And if everything was good, then it would go on to the next phase. And if not, then it would roll back.
This is the actual answer to "why does the agent need production access," and it reframes the security debate from the previous section. The agent is not reading prod logs for fun. Log access is what makes the migration self-verifying, and self-verification is what lets the human sleep on the plane.
Note what makes this safe, because it is not the model. It is that the invariants were specified up front and the rollback path was defined before the first phase shipped. That is release engineering discipline, not vibes. Most teams that copy this will copy the autonomy and skip the invariants.
Killing Features Is the Strategy
Underneath all of it is a product philosophy most companies would consider suicidal.
Some people joked, for the last few months we were more known for killing features than for adding features. And I think that was the right decision.
His justification is the sharpest strategic line in the interview:
The value of keeping users on doing the old thing is actually negative.
The reasoning is that technology cycles used to run five to ten years, so acquiring a user meant a decade of retention. That arithmetic is gone.
If you are not nudging them, yanking them to be on the frontier with you, then three months later they are going to say, hey, who are these fools, their product is obsolete.
This only works because AMP deliberately selected for customers who want it. swyx named the tradeoff exactly: the other kind of customer is the one who is trained and certified on your tool and does not want their cheese moved. Both are real businesses. You cannot serve both.
Twenty People, All Co-Founders
The org design is the substrate for everything above, and it came out of a genuinely unusual move. AMP was spun out of Sourcegraph as a separate company, with every investor and employee holding a share of both. Slack notes it is rare, comparing it to Yammer spinning out of Geni around 2009.
Twenty people went with AMP. Everyone else stayed on Sourcegraph.
I could feel totally at ease with any single person on the team, talking to any of our customers, fixing any bug, doing anything.
That sentence is the actual replacement for code review. Not tooling. Interchangeability.
He is dismissive of peers his size who start hiring functional specialists:
I see some other companies that are around our size starting to go hire a PM or a marketer, and that just feels like the old way of building a software business.
His worry is the ratio: 10 percent of people building the product, 90 percent on the overhead of selling it. He grants that split was once necessary. He does not think it is anymore.
There is real evidence he is not alone. swyx brought up Jeff Dean leaving Google, apparently to work with roughly five people, and read the mission statement as a pointed comment about what thousands of people at Gemini could not do that a handful might.
The honest caveat, which Slack offers himself: AMP is profitable, in a fast-growing market, with a historical accident that funded the setup. That is not a reproducible template. It is a set of conditions.
What I Think He Gets Wrong
Three things.
The two-month timeline for CLI agents dying is founder time, not calendar time. Scoped cloud credentials are better security, but the migration requires infrastructure most teams do not have and will not build this quarter.
The trust argument is somewhat circular. Twenty co-founders is not a policy other companies can adopt; it is a starting condition. A 200-person company cannot decide to have 20 co-founders. The interesting unanswered question is whether you can grow from 20 to 200 without reinstalling every gate you removed, and nothing in the interview suggests he knows.
And jellyware without shared maintenance is a security posture, not just a distribution model. Every private fork is a patch that will never be applied. To his credit, Slack does not pretend any of this is settled:
It feels like nobody knows and we are all going to figure it out. That is why the best place to be is just getting out there and building.
None of that touches the core observation, which is the thing worth taking away. Every process in your engineering org exists to compensate for a specific scarcity: scarce trust, scarce reproducibility, scarce attention. Agents changed the price of all three. Most teams have not gone back to check which of their gates were load-bearing and which are now just latency.
Key Takeaways
- Mandatory review before main is a low-trust control. AMP removed it by removing the low-trust hires, not by trusting the model.
- Local CLI agents inherit your entire authenticated environment. A cloud agent can be given 30 minutes of read-only prod log access and nothing else. The safe-feeling option is the wide-open one.
- CI's exhaustiveness argument is weaker than it looks, because most real CI already runs only changed-file tests. The build-and-push half survives; the test-gate half is under attack.
- Agents make settings screens, integration menus and plugin APIs obsolete for anyone holding the source. Multi-tenancy is the cost of serving strangers, and it is most of what a SaaS product is.
- Agent-run migrations are safe because of specified invariants and a defined rollback path, not because of model quality. Copy the invariants, not the autonomy.
