HN user

samdjstephens

100 karma
Posts1
Comments28
View on HN

I can see the value in a protocol here, but the issue is these efforts are only as good as the industry adoption that they gain: who is using this?

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.

Many or even most software engineers are experts in their own codebases though, which means a large proportion of engineers are getting high value out of AI.

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?

Curious about your definition of these terms.

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.

The broad consumer reach of ChatGPT creates a powerful distribution channel into the workplace

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 really like this too - having the previous plan and implementation in place to create the next plan, but then clearing context once that next plan exists feels like a great way to have exactly the right context at the right time.

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 suspect it has something to do with a) the average quality of code in open source repos and b) the way the reward signal is applied in RL post-training - does the model face consequences of a brittle implementation for a task?

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.

Politics is accruing and deploying political capital within an organisation - or less abstractly, building relationships and using them.

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.

If LLMs stopped improving today I’m sure you would be correct- as it is I think it’s very hard to predict what the future holds and where the advancements take us.

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.

It seems to me that MCP and Skills are solving 2 different problems and provide solutions that compliment each other quite nicely.

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.

Definitely take that point. But this valuation is perhaps more about how much that traction, brand and data is worth to OpenAI, who cannot buy Copilot. $3bn doesn’t seem so disproportionate in that context especially given the amount of money being attracted to the space.

Just consider what it fundamentally is: a company at the leading edge of a product category that has found absurdly strong technology/use-case fit, and is growing insanely fast.

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.

DeepSeek-R1 2 years ago

Yeah it's very interesting... It appears to lead itself astray: the way it looks at several situational characteristics, gives each a "throw-away" example, only to then mushing all those examples together to make a joke seems to be it's downfall in this particular case.

Also I can't help but think that if it had written out a few example jokes about animals rather than simply "thinking" about jokes, it might have come up with something better

It’s about demand isn’t it? TSMC have red hot demand, it’s not hard to understand their urgency in setting up new fabs, wherever they may be. Intel don’t have the same incentive - their incentive is to take the money (because, why wouldn’t you), build newer fabs and hope for some breakthrough in demand. The urgency is not there: being complete before there is demand could be detrimental

There’ll always be an advantage for those who understand the problem they’re solving for sure.

The balance of traditional software components and LLM driven components in a system is an interesting topic - I wonder how the capabilities of future generations of foundation model will change that?

If you follow the authors advice to its logical conclusion then all changes to the code base are narrowly focussed tweaks - where does the longer term thinking come into this?

If I’m implementing a new feature, should I also disregard the need for refactoring?

A more nuanced approach is needed. You need to learn when to make changes additively and when to reshape the code to fit your new use case (and how much reshaping is required).

As an aside: I think tech debt sprints (if needed regularly) are often a sign that you aren’t developing software sustainably day to day.

Interesting, I wouldn’t say that I’ve found it difficult to run in even a small team.

The problem I’ve always had with Airflow has been with non-cron-like use cases, for example data pipelines kicked off when some event occurs. Sensors were often an awkward fit and the HTTP API was quite immature back when I was using it

No, but there's such thing as a "somewhat objective album ranking".

I wouldn't disagree with that, I'm sure all of the various versions of this list by RS are "somewhat objective"

Not when it hasn't change that much for 3 decades prior...

That's an interesting point - but look at the last decade: western society has been going through some turmoil, change is happening faster in some areas

As if Marvin Gaye represents some new taste/genre? It's as old or older as a lot of the stuff it went above in ranking. > And it's not like 2020 sensibilities are somehow closer to Joni Mitchel's Blue suddenly over, say, Velvet Underground (which, iirc, got dropped in ranking).

I think Marvin Gaye is more relevant to modern tastes (and therefore universal tastes) than the Beatles, for example. But yes, that doesn't explain all, or even most, of the shift in the rankings.

Is there such a thing as an objective album ranking? Especially when you consider the shifting landscape of music over time. Actually forget the shifting landscape of music, consider the shifting landscape of people - theres been significant generational change since 2003, doesn't it make sense that albums move up and down the ranking as their relevance increases or decreases? It doesn't surprise me at all that Marvin Gaye would have gone up the ranking.

edit: I think it's also worth asking the question of what role race played in the degree to which an artist or group was heralded "at the time".

To add to that - 5.75h free time might seem like a decent amount (although you didn’t account for things like washing, cooking, shopping which eat up much of the remaining time) but much of that time is after work when I’m normally fried from ~12 hours working/commuting/doing chores, leaving me incapable of anything that’s even moderately mentally taxing