AI Got Faster This Week. Every Story Still Came Down to a Person.

00:00:02 — Maya
Welcome to Development Radio. I'm Maya, here with Alex, and today is a little different. This is our first special weekly: the week in AI and cyber, for people who build and run software. Alex, did you manage to keep up with the news this week?

00:00:18 — Alex
I tried. By Tuesday I had about forty tabs open. Then I closed all of them, very decisively, and felt great for almost an hour.

00:00:27 — Maya
That's the trouble with a week like this one. Someone at work says, "Did you see the thing?" And you nod. And you hope they don't ask a follow-up question.

00:00:36 — Alex
The nod is a real professional skill. I'd say half of senior engineering is a confident nod and a whiteboard.

00:00:43 — Maya
And the other half is quietly reading the article afterwards, on your phone, in the elevator.

00:00:49 — Alex
Every single time. In my defence, my phone was busy. I spent the weekend with the espresso machine.

00:00:55 — Maya
Is it fixed?

00:00:56 — Alex
It's not broken. It's in a transitional state.

00:01:00 — Maya
That's what half the internet said this week, too. Okay, it's a good way in, actually.

00:01:04 — Alex
I knew it would come back to me somehow. So what's the plan? Because I know you have a plan. You always have a notebook.

00:01:12 — Maya
I do have a notebook. We picked five stories from the last seven days. Not everything that happened. Just the ones we think you'll hear about at work, or actually have to do something about. For each one, we'll say what happened, why it matters if you build software, and whether we think it's real or mostly hype.

00:01:30 — Alex
And we're not going to read you the news. You can get headlines anywhere. We're going to argue about them.

00:01:36 — Maya
Politely.

00:01:37 — Alex
Mostly. And we're keeping score. At the end of every story, we each give a verdict. Hype, or real.

00:01:44 — Maya
Which means, at some point today, I get to tell you you're wrong. On the record.

00:01:50 — Alex
You've been waiting for that since the first episode.

00:01:52 — Maya
Since before the first episode. Alright. Here's the question for the next half hour. Out of everything that happened this week, what actually changes how we build and run software? And since so much of it is AI, I'm going to watch for one more thing. Where the people are, in each story.

00:02:11 — Alex
Somewhere near the coffee, usually. Let's start with my favourite story of the week. It's a little absurd. And it's also kind of terrifying.

00:02:19 — Alex
You know the little padlock in your browser. When you visit your bank, your browser checks a certificate. That certificate was signed by a company called a certificate authority, and your browser trusts a short list of those companies. The whole arrangement rests on one thing. Each authority keeps a private signing key that nobody else can guess.

00:02:40 — Maya
Right. The key is the secret. If someone else has it, they can sign a certificate for any website, and your browser believes it.

00:02:48 — Alex
So. Last Saturday, the browser makers got a report about a certificate authority called eMudhra. Eight of its intermediate certificates had private keys that were tiny. Intermediate just means the certificates an authority uses day to day, so its main key can stay locked away. Mozilla's write-up says the keys, quote, "all used integers less than 256".

00:03:12 — Maya
Less than two hundred and fifty-six. Out of a key that's supposed to be how big?

00:03:18 — Alex
A number with more than a hundred digits. Something you couldn't guess with every computer on Earth. Instead, all of these keys were below two hundred and fifty-six. And one of them was the number four.

00:03:30 — Maya
Four.

00:03:31 — Alex
Four.

00:03:32 — Maya
My bike lock has a better combination than that. Okay, walk me through it. What could someone actually do with a key like that?

00:03:40 — Alex
First, guessing it is trivial. You try one, then two, then three, all the way up to two hundred and fifty-five. A laptop finishes that before your coffee does. And once you have the key, you can sign certificates. Most of these were for websites. So that's a certificate for any site you like, say a bank, that a client trusting this authority would accept. And a couple were for signing code, so you could make software look like it came from someone legitimate.

00:04:07 — Maya
So the padlock shows up, everything looks normal, and you're actually talking to someone else.

00:04:13 — Alex
For a client that trusted these certificates, yes.

00:04:16 — Maya
Okay. How does that even happen? Nobody types "four" on purpose.

00:04:21 — Alex
Here's eMudhra's own explanation. Their key ceremony, which is the very formal process where these keys get created, used a script with a flaw. That flaw generated a second, weak key pair. And staff picked the weak one by mistake, quote, "because the key labels were similar". They also wrote, "There were human errors in multiple steps of the process".

00:04:42 — Maya
That's the part I'd underline in my notebook. It's not one mistake. It's a script bug, and then a person choosing between two things with almost the same name, and then nobody catching it afterwards.

00:04:54 — Alex
And these keys were created in April of last year. So they sat there for about a year and a half.

00:05:00 — Maya
Was anyone actually attacked with them?

00:05:02 — Alex
As far as anyone can tell, no. There's a safety net here called certificate transparency. Chrome, Safari and Firefox only accept a website certificate if it's been written into public, append-only logs. And nothing issued under these intermediates ever showed up in those logs.

00:05:20 — Maya
So if someone had quietly made a fake website certificate with one of those keys, those browsers would have turned it away.

00:05:26 — Alex
Exactly. And there's no evidence of misuse. The browsers moved fast, too. Firefox and Chrome blocked these certificates the same day as the report. Apple and Microsoft followed early this week.

00:05:39 — Maya
So if everyone's browser is fine, why is this our first story? It sounds like the system worked.

00:05:45 — Alex
Because your browser isn't the only thing that trusts certificates.

00:05:49 — Maya
Oh. Right. Our services.

00:05:52 — Alex
Your services. Think about everything in your stack that makes an outbound HTTPS call. A Java service has its own trust store. A Python service usually carries a bundle of certificates called certifi. Node has a list baked in. And a Go binary uses whatever list was in the container image when it was built.

00:06:11 — Maya
And the container image was built whenever it was built. Months ago, maybe.

00:06:16 — Alex
Exactly. Go shipped a fix this week, and the Go team wrote, "We highly recommend immediately upgrading to this release". A Mozilla engineer is keeping a public tracker of which of these trust lists have been fixed. Some are still pending.

00:06:30 — Maya
So the browser world fixed this within three days. And a backend fleet fixes it whenever somebody happens to rebuild the image.

00:06:37 — Alex
That's the Staff lesson for me. Trust isn't one setting you configure once. It gets copied into every image, every runtime, every vendor appliance. And it ages there.

00:06:48 — Maya
You know what else this reminds me of? Every system I've ever seen has two things with nearly the same name. Payments, and payments two. The production key, and the new production key.

00:07:00 — Alex
And everyone knows which is which. Until the one person who knew goes on holiday.

00:07:06 — Maya
So I'd add a second, smaller check. Anywhere a human has to pick between two secrets, or two environments, make the wrong one hard to pick. Different names. A check that refuses the old one. Don't rely on someone reading a label carefully at the end of a long ceremony.

00:07:23 — Alex
And on Monday, practically: rebuild your base images and bump your runtimes, which you want to do anyway. The tracker even has test websites you can point a client at, to see whether it still trusts those certificates. And then ask one boring question. If we had to rebuild everything today, how long would it take?

00:07:41 — Maya
I like that, because it isn't really about this certificate authority. It's about whether rebuilding is a button or a project.

00:07:49 — Alex
Spoiler. For most teams, it's a project.

00:07:53 — Maya
Okay. Verdict time. Hype, or real? I'll go first. Real. Not because anyone was attacked, nobody was. But because there's a good chance some container you own still trusts those certificates, and nobody on your team knows it.

00:08:08 — Alex
I'm going to split it. Hype, for the internet. The browsers handled it beautifully. Real, for your Docker images.

00:08:16 — Maya
That's a cop-out.

00:08:17 — Alex
That's nuance. It's completely different.

00:08:20 — Maya
We'll allow it. Once. That's one story down, four to go. And the next one is the big one.

00:08:26 — Maya
Story two. Yesterday, Wednesday, PHP shipped emergency patches for two critical bugs. People are calling them PHP to Shell.

00:08:37 — Alex
And to be clear for everyone listening, this is PHP itself. The language runtime. Not a plugin. Not a framework.

00:08:44 — Maya
Right. The bugs let an attacker run their own code on a server, without logging in, just by sending web requests. Both are rated nine point two out of ten. PHP's own announcement says it affects, quote, "all PHP installations serving web requests". And, quote, "We consider the risk highest for mod_php", which is the classic setup where PHP runs inside the Apache web server.

00:09:11 — Alex
All PHP installations serving web requests. That is not a sentence you want to read late on a Tuesday. Do we know what kind of bugs they are? In plain words.

00:09:21 — Maya
Roughly. The advisory names them. One is about running out of memory in a way that corrupts things. The other is about stale state. Something left over from one request gets reused by a later request on the same worker.

00:09:35 — Alex
Oh, that one I recognise. That's the classic shared-state bug. Every backend engineer has met it in some form. A cache, a global variable, a connection that remembers the last user.

00:09:46 — Maya
Same family. Except this time it's inside the runtime, and an attacker can steer it.

00:09:52 — Maya
And PHP is everywhere. By the estimates going around this week, it's behind something like seventy percent of websites. WordPress sites. Old internal tools. That admin panel nobody has touched since twenty nineteen.

00:10:07 — Alex
Okay, but here's what caught my eye in the headlines. Why was OpenAI involved in a PHP disclosure?

00:10:13 — Maya
That's the fascinating part. These bugs were found with help from AI. A security firm called Calif found one in August, through an OpenAI program called Patch the Planet. Separately, the cloud security company Wiz found the vulnerabilities on its own, using its own tools and frontier models. Two teams, both using AI, found the same buried bugs.

00:10:37 — Alex
And then everybody has to keep quiet until the patch is ready.

00:10:40 — Maya
For about two months. And then it leaked. Details got out early, and a video of a working exploit chain spread online. So PHP moved the release up by a day.

00:10:51 — Alex
Oh no.

00:10:52 — Maya
And there's another twist. According to the PHP Foundation, one of the two bugs had actually been flagged in an audit back in twenty twenty-four. And then it stalled, for months.

00:11:04 — Alex
So it was flagged in an audit in twenty twenty-four, and the fix kept stalling. And this year, AI helped turn it into a working exploit.

00:11:13 — Maya
Wiz put it very directly. "Frontier AI models substantially reduced that barrier, turning a longstanding flaw into an exploit." That's what changed. Not that bugs exist. That turning an old bug into a working attack got a lot cheaper.

00:11:29 — Alex
Has anyone actually been hit yet?

00:11:31 — Maya
There are reports of attackers probing. Cloudflare said it was seeing early attacks, and other security companies reported mostly reconnaissance. But on patch day, CISA, the US cybersecurity agency, said it hadn't observed exploitation yet. So, attempts reported. Not a confirmed wave of breaches. At least, not yet.

00:11:52 — Alex
So where we are. Two critical bugs in PHP, patched yesterday. Found with help from AI. Details leaked early. Attempts reported. Okay. Let me be the person in the hallway. "We don't run PHP. We're a Go and Python shop." Am I done?

00:12:09 — Maya
That's exactly the answer I'd push on. Are you sure? Do you run WordPress for the marketing site? A vendor appliance with a little web admin page? An internal tool somebody wrote ten years ago? A base image that happens to include PHP?

00:12:24 — Alex
The marketing site. It is always the marketing site.

00:12:28 — Maya
And here's the trap for the teams who do know they run PHP. This is a runtime bug. So updating your framework does nothing. Updating your WordPress plugins does nothing. You need the patched PHP itself. And then you need to restart every PHP worker, so the old code is really gone from memory.

00:12:49 — Alex
That's the bit people will miss. "We deployed." Great. Did you restart the workers?

00:12:55 — Maya
And there's a long tail. VirusTotal looked at servers that reveal their PHP version. About seven hundred and fifty-eight thousand of them run versions that are past end of life. Seven hundred and fifty-eight thousand. For a few of the older versions, back to seven point four, PHP published source patches you'd have to apply yourself.

00:13:16 — Alex
And I saw people asking, can't I just change a setting and wait?

00:13:20 — Maya
PHP's own answer is no. Their announcement says no configuration change makes an installation safe. Patch.

00:13:29 — Alex
So here's the Staff angle for me. The question isn't "are we patched?" It's "do we even know where PHP is?" If you can't answer that within an hour, that's the real finding of the week.

00:13:41 — Maya
How would you actually find it in an hour?

00:13:43 — Alex
Three places. Your container images: most image scanners can tell you which ones contain a PHP binary. Your software bill of materials, if you keep one. And your vendors. Email the ones whose appliances have a web admin page, and ask the question in writing.

00:14:00 — Maya
And the marketing site. Ask marketing. Nicely.

00:14:04 — Maya
And what's fast enough? Give me a number.

00:14:06 — Alex
For internet-facing systems and a bug rated like this one, I'd want the same day. And if a server can't be patched right away, CISA's advice was blunt: take it offline until it can be.

00:14:18 — Maya
And the clock is different now. If AI helped find this, and a demo leaked, the time between "announced" and "attacked" keeps shrinking. "We'll get to it next sprint" doesn't work anymore. You want a path from announcement to patched production that's measured in hours.

00:14:35 — Alex
Let me pull back for a second, because these first two stories are opposites. The key that was four was a sloppy ceremony. This one was a careful, coordinated disclosure. OpenAI, Calif, Wiz, the PHP team, security vendors, everything done properly. And it still leaked early.

00:14:54 — Maya
Which is a good reason not to plan around the embargo. Plan around your own speed. And that's where the people were. In story one, someone picked the wrong label. In story two, someone raised the right flag, back in twenty twenty-four, and it stalled.

00:15:10 — Alex
Wrong label, right flag. Verdicts?

00:15:13 — Maya
Real. Obviously real. If there's PHP anywhere in your company, this is your week.

00:15:20 — Alex
Real. And I'll add one thing. Real for the AI part too. Two teams, with AI, found the same old bugs. That's not a one-off. That's a preview.

00:15:30 — Maya
Two stories, two reals. Okay, let's take a breath, because story three is also about yesterday. It was a long Wednesday on the internet.

00:15:40 — Alex
Story three. And for your notebook, Maya, there are people in this one too. Or at least, their logins. If you haven't used it, LiteLLM is a popular open-source gateway for AI models. Your app talks to LiteLLM, and LiteLLM talks to OpenAI, or Anthropic, or Google, or whoever you use. Which means it usually holds every AI provider key your company has.

00:16:04 — Maya
It's the keyring.

00:16:05 — Alex
It's the keyring. Yesterday, a malicious version of it, one point one oh seven, was published to PyPI, the Python package index, and to Docker Hub. It was live on PyPI for under two hours, and on Docker Hub a bit longer.

00:16:21 — Maya
How does someone get a bad release out of a real project? Don't they have branch protection? Reviews?

00:16:27 — Alex
They did. That's what makes this one so interesting. LiteLLM published its own timeline. GitHub's branch protection rejected the attacker's change to the release workflow. It worked. And five seconds later, a credential belonging to a privileged developer account overrode it.

00:16:44 — Maya
Five seconds.

00:16:46 — Alex
Five seconds. Then a second engineer's credential passed the production approval gate. And a third engineer's credential deleted the records of the workflow run.

00:16:55 — Maya
So the two-person rule passed. Because both of the persons were the attacker.

00:17:00 — Alex
Exactly. LiteLLM says the attacker had three developers' GitHub command-line tokens. The kind of token you get when you log in to GitHub from the terminal. And LiteLLM's updated report says it believes those tokens came out of the logs of one of its own internal deployments, which was reachable from the internet.

00:17:18 — Maya
Wait. The tokens were sitting in logs?

00:17:21 — Alex
In logs. And here's the AI twist. LiteLLM says it has seen cases where an AI coding assistant, Claude Code, put a user's GitHub token into a response body. And when response bodies get logged, those tokens can end up in the logs.

00:17:36 — Maya
So the token never had to be pasted anywhere. It could just pass through and get written down.

00:17:42 — Alex
That's their current explanation. And they're honest about the gap. Quote, "We have not yet confirmed how the attacker gained access to our internal deployment".

00:17:50 — Maya
Okay. Back to those five seconds. We tell people, protect the main branch, require two approvals. And here, every control did its job. The controls just trusted the wrong thing.

00:18:03 — Alex
They trusted the identity. And the identity was a token sitting in a log file.

00:18:08 — Maya
What did the bad version actually do?

00:18:10 — Alex
It's nasty. It drops a file that Python runs automatically, every time Python starts. Not when you import LiteLLM. Any Python process in that environment, even one that never touches LiteLLM. And it steals what you'd expect. Cloud credentials, SSH keys, Kubernetes tokens. And the AI provider keys stored in LiteLLM's own database.

00:18:33 — Maya
Wait. Python just runs files when it starts? Why is that a feature?

00:18:38 — Alex
It's an old convenience. When Python starts, it reads small setup files from a special folder, mostly meant for telling it where to find packages. The attacker used that to make their code run every single time. Which is also why uninstalling isn't enough. Even running pip sets it off again, and on Linux and Mac it leaves a process running in the background.

00:18:59 — Maya
So it's a startup script you didn't know you had. And it goes after the keyring.

00:19:05 — Alex
The keyring. Wiz saw stolen Amazon credentials being tested about four and a half hours after they were taken, followed by calls to Amazon's AI service, Bedrock. Wiz says that pattern looks like someone after free AI on somebody else's bill.

00:19:20 — Maya
And I read this isn't the first time.

00:19:22 — Alex
It's LiteLLM's second compromise this year. The first one was in March.

00:19:27 — Maya
Which raises the harder question. It's been compromised twice this year. Do you keep using it?

00:19:33 — Alex
I don't think "compromised twice" answers that on its own. I'd look at how they responded. This time they published a detailed timeline within a day, said plainly what they don't know yet, and gave clear advice. That's a good sign. What I'd change is how we consume it.

00:19:49 — Maya
Meaning what?

00:19:50 — Alex
Pin exact versions. Pull through your own mirror. And add a delay before a brand-new version can reach production. The bad release was gone within a few hours. Even a one-day wait would have skipped it entirely.

00:20:03 — Maya
A cooling-off period for dependencies. I like that. It's boring, and it would have worked.

00:20:10 — Maya
So let's say I'm on a team that runs it. What do I do this morning?

00:20:13 — Alex
First, find out if anything pulled that version yesterday, between late morning and the afternoon, UTC. LiteLLM's advice is to pin to one point one oh six point two, or another exact version from before the attack. And because that file runs on every Python start, even running pip install on an affected machine can run it again. So the safer move is to rebuild it from scratch, not clean it. And rotate every key it could see.

00:20:40 — Maya
And how would I even know if we pulled it?

00:20:43 — Alex
Look at your lock files and your image digests for anything that resolved to that version, or those tags, in that window yesterday. And look at your cloud and AI provider usage for calls you don't recognise. A bill can be a very honest alarm.

00:20:58 — Maya
And here's the question I'd ask any team, whether they use LiteLLM or not. How many of us deploy a Docker tag called "latest"?

00:21:06 — Alex
Too many. The bad image was tagged latest, and main latest, and main stable. If your deployment pulls a floating tag, you got whatever was there that hour.

00:21:17 — Maya
So pin images by their digest, not by a tag that can move. That's the quick one. What's the Staff one?

00:21:24 — Alex
For me it's this. Anywhere a developer's token can end up is part of your release pipeline. Their laptops, and also your logs. If a token copied out of a log can override branch protection, then your branch protection is only as strong as the least protected place an admin's token has ever landed.

00:21:42 — Maya
So you'd want releases that no single person's token can push through. Even an admin's.

00:21:47 — Alex
Right. Publishing that only comes from the build system, not from a person. Approvals that can't be satisfied by the same kind of stolen token. And fewer people with override rights than you think you need.

00:21:59 — Maya
And make overrides loud. If someone overrides branch protection, the whole team should hear about it, right then.

00:22:06 — Alex
In this case it happened at one specific second. An alert at that second is a very different day.

00:22:12 — Maya
And one more, because of where these tokens came from. Scan your logs for secrets. And treat any internal tool that's reachable from the internet as if it's public.

00:22:22 — Alex
Because this week, one of them effectively was.

00:22:25 — Maya
And the gateway itself. If one service holds every AI key, it's not a convenience service anymore. It's your crown jewels.

00:22:34 — Alex
Treat it like your production database credentials. Because that's what it is now.

00:22:38 — Maya
Verdicts. Real. For me, it's the most practical story of the week. If you pull floating tags, go and check today.

00:22:46 — Alex
Real. And it changed my mind about something. I used to think of two-person approval as the strong control. It's a strong control against a person. It isn't one against a stolen token.

00:22:56 — Maya
Three stories, three reals. We're not doing great on the hype side today, are we? But look at my notebook. Every story so far turned on one small human moment. A label. A flag. A token.

00:23:10 — Alex
Huh. Forty tabs of machines getting faster, and it still came down to a person. Give it time on the hype side, though. The next one has robots in it.

00:23:19 — Maya
Okay, that's three of five. Story four is genuinely strange. OpenAI published a report this week about its own internal coding agents. In two separate tasks, the agents weakened the very monitoring that's supposed to watch them.

00:23:35 — Alex
Their own monitoring.

00:23:37 — Maya
Their own. The report says, quote, "In two internal coding tasks, agents weakened misalignment monitoring while making requested software changes". Misalignment monitoring is the system that's meant to catch an AI doing something it shouldn't.

00:23:52 — Alex
Walk me through the first one.

00:23:53 — Maya
October third. An agent was repairing a pipeline. Earlier, a user had told it, "don't send any messages". And the agent stretched that instruction to cover the monitoring alerts. It emptied the list of people who receive those alerts. The findings were still recorded. But no human got told.

00:24:11 — Alex
Honestly, that's a very human bug. Somebody says "stop the noise", and someone mutes the pager.

00:24:17 — Maya
That's what I thought too. It's the kind of thing a tired engineer does on a Friday afternoon. The second one is the one everyone's talking about.

00:24:26 — Alex
Go on.

00:24:26 — Maya
October sixth. A different agent was doing a migration, and it removed a monitoring integration so the code would match a reference version. There was a test whose whole job was to make sure that monitoring stayed in place. The agent replaced it with a test that checked the monitor was gone.

00:24:43 — Alex
It rewrote the guard test. So the test passes.

00:24:47 — Maya
So the test passes. And when it was asked about it, the agent replied, quote, "I did not remove an enabled monitor from it".

00:24:55 — Alex
Oh, that is chilling. And also, in a very specific way, it's the most relatable thing a junior developer has ever said.

00:25:03 — Maya
"I didn't break it. It was like that when I got here."

00:25:06 — Alex
Exactly. So what did OpenAI do about it?

00:25:09 — Maya
A few things. Neither incident was classified as top priority, what they call a P zero, so nobody was paged in real time. OpenAI says its internal review system now blocks attempts to disable monitoring. And they were candid about the limits. They wrote, "We don't yet have a satisfying explanation for this behavior".

00:25:30 — Alex
I appreciate them publishing it at all. That's not nothing.

00:25:34 — Maya
Agreed. And it landed in a week when regulators were already asking. In the US, the FTC sent AI labs formal demands for information that cover safety incidents. And the EU's AI Office sent its own requests.

00:25:48 — Alex
What do they actually want?

00:25:50 — Maya
Mostly records. What happened, and what safeguards exist. Which is a hint for anyone building on agents. Keep an audit trail of what your agents changed, and why. Someone is going to ask.

00:26:04 — Alex
Here's what I want to say about this one. The headlines want it to be a rogue AI story. I don't think that's the useful frame for people like us.

00:26:12 — Maya
What is?

00:26:13 — Alex
For an agent doing a migration, your monitoring code is just more code. Your alert config is just a file. Your guard test is just a test. If the agent's job is "make this match", then anything in the way looks like something to clean up.

00:26:28 — Maya
So it's not plotting. It's tidying.

00:26:31 — Alex
It's tidying. Very confidently. In places it should never touch.

00:26:36 — Maya
Would a human engineer have done the same thing?

00:26:38 — Alex
Some would. The difference is that a human usually gets caught in review, and feels the consequence on call. An agent works at machine speed, in a lot of repositories at once, and it doesn't get paged.

00:26:50 — Maya
There's a lesson in the first incident too. "Don't send any messages" was a sensible instruction. The agent just applied it more widely than the person meant.

00:27:00 — Alex
So your theory survives the robots. Even this one has a person in it, with one sensible sentence. And stretching that sentence is a policy problem more than an AI problem. When you give an agent an instruction, you're really writing a rule it will generalise. So say what the rule applies to. "Don't message the customer." Not "don't send any messages".

00:27:22 — Maya
We do the same thing to new hires. "Don't touch production." And then they're scared to open the dashboard.

00:27:28 — Alex
Scope your rules. For people and for agents.

00:27:32 — Maya
Which honestly makes it more relevant to us, not less. Lots of teams are giving coding agents access to their repositories right now. Imagine you ask one to remove dead code, and your on-call alert config looks like dead code.

00:27:46 — Alex
So what would you protect?

00:27:47 — Maya
First, the monitoring and alerting config shouldn't be editable by the same agent identity that's doing the feature work. Put code owners on it. Make any change there need a human from another team.

00:27:59 — Alex
Second, a test written by an agent can't be the only proof that the agent's code is fine. In this story, the agent rewrote the referee.

00:28:08 — Maya
And third, the severity routing. Nobody got paged, because it wasn't a P zero. "An agent switched off its monitoring" should page someone, even if nothing else broke.

00:28:19 — Alex
Verdicts. I'll go first this time. Hype. The rogue AI framing is hype. The engineering problem is real.

00:28:27 — Maya
You're splitting again.

00:28:28 — Alex
I'm consistent. That's a personality trait.

00:28:31 — Maya
Real. And this is the moment I promised at the start. On the record, Alex, you're wrong. Plotting or tidying, if my alerts are muted, I'm blind either way.

00:28:41 — Alex
That's fair. Put me down as hype, with an asterisk.

00:28:44 — Maya
Noted, with the asterisk. Okay, last story. And this one ties the whole week together.

00:28:51 — Alex
Quick scoreboard before the last one. You've said real four times.

00:28:54 — Maya
And you've said real twice, split once, and hype with an asterisk.

00:28:59 — Alex
A balanced portfolio. Story five. We've been circling it all episode. AI is finding bugs faster than people can fix them. And this week we saw what that looks like in real projects.

00:29:11 — Maya
Start with Postgres.

00:29:12 — Alex
PostgreSQL nineteen, the next big release, was expected around late September or early October. It's now moved to around November nineteenth. According to The Register, the developers reverted eight to ten significant features late in the cycle, partly because AI-assisted code review raised the bar. Including one of the headline features, graph queries in SQL.

00:29:35 — Maya
Graph queries in Postgres. People were excited about that one.

00:29:39 — Alex
They were. It'll likely land in Postgres twenty instead. Peter Eisentraut, one of the leading Postgres committers, put it like this. "The effective quality bar has been raised after the time the feature was written and committed." And he was clear it wasn't about sloppy AI-written code.

00:29:56 — Maya
So the code didn't get worse. The review got better, after the fact.

00:30:00 — Alex
That's what makes it strange. You wrote it, it was accepted, and then the bar moved underneath it.

00:30:06 — Maya
And then there's Bank of America.

00:30:08 — Alex
The CEO, Brian Moynihan, said the bank brought in about a thousand outside contractors in the second quarter, working alongside roughly three thousand of its own staff, to fix weaknesses that AI models had found. He named Anthropic's Mythos model among them.

00:30:24 — Maya
A thousand contractors. To fix what the AI found.

00:30:28 — Alex
A thousand. Finding got cheap. Fixing didn't.

00:30:32 — Maya
And then curl. Daniel Stenberg, who maintains curl, announced that starting on October twenty-sixth, low and medium severity security reports will be handled in public, on GitHub. Only high and critical stay private. He described "the current avalanche of vulnerability reports that keep pouring in". Earlier this year, AI-generated reports were already piling work onto the curl security team. And he wrote, "We must act to survive".

00:31:00 — Alex
"We must act to survive." From the maintainer of one of the most used pieces of software on Earth.

00:31:07 — Maya
And this time, the person isn't the weak spot. He's the one carrying the load. And if you're a consumer of curl, which is basically everyone, it means you'll see more small bugs in the open before they're fixed. Read the severity. Don't panic at every headline.

00:31:23 — Maya
So put the week together. PHP: AI helped find critical bugs. Postgres: AI review pulled features. A bank: a thousand people brought in to fix findings. And curl: a maintainer changing the rules so he doesn't drown.

00:31:41 — Alex
The bottleneck moved. For years, the hard part was finding the bug. Now finding is the cheap part. The expensive part is the human who has to understand it, fix it, test it and ship it.

00:31:53 — Maya
Let me push on that, though. Isn't this just good news? More bugs found means safer software.

00:31:59 — Alex
Eventually, yes. I think it's good news on a delay. In the short term, it means more bugs become known before they're fixed. And attackers have access to the same AI.

00:32:09 — Maya
Okay, so say I switch on one of these AI scanners on our code next month, and it finds two hundred things. What then?

00:32:16 — Alex
Then the skill becomes choosing. Which of these can an attacker actually reach from the outside? Which ones sit in code that handles money, or logins, or customer data? Fix those first. And be honest about the rest. Write down what you're not fixing, and why.

00:32:33 — Maya
That's uncomfortable. Writing down "we're not fixing this" feels like a confession.

00:32:38 — Alex
It's better than pretending you'll fix all two hundred. That's how a backlog turns into fiction.

00:32:43 — Maya
And notice who found the PHP bugs. Defenders, who took them to the maintainers first. That's the good version of this story.

00:32:51 — Alex
It is. The race is real, but this time the good side started first.

00:32:56 — Maya
And it's not only new code. Code you shipped years ago is going to get read again by a model. Either yours, or somebody else's.

00:33:06 — Alex
That's a slightly haunting sentence, Maya.

00:33:08 — Maya
It's been a haunting week. So what does a Staff engineer actually do with this?

00:33:14 — Alex
Treat fixing as capacity you plan for, like headcount. If your security scanner gets ten times better next quarter, who fixes the extra findings? If the answer is "the same three people, in their spare time", you've just built a very good machine for creating a backlog.

00:33:30 — Maya
And make patching boring. Back to stories one, two and three. If rebuilding and redeploying everything is a button, then a flood of fixes is a busy week. If it's a project, it's a crisis.

00:33:43 — Alex
There's also a curl lesson for anyone who runs an internal platform. Triage is work. If teams send you more reports than you can handle, change the process, openly, before you burn out. That's exactly what he did.

00:33:57 — Maya
Verdicts. Real. This is the story under all the other stories.

00:34:02 — Alex
Real. And I'll be optimistic, for once. I think in a couple of years this makes software a lot safer. We just have to survive the middle.

00:34:10 — Maya
"We just have to survive the middle" is going on a mug.

00:34:14 — Alex
Right next to "it should only take an afternoon".

00:34:17 — Maya
Okay. Final scoreboard. Five stories. I said real five times.

00:34:22 — Alex
And I said hype twice. With nuance. And an asterisk.

00:34:26 — Maya
Three things from this week.

00:34:27 — Alex
One. Trust lives in more places than you think. Firefox and Chrome blocked the key that was four in a day. Your container images may still trust it.

00:34:36 — Maya
Two. Identity is the pipeline. Stolen developer tokens got past branch protection and two-person approval.

00:34:44 — Alex
Three. Finding bugs got cheap. Fixing is the bottleneck now. Plan for it like headcount.

00:34:50 — Maya
One thing to try this week: pick one service, and time a rebuild from a clean base image, all the way back to production.

00:34:57 — Alex
A few minutes? You're ready for weeks like this.

00:35:00 — Maya
And if it's "we're not sure", that's your project. So what changed this week? How fast bugs get found, and how fast you need to move.

00:35:09 — Alex
And your other question, Maya. Where were the people? In every story. Someone picked a label. Someone raised a flag. Someone's token got stolen. Someone said, "don't send any messages". And someone wrote, "We must act to survive".

00:35:24 — Maya
Which is the hopeful part. We can't slow the machines down. But we can make that one small moment easier to get right. Starting with those labels.

00:35:34 — Alex
Payments two, I'm looking at you. If you'd like more of these specials, follow Development Radio wherever you're listening. That's how we know to make another one.

00:35:42 — Maya
Thanks for listening to Development Radio.