The way I think of them is as a mulligan in a trading card game like Magic.
Sometimes you have a hand you can't keep, and it's better to draw a new hand with one fewer card. Don't want to do that too many times, or you will almost certainly have a losing hand.
- Post autonomous weapons / DOD mess, I think they made some changes to make it more suspicious of what the usage is, particularly for malware. They also knew the government would be watching like a hawk, so its hedged to be extra safe.
- Because the tasks are running longer and more autonomously, they've raised the "self-confidence" level so it just makes decisions and stands by them more firmly.
- I think they've also slightly lowered the temperature so the outputs are more deterministic, so even if something has left context, it can make the same decision again with higher likelihood that it guesses the same thing.
- Lowering the temperature also makes it easier to sneak through some cached outputs (I think this likely only happens for first answers).
- They are deeply afraid of making sycophantic AI that creeps into the area of "addiction" like what happened with GPT-4o and opening themselves up to further legal liability.
Off topic: what’s the history behind the naming of Pull Request (PR) vs. Merge Request (MR)? I understand why both can be considered “correct”, but I’m curious why, say, GitHub uses PR and Gitlab uses MR.
I'm not sure, but my understanding is that GitHub historically focused more on open source, with PRs being mainly across repos of unrelated users, such that there's more of a distance to "pull" across, while Gitlab was always mainly targeting companies, where people typically use branches in the same repo, so it's just a nearby merge.
In other words, I see a pull request in an open source project to be just "I have something nice in my fork, do you think it'll be useful upstream?", which is acceptable to reject, whereas in a team setting it's "I have a feature that I think is ready to merge - give it a look and see if I missed something before we put it in".
From a semantics perspective, MR makes more sense as it's a request to merge a branch into another. PR is weird IMO, but I think really just caught on due to GitHub's popularity.
I built an internal company MCP that uses Google Workspace auth and injects a mix of guidance (disguised as tools) on how we would like certain tasks to be accomplished via Claude as well as API-like capabilities for querying internal data and safely deploying small apps internally.
I’d really love to get away from the SSE MCP endpoints we use, as the Claude desktop app can get really finicky about disconnects. I thought about distributing some CLIs with Skills instead. But, MCP can be easily updated with new tools and instructions, and it’s easy to explain how to add to Claude for non-technical people. I can’t imagine trying to make sure everyone in my company had the latest skill and CLI on their machine.
I think many of us have been burned by the absolutely awful and unstable JIRA MCP and found that skills using `acli` actually work and view the rest of the MCP space thru that lens. Lots of early - and current! - MCP implementations were bad. So it’s an uphill battle to rebuild reputation.
The Atlassian CLI is pretty bad too! But at least the robot can consistently use it. And I can use it to help the robot figure out Atlassian’s garbage data structures. There’s not much I can do to debug their awful MCP.
CLIs are technically better for a number of reasons.
If an enterprise already has internal tooling with authn/z, there's no reason to overlay on top of that.
MCPs main value is as a structured description of an agent-usable subset of an API surface with community traction, so you can expect it to exist, be more relevant than the OpenAPI docs.
I've started thinking of these systems as legacy systems. We have them. They are important and there's a lot of data in them. But they aren't optimal any more.
How we access them and where data lives is essentially an optimization problem. And AI changes what is optimal. Having data live in some walled garden with APIs designed to keep people out (most SAAS systems) is arguably sub optimal at this point. Sorting out these plumbing issues is actually a big obstacle for people to do productive things via agentic tools with these systems.
But a good way to deal with this is to apply some system thinking and figure out if you still need these systems at all. I've started replacing a lot of these things with simple coder friendly solutions. Not because I'm going to code against these things but because AI tools are very good at doing that on my behalf. If you are going to access data, it's nicer if that data is stored locally in a way that makes it easy to access that data. MCP for some SAAS thing is nice. A locally running SQL database with the data is nicer. And a lot faster to access. Processing data close to where it is stored is optimal.
As for MCP. I think it's not that important. Most agentic coding tools switch effortlessly between protocols and languages. In the end MCP is just another RPC protocol. Not a particularly good or optimal one even. If you had an API or cli already, it's a bit redundant to add MCP. Auth is indeed a key challenge. And largely not solved yet. I don't think MCP adds a whole lot of new elements for that.
I did not get that impression at all. He mentioned quite a few conversations with partner level employees, technical fellow, principal managers.
The impression I got is he tried to fix things, but the mess is so widespread and decision makers are so comfortable in this mess that nobody wants to stick their necks out and fix things. I got strong NASA Challenger vibes when reading this story…
Sometimes you have a hand you can't keep, and it's better to draw a new hand with one fewer card. Don't want to do that too many times, or you will almost certainly have a losing hand.