🔥 Top Story
Specification-driven composition for flexible data workflows
AWS's Architecture blog addresses a common scalability bottleneck that emerges as data pipelines grow. Pipelines usually start as simple scripts, but as they scale, transformation logic gets duplicated across multiple workflows, and even a small change can cascade unpredictably across many of them. The post proposes "specification-driven composition" as a way out: instead of hard-coding transformation logic separately in each workflow, teams define transformation rules as declarative specifications that can be composed into different workflows. That separation means a logic change happens in one place and propagates consistently to every workflow built from it. The approach targets data engineering teams whose maintenance burden grows faster than their pipeline count as systems scale. It's presented as a reusable architectural pattern rather than a specific new AWS service launch.
💡 Why it matters: Teams whose pipeline count keeps growing faster than their ability to safely change shared logic should consider separating transformation specs from workflow code to contain duplication and blast radius.
🔗 Read more · AWS Architecture
Kubernetes & Cloud Native
Navigating the ingress-NGINX retirement
CNCF
Kubernetes SIG Network and the Security Response Committee have announced the retirement of the community-maintained ingress-nginx controller (the kubernetes/ingress-nginx repository), and this post lays out how to prepare. Best-effort maintenance continues until March 2026, after which there will be no further releases, bugfixes, or security patches of any kind. The post clears up a common misconception: it's the community ingress-nginx controller that's retiring, not the Kubernetes Ingress API itself, and the separately maintained NGINX Ingress Controller from F5/NGINX Inc. (a different codebase, open-source and commercial editions) is unaffected. The retirement stems from chronic maintainer shortage, for years the project ran on one or two volunteers working after hours, compounded by flexibility features like the "snippets" annotations that were once considered helpful but are now viewed as serious security risks. SIG Network and the Security Response Committee are urging all ingress-nginx users to begin migrating to Gateway API or another ingress controller immediately. Teams still running ingress-nginx in production need a migration plan in place before March 2026.
💡 Any team running ingress-nginx in production needs a Gateway API (or alternative controller) migration plan now, since security patches stop entirely after March 2026.
Migrate Amazon EC2 to EKS Auto Mode using Kiro CLI and MCP servers
AWS Containers
This AWS Containers blog post walks through a practical migration scenario: moving a Node.js web application running on EC2 instances into a highly scalable, containerized service on EKS Auto Mode. The centerpiece is using AWS's recently introduced Kiro CLI together with MCP (Model Context Protocol) servers to automate the process, Kiro CLI is a command-line tool that provisions infrastructure, deploys applications, and manages resources through natural-language-driven commands. The fully managed Amazon EKS MCP server provides secure, authenticated access to AWS services and guides users through cluster creation, automatically provisioning prerequisites and applying AWS best practices along the way. During development, it offers high-level workflows for application deployment and cluster operations, reducing the complexity of working directly with EKS and Kubernetes. AWS published a companion sample implementation on GitHub that reproduces the actual Node.js migration described in the post. The broader point is that AI-assistant-driven tooling that can execute infrastructure commands directly is aimed at compressing migration timelines and reducing configuration-error risk.
💡 Teams planning an EC2-to-EKS migration should pilot the Kiro CLI + EKS MCP server combo to see how much manual configuration work it actually removes before committing to a full rollout.
AI & ML
GPT-5.6 is now the preferred model in Microsoft 365 Copilot
OpenAI
OpenAI announced that GPT-5.6 is now the preferred model powering Microsoft 365 Copilot. As a result, Copilot features across Word, Excel, PowerPoint, Copilot Chat, and Cowork are described as gaining stronger AI capabilities for faster, higher-quality output. The announcement lines up with GPT-5.6's broader global rollout to app and API users on Thursday, underscoring how central OpenAI's models remain within the Microsoft ecosystem. The post doesn't cite specific benchmark numbers for the Microsoft 365 integration itself, instead emphasizing general quality and speed improvements across office workflows like document drafting, spreadsheet analysis, and presentation building. For organizations already on Microsoft 365 Copilot, this effectively means an automatic model upgrade with no action required on their part.
💡 Since the model swap happens automatically behind Copilot with no configuration needed, organizations using Microsoft 365 Copilot should notice a real quality shift in document and spreadsheet automation output.
ChatGPT is now a partner for your most ambitious work
OpenAI
OpenAI unveiled "ChatGPT Work," describing it as "a partner for your most ambitious work." According to OpenAI, ChatGPT Work is an agent that can take real action across a user's apps and files, staying with a single project for hours at a time if needed, and turning a stated goal into finished output rather than just answering questions about it. It's built on Codex technology and connects to third-party services including Slack, Microsoft Teams, Google Drive, SharePoint, calendars, and CRM tools to pull in data and invoke the tools a task requires. Like Claude Cowork, it supports recurring, scheduled execution through a "Scheduled Tasks" feature, letting users automate work that repeats on a regular cadence. The core shift here is moving ChatGPT beyond a question-answering chatbot into something that carries out long-running, project-style work on a user's behalf. Together with the Codex/Atlas consolidation, this positions OpenAI's product line as a direct, general-purpose competitor to Claude Cowork.
💡 As both OpenAI and Anthropic now field agents built for hours-long project work, teams choosing a work-automation tool should compare them on connector coverage and how reliably scheduled tasks actually run.
GPT-5.5 Bio Bug Bounty
OpenAI
OpenAI introduced a "Bio Bug Bounty" program aimed at strengthening its safeguards against biology-related misuse in GPT-5.5. The program invites researchers with experience in AI red-teaming, security, or biosecurity to find a single "universal jailbreak" prompt capable of getting the model to answer all five of its predefined bio-safety test questions without moderation intervening, from a clean chat. The scope is limited to GPT-5.5 running in Codex Desktop, and the reward for a successful universal jailbreak was raised from $25,000 to $50,000. Participation runs through application and invitation, with priority given to a vetted list of trusted bio red-teamers, and every prompt, completion, finding, and communication is covered by an NDA. The program has since evolved into an ongoing, private "OpenAI Bio Bounty Program" that targets universal jailbreaks against OpenAI's frontier models going forward, starting with GPT-5.6. It signals OpenAI's push to make external adversarial testing of bio-risk safeguards a standing part of how it ships frontier models, rather than a one-off exercise.
💡 Turning bio-risk safeguard testing into a standing, $50k-bounty external red-team program signals that internal-only safety testing is no longer seen as sufficient for frontier models.
SensorFM: Towards a general intelligence and interface for wearable health data
Google Research
Google Research introduced SensorFM, a foundation model aimed at providing general-purpose intelligence and an interface for wearable health data. It's pre-trained on more than one trillion minutes of multimodal sensor signals collected from five million consented participants, learning a single, reusable representation of human physiology that spans cardiovascular, metabolic, sleep, and mental health as well as lifestyle and demographic factors. By co-scaling model size and data together, SensorFM produces a general representation that transfers to 35 different health prediction tasks and supports label-efficient adaptation plus data infilling for gaps in sensor streams. Google says the model can also serve as a grounding tool for a "Personal Health Agent." It builds on Google's earlier SensorLM, a related model trained on 59.7 million hours of Fitbit and Pixel Watch data that translates raw sensor readings into natural language, SensorFM goes further by targeting prediction and adaptation across a broad task set rather than just language translation of sensor data. Google frames this as infrastructure for a future generation of digital health coaches, clinical monitoring tools, and natural-language wellness applications built on wearable data.
💡 For teams building health or wearable products, a broadly pre-trained representation model like SensorFM could mean adapting to a new prediction task with a small labeled dataset instead of training a model from scratch each time.
Cloud Updates
Safely run AI-generated code in Cloud Run sandboxes
Google Cloud
Google Cloud opens this post with a question it says it hears often from customers: how do you safely run AI-generated code or untrusted binaries without putting your host application, data, and cloud credentials at risk? Its answer is Cloud Run sandboxes, now in public preview, which let you execute untrusted code or agent tools in an isolated environment inside Cloud Run's second-generation execution environment. Rather than spinning up a separate instance, the sandbox runs within the same instance as your existing container and shares its allocated CPU and memory, which keeps it optimized for low latency. The feature directly targets the growing need to run untrusted code as AI agents move into production, chatbots with code interpreters, services that execute user-uploaded scripts, or agentic apps that need to immediately run LLM-generated code. The main value proposition is adding an isolation layer to an existing Cloud Run service without having to build and operate separate sandboxing infrastructure. Google offers a related but separate isolation technology for Kubernetes workloads, the gVisor-based GKE Agent Sandbox, reflecting a broader push to harden AI workload isolation across both Cloud Run and GKE.
💡 Teams that need to run AI-agent-generated code in production can now add an isolation layer directly to an existing Cloud Run service instead of standing up separate sandboxing infrastructure.
Solve harder problems with AlphaEvolve, now available to everyone on Google Cloud
Google Cloud
Google Cloud announced that AlphaEvolve, its code discovery and optimization agent, is now generally available on the Gemini Enterprise Agent Platform. AlphaEvolve pairs the creative problem-solving of Gemini models with automated evaluators that verify results against a "ground truth" the user defines, plus an evolutionary framework that keeps improving the most promising candidates. When new code outperforms the current version, it becomes the parent for the next generation, and this feedback loop lets the system discover algorithms significantly more efficient than the ones it started with. Google says it uses AlphaEvolve to make its own infrastructure more efficient, and customers are applying it to improve machine learning models, accelerate drug discovery, and optimize supply chains and warehouse design. Cited examples include Klarna doubling the training speed of one of its largest transformer models while improving quality, Substrate achieving a multi-fold runtime speedup in its computational lithography framework, WPP gaining 10% accuracy improvements in advertising, and Schrödinger reaching roughly a 4x speedup in training and inference for machine-learned force fields. Previously limited to select users, AlphaEvolve's move to general availability lowers the barrier for any organization where optimization is a core bottleneck to try it directly.
💡 Teams whose bottleneck is optimization, model training speed, supply-chain planning, compute-heavy simulation, can now try AlphaEvolve's evolutionary code-improvement loop directly, without a dedicated research team.
Why we cannot wait for better post-quantum signature algorithms
Cloudflare
NIST is currently advancing nine new post-quantum signature algorithms through a third standardization round as candidates for future adoption. In this post, Cloudflare walks through each of the nine candidates and argues that, while they show real promise, waiting for a "better" algorithm to emerge is the wrong call given they're all still in development. Instead, the post's core argument is that organizations should adopt ML-DSA now, the best post-quantum signature option currently available for real deployment. This builds on NIST's earlier work finalizing its first post-quantum signature standards, of which ML-DSA is already part, and reflects Cloudflare's operational urgency as a company that has to actually migrate TLS certificate and signing infrastructure ahead of the quantum computing threat. The piece reads as a direct warning to organizations tempted to delay migration while waiting for smaller or more efficient signature schemes to mature. Its bottom line: don't wait for the perfect algorithm, start migrating to the validated one that exists today.
💡 Organizations delaying their post-quantum migration should stop waiting for a "better" algorithm and start moving TLS and signing infrastructure to the already-standardized ML-DSA now.
Autopilot Clusters with GKE managed DRANET: GPUs and TPUs
Google Cloud
This Google Cloud post explains that GKE-managed DRANET now supports both GPUs and TPUs, and walks through using it on both standard clusters (where you control the details) and Autopilot clusters (where Google handles the underlying configuration). Managed DRANET lets you request and allocate networking resources for your pods, including network interfaces that support TPUs and RDMA (Remote Direct Memory Access). To enable managed DRANET on an Autopilot cluster, you need to set up a VPC, enable Dataplane V2, and use the rapid release channel, which is required for managed DRANET support on Autopilot. Mechanically, GKE Autopilot reads a ComputeClass to provision the right node type and configure managed DRANET networking, with the resource claim acting as the bridge that binds pods directly to the GPU or TPU accelerators on those nodes. In practice, this means teams running large-scale GPU/TPU training or inference workloads get accelerator networking automated by Autopilot without having to hand-tune the underlying infrastructure.
💡 Teams running large-scale GPU/TPU training on GKE Autopilot can offload accelerator network interface configuration to managed DRANET instead of hand-tuning it themselves.
Introducing Red Hat OpenShift Service Mesh 3.4
Red Hat
Red Hat announced that OpenShift Service Mesh 3.4 is now generally available for use with Red Hat OpenShift and Red Hat OpenShift Platform Plus. This Istio-based service mesh has been moving toward a lighter, sidecar-less architecture across its 3.x releases, having brought ambient mode, ztunnel, and waypoint proxies to general availability in earlier versions along with improved network traffic visibility in the Service Mesh Console plugin. 3.4 continues that trajectory as a minor release, though the announcement itself focuses on confirming general availability and supported platforms rather than enumerating specific new capabilities. The exact list of new features and changes in 3.4 would need to be checked against the release notes, since this post alone doesn't detail them. For organizations already running Service Mesh on OpenShift, the update to a newly GA'd supported version is a natural trigger to plan an upgrade.
💡 Teams running Istio-based Service Mesh on OpenShift should check the 3.4 release notes for exact changes before scheduling an upgrade to the newly GA'd version.
From automatic CI/CD to autonomous agentic workflows: Continuous AI with Red Hat OpenShift
Red Hat
This Red Hat blog post addresses a common gap between promise and reality: teams are told AI tools will speed up delivery and improve code quality, but in practice the volume of code changes surges and existing systems and processes can't keep pace, creating a new bottleneck. Its answer is "Continuous AI", evolving from automated CI/CD toward autonomous agentic workflows, with Red Hat OpenShift proposed as the platform to run it on. Related Red Hat Developer posts explain why CI/CD matters even more for agentic systems: because they rely on nondeterministic LLMs, and evaluation runs carry a real token cost, about $0.64 per evaluation run with a frontier model in one measured example, which is why hosting a model as a service on OpenShift AI is suggested as a way to turn that variable cost into fixed infrastructure spend. The broader material also points to platform-agnostic frameworks, such as cicaddy, that let teams build agentic workflows directly inside an existing CI pipeline without standing up a separate agentic platform. The core message is that adopting AI coding tools isn't the hard part, building the CI/CD and governance capacity to absorb the resulting surge in changes is what actually determines whether productivity improves.
💡 Organizations seeing a surge in code changes from AI coding tools should first shore up the CI/CD and governance capacity, and evaluation cost model, needed to absorb that volume, not just adopt more tooling.
DevOps & Infrastructure
Meta debuts Muse Spark 1.1 and it isn’t free
The New Stack
On Thursday, Meta rolled out Muse Spark 1.1, a major update to its AI platform, and for the first time made it a paid API rather than a free download. The new Meta Model API launched in public preview for US developers with metered, pay-as-you-go pricing: $1.25 per million input tokens, $4.25 per million output tokens ($0.15 for cached input), plus $20 in free credits for new accounts. That output pricing undercuts rivals like Anthropic's Opus 4.8, OpenAI's GPT-5.5, and Fable 5, which charge $25-$50 per million output tokens, making Muse Spark roughly six times cheaper on a sticker-price basis. Muse Spark 1.1 is a multimodal reasoning model from Meta Superintelligence Labs built for agentic tasks, and its aggressive pricing is read as Meta's opening move into the crowded AI coding/agent market. Web Search Grounding is billed separately at $2.50 per 1,000 queries. The launch marks a notable shift for a company that had leaned heavily on free, open-weight models until now.
💡 With Meta undercutting rivals on output-token pricing by up to 6x, teams running agentic or coding workloads now have a meaningful new cost baseline to benchmark against.
OpenAI is folding Codex into the ChatGPT app — and taking aim at Claude Cowork
The New Stack
Alongside the GPT-5.6 launch on Thursday, OpenAI folded Codex and Atlas into a single ChatGPT desktop app and introduced "ChatGPT Work," a new agent explicitly positioned against Claude Cowork. Built on Codex technology, ChatGPT Work can kick off or directly produce complex agentic work involving documents, spreadsheets, and other assets, pulling in data and invoking tools from Slack, Microsoft Teams, Google Drive, SharePoint, calendars, and CRM services. Like Cowork, it supports scheduled, recurring execution via a feature also named "Scheduled Tasks." Within the unified app, Codex keeps its own dedicated coding experience alongside Chat and Work, gaining inline diff editing, a side-panel pull request review flow, faster Computer Use powered by GPT-5.6, and multi-repository project support. OpenAI is also extending Codex, previously desktop, CLI, and web only, to the ChatGPT mobile app on iOS and Android. Taken together, the moves push Codex from a coding-only tool into a general-purpose work agent that competes directly with Claude Cowork.
💡 With Codex expanding from a coding tool into a Cowork-style work agent, teams evaluating agentic productivity tools should compare the two products' connector coverage and integration depth side by side.
OpenAI’s GPT-5.6 is now live
The New Stack
As expected, OpenAI made its GPT-5.6 family of models available globally to app and API users on Thursday. For the first time, it launched three distinct versions simultaneously: Sol, the flagship model built to rival Anthropic's Fable 5; Terra, a balanced, lower-cost tier; and Luna, the fastest and cheapest option. OpenAI says Sol comes within about a percentage point of Fable 5's quality while costing roughly half as much and running in a little over half the time. Agentic capabilities are also expanded, the model can now write and run lightweight programs to coordinate tools, process intermediate results, and choose its next action mid-task, cutting token use and model round-trips on tool-heavy work. For users willing to burn more tokens for better results, a new "Ultra" mode dispatches four agents in parallel, comparable to Anthropic's "ultracode." Access is tiered by plan: Free and Go users get Terra, Plus/Pro/Business/Enterprise users can choose among Sol, Terra, and Luna with adjustable reasoning effort, and Pro/Enterprise users additionally get Sol Pro for the highest-quality results on complex tasks.
💡 With GPT-5.6 claiming near-Fable-5 quality at half the cost plus a parallel-agent Ultra mode, teams optimizing for model cost and latency should re-check which tier their plan actually grants access to.
How GitHub gave every repository a durable owner
GitHub
The post starts from a stark internal problem: GitHub had more than 14,000 repositories, but fewer than half had a clearly identified owner. Repositories tied to production services had long had solid ownership tracking, but for the rest, those not attached to any specific service, there was no reliable way to determine who was responsible. GitHub's security team says it addressed this by giving every active repository a validated owner within 45 days and archiving the rest. Key lessons from the effort include enforcing ownership at the moment a repository is created, making ownership properties required rather than optional, building a grace-period workflow to bring existing repositories into compliance, and designing guardrails for edge cases like bad data sources or missed notifications. That ownership data then became the foundation for downstream security automation, vulnerability alert routing, access control, and incident response. It's a concrete illustration of how much security risk accumulates when a large organization can't answer the basic question of who owns a given repository.
💡 Enforcing repository ownership as a required property at creation time, not after the fact, is what makes downstream security automation like vulnerability routing and access control actually work at scale.
Business intelligence plugins for Grafana: A support update
Grafana
In January, Grafana Labs took over maintenance of the business intelligence (BI) plugins originally built by Volkov Labs and committed to a six-month maintenance window. This post announces that Grafana Labs is extending that commitment through the end of 2026. For users who have BI plugins wired into production dashboards, that removes the near-term risk of the plugins suddenly going unmaintained. It's a case of a major vendor formally picking up support for community plugins whose original developer stepped away, which gives observability teams that depend on third-party plugins more predictability in their maintenance roadmap. The post itself functions mainly as a support-status announcement rather than a feature release, aimed at helping teams plan whether to keep using the plugins or start evaluating alternatives.
💡 Teams running Grafana BI dashboards on these plugins now have breathing room, since the support end-date has moved out to the end of 2026 rather than expiring on the original six-month clock.
Green DevOps: Why carbon measurement belongs in your CI/CD pipeline
GitLab
GitLab points out that a typical software team runs hundreds of CI/CD jobs a day, consuming compute and generating carbon emissions that don't show up anywhere in the pipeline logs. The post argues for building carbon measurement directly into CI/CD pipelines and points to Eco CI, an open-source tool, as the way to do it. Eco CI runs as lightweight bash scripts inside pipeline jobs with no separate server or database required, monitoring CPU utilization during command execution and estimating energy consumption using pre-calculated power curves from the SPECpower database. Previously available only for GitHub Actions, Eco CI has now added GitLab pipeline support, which teams can enable by including a template file in their GitLab CI configuration. Measurement results are saved as text files that can be downloaded as job artifacts, or sent to an external dashboard to compare energy and carbon trends across branches, commits, or time periods. GitLab is explicit that it doesn't maintain Eco CI itself or make any claim that it satisfies regulatory or compliance requirements.
💡 Teams wanting visibility into CI/CD carbon impact can start measuring energy use per branch or commit just by dropping the Eco CI template into their pipeline config, with no extra infrastructure needed.
Symlinks Are Still Scary (And Yes, You Can Commit Them to Git)
Snyk
This Snyk post revisits an old Unix-era attack technique: a harmless-looking symbolic link committed to a Git repository can quietly redirect a tool into reading from or writing to an arbitrary file outside the repository. Its framing is that this old trick is now resurfacing in AI coding assistants with much nastier consequences, echoing a vulnerability pattern the security community has labeled "GhostApproval." That pattern has reportedly been found across multiple major AI coding assistants, including Amazon Q Developer, Cursor, Google Antigravity, and Windsurf, where a symlink in a malicious repository tricks an agent into touching files outside its workspace sandbox, so a user who approves what looks like a harmless local edit unknowingly authorizes a write to a sensitive file. Vendor responses to these reports have reportedly varied: some patched quickly, some acknowledged the report but went quiet, and at least one rejected a report as outside its threat model. The broader point is that committing symlinks to Git is legitimate and sometimes useful, but it becomes a real remote-code-execution risk once an AI agent fails to validate filesystem boundaries before acting on one. For teams running AI coding assistants against untrusted repositories, open-source clones, external pull requests, the practical takeaway is to check whether a given tool actually validates symlinks and enforces workspace boundaries before trusting it.
💡 Teams running AI coding assistants against untrusted repos should verify the tool actually validates symlinks and enforces workspace boundaries before trusting it with external pull requests or cloned code.
This digest was collected from RSS feeds and summarized by AI (Claude). See the original links for full details.