🔥 Top Story
Shopify’s CEO threatened to ban Claude Code. Anthropic had already closed the feature request.
Shopify CEO Tobi Lütke said on X he's considering banning Claude Code at the company, not because the tool is bad but because Anthropic still won't natively read AGENTS.md. Shopify runs thousands of developers in a single massive monorepo where coding agents pick up instruction files recursively down the directory tree, so every agent needs the right file in every folder. AGENTS.md, introduced by OpenAI in 2025 and now stewarded by the Linux Foundation's Agentic AI Foundation, has become a de facto standard used by over 60,000 projects and tools like Codex, Cursor, Gemini CLI, and GitHub Copilot. Claude Code instead relies solely on its own CLAUDE.md, so a directory missing one of the two files leaves a subset of developers working with what Lütke called a 'lobotomized' agent. Anthropic offers workarounds like importing AGENTS.md into CLAUDE.md or symlinks, but has closed a feature request for native recursive AGENTS.md discovery as 'not planned.' Shopify has built automation to paper over the gap, but Lütke argues platform teams shouldn't have to pay that complexity tax at all. The dispute highlights a real fragmentation risk as more coding agents converge on the same large codebases without a shared convention.
💡 Why it matters: Any org running multiple coding agents against the same monorepo should treat CLAUDE.md/AGENTS.md drift as a silent correctness risk and automate keeping both files in sync until Anthropic ships native support.
🔗 Read more · The New Stack
Kubernetes & Cloud Native
The lazy developer’s guide to observing your own code
CNCF
This CNCF blog post addresses developers' common resentment toward being asked to 'shift left' on observability by instrumenting application code with OpenTelemetry themselves, and makes the case for why this actually benefits developers, not just SREs. It lists five concrete benefits: instrumentation reduces debugging time, accelerates development and deployment, surfaces slow paths and hidden retries before they hit production, helps developers reason about unpredictable microservices interactions, and helps untangle inconsistent quality from AI-generated ('vibecoded') code. Drawing on developer interviews, the piece identifies real pain points: SDK/SIG maturity varies wildly by language, languages like Rust and Elixir lack zero-code (automatic) instrumentation and require starting from scratch, there are too many competing options (SDKs, eBPF, compile-time instrumentation), and API instability, painful dependency upgrades, and high-cardinality metrics all add friction. Its practical advice is to start with zero-code instrumentation where available (Java, .NET, Python, JavaScript, PHP, Go), fill gaps with manual instrumentation, practice observability-driven development by instrumenting code as it's written rather than retroactively, and use AI carefully to assist with instrumentation work. On what to instrument, it recommends adding spans only to meaningful units of work — inbound requests, outbound calls to databases/caches/APIs/queues, and business-critical operations — rather than instrumenting every method call, which just creates noise (the excerpt available cuts off before further tips).
💡 When rolling out instrumentation standards to a new team or language, factor in that manual-instrumentation burden spikes sharply for languages without zero-code auto-instrumentation (Rust, Elixir), meaning observability cost should be weighed as an architectural decision at stack-selection time, not bolted on afterward.
Stop trying to learn all of Kubernetes at once
CNCF
Written by Joep Piscaer of Portainer.io for the CNCF blog, this piece argues that Kubernetes learning resources fail beginners by dumping too much at once, and instead proposes five pieces of mental scaffolding to internalize before diving into configuration details. First is desired state and reconciliation — the single mechanism underlying self-healing, scaling, and rollouts, where you declare what should exist rather than commanding actions and the system continuously reconciles reality against that declaration. Second is the control-plane/worker split and what 'disposable' really means: unlike a sick vSphere ESXi host that gets nursed back to health, a sick Kubernetes node just gets replaced, since any healthy node can run any workload. Third is the four networking layers — container to pod, pod to service, service to ingress, ingress to the outside world — with the insight that most networking confusion is really confusion about which layer a problem is occurring at. Fourth is treating requests and limits as a survival contract rather than a suggestion, since misconfiguring them either wastes capacity or gets pods evicted at the worst possible moment, making this the most common root cause behind 'works in staging, falls over in production.' Fifth is understanding why CNI and CSI exist as plugin interfaces rather than built-in implementations — a deliberate flexibility tradeoff that, once understood, makes the sprawling ecosystem of networking and storage plugins look intentional rather than chaotic. The author concludes that everything else — service mesh, policy engines, GitOps — can wait until a real problem makes the need for it obvious, and points to a free vendor-neutral primer at kubeschool.portainer.io.
💡 Platform teams building onboarding material should consider adopting these five scaffolding concepts — especially reframing requests/limits as a survival contract rather than a suggestion, and nodes as disposable rather than assets to nurse — as a minimum curriculum, since misunderstanding them is called out here as the most common root cause of 'works in staging, falls over in production' incidents.
AI & ML
AgentHands: Generating interactive hand gestures for spatially grounded agent conversations in XR
Google Research
AgentHands is a Google XR research prototype, published at CHI 2026, that augments LLM-powered conversational agents with expressive, speech-synchronized hand gestures for spatially grounded guidance in extended reality. Unlike 2D bounding-box overlays used by systems such as Project Astra or Gemini 3.1 Flash Live, AgentHands moves beyond flat UI by giving an embodied agent hands that point, mimic actions, and convey emotion in a 3D environment. The team built a six-dimension taxonomy covering handedness, gesture type, spatiality, temporal dynamics, interactivity, and visual effects, then implemented a pipeline with an environment-awareness module (using eye gaze and scene reconstruction to register objects as 3D bounding boxes), a gesture event library, LLM-driven gesture-embedded reasoning, and a local XR parser that syncs text-to-speech with animation via word-level timestamps. Demo scenarios include orchid care coaching, 3D printer operation walkthroughs, and a wellness-coach interaction. A within-subjects study with 12 participants comparing AgentHands to a speech-only baseline found statistically significant improvements (p < 0.05) in how easily users located objects and identified directions the agent referenced. The work is an early-stage HCI prototype rather than a shipping product, so scalability and production deployment questions remain open.
💡 This is still pure research, but teams building XR or spatial-computing products should note it previews a future on-device agent UX requirement — synchronizing TTS, animation, and scene state with tight latency budgets — that platform architectures will eventually need to support.
5 ways to upgrade your home decor with Google Search
Google AI
This Google blog post is a consumer-facing lifestyle piece describing five ways to use Google Search tools for home decor projects, unrelated to any developer or infrastructure topic. AI Mode in Search lets users upload a photo of their room and specify constraints like wall width to get furniture recommendations, then generate a mockup showing a specific item (like an emerald velvet sofa) placed in their actual space. Google Lens can identify a vintage item from a photo and surface similar products within a price range, while Circle to Search on recent Pixel and Galaxy S26 devices lets users circle an item in a social post or webpage to find matches without switching apps. Search Live provides real-time, camera-assisted voice guidance for DIY tasks like installing floating shelves, and shoppers can check price history or set price-drop alerts before buying. The post notes trending searches like 'home decor inspo' (up 300% in a month) and cites that its AI-generated summary feature is experimental. There is no engineering, cloud, or DevOps content here — it's a pure product-marketing piece for Search consumer features.
💡 There's no infra or developer content here, but the fact that image-grounded visualization and price-history tracking have shipped as mainstream consumer Search features is worth noting as a signal that similar multimodal search-plus-generation patterns will likely show up in enterprise product-catalog and asset-management tooling soon.
Granite 4.2 LLMs: How They're Built
Hugging Face
This IBM Granite team post on Hugging Face is a detailed engineering walkthrough of how Granite 4.2 was built. The models use a dense, decoder-only transformer with Grouped Query Attention (40 heads, 8 KV heads), RoPE (θ=10,000,000), SwiGLU MLPs, RMSNorm, and untied input/output embeddings, with all three sizes (3B, 8B, 30B) sharing the same architecture and training recipe. Pre-training ran on roughly 15 trillion tokens across a five-phase schedule that extends context to 512K in the final long-context phase, and SFT drew on about 7.2 million samples (~100B tokens, ~65B trainable) split 31.6% agentic and 68.4% non-agentic, with the agentic corpus dominated by software engineering (69%), tool calling (12.1%), and terminal use (8%) trajectories generated via scaffolds like OpenHands, SWE-agent, Gemini CLI, and Codex. Data quality control used GPT-OSS-120B and Gemma 4 as LLM judges to filter low-quality or hallucinated samples and SHA-256 hashing for local and global deduplication. The 30B model gets an extra phase-2 SFT pass focused on agentic coding (retaining 16% replay data), and the 8B/30B models then go through a multi-stage, multi-environment reinforcement learning pipeline that teaches them to act as agents inside real sandboxed environments. Served through an OpenAI-compatible endpoint like vLLM, the models emit tool calls in the standard OpenAI function-calling format, letting them plug into existing agentic harnesses without extra glue code.
💡 The unusually granular disclosure of SFT data sourcing scaffolds, LLM-judge filtering, and SHA-256 deduplication gives teams fine-tuning their own agentic models a concrete, reusable reference for building a comparable data pipeline rather than starting from scratch.
Quantization-Aware Healing: a compressed, 4-bit model that outperforms its full-precision original
Hugging Face
Multiverse Computing introduced Quantization-Aware Healing (QAH), a technique for recovering accuracy in a model that has been both structurally compressed (layers, heads, or neurons removed) and quantized to 4 bits, by distilling directly from the original pre-compression, full-precision model as a frozen teacher via KL divergence. This sidesteps the limitations of quantization-aware training (QAT), which re-runs an already expensive multi-stage post-training process through a noisier low-precision forward pass and can become unstable, and quantization-aware distillation (QAD), which distills from the recovered bfloat16 checkpoint and thus caps the quantized model's accuracy at that checkpoint's own ceiling. To make this work at 32K-token context, QAH reuses a memory-efficient chunked KL-divergence loss from a companion paper that computes divergence one sequence slice at a time, avoiding materializing the full vocabulary-by-sequence grid. Applied to a GPT-OSS 120B model structurally compressed to 60B parameters and quantized to MXFP4, QAH beat its own bfloat16 (16-bit) version on 7 of 9 benchmarks, with the largest gains on long-context reasoning (+7.4 on AA-LCR) and math (+5.6 on AIME 2025). Remarkably, the QAH 60B model — at half the parameters and roughly a quarter of the weight memory — even outscored the full-size 120B teacher on LiveCodeBench (66.5 vs. 66.0), and a head-to-head comparison against QAT on a GPT-OSS 9B model showed QAH reaching a similar or better peak with a more stable training curve. The results suggest a smaller, cheaper 4-bit model can be more accurate than its own full-precision source, inverting the usual size-versus-accuracy tradeoff for teams deploying compressed models in production.
💡 Teams serving structurally compressed, quantized models should recognize that the common QAD approach caps accuracy by distilling from an already-degraded recovered checkpoint, and that switching to QAH — distilling straight from the original full-precision model — can meaningfully raise accuracy without added serving infrastructure cost.
The full stack behind abundant intelligence
OpenAI
Written by OpenAI CFO Sarah Friar, this piece argues that compounding advances across chips, compute, models, and products are what deliver more useful intelligence at greater scale and lower cost. The central framework is the Jevons paradox: as efficiency improves, more use cases become economically worthwhile, expanding total consumption and generating new economic activity — more work completed, better decisions made, more products launched, more revenue generated. Friar frames this as OpenAI's 'compounding advantage': better technology produces better economics, better economics fund the next wave of technical progress, and each gain strengthens the whole system. As a concrete data point, she cites GPT-5.6 Sol reaching a new high on the Artificial Analysis Coding Agent Index in max-reasoning mode while using 54% fewer output tokens than a comparable leading model. The piece is essentially a CFO-level economic argument for why useful intelligence per unit of compute keeps improving through gains in models, routing, and hardware. Note that OpenAI's site blocked automated fetching (Cloudflare bot protection), so this summary is based on secondary reporting and search-result excerpts rather than the full original text.
💡 Because the Jevons-paradox argument implies that efficiency gains expand usage rather than shrinking spend, engineers doing infrastructure capacity planning should budget for total compute cost potentially rising even as per-token model cost falls.
Jalapeño’s first results show industry-leading speed and efficiency in AI inference
OpenAI
OpenAI published the first benchmark results for Jalapeño, its custom inference chip developed in close collaboration with Broadcom. Tested on Semianalysis's InferenceX benchmark, Jalapeño delivered 1.5 to 1.9 times more throughput per watt and cut end-to-end latency by 1.7 to 3.6 times compared to the best currently available inference processors across three models, and was reported as 2.1 to 4.1 times faster on highly interactive workloads. The design's core idea is minimizing data movement and communication delay: model state, including the KV cache used during response generation, can be explicitly placed and kept local while the system activates the right mix of compute, memory, and networking for each inference phase. OpenAI says its own models assisted in the chip's development process, and it plans to deploy Jalapeño in small volumes by the end of 2026, scaling up meaningfully in 2027, with second- and third-generation chips already in development. This represents OpenAI moving to reduce its dependence on third-party inference hardware vendors like Nvidia by controlling inference cost and latency directly through custom silicon. Because OpenAI's site blocked automated fetching, this summary draws on the original excerpt plus corroborating secondary coverage (TechCrunch, The Register, The New Stack) rather than the full primary text.
💡 A verified 1.5-1.9x improvement in throughput per watt would meaningfully reshape the per-token power and cost economics for anyone running inference at scale, so teams planning their own inference infrastructure should watch for real pricing and availability details once small-volume deployment begins in late 2026.
Disrupting a new covert influence campaign from Russia
OpenAI
OpenAI announced it disrupted a new covert influence operation originating from Russia and banned the associated ChatGPT accounts. The operation ran a fake Israel-based 'expert community' think tank called the International Burke Institute (IBI), routing connections through VPNs to circumvent OpenAI's restrictions on access from Russia. Its primary use of ChatGPT was generating social media posts promoting IBI website articles across X, LinkedIn, Facebook, Substack, and Telegram — with operators making requests in Russian while instructing the model to produce output in English and German and explicitly asking it to scrub any linguistic clues revealing Russian authorship. Of 36 sampled IBI articles, 34 were found to be plagiarized, with some falsely attributed to Francis Fukuyama and Noam Chomsky, and the operation also ran a 'sovereignty index' praising Russia while criticizing France, Germany, and the United States. OpenAI disclosed this as part of its ongoing threat intelligence reporting on malicious AI use, illustrating a continuing pattern of state-linked actors using generative AI for influence operations. As OpenAI's site blocked automated fetching, this summary is based on the article's excerpt and corroborating secondary reporting.
💡 Because the operators used specific evasion tactics — VPN routing and explicit instructions to strip linguistic tells — to get around geographic access restrictions, teams operating AI platforms should take away that region/IP-based blocking alone is insufficient and needs to be paired with content-pattern and behavioral-anomaly detection.
Wire It, Run It, Deploy It: AI Workflows in Gradio
Hugging Face
This Hugging Face post introduces Gradio's new gr.Workflow feature, which turns a pipeline of AI models and functions into a visual graph instead of hand-wired Python code. Users connect typed nodes — references (inputs), operators (processing steps), and subjects (outputs) — on a drag-and-drop canvas where every node is runnable and every intermediate result is visible; the same graph automatically becomes a REST API and deploys to Hugging Face Spaces with one command. Example workflows include a single-node image editor built on Qwen-Image-Edit, a media studio that chains FLUX image generation into background removal, text-to-speech, and an LLM-generated title (with each output exposed as its own endpoint like /sticker, /voiceover, /episode_title), a fan-out pattern that generates multiple parallel image variants from one prompt, a dataset-profiling app that fans a single Hugging Face dataset ID out to four parallel analysis nodes, and a GPU-backed node using the @spaces.GPU decorator so ZeroGPU allocates a GPU only when that node runs. An operator can be a custom Python function, a model via Hugging Face Inference Providers, another Gradio Space, or a row from a Hub dataset, and any completed workflow can be called from Python via gradio_client or plain curl. Getting started takes just a few lines — gr.Workflow(bind=[your_function]).launch() — and every example is a live, duplicable Hugging Face Space rather than a static code sample.
💡 The fact that every workflow node automatically becomes its own REST endpoint means a prototyped multi-model pipeline can be wired straight into internal services or production integrations without building a separate API gateway, meaningfully shortening deployment lead time.
Cloud Updates
Bringing gVisor sandboxes to distributed Ray clusters
Google Cloud
Google Cloud, in partnership with Anyscale, introduced an experimental library that brings native gVisor-based sandboxing directly into distributed Ray clusters, aimed at RL post-training workflows. As agentic and reasoning models scale up, safely isolating dynamic rollouts, code generation, and multi-turn tool interactions had become a bottleneck for frameworks like veRL, NeMo-RL, SLIME, MILES, and SkyRL that already run on Ray. Rather than inventing a separate abstraction, Ray Sandboxing represents each sandbox as a Ray Actor so the existing Ray scheduler handles placement, CPU/memory reservation, lifecycle, and failure recovery; starting in Ray 2.58, the ray.experimental.sandbox API lets developers create sandboxes from OCI-compatible images and execute commands, manage files, and inspect or tear down state using familiar Ray calls. A lower-level SandboxRuntime API is also available for building custom sandbox pools inside an actor. gVisor was chosen because it implements much of the Linux syscall interface in userspace, adding an isolation boundary between untrusted, model-generated code and the host kernel, while remaining OCI-compatible, requiring no exposed Docker daemon, and offering sub-second startup with low per-sandbox memory overhead — properties suited to using sandboxes as fine-grained distributed resources. Google plans to extend support to other sandboxing runtimes like Agent Substrate or Kata Containers in future Ray releases. The feature is explicitly experimental, and interested teams are directed to the Ray documentation, a GKE user guide, and a GitHub issue for feedback.
💡 For teams running RL or agentic pipelines on GKE that must treat model-generated code and tool calls as untrusted, being able to manage gVisor sandboxes as first-class Ray Actors inside the existing scheduler and failure-recovery model — rather than bolting on separate isolation infrastructure — meaningfully cuts operational complexity.
Now introducing Gemini Enterprise for Legal
Google Cloud
Google Cloud CEO Thomas Kurian introduced Gemini Enterprise for Legal, the first in a new line of industry-specific solutions, built on the premise that general-purpose model intelligence alone can't meet law's strict confidentiality, matter-permission, and ethical-wall requirements. The offering rests on four components: domain-specific 'skills' for contract review and redlining, playbook creation, regulatory horizon scanning, legal research, and DSAR fulfillment; secure MCP connectors into document management and case systems that inherit existing permissions rather than bypassing them; pre-built agents that complete work end-to-end rather than just returning suggestions; and an open partner ecosystem including Accenture, Deloitte, and KPMG — all sitting under a governed control plane enforcing VPC/CMEK policies and citation-traceable outputs. Concrete workflows include autonomously tracking legislative and regulatory changes to flag exposure gaps and draft policy updates, automating Data Subject Access Request (DSAR) compilation across fragmented systems, benchmarking inbound vendor agreements and NDAs against firm playbooks to surface high-risk clauses, and redacting sensitive material for court filings. It connects via secure MCP integrations to Google Workspace, Microsoft 365, document management systems like iManage and NetDocuments, Docusign, e-discovery platforms Everlaw and RelativityOne, and legal research sources like Thomson Reuters HighQ and CourtListener, with access bound to each system's existing role-based permissions and ethical walls. The product targets law firms and corporate legal departments that need auditable, permission-respecting AI rather than a general chatbot layered on top of privileged data.
💡 The real differentiator here isn't model quality but the governance design — MCP connectors that inherit existing matter permissions and ethical walls from source systems rather than re-implementing access control at the agent layer — which is a pattern worth studying for any platform team introducing AI agents into a regulated, permission-sensitive industry.
Now introducing Gemini Enterprise for Financial Services
Google Cloud
Google Cloud CEO Thomas Kurian introduced Gemini Enterprise for Financial Services, targeting capital markets and corporate banking workflows where general-purpose AI lacks the real-time accuracy, verifiable data lineage, and strict security financial institutions require. The offering combines reusable domain skills, secure MCP connectors, agents that act rather than just suggest, and an open partner ecosystem, all under a governed control plane. Its centerpiece is the Financial Research agent, a Google-built and managed agent shipping with more than 50 foundational skills that runs end-to-end research with confidence scores, explicit methodologies, auditable data snapshots, and precise source citations, reachable via the Gemini Enterprise app or wired into existing workflows through Agent-to-Agent (A2A) APIs. Concrete workflows include KYC research that ingests PDFs, Excel files, and SEC filings to map complex corporate hierarchies and resolve ultimate beneficial owners; reducing bond portfolio risk-exposure analysis to under five minutes with automated duration-hedging suggestions; identifying credit-market mispricings to surface trade ideas; and compressing bond-issuance pitch timelines from days to minutes. It connects via secure MCP integrations to licensed market-data and fundamentals providers (Daloopa, FactSet, Finnhub, Fiscal.ai), risk and ratings sources (Moody's, MSCI, PitchBook), regulatory records (SEC Edgar, Dun & Bradstreet), and digital-asset data (CoinDesk), with access strictly bound by each institution's existing licensing entitlements and role-based controls. It's aimed at private equity specialists, wealth managers, and compliance teams who need auditable, source-cited output rather than a general chatbot bolted onto proprietary financial data.
💡 The real value proposition isn't the underlying model but the Financial Research agent's built-in explainability — confidence scores, auditable data snapshots, and source citations by default — which gives regulated financial organizations a concrete benchmark for deciding whether to build that auditability layer themselves or adopt it off the shelf.
Streamlining container security: Red Hat Hardened Images now supported in AWS InspectorScan API and ECR Basic scanning
Red Hat
Red Hat announced that its minimized container base image catalog, Red Hat Hardened Images, is now supported in AWS's InspectorScan API and Amazon ECR Basic scanning. The motivation is that traditional base images bundled with unnecessary shells, package managers, and tools generate a flood of vulnerability alerts, burdening security teams with noise triage and developers with CVE remediation. Hardened Images contain only the files an application actually needs to run, are built through Red Hat's trusted software supply chain, and are rigorously tested to support compliance certifications like CIS, STIG, and OpenSCAP. Amazon ECR Basic scanning draws on more than 50 data feeds — vendor advisories, threat intelligence, and the NVD — to automatically or manually scan images already in the registry for OS-package CVEs, surfacing findings in the ECR console and via EventBridge. The AWS InspectorScan API extends this earlier into the pipeline: it accepts an SBOM generated from container images or binaries and returns a detailed vulnerability report scored against NVD/CVSS, letting teams gate insecure images out before they ever reach the registry. Hardened Images also ship in purpose-built variants — a lean, shell-free Default runtime for production, a Builder variant with package managers for multi-stage build pipelines, and a FIPS variant enforcing FIPS 140-2/3 validated cryptography for regulated environments — with the full catalog spanning roughly 60 core images and over 150 variants.
💡 Understanding that InspectorScan API catches vulnerabilities pre-build while ECR Basic scanning catches them post-registry means teams already using AWS-native container security tooling can structurally reduce CVE noise just by switching base images to Hardened Images, without adding a separate third-party scanner.
Preparing OpenStack for the post-quantum era: A systematic approach to crypto-agility
Red Hat
Red Hat published the results of a systematic audit of post-quantum cryptography (PQC) vulnerabilities across the entire OpenStack ecosystem. The concern is 'Q-day' — the future moment when a cryptographically relevant quantum computer running Shor's algorithm breaks RSA, ECDSA, ECDH, and Ed25519, the very algorithms OpenStack relies on for token signing, key generation, TLS, and secret storage — which already creates present-day risk via 'harvest now, decrypt later' attacks on data encrypted today. An upstream PQC Migration Pop-up Team formed at the April 2026 PTG, combined with 27 downstream engineering teams analyzing over 90 repositories using a purpose-built scanner, documented 572 findings and 39 cross-cutting patterns across 23 teams, independently validated by a separate security review. Four systemic patterns emerged: Barbican's SimpleCrypto plugin only generates RSA and DSA keys; Keystone signs tokens with hardcoded ECDSA P-256 with no configuration option to switch algorithms; oslo.messaging's legacy SSL version map has no TLS 1.3 entry, blocking PQC hybrid key exchange for all interservice messaging; and cert-manager/Go-based operators default to RSA-2048 or allow protocol downgrades when no explicit minimum TLS version is set. Encouragingly, a meaningful share of findings resolve automatically once the platform upgrades to OpenSSL 3.5 (which natively ships ML-KEM/FIPS 203 and ML-DSA/FIPS 204) and pyca/cryptography 48.0/49.0, as long as application code doesn't itself restrict TLS protocol versions or cipher suites — meaning some fixes require no code changes at all, while the hardcoded cases require targeted engineering work.
💡 Organizations running OpenStack should prioritize by separating findings that resolve automatically with an OpenSSL 3.5 platform upgrade from those requiring direct application-code fixes because of hardcoded algorithm choices in components like Keystone and Barbican, and this post's four systemic patterns can serve directly as that triage checklist.
Paying it forward: How mentorship comes full circle for early talent
Red Hat
This is a Red Hat corporate culture and talent-branding post about its internship mentorship program, with no technical engineering content. TAM team manager Marc Richter describes how mentoring intern Aarna Upadhyaya became a two-way exchange where his veteran team members learned from her fresh perspective. Senior software engineer Alex Oladele credits his mentee, Ansible Automation Hub intern Mason Mines, with lifting team morale through his enthusiasm. College interns in Raleigh and Boston in turn mentored participants in Red Hat's High School Internship Program, creating a cyclical mentorship structure. Boston sales intern Alissa Rogozin reflects that teaching a newer intern reinforced her own understanding of what she'd learned. The post frames internships as a chance to tackle real business challenges that help interns clarify their career direction, and frames mentoring as bidirectional rather than top-down across managers, peers, and interns. The piece is essentially recruitment and employer-branding content highlighting Red Hat's reciprocal mentorship culture across management, peer, and intern-to-intern relationships.
💡 This is pure employer-branding content with no technical takeaway for cloud or DevOps engineers, though managers designing junior-engineer onboarding and mentorship programs may find the reciprocal-mentorship structure worth referencing.
DevOps & Infrastructure
IBM’s new Granite 4.2 models add reasoning and stay dense
The New Stack
IBM released its Granite 4.2 family of open-weight LLMs in 3B, 8B, and 30B parameter sizes, sticking with dense, decoder-only transformers pre-trained from scratch rather than following the industry trend toward Mamba/attention hybrids. Billed as a 'reasoning-focused' release, the models support thinking and non-thinking modes plus a new low-effort mode that spends minimal reasoning tokens on easy questions. Trained on roughly 15 trillion tokens across a five-phase pipeline under Apache 2.0, the models now support up to 512K context (128K natively in the released configuration) and include 1 trillion tokens of synthetic code from IBM's CodeAlchemy pipeline. The 8B and 30B variants went through an additional agentic reinforcement learning stage that teaches them to call tools, edit and run code, operate a terminal, and search the web. Benchmarks aren't groundbreaking, but the 8B model comes close to the 30B's results while remaining easy to run on a typical Mac or a modest RTX GPU, though coding performance lags rivals like Qwen 3.8 27B. IBM frames Granite's value proposition around high-throughput agentic tasks rather than frontier benchmark scores, positioning it for enterprises that need lightweight, reliable agents rather than maximum raw capability.
💡 Platform teams looking to run agentic workloads cost-effectively on their own infrastructure should note that the 8B dense model nearly matches the 30B's results while running on modest hardware, making it a practical alternative to frontier-model API costs.
How telemetry pipelines keep AI agent costs under control
The New Stack
This Apica-sponsored piece argues that as enterprises move AI agents into production, telemetry costs are becoming an unpredictable infrastructure crisis. A survey of 300+ North American and Western European IT decision-makers, commissioned by Apica via Omdia/Informa TechTarget, found 59% have already killed or delayed an agentic AI deployment specifically because of monitoring costs, hitting high-stakes areas like cybersecurity, compliance, and fraud detection hardest. Telemetry volume tripled in the past year for 54% of organizations, with AI/ML workloads driving 43% of that growth; average observability spend now sits at $3.17 million, up 28% year over year, and enterprises expect a 9.5x increase in telemetry data within two years. The root cause is structural: a single agent task can fan out into a top-level trace, multiple model calls, retrieval and tool calls, retries, loops, and delegated sub-agent branches, each generating high-cardinality identifiers like tool_name, agent_id, and trace_id that are expensive to index and aggregate. Apica CPTO Andi Mann argues the fix is to push intelligence upstream into a pipeline-first architecture that samples routine successful events while preserving failures, retries, policy violations, and unusually slow traces, enriching and redacting data at the source before it reaches costly central platforms. Organizations with a telemetry pipeline are reportedly 50% more likely to be prepared for agentic AI's data growth, and mature adopters are 80% more likely to avoid the operational cost blowups plaguing their peers — with Apica claiming up to 40% TCO reduction versus legacy observability stacks. As a vendor-sponsored piece, the cost-saving figures should be read as Apica's own study rather than independently verified benchmarks.
💡 Because a single agent task can fan out into exponentially more traces, tool calls, and high-cardinality identifiers than a conventional request, teams with an already-mature observability stack still need a source-side sampling and filtering layer or risk telemetry costs outgrowing the budget and forcing deployments to be pulled, as this vendor-sponsored survey documents happening at 59% of surveyed enterprises.
The Grafana AI SDK for Go: a shared foundation for building AI applications
Grafana
Grafana Labs open-sourced the Grafana AI SDK for Go to stop its own teams from repeatedly building slightly different LLM client abstractions for streaming, tools, and error handling. It provides common interfaces for generating text, streaming responses, executing typed Go functions as tools, producing schema-validated structured output, and running multi-step agent loops, and it speaks the Vercel AI SDK's wire protocol so a Go backend can stream directly to useChat, useCompletion, and useObject frontend hooks. It currently supports Anthropic, Amazon Bedrock, OpenAI's Responses API, and OpenAI-compatible APIs through separate provider modules, plus built-in timeouts, retries, model fallback, structured logging, Prometheus metrics, and an Agent Observability middleware. The design deliberately mirrors Vercel's AI SDK model but is expressed through idiomatic Go — interfaces, channels, explicit errors, contexts, and functional options — with conformance tests run against pinned upstream Vercel versions and real TypeScript frontend packages. The most consequential shared behavior is the Agent Observability middleware, which records model and agent activity, usage, errors, multi-step relationships, and which provider served a routed call directly into Grafana. Grafana published this alongside a broader set of AI tooling released during its first Grafana Labs AI Week. It's still a young project without full feature parity with the Vercel SDK, and the team maintains a public compatibility baseline and gap list rather than claiming complete equivalence.
💡 Grafana's own experience shows that letting each team build its own LLM integration fragments retry, streaming, and observability conventions, so organizations building AI features across multiple teams should standardize on a shared provider abstraction and observability middleware early rather than paying the cost of consolidating later.
Golden Paths for AI agents: What changes when platform users aren’t human?
Datadog
Written by Datadog engineers, this post explains how to redesign Golden Paths — internal platform workflows originally built to guide human developers — for a new class of platform user: autonomous AI agents. Citing Gartner's 2026 Hype Cycle for Agentic AI, which notes agents have the most aggressive adoption curve of any emerging technology and are now treated as a formal 'agent experience' (AX) persona, the piece distinguishes between a synchronous, low-latency execution pattern for real-time conversational agents (with end-to-end deadlines and per-call timeouts) and a durable, resumable execution pattern for long-running asynchronous agents, where workflow state must persist independently of model context to survive restarts. Datadog illustrates the durability point with a real incident: during a rolling deployment of its internal AI Gateway, a graceful shutdown window too short for in-flight agent requests caused a spike in timeouts until the window was extended. For agents that execute code, the post recommends isolating that execution in a sandbox exposed as a remote tool — restricting filesystem, network, resource, and lifetime limits — rather than letting the agent inherit the full development environment's permissions. Its central architectural recommendation is a 'hybrid Golden Path' that separates probabilistic agent judgment from deterministic control: agent outputs like a proposed code fix must pass through deterministic gates (tests, security scans, approvals, merge permissions) before any consequential action executes, and the agent can revise a failing output but cannot override the gate itself. Finally, every platform capability exposed to an agent needs a machine-consumable contract — clear description, typed I/O, versioned schemas, machine-readable limits and error categories, and declared side effects and approval requirements — enforced at the platform level rather than trusted to the agent's own orchestration.
💡 Datadog's own incident — where a graceful shutdown window tuned for human traffic was too short for in-flight agent requests during a rolling AI Gateway deployment — is a concrete operational signal that any service now receiving agent traffic needs to re-tune deployment and shutdown parameters that were originally set for human request patterns.
Scale software delivery pipelines in isolation without owning the runner fleet
GitLab
GitLab announced Hosted Runners for GitLab Dedicated, a fully managed CI execution service for customers already on GitLab Dedicated (an isolated, single-tenant managed instance). The motivating problem is that agentic workflows are driving up pipeline volume, making full data isolation and runner-fleet operational burden a growing challenge — this service removes the need for organizations to provision, patch, and scale their own runner fleet. Key features include a runner fleet fully isolated from other customers with a 'one runner, one job' model where each job runs in a freshly provisioned, isolated VM that's deleted immediately after completion; network security via AWS PrivateLink for connecting to internal artifact registries, secret managers, and deploy targets; compliance support matching GitLab Dedicated's existing data-residency guarantees; and a 99.9% uptime SLA. Runners are self-serviceable through Switchboard, the GitLab Dedicated management console, and usage draws down from GitLab Credits on a consumption-based pricing model tracked via a dedicated dashboard. Machine sizes range from Small (2 vCPU/8GB) to 2X-Large (32 vCPU/128GB) across Linux x86-64 and Arm64 architectures. The offering is effectively GitLab absorbing the classic runner capacity tradeoff — over-provisioning for good developer experience at higher cost, versus under-provisioning to save money at the expense of CI queue wait times — on behalf of the platform team.
💡 The 'one runner, one job' model — a fresh VM provisioned and destroyed per job — gives platform teams that have been wrestling with their own runner fleet's over- vs. under-provisioning tradeoff a concrete basis for deciding whether to shift that burden onto an SLA-backed vendor service instead.
Your alt text passes automated checks. That doesn’t mean it’s any good.
GitHub
GitHub's engineering team describes how they built an alt-text quality plugin for the GitHub Accessibility Scanner. The motivating data comes from WebAIM's 2026 WebAIM Million report: 16.2% of images across the top million home pages have no alt text at all, and another 10.8% of the ones that do have alt text that's essentially useless — a filename, a generic word like 'image,' or text copied from a neighboring image. The team's five default, deterministic rules operate on the alt string alone (missing/whitespace-only, filename-as-alt, unfilled placeholders like 'TODO', a single generic word, and exact repetition across adjacent images), while judgments that require seeing the image and its context are isolated into a single opt-in rule that calls a vision model. The repetition check initially walked images in document order and incorrectly grouped a header and footer 'GitHub' logo that were far apart on screen, so the team rewrote it to compare bounding-box gaps against image size, judging by on-screen layout rather than DOM order. The opt-in AI quality check feeds a vision model the nearby heading, page title, figcaption, whether the image sits inside a link, and up to 600 characters of surrounding prose; its first version nitpicked even perfectly good alt text because a language model will always answer 'could this be better?' with yes, which the team fixed with a four-step ordered decision procedure, explicit anti-nitpick rules, and structured output that forces reasoning before a verdict. The AI rule is off by default, requires a GitHub Models token, and redacts image URLs before sending them to avoid leaking signed CDN tokens or session identifiers — reflecting deliberate privacy and cost tradeoffs around calling an external model on webpage data.
💡 As the authors explicitly note, a quality rule with a high false-positive rate is a rule teams simply disable, so any team adding automated accessibility or quality checks to CI should borrow this design principle directly: keep deterministic string-based rules on by default and isolate AI-based judgment calls into an explicit opt-in check.
This digest was collected from RSS feeds and summarized by AI (Claude). See the original links for full details.