The Software Efficiency Report | 2026 Week 46

Metric of the week

Review Pickup Time (RPT): Target Under 2 Hours (Elite Teams: Under 1 Hour)

Deep dive

Shipping Software Into Customer-Controlled Environments

Software Efficiency Metric of the Week

Review Pickup Time (RPT): Target Under 2 Hours (Elite Teams: Under 1 Hour)

What it is: The median time a pull request sits waiting between being marked ready for review and a teammate leaving the first real comment or approval.

Why it matters: Developers can put together a pull request in minutes now, so waiting in the review queue has become the real slowdown. When a PR sits untouched for half a day, the author moves on to another task. Coming back later to answer questions or fix small issues breaks their focus and delays the whole release.

The Formula: RPT = Median(Time of First Human Review - Time PR Marked Ready)

Quick Example: Say you open a pull request at 10:00 AM, nobody looks at it until 4:30 PM, and you only see the feedback the next morning. Your Review Pickup Time on that PR is 6.5 hours. Across 50 PRs in a week, a 6-hour wait adds up to nearly two full workdays of dead time before anyone even starts reviewing the code.

How to fix a high RPT:

1. Assign reviewers automatically: Set up CODEOWNERS and round-robin assignment rules so PRs go straight to an owner instead of sitting in a shared Slack channel.
2. Set daily review blocks: Have the team clear open PRs first thing in the morning and right after lunch before diving into new coding work.
3. Keep PRs small: Break features into focused changes under 250 lines so a teammate can review them in 10 minutes between meetings.

If your review pickup time regularly crosses 4 hours, stop asking developers to code faster. Clear the review queue first so finished code does not sit on the shelf.

Reader Poll

If your codebase contains hundreds of feature flags that were turned on two years ago and never deleted, are you actually controlling release risk or just burying boolean landmines in your production code?

My take: Feature flags are one of the best tools in modern continuous delivery. They let you decouple deployment from release, run safe canaries, and kill a bad rollout in seconds without waiting for a redeploy. But without strict hygiene, flags quickly become one of the most dangerous forms of technical debt an engineering team can carry.

I have seen services where single functions are wrapped in four layers of nested if-else checks with names like enable_new_pricing_v2_final_really. Nobody on the current team knows what happens if an old flag gets accidentally flipped off, which database fields are still safe to read, or how many dead code paths are still being compiled into every build. Testing every possible permutation becomes mathematically impossible, and sooner or later an unsuspecting engineer flips a config switch that resurrects a long-forgotten bug. Feature flags are meant to be temporary scaffolding, not permanent architectural fixtures.

Here is how leaders can actively fix this:

1. Set an expiration date on every flag at creation: Require every feature flag to have a defined sunset date and an assigned owner. If a flag is still active ninety days after reaching 100 percent rollout, treat it as a bug.
2. Pair launch tickets with cleanup tickets: Never mark a product epic as done until the removal pull request is merged and the old conditional logic is completely deleted.
3. Automate stale flag detection in CI: Use static analysis to scan your repository for flags that evaluate to the exact same value across all environments, and surface stale toggles directly in pull request checks.

How disciplined is your team about cleaning up stale feature flags?

• A) Zero dead flags: Flags have strict expiration dates, and cleanup pull requests merge as soon as a feature reaches full rollout.
• B) Occasional spring cleaning: We leave flags around longer than we should, but teams periodically dedicate time to prune old toggles.
• C) Boolean spaghetti: Our code is littered with year-old flags, and tripping over obsolete conditional logic during feature work is common.
• D) Flying blind: Nobody knows which flags are safe to delete, so we leave them all in place out of fear of breaking production.

When your team finishes rolling out a new feature, do you immediately delete the flag and strip out the old code, or do you leave it in place until someone accidentally trips over a dead switch?

Engineering Tip of the Week

Split refactoring and behavior changes into separate pull requests

Bundling code cleanups, renames, and file reorganizations alongside new business logic is the fastest way to hide subtle regressions and turn a ten-minute review into an exhausting slog. Reviewers quickly get fatigued scanning through dozens of cosmetic diffs, drastically increasing the odds that a critical bug slips through unnoticed. Split your changes into two distinct steps instead: ship the refactor first as a standalone pull request with zero functional changes, then layer your new feature on top of the clean foundation. Reviews move twice as fast, root-cause debugging down the road stays painless, and you can roll back a buggy feature in seconds without unraveling your codebase improvements.

Technology Ecosystem Trends

Top Developments/Trends picks for this week Shaping Modern Engineering Efficiency and Operations

Kubernetes becomes the default AI infrastructure layer: Nvidia previewed its own Kubernetes engine, NVKE, built to manage GPU fleets, while Spectro Cloud shipped GPU-enabled VM creation in PaletteAI 1.4, both unveiled at KubeCon NA this week, confirming platform teams now treat Kubernetes as the control plane for AI workloads, not a niche fit. Source

CNCF takes on agent sandboxing as its own problem: Google donated Agent Substrate and gVisor to the CNCF as Sandbox projects, built to resume idle agents in under 500 milliseconds instead of the 20-plus seconds a scaled-to-zero pod needs, a direct fix for agents that sit idle 90 to 95 percent of the time. Source

The cloud growth story reaches past the big three: Cloudflare's Q3 revenue grew 39 percent to $782.5 million with current bookings up 37 percent, proof the AI traffic boom that lifted AWS and Google Cloud last quarter is reaching edge and CDN providers too, not just the hyperscalers. Source

Lean, Hard-Gated Test Automation Replaces Bloated Suites Engineering leaders are aggressively auditing continuous testing pipelines to discard brittle UI test suites and flaky scripts, adopting targeted integration test runners that enforce hard stops on deployment failure. Source

Standardized Agent Protocols (MCP) Break Down Operational Silos Platform and DevOps teams are unifying cross-system operations by exposing CI/CD, Kubernetes infrastructure, and telemetry to agents via the Model Context Protocol, replacing fragmented point-solution bots with governed developer assistants. Source

Telemetry Standardizes Around Zero-Code eBPF and OpenTelemetry Observability stacks are ditching intrusive agent instrumentation in favor of Linux kernel-level eBPF monitoring and stable OpenTelemetry pipelines, offering instant visibility across hybrid workloads without risking app degradation. Source

Patch day is already too late for a growing share of attacks: VulnCheck found 23 percent of newly listed exploited flaws were attacked before their CVE was published, and a Zyxel switch zero-day this week worked against firmware already patched for a different flaw, meaning verifying a patch closes the hole matters as much as applying it fast. Source

AI coding tools are cutting both ways on security: a new Linux Foundation and ActiveState survey of 172 practitioners found AI tools get credit for catching 30 percent of the vulnerabilities teams found this year, yet false positives added 30 percent to workloads and only one in three organizations has a formal security policy covering AI at all. Source

AI labs start buying power plants instead of waiting for them: Anthropic paid $3.4 billion for 1.7 gigawatts of Caterpillar gas generators through a Texas supplier, a deal the Financial Times reported and that remains unconfirmed elsewhere, but one that would be the largest known power-equipment purchase by an AI company and a sign capex is now bypassing utility queues entirely. Source

Washington finally puts a checklist on the cold-chain threat: CISA, the FBI, HHS, USDA and DOT issued a joint advisory telling food, healthcare and transport operators to pull refrigeration controllers off the open internet and segment them onto their own network, the first concrete federal response to weeks of attacks. Source Source

Tools, Resources and Communities | Worth Knowing

Open Source Tools

• DuckDB: An in-process SQL OLAP database management system engineered for fast analytical queries, allowing developers to run columnar analytics across Parquet, Arrow, and CSV datasets directly inside application runtimes without managing a heavy distributed data warehouse cluster. Source
• Redpanda: A high-throughput, Kafka-compatible streaming data platform written in C++ that uses a thread-per-core architecture to deliver deterministic, ultra-low tail latencies and a significantly smaller hardware footprint without JVM garbage collection pauses. Source

Commercial Platforms

• Wiz: A cloud-native security and vulnerability management platform that connects agentlessly across multi-cloud environments (AWS, Azure, GCP) to correlate misconfigurations, exposed secrets, network vulnerabilities, and excessive IAM permissions into an actionable risk graph. Source
• Render: A modern cloud application platform offering a unified developer experience with managed databases, background workers, zero-downtime deploys, and automated preview environments without the operational complexity of managing raw Kubernetes clusters. Source

Learning Resources – Interesting articles

• The Architecture of Open Source Applications (AOSA): A multi-volume reference library dissecting the internal architectures, design trade-offs, and lessons learned behind foundational open-source systems like NGINX, Git, and LLVM, written by the maintainers themselves. Source
• Netflix TechBlog: An industry-shaping technical publication detailing planetary-scale distributed architecture, chaos engineering methodologies, resilient video streaming pipelines, and infrastructure efficiency from Netflix's core platform teams. Source
• A Philosophy of Software Design by John Ousterhout (Stanford Notes & Guide): An architectural reference emphasizing "deep modules" (simple interfaces concealing rich functionality), cognitive load reduction, and pragmatic complexity management in software systems. Source

Deep Dive Article : Shipping Software Into Customer-Controlled Environments

It usually starts with one line in a security questionnaire. Can the product run in our environment, without access to the internet?

For a lot of software companies, that is the first time anyone asks the question seriously. The product has been built, tested and released for years on the assumption that you, the vendor, can see it, reach it and fix it. Then a hospital, a bank, a telecom or a government agency says they will run it themselves, inside their own walls, on their own schedule. And that assumption quietly breaks.

Yes, you can do it. Just not by zipping up your SaaS release process and calling it a day.

Once the customer runs your software, the things that make modern delivery forgiving are gone. You cannot watch it. You cannot log in. A fix does not ship in an hour. What you get instead is a short list of things that must be right before release: a bundle that verifies itself, an installer that checks the environment before it touches anything, upgrades tested from every version you still support, licensing that does not call home, and a way to get diagnostics out when something fails.

I have spent over two decades in System Admin, IT, release engineering, DevOps and platform engineering across companies building products for regulated environments like defense and healthcare. A fair amount of that time was spent on exactly this problem. What follows is what I have seen work, in the order a customer usually meets these challenges.

Three models that get lumped together

People say "on-prem" when they mean three different things. The differences decide almost every design choice that follows.

On-premises means the customer's ops team runs your software in their data center. You usually get outbound-only connectivity, often through a proxy. Updates arrive as downloads or as bundles you send. You can see whatever they choose to share.

Private cloud means the customer's team runs it in their own cloud account or private cluster. You usually get outbound connectivity, sometimes tightly restricted. Updates arrive through registry pulls, chart repositories or bundles. The thing that tends to break first here is cluster policies, storage classes and version skew.

Air-gapped means the customer's team runs it on an isolated network with no connection to you at all. Files move by approved media or a transfer gateway. You see nothing unless they export it. And anything that quietly assumed internet access will break.

Build the packaging for the strictest model you expect to meet, and most of the packaging problems disappear for the other two. The environment problems do not. A private cloud customer will still hit cluster policies and storage classes that an air-gapped build never exercised. A plain on-prem customer will still put you behind a TLS-intercepting proxy.

Start with the bundle, not the installer

The most important thing you will ship is a single, versioned bundle that contains everything needed to install or upgrade. Nothing fetched later.

That means your own binaries, container images, charts or packages, operating system and language dependencies, database migration scripts, default configuration and documentation. Pin container images by digest, not by tag. Include a manifest of everything inside, a checksum for every file & a Software Bill of Materials in a standard format like SPDX or CycloneDX. The security team on the other side will ask for it.

Signing that works with no internet. Sign the bundle, and make sure the customer can verify the signature offline. Two details catch people out. The public key has to reach the customer by a different route than the bundle, otherwise the signature proves nothing. And verification has to work on a machine with no network at all, which rules out anything that checks a transparency log or a revocation list online. Keyless signing flows that call a public log are out. Key-based signatures against a trust root the customer already holds work fine.

Kubernetes customers need a registry story. An air-gapped cluster cannot pull from your registry, and it often cannot pull from anyone's. So the bundle needs the images as archives, plus a loader that pushes them into the customer's private registry, plus charts where the registry host can be rewritten in one value. Skip this and the first thing a cluster operator does with your product is hand-edit image references across forty manifests.

The hidden outbound call. The most common failure at this stage is a call nobody knew was there. Something at install time pulls an image from a public registry, loads a font from a CDN, checks a certificate revocation list, resolves a telemetry endpoint, or asks a license server whether it may start. None of it shows up in your CI, because your CI has internet.

Here is a test worth running. Take a clean virtual machine, block every outbound packet, copy the bundle over the way a customer would, and run the install. Does it finish without anyone editing a file or reading a log to find out what it was waiting for? If not, you have a hidden dependency, and your customer will find it first.

Make the installer check first

On the customer's side, your installer will be run by someone who has never met your engineers. It will run in a maintenance window, often under a change ticket that allows four hours. A failure at hour three, halfway through, with a cryptic message is how you lose a reference customer.

A good installer runs a preflight stage and refuses to continue if it cannot be sure. Operating system and kernel version, CPU architecture, disk space and type, memory, required ports, DNS resolution, time sync, trusted certificates, proxy settings, FIPS or SELinux mode, container runtime, storage classes. Each check should say what it found, what it expected, and what to do about it, in language the customer's operators can act on without calling you.

A few habits pay for themselves. Support a non-interactive mode driven by an answers file, because enterprises automate. Make the installer safe to re-run and resumable after a partial failure. Offer a dry run. Document exactly what it changes on the host. And ship an uninstall that works. The customer's security team will want proof that they can remove the product cleanly before they agree to install it.

Another test worth running: give the installer to an engineer who has never seen the product, on a host that is missing two prerequisites. Can they fix both from the preflight output alone, without a message to your team?

Upgrades are where customers judge you

Installing happens once. Upgrading happens for years, and that is where trust is built or lost.

Customers do not upgrade when you release. They upgrade when their change calendar, their validation process and their appetite for risk allow, which is often much later. At any moment you have customers spread across a range of versions, and each of them expects a path to the current one that works.

A few things to get right. State which versions can upgrade directly to which, and enforce it in the upgrade tool, not in a PDF. Prefer expand-then-contract database migrations, so old and new versions can both run against the schema during the transition. Assume rollback means restore. In a customer environment you usually cannot cleanly undo a migration, so the upgrade should take a backup or insist on one, and the rollback procedure should be tested, not only written down. Plan for partial upgrades. Agents, servers, user interfaces and firmware rarely update at the same moment. Decide how much version skew you support, and test exactly that much. Write release notes for the customer's operator: what changes, what needs downtime, what to check afterward.

There is one upgrade path most teams forget to design: the urgent one. When a critical vulnerability is fixed, a connected customer gets the patch in days. An air-gapped customer gets it when your bundle clears their transfer process, which can take weeks. So decide ahead of time what a security patch bundle looks like, how small it can be, whether it can skip the full test cycle your feature releases go through, and how the customer finds out it exists at all.

Test worth running: pick the oldest version you still support, load it with realistic data, and upgrade to current while killing the process halfway through. What state does the system end up in, and can the operator get out of it without you?

Write the compatibility contract down

Support gets expensive when nobody can say what is and is not supported. Publish a compatibility contract, and keep it short enough that people will read it.

It should cover supported operating systems, kernels, Kubernetes versions, databases, and browser or client versions. Supported upgrade paths and the maximum version skew between components. How long each release is supported, and how much notice you give before dropping a platform. And what "supported" means in practice: tested, or only expected to work.

Then treat the contract as a test plan. Every line is a promise you have to verify. If you cannot test a combination, do not list it. A short, honest matrix beats a long, hopeful one.

Choose any row in your compatibility matrix and ask who last tested it, and when. If the answer is "we think it works," take the row out.

Licensing without a phone home

A license check that needs a server on the internet is the quickest way to break an air-gapped deployment. Teams often find this out late.

Offline licensing generally means a signed license file that encodes the customer, the entitlements and an expiry, verified locally against a public key inside the product. For tighter control, add an offline activation exchange: the product produces a request file, you return a response file, and the customer carries both across the gap. Usage reporting works the same way, as an export the customer chooses to send you.

The design choices matter more than the mechanism.

Fail soft. When a license expires or cannot be verified, warn and degrade long before you stop anything. A hospital or a factory floor should never lose a system at 3 a.m. because a date rolled over.

Expect wrong clocks. Isolated networks often have drifting or manually set clocks, and some are reset on purpose. Do not treat every time anomaly as tampering.

Be careful with hardware binding. It helps for devices. It hurts for virtual machines that get cloned, migrated and restored as routine.

Make renewal boring. Send it far enough ahead that the customer's own approval process can finish.

Do not design the license system for the customer you are afraid of. Design it for the honest one running a 24/7 operation, and deal with the rest commercially.

Test worth running: set the system clock a year forward, then back two years, on a running install. Does the product warn and keep working, or does it lock the customer out?

Support when you cannot log in

In SaaS, debugging means looking at logs and metrics. In a customer-controlled environment, you may get a screenshot and the words "it does not work." Build the support path into the product, on purpose.

Ship a single command that creates a support bundle: versions, configuration with secrets removed, system information, recent logs and health checks. The customer should be able to read it before sending it. That also helps it get past their security team.

Make sure logs carry a version, a component name and a correlation ID, so one failing request can be followed across services. Offer a diagnostic mode that can be switched on temporarily and visibly switches itself off again. If you build in telemetry, make it opt-in and documented line by line. Replace it with an exportable file wherever no connection is allowed.

Remote access should be something the customer starts. It should be time-limited and logged, and it should go through whatever they already approve: their jump host, their VPN, or a screen share where their admin does the typing.

Write the runbooks for the customer's operations team, not for your own engineers. They know their network and their tooling far better than you do. They do not know your architecture, and they should not have to.

Test worth running: break something on a test install, then hand a colleague only the support bundle. Can they identify the failing component and the version it was running without asking a single question?

Testing an environment you cannot see

This is the hard part, and it is mostly discipline rather than tooling. You cannot reproduce the customer's environment. You can reproduce its hostility.

Build a lab, or a set of CI environments, that behaves like the worst networks and hosts you expect to meet. No outbound internet, or internet only through a proxy. A proxy that intercepts TLS and re-signs traffic with a private certificate authority. Private certificate authorities, short certificate lifetimes, drifting clocks. FIPS mode, SELinux or AppArmor enforcing, read-only filesystems. Older operating systems and kernels than you would choose. Strict Kubernetes policies, odd storage classes, IPv4-only networks, restricted DNS. Slow disks, small machines, data left behind by older versions.

Three rules for using the lab.

First, test the thing you ship. Run the install from the real, signed bundle, transferred and verified the way a customer would do it. Not from a CI shortcut.

Second, test upgrades from every supported version, with data that has lived through the previous versions. Interrupt some of them partway to see what state they leave behind.

Third, turn every escalation into a test. Each time a customer environment surprises you, add that profile to the lab so it cannot surprise you twice. After a few years the lab becomes a record of the real world.

For your first few customers, a design partner is worth more than any amount of lab work. Find a customer willing to run a release candidate in their own environment and give you honest feedback, and hand them a short acceptance checklist they can run themselves.

Test worth running: list your last five customer escalations. For each one, is there now an automated test that would have caught it? Every "no" is a surprise you have agreed to have again.

If you also ship devices

Everything above applies, plus a few extras.

Updates should be signed and verified on the device. Use A/B partitions or a similar mechanism that can return to the last good image if a boot fails. Define which firmware versions work with which companion software, because the two never update together. And plan for the update being applied in the field by someone who is not an engineer, possibly under a regulatory change-control process.

For medical and other regulated devices, expect questions about Software Bills of Materials, patching cadence and vulnerability handling. Have documented answers ready before the customer's security team asks.

The regulatory angle

This is not only good practice any more. Customer-run software is exactly where regulators have started to look, because a vendor that cannot patch quickly or say what is inside its product is a risk to everyone downstream.

In the EU, the Cyber Resilience Act (Regulation (EU) 2024/2847) applies to products with digital elements, and where the software runs does not change that. Reporting duties for actively exploited vulnerabilities and severe incidents started on 11 September 2026, with an early warning due within 24 hours. The remaining requirements, including technical documentation and Software Bills of Materials, apply in full from 11 December 2027.

Notice what that does to an air-gapped customer base. If you have to report within 24 hours, you also need a way to get a fix, or at least a mitigation notice, to customers you have no connection to. That is the urgent-patch path from the upgrades section, with a legal deadline attached.

In the US, federal buyers lean on NIST's Secure Software Development Framework (Special Publication 800-218), and device makers face premarket expectations from the FDA, set out in its Source.

The direction is the same everywhere: know what you ship, say what is inside it, and have a plan to patch it that actually works when the customer controls the environment.

Where to start

If you are looking at all of this and thinking "we are not ready," that is common. Most teams whose product grew up as SaaS are not ready. It is fixable, and the order matters more than the completeness.

1. Get an install working from one bundle with outbound traffic blocked. That alone surfaces most of the surprises, and everything else builds on it.
2. Add the preflight checks and the support bundle. They lower the cost of every other problem you will have.
3. Build the upgrade test matrix and write the compatibility contract from what you can verify.
4. Sort out licensing, signing and the urgent-patch path. These go quickly once the bundle exists.
5. Keep going. The hostile-environment lab, the customer runbooks, a design partner.

A readiness checklist

I will leave you with this. Answer these honestly. Each "no" is a place a customer will find the problem before you do.

1. Can you install from one signed bundle on a machine with no internet access?
2. Do you know every outbound connection the product makes at install time and at runtime?
3. Does the installer check the environment before it changes anything, with messages an operator can act on?
4. Can a customer verify the bundle's signature and contents offline?
5. Is there a published list of supported upgrade paths, enforced by the tooling?
6. Have you tested an upgrade from every supported version, including an interrupted one?
7. Do you have a defined path for getting an urgent security patch to a customer with no connection to you?
8. Does the license work offline, and does it fail soft?
9. Can the customer produce a support bundle with one command and review it before sending?
10. Do you test behind a TLS-intercepting proxy and with a private certificate authority?
11. Does every customer escalation become a test case?

If you answered "no" to more than a few, you are in good company. The question is what you do next.

We at Stonetusker, help engineering teams at Series B to D scale-ups and enterprises get their delivery side right. If you are weighing whether your team is ready for an on-prem or air-gapped customer, or you already ship into customer environments and keep getting surprised, I would be happy to talk it through.

Technology Ecosystem Weekly News Digest – Top Picks

Cloud and Platform News

AWS this week:

• A new Nitro Sandboxes capability brings hardware-isolated pods, tasks and VMs to EKS, ECS and EC2, giving multi-tenant platforms a harder isolation boundary than a shared kernel. Source
• EKS Auto Mode and Karpenter now support Dynamic Resource Allocation, so Kubernetes workloads can request GPUs and other specialized hardware on demand instead of through fixed device counts. Source
• Security Hub now rolls up an organization-wide software bill of materials for EC2, ECR and Lambda, built on Inspector's SBOM data and included free in Security Hub Essentials, a real step up for supply-chain visibility. Source
• Amazon OpenSearch Service added managed cross-region disaster recovery and the ability to validate and roll back version upgrades, closing two long-standing operational gaps at once. Source
• AWS Marketplace will now auto-convert SaaS free trials to paid subscriptions unless a buyer cancels first, a quiet billing change procurement teams should flag internally before it surprises a budget. Source

Azure this week:

• Azure Functions reached general availability for .NET 11, giving teams modernizing older .NET workloads a fully supported serverless target. Source
• AKS added managed Dynamic Resource Allocation for GPU and RDMA node pools, made Fleet placement controls generally available across clusters, and added health gates that pause an upgrade automatically if cluster or workload health drops. Source
• Support for .NET 8 and .NET 9 on Azure Static Web Apps ends November 10, so anyone still running those runtimes there needs a migration plan now, not later. Source
• Azure Front Door's TLS key exchange policy now supports post-quantum cryptography in general availability, one of the more concrete PQC-readiness moves from a major cloud this year. Source
• WAF Insights for Application Gateway reached general availability, giving teams visibility into which firewall rules are actually firing instead of guessing from logs. Source

Google Cloud this week:

• GKE capacity buffers reached general availability, letting platform teams pre-provision headroom for scaling events instead of racing the autoscaler during a spike. Source
• Cloud Run added a Vulnerability Assessment feature in public preview, scanning container images for known flaws as part of the deploy path instead of as a bolted-on step. Source
• Model Armor's image screening moved to general availability, extending Google's AI guardrails past text to catch unsafe or malicious image inputs and outputs. Source
• Agent Registry added skill security scanning in preview and made standalone skills generally available, treating "what can this agent actually do" as its own security surface. Source
• Cloud SDK 593.0.0 shipped breaking changes to App Lifecycle Manager flags, so anyone with gcloud CLI automation or IaC pipelines should check their scripts before the next upgrade. Source

Broadcom is giving VMware shops a cheaper on-ramp and an AI quickstart. VMware Cloud Foundation now includes automated day-zero setup for private AI environments, wiring up vCenter, vSphere Supervisor and VMware Kubernetes Service in one workflow, plus multi-tenant model sharing meant to cut GPU requirements. Broadcom also launched a new entry-level vSphere Express edition, capped at 128 cores but still including vMotion, HA and vTPM. Pricing wasn't disclosed and some of this is still rolling out, but it reads as a real response to customers who felt priced out after the VMware acquisition. Source Source

Databricks this week: Pages hit general availability, giving teams a governed place in Unity Catalog to define business terms and metrics for AI agents. Genie ZeroOps entered beta as a background agent that watches data pipelines, diagnoses failures, and suggests code fixes. Feature Views are now on by default for workspaces using the compliance security profile, and teams can start writing custom service policies in Python while that feature is in beta. Source Source Source

Oracle Cloud Infrastructure bundled a round of database operations upgrades. OCI's Database Management and Ops Insights tools picked up privilege-use analysis, GoldenGate deployment monitoring, SQL job templates, reusable metric-extension templates and a unified onboarding flow for the two products, alongside AWR snapshot collection and SQL monitoring reports. It's Oracle's own release notes rather than independently confirmed news, but the changes are specific enough to matter to anyone running production databases on OCI. Source

Open-Source and Linux Ecosystem News

CNCF and Kubernetes this week:

• KubeVirt, the project that runs virtual machines on Kubernetes, reached CNCF Graduated status, the foundation's highest maturity tier, with production users including ByteDance, Cloudflare, CoreWeave and Nvidia. Source
• Istio's ambient-mode service mesh added general availability for multi-network and multi-cluster support, letting platform teams run active-active workloads across clusters spanning different networks, regions and clouds. Source Source
• NATS, the lightweight cloud-and-edge messaging system, also reached Graduated status after a third-party security audit, with more than 2,000 companies, including Nvidia, Walmart and Mastercard, listed as users. Source
• CloudNativePG, a from-scratch Kubernetes operator for running PostgreSQL, moved up to CNCF Incubating status, with more than 50 named production adopters including IBM, Google Cloud and Tesla. Source
• KubeRay, the toolkit for running Ray's distributed machine learning workloads on Kubernetes, was donated to the CNCF, putting the last major piece of the PyTorch-Ray-Kubernetes AI stack under Linux Foundation governance. Source
• Nvidia contributed OpenShell, a runtime that enforces policy-based limits on what autonomous AI agents can actually do, to the CNCF Sandbox, with engineers from Red Hat, Docker and Canonical also named as core contributors. Source

OpenTelemetry's JavaScript SDK hit version 3.0. A major version bump for one of the most widely used Node.js instrumentation libraries usually means breaking API changes, so teams instrumenting Node services for observability should check their dependencies before the next upgrade rather than after something breaks in production. Source

Linux 7.3 confirmed as the 2026 Long-Term Support kernel: Greg Kroah-Hartman confirmed that the 7.3 branch, rather than December's 7.4 release, will serve as the annual LTS baseline. Embedded teams building board support packages for 2027 products can lock onto 7.3 now instead of waiting through the year-end merge window. Source

DevOps, Platform Engineering and SRE News

Red Hat ships OpenShift 5 with built-in MCP server, OpenTelemetry pipelines, and GitOps source hydrator: Red Hat released OpenShift 5 featuring a role-based Model Context Protocol (MCP) server and gateway so AI tools can inspect cluster state and pipeline runs safely under Kubernetes RBAC rules. The update also transitions OpenShift Pipelines metrics and tracing to OpenTelemetry and introduces a GitOps source hydrator that pre-renders Helm and Kustomize manifests into Git for clean diff reviews. Source

Linux Foundation launches Agent Name Service (ANS) for DNS-based agent identity: Supported by Cloudflare, Cisco, DigiCert, GoDaddy, and OWASP, the Linux Foundation formalized the Agent Name Service specification to handle AI agent registration and verification over standard DNS and TLS certificates. Platform engineers get an open, vendor-neutral way to verify which organization owns an autonomous agent before allowing it to interact with internal APIs. Source

Broadcom is pushing to make virtual machines first-class Kubernetes citizens instead of legacy baggage. It donated a new Virtual Machine API to the CNCF as a sandbox project and helped launch a CNCF Workload Conformance Working Group built around its Sonobuoy diagnostic engine, aimed at a real portability standard for Kubernetes workloads. The timing isn't subtle: a Linux Foundation survey the group cited found VMs still make up 53 percent of production applications, and a third of respondents expect their VM footprint to grow because of AI workloads, right as Broadcom's VMware licensing changes push some platform teams to reconsider their stack. Source

Security and DevSecOps News

OpenAI details automated AI pipeline for finding and patching Linux kernel flaws: OpenAI shared technical findings from an automated security pipeline that discovers Linux vulnerabilities, builds proof-of-concept exploits, and generates candidate patches. Iterative variant testing proved essential to stop initial AI patches from introducing performance regressions or missing related edge cases. Source

GitHub Secret Scanning expands to GitHub Actions workflow logs: GitHub launched a public preview of secret scanning for GitHub Actions workflow logs to catch leaked API keys and cloud tokens printed during CI builds. Findings appear directly in the repository's secret scanning alert list with automated validity checks, even after the logs are deleted. Source

Git fixed a flaw that turns a routine clone into remote code execution. CVE-2026-111760 lets an attacker replace a submodule's .git file with a symlink pointing at a malicious hooks directory, so cloning a booby-trapped repository with submodules can run the attacker's code. Git 2.56.1 and backports down to 2.50.2 carry the fix, and GitHub has already patched github.com itself, though fixes for GitHub Desktop, Copilot and Actions were still pending at disclosure. Until patched, don't recursively clone repositories you don't trust. Source

AI/ML and Agentic AI News

PyTorch ships an ExecuTorch WebGPU backend for browser inference: PyTorch published a WebGPU backend for ExecuTorch that runs quantized neural networks natively on client GPUs inside web browsers. Developers can now ship local inference features without paying server-side GPU bills or hitting WebAssembly performance limits. Source

Google releases Gemini 4 Carbon for long-horizon agentic coding: Google launched Gemini 4 Carbon with a 1-million-token context window, configurable thinking depth levels, and background execution for outputs longer than 64,000 tokens. Early developer tests showed strong results on multi-file debugging, legacy API maintenance, and automated refactoring. Source

Anthropic launches Claude Fable 5.2 and Mythos 5.2: Anthropic released Claude Fable 5.2 with adaptive thinking, a 1-million-token context window, and 30 percent faster output speeds than version 5.1 at lower token prices. Engineering teams can run Fable 5.2 as an orchestrator that coordinates hundreds of subagents across monorepos or consult it as an advisor model during complex debugging. Source

Meta introduces Muse Ember 1.0 for low-cost agent subtasks: Meta released Muse Ember 1.0, a lightweight model built for high-volume agent operations such as reading files, running tests, and making targeted code fixes. With a 1-million-token context window and pricing starting at $0.10 per million input tokens, it helps teams cut inference bills in multi-agent coding setups. Source

Thinking Machines Lab released its second open-weight model. Inkling 2 Small is a 594 billion parameter mixture-of-experts model with image input, available now through the company's Tinker platform, with a fully open Apache 2.0 release planned for the following week pending safety review. The lab's own benchmarks put it competitive with, though trailing DeepSeek's V4.1 Flash on, several coding tasks, giving teams evaluating self-hostable alternatives to closed frontier models another real option. Source

Embedded Systems and IoT News

Siemens introduces the HyperLynx Agentic Toolkit for board verification: Built on the HyperLynx platform, this toolkit combines physics-based simulation with natural language agent workflows to automate signal integrity checks and result analysis. Hardware and firmware teams working on high-speed interconnects can spot layout bottlenecks faster without manually scripting complex verification runs. Source

Texas Instruments adds agentic AI workflows to Code Composer Studio: TI updated its CCStudio IDE and VS Code extension with Model Context Protocol (MCP) servers that feed hardware context, SDKs, and pin data directly to AI agents. Engineers can automate device migration, peripheral setup, flashing, and debugging in plain language, cutting legacy code migration timelines from months to days. Source

STMicroelectronics launches a unified STM32 microcontroller platform: Announced at the STM32 Summit, this unified architecture lets engineering teams reuse IP, software stacks, and development tools across automotive, industrial, and robotics lines. ST also introduced beta agentic coding features that feed STM32-specific context to AI tools to improve code accuracy and lower token overhead. Source

Renesas debuts the cloud-based Xplore Developer Hub: Expanding its Renesas 365 platform, the new browser-based workspace gives teams instant access to IDEs, evaluation boards, and over 100 validated software building blocks without local setup. Teams can share real-time progress and reuse pre-tested modules for BLE, NFC, and power management across different hardware projects. Source

Closing Note

This week's issue looks at the challenges of delivering software beyond environments that engineering teams fully control. As more enterprises ask vendors to run software in their own data centres, private clouds and isolated networks, release engineering has to account for a different set of operational requirements.

The deep dive examines what it takes to ship software into customer-controlled environments. From offline installation and signed release bundles to upgrade management, licensing, security patches and diagnostics, it covers the engineering practices needed to make these deployments reliable over the long term.

Across this week's technology updates, there are several developments worth watching, from Kubernetes and cloud infrastructure to agentic systems, open-source platforms, software supply-chain security and embedded systems. The common thread is the need for stronger engineering practices as software environments become more demanding.

If you want to understand where your engineering delivery system needs improvement, start with TuskerGauge. It is a free assessment covering CI/CD, testing, infrastructure, security, observability, SRE and engineering practices.

Find the gaps in your engineering delivery system

Already know where the bottlenecks are? Tusker90Pro helps turn those findings into a practical 90-day improvement roadmap focused on delivery flow, reliability, release management and engineering operations.

Build your 90-day improvement roadmap

The goal is to build a delivery system that works reliably, whether software runs in your own cloud, a customer's infrastructure or an environment with no internet access.

If you are dealing with a specific engineering delivery challenge, write to contact@stonetusker.com. We can discuss the problem, the constraints and practical ways to address them.