keithwhor

The economics of production cost, investment and distribution have created a lopsided industry where only guaranteed hits get funded. Less soul = pandering to more people.

With new tools we can reduce the production costs of great movies considerably. More budget, if it exists, can go to marketing and distribution. I expect this will lead to more experimental films and a lot more "soul." There will be a TON of slop, too, but that's fine! It's all part of experimentation with a new medium.

My guess is that intelligence gets commodified to the point where LLMs and diffusion models are sold on chips and we seamlessly integrate them into the HW + SW stack. Then they’re just another abstraction; we talk to our computers to get things built. At essentially zero cost, truly too cheap to meter.

In parallel there’s an explosion of creative output; Marvel movies turn around in 1 year instead of 4, solely blocked on availability of actors. Some actors license their likeness to unblock their calendar from reshoots so they can earn more. We don’t replace them wholesale because people idolize celebrity.

And demand for movies? Skyrockets. With new mediums to pursue. Classics like Goodfellas resurrected in high-fidelity 3D on the Vision Pro. A combination of diffusion models and Gaussian splatting means every movie can be upscaled to immersive 3d.

Video games enter a second renaissance, with indie developers having the advantage. For large studios, nostalgia is the moneymaker. The remake of Final Fantasy VII across three games that costs $100Ms and decades? Final Fantasy VIII gets rebuilt from scratch with a team of 30. But the rest of the money and team that would’ve been on that project now expand to other, more ambitious projects.

This is just the tip of the iceberg. Mars? Why stop at Mars? Let’s start megaprojects to explore the galaxy. Mine asteroids for resources. What’s stopping us? Humans yearn for the unknown. When we exhaust resources or a modality of existence, we dream bigger, not smaller.

I personally see consumer and entertainment spending, and people employed lucratively in these sectors, growing dramatically. Maybe SaaS and a lot of businesses that have traditionally employed white collar employees fade. And a bunch of boring “financistas” don’t know how to make a buck betting in the casino anymore because boring old businesses and things nobody really wanted to do anyway aren’t lucrative anymore.

But, personally, the whole reason I got into software was to build cool stuff. Starting with video games! The type and scale of cool stuff I can build is only getting better, at an insanely fast rate. My bet is we thrive.

A friend and I are working on something like this. It’s more Slack-adjacent; the problem we’re tackling is, “what does a future where agents seamlessly integrate with day to day communication look like?” We’re a little more focused on the developer platform.

We’re embarrassingly early and haven’t “launched” yet but I guess there’s some value in sharing with an audience who might be interested!

We call it “Superuser” [0], the social hub for agent tools. There’s more of a focus on the developer platform, but warning: major WIP! We are shipping huge changes and our docs are out of date...

[0] https://superuser.app

One that goes boom.

You’ve just described what Roblox is already doing.

It’s also possible for LLMs to be inevitable, generate massive amounts of wealth and still be mostly fluff in terms of objective human progress.

The major change from my perspective is new consumer behavior: people simply enjoy talking to and building with LLMs. This fact alone is generating a lot (1) new spend and (2) content to consume.

The most disappointing outcome of the LLM era would be increasing the amount of fake, meaningless busywork humans have to do just to sift through LLM generated noise just to find signal. And indeed there are probably great products to be built that help you do just that; and there is probably a lot of great signal to be found! But the motion to progress ratio concerns me.

For example, I love Cursor. Especially for boilerplating. But SOTA models with tons of guidance can still not reliably implement features in my larger codebases within the timeframe it would take me to do it myself. Test-time compute and reasoning makes things even slower.

I think it's likely we learn to develop healthier relationships with these technologies. The timeframe? I'm not sure. May take generations. May happen quicker than we think.

It's clear to me that language models are a net accelerant. But if they make the average person more "loquacious" (first word that came to mind, but also lol) then the signal for raw intellect will change over time.

Nobody wants to be in a relationship with a language model. But language models may be able to help people who aren't otherwise equipped to handle major life changes and setbacks! So it's a tool - if you know how to use it.

Let's use a real-life example: relationship advice. Over time I would imagine that "ChatGPT-guided relationships" will fall into two categories: "copy-and-pasters", who are just adding a layer of complexity to communication that was subpar to begin with ("I just copied what ChatGPT said"), and "accelerators" who use ChatGPT to analyze their own and their partners motivations to find better solutions to common problems.

It still requires a brain and empathy to make the correct decisions about the latter. The former will always end in heartbreak. I have faith that people will figure this out.

I am building a company in this space, so can hopefully give some insight [0].

The issue right now is that both (1) function calling and (2) codegen just aren't really very good. The hype train far exceeds capabilities. Giving great demos like fetching some Stripe customers, generating an email or getting the weather work flawlessly. But anything more sophisticated goes off the rails very quickly. It's difficult to get models to reliably call functions with the right parameters, to set up multi-step workflows and more.

Add codegen into the mix and it's hairier. You need a deployment and testing apparatus to make sure the code actually works... and then what is it doing? Does it need secret keys to make web requests to other services? Should we rely on functions for those?

The price / performance curve is a consideration, too. Good models are slow and expensive. Which means their utility has to be higher in order to charge a customer to pay for the costs, but they also take a lot longer to respond to requests which reduces perception of value. Codegen is even slower in this case. So there's a lot of alpha in finding the right "mixture of models" that can plan and execute functions quickly and accurately.

For example, OpenAI's GPT-4.1-nano is the fastest function calling model on the market. But it routinely tries to execute the same function twice in parallel. So if you combine it with another fast model, like Gemini Flash, you can reduce error rates - e.g. 4.1-nano does planning, Flash executes. But this is non-obvious to anybody building these systems until they've tried and failed countless times.

I hope to see capabilities improve and costs and latency trend downwards, but what you're suggesting isn't quite feasible yet. That said I (and many others) are interested in making it happen!

[0] https://instant.bot

I think this is a cop out. OpenAI literally published a better integration spec two years ago, stored on `/.well-known/ai-plugin.json`. It just gave a summary of an OpenAPI spec, which ChatGPT could consume and then run your functions.

It was simple and elegant, the timing was just off. So the first shot at this problem actually looked quite good, and we're currently in a regression.

In the grand scheme of things I think we are still very early. MCP might be the thing which is why I'd rather try and contribute if I can; it does have a grassroots movement I haven't seen in a while. But the wonderful thing about the market is that incentives, e.g. good customer experiences that people pay for, will probably win. This means that MCP, if it remains the focal point for this sort of work, will become a lot better regardless of whether or not early pokes and prods by folks like us are successful or not. :)

Quick follow up:

I anticipate alignment issues as well. Anthropic is building MCP to make the Anthropic experience great. But Anthropic's traffic is fractional compared to ChatGPT - 20M monthly vs 400M weekly. Gemini claims 350M monthly. The incentive structure is all out of whack; how long are OpenAI and Google going to let an Anthropic team (or even a committee?) drive an integration spec?

Consumers have barely interacted with these things yet. They did once, with ChatGPT Plugins, and it failed. It doesn't entirely make sense to me that OpenAI is okay to do this again but let another company lead the charge and define the limitations of the end user experience (because that what the spec ultimately does, dictates how prompts and function responses are transported), when the issue wasn't the engineering effort (ChatGPT's integration model was objectively more elegant) but a consumer experience issue.

The optimistic take on this is the community is strong and motivated enough to solve these problems as an independent group, and the traction is certainly there. I am interested to see how it all plays out!

On MCP's Streamable HTTP launch I posted a issue asking if we should just simplify everything for remote MCP servers to just be HTTP requests.

https://github.com/modelcontextprotocol/modelcontextprotocol...

MCP as a spec is really promising; a universal way to connect LLMs to tools. But in practice you hit a lot of edge cases really quickly. To name a few; auth, streaming of tool responses, custom instructions per tool, verifying tool authenticity (is the server I'm using trustworthy?). It's still not entirely clear (*for remote servers*) to me what you can do with MCP that you can't do with just a REST API, the latter being a much more straightforward integration path.

If other vendors do adopt MCP (OpenAI and Gemini have promised to) the problem they're going to run into very quickly is that they want to do things (provide UI elements, interaction layers) that go beyond the MCP spec. And a huge amount of MCP server integrations will just be lackluster at best; perhaps I'm wrong -- but if I'm { OpenAI, Anthropic, Google } I don't want a consumer installing Bob's Homegrown Stripe Integration from a link they found on 10 Best MCP Integrations, sharing their secret key, and getting (A) a broken experience that doesn't match the brand or worse yet, (B) credentials stolen.

I've been programming since I was eight, but truly fell in love with biology in 12th grade chemistry: the first introduction to organic chemistry and biochemistry. It was the first time I truly started grokking the application of systems-level thinking to the biological world; how do trees "know" to turn red in the autumn? How do fetuses assemble themselves from two cells?

I decided to purse a double major in biochemistry and evolutionary biology and it was one of the best decisions I've made in my life. The perspective you gain from understanding all life in terms of both networks and population dynamics of atoms, molecules, cells, tissue, organisms and populations -- and how every layer reflects the layer both underneath and above it in a fractal pattern -- is mind-expanding in a way I think you just don't and can't get designing software systems alone.

I work as a software engineer / founder now, but always reflect wistfully on my time as a biologist. I hope to get back to it some day in some way, and think what the Arc Institute team is doing is inspirational [0].

[0] https://arcinstitute.org/

I mean you don’t need gRPC. You can just treat all tool calls as SSEs themselves and you have streaming. HTTP is pretty robust.

At least this uses existing standards, which was my biggest gripe with MCP. That said - protocol whiplash. And it might get worse.

If this is a bet, I'll happily take the other side and give you 4:1 on it.

I don’t disagree. I fought this battle for a long time — ran a company where I tried to simplify SDK development by making every endpoint POST and JSON params; sorta like SOAP / just simple RPC. Why do you need all the HTTP methods when most SDKs simplify everything to .retrieve etc, why not name the endpoints that?

What I realized was that these specs are valuable because they’re stable over long periods of time and handle many sorts of edge cases. Also from a systems integration perspective, everybody already knows and is trained in them. Over many years I accepted the wisdom of commons.

A lot of tooling already exists to make development of these sorts of systems easy to implement and debug. Hence why I think for Remote MCP servers, HTTP as it exists is a great choice.

That makes sense. But if that's the case I think we should call a spade a spade and differentiate "Local-first MCP" and "Remote MCP"; because what (many, most?) companies are really trying to do is integrate with the latter.

Which is where you see this sort of feedback, where a bunch of us API engineers are like; "there's already a well-trodden path for doing all of this stuff. Can we just do that and agree that it's the standard?"

Would disagree there — system integration probably accounts for like 90% of development work; just at different layers of abstraction.

It’s evergreen work that companies are endlessly trying to eliminate or automate yet keep running headfirst into.

This is very cool but definitely has the XKCD standards vibe [0]. If the industry is standardizing on MCP but then we decide it's not good enough, we just end up back where we started. I hope there's enough willpower (and low enough ego) to get to a really tight, single great implementation.

[0] https://xkcd.com/927/

The good thing to note is that (AFAIK) MCP is intended to be a collaborative and industry-wide effort. Whereas plugins was OpenAI-specific.

So, hopefully, we can contribute and help direct the development! I think this dialogue is helpful and I'm hoping the creators respond via GitHub or otherwise.

The `stdio` approach for local services makes complete sense to me. Including using JSONRPC.

But for remote HTTP MCP servers there should be a dead simple solution. A couple years ago OpenAI launched plugins as `.well-known/ai-plugin.json`, where it'd contain a link to your API spec, ChatGPT could read it, and voila. So all you needed to implement was this endpoint and ChatGPT could read your whole API. It was pretty cool.

ChatGPT Plugins failed, however. I'm confident it wasn't because of the tech stack, it was due to the fact that the integration demand wasn't really there yet: companies were in the early stages of building their own LLM stacks, ChatGPT desktop didn't exist. It also wasn't marketed as a developer-first global integration solution: little to no consistent developer advocacy was done around it. It was marketed towards consumers and it was pretty unwieldy.

IMO the single-endpoint solution and adhering to existing paradigms is the simplest and most robust solution. For MCP, I'd advocate that this is what the `mcp/` endpoint should become.

Edit: Also tool calling in models circa 2023 was not nearly as good as it is now.

Today MCP added Streamable HTTP [0] which is a huge step forward as it doesn't require an "always-on" connection to remote HTTP servers.

However, if you look at the specification it's clear bringing the LSP-style paradigm to remote HTTP servers is adding a bunch of extra complexity. This is a tool call, for example:

    {
      "jsonrpc": "2.0",
      "id": 2,
      "method": "tools/call",
      "params": {
        "name": "get_weather",
        "arguments": {
          "location": "New York"
        }
      }
    }

I've made the suggestion to remove some of this complexity [1] and fall back to just a traditional HTTP server, where a session can be negotiated with an `Authorization` header and we rely on traditional endpoints / OpenAPI + JSON Schema endpoint definitions. I think it would make server construction a lot easier and web frameworks would not have to materially be updated to adhere to the spec -- perhaps just adding a single endpoint.

[0] https://spec.modelcontextprotocol.io/specification/2025-03-2...

[1] https://github.com/modelcontextprotocol/specification/issues...

Great read. I think connecting with nature while you’re young is great — when you’re older, even better. Would love to read more of these.

DeepSeek V3 is easily the best cost / performance non-reasoning model on the market but accessing it via API is not straightforward -- at least for people who want their model hosted in the US. For the layperson OpenAI / Anthropic are much more accessible.

Some of OpenRouter's [0][1] providers seem bunk; their version is corrupted. Occasionally just get mangled outputs. Fireworks [2] is my best experience so far: their serverless API, haven't messed with custom deployments. Fast, performant, better than other models in its size category and less expensive.

[0] https://openrouter.ai/deepseek/deepseek-chat:free

[1] https://openrouter.ai/deepseek/deepseek-chat

[2] https://fireworks.ai/models/fireworks/deepseek-v3

This is incredible.

IMO, saving one life justifies every cent invested into OpenAI. How many thousands (or many, many more) will we never know about?

This is a huge differentiator from Google, where doctors sigh and act aggressively skeptical when you do your own research.

Conversely, I think you're overestimating the impact of the value (or lack thereof) of technology over distribution and market timing.

(1) That's a big if. It requires building a team specialized in delivering what Cursor has already delivered which is no small task. There are probably only a handful of engineers on the planet that have or can be incentivized to develop the product intuition the Cursor founders have developed in the market already. And even then; I'm an aspiring engineer / PM at Anthropic. Why would I choose to spend all of my creative energy copying what somebody else is doing for the same pay I'd get working on something greenfield, or more interesting to me, or more likely to get me a promotion?

(2) It's not clear to me that users (or developers) actually behave this way in practice. Engineering is a bit of a cargo cult. Cursor got popular because it was good but it also got popular because it got popular.

I think an argument could be reasonably made that the app layer is the only moat. It’s more likely Anthropic eventually has to acquire Cursor to cement a position here than they out-compete it. Where, why, what brand and what product customers swipe their credit cards for matters — a lot.

Something worth noting is that ChatGPT currently is the killer app -- DeepSeek's current chart-topping app notwithstanding (not clear if viral blip or long-term trend).