Hold the write-static-code guardrail at the 98 percent it actually buys - concede the escape case publicly and still refuse to mandate replacing third-party MCPs
Situation
At the 9/2 engineering all-hands Peter clarified the missive he had sent two weeks earlier about writing static code rather than pointing Claude at an MCP server. He gave the concrete failure it came from: someone stood up a Claude skill pointed straight at the HubSpot MCP server, and it deleted an org worth of data and 14 customers. The rule he wants: have the AI write Python or JavaScript, scope the token to exactly what that script needs, and let the skill know only that the script exists - not that the MCP server does. Jamin Collins pushed back hard and correctly - an over-helpful agent will eventually route around any tool that is not an actual guard, and once it learns it can, it will stop using the guard entirely. Peter conceded it in front of the whole org twice - he is right, he is completely right - and then held the line anyway: I do not think it is worth throwing out a pattern that works 98 percent of the time because of the 2 percent. If there is a better pattern you want to pitch, I am all for it. He named the tradeoff explicitly: the full fix is replacing each third-party MCP, which means an admin approval process per service, and I do not want to constrain our usage and our experimentation right now. Once we find that a certain set of tooling is really valuable, then it is worth investing in doing exactly that. He framed it as accepting a little bit of risk so that we can experiment as a team, and set the target as getting rid of the 100 percent failure case, not solving every edge case.
Reasoning
Peter is optimising for the shape of the loss, not its probability. The catastrophic case - an unmediated agent with write scope on a system of record - is a total loss and is already happening about twenty times a quarter by his count. The residual case is an agent occasionally escaping a soft boundary, which is recoverable. Buying the first with a cheap pattern is worth leaving the second on the table. The alternative Jamin named is correct and unaffordable right now: per-service admin approval would gate exactly the experimentation Peter has spent six months trying to get the org to do. He also deliberately conceded the technical point in public rather than defending the pattern as complete - the guardrail survives on its cost-benefit, not on being airtight, and saying so is what keeps engineers arguing with him honestly.
Additional Context
This was the second of two topics at a 45-minute engineering all-hands Peter called specifically because the written missive had generated confusion and pushback rather than compliance. He opened by saying it was not a scolding call.
Observed Evidence
Fathom transcript of the 9/2 engineering all-hands; the 8/31 #eng-management message setting the agenda.
Matching Patterns
Confidence Breakdown
Reasoning Depth Analysis
People Involved
Source
reflection
AI Confidence
94%
Related Context
fathom
No, he is right. He is completely right. ... I do not think it is worth throwing out something, a pattern that I would argue works 98 percent of the time. I do not think it is worth throwing that away because of the 2 percent. If there is a better pattern that you want to pitch, I am all for it.
fathom
I do not want to constrain our usage and our experimentation right now. Once we find that a certain set of tooling is really valuable, then I think it is worth investing in doing exactly what you just said, Jamin. But I do not want to block people out of the gate from going and poking and learning.
slack
I have gotten lots of questions about my write static code rather than just pointing claude at an MCP missive.
Outcome
No outcome recorded yet.
Decision ID: 44891fb7-2d72-4c9a-9e9a-64f382ed99e5