MCP is more like a UI that is optimized for LLMs for interacting with a tool or data source. I'd argue that an API is not a user interface and that's not really their intention.
> Regardless, again: if the AI is so smart, and it somehow needs something akin to MCP as input (which seems silly), then we can use the AI to take, as input, the human readable documentation -- which is what we claim these AIs can read and understand -- and just have it output something akin to MCP.
This example is like telling someone who just wants to check their email to build an IMAP client. It's an unnecessary and expensive distraction from whatever goal they are actually trying to accomplish.
As others have said, models are now being trained on MCP interactions. It's analogous to having shared UI/UX patterns across different webapps. The result is we humans don't have to think as hard to understand how to use a new tool because of the familiar visual and interaction patterns. As the design book title says, 'don't make me think.'
The U in UI is User, and refers to the human. If something is Interfacing with an Application, and that something is another Application instead of a human, that means the interaction is happening via an Application Interface (to make things easier, we'll call it an AI for short...just kidding).
That seems to be what happens here with MCP: it is a way for an Application (the LLM) to derive programming by Interfacing with another Application (the 3rd party API provider, for example).
That would make MCP an API for accessing other APIs. Not that that's bad, computers are layers of abstraction all the way down. At the same time though, we already have some of those. Perhaps some sort of OpenAPI bridge would be useful in the same manner and not require rewriting API specs, but that probably exists, too.
Who am I kidding, though? The AI assistants/agents are going to be writing whatever manifests are necessary to run more AI, so it'll be a negligible increase in effort to do both.
> If something is Interfacing with an Application, and that something is another Application instead of a human, that means the interaction is happening via an Application Interface
My point is, the applications have been (until recently) predominantly written by humans. API is the interface developers use through the code they write. Just like a UI can be better or worse, so can API: it might be concise, expressive, consistent – or verbose, clunky and completely unpredictable. Just like in UI you don’t want to click through dozens of submenus, in API you don’t want to make a dozen of calls to do something simple. It’s way more similar than you think!
Now where MCP fits in here is a whole other question...
> Just like a UI can be better or worse, so can API: it might be concise, expressive, consistent – or verbose, clunky and completely unpredictable. Just like in UI you don’t want to click through dozens of submenus, in API you don’t want to make a dozen of calls to do something simple.
What you're describing are qualities of an interface, as in a User Interface or an Application Interface. You are right that UIs and APIs are similar, because they are both Interfaces. You are right that a good Interface has certain qualities, whether it's a UI or an API. For example, a GraphQL API tries to address the challenge of, "in API you don’t want to make a dozen of calls to do something simple" by consolidating multiple calls into 1.
That said, API is the interface programs use to interact with an application, UI is the interface humans use to interact with a program. Sometimes you get both: A developer interacts with an IDE or text editor (a user interface), and the IDE or text editor interacts with the underlying layer (an application interface).
What you don't see are humans typing bytes to an MCU server, or any other API. Humans are clicking or typing commands into a program via a UI, the program connects to the MCU server via an API, the MCU server connects to, say, a weather server via an API.
Evolution is the heuristic search for effective neural architectures. It is training data, but for the meta-search for effective architectures, which gets encoded in our DNA.
Then we compile and run that source code and our individual lived experience is the training data for the instantiation of that architecture, e.g. our brain.
It's two different but interrelated training/optimization processes.
That's underselling the product, a swarm of nanobots that are (literally, currently) beyond human understanding that are also the only way to construct certain materials and systems.
Inheritor of the Gray Goo apocalypse that covered the planet, this kind constructs an enormous mobile mega-fortress with a literal hive-mind, scouring the environment for raw materials and fending off hacking attempts by other nanobots. They even simulate other hive-minds to gain an advantage.
I disagree. A neural network is not learning it's source code. The source code specifies the model structure and hyperparameters. Then it compiled and instantiated into some physical medium, usually a bunch of GPUs, and weights are learned.
Our DNA specifies the model structure and hyperparameters for our brains. Then it is compiled and instantiated into a physical medium, our bodies, and our connectome is trained.
If you want to make a comparison about the quantity of information contained in different components of an artificial and a biological system, then it only makes sense if you compare apples to apples. DNA:Code :: Connectome:Weights
One is talking about an improvement made by making control flow changes during inference (no weights updates).
The other is talking about using reinforcement learning to do weight updates during training to promote a particular type response.
OpenAI had previously used reinforcement learning with human feedback (RLHF), which essentially relies on manual human scoring as its reward function, which is inherently slow and limited.
o1 and this paper talk about using techniques to create a useful reward function to use in RL that doesn't rely on human feedback.
> I think this submission paper is talking about reinforcement learning as part of/after the main training
Reinforcement learning to promote a particular type of self-correction response
> They might have done that for O1, but the bigger change is the "runtime train of thought" that once the model received the prompt and before giving a definitive answer,
Also reinforcement learning to promote certain reasoning trace
> o1 and this paper talk about using techniques to create a useful reward function to use in RL that doesn't rely on human feedback.
I take this to mean during weight updates, e.g. training.
> "runtime train of thought"
I take runtime here to mean inference, not during RL. What does runtime mean to you?
Previous approaches [0] successfully used inference time chain of thought to improve model responses. That has nothing to do with RL though.
The grandparent is wrong about the paper. They are doing chain of thought responses during training and doing RL on that to update the weights, not just during inference/runtime.
Almost every PM I've worked with had an engineering degree and/or previously worked as an engineer. This "Josh" sounds like a strawman or you've had bad luck with PMs in the past.
It also sounds like you have a PM on your team, but they actually have the title of SWE or Eng. Mgr. They probably spend > 50% of their time on the above listed responsibilities rather than engineering. Hopefully they don't get docked in their performance reviews for essentially performing the duties of a PM rather than those of an engineer.
I am very much for any SWE or Eng. Mgr taking responsibility and spending as much of their time as they see fit on anything they see fit to build a great product. Not only that, but I will encourage them to continue doing so and give them a great review score and potentially a salary bump!
> Performing the duties of a PM rather than those of an engineer.
The duties of an engineer are to know what to build, prioritize it against their other work, and build it, alon with the other engineer in their team. If you consider the "knowing what to build/prioritize" as PM work, so be it. I consider it engineering work.
Your sources are talking about the ratio of small molecule vs. large molecule drugs. Even if you're developing small molecule drugs you are likely targeting some aspect of protein signaling/gene expression.
People are being dismissive of your comments because to say that proteins are niche in the context of pharma is like saying advertising is niche in the context of Meta and Google.
> People are being dismissive of your comments because to say that proteins are niche in the context of pharma is like saying advertising is niche in the context of Meta and Google.
its all about how you define word "niche", for google, main revenue stream is supported by several pillars: search tech, infra tech, ads tech, ecosystem+network effect, human management. You remove one pillar, and everything is destroyed, so one can say ads is one of the niches in their food chain. I suspect with proteins it is about the same.
> in the context of pharma
there is no context of pharma. Post is about more broad bio-medical publications.
So the pathway to synthesize every protein is +/- the same: That's gene transcription[1] and translation[2]. If that's broken, you're in big trouble!
But if you mean in general if you're capable of looking at metabolic pathways where each protein catalyses a step in the pathway, that's definitely interesting. If a certain person has a flawed gene coding for protein X, that could indeed cause a problem.
To find valid answers, you might need to eg. track nodes and states in a graph, to figure all the consequences of a break. Not all types of storage systems/engines are equally good at that.
I read the post before I made any criticism of your comments. We're talking on a thread within the larger context of comments on the post. But more importantly, if you read the post, you will see there is a theme of industrial biochemistry (IE, pharma and biotech) running through it, because pharma/biotech is the primary consumer of these products, and the vast majority of the revenue stream.
that's one of the themes (and you are already working hard to stretch drugs pharma to "biochemistry"), if you can't see other themes in his examples and screenshots, I think this discussion is not interesting to me.
"php" is used by people in a clear and narrow ideological perspective, if you see someone using "php" in the context where I can predict their political bent, and position on just about every social issue facing society today
It was a pun about how this thread is being overly semantic in an unnecessary and uninteresting way...
We could also talk about how the word 'executes' implies some kind of agency which computers lack. It's like saying a rock just executes the laws of physics when it rolls down a hill...
> Regardless, again: if the AI is so smart, and it somehow needs something akin to MCP as input (which seems silly), then we can use the AI to take, as input, the human readable documentation -- which is what we claim these AIs can read and understand -- and just have it output something akin to MCP.
This example is like telling someone who just wants to check their email to build an IMAP client. It's an unnecessary and expensive distraction from whatever goal they are actually trying to accomplish.
As others have said, models are now being trained on MCP interactions. It's analogous to having shared UI/UX patterns across different webapps. The result is we humans don't have to think as hard to understand how to use a new tool because of the familiar visual and interaction patterns. As the design book title says, 'don't make me think.'