Techlist.io - Korean Tech Blog Curator

google3 min readCurated summary

Towards a quantum computer that learns from its errors

Quantum computers require constant recalibration because analog control signals drift during computation. Google Quantum AI combined reinforcement learning (RL) with quantum error correction (QEC), allowing a system to learn from detected errors and adjust thousands of control parameters while computation continues. Tests on the Willow processor showed improved logical stability, suggesting this approach could support much longer quantum computations. ## The Challenge of Quantum Errors - Quantum systems are highly sensitive to drift in signal frequencies, amplitudes, and phases. - Conventional recalibration requires stopping the entire computation, limiting algorithms that may need to run for days or months. - QEC uses many physical qubits to form logical qubits and converts analog noise into binary error-detection events. - These events indicate that an error occurred within a spacetime region but do not identify its precise cause or location. - Decoders such as AlphaQubit and Tesseract infer corrections, but they do not explain whether errors arose from environmental decoherence or preventable calibration drift. ## Moving Beyond Physics-Based Calibration - Traditional calibration depends on manually designed physical models. - Such models can reach performance limits when hardware behavior involves complex, poorly understood interactions. - Google argues that quantum control may benefit from the same shift toward data-driven learning seen in computer vision, robotics, and protein-folding research. - As quantum hardware improves, remaining errors increasingly reflect subtle phenomena that are difficult to model analytically. ## Using Error Detection as a Learning Signal - An RL agent experiments with control strategies and improves based on the resulting error data. - QEC detection events serve two purposes: - Decoders use them to infer logical corrections. - The RL system uses them to identify drift and refine control parameters. - This enables continuous calibration without interrupting the quantum computation. - The approach can steer thousands of analog control parameters dynamically. ## Results on the Willow Processor - Researchers deliberately introduced control-parameter drift into Google’s Willow superconducting processor. - RL steering improved the logical stability of the error-correcting code by 3.5 times. - After expert, human-guided calibration, RL fine-tuning reduced the logical error rate by an additional 20%. - Combined improvements produced fewer than one logical error per 1,000 surface-code correction cycles and fewer than one per 100 color-code cycles. - The processor therefore operated as a more reliable quantum memory for longer periods. ## Scaling to Larger Systems - Simulations included hundreds of qubits and tens of thousands of control parameters. - The RL agent reduced initially high physical error rates by learning better control settings. - QEC suppressed the logical error rate exponentially as the number of physical qubits increased. - The simulations indicated that the number of RL training iterations needed to reduce physical errors did not depend on system size, supporting potential scalability. The results suggest that future quantum computers could use QEC not only to correct errors but also to learn their causes and continuously adapt to hardware drift. RL-based calibration could reduce dependence on manual tuning and help make long-running, fault-tolerant quantum computation practical.

Read original(opens in new tab)
google3 min readCurated summary

SymptomAI: Towards a conversational AI agent for everyday symptom assessment

SymptomAI explores whether conversational AI can conduct realistic symptom interviews and generate useful differential diagnoses outside curated medical vignettes. In a randomized national study of 13,917 participants, SymptomAI agents often performed as well as or better than clinician-generated differentials according to expert reviewers, particularly when they actively asked follow-up questions. The study also found that diagnoses associated with infectious illnesses corresponded with shifts in participants’ Fitbit biosignals, suggesting potential for large-scale health research. ## Moving Beyond Curated Medical Cases - Existing language-model evaluations often use detailed, synthetic, or highly structured patient vignettes. - Real patients may provide incomplete information, have varying medical literacy, or describe symptoms unpredictably during conversation. - SymptomAI was designed to test end-to-end symptom assessment in a more natural setting, while making clear that its outputs were research results rather than clinical diagnoses. ## National-Scale Study Design - 13,917 consenting participants were randomly assigned to one of five Gemini Flash 2.0 SymptomAI agents. - Participants described their symptoms, answered follow-up questions, received a differential diagnosis (DDx), and were given next-step recommendations. - Two weeks later, participants reported diagnoses received from healthcare providers. - Three board-certified clinicians reviewed the conversations, created their own differentials, and blindly ranked SymptomAI’s DDx against clinician-generated alternatives. ## SymptomAI Compared Favorably with Clinicians - Clinical reviewers preferred SymptomAI’s differential diagnosis over those from other clinicians in more than 50% of cases. - SymptomAI’s DDx was more likely to be ranked as the highest-quality option. - Using top-five accuracy—whether the eventual provider diagnosis appeared among five proposed diagnoses—reviewers found SymptomAI’s differentials accurate more often than the comparison clinician differentials. ## Follow-Up Questions Improved Accuracy - The study tested five interview strategies: - Dynamic Live and Dynamic Final agents could ask unrestricted follow-up questions. - Fixed Canonical and Flexible Canonical agents used standardized medical history questions. - The Base condition represented a user-led interaction with an unprompted language model. - Every agent-driven strategy significantly outperformed the Base condition. - The findings indicate that actively eliciting additional information is more effective than relying solely on what users initially choose to disclose. ## Strongest Results in Uncertain Cases - SymptomAI’s advantage over clinician baselines was greatest when clinicians expressed low confidence in their own differentials. - This suggests conversational AI may be especially useful as a second opinion or support tool in ambiguous cases, though the study does not establish that it can replace professional diagnosis. ## Connecting Diagnoses with Wearable Data - The researchers used SymptomAI’s diagnostic outputs as potential reference labels for analyzing population-scale physiological data. - Participants provided up to 30 days of Fitbit biometric data before their SymptomAI interaction. - Acute respiratory infection cases showed noticeable biosignal changes in the days leading up to symptom reporting. - These shifts appeared consistent with symptom onset and possible immune responses, although the provided text ends before presenting the full analysis. SymptomAI’s results support building conversational systems that ask structured follow-up questions and assist with differential diagnosis. Any practical deployment should retain clinician oversight, communicate uncertainty clearly, and treat AI-generated assessments as decision support rather than confirmed medical diagnoses.

Read original(opens in new tab)
naver1 min readCurated summary

VictoriaMetrics Operations Part 2 — A Three-Step Optimization Strategy That Solved a Resource Crisis Without Adding Hardware

The content is a minimal NAVER D2 landing-page fragment rather than a substantive technical blog post. It lists navigation links to D2 News, About D2, NAVER Developers, DEVIEW, OpenSource, and D2 STARTUP FACTORY, along with a copyright notice. ## Page Navigation - “Hello world” appears as the only greeting or introductory text. - Links are provided to: - D2 News - About D2 - NAVER Developers - DEVIEW - OpenSource - D2 STARTUP FACTORY ## Copyright - Copyright © NAVER Corp. All Rights Reserved. No technical argument, explanatory sections, or detailed conclusions are included in the provided content.

Read original(opens in new tab)
github2 min readCurated summary

How to build interactive experiences with canvases

Canvases extend GitHub Copilot beyond text-based conversations by providing shared, interactive workspaces where developers and agents can visualize information and take action together. They are useful for tasks such as triaging issues, exploring code architecture, managing worktrees, and searching organizational knowledge. The article concludes that canvases make AI workflows more engaging, practical, and easier to iterate on. ## How canvases work - Canvas extensions are interactive surfaces within the GitHub Copilot app. - Agents can update the canvas while users interact through clicks, edits, swipes, and other controls. - User actions may be sent back to the agent or handled locally. - Developers create one by running `/create-canvas` in a Copilot agent session and describing the desired interface and capabilities. - Canvases can evolve through follow-up prompts that add features or refine existing behavior. ## Visual issue triage - A card-based interface displays GitHub Issues one at a time. - Users swipe right to ship an issue or left to reject it. - The canvas updates immediately, organizing issues into decision-based categories. - This replaces a slower, text-heavy review process with direct visual interaction. ## Interactive codebase diagrams - A generated diagram represents components of a project as connected nodes. - Users can hover over, drag, and filter elements to explore relationships and architectural layers. - The interface turns static codebase documentation into an explorable model. ## Managing sessions and worktrees - A canvas can display active GitHub Copilot sessions and their associated Git worktrees. - It distinguishes active, stale, and orphaned worktrees. - Cleanup actions are available directly from the interface, reducing manual maintenance. ## Improving agent prompts - The prompt coach reviews previous agent interactions. - It identifies issues such as unclear context, spelling mistakes, and syntax problems. - It suggests ways to make prompts more precise and improve future agent results. ## Finding organizational knowledge - A knowledge finder can search sources such as Slack, Teams, email, and documentation. - It identifies people connected to a file or topic. - Results explain both who has relevant context and where that connection was found, making it easier to locate the right expert. ## Getting started Canvases are best suited to workflows where visual understanding and direct manipulation are more effective than sequential prompts. Developers can try them in the GitHub Copilot app by using `/create-canvas`, then iterating with the agent to build a workspace tailored to their task.

Read original(opens in new tab)
cloudflare3 min readCurated summary

How the 2026 World Cup affected Internet traffic

The 2026 World Cup demonstrated how a rare shared global event can reshape Internet behavior across countries. Cloudflare used traffic data from its global network to show that match timing, teams, and major storylines significantly affected online activity. Overnight matches often doubled traffic, while games during normal active hours could reduce browsing as people focused on watching. ## Measuring “Normal” Internet Activity - Cloudflare established a baseline using the median traffic from the previous four weeks. - Traffic changes were expressed as a log₂ ratio: - `0` means normal activity. - `+1` means traffic doubled. - `−1` means traffic fell to half its normal level. - This approach made traffic changes comparable between high-volume and low-volume countries. ## Kickoff Time Shaped Online Behavior - The largest traffic changes occurred during matches played between midnight and 8 a.m. local time. - Fans staying awake or waking early caused traffic to rise well above normal, sometimes by more than 2x. - Daytime matches had little effect because viewers were likely already online. - Evening matches produced a smaller increase on weekdays, but could also cause traffic to fall when people stopped browsing to watch. - In Bosnia and Herzegovina: - A 2 a.m. match caused traffic to more than double. - An evening match reduced traffic to roughly 70% of normal. - Brazil and Japan showed opposite patterns during the same match: - Japan’s overnight viewing produced traffic around twice its usual level. - Brazil’s daytime match coincided with traffic about 40% below normal. ## Matches With the Greatest Global Impact - Cloudflare measured traffic during the two hours after kickoff. - For each match, it calculated the absolute deviation from normal across countries and then used the median result. - Simultaneous matches were excluded because their effects could not be reliably separated. - The most impactful match was Argentina vs. Switzerland, with traffic changing by a factor of about 1.26. - France vs. Spain followed at 1.21. - The highest-impact games included quarterfinals, knockout matches, and some round-of-32 games—not only the final or semifinals. ## Argentina Led the Teams Drawing Global Attention - Argentina produced the largest average worldwide traffic impact, at 1.17x normal activity. - France, Brazil, Portugal, Morocco, Spain, and Norway also ranked highly. - Argentina’s appeal was linked to its status as defending champion and the possibility that the tournament could be Lionel Messi’s final World Cup. - Haiti and Iraq appeared as outliers because matches involving major teams caused especially large changes relative to their usual traffic levels. ## More Traffic to Sports Betting Websites - Requests to gambling-related websites increased after the tournament began compared with the preceding month. - Before the World Cup, betting traffic followed a regular weekly cycle. - Once matches began nearly every day, that weekly pattern flattened into a more consistent level of activity. Overall, the data shows that the World Cup affected Internet use in two distinct ways: inconvenient kickoff times brought previously offline fans online, while matches during normal usage hours often diverted people away from their usual browsing. For analyzing global events, normalized, country-by-country traffic measurements provide a clearer picture than raw request volumes alone.

Read original(opens in new tab)
stripe3 min readCurated summary

Analyzing the evidence that helps businesses win “product not received” disputes

“Product not received” disputes are Stripe’s most common nonfraud dispute category, and strong, specific fulfillment evidence is closely associated with higher win rates. Analysis of one million disputes found that physical-goods businesses benefited most from confirmed delivery data, while digital businesses benefited from usage records and processor-verified refunds. The findings suggest businesses should connect fulfillment systems to dispute workflows and submit evidence strategically. ## Delivery Evidence for Physical Goods - Delivery confirmation correlated with a **27 percentage point** higher win rate than disputes without it. - Adding a GPS delivery map increased the lift by another **15 percentage points**. - A recipient signature added a further **2 percentage points**. - Disputes containing all three forms of evidence had a **44 percentage point** higher win rate. - Many businesses fail to provide this evidence because shipping and dispute systems are disconnected, making order matching a manual, difficult-to-scale process. ## Timing of Tracking Evidence - A tracking number is much more persuasive once it shows confirmed delivery. - Evidence submitted after delivery was confirmed correlated with a **27 percentage point** higher win rate. - Evidence submitted while a package was still in transit produced only a **2 percentage point** lift. - If the response window allows, businesses should wait for delivery confirmation. - If early submission is necessary, they should document that the shipment remains within the delivery timeframe agreed to at checkout. ## Evidence for Digital Goods - Digital activity and usage logs—such as records showing that a customer streamed, downloaded, or accessed the purchased product—correlated with a **10 percentage point** higher win rate. - Service documentation, including provisioning records, produced an **8 percentage point** lift. - Specific evidence of consuming the purchased content is stronger than general proof that the customer had access to the service. ## Refund Verification - For digital-goods businesses, evidence of a full refund processed through Stripe correlated with a **63 percentage point** higher win rate. - Refunds issued through other channels, such as store credit, produced only a **6 percentage point** lift. - Processor-issued refunds are more verifiable to card issuers because they leave a record on the card network. ## Stripe’s Automated Approach - Stripe’s Smart Disputes can automatically assemble evidence packets using shipping and fulfillment data. - Businesses can provide a carrier and tracking number, after which Stripe retrieves delivery status, timestamps, and location information from supported providers. - Additional communications or documentation can be combined with the generated packet. - If no action is taken before the deadline, Smart Disputes can submit the response automatically. Businesses should prioritize specific, independently verifiable fulfillment evidence and coordinate submission timing with the actual delivery or usage status.:VEVENT

Read original(opens in new tab)
cloudflare3 min readCurated summary

Cloudflare Internal DNS is now generally available

Cloudflare Internal DNS is now generally available as a unified platform for public and private DNS. It combines recursive resolution, authoritative private zones, DNS policy enforcement, and Zero Trust controls on Cloudflare’s global network. The goal is to eliminate fragmented DNS systems and simplify split-horizon management without duplicated configurations or synchronization drift. ## Problems with Traditional Internal DNS - Organizations often manage public DNS, internal DNS, and cloud-provider DNS separately. - Separate control planes create inconsistent policies, limited visibility, and operational overhead. - Split-horizon DNS typically requires parallel environments that can drift and cause outages. - Legacy appliances introduce hardware refresh cycles and scaling constraints. ## Unified DNS and Zero Trust - Public and private DNS share one platform, API, audit trail, and policy layer. - Internal DNS is included for Enterprise customers using Cloudflare Gateway. - Gateway policies determine which users and devices can resolve specific DNS views. - Private name resolution becomes part of the broader Zero Trust architecture. ## Internal DNS Architecture Cloudflare Internal DNS has two main components: - **Gateway Resolver** - Performs recursive resolution and evaluates DNS policies. - Can filter queries or redirect them to different upstream sources. - Provides centralized logging, auditing, and policy management. - **Internal Authoritative DNS** - Serves records for private zones using Cloudflare’s authoritative DNS infrastructure. - Stores resources such as internal applications, databases, and service endpoints. The main configuration objects are: - **Internal Zones:** Authoritative records for private resources. - **DNS Views:** Resolution contexts containing one or more zones. - **Resolver Policies:** Gateway rules that route matching queries to a specific view. - **Zone references:** Allow one shared zone to be reused across multiple views without duplicating records. ## Query Resolution and Change Propagation - Queries first reach the Gateway Resolver for policy evaluation. - Matching policies route queries to an internal DNS view. - Blocked queries are dropped. - Unmatched queries use public resolution through 1.1.1.1. - Views can fall back to public DNS when a name is not found internally. - Changes from the dashboard, API, or Terraform use the same DNS Records API. - Records are validated, persisted, replicated globally, and propagated within seconds as caches are invalidated. ## Getting Started - Enterprise customers using Gateway can access Internal DNS from **Networking → Internal DNS**. - Initial setup generally requires: - Creating an internal zone and records. - Creating a DNS view and associating the zone. - Creating a Gateway resolver policy that routes users or devices to the view. - Terraform is supported and follows the same API ingestion and propagation path. ## Connectivity Cloud Integration - Internal DNS works with Cloudflare One Client, DoH, DoT, standard DNS, PAC files, and Cloudflare WAN. - Cloudflare WAN enables devices across branches, data centers, cloud environments, and remote networks to resolve internal names without installing the client on every device. - The service extends Cloudflare’s existing Connectivity Cloud rather than operating as an isolated DNS product. Cloudflare’s recommendation is to consolidate public DNS, private DNS, and DNS security policies on one control plane, particularly for organizations already using Cloudflare Gateway or WAN.

Read original(opens in new tab)
aws3 min readCurated summary

AWS Weekly Roundup: One-click Lambda setup prompt, OpenAI GPT-5.6 models on Bedrock, and more (July 20, 2026) | Amazon Web Services

The AWS Weekly Roundup highlights new tools for AI-assisted serverless development, including a one-click Lambda setup prompt that configures coding agents with AWS Serverless skills and MCP. It also covers major service updates such as OpenAI models on Bedrock, faster S3 storage-class transitions, self-managed Lambda code storage, and Cognito password-hash imports. Additional stories include SQS’s 20th anniversary, open agent protocols, DynamoDB bulk operations, and a resolved Cost Explorer billing-data incident. ## One-Click Lambda Setup for Coding Agents - The Lambda console now provides a prompt that configures AI coding agents with: - AWS Serverless skills - The Serverless Model Context Protocol (MCP) server - Embedded serverless best practices - The setup guide supports Claude Code, Kiro, Cursor, GitHub Copilot, Codex, Devin Desktop, and OpenCode. - Developers can copy the setup URL into their preferred agent: ```text fetch https://docs.aws.amazon.com/lambda/latest/dg/samples/aws-lambda-agent-setup.md ``` - AWS’s Agent Toolkit can also install the AWS MCP Server, providing current AWS knowledge and controlled resource access. ## Major AWS Service Launches - **OpenAI GPT-5.6 models on Amazon Bedrock** - Sol: flagship reasoning - Terra: balanced performance - Luna: faster, lower-cost inference - All are available through Bedrock’s Responses API and its high-performance inference engine. - **Same-day S3 transitions** - Objects can transition to S3 Standard-IA or S3 One Zone-IA on the day they are created. - The previous 30-day minimum retention period in S3 Standard no longer applies. - These classes can reduce storage costs by up to 40% while retaining millisecond access. - Suitable for backups, log analytics, and compliance data that becomes cold quickly. - **Self-managed Lambda code storage** - Lambda can reference code directly from customer-owned S3 buckets. - Lambda no longer needs to create intermediate copies. - This removes code-storage limits and can shorten activation times after deployments. - **Cognito password-hash imports** - CSV user imports can now include password hashes. - Users can sign in immediately with existing credentials instead of resetting passwords. - Import configuration specifies the source system’s hashing algorithm. ## Additional AWS Updates - **Amazon SQS at 20** - SQS continues to provide scalable decoupling between message producers and consumers, two decades after its public launch. - **Open protocols with Strands Agents SDK** - An example demonstrates how MCP, A2A, UTCP, AG-UI, and x402 can work together when building AI agents. - **Open-source DynamoDB Bulk Executor** - Performs large-scale table operations without custom code. - Supports `count`, `find`, `delete`, and `update` commands. - **Kiro CLI for AWS Support** - MCP integration combines investigation, documentation lookup, and support-case creation. - Examples cover Glue failures, Lambda cold starts, and WAF false positives. ## Cost Explorer Incident - Some customers saw inaccurate estimated billing and usage data in Cost Explorer. - The issue generated erroneous budget and cost-anomaly alerts. - AWS resolved the incident and is conducting a retrospective to improve billing-incident prevention and response. AWS’s latest releases emphasize faster serverless development, more capable AI tooling, lower-cost storage, and easier automation of operational tasks. Developers should explore the Lambda agent setup and Agent Toolkit while reviewing the new storage, identity, and bulk-operation capabilities for relevant workloads.

Read original(opens in new tab)
spotify3 min readCurated summary

Content Ingestion & Podcast Video Incident Report | Spotify Engineering

Spotify’s June 24 publishing incident delayed video podcast episodes for several hours after transcoding capacity was overwhelmed. The disruption resulted from insufficient capacity headroom, a concurrent batch job, increased processing costs, and a scheduling bug that reduced throughput by about 10%. Spotify cleared the backlog by the following morning and has since expanded capacity, improved monitoring, and launched a broader publishing reliability initiative. ## What Caused the Delay - A spike in new video podcast submissions pushed transcoding infrastructure close to its maximum capacity. - A scheduled batch job was reprocessing existing episodes, consuming capacity needed for new publications. - Recent video-quality improvements increased the processing time and compute required per episode. - A resource-scheduling bug following an infrastructure migration underused available hardware, reducing throughput by approximately 10%. - Creators re-uploaded missing episodes, unintentionally adding more load because Spotify did not clearly confirm that uploads had been received and queued. ## Incident Timeline and Response - Early monitoring alerts fired at 13:30 UTC, but they were not initially recognized as a broader capacity problem. - At 15:00, a delivery spike brought transcoding close to capacity. - The batch job was stopped at 16:35 to free resources. - Formal incident response began at 17:34 after queue thresholds were exceeded. - A scheduling fix was deployed at 20:49, and an additional processing cluster came online at 00:14 on June 25. - All queues were cleared by 01:02, with normal pipeline operation confirmed at 07:30. - Approximately four hours passed between the first alerts and formal incident response, highlighting a major monitoring and escalation gap. ## Remediation Measures - Spotify increased transcoding capacity by approximately 67% to provide more room for traffic spikes and batch processing. - The resource-scheduling bug was fixed, restoring use of previously underutilized compute capacity. - Monitoring was improved to warn earlier when capacity is approaching operational limits. ## Broader Reliability Program - Capacity planning is being expanded to account for burst traffic, background workloads, and recovery needs—not only typical steady-state demand. - Publishing systems will prioritize real-time creator uploads over background operations. - Spotify is extending rate limiting and backpressure mechanisms across the pipeline so unexpected load can be handled more gracefully. - A dedicated cross-team effort is coordinating these improvements across the publishing infrastructure. Spotify’s main lesson is that reliable publishing requires both additional capacity and better operational safeguards. Earlier detection, clearer upload acknowledgments, stronger workload prioritization, and deliberate burst-capacity planning should reduce the likelihood and impact of similar incidents.

Read original(opens in new tab)
dropbox3 min readCurated summary

How our universal content processing platform Riviera evolved for AI and beyond

Riviera evolved from Dropbox’s preview-generation service into a shared content-processing platform used by products including Search, Replay, Sign, and Dash. Its core insight was to compose reusable transformations rather than build separate pipelines for every file type and output. As AI increased demand for consistent document extraction and preparation, Dropbox expanded Riviera’s capabilities and began offering them through APIs and Model Context Protocol tools. ## The Preview Problem - Dropbox supports more than 300 file formats, each requiring outputs such as: - Thumbnails - Full previews - Extracted text - Streaming manifests - Metadata - Building a separate service for every format and output would duplicate logic, dependencies, and operational work. - Configurations and package versions could drift across services, making the system harder to maintain and scale. ## Reusable Transformations as the Foundation - Riviera treats previews as sequences of smaller, reusable transformations. - For example, a PowerPoint preview can be produced by: - Converting the presentation to PDF - Rendering each PDF page as an image - The same PDF-to-image transformation can support PDFs and other workflows requiring page images. - This approach enables new formats and products to reuse existing capabilities instead of starting from scratch. ## Separating Coordination from Execution - Riviera uses a central coordinator to: - Collect and validate requests - Compose transformation workflows - Cache responses - Dispatch jobs to backend workers - Each worker handles a specific transformation, creating a clear unit for maintenance and scaling. - The platform now includes more than 100 capabilities and performs hundreds of thousands of transformations per second. - New formats and transformations can generally be added as plugins without changing the core system. ## From Internal Service to Shared Platform - Other Dropbox teams quickly adopted Riviera when they discovered overlapping content-processing needs. - Machine learning teams reused preview thumbnails for image normalization, avoiding duplicate generation. - Search used Riviera to prepare documents for indexing, while Sign, DocSend, and Replay reused existing transformations. - Dropbox eventually opened the plugin model to product teams, allowing them to add capabilities while the Riviera team maintained the platform’s core architecture. - Replay particularly benefited from Riviera’s complex video transcoding and manipulation capabilities, accelerating product development from months to weeks. ## Supporting AI Workloads - Dash introduced greater demand for reliable document preparation before AI processing. - AI systems require content to be transformed into consistent, machine-readable representations, including: - Extracted text - Data from scanned pages - File metadata - Normalized versions of hundreds of file types - These are fundamentally content-transformation challenges rather than AI-model challenges. - Because Riviera already supported many formats and transformations, Dash could build on existing infrastructure instead of creating a separate document-processing system. ## Broader Availability - Dropbox is making Riviera’s capabilities available to external developers and design partners. - Access is provided through APIs and Model Context Protocol tools. - The platform is intended for applications such as content management, document automation, search indexing, and AI document processing. Riviera’s evolution demonstrates the value of a shared transformation platform: reusable workers reduce duplication, centralized coordination improves reliability, and each new capability benefits multiple products. For teams building content-heavy or AI-powered applications, using standardized transformation infrastructure can be more efficient than maintaining format-specific pipelines independently.

Read original(opens in new tab)
gitlab3 min readCurated summary

GitLab Transcend Hackathon: What developers built on GitLab Orbit

GitLab’s Transcend Hackathon showed how developers use GitLab Orbit’s live code graph to answer questions about dependencies, ownership, testing, deployments, and risk. Of 1,576 registered participants, teams submitted 265 eligible projects, while contributors also merged 61 improvements into Orbit itself. The strongest projects used graph-based context to improve change analysis, migrations, testing, security response, and agent governance. ## Problems Developers Targeted - Around 70 teams built tools to predict what a change might break before merging. - More than 30 focused on onboarding and codebase comprehension. - Other common use cases included: - Incident root-cause analysis - Architecture drift detection - Flaky-pipeline diagnosis - CVE tracing across repositories - The popularity of these projects reflected a shared problem: relevant information is scattered across Git, CI, deployment systems, and dashboards. - Orbit consolidates those relationships into a queryable graph that agents can access through MCP or engineers can query directly. ## Technological Implementation - **Winner: Sankofa** - Provides three agents triggered by different workflow events: - **Radar** analyzes merge-request blast radius, affected pipelines, and ownership. - **Guide** prepares briefs when issues are assigned. - **Shield** traces vulnerabilities through the dependency graph. - Shield can identify a vulnerability’s full reach in one graph traversal. - **Runner-up: Stayed Shipped** - Measures whether changes merged by AI agents remain in production. - Detects changes that were later silently fixed forward, a result standard dashboards often miss. ## Design and Usability - **Winner: Carver** - Estimates the cost and risk of legacy migrations using Orbit’s dependency graph. - Breaks work into units, estimates effort and generation cost, and highlights untested, high-risk services. - Refuses to invent estimates when the relevant service cannot be grounded in Orbit. - **Runner-up: Marshal** - Takes an organization-wide migration goal, identifies affected repositories, sequences the work, and creates merge requests in waves. ## Potential Impact - **Winner: CrossCut** - Selects only tests that a change can actually affect. - Traverses Orbit’s call graph from changed symbols to determine transitive test impact. - Can reduce CI workloads by 90% or more on large or cross-repository suites. - **Runner-up: OrbitWeaver** - Performs autonomous refactoring using exact graph-based blast radius rather than vector similarity. - Updates affected files in dependency order, reducing the risk of incomplete refactors and broken pipelines. ## Quality of the Idea - **Winner: Transcend** - Extends Orbit with OWL, SPARQL, RDF, and semantic-web reasoning. - Supports queries involving transitive closure, external knowledge bases, and complex joins beyond the native API. - Its demonstration connected code implementing knowledge-graph embedding methods with related papers, authors, and publication years. - **Runner-up: Universal Agent OS** - Focuses on agent governance rather than agent capabilities. - Requires agents to interview users, plan before coding, preserve evidence, and validate their work. - Emphasizes accountability as AI-generated code becomes more common. ## Contributions to Orbit - The Contribute Track produced 61 merged merge requests from 26 contributors. - Improvements included: - Support for C++20 concepts, Go package declarations, Kotlin coroutines, and Ruby lambdas - Ontology corrections - A CI SIGPIPE fix - The first Orbit query tutorial - Documentation fixes, including clarification of `max_depth` versus `max_hops` - Nineteen contributors received cash prizes, and all participants earned swag credits. GitLab Orbit’s strongest value is not simply agent orchestration but the structured context behind it. Teams building reliable developer automation should prioritize a live dependency and ownership graph, using precise traversal where correctness matters more than probabilistic retrieval.

Read original(opens in new tab)
gitlab2 min readCurated summary

Automate work item assignment with GitLab Duo

The GitLab Duo Agent Platform’s new **“Work item created”** trigger automates triage as soon as an issue or other work item is created. A custom flow can assess team workloads and assign the item without manual intervention, improving speed and workload balance. The post demonstrates this using two agents and GitLab Orbit. ## The Problem with Manual Assignment - Team members must repeatedly check capacity, workload, meetings, and PTO before routing each work item. - Manual triage becomes slow and inconsistent as issue volume grows. - Previously, GitLab Duo Flows required a human action—such as a mention or assignment—to start. ## How the Trigger Works - The trigger fires immediately when a work item is created in a configured project. - Flows run continuously in the background without requiring someone to initiate them. - This enables instant, scalable routing while developers focus on higher-value decisions. ## Benefits of Automated Triage - Assigns and routes work immediately. - Handles anything from a single issue to hundreds of items. - Applies workload and availability criteria consistently. - Removes repetitive assignment work from team leads and developers. ## Example: The “Work Item Assigner” Flow - The demonstrated flow runs in the `Intra-account-transfers` project. - Its first agent uses GitLab Orbit to determine each resource’s number of open work items across the top-level group. - A second agent identifies the least-loaded person and assigns the new work item to them. - When a new issue is created, the flow activity log shows both agents executing their steps. - In the example, the issue is automatically assigned to William, who has the lightest workload. ## Potential Enhancements - Connect the flow to HR or PTO systems through Model Context Protocol (MCP) to account for upcoming leave. - Integrate team calendars to consider real-time availability when making assignments. The post recommends using the “Work item created” trigger with workload-aware agents to automate routine assignment decisions, achieve faster triage, and distribute work more evenly.

Read original(opens in new tab)
netflix4 min readCurated summary

In-House LLM Serving at Netflix

Netflix built an in-house LLM serving platform within its existing production ML infrastructure rather than creating a separate ML stack. The platform combines a JVM-based serving layer, NVIDIA Triton, GPU-backed Model Scoring Service, and an OpenAI-compatible HTTP frontend. Its main design choices—vLLM, model packaging, API compatibility, and deployment strategy—prioritize operational flexibility and seamless movement from hosted models to self-hosted ones, while production exposed versioning and compatibility risks. ## Architecture and Serving Model - Netflix’s unified JVM serving system handles routing, A/B testing, feature retrieval, inference, post-processing, and logging. - Callers access models through: - A gRPC path integrated with the existing serving system. - A direct HTTP path for newer LLM applications. - Small CPU models run in-process to avoid remote-call overhead. - Larger GPU models run through Model Scoring Service (MSS), which supports XGBoost, TensorFlow, PyTorch, and LLMs. - NVIDIA Triton manages model loading, batching, and GPU scheduling. - A Java control plane provides deployment, versioning, health checks, autoscaling, and multi-region rollout. ## Choosing vLLM as the Standard Engine - Netflix originally used TensorRT-LLM, but re-evaluated its choice as open-source engines improved and workloads diversified. - vLLM was selected based on operational fit rather than benchmark performance alone: - Supports custom model architectures without lengthy compilation. - Provides hooks for custom decoding and constraint logic. - Is easier to debug than earlier compiled-engine workflows. - Is familiar to many researchers, reducing the research-to-production transition cost. - The workload includes embeddings, prefill-only inference, autoregressive decoding, and custom per-step decoding constraints. ## Triton Integration and Model Packaging - Triton offers both a Python backend and a dedicated vLLM backend. - The Python backend requires explicit input and output tensor definitions, coupling packaged artifacts to frontend changes. - The vLLM backend uses a JSON configuration pointing to model weights and tokenizers, generating tensor specifications dynamically. - Netflix considers the vLLM backend the preferred default because models and frontends can evolve independently. - Production revealed two limitations: - Triton and vLLM must be version-pinned because incompatible APIs can prevent the backend from loading entirely. - Models requiring custom preprocessing, postprocessing, tokenization, or ensemble execution still need Triton’s Python backend. ## OpenAI-Compatible HTTP Frontend - Netflix keeps LLMs compatible with the same internal gRPC model-serving interface used by other model types. - It also exposes an OpenAI-compatible API because that interface is widely supported by inference engines, orchestration tools, evaluation systems, and client libraries. - This makes replacing a hosted model with a fine-tuned self-hosted model largely transparent to callers. - The implementation uses Triton’s OpenAI-compatible frontend, FastAPI, and a `TritonLLMEngine` that translates requests into Triton inference calls. - KServe HTTP and gRPC frontends remain available for the Java control plane. - Netflix found that Triton’s frontend silently discarded the `response_format` parameter, meaning JSON requests could reach vLLM without guided decoding and produce malformed output. - The team patched the frontend to translate `response_format` into vLLM guided-decoding parameters. ## Deployment and Rollout Strategies - GPU services require longer startup times than CPU services, and model versions may change input/output schemas. - Netflix supports Red-Black deployment: - Runs the new version alongside the old one. - Performs health checks before shifting traffic. - Gradually scales up the new version while scaling down the old one. - Supports atomic rollback if deployment fails. - Red-Black deployment works well when the model interface remains stable. - Production exposed a schema-coordination problem: if a new model changes tensor dimensions or other I/O requirements, upstream callers may send old requests to the new model during the migration window, causing failures. - The post introduces a Versioned strategy as a solution, but the provided text ends before explaining its implementation. Netflix’s experience suggests that successful in-house LLM serving depends as much on compatibility and deployment mechanics as on raw inference speed. A practical platform should standardize on an extensible engine such as vLLM, preserve ecosystem-compatible APIs, tightly control engine versions, retain escape hatches for custom models, and explicitly coordinate model-schema changes during rollout.

Read original(opens in new tab)
cloudflare2 min readCurated summary

Cloudflare WAF protects WordPress applications from two high-severity vulnerabilities

Cloudflare has deployed WAF protections for two serious WordPress vulnerabilities: a high-severity SQL injection and a critical unauthenticated remote code execution flaw. The rules protect proxied WordPress sites on both free and paid Cloudflare plans, but they only reduce exposure while sites are patched. WordPress updates remain essential, with fixes available in versions 6.8.6, 6.9.5, 7.0.2, and 7.1 Beta 2. ## Vulnerabilities and Affected Versions - **CVE-2026-60137 — SQL injection** - Affects WordPress 6.8 and later. - Crafted input can alter database queries. - Rated High. - **CVE-2026-63030 — Unauthenticated RCE** - Affects WordPress 6.9 and later. - Exploits the REST API batch endpoint when persistent object caching is not enabled. - Requires no authentication or user interaction. - Rated Critical. - Versions earlier than 6.8 are not affected. - WordPress 6.8.6 fixes the SQL injection; later listed releases fix both vulnerabilities. ## Cloudflare WAF Protections - Cloudflare deployed the protections at **17:03 UTC on July 17, 2026**. - Both rules are enabled with a default **Block** action: - SQL injection rule: `1c060d3a371549219ee290d7ed933fcc` for Managed Rules and `db003b39b7774859a8d588ce33697a1a` for the Free Ruleset. - RCE rule: `7dfb2bd4708d4b88b9911dc0550664b6` for Managed Rules and `ebd3f2df15c74ddcbf6220c9b5ec246a` for the Free Ruleset. - The SQL injection rule blocks malicious parameter values before they reach WordPress. - The RCE rule targets requests attempting to access the vulnerable REST API path. ## Customer Actions - Pro, Business, and Enterprise customers should ensure Cloudflare Managed Rules are enabled. - Free-plan customers receive protection automatically through the Free Ruleset. - Review ruleset overrides, especially configurations that change blocking to logging. - Monitor Cloudflare Security Events for requests matching either rule. - Confirm that WordPress automatic updates succeeded and that the site runs a patched release. ## Ongoing Protection Cloudflare will monitor matching traffic and refine detections as attackers develop new variations. The WAF rules provide defense in depth, but they cannot repair vulnerable WordPress code. Administrators should patch WordPress immediately, verify that both WAF rules remain active with the **Block** action, and investigate suspicious requests if updating is temporarily impossible.

Read original(opens in new tab)
github1 min readCurated summary

The cost of saying yes has changed

Dalia is a software engineer on GitHub’s Copilot Agent Control Plane team. Her work focuses on building the subagent governance layer for Copilot customers. ### Role and Focus - Works on GitHub Copilot’s Agent Control Plane. - Builds governance capabilities for subagents. - Supports Copilot customers through controls and management features. The provided content contains only a brief professional description, not a full blog post, so there are no additional technical sections or conclusions to summarize.

Read original(opens in new tab)