Techlist.io - Korean Tech Blog Curator

pinterest3 min readCurated summary

Ads Candidate Generation using Behavioral Sequence Modeling

Pinterest’s Ads team uses behavioral sequence modeling to improve ad candidate generation by predicting what users are likely to convert on next. Transformer-based two-tower models first predict relevant advertisers and then specific products, using offsite activity such as views, purchases, and add-to-cart events. The advertiser model is already in production, while item-level modeling addresses Pinterest’s rapidly growing catalog and enables more precise, scalable personalization. ## Predicting Advertiser Interaction - A bidirectional Transformer encodes each user’s behavioral event sequence. - An MLP-based advertiser tower represents candidate advertisers. - Training uses: - In-batch negative samples - Sampled softmax loss - Positive events consisting of checkout, add-to-cart, or signup conversions within a future K-day window - Log-Q bias correction to avoid excessively penalizing popular advertisers - The model is evaluated with Recall@K by comparing user and advertiser embedding similarity against an indexed set of roughly 2 million advertisers. - An offline batch job generates each user’s top 100 advertisers and publishes them to the online feature store. - During ad serving, eligible ads from those advertisers are passed to the L1 ranker, blended with other candidate sources, and scored by heavier downstream models and the marketplace auction. - Online experiments produced higher conversion volume and lower cost per action. - The advertiser-level model has served production traffic for Standard ads since Spring 2024. ## Moving from Advertisers to Products - Pinterest next sought to predict the specific products a user would interact with, rather than only the likely advertiser. - Item-level prediction better matches the item-based ad delivery funnel and avoids forcing downstream models to score an impractically large set of products from selected advertisers. - The approach aims to capture both immediate intent and longer-term interests. ## Item-Level Model Architecture - The model retains the two-tower design: - A user tower encodes behavioral sequences. - An item tower represents individual shopping product Pins. - Item representations combine: - Internal Pin embeddings learned from Pinterest’s engagement graph - Product metadata from the merchant catalog - Because the catalog exceeds 1 billion items, training uses both in-batch negatives and a randomly sampled negative set of 20 million Pins. - The model uses the same conversion labels as the advertiser model. - Label weights and log-Q parameters are tuned to balance retrieval quality with diversity across both products and advertisers. - Daily inference updates user embeddings only for users with new activity, appending them to a previous feature-store snapshot to reduce computation. - The trained item tower indexes hundreds of millions of ad items. ## Evaluation and Diversity - Item retrieval is evaluated using cosine similarity and hit rates at different K values. - Final model selection considers both: - Item-level Recall@K - Advertiser-level Recall@K - Qualitative review is also important because offsite activity is sparse and noisy. - The model is compared with max-pooling and mean-pooling baselines that use aggregated embeddings without Transformer-based sequence modeling. - The evaluation emphasizes that strong retrieval must also produce semantically relevant and sufficiently diverse recommendations. Pinterest’s progression from advertiser prediction to item prediction shows how behavioral sequence models can make ad retrieval more personalized while remaining scalable. A practical system should combine sequence-aware user representations, large-scale approximate retrieval, and explicit controls for popularity, diversity, and computational efficiency.

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

My Journey to Airbnb: Peter Coles

Peter Coles’s career connects mathematical training, academic economics, and practical data science. After studying game theory and market design, he moved from Harvard Business School to eBay and then Airbnb, where he could apply economic models to real-world marketplaces. At Airbnb, he helped build economics and data science teams, guide policy decisions, investigate pandemic-driven changes, and measure the company’s broader impact. ## From Mathematics to Economics - Coles grew up in Milwaukee and developed an early interest in marketplaces by trying to run a neighborhood rock stand. - He studied math at Princeton after briefly pursuing ancient history. - He earned a PhD in economics at Stanford, focusing on game theory—the study of strategic decision-making. - His mentor, Jon Levin, taught him to simplify complex research problems. - While studying in Germany, Coles traveled around Europe and stayed with strangers connected to classmates, unintentionally experimenting with a model similar to Airbnb. ## Studying Markets and Market Design - At Harvard Business School, Coles researched market design and taught with Al Roth, who later won the Nobel Prize in Economics. - His work focused on “matching,” or designing systems that pair participants from two groups when prices cannot directly balance supply and demand. - He studied participant strategy, signaling, and market mechanisms, including improvements to the market for PhD economists. - He also wrote business cases about companies such as Zillow, Microsoft, and Craigslist. - Although he valued academia, he found the long research and peer-review cycle was not a good long-term fit. ## Applying Economics at eBay - In 2013, Coles joined eBay as technology and the sharing economy were rapidly expanding. - He led an economics team created by Steve Tadelis and helped combine it with another group to form eBay’s Data Labs. - One notable project, “What’s It Worth,” developed a method for estimating the fair market value of items sold on eBay. - The work combined economic reasoning, practical marketplace knowledge, and statistical modeling. ## Building Airbnb’s Economics and Data Science Functions - In 2015, Coles joined Airbnb to help address the company’s growing regulatory challenges. - He built a global team of economists and data scientists to study short-term rentals and their relationship with cities. - The team used data to inform policy discussions and evaluate Airbnb’s effects on guests, hosts, and communities. - This role allowed Coles to connect economic theory with decisions affecting a rapidly expanding platform. ## Central Strategy & Insights - As Airbnb grew, executives needed analysis that crossed organizational boundaries. - Coles and Jackson Wang founded Central Strategy & Insights, known as CSI. - The team acted as “forensic investigators,” assembling evidence and narratives from company-wide data. - During the pandemic, CSI analyzed major changes in guest travel patterns and determined what kinds of supply Airbnb would need. - The team also led business reviews and prepared analyses for shareholders before Airbnb’s IPO. ## Measuring Airbnb’s Broader Impact - Coles later returned to policy-focused work with a larger economics organization. - The team developed models to guide Airbnb’s response to governments as travel recovered after the pandemic. - Economists and analysts evaluated Airbnb’s impact on hosts, guests, and society. - Their work included the US Economic Impact Report and expanded collaboration with academic researchers using Airbnb data. Coles’s experience suggests that marketplace companies benefit from combining rigorous economic research with hands-on data science. Moving between academia and industry enabled him to turn theories about market design into practical tools for product strategy, policy, and impact measurement.

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

Towards a science of scaling agent systems: When and why agent systems work

AI agent systems do not improve simply by adding more agents. Google Research’s evaluation of 180 configurations found that coordination helps substantially on parallelizable tasks but can severely hurt sequential workflows and tool-heavy tasks. The study proposes measurable design principles and a predictive model that selected the best architecture for 87% of unseen tasks. ## Defining Agentic Tasks The study distinguishes agentic tasks from static benchmarks by requiring: - Sustained, multi-step interaction with an external environment. - Iterative information gathering under partial observability. - Adaptive strategy changes based on environmental feedback. Researchers tested five architectures across Finance-Agent, BrowseComp-Plus, PlanCraft, and Workbench: - **Single-agent:** One agent handles reasoning and actions sequentially. - **Independent:** Agents work in parallel without communication and combine results at the end. - **Centralized:** An orchestrator delegates work and synthesizes outputs. - **Decentralized:** Agents communicate directly in a peer-to-peer network. - **Hybrid:** Hierarchical oversight is combined with peer coordination. ## Coordination Must Match the Task - Multi-agent systems produced very different results across GPT, Gemini, and Claude models. - On parallelizable financial reasoning tasks, centralized coordination improved performance by **80.9%** over a single agent. - Parallel agents can independently analyze areas such as revenue, costs, and market comparisons before combining their findings. - On sequential planning tasks, every multi-agent architecture performed worse, with declines of **39–70%**. - Communication and synchronization overhead can fragment reasoning and consume the available cognitive budget. ## The Tool-Coordination Trade-off - As tasks require more tools, coordinating multiple agents becomes increasingly expensive. - Tool-heavy systems, such as coding agents with access to 16 or more tools, face a disproportionate coordination “tax.” - Adding agents is therefore especially risky when actions must be tightly ordered or frequently synchronized. ## Architecture and Reliability - Architecture affects not only performance but also how errors spread. - Independent agents amplified errors by up to **17.2×**, because no mechanism checked their intermediate results. - Centralized systems limited error amplification to **4.4×**. - An orchestrator acts as a validation bottleneck, detecting and containing mistakes before they propagate. ## Predicting the Best Architecture - The researchers built a predictive model using properties such as task decomposability and tool count. - The model achieved an **R² of 0.513**. - It correctly predicted the optimal coordination strategy for **87% of unseen task configurations**. - These results point toward systematic, task-driven agent design rather than relying on the assumption that more agents are always better. For practical deployments, choose architecture based on the task: use coordinated parallel agents for decomposable work, simpler sequential systems for tightly ordered reasoning, and centralized oversight when reliability and error containment are priorities.

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

The AI Evolution of Graph Search at Netflix

Netflix is evolving Graph Search from structured DSL queries toward natural-language search using large language models (LLMs). The goal is to let users describe what they want in everyday language while preserving the accuracy and trustworthiness required by Netflix’s complex, federated GraphQL data. Rather than replacing existing applications, Netflix plans to augment them with AI-generated filters and future retrieval-augmented generation capabilities. ## Why Natural-Language Search Is Needed - Graph Search currently relies on a Filter DSL, with applications translating UI interactions into structured queries. - Netflix has hundreds of applications with inconsistent query-building experiences, forcing users to learn different interfaces. - Some indexes contain hundreds of filterable fields, making large forms slow and cumbersome even for subject-matter experts. - Users naturally express goals in language such as “show all movies from the 90s about robots from the US,” not through query builders or DSL syntax. - Natural-language input could reduce friction while allowing each application to retain its own domain-specific presentation. ## Converting Text into Graph Search Filters - The core task is translating an ambiguous natural-language request into a valid Graph Search Filter DSL statement. - Graph Search indexes are defined through GraphQL queries containing typed fields, including booleans, strings, enums, and controlled vocabularies. - Generated filters can combine: - Comparisons such as `>` and `==` - Inclusion or exclusion operators such as `IN` - Logical operators such as `AND` - Netflix evaluates generated queries at three levels: - **Syntactic correctness:** The statement follows the DSL grammar and can be parsed. - **Semantic correctness:** The query uses existing fields, respects field types, and selects valid controlled-vocabulary values. - **Pragmatic correctness:** The filter accurately reflects the user’s intended meaning. ## Context Engineering for the LLM - The LLM needs index metadata to generate semantically valid filters. - Netflix derives much of this context from GraphQL schemas, including: - Field paths - Field descriptions from schema comments - Field types - Valid enum or controlled-vocabulary values - Controlled vocabularies define finite, governed sets of values, such as countries, and prevent generated queries from using invalid alternatives. - Supplying all metadata works for simple examples but does not scale: - Some indexes contain hundreds of fields. - Some vocabularies contain thousands of values. - Larger prompts increase latency and can reduce generation accuracy. - Netflix therefore needs ways to provide the LLM with relevant metadata without overwhelming its context, while still grounding generated queries in the actual schema and allowed values. Netflix’s approach combines schema-aware context, LLM-based query generation, and validation to make natural-language Graph Search practical. The key recommendation is to use AI as an augmentation layer over existing Graph Search applications, with strong grounding and correctness checks rather than treating generated queries as inherently reliable.

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

Rust at Scale: An Added Layer of Security for WhatsApp

WhatsApp has deployed a Rust-based media security layer across billions of devices to defend against malware hidden in images, videos, PDFs, and other attachments. The system, called Kaleidoscope, validates file formats and identifies suspicious content before it reaches vulnerable downstream libraries. WhatsApp’s large-scale rollout demonstrates Rust’s production readiness and supports the company’s broader shift toward memory-safe languages. ## Media Handling as a Security Boundary - WhatsApp’s default end-to-end encryption protects messages, but shared media can still contain maliciously crafted files. - Attackers may exploit vulnerabilities in: - Operating system libraries - Media parsers - WhatsApp itself - Dangerous attachments can appear harmless, particularly when malware is concealed in images or videos. ## Lessons from the 2015 Stagefright Vulnerability - Android’s Stagefright vulnerability affected operating-system media-processing libraries. - Applications could not directly patch the vulnerable libraries, while users often took months to update their devices. - WhatsApp adapted its existing cross-platform C++ `wamedia` library to identify malformed MP4 files that could trigger vulnerable parsers. - This allowed WhatsApp to protect users faster than relying solely on operating-system updates. - Because the library automatically processes untrusted downloads, WhatsApp identified it as a strong candidate for memory-safe implementation. ## Replacing C++ with Rust - WhatsApp developed the Rust implementation alongside the original C++ version rather than performing a gradual rewrite. - Differential fuzzing, unit tests, and integration tests verified compatibility. - Key challenges included: - Increased binary size from the Rust standard library - Build-system support for WhatsApp’s many target platforms - The final implementation replaced approximately 160,000 lines of C++ with 90,000 lines of Rust, including tests. - Rust provided performance and runtime memory-use improvements. - The library was deployed across Android, iOS, Mac, Web, wearables, and other platforms. ## Kaleidoscope’s File Checks - Kaleidoscope expands beyond basic MP4 validation by checking for: - Non-conforming structures that could exploit parser differences - Embedded files and scripts in PDFs - Files that disguise their type through spoofed extensions or MIME types - Known dangerous formats such as executables and applications - These checks support safer handling in WhatsApp’s user interface and help defend against malicious attachments and unofficial clients. - The system cannot prevent every attack, but it adds an important defense-in-depth layer. ## WhatsApp’s Broader Security Strategy - WhatsApp distributes the libraries each month to billions of phones, computers, watches, and browsers across WhatsApp, Messenger, and Instagram. - The company describes this as the largest deployment of Rust code across diverse end-user platforms. - Its wider security program includes: - End-to-end encrypted messages, calls, and backups - Key transparency and additional calling protections - Fuzzing, static analysis, audits, and attack-surface monitoring - CVE reporting and an expanded bug bounty program - WhatsApp’s vulnerability strategy focuses on minimizing attack surface, strengthening remaining C and C++ code, and choosing memory-safe languages for new development. - Existing protections include control-flow integrity, hardened allocators, safer buffer APIs, specialized developer training, and automated analysis. WhatsApp plans to accelerate Rust adoption, particularly for security-sensitive, cross-platform components that process untrusted input. Its media library rollout provides evidence that Rust can deliver both memory safety and performance at global consumer scale.

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

Building a serverless, post-quantum Matrix homeserver

The post describes a proof-of-concept Matrix homeserver ported from Synapse to Cloudflare Workers. It replaces traditional VPS, PostgreSQL, Redis, and filesystem infrastructure with Workers, Durable Objects, D1, KV, and R2, reducing operational overhead and allowing costs to fall near zero when idle. The design also provides post-quantum TLS automatically while preserving Matrix’s end-to-end encryption, though the homeserver still exposes metadata. ## From Synapse to Cloudflare Workers - Traditional Synapse deployments depend on: - PostgreSQL for persistent state - Redis for caching - Filesystem storage for media - VPS infrastructure and operational maintenance - The proof of concept reimplemented core Matrix functionality in TypeScript with Hono, including: - Event authorization - Room state resolution - Cryptographic verification - Cloudflare services replace the traditional components: - Durable Objects provide strongly consistent, atomic coordination. - D1 replaces PostgreSQL. - KV replaces Redis. - R2 replaces filesystem-based media storage. ## Benefits of a Serverless Homeserver - Deployment becomes a single `wrangler deploy` command. - Cloudflare provides TLS termination, load balancing, DDoS protection, and global distribution. - Request-based pricing means the homeserver can cost almost nothing during periods of inactivity. - Workers execute close to users in more than 300 locations, reducing latency for globally distributed communities. - Built-in security features reduce the need to configure firewalls, rate limiting, WAF rules, and IP reputation systems manually. ## Post-Quantum TLS and Matrix Encryption - Cloudflare’s TLS 1.3 connections use hybrid `X25519MLKEM768`. - This combines: - X25519, a classical elliptic-curve algorithm - ML-KEM, a lattice-based post-quantum algorithm standardized by NIST - The hybrid design requires both cryptographic systems to be broken before the connection is compromised. - Traditional deployments would need to upgrade cryptographic libraries, configure cipher suites, test client compatibility, and monitor negotiation failures. - Workers provide this protection automatically through Cloudflare’s infrastructure. ## How Messages Are Protected - Matrix clients encrypt messages locally using Megolm before sending them. - The encrypted Megolm payload is then transported over TLS using post-quantum hybrid key agreement. - The Worker terminates TLS but receives only ciphertext, which it stores and routes without seeing plaintext. - Recipients download the ciphertext over another protected TLS connection and decrypt it locally. - This creates two independent encryption layers: - TLS protects data in transit. - Megolm end-to-end encryption protects message contents from the homeserver and infrastructure providers. ## Metadata and Privacy Limits - The homeserver operator can still observe metadata, including: - Room membership - Room existence - Message timing - Other routing and account information - Message contents remain inaccessible because they are encrypted before reaching the server. - Encrypted-room media is also encrypted client-side, and private keys remain on user devices. ## Storage Architecture - The design assigns each storage primitive to the consistency model it supports best. - D1 stores durable, queryable Matrix data, including users, rooms, events, and device keys across more than 25 tables. - Durable Objects handle real-time coordination and the strong consistency needed for Matrix state resolution. - KV provides cache-like storage, while R2 handles media and filesystem-style objects. The project demonstrates that a Matrix homeserver can be made substantially easier to operate with serverless infrastructure while gaining globally distributed execution and automatic post-quantum transport security. It remains a personal proof of concept, so production deployments should evaluate feature completeness, scalability, compatibility, and the privacy implications of relying on Cloudflare.

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

ATLAS: Practical scaling laws for multilingual models

ATLAS introduces practical scaling laws for training multilingual language models, addressing the lack of public guidance for non-English systems. Based on 774 runs covering 400+ languages and models from 10M to 8B parameters, it predicts how to combine languages, data, and model capacity efficiently. The study finds strong cross-lingual transfer, a manageable multilingual capacity tax, and clear trade-offs between fine-tuning and pretraining from scratch. ## Adaptive Scaling for Multilingual Mixtures - ATLAS extends traditional scaling laws with: - A cross-lingual transfer matrix identifying helpful language combinations. - Rules for scaling model size and data as supported languages increase. - Guidance on whether to pretrain from scratch or fine-tune a multilingual checkpoint. - It separates training data into: - The target language. - Similar “transfer languages,” such as Spanish, Portuguese, and Italian for Catalan. - All other languages. - This allows ATLAS to estimate which languages help or hinder a target language. ## Evaluation Across Languages and Model Sizes - Experiments used MADLAD-400, spanning more than 750 monolingual, bilingual, and multilingual runs. - ATLAS outperformed earlier scaling laws when predicting performance for new: - Model sizes. - Data volumes. - Language mixtures. - Optimal scaling patterns were broadly similar across English, French, Russian, Chinese, Hindi, and Swahili. - Multilingual vocabularies and data impose a compute-efficiency tax, particularly for English. - Low-resource languages eventually encounter data repetition, causing their scaling curves to bend upward. ## Cross-Lingual Transfer - The transfer matrix measures how training on one language affects another. - Examples of strong transfer include: - Norwegian benefiting from Swedish and German. - Malay benefiting from Indonesian. - Arabic benefiting from Hebrew. - English, French, and Spanish are broadly useful training languages, partly because of their large, diverse, and high-quality web corpora. - Shared writing systems and language families are the strongest predictors of positive transfer, with statistical significance of p < .001. - Transfer is asymmetric: language A may help language B more than B helps A. - The results replace informal language-selection assumptions with empirical data. ## Scaling the Number of Supported Languages - ATLAS formalizes the “curse of multilinguality,” in which adding languages can reduce performance because model capacity is limited. - Adding languages creates a modest capacity cost but also substantial positive transfer. - To support twice as many languages, the study recommends approximately: - 1.18× larger model size. - 1.66× more total training data. - Although each language receives less data individually, cross-lingual synergies offset much of the degradation. ## Pretraining Versus Fine-Tuning - Fine-tuning a strong multilingual “Unimax” checkpoint generally delivers the best early performance for the least additional compute. - Pretraining from scratch can eventually produce better results when substantially more tokens are affordable. - For 2B-parameter models, the crossover typically occurs between roughly 144B and 283B tokens, depending on the language. - The supplied article ends while discussing how ATLAS further models this crossover point. ## Practical Recommendation Use ATLAS to select language mixtures based on measured transfer rather than intuition. Fine-tune an existing multilingual checkpoint under tight compute budgets, but consider training from scratch when enough data and compute are available to pass the language-specific crossover point.

Read original(opens in new tab)
gitlabOriginal article

How to set up GitLab SAML SSO with Google Workspace (opens in new tab)

Organizations using GitLab.com SaaS can streamline access control by integrating SAML-based Single Sign-On (SSO) with Google Workspace. This setup enables automated user provisioning and dynamic permission management by mapping Google Workspace groups directly to GitLab roles. The result is a centralized security model that reduces manual administrative tasks while ensuring users have immediate, secure access to the platform. ### Prerequisites and Architectural Benefits * The integration requires a GitLab Premium or Ultimate subscription and Super Admin access to Google Workspace. * Once configured, the authentication flow redirects users to Google for credentials, after which Google sends a SAML assertion to GitLab containing user details and group memberships. * The system supports "Just-in-Time" provisioning, meaning GitLab accounts are created automatically upon a user's first successful login. * Permissions are dynamic; GitLab updates group memberships and roles every time a user signs in to reflect their current status in Google Workspace. ### Gathering GitLab Configuration Details * Configuration must be performed at the GitLab top-level group rather than within individual subgroups. * Administrators need to retrieve the Assertion Consumer Service (ACS) URL, which typically follows the format `https://gitlab.com/groups/[your-group]/-/saml/callback`. * The Identifier (Entity ID) must be copied to uniquely identify the GitLab group within the Google identity provider settings. * The GitLab SSO URL is the specific entry point users will utilize to initiate the authentication process. ### Configuring the Google Workspace SAML Application * Within the Google Admin Console, administrators must create a "Custom SAML app" to house the integration settings. * The setup process provides a Google SSO URL and a certificate file (typically a `.pem` format) that must be saved for the GitLab-side configuration. * The previously gathered GitLab ACS URL and Entity ID are entered into the Service Provider details section of the Google app configuration. ### Mapping User Attributes and Synchronizing Groups * Specific attribute mapping is required to ensure user data flows correctly: Google’s "Primary Email" should map to the "NameID," "First Name" to "firstName," and "Last Name" to "lastName." * For group synchronization to function, administrators must map selected Google Groups to an app attribute named exactly `groups` (lowercase). * Google allows for the synchronization of up to 75 groups, which GitLab uses to determine and update user permissions upon login. * The application must be explicitly turned "ON" for specific organizational units or the entire domain within the Google Admin Console to allow user access. ### Finalizing the Identity Provider Connection * GitLab requires a SHA-1 certificate fingerprint for security verification rather than the raw certificate file provided by Google. * Administrators must convert the downloaded Google `.pem` certificate into a SHA-1 fingerprint using an online conversion tool or a command-line utility. * This fingerprint, along with the Google SSO URL, is entered into GitLab’s SAML SSO settings to establish the trusted connection between the two platforms. To ensure a smooth rollout, it is recommended to test the integration with a small group of users before enforcing SAML for the entire organization. This allows administrators to verify that group-based permissions are mapping correctly to GitLab roles without disrupting existing workflows.

aws3 min readCurated summary

AWS Weekly Roundup: Amazon EC2 G7e instances, Amazon Corretto updates, and more (January 26, 2026) | Amazon Web Services

AWS’s January 26, 2026 roundup highlights new GPU infrastructure, Java updates, container optimization, expanded observability, and more flexible Amazon Connect workflows. The main launch is EC2 G7e, powered by NVIDIA Blackwell GPUs and designed for demanding AI inference, spatial computing, and scientific workloads. AWS also announced regional expansions and upcoming community and re:Invent-focused events. ## Amazon EC2 G7e Instances - Generally available in US East (N. Virginia) and US East (Ohio). - Powered by NVIDIA RTX PRO 6000 Blackwell Server Edition GPUs. - Deliver up to 2.3× the inference performance of G6e instances. - Provide twice the GPU memory and support configurations with up to eight GPUs and 768 GB of total GPU memory. - Can run medium-sized models of up to 70 billion parameters using FP8 precision on a single GPU. - Target generative AI inference, spatial computing, and scientific computing. ## Amazon Corretto Security Updates - AWS released January 2026 quarterly security and critical updates for supported OpenJDK versions. - New releases include: - Corretto 25.0.2 - Corretto 21.0.10 - Corretto 17.0.18 - Corretto 11.0.30 - Corretto 8u482 - Updates provide current security patches and performance improvements for Java applications. ## Amazon ECR Layer Sharing - Amazon Elastic Container Registry now supports cross-repository layer sharing through blob mounting. - Common image layers can be reused across repositories rather than uploaded repeatedly. - This can speed up image pushes and reduce storage costs by storing shared layers once. ## CloudWatch Database Insights Expansion - On-demand Database Insights is now available in: - Asia Pacific (New Zealand) - Asia Pacific (Taipei) - Asia Pacific (Thailand) - Mexico (Central) - The machine-learning-powered feature helps identify database performance bottlenecks and recommends remediation steps. ## Amazon Connect Guided Experiences - Step-by-Step Guides now support conditional logic and real-time data updates. - Managers can configure interfaces that show or hide fields, change default values, and modify required fields based on earlier inputs. - Automatic refreshes from Amazon Connect resources help agents work with current information. ## Upcoming AWS Events - **Best of AWS re:Invent:** A free virtual event on January 28–29 featuring curated announcements, technical sessions, leadership insights, and live Q&A. - **AWS Community Day Ahmedabad:** A free, community-led conference on February 28, 2026, with technical talks, demos, networking, and real-world use cases. - AWS encourages builders to use the AWS Builder Center to discover additional virtual and in-person events. AWS customers working with AI should consider evaluating G7e instances, while Java teams should apply the latest Corretto updates. ECR users can also benefit from shared layers to improve container delivery efficiency and reduce costs.

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

Cable cuts, storms, and DNS: a look at Internet disruptions in Q4 2025

In Q4 2025, Internet disruptions were driven primarily by submarine cable cuts, power failures, extreme events, technical problems, and one government-directed shutdown. Tanzania experienced a prolonged election-related blackout, while damaged international cables disrupted connectivity in Haiti, Pakistan, Cameroon, and the Dominican Republic. Cloudflare’s analysis uses major deviations in network traffic and routing announcements to identify these incidents, though it is not exhaustive. ## Government-Directed Shutdown ### Tanzania - Internet traffic fell by more than 90% on October 29 during violent protests surrounding the presidential election. - The initial shutdown lasted about 26 hours, but a second near-total outage began shortly after service briefly returned. - Connectivity did not substantially recover until November 3. - Announced IPv4 and IPv6 address space declined slightly but never disappeared entirely, indicating that Tanzania was not completely disconnected from the global Internet. - Internet and social media restrictions had also occurred ahead of Tanzania’s 2020 elections. ## Submarine and Fiber Cable Cuts ### Digicel Haiti - Digicel Haiti suffered two international fiber cuts during the quarter. - On October 16, traffic fell to nearly zero; the provider reported two cuts and restored the first fiber within several hours. - On November 25, another cut along National Road 1 caused a complete outage lasting roughly six hours. - Service was restored after repairs to the international optical fiber infrastructure. ### Cybernet/StormFiber in Pakistan - Traffic dropped to about half its expected level on October 20, while announced IPv4 address space fell by more than one-third. - The cause was a cut to the PEACE submarine cable in the Red Sea near Sudan. - Pakistan has multiple international cable routes, including IMEWE and SEA-ME-WE-4, which helped enable rapid recovery. - Traffic and address announcements returned close to normal by October 21, ahead of the provider’s October 27 restoration target. ### Cameroon and the WACS Cable - Camtel, MTN Cameroon, and Orange Cameroun experienced major disruptions on October 23 because of an incident involving the West Africa Cable System (WACS). - Traffic initially fell around 05:00 local time and recovered by approximately 22:00, although it fluctuated dramatically and sometimes dropped by 90–99%. - MTN and Orange also saw reductions in announced IP address space, while Camtel’s announcements remained stable. - The volatility may have reflected attempts to reroute traffic over other submarine cables. - Connectivity in the Central African Republic and Republic of Congo was reportedly affected as well. ### Claro Dominicana - Claro Dominicana experienced two sharp traffic declines on December 9. - Traffic eventually fell 77% below the comparable level from the previous week. - The provider attributed the disruption to two severed fiber-optic cables, which caused intermittent service and slow speeds. - Technicians restored nationwide service after repairing the cables. ## Power-Related Disruption ### Dominican Republic - A transmission-line outage on November 11 caused a major national power interruption. - Internet traffic fell by nearly 50% compared with the previous week and remained depressed until December 12. - The electrical operator later reported that 96% of national demand had been restored. - A technical report traced the blackout to a manually disconnected live line at the 138 kV San Pedro de Macorís I substation. - The resulting short circuit triggered protection systems and disconnected nearby lines, separating 575 MW of generation. ## Overall Pattern - More than 180 Internet disruptions were observed globally during 2025. - Q4 included only one government-directed shutdown, but several international cable failures caused severe regional outages. - Traffic measurements and BGP address announcements helped distinguish partial connectivity loss from complete national disconnection. - The incidents demonstrate how dependent national networks remain on a limited number of submarine cables, fiber routes, and reliable electrical infrastructure. Cloudflare’s findings suggest that network operators should diversify international cable routes, improve redundancy, and prepare for power and infrastructure failures. The Cloudflare Radar Outage Center provides a broader list of verified anomalies and confirmed outages.

Read original(opens in new tab)
tossOriginal article

Welcoming the Era of (opens in new tab)

The tech industry is shifting from Software 1.0 (explicit logic) and 2.0 (neural networks) into Software 3.0, where natural language prompts and autonomous agents act as the primary programming interface. While Large Language Models (LLMs) are the engines of this era, they require a "Harness"—a structured environment of tools and protocols—to perform real-world tasks effectively. This evolution does not render traditional engineering obsolete; instead, it demonstrates that robust architectural principles like layered design and separation of powers are essential for building reliable AI agents. ### The Evolution of Software 3.0 * Software 1.0 is defined by explicit "How" logic written in languages like Python or Java, while Software 2.0 focuses on weights and data in neural networks. * Software 3.0, popularized by Andrej Karpathy, moves to "What" logic, where natural language prompts drive the execution. * The "Harness" concept is critical: just as a horse needs a harness to be useful to a human, an LLM needs tools (CLI, API access, file systems) to move from a chatbot to a functional agent like Claude Code. ### Mapping Agent Architecture to Traditional Layers * **Slash Commands as Controllers:** Tools like `/review` or `/refactor` act as entry points for user requests, similar to REST controllers in Spring or Express. * **Sub-agents as the Service Layer:** Sub-agents coordinate multiple skills and maintain independent context, mirroring how services orchestrate domain objects and repositories. * **Skills as Domain Components:** Following the Single Responsibility Principle (SRP), individual skills should handle one clear task (e.g., "generating tests") to prevent logic bloat. * **MCP as Infrastructure/Adapters:** The Model Context Protocol (MCP) functions like the Repository or Adapter pattern, abstracting external systems like databases and APIs from the core logic. * **CLAUDE.md as Configuration:** Project-specific rules and tech stacks are stored in metadata files, acting as the `package.json` or `pom.xml` of the agent environment. ### From Exceptions to Questions * Traditional 1.0 software must have every branch of logic predefined; if an unknown state is reached, the system throws an exception or fails. * Software 3.0 introduces Human-in-the-Loop (HITL), where "Exceptions" become "Questions," allowing the agent to ask for clarification on high-risk or ambiguous tasks. * Effective agent design requires identifying when to act autonomously (reversible, low-risk tasks) versus when to delegate decisions to a human (deployments, deletions, or high-cost API calls). ### Managing Constraints: Tokens and Complexity * In Software 3.0, tokens represent the "memory" (RAM) of the system; large codebases can lead to "token explosion," causing context overflow or high costs. * Deterministic logic should be moved to external scripts rather than being interpreted by the LLM every time to save tokens and ensure consistency. * To avoid "Skill Explosion" (similar to Class Explosion), developers should use "Progressive Disclosure," providing the agent with a high-level entry point and only loading detailed task knowledge when specifically required. Traditional software engineering expertise—specifically in cohesion, coupling, and abstraction—is the most valuable asset when transitioning to Software 3.0. By treating prompt engineering and agent orchestration with the same architectural rigor as 1.0 code, developers can build agents that are scalable, maintainable, and truly useful.

figma2 min readCurated summary

Think Outside of the Box—with Claude and FigJam | Figma Blog

Figma and Anthropic have integrated FigJam with Claude so teams can turn AI conversations into editable diagrams. Users can generate flows, timelines, architecture diagrams, and other visual artifacts from prompts, PDFs, images, screenshots, documentation, or code. The integration is intended to make AI-assisted thinking more collaborative by moving ideas from a private chat into a shared workspace where teams can refine and act on them. ## Turning Conversations into Diagrams - Claude can create editable FigJam diagrams directly from written prompts and uploaded materials. - Product teams can generate user flows from PRDs to identify friction, edge cases, and missing steps. - Visualizing ideas reduces copy-pasting and context switching while making abstract concepts easier to discuss. - Teammates can comment, react, and build on the generated diagrams in FigJam’s shared canvas. ## Supporting Product Planning - Product managers can use Claude and FigJam to create initial project plans and Gantt charts. - Generated timelines can map milestones, dependencies, and sequencing. - Early visual drafts help teams spot planning problems, unblock work, and align more quickly. ## Helping Engineers Explain Complex Systems - Claude can generate diagrams from technical documentation or uploaded code files. - Diagrams can represent: - System architecture - Services and APIs - Databases and dependencies - Request and response flows - Sequence and state transitions - These diagrams provide shared context for front-end and back-end teams and help reduce implementation risk. - Claude can compare system patterns and suggest suitable visualization styles. ## FigJam as a Collaborative Workflow - Ideas generated in Claude can move into the broader Figma ecosystem: - Refined in Figma Design - Shared through Figma Slides - Translated into code - Figma is also improving FigJam with more advanced shape collections and connector types. - Anthropic has released a UI kit for designing Claude MCP apps in Figma. - The workflow connects brainstorming, planning, refinement, and execution in one process. ## AI as an Ongoing Collaborator - Multi-turn conversations let teams iteratively develop user journeys, prioritization strategies, and implementation plans. - Claude can propose alternative solutions and recommend chart formats such as decision trees, Gantt charts, sequence diagrams, and state diagrams. - FigJam diagrams become shared, evolving artifacts rather than one-off AI outputs. - Figma presents this integration as a step toward making complex systems easier for teams to understand and improve together. Teams can access the feature through the Figma Connector in Claude’s browser or desktop apps, with support listed for Claude Opus 4.5 and Sonnet 4.5.

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

Route leak incident on January 22, 2026

On January 22, 2026, a routing-policy automation error caused Cloudflare to leak IPv6 BGP prefixes from its Miami data center. For 25 minutes, external traffic was redirected through Miami, congesting backbone links, increasing latency and packet loss, and causing some traffic to be dropped by firewall filters. The incident resulted from removing prefix-list constraints, leaving a Juniper policy that accepted and externally advertised unintended internal routes. ## What a BGP Route Leak Is - A route leak occurs when an autonomous system advertises routes it is not supposed to forward. - This violates valley-free routing principles, such as sending routes learned from a peer onward to another peer or provider. - The leaking network may lack the capacity or firewall rules to handle the redirected traffic. - Cloudflare’s incident involved a mixture of Type 3 and Type 4 route leaks under RFC 7908. ## Incident Impact and Timeline - The triggering automation change was merged at **19:52 UTC**. - At **20:25 UTC**, it ran on a single Miami edge router and caused unexpected advertisements to peers and transit providers. - The network team began investigating at **20:40 UTC** and formally coordinated the incident at **20:44 UTC**. - At **20:50 UTC**, an operator reverted the bad configuration and paused automation on the router. - The leak lasted approximately **25 minutes**, causing: - Congestion on Miami backbone infrastructure - Increased packet loss and latency for some Cloudflare customers - Traffic from unrelated external networks to be funneled through Miami - Packet drops from firewalls configured to accept only Cloudflare-related traffic - The triggering code change was reverted at **21:47 UTC**, and automation was later verified and resumed. ## The Configuration Error - Cloudflare intentionally removed Miami advertisements for a Bogotá data center after infrastructure changes made the Miami-to-Bogotá forwarding path unnecessary. - The change removed `6-BOG04-SITE-LOCAL` prefix-list conditions from multiple export policies. - Those prefix lists had constrained policies to specific Bogotá prefixes. - Once removed, policies such as `6-TELIA-ACCEPT-EXPORT` still matched routes with `route-type internal` and accepted them for export. - On Juniper JunOS and JunOS EVO, `route-type internal` matches any non-external route, including Internal BGP (IBGP) routes. - Consequently, routes that should have remained internal were treated as exportable and advertised to external peers and providers. - The problem affected IPv6 traffic only. ## Response and Remediation - Operators manually reverted the generated router configuration. - Automation was paused on the affected Miami router to prevent the faulty policy from being reapplied. - The source-code change was reverted, and the router was checked before automation resumed. Cloudflare’s incident demonstrates that removing seemingly obsolete route filters can unintentionally broaden a policy. Export policies should explicitly constrain acceptable prefixes and include validation or safeguards that prevent internal routes from being advertised externally.

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

Metronome + Stripe: Building the future of billing

Stripe has finalized its acquisition of Metronome to strengthen Stripe Billing’s usage-based and hybrid billing capabilities. The combined platform will support everything from self-serve subscriptions to complex, sales-led contracts and large-scale AI product catalogs. Stripe’s goal is a unified monetization system covering billing, payments, analytics, revenue recognition, and tax. ## Expanding Usage-Based Billing - Stripe Billing already supports thousands of customers, including rapidly growing AI companies. - Existing models include: - Credit burndown, used by Lovable - Outcome-based billing, used by Intercom - Subscriptions, used by Anthropic - Metronome adds expertise in complex usage-based billing and strengthens Stripe’s ability to support evolving pricing models. ## Supporting Complex Product Catalogs - The combined platform will handle product catalogs with thousands of SKUs. - Multidimensional metering will support sophisticated AI infrastructure pricing, such as OpenAI’s models. - Custom contracting will serve companies combining sales-led growth with usage-based pricing, including Confluent and Anyscale. ## One Platform for Multiple Sales Models - Stripe plans to support: - Self-serve product-led growth - High-touch enterprise sales - Purchases through cloud marketplaces - Metronome customers will gain access to Stripe’s global reach and reliability. - Integrated payments, analytics, revenue recognition, and tax tools are intended to reduce the need for separate systems and specialized engineering teams. ## Monetization as Product Development - Stripe argues that pricing and monetization are becoming active parts of product strategy rather than back-office operations. - Flexible billing infrastructure allows companies to experiment with pricing and adapt as their products and markets evolve. - The long-term goal is a billing platform suitable for startups as well as public companies operating globally. Stripe recommends that businesses interested in modern usage-based or hybrid monetization explore the combined Stripe Billing and Metronome offering.

Read original(opens in new tab)
daangnOriginal article

Redux for Servers: Developing a (opens in new tab)

Traditional CRUD-based architectures often struggle to meet complex backend requirements such as audit logging, version history, and state rollbacks. To address these challenges, Daangn’s Frontend Core team developed **Ventyd**, an open-source TypeScript library that implements event sourcing on the server using patterns familiar to Redux users. By shifting the focus from storing "current state" to storing a "history of events," developers can build more traceable and resilient systems. ### Limitations of Traditional CRUD * Standard CRUD (Create, Read, Update, Delete) patterns only record the final state of data, losing the context of "why" or "how" a change occurred. * Implementing complex features like approval workflows or history tracking usually requires manual table management, such as adding `status` columns or creating separate history tables. * Rollback logic in CRUD is often fragile and requires complex custom code to revert data to a previous specific state. ### The Event Sourcing Philosophy * Instead of overwriting rows in a database, event sourcing records every discrete action (e.g., "Post Created," "Post Approved," "Profile Updated") as an immutable sequence. * The system provides a built-in audit log, ensuring every change is attributed to a specific user, time, and reason. * State can be reconstructed for any point in time by "replaying" events, enabling seamless "time travel" and easier debugging. * It allows for deeper business insights by providing a full narrative of data changes rather than just a snapshot. ### Redux as a Server-Side Blueprint * The library leverages the familiarity of Redux to bridge the gap between frontend and backend engineering. * Just as Redux uses **Actions** and **Reducers** to manage state in the browser, event sourcing uses **Events** and **Reducers** to manage state in the database. * The primary difference is persistence: Redux manages state in memory, while Ventyd persists the event stream to a database for permanent storage. ### Technical Implementation with Ventyd * **Type-Safe Schemas**: Developers use `defineSchema` to define the shape of both the events and the resulting state, ensuring strict TypeScript validation. * **Validation Library Support**: Ventyd is flexible, supporting various validation libraries including Valibot, Zod, TypeBox, and ArkType. * **Reducer Logic**: The `defineReducer` function centralizes how the state evolves based on incoming events, making state transitions predictable and easy to test. * **Database Agnostic**: The library is designed to be flexible regarding the underlying storage, allowing it to integrate with different database systems. Ventyd offers a robust path for teams needing more than what basic CRUD can provide, particularly for internal tools requiring high accountability. By adopting this event-driven approach, developers can simplify the implementation of complex business logic while maintaining a clear, type-safe history of every action within their system.