Without the singularity, I think Frontier labs will offer intelligent model blends. They'll have their own versions of "cheap" models and be expert at using the appropriate amount of compute for a task.

Frontier models need to do everything for everyone. It's expected (though not often done) that smaller models fine-tuned on specific tasks can approach frontier performance on a specific area. [0]

Post-training/fine-tuning is not trivial and having it as a service might make it more accessible.

[0] https://surgehq.ai/blog/training-on-complexconstraints

In my experience everything that affects engineers affects an agent. Good abstractions, reasonably sized methods, good names, principled (intra & inter) service architecture, unit tests, etc.

All of these things have historically been the job of engineers, because it helps other people contribute to the code.

Now it helps other people and other agents contribute to the code.

It has taken LLMs to encourage companies to prioritise a clean codebase, tickets with unambiguous context and examples of what is right and wrong when onboarding new team members.

If only we cared so much for junior developers.

Related - "The Electric Slide" [0] from NotBoring (a techno-optimist news letter) talks about production of batteries and other parts of the "Electric Stack", and explains where the US/China are relative to each other and the rest of the world, and why China has such a big lead.

[0] https://www.notboring.co/p/the-electric-slide

Basically MCP is little more than a brand name for "APIs LLM's can use". This means more services are creating APIs, because xyz company who's never been super tech forward doesn't want their tools to be obsolete when everyone uses agents.

Overall, I am in favor of this goal. I'm not sure this is the protocol I'd choose to accomplish it, but it's the one people hear about, and the one they're using.

Yeah it was quite weird seeing "Many of these companies don't even have an external API!" given MCP is literally a protocol for an external API. Not a good one in my opinion but it indeed has mindshare.

"and the one they're using." no it's not.

Agents are just making REST calls and that's it.

The best thing a company can do to make their stuff 'agent ready' is to make sure the lllm.txt docs are clear-cut and ready for the AI with clear instructions for agentic use.

'MCP' is frankly a hurdle.

Now - it probably does make sense to add MCP, because it's not expensive at all, and some will like that use case, it maybe garners a bit more attention .

MCP is a 'weak externalization' - people are using it because others are using it, and it's a 'workable' but 'not strong' solution.

It could very well entrench itself however.

It's that extra amazon box that wrap the actual box that wrap the thing you ordered. Except you're doing the wrapping.

I would say the truth[tm] is likely somewhere in the middle ground. Right now corporate MCP deployments happen to satisfy two very specific stopgap niches:

    * Internal services that never had real APIs are getting them retrofitted via the MCP layer
    * MCP servers can run with dedicated service accounts that assume-role to a safe(r) subset of the calling user's permissions

The first one is a business benefit. Enterprises tend to have a lot of data siloes, and coordination between teams/departments/units just to learn that a given data set exists takes a LOT of time - even before you start to arrange suitable access to any of them.

The second one addresses a much deeper architectural chasm. We want to have our agents carry nearly-the-same-but-not-the-most-dangerous permissions as we do. No regulated business can risk unleashing agents with zero judgement capacity to wreck their systems, and on the other hand the existing identity systems are not geared for real-time dynamically adjusted user permissions. The need for so called "agent-aware IAM" is urgent. So instead of letting users connect to the internal APIs directly with their full suite of powers, MCP servers act as stand-ins for API gateways.

MCPs are not as flexible as full-fledged CLI tools, and that's a bit of a shame. But they can also become identity-aware proxies that enforce the intended permissions for agent-safe use. It will probably take years before IAM systems can adapt to the needs of the new world, and it will take another DECADE after that for the improved IAM systems to become universally available across the larger enterprises. So in a big way I agree with you:

> MCP is a 'weak externalization' - people are using it because others are using it, and it's a 'workable' but 'not strong' solution.

"Workable" is a load-bearing term. MCP servers are by no means perfect, but they are good enough for specific needs and allow to move the balancing point as needed while the world catches up.

I'm an engineer and prefer CLI or raw API access 99% of the time. But I also have decades of scars from infosec. The single biggest security threat for a business used to be an employee who could not get their job done. They found ways to work around the roadblocks. These days the single biggest threat is an employee who can not get their job done, but has an infinitely patient agent with vast latent capabilities at their disposal.

So this is thoughtful - but - MCP isn't actually a very good solution for corporate automation either.

Corporate automations face the same problems human driven agents use:

+ The 'tool' section of the chat is not the right place, and it's too limiting + The very concept of MCP server introduces a brittle layer - for what purpose?

CLI for local calls, REST for remote.

That's it.

We build security around that the same way we would otherwise.

Now -> 'better / standard' json type calling for both of those!

Sure! 'Agent Calling API' or something. Yes.

'Agentic Identity Standard'? Yes to that as well.

But MCP was 'the right solution for a period in LLMs that has been superceded.

If MCP did not exist today - we would not invent it. That's the strongest argument I think.

That mimetic thing…

I remember 10s of HN submissions where handlers were trying to get conversations about MCP going on HN back when there was almost nothing known about it and nothing to say.

It was always about tricking people into thinking there was authentic interest in it and it still is.

Yes. But that's dangerous for end users. It enables lock in. All it does is context management, so skills are much better choice

The opinion that more companies creating APIs is good?

> If you’re going to use an LLM to write me an email, I’d much rather you just send me the prompt; at least then I’d have an idea of what you actually meant to say.”

I'm excited for when Github starts letting me check in the chain-of-thought that produced a line of code, and git blame it like I can with commits.

I think a more realistic model is not fully open source, but apps with extremely open/flexible APIs and data models that allow arbitrary front-ends (likely with a default one provided by whoever provides the API). Kind of like Stripe's model, but the audience of "developers" is bigger since anyone can be a "developer" with Claude Code

Or maybe it will be the more established open source model where the code is free but the maintainers offer hosting/some default product

I'm really interested in how LLMs will enable more customizable, personal software. Our PMs & Designers are writing a lot of code now, and our engineers are spending time figuring out how to make a system that's easy for PMs & designers to extend/add to.

It's not a big leap to apply that model to a company and its customers, where the company builds a well-abstracted, easily extensible base that 1) Customers can easily extend/customize for their workflows 2) Customers can self-host or run fully isolated, much easier (probably not quite there yet, but is a possible world)

> Our PMs & Designers are writing a lot of code now, and our engineers are spending time figuring out how to make a system that's easy for PMs & designers to extend/add to

Sounds like your developers are relegating themselves to being review monkeys instead of developers

In a post Claude Code world that's the job of engineers - the engineering is designing good abstractions, scalable systems, and things that are easy to contribute to. This is what the highest leverage senior engineers have always done, the audience has just changed

Engineering has moved up another layer of abstraction (just like we moved past managing buffers & writing machine code)

The "open source" part is the wrapper on top (up to you if you believe that's meaningful here)

Good engineering has always been about minimizing the amount of effort it takes for someone to understand and modify your code. This is the motivation for good abstractions & interfaces, consistent design principles, single-responsibility methods without side-effects, and all of the things we consider "clean code".

These are more important than ever, because we don't have the crutch of "Teammate x wrote this and they are intimately familiar with it" which previously let us paper over bad abstractions and messy code.

This is felt more viscerally today because some people (especially at smaller/newer companies) have never had to work this way, and because AI gives us more opportunity to ignore it

Like it or not, the most important part of our jobs is now reviewing code, not writing it. And "shelfed" ideas will now look like unmerged PRs instead of unwritten code