Separate fun fact: Gemini CLI blocks env vars with strings like 'AUTH' in the name. They have two separate configuration options that both let you allow specific env vars. Neither work (bad vibe coding). Tried opening an issue and a PR, and two separate vibe-coding bots picked up my issue and wrote PRs, but nobody has looked at them. Bug's still there, so can't do git code signing via ssh agent socket. Only choice is to do the less-secure, not-signed git commits.

On top of that, Gemini 3 refuses to refactor open source code, even if you fork it, if Gemini thinks your changes would violate the spirit of the intent of the original developers in a safety/security context. Even if you think you're actually making it more secure, but Gemini doesn't, it won't write your code.

> it sure feels like software has become a brittle mess, with 98% uptime becoming the norm instead of the exception, including for big services

As somebody who has been running systems like these for two decades: the software has not changed. What's changed is that before, nobody trusted anything, so a human had to manually do everything. That slowed down the process, which made flaws happen less frequently. But it was all still crap. Just very slow moving crap, with more manual testing and visual validation. Still plenty of failures, but it doesn't feel like it fails a lot of they're spaced far apart on the status page. The "uptime" is time-driven, not bugs-per-lines-of-code driven.

DevOps' purpose is to teach you that you can move quickly without breaking stuff, but it requires a particular way of working, that emphasizes building trust. You can't just ship random stuff 100x faster and assume it will work. This is what the "move fast and break stuff" people learned the hard way years ago.

And breaking stuff isn't inherently bad - if you learn from your mistakes and make the system better afterward. The problem is, that's extra work that people don't want to do. If you don't have an adult in the room forcing people to improve, you get the disasters of the past month. An example: Google SREs give teams error budgets; the SREs are acting as the adult in the room, forcing the team to stop shipping and fix their quality issues.

One way to deal with this in DevOps/Lean/TPS is the Andon cord. Famously a cord introduced at Toyota that allows any assembly worker to stop the production line until a problem is identified and a fix worked on (not just the immediate defect, but the root cause). This is insane to most business people because nobody wants to stop everything to fix one problem, they want to quickly patch it up and keep working, or ignore it and fix it later. But as Ford/GM found out, that just leads to a mountain of backlogged problems that makes everything worse. Toyota discovered that if you take the long, painful time to fix it immediately, that has the opposite effect, creating more and more efficiency, better quality, fewer defects, and faster shipping. The difference is cultural.

This is real DevOps. If you want your AI work to be both high quality and fast, I recommend following its suggestions. Keep in mind, none of this is a technical issue; it's a business process isssue.

A lot of the reasons to use MCP are contained in the architecture document (https://modelcontextprotocol.io/specification/2025-11-25/arc...) and others. Among them, chief is security, but then there's standardization of AI-specific features, and all the features you need in a distributed system with asynchronous tasks and parallel operation. There is a lot of stuff that has nothing to do with calling tools.

For any sufficiently complex set of AI tasks, you will eventually need to invent MCP. The article posted here talks about those cases and reasons. However, there are cases when you should not use MCP, and the article points those out too.

MCP is a fixed specification/protocol for AI app communication (built on top of an HTTP CRUD app). This is absolutely the right way to go for anything that wants to interoperate with an AI app.

For a long time now, SWEs seem to have bamboozled into thinkg the only way you can connect different applications together are "integrations" (tightly coupling your app into the bespoke API of another app). I'm very happy somebody finally remembered what protocols are for: reusable communications abstractions that are application-agnostic.

The point of MCP is to be a common communications language, in the same way HTTP is, FTP is, SMTP, IMAP, etc. This is absolutely necessary since you can (and will) use AI for a million different things, but AI has specific kinds of things it might want to communicate with specific considerations. If you haven't yet, read the spec: https://modelcontextprotocol.io/specification/2025-11-25

It's partly fact, partly reasoning. One fact comes from STUXnet and Snowden Leaks, where they developed and deployed vulns that persisted for years without notice. The other fact is I've interviewed at the research centers and my eyes got pretty wide at the stuff they told me without an NDA, so they're definitely paying a lot to develop and acquire more vulns/new attacks. That was all 20 years ago, but the contracts are still there so there's no reason to suppose it stopped. There's also past NSA directors that've spoken at DEFCON for years about how they want more hackers, and the new cold war with China and Russia has been ongoing for nearly as long.

I'm not saying they stockpile vulns; I'm saying if somebody on the dark web said they had a vuln for sale for $50k, and it could help an agency penetrate China/Iran strategically, it would make no sense to turn it down, when they already pay many times more money to try to develop similar vulns.

They have a class of attacks which are used for targeted intrusion into foreign entities. Typically espionage or cyberwarfare, so they're not often used (they're aware they might be a one-use attack), but some persist for a long time. Foreign entities also tend not to admit to the attacks when found, so if the vendor is a US entity, often the vendor doesn't find out. We do the same; when our intelligence agencies find out about a US compromise, they often keep mum about it.

I'm not talking about XSS specifically, I mean in general. An XSS isn't usually high-value, but if it affects the right target, it can be very valuable. Imagine an XSS or CSRF vuln in a web interface for firmware for industrial controls used by an enemy state, or a corporation in that state. It might only take 2 or 3 vectors to get to that point and then you have remote control of critical infrastructure.

Oh - and the idea that a vendor will always patch a hole when they find it? Not completely true. I have seen very suspicious things going on at high value vendors (w/their products), and asked questions, and nobody did anything. In my experience, management/devs are often quite willing to ignore potential compromise just to keep focusing on the quarterly goals.