Ship It Weekly Host Commentaries

For this Conversations episode, I wanted to stay anchored on a question that I think is going to matter a lot more over the next couple years.

Not whether AI can help with infrastructure.

Whether it should be trusted anywhere near real infrastructure before it has a place to prove itself first.

That is why this one interested me.

Because Ang Chen is not really pitching “let the agent run prod.” He keeps bringing it back to a safer idea than that. Build a sandbox. Build a digital twin. Let Terraform, CloudFormation, SDK scripts, and even AI-assisted workflows hit that first. Then see what breaks before anything touches the real cloud.

What I liked most is that the conversation did not stay at the vague “AI will change everything” level.

He actually gives a pretty grounded answer for what high fidelity is supposed to mean. Not “trust us, it feels real.” More like: constrain the generation, use formal scaffolding so the model is not just free-writing random emulator logic, then strategically test those behaviors against the actual cloud and patch the gaps when they show up. That is a much more serious answer than a lot of AI infrastructure demos give right now.

And honestly, that is where the episode got interesting for me.

Because if you are a platform engineer or DevOps person, you already know the pain here. Testing directly against real cloud is slow, expensive, and risky. Even when everything works, you are still paying in time, feedback delay, and blast radius. So the promise of something like Vera is not magic. It is faster iteration and safer validation. That is a much better frame for this than hype.

I also liked that Ang did not try to pretend the answer is perfect.

He says pretty directly that it is not one-to-one. The goal is not perfect imitation down to every line of output. The goal is to be close enough to support real classes of DevOps testing. I think that is the honest version of this whole category. Because if a sandbox can catch meaningful mistakes, break bad assumptions, and help validate changes before CI pushes something into actual cloud, that is already very valuable even if it is not a perfect clone of AWS.

The edge case he brought up was great too, because it shows how brutal infra tooling can be about details.

Something as dumb as camelCase versus snake_case in a response can be enough to break Terraform. That is the kind of thing people outside this space miss. Infrastructure tools are not impressed by “close enough.” They are extremely literal. So when people talk about cloud emulation, this is the real bar. Not whether it looks convincing in a demo. Whether it behaves precisely enough that existing tools do not choke on it.

Another part I liked was his answer on where this fits first.

Not everywhere. Not all at once. Plug it into CI/CD. Let it validate Terraform changes in a sandbox. Let it catch issues before push. That felt practical. At the same time, he was clear about limits too. EC2 was the main focus in the interview, it does not cover all AWS resources yet, and some of the more ambitious AI debugging and deployment-specific customization ideas are still on the roadmap. That honesty helps, because it keeps this grounded in “useful early tool” instead of “finished answer.”

The bigger thread running through the whole conversation is the one I keep coming back to.

AI for ops is probably not going to be won by whoever gives agents the most access. It is probably going to be won by whoever builds the best guardrails, the best evals, and the best places for those agents to learn safely. And that is what Vera feels like to me. Not the final form of AI in infrastructure, but a much smarter direction than pretending the path forward is just giving an LLM credentials and hoping for the best.

So if you are listening to this episode and want one takeaway, it is this:

Before AI earns the right to touch real infrastructure, it should have to survive a sandbox first.

That is the bar.

If you want, I can also tighten this into a slightly shorter, more spoken-word version for teleprompter delivery.

For this episode, the thing that kept showing up was not really “AI” by itself.

It was responsibility.

More specifically, what happens when companies roll out a new interface, a new abstraction, or a new “easy path,” and then quietly hand platform teams all the responsibility that comes with it.

That’s what tied these stories together for me.

McKinsey had to publicly deal with a vulnerability in Lilli, which is useful not because it turned into some huge apocalyptic breach story, but because it reminds people that internal AI tools are still real systems. They may look friendly. They may be framed like helpers. But once they can touch company knowledge, influence decisions, or sit in the middle of a workflow people trust, they stop being side tools. They become part of the operating surface.

And that means all the old questions come right back.

Who can access it.
What can it read.
What can it write.
What does it trust.
What gets logged.
What happens when somebody uses it in a way nobody really modeled.

That is the part people keep wanting to skip.

Everybody wants the new interface. Very few people want the old responsibilities that come with it.

The Kafka story hit a different version of the same theme.

Diskless topics are interesting because they feel like architecture honesty. Not hype. Not branding. Just a pretty direct acknowledgment that cloud economics eventually force you to revisit assumptions that used to feel settled. If durable local storage and broker-led replication were the obvious center of gravity before, maybe they are not the obvious center of gravity now. That is a much more useful kind of story to me than most “future of AI” noise, because it is really about something deeper: when the environment changes enough, old architecture starts charging rent.

And a lot of teams are probably living that right now, even outside Kafka.

You see it when the old design still technically works, but it works in a way that is more expensive, more awkward, or more fragile than anybody wants to admit. At some point, tuning stops being the answer. The answer becomes rethinking what the system is centered around in the first place.

Then there’s Google closing the Wiz acquisition, which to me reads less like a flashy M&A story and more like an admission about where the cloud fight actually is now.

The fight is not just compute. It is not just managed services. It is not just who has the nicest product page or the most polished launch event. It is posture. Visibility. Exposure. Identity. Policy. Security as part of the actual platform choice.

That feels obvious if you live in this space, but it is still worth saying out loud because companies still act like cloud strategy and security strategy are two separate conversations. I buy that less and less. Not when environments are this messy. Not when AI is adding new surfaces. Not when half the real work is figuring out what is running where, who can touch it, and what your blast radius looks like when somebody gets it wrong.

The AWS Copilot story is kind of the same lesson again, just in a more familiar cloud-ops form.

The paved road moved.

That’s really the story.

And platform teams know exactly what that means. It means the thing that felt like the safe, vendor-approved path now has an off-ramp. It means migration work. Retraining. Documentation churn. Re-explaining choices to teams that thought the answer was already settled. It means carrying the cost of somebody else’s product direction.

That is why I keep coming back to the idea that convenience in cloud is borrowed.

Sometimes borrowing it is absolutely worth it. I am not against paved roads. Most teams should probably use more of them, not less. But the tradeoff is always there. When the road changes, you move too. And if you have not thought about the exit story in advance, the migration always feels more annoying than it should.

Then the Kubernetes AI Gateway Working Group rounds the whole episode out in a way I really like, because it cuts through a lot of the dumbest AI discourse.

The interesting question is not “do you believe in AI” or “what model is best this week.”

The interesting question is what happens when AI traffic becomes normal platform traffic.

Because once that happens, the conversation gets a lot more real. Now it is rate limiting. Access control. Payload inspection. Egress policy. Caching. Guardrails. Prompt injection defenses. Logging. Routing. Normal boring platform words. Which is exactly why I like the story. It is a sign that the industry is moving from novelty into operations.

And that is usually where the truth shows up.

If I had to boil the whole episode down, I think it comes back to this:

The new interface does not remove the old responsibilities.

That is true for internal AI tools.
It is true for cloud architecture.
It is true for security acquisitions.
It is true for vendor paved roads.
And it is definitely true for AI-shaped traffic once it starts touching real systems.

There’s always a shiny version of the story companies want to tell.

Smarter tools.
Faster delivery.
Simpler workflows.
Better leverage.
A more intelligent future.

And sure, some of that is real.

But the operator version of the story always lands a little differently.

What are the trust boundaries.
What gets logged.
What is actually enforced.
How clean is rollback.
What happens when the vendor changes direction.
What assumptions are now too expensive to keep pretending are normal.
Who owns the control plane after all this stuff hardens into real production dependency.

That’s where this episode lived for me.

Not in the hype.
Not in the demo.
Not in whether the new thing sounds cool.

More in the handoff point where new capability turns into somebody else’s operational burden.

And most of the time, that somebody is us.

For this episode, the theme that kept showing up was pretty simple: AI is crossing out of the “tooling” bucket and into the parts of the stack that change how companies operate, how platforms fail, and how trust actually gets enforced.

Not just code suggestions. Not just faster PRs. Not just nicer demos.

Now it’s showing up in layoffs, org redesign, agent identity, security boundaries, and platform instability. Block tied a major workforce reset to “intelligence tools.” Atlassian said AI is changing the mix of skills and roles it needs. Meta bought Moltbook, which is basically a weird little lab experiment for agent-to-agent behavior that already came with a security stain on it. And GitHub had to come out and say, pretty directly, that they have not met their own availability standards lately.

That’s why I don’t think this episode is really “about AI” in the lazy sense.

It’s about what happens when AI stops being a side tool and starts becoming part of the operating model.

The Block story is the clearest example. In the shareholder letter, Jack Dorsey said “intelligence tools have changed what it means to build and run a company,” and argued that a significantly smaller team could do more and do it better. But the follow-up reporting immediately made the story messier, pointing to other pressures too, including crypto weakness, overstaffing, and stock pressure. That gap is the interesting part. Not whether AI helps, because obviously it does in some contexts. The interesting part is how fast “AI” is becoming a clean explanation for decisions that are also about cost, structure, expectations, and management philosophy.

And Atlassian matters because it makes Block feel less isolated.

Their March 11 update was explicit: about 10% of the company, around 1,600 people, while self-funding more investment in AI and enterprise sales and reorganizing to move faster. They also said, pretty plainly, that while their approach is not “AI replaces people,” it would be disingenuous to pretend AI doesn’t change the mix of skills needed or the number of roles required in certain areas. That’s a very different tone than Block, but it lands in a similar place. AI is no longer just being sold as leverage. It is being used as staffing logic.

From the DevOps and SRE seat, that creates a very practical question.

If leadership is going to claim more output from fewer people, what exactly is scaling the safety net?

Because generated output scales fast. Human review, operational context, on-call coverage, and rollback discipline usually do not. That part is my inference, obviously, but it’s the inference these stories keep pushing me toward. If AI becomes the reason to cut faster than you improve your controls, then the real result is not “transformation.” It’s just a thinner human layer sitting behind a more aggressive delivery system.

The Moltbook story is the other side of this.

On paper it sounds goofy. Meta bought a social network for AI agents. Fine. Weird internet headline. But Reuters is clear that this is not just a joke acquisition. Meta is bringing the founders into Superintelligence Labs, and the whole thing points at where the agent race is headed. At the same time, Reuters also notes that Moltbook’s rise came with security problems, including a flaw that exposed private messages, thousands of emails, and more than a million credentials before Wiz reported it and the issue was fixed. That’s why the story matters. Not because “robots posting on a forum” is inherently important, but because it previews the trust problem. Once agents start acting on behalf of users, teams, or companies, identity, permissioning, auditability, and blast radius stop being product details and start becoming platform concerns.

That’s also why the AWS Bedrock AgentCore Policy announcement was a good lightning-round item.

It is basically AWS saying, out loud, that agent-tool interactions need centralized, fine-grained controls that operate outside the agent code itself. Security, compliance, and operations teams need to define what agents are allowed to do without rewriting the agent every time. That feels like the grown-up version of this whole conversation. Not “trust the prompt.” Not “the model seemed fine in a demo.” Policy, validation, interception, governance. The same old boring words that always matter once software starts touching real systems.

Then there’s GitHub, which was honestly one of the most useful stories in the bunch because it brought the whole episode back to reality.

GitHub said the most significant incidents happened on February 2, February 9, and March 5, and tied the instability to rapid load growth, architectural coupling, and a weak ability to shed load from misbehaving clients. On the Actions side, one outage came from a telemetry gap that caused security policies to hit key internal storage accounts and block VM metadata access. Another came from a Redis failover that left a cluster with no writable primary. That is just real platform engineering pain. No fluff. No fake confidence. Just growth, dependency coupling, failover assumptions, and systems that turned out to be less isolated than they needed to be.

And that part connects directly to stuff we’ve already talked about on the show.

We were already on the Block layoff angle in a previous week’s episode, Episode 24Mar 6, 2026⏱️ 18:20AWS Bahrain/UAE Data Center Issues Amid Iran Strikes, ArgoCD vs Flux GitOps Failures, GitHub Actions Hackerbot-Claw Attacks (Trivy), RoguePilot Codespaces Prompt Injection, Block “AI Remake” Layoffs, Claude Code SecurityEpisode: AWS Bahrain/UAE Data Center Issues Amid Iran Strikes, ArgoCD vs Flux GitOps Failures, GitHub Actions Hackerbot-Claw Attacks (Trivy), RoguePilot Codespaces Prompt Injection, Block “AI Remake” Layoffs, Claude Code Security.

And on the GitHub outage side, we’ve hit that theme more than once already in Episode 1Nov 20, 2025⏱️ 12:54Special: When the Cloud Has a Bad Day: Cloudflare, AWS us-east-1 & GitHub OutagesEpisode: Special: When the Cloud Has a Bad Day: Cloudflare, AWS us-east-1 & GitHub Outages and Episode 19Feb 12, 2026⏱️ 15:49When guardrails break prod: GitHub “Too Many Requests” from legacy defenses, Kubernetes nodes/proxy GET RCE, HCP Vault resilience in an AWS regional outage, and PCI DSS scope creepEpisode: When guardrails break prod: GitHub “Too Many Requests” from legacy defenses, Kubernetes nodes/proxy GET RCE, HCP Vault resilience in an AWS regional outage, and PCI DSS scope creep. So this episode is less a brand-new theme and more the next step in the same pattern: AI is changing the pressure on the system, but the failures still show up in trust boundaries, control planes, and operational weak points.

That’s why I liked ending the main stories with Anthropic and Mozilla.

Because it keeps the episode from collapsing into “AI hype bad” or “AI layoffs bad” and pretending that’s the whole picture. Anthropic said Claude Opus 4.6 found 22 Firefox vulnerabilities in two weeks, 14 of them high severity, and Mozilla shipped fixes in Firefox 148. That’s a much more grounded version of the value story. Bug hunting, security review, broader coverage, more signal for humans to validate and act on. That feels way more real to me right now than the giant hand-wave of “smaller teams can just do more now, trust us.”

If I had to boil the whole thing down, I think the real divide is this:

There’s the AI story companies want to tell, and then there’s the AI story operators actually have to live with.

The company story is leverage, speed, restructuring, transformation, and the future.

The operator story is guardrails, permissions, blast radius, audit trails, outage recovery, and who still has to wake up when the system behaves in a way nobody modeled.

That’s where this episode lived for me.

Not “is AI good or bad.”

More like: where is it actually useful, where is it being used as cover language, and what new control points do platform teams need to care about before the hype gets translated into production reality?

Past Ship It Weekly references

Block layoff episode:
Episode 24Mar 6, 2026⏱️ 18:20AWS Bahrain/UAE Data Center Issues Amid Iran Strikes, ArgoCD vs Flux GitOps Failures, GitHub Actions Hackerbot-Claw Attacks (Trivy), RoguePilot Codespaces Prompt Injection, Block “AI Remake” Layoffs, Claude Code SecurityEpisode: AWS Bahrain/UAE Data Center Issues Amid Iran Strikes, ArgoCD vs Flux GitOps Failures, GitHub Actions Hackerbot-Claw Attacks (Trivy), RoguePilot Codespaces Prompt Injection, Block “AI Remake” Layoffs, Claude Code Security

GitHub outages episodes:
Episode 1Nov 20, 2025⏱️ 12:54Special: When the Cloud Has a Bad Day: Cloudflare, AWS us-east-1 & GitHub OutagesEpisode: Special: When the Cloud Has a Bad Day: Cloudflare, AWS us-east-1 & GitHub Outages
Episode 19Feb 12, 2026⏱️ 15:49When guardrails break prod: GitHub “Too Many Requests” from legacy defenses, Kubernetes nodes/proxy GET RCE, HCP Vault resilience in an AWS regional outage, and PCI DSS scope creepEpisode: When guardrails break prod: GitHub “Too Many Requests” from legacy defenses, Kubernetes nodes/proxy GET RCE, HCP Vault resilience in an AWS regional outage, and PCI DSS scope creep

Source links mentioned

Block Q4 2025 shareholder letter
What was really behind Jack Dorsey laying off nearly half of Block’s staff?
An important update on our team - Atlassian
Meta acquires AI agent social network Moltbook - Reuters
Wiz on the Moltbook exposure
Addressing GitHub’s recent availability issues - GitHub
Partnering with Mozilla to improve Firefox’s security - Anthropic
Policy in Amazon Bedrock AgentCore is now generally available - AWS

For this Conversations episode, I wanted to stay anchored on something that sounds simple, but a lot of people still get wrong when they’re trying to break into cloud or DevOps.

The answer usually is not “learn more tools.”

It’s focus.

Yvonne Young is great for this topic because she is not coming at it from the usual hype angle. She is not telling people to go collect every cert, every platform, and every buzzword. She keeps bringing it back to a much more grounded idea: pick a direction, learn the basics, stay consistent, and understand the business problem behind the tool. Without that, people wind up busy, but not actually job ready.

What I liked most is that her framework is not complicated.

First, figure out what you actually want to do. Security, cloud, infrastructure, databases, SRE, whatever it is. But pick something. Her point is that a lot of juniors get stuck because they try to learn everything at once, and then there is no path, no depth, and no real momentum.

Then build the foundation. In her view, Linux is still the starting point because so much of modern infrastructure still sits on top of it. Not “become a wizard overnight.” Just be functional. Know the basics. Move files, check disk, inspect ports, troubleshoot a service, use the help system, and get comfortable enough that you are not totally lost the second something breaks. That part really matters because it is the layer underneath a lot of the cloud and DevOps tooling people want to jump to first.

Then there is the consistency piece, which honestly is probably the most useful part for people listening to this episode.

Yvonne talks about how skills fade if you do a big cram session, then disappear for a week. Her point is that retention usually comes from short, repeatable reps. Thirty minutes. Forty-five minutes. A quick checklist. Brush up before interviews. Keep the basics fresh. That is a way more realistic model than pretending everyone is going to sit down for three-hour deep work sessions every night after work.

I also liked how she framed “job ready,” because I think a lot of people hear that phrase and imagine they are supposed to know everything.

Her take is almost the opposite.

Know the basics. Be ready for both the technical side and the behavioral side. Do the research on the company. And if you get asked something you do not know, do not panic and fake it. Show how you would think through it. Show how you would find the answer on the job. That is a much healthier and much more realistic definition than pretending readiness means total mastery.

Another thing that came through clearly is that she does not really teach tools in isolation. She teaches problems first.

That showed up in the way she talked about cloud adoption, security, and Vault. Not “learn Vault because Vault is cool.” More like, “understand secret sprawl, understand why companies care about centralized access and rotation, and then the tool makes sense in context.” Same with cloud. The point is not memorizing product names. The point is understanding why a business wants speed, efficiency, scale, or better security in the first place.

That part matters because it changes how people interview too.

If you only talk about tools, you sound like you memorized a stack. If you talk about the business problem the tool solves, you sound like someone who understands the bigger picture. And that is a much better signal, especially for people trying to get that first real break.

The other thread running through this whole conversation is mentorship.

Yvonne keeps coming back to the idea that without a mentor or a community, people lose time wandering. And honestly, that felt true not just for juniors, but for companies too. Because later in the episode she flips it around and talks about what seniors should do better: better onboarding, being available, and not throwing people into sink-or-swim situations with no lifeline. That part hit, because most of us have seen exactly that.

So if you are listening to this episode and you want one concrete takeaway, it is this:

Do not confuse motion with progress.

You do not need every tool.
You do not need every certification.
You do not need to know everything.

You need focus, fundamentals, consistency, and enough business context to understand why the work matters.

That is the real path in.

For this episode, the theme that kept showing up was control planes under pressure.

Not just the obvious ones like Kubernetes or CI/CD.

But the broader set of systems we now depend on to run infrastructure: GitOps controllers, developer workspaces, agent tooling, and even the geopolitical reality behind cloud regions and AI supply chains.

A lot of the stories this week look unrelated on the surface.

An AWS region dealing with infrastructure disruptions in the Middle East.
A GitOps migration story from ArgoCD to Flux.
CI pipelines being actively hunted by automated attackers.
Prompt injection turning into token theft in developer environments.
Companies restructuring around “AI productivity.”
And security tooling itself becoming AI-driven.

But if you zoom out a little, they’re all variations of the same underlying shift.

The automation layer has become the real control plane of modern infrastructure.

And once that happens, two things follow very quickly.

First, attackers target the control plane.

Second, organizations try to scale it faster than their guardrails.

You can see the first part clearly in the GitHub Actions attacks that StepSecurity documented.

This wasn’t someone finding a bug in an application.

It was an automated campaign targeting CI workflows across open source repositories.

The attacker isn’t interested in the application logic.
They want the release mechanism.

If you compromise CI, you don’t need a vulnerability in the app.
You can modify the artifacts, steal tokens, publish malicious packages, or pivot into infrastructure.

That’s why the Trivy maintainers’ response was interesting. They quickly published details about the attack vector and the workflow that was responsible.

That’s the right instinct.

CI incidents are supply chain incidents now.

---

StepSecurity hackerbot-claw analysis
https://www.stepsecurity.io/blog/hackerbot-claw-github-actions-exploitation

Trivy incident discussion
https://github.com/aquasecurity/trivy/discussions/10265

The second theme was control planes that fail in subtle ways.

The ArgoCD story is a good example.

GitOps sounds beautiful in theory.

Git is the source of truth.
The cluster reconciles to match it.
Everything is declarative.

But operationally, the controller itself becomes part of the reliability story.

If it gets stuck on a failed state, it can block the path to recovery.

And the CRD ordering problem mentioned in that migration write-up is something many teams eventually encounter.

It’s not a catastrophic bug.
It’s a behavior mismatch between how engineers expect reconciliation to work and how the system actually behaves.

That’s the dangerous category of failure.

Because it usually shows up during an incident, when you’re trying to deploy the fix.

Migration write-up
https://hai.wxs.ro/migrations/argocd-to-flux/

Another version of this control plane expansion is happening in developer environments.

The RoguePilot research is a good example of that.

A malicious GitHub issue can contain instructions that get interpreted when a developer launches a Codespace.

That’s essentially prompt injection as a supply chain vector.

And the problem isn’t just the model.

It’s the environment.

If the agent reading that issue has access to a GITHUB_TOKEN, or can run commands, or can open pull requests, the attacker has a pathway into real operations.

---

RoguePilot overview
https://thehackernews.com/2026/02/roguepilot-flaw-in-github-codespaces.html

Original research
https://orca.security/resources/blog/roguepilot-github-copilot-vulnerability/

There’s also a bigger conversation happening about agent boundaries.

Vercel published a good write-up on this recently.

The core idea is simple: most agents today run generated code with the same privileges as the developer or system running them.

Which means the real question becomes:

Where is the trust boundary?

Is the agent allowed to read untrusted content?
Is it allowed to execute commands?
Does it have access to secrets?

Those are the same questions we’ve been asking about CI systems for years.

We’re just asking them again for AI tools.

---

Security boundaries in agentic architectures
https://vercel.com/blog/security-boundaries-in-agentic-architectures

The AWS regional disruption story fits into this theme in a different way.

It’s a reminder that cloud infrastructure still exists in the physical world.

Power events, connectivity problems, geopolitical instability — all of these can show up as “cloud issues.”

And that’s why the phrase multi-AZ is not multi-region matters.

Availability zones protect you from localized failures.

Regions protect you from systemic ones.

And organizations that treat those as interchangeable eventually discover the difference during a very long outage.

---

Reuters coverage
https://www.reuters.com/world/middle-east/amazon-cloud-unit-flags-issues-bahrain-uae-data-centers-amid-iran-strikes-2026-03-02/

Then there’s the organizational side of all this.

The Block layoffs framed as an “AI remake” are part of a pattern we’re seeing across the industry.

Companies expect automation and AI to increase productivity.

And in many cases, they’re right.

But there’s a hidden constraint.

Automation scales faster than human oversight.

That idea has been explored really well by Uwe Friedrichsen in his Ironies of Automation series.

The key insight is that automation concentrates responsibility rather than eliminating it.

Systems get faster.
Systems get more capable.
But humans do not scale at the same rate.

Which means failures propagate faster than organizations can understand them.

---

Ironies of Automation series
https://www.ufried.com/blog/ironies_of_automation/

Ironies of AI (Part 2)
https://www.ufried.com/blog/ironies_of_ai_2/

We actually touched on that idea in an earlier Ship It Weekly episode when talking about control planes and automated RCA.

That conversation still applies here.

Earlier episode reference
Episode 10Jan 2, 2026⏱️ 17:45Fail Small, IaC Control Planes, and Automated RCAEpisode: Fail Small, IaC Control Planes, and Automated RCA

One more interesting development this week was Anthropic announcing Claude Code Security.

Tools like this aim to scan codebases for vulnerabilities and propose fixes automatically.

In theory, that’s extremely powerful.

Security teams spend huge amounts of time triaging issues that developers never get around to fixing.

If AI can propose safe patches and reduce that backlog, that’s a real win.

But it also raises the same operational question we’ve been talking about throughout this episode.

Is the tool suggesting changes, or making them autonomously?

Because the moment a system can modify code, open pull requests, or deploy changes, it’s no longer just a scanner.

It’s part of the control plane.

---

Claude Code Security
https://www.anthropic.com/news/claude-code-security

Finally, a quick note on the AI supply chain angle we mentioned in the lightning round.

DeepSeek reportedly withheld access to a new model from certain U.S. chipmakers while making it available earlier to domestic firms.

This is another reminder that AI infrastructure is now intertwined with geopolitics and hardware supply chains.

Which means “what model can we run” may become just as much a business or regulatory question as a technical one.

---

DeepSeek coverage
https://www.reuters.com/world/china/deepseek-withholds-latest-ai-model-us-chipmakers-including-nvidia-sources-say-2026-02-25/

If you step back from all of these stories, the through-line becomes pretty clear.

Infrastructure reliability used to be mostly about applications and servers.

Now it’s about the systems that operate the systems.

CI pipelines
GitOps controllers
Developer environments
Agent frameworks
Security automation
Cloud regions

These are the new control planes.

And the work of DevOps and SRE increasingly revolves around making sure those layers are safe, observable, and recoverable when something inevitably goes wrong.

That’s all for this week’s commentary.

If you want the full breakdown of the stories discussed in the episode, check the show notes and episode page.

More episodes are available at
https://shipitweekly.fm

And if this show has been useful, consider sharing it with a teammate or another engineer who’s living in the same automation-heavy world we all are right now.

Thanks for listening. See you next week.