While I got me a 16GB Macbook Air, I appreciate that Apple continues to make 8GB devices. This indicates for me also a commitment for not bloating up the OS (like Windows did) too much and caring about memory efficiency.
I'm not surprised if this is true to a wide degree (not fully).
What the people that predicted that AI will change productivity drastically in just a year or two imho underestimate: Just because a technology is capable of this in theory (and I think it is, even today) - it doesn't mean we are willing or able to deploy it to its full potential at scale. There will be a few individuals and very few companies which will do so or come close.
For most of the companies, they're still doing a lot of processes manually that could have been automated with 80s technology. Why should a change in the technology suddenly make everyone change their mindset, culture, way of thinking? This may take 1-2 generations to more fully form. Maybe that's also better: Slower change is less destablizing for society / individuals, I think of it more like a defensive mechanism of the system to keep it stable.
This is nice, but that it goes into its vendor specific .codex/ folder is a bit of a drag.
I hope such things will be standardized across vendors. Now that they founded the Agentic AI Foundation (AAIF) and also contributed AGENTS.md, I would hope that skills become a logical extension of that.
This is interesting. Also "Discover tools on-demand". Are there any stats or estimates how many tools an LLM / agent could handle with this approach vs. loading them all into context as MCP tools?
Let me take the other position in this comment: I also see that how MCP works really helped its quick adoption. Because you could just build a local MCP server as a proxy around existing APIs and functionality, there is no need to touch anything existing. And MCP often starts as "MCP Server" that is basically a software artifact that you'd just configure and run - often locally. I don't think that just doing REST or extending existing REST APIs wouldn't have delivered this part of the MCP success story.
But now that many companies focus on MCP as a remote API, the question obviously comes up why not just use standard API protocols for that and just optimize the metadata for AI consumption.
What bothers me about MCP is that there is not even a standard way to describe an entire MCP server in a single JSON file. Like OpenAPI for REST. This makes exchanging metadata and building catalogs unnecessarily unstandardized.
The article also mentioned that OpenAPI is too verbose: I totally see that, but you could optimize this by stripping an OpenAPI file down to the basics that you need for LLM use, maybe even using the Overlay spec. Or you convert your OpenAPI files to the https://www.utcp.io format that pylotlight mentioned.
Some "curation" of what's really relevant for AI consumption may be a helpful anyway, as too many tools will also lead to problems in picking the right ones.
If you're also interested in Software Architecture (at least the high-level), then I can also recommend https://architectelevator.com/book/ by Gregor Hohpe (who also wrote another long-time classic: Enterprise Integration Patterns).
Another one I found very helpful is Designing Data-Intensive Applications by Martin Kleppmann.
The simplest solution here would be to use JSON5 (https://json5.org/) if you're after comments.
It still doesn't support / standardize dates, though.
But realistically, it's also all about the ecosystem. VSCode for example doesn't come with JSON5 support out of the box. GitHub and many other tools / renderers and supports it at least in syntax highlighting.