To be fair, I'd consider hard-core scalability/reliability software engineering skills to be their very own speciality domain.
But I'd also claim that these things fall on a spectrum. At the extreme end we have exchanges and HFT-like trading systems, where absolute accuracy and latency are not even constraints but industry fundamentals. At the other end we have "toy" applications that handle tens of requests per second, tops.
Scalability problems are definitely near the extreme end. Only instead of raw latency, you get to deal with complex failure modes, throughput, capacity problems, read amplification and thundering herds... all the while being constrained by available CPU cycles and bounded memory.
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.
And in a way this feels like a good thing (from a corporate strategy perspective). If MS really wants to compete with Claude Code they will need to dogfood to have even a hope of ever catching up.
As much as I may dislike MS, their software or their practices I have to admit that they have pulled this off at least once before. Back in 2019/2020 their Teams web client was absolutely atrocious and utterly unusable on Linux. Sometime in 2023/2024 it had become quite tolerable and worked mostly better than Google Meet. (Screen sharing options in Teams suck to this day, though.)
Many of Ikea's wood (wood-like?) products are pretty flimsy, designed to be built once and never moved or taken apart. (cough - all cupboards, most cabinets - cough)
But somewhat ironically their steel kitchenware is competitive with catering equipment. It may not be as well designed for maximum functionality and storage packing efficiency, but costs about the same or even less than comparable Vogue gear. Over the years I've spotted an increasing number of street food vendors using Ikea bowls and trays, so the price and availability advantage appears to be real.
Part of this is likely driven by regulations. Github has plenty of clients that fall under DORA, NIS2 or both.
I don't remember the exact wording about what qualifies as "incident" or "major incident" but the TL;DR is that the regulated entities are required to notify their regulators of impactful supplier incidents within 24h with initial information and within 72h with more complete details.
Which in turn means that Github will have signed contracts that bind them to accommodating timelines.
I used Claude about a week ago to do a pretty intensive refactoring. Cleanup, initial modularisation, beginnings of a test suite, and better isolated build. In a span of couple of hours, and over a sequence of 20+ new commits, I burned a hair over $100 in tokens.
If you are working on a seriously large legacy code base, I can see how you'd get to >$250 on a bad day.
The assassination of an investigative journalist and its subsequent handling is certainly a symptom of the island's embedded corruption. (And I say this as someone who likes the place!) When gambling and international finance make up >10% of the GDP, that's not unexpected. IIRC gambling and online gaming alone used to be >15% of Malta's economy but that balance has shifted over the past decade.
I'd think that the country's regressive anti-abortion laws are a bigger stain on its reputation. You can root out corruption. Moving the nation's Overton window towards a less illiberal stance tends to take a few generations.
Sports betting exchanges have been doing that for a very long time. There is never a good time to take the system down for maintenance - event settlements happen every few minutes, and live games with in-play betting are going on somewhere in the world at any given time.
Makes things damn hard indeed, because you have to truly learn asynchronicity, CQRS and complex live migrations. (Incidentally, engineers who have worked on such systems tend to be over-represented in extreme HA businesses.)
reply