This is super neat, and not something I'd thought of attempting yet. Thanks for sharing the results, and the thoughtful and well-caveated take on the future of frameworks.
While reading the essay, I could not stop thinking about the literal "X" company which was formerly known as Twitter :D. It's like X is no longer a variable but a constant.
> Invention, not automation, will be the greatest contribution of superintelligence. Early AI could answer questions and do routine work. Soon it will increasingly help discover new knowledge -- ranging from discovering new drugs to cure a family member's disease to finding new ways to improve your business. While the number of questions a person can ask in a day is limited, the number of valuable things superintelligence can invent to help achieve your goals is unlimited.
Sort of a half-baked tangent of a thought but is it really possible for an AI superintelligence to "invent"?
> "Claude now lists over 950 MCP servers in the connectors directory, used by millions of people every day. This year we shipped support for new protocol extensions alongside features that make MCP easier to build on and deploy"
Where are all these MCP servers? I feel like if I explore the directory, I see the same subset over and over.
Separately, would love to see more love from Anthropic for MCPB. I think this is an exciting and underutilized variation and have been enjoying building MCPB servers.
This piece is more thoughtful than the title initially led me to believe. However, I feel like it's sort of like advocating for us all being able to read/write binary (using a bit of an extreme to prove a point). While there might certainly be benefits to understanding less abstract layers, I don't think it's necessary or even necessarily helpful. That said, I don't think the answer is "turn your brain off completely" but I think that there should be tools that facilitate thoughtful ways of vibe coding with natural language, which is basically another abstraction layer from writing the code and tests yourself.
I'm making the case that we should make tools for the higher abstraction, not a lower one. You said it yourself: why should we read/write binary? We don't, we shouldn't. It might be useful in some cases, but working with assembly is much easier.
Intent is more natural to us than code, for the same reason assembly is more natural than binary.
I'd agree with you then! I don't think that case was clearly laid out (or at least I didn't understand your argument to be as such). I'd also say that humans are historically quite bad at communicating intent (even if it comes more naturally and is communicated in natural-language), so I think tools that support human <> agent interaction and iteration are important.
> "The models are finally ready. Costs of inference are getting optimized with open models, and even on-device models. And, when I first experienced OpenClaw earlier this year, I had the epiphany that it isn’t the models that matter, but the harnesses, loops, and context which will lead to so many new opportunities ahead. Just as we’re learning in enterprise, we can finally invent new products that allow users to do things more naturally, using simple language to express their needs."
Seems like a wild move from the Devin team. Very curious about the metrics going into their "estimator" and also that they compared it to human estimates as a measure of success.
This is a bit of a tangent but can you explain the Western gaming studios analogy a bit further? It's not something I'm familiar with but am curious (I get the idea and broad parallel, but actually would love to better understand the details).
I wondered about this as well, but could also imagine AI tools (perhaps at the application layer and not root-LLM layer) helping to mitigate this - that's a world I've been exploring.
Don't think we're there yet, but it feels like there's a future dream of everyone being able to build and maintain custom software with AI, and not having to make the tradeoff of creativity vs. components that's historically been true with low/no code.
That said, where we are today, completely agree with what you're saying. LLMs like to generate code, and in my experience are pretty bad at iterating on or maintaining the prolific code they've created.
reply