samdjstephens
Joined 10 years ago
Joined 10 years ago
MCP came from Anthropic, A2A from Google so they had big tech backing from day 1.
As a developer, I wouldn’t touch this without confidence I can get gains down the line from interoperability.
What’s not clear to me is: if writing more code per engineer is possible, does that result in fewer engineers or just more software, especially in areas that traditionally got squeezed: UX, testing, DevEx, documentation, etc. Perhaps the bar just gets raised?
Likewise - I think sometimes we ascribe a mythical aura to the concept of “intelligence” because we don’t fully understand it. We should limit that aura to the concept of sentience, because if you can’t call something that can solve complex mathematical and programming problems (amongst many other things) intelligent, the word feels a bit useless.
They mention this line in different forms a couple of times in the article. It’s clear they’re pretty rattled about Anthropic’s momentum in enterprise, I wonder how confident they really are in this rationale.
I often do follow ups, that would have been short message replies before, as plans, just so I can clear context once it’s ready. I’m hitting the context limit much less often now too.
I wonder if these RL runs can extend over multiple sequential evaluations, where poor design in an early task hampers performance later on, as measured by amount of tokens required to add new functionality without breaking existing functionality.
What you’re describing is a particular form of manipulative and divisive politics which is performed by insecure, desperate or selfish people.
Many engineers are not good at building relationships (the job of coding isn’t optimal for it after all), so painting the people who are good at is as narcissistic may be comforting but isn’t correct.
I don’t see a particularly good reason why LLMs wouldn’t be able to do most programming tasks, with the limitation being our ability to specify the problem sufficiently well.
MCP is about integration of external systems and services. Skills are about context management - providing context on demand.
As Simon mentions, one issue with MCP is token use. Skills seem like a straightforward way to manage that problem: just put the MCP tools list inside a skill where they use no tokens until required.
Looking for a moat in the technology is always a bit of a trap - it’s in the traction, the brand awareness, the user data etc.
I too have started using plan mode less, mainly for two reasons: 1. I plan my prompt more carefully and think about architecture up front 2. I found with more recent powerful models, the clarifying questions were generally not useful because it was pointing out issues it obviously knew the answer to and would have resolved in implementation anyway. So essentially they became time-wasting and anxiety inducing for no good reason
The mental shift I made was to not accept poor understanding of a code base on my part when writing the prompt - if I don’t understand it, I can’t predict what assumptions the model will make even on a basic level.
I used to tell myself that plan mode mitigated that, but I usually ended up mentally glossing over the generated plans anyway.
That just resulted in pure anxiety-driven engineering, where I’d often spend extra cycles verifying what was built and worrying about the design.
So invest the time understanding the system, at an appropriate level. That level will change over time as models get better.