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.

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

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 another large feature branch is merged then your regular rebase turns into a horror-merge.

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.

edit: I’m genuinely intrigued

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