Techlist.io - Korean Tech Blog Curator

google·Jan 12, 2026Original article

Hard-braking events as indicators of road segment crash risk (opens in new tab)

Google Research has established a statistically significant correlation between hard-braking events (HBEs) collected via Android Auto and actual road crash rates. By utilizing HBEs as a "leading" indicator rather than relying on sparse, lagging historical crash data, researchers can proactively identify high-risk road segments with much greater speed and spatial granularity. This validation suggests that connected vehicle data can serve as a scalable proxy for traditional safety assessments. ### Data Density and Scalability * HBEs—defined as forward deceleration exceeding -3m/s²—provide a signal that is 18 times denser than reported crash data. * While crashes are statistically rare and can take years to provide a valid safety profile for a specific road segment, HBEs offer a continuous stream of information. * This high density allows for the creation of a comprehensive "safety map" that includes local and arterial roads where crash reporting is often inconsistent or sparse. ### Statistical Validation of HBEs * Researchers employed negative binomial regression models to analyze 10 years of public crash data from California and Virginia alongside anonymized HBE data. * The models controlled for confounding factors such as traffic volume, segment length, road type (local, arterial, highway), and infrastructure dynamics like slope and lane changes. * The results confirmed a consistent positive association between HBE frequency and crash rates across all road types, proving HBEs are a reliable surrogate for risk regardless of geography. ### High-Risk Identification Case Study * An analysis of a freeway merge connecting Highway 101 and Highway 880 in California served as a practical validation of the metric. * This specific segment was found to have an HBE rate 70 times higher than the state average, correlating with a historical record of one crash every six weeks. * The HBE signal successfully flagged this location as being in the top 1% of high-risk segments without needing years of collision reports to confirm the danger, demonstrating its utility in identifying "black spots" early. ### Real-World Application and Road Management * Validating HBEs transforms raw sensor data into a trusted tool for urban planners and road authorities to perform network-wide safety assessments. * This approach allows for proactive infrastructure interventions, such as adjusting signage or merge patterns, before fatalities or injuries occur. * The findings support the integration of connected vehicle insights into platforms like Google Maps to help authorities manage road safety more dynamically.

Predictive ModelingTraffic AnalysisStatistical ModelingAndroid Auto+3

airbnb·Jan 12, 2026·3 min readCurated summary

Pay As a Local

Airbnb launched more than 20 locally preferred payment methods across global markets in just over 14 months. The initiative aimed to improve checkout conversion, reach customers with limited access to cards, and provide familiar payment options. Airbnb achieved this by combining a replatformed, domain-oriented payments architecture with reusable PSP connectors and standardized payment-flow patterns. ## Why Local Payment Methods Matter - Local payment methods (LPMs) include: - Digital wallets such as M-Pesa and MTN MoMo - Online bank transfers - Real-time payment systems such as PIX and UPI - Regional payment schemes such as EFTPOS and Cartes Bancaires - They help Airbnb: - Increase conversion by offering trusted local options - Enter markets where card usage is limited - Serve customers without credit cards or traditional banking access - Airbnb identified more than 300 payment options worldwide. - For the initial rollout, it evaluated the top 75 travel markets and selected one or two methods per market, producing a shortlist of just over 20 integrations. ## Payments Platform Modernization - Airbnb separated payment capabilities from its core stays, experiences, and services businesses. - Its Payments LTA modernization replaced a monolith with domain-oriented services. - Core payment subdomains include: - Pay-in and payout - Transaction fulfillment and processing - Wallets and payment instruments - Ledger - Incentives and stored value - Issuing - Settlement and reconciliation - This structure improved reuse, extensibility, time to market, and team autonomy. ## Connector Architecture and Multi-Step Transactions - The processing domain uses connector and plugin-based integrations for payment service providers (PSPs). - Plugins support: - API- and file-based integrations - Payment routing and switching - Market-specific PSP behavior - Airbnb also introduced Multi-Step Transactions (MST), a PSP-agnostic framework for payments requiring multiple stages. - MST represents intermediate operations as Actions, including: - Redirects to external apps or websites - Strong customer authentication challenges - Payment-method-specific interactions - PSP plugins normalize these requirements into an `ActionPayload` and return an `ACTION_REQUIRED` transaction status. ## Three Standardized LPM Flow Types Airbnb analyzed its payment methods and grouped them into three reusable archetypes: - **Redirect flow:** The guest is sent to an external site or app, then returned to Airbnb. Examples include Naver Pay, GoPay, and FPX. - **Async flow:** The guest completes payment later through a QR code, push notification, or wallet app, while Airbnb receives confirmation through a webhook. Examples include Pix, MB Way, and Blik. - **Direct flow:** Payment credentials are entered within Airbnb and processed immediately, similar to card payments. Examples include Cartes Bancaires and Apple Pay. This classification reduced duplicate engineering work and made new integrations more predictable. ## Orchestrating External Payment Actions - For redirect payments: - Airbnb sends a charge request to the local vendor. - The vendor returns a `redirectUrl`. - The guest completes payment externally. - Airbnb receives a result token and uses it to confirm the transaction securely. - For asynchronous payments: - Airbnb sends a charge request and receives `qrCodeData`. - The checkout displays the QR code. - The guest pays in an external wallet. - The vendor sends a webhook, allowing Airbnb to mark the payment successful and confirm the order. - These flows required careful handling of app switching, session handoff, delayed confirmation, and synchronization between Airbnb and external providers. ## Outcome Airbnb’s rollout demonstrates that broad local-payment coverage depends less on building every integration independently and more on creating reusable abstractions. A modular payments platform, standardized flow archetypes, normalized PSP actions, and plugin-based connectors enabled the company to support diverse regional payment behaviors at global scale.

Read original(opens in new tab)

MicroservicesApi IntegrationSoftware ArchitectureWebhooks+3

google·Jan 11, 2026Original article

NeuralGCM harnesses AI to better simulate long-range global precipitation (opens in new tab)

NeuralGCM represents a significant evolution in atmospheric modeling by combining traditional fluid dynamics with neural networks to solve the long-standing challenge of simulating global precipitation. By training the AI component directly on high-quality NASA satellite observations rather than biased reanalysis data, the model achieves unprecedented accuracy in predicting daily weather cycles and extreme rainfall events. This hybrid approach offers a faster, more precise tool for both medium-range weather forecasting and multi-decadal climate projections. ## The Limitations of Cloud Parameterization * Precipitation is driven by cloud processes occurring at scales as small as 100 meters, which is far below the kilometer-scale resolution of global weather models. * Traditional models rely on "parameterizations," or mathematical approximations, to estimate how these small-scale events affect the larger atmosphere. * Because these approximations are often simplified, traditional models struggle to accurately capture the complexity of water droplet formation and ice crystal growth, leading to errors in long-term forecasts. ## Training on Direct Satellite Observations * Unlike previous AI models trained on "reanalyses"—which are essentially simulations used to fill observational gaps—NeuralGCM is trained on NASA satellite-based precipitation data spanning 2001 to 2018. * The model utilizes a differentiable dynamical core, an architecture that allows the neural network to learn the effects of small-scale events directly from physical observations. * By bypassing the weaknesses inherent in reanalysis data, the model effectively creates a machine-learned parameterization that is more faithful to real-world cloud physics. ## Performance in Weather and Climate Benchmarks * At a resolution of 280 km, NeuralGCM outperforms leading operational models in medium-range forecasts (up to 15 days) and matches the precision of sophisticated multi-decadal climate models. * The model shows a marked improvement in capturing precipitation extremes, particularly for the top 0.1% of rainfall events. * Evaluation through WeatherBench 2 demonstrates that NeuralGCM accurately reproduces the diurnal (daily) weather cycle, a metric where traditional physics-based models frequently fall short. NeuralGCM provides a highly efficient and accessible framework for researchers and city planners who need to simulate long-range climate scenarios, such as 100-year storms or seasonal agricultural cycles. Its ability to maintain physical consistency while leveraging the speed of AI makes it a powerful candidate for the next generation of global atmospheric modeling.

AIMachine LearningNeural NetworksClimate Modeling+5

toss·Jan 8, 2026Original article

Managing Thousands of API/ (opens in new tab)

Toss Payments manages thousands of API and batch server configurations that handle trillions of won in transactions, where a single typo in a JVM setting can lead to massive financial infrastructure failure. To solve the risks associated with manual "copy-paste" workflows and configuration duplication, the team developed a sophisticated system that treats configuration as code. By implementing layered architectures and dynamic templates, they created a testable, unified environment capable of managing complex hybrid cloud setups with minimal human error. ## Overlay Architecture for Hierarchical Control * The team implemented a layered configuration system consisting of `global`, `cluster`, `phase`, and `application` levels. * Settings are resolved by priority, where lower-level layers override higher-level defaults, allowing servers to inherit common settings while maintaining specific overrides. * This structure allows the team to control environment-specific behaviors, such as disabling canary deployments in development environments, from a single centralized directory. * The directory structure maps files 1:1 to their respective layers, ensuring that naming conventions drive the CI/CD application process. ## Solving Duplication with Template Patterns * Standard YAML overlays often fail when dealing with long strings or arrays, such as `JVM_OPTION`, because changing a single value usually requires redefining the entire block. * To prevent the proliferation of nearly identical environment variables, the team introduced a template pattern using placeholders like `{{MAX_HEAP}}`. * Developers can modify specific parameters at the application layer while the core string remains defined at the global layer, significantly reducing the risk of typos. * This approach ensures that critical settings, like G1GC parameters or heap region sizes, remain consistent across the infrastructure unless explicitly changed. ## Dynamic and Conditional Configuration Logic * The system allows for "evolutionary" configurations where Python scripts can be injected to generate dynamic values, such as random JMX ports or data fetched from remote APIs. * Advanced conditional logic was added to handle complex deployment scenarios, enabling environment variables to change their values automatically based on the target cluster name (e.g., different profiles for AWS vs. IDC). * By treating configuration as a living codebase, the team can adapt to new infrastructure requirements without abandoning their core architectural principles. ## Reliable Batch Processing through Simplicity * For batch operations handling massive settlement volumes, the team prioritized "appropriate technology" and simplicity to minimize failure points. * They chose Jenkins for its low learning curve and reliability, despite its lack of native GitOps support. * To address inconsistencies in manual UI entries and varying Java versions across machines, they standardized the batch infrastructure to ensure that high-stakes financial calculations are executed in a controlled, predictable environment. The most effective way to manage large-scale infrastructure is to transition from static, duplicated configuration files to a dynamic, code-centric system. By combining an overlay architecture for hierarchy and a template pattern for granular changes, organizations can achieve the flexibility needed for hybrid clouds while maintaining the strict safety standards required for financial systems.

KubernetesAWSInfrastructure As CodeGitops+3

daangn·Jan 8, 2026Original article

Karrot’s User Behavior (opens in new tab)

Daangn transitioned its user behavior log management from a manual, code-based Git workflow to a centralized UI platform called Event Center to improve data consistency and operational efficiency. By automating schema creation and enforcing standardized naming conventions, the platform reduced the technical barriers for developers and analysts while ensuring high data quality for downstream analysis. This transition has streamlined the entire data lifecycle, from collection in the mobile app to structured storage in BigQuery. ### Challenges of Code-Based Schema Management Prior to Event Center, Daangn managed its event schemas—definitions that describe the ownership, domain, and custom parameters of a log—using Git and manual JSON files. This approach created several bottlenecks for the engineering team: * **High Entry Barrier**: Users were required to write complex Spark `StructType` JSON files, which involved managing nested structures and specific metadata fields like `nullable` and `type`. * **Inconsistent Naming**: Without a central enforcement mechanism, event names followed different patterns (e.g., `item_click` vs. `click_item`), making it difficult for analysts to discover relevant data. * **Operational Friction**: Every schema change required a Pull Request (PR), manual review by the data team, and a series of CI checks, leading to slow iteration cycles and frequent communication overhead. ### The User Behavior Log Pipeline To support data-driven decision-making, Daangn employs a robust pipeline that processes millions of events daily through several critical stages: * **Collection and Validation**: Events are sent from the mobile SDK to an event server, which performs initial validation before passing data to GCP Pub/Sub. * **Streaming Processing**: GCP Dataflow handles real-time deduplication, field validation, and data transformation (flattening) to prepare logs for storage. * **Storage and Accessibility**: Data is stored in Google Cloud Storage and BigQuery, where custom parameters defined in the schema are automatically expanded into searchable columns, removing the need for complex JSON parsing in SQL. ### Standardizing Discovery via Event Center The Event Center platform was designed to transform log management into a user-friendly, UI-driven experience while maintaining technical rigor. * **Standardized Naming Conventions**: The platform enforces a strict "Action-Object-Service" naming rule, ensuring that all events are categorized logically across the entire organization. * **Recursive Schema Builder**: To handle the complexity of nested JSON data, the team built a UI component that uses a recursive tree structure, allowing users to define deep data hierarchies without writing code. * **Centralized Dictionary**: The platform serves as a "single source of truth" where any employee can search for events, view their descriptions, and identify the team responsible for specific data points. ### Technical Implementation and Integration The system architecture was built to bridge the gap between a modern web UI and the existing Git-based infrastructure. * **Tech Stack**: The backend is powered by Go (Gin framework) and PostgreSQL (GORM), while the frontend utilizes React, TypeScript, and TanStack Query for state management. * **Automated Git Sync**: When a user saves a schema in Event Center, the system automatically triggers a GitHub Action that generates the necessary JSON files and pushes them to the repository, maintaining the codebase as the ultimate source of truth while abstracting the complexity. * **Real-time Validation**: The UI provides immediate feedback on data types and naming errors, preventing invalid schemas from reaching the production pipeline. Implementing a dedicated log management platform like Event Center is highly recommended for organizations scaling their data operations. Moving away from manual file management to a UI-based system not only reduces the risk of human error but also democratizes data access by allowing non-engineers to define and discover the logs they need for analysis.

Data PipelineData EngineeringBigqueryGcp Dataflow+3

toss·Jan 7, 2026Original article

Rethinking Design Systems (opens in new tab)

Toss Design System (TDS) argues that as organizations scale, design systems often become a source of friction rather than efficiency, leading teams to bypass them through "forking" or "detaching" components. To prevent this, TDS treats the design system as a product that must adapt to user demand rather than a set of rigid constraints to be enforced. By shifting from a philosophy of control to one of flexible expansion, they ensure that the system remains a helpful tool rather than an obstacle. ### The Limits of Control and System Fragmentation * When a design system is too rigid, product teams often fork packages to make minor adjustments, which breaks the link to central updates and creates UI inconsistencies. * Treating "system bypasses" as user errors is ineffective; instead, they should be viewed as unmet needs in the system's "supply." * The goal of a modern design system should be to reduce the reason to bypass the system by providing natural extension points. ### Comparing Flat and Compound API Patterns * **Flat Pattern:** These components hide internal structures and use props to manage variations (e.g., `title`, `description`). While easy to use, they suffer from "prop bloat" as more edge cases are added, making long-term maintenance difficult. * **Compound Pattern:** This approach provides sub-components (e.g., `Card.Header`, `Card.Body`) for the user to assemble manually. This offers high flexibility for unexpected layouts but increases the learning curve and the amount of boilerplate code required. ### The Hybrid API Strategy * TDS employs a hybrid approach, offering both Flat APIs for common, simple use cases and Compound APIs for complex, customized needs. * Developers can choose a `FlatCard` for speed or a `Compound Card` when they need to inject custom elements like badges or unique button placements. * To avoid the burden of maintaining two separate codebases, TDS uses a "primitive" layer where the Flat API is simply a pre-assembled version of the Compound components. Design systems should function as guardrails that guide developers toward consistency, rather than fences that stop them from solving product-specific problems. By providing flexible architecture that supports exceptions, a system can maintain its relevance and ensure that teams stay within the ecosystem even as their requirements evolve.

Design SystemsReactScalabilityComponent Api Design+3

line·Jan 7, 2026Original article

Code Quality Improvement Techniques Part (opens in new tab)

LY Corporation’s technical review highlights that making a class open for inheritance imposes a "tax" on its internal constraints, particularly immutability. While developers often use inheritance to create specialized versions of a class, doing so with immutable types can allow subclasses to inadvertently or intentionally break the parent class's guarantees. To ensure strict data integrity, the post concludes that classes intended to be immutable should be made final or designed around read-only interfaces rather than open for extension. ### The Risks of Open Immutable Classes * Kotlin developers often wrap `IntArray` in an `ImmutableIntList` to avoid the overhead of boxed types while ensuring the collection remains unchangeable. * If `ImmutableIntList` is marked as `open`, a developer might create a `MutableIntList` subclass that adds a `set` method to modify the internal `protected valueArray`, violating the "Immutable" contract of the parent type. * Even if the internal state is `private`, a subclass can override the `get` method to return dynamic or state-dependent values, effectively breaking the expectation that the data remains constant. * These issues demonstrate that any class with a "fundamental" name should be carefully guarded against unexpected inheritance in different modules or packages. ### Establishing Safe Inheritance Hierarchies * Mutable objects should not inherit from immutable objects, as this inherently violates the immutability constraints established by the parent. * Conversely, immutable objects should not inherit from mutable ones; this often leads to runtime errors (such as `UnsupportedOperationException`) when a user attempts to call modification methods like `add` or `set` on an immutable instance. * The most effective design pattern is to use a "read-only" (unmodifiable) interface as a common parent, similar to how Kotlin distinguishes between `List` and `MutableList`. * In this structure, mutable classes can inherit from the read-only parent without issue (adding new methods), and immutable classes can inherit from the read-only parent while adding stricter internal constraints. To maintain high code quality and prevent logic errors, developers should default to making classes final when immutability is a core requirement. If shared functionality is needed across different types of lists, utilize composition or a shared read-only interface to ensure that the "immutable" label remains a truthful guarantee.

KotlinCode QualitySoftware DesignOop+2

figma·Jan 7, 2026·2 min readCurated summary

Software Is Culture

Software has evolved from an invisible, mechanical tool into an intimate part of human experience. The next major shift is toward intelligent, adaptive systems that learn and change with users. The post argues that designers will shape this future not merely by automating tasks, but by deciding where technology directs human attention, curiosity, and creativity. ## Software as Human Experience - Software once operated behind screens as an efficient, obedient system. - Touch interfaces—pinching, swiping, and tapping—made software embodied and deeply connected to how people think, feel, and communicate. - As a result, user experience became inseparable from human experience. ## The Shift to Intelligent Software - Future systems will learn, adapt, and respond rather than follow fixed interactions. - Interfaces may change in real time based on users’ needs and behavior. - Static products will become fluid, adaptive, and increasingly “alive.” - Understanding this transition requires examining influential interactions and design decisions from the past two decades. ## AI as Tool and Collaborator - AI can amplify distinctly human qualities rather than simply replace human work. - Interaction is shifting from commands, layers, and parameters toward conversation, goals, gestures, and overall intent. - The central design question is not what to automate, but where people should focus their attention. ## The Designer’s Role - Designers are navigating how intelligent software will affect curiosity, meaning, and craft. - Their choices will influence how future generations experience and understand technology. - Finding a personal perspective as a designer is essential to shaping software’s cultural impact. The practical takeaway is to treat software design as cultural work: build adaptive systems thoughtfully, and focus on how they direct human attention and enable meaningful action.

Read original(opens in new tab)

AIUser ExperienceMachine LearningSoftware Design+3

datadog·Jan 7, 2026·1 min readCurated summary

Hardening eBPF for runtime security: Lessons from Datadog Workload Protection | Datadog

The provided text does not include the blog post’s article body. It contains Datadog’s navigation menu and a link to an engineering post titled around “eBPF workload protection lessons,” so there is not enough source material to accurately summarize its technical arguments or conclusions. ## Available information - The page is hosted by Datadog’s engineering blog. - The linked topic concerns workload protection built with eBPF. - Datadog’s broader product areas include infrastructure monitoring, application performance monitoring, security, logs, and AI. - The excerpt itself does not describe: - The eBPF implementation - Design challenges or trade-offs - Performance considerations - Security detection methods - Lessons learned or recommendations Please provide the article text or a fuller extract for a substantive summary.

Read original(opens in new tab)

KubernetesDatadogObservabilityApplication Performance Monitoring+3

datadog·Jan 7, 2026·3 min readCurated summary

Hardening eBPF for runtime security: Lessons from Datadog Workload Protection

eBPF gives security tools broad, efficient, and relatively safe access to Linux kernel activity, making it well suited for runtime threat detection. Datadog chose it for Workload Protection after comparing kernel modules, tracing interfaces, ptrace, seccomp, Linux Audit, and other approaches. However, five years of production use across diverse kernels showed that eBPF’s safety and performance benefits are not automatic; reliability, compatibility, observability, and operational discipline are essential at scale. ## Why Runtime Workload Protection Is Needed - Static analysis and vulnerability scanning cannot catch every threat. - Zero-days and vulnerable third-party dependencies can remain active while patches are being prepared or deployed. - Workload Protection is intended to: - Monitor known-vulnerable workloads until they can be patched. - Continuously observe all workloads. - Detect and help mitigate previously unknown vulnerabilities during incident response. ## Alternatives Evaluated Datadog evaluated a broad range of Linux monitoring and instrumentation mechanisms: - **Linux kernel modules** - Offer deep access and can hook or replace almost any kernel function. - Are invasive and often considered too risky for production infrastructure. - **Traditional tracing interfaces** - Include inotify, fanotify, kprobes, tracepoints, and perf events. - Provide useful visibility but generally need to be combined for comprehensive coverage. - **ptrace and seccomp-bpf** - Can provide detailed user-space process visibility. - Are less suitable as a unified solution for monitoring the whole system. - **Linux Audit** - Produces configurable streams for process execution, file access, and network activity. - Is widely used by security tooling but has its own performance and operational tradeoffs. - **Other mechanisms** - Netlink, LD_PRELOAD, and binfmt_misc were also considered. - Each involves compromises in reliability, visibility, or system impact. ## Why eBPF Stood Out - **Safety checks** - The kernel statically verifies eBPF bytecode before loading it. - Verification detects issues such as infinite loops and unsafe memory access. - This is safer than deploying custom kernel modules, though eBPF can still cause harm or performance problems. - **Performance** - eBPF generally has lower overhead than approaches such as Linux Audit or ptrace. - Actual impact depends heavily on implementation and workload. - **Unified visibility** - A single mechanism can observe process, filesystem, and network activity. - This avoids assembling multiple specialized tracing systems. - **Container and namespace coverage** - eBPF provides consistent visibility across namespaces, cgroups, and containers. - CO-RE (Compile Once–Run Everywhere) improves portability across Linux distributions and kernel versions. - **Enforcement capabilities** - BPF LSM programs support mandatory access controls. - This gives eBPF enforcement power beyond ordinary tracing mechanisms, which is important for runtime security. ## Lessons from Operating eBPF at Scale After five years of operating an agent that hooks process scheduling, filesystem, and networking internals, Datadog emphasizes that production eBPF is more complicated than its reputation suggests. The six areas of operational experience are: - Ensuring programs load, attach, and continue firing across kernel versions. - Capturing and enriching event data accurately. - Monitoring and auditing eBPF usage to reduce the attack surface. - Coexisting with other eBPF-based tools on the same host. - Measuring and controlling performance overhead. - Shipping changes safely through disciplined rollout practices. The practical recommendation is to treat eBPF as powerful infrastructure rather than a maintenance-free kernel feature: validate behavior across kernels and workloads, monitor its own operation, measure overhead continuously, and use cautious deployment practices.

Read original(opens in new tab)

Database DesignObservabilityEbpfLinux Kernel+4

figma·Jan 6, 2026·2 min readCurated summary

Issue No.14: Software Is Culture | Figma Blog

Software increasingly shapes how people communicate, play, create, eat, and connect. Figma’s January 2026 newsletter argues that as AI evolves from tool to teammate, software will become more responsive to human needs—and its cultural influence will grow. The issue explores this idea through design, language, gaming, food, and physical fabrication. ## Design Is Culture - Familiar interactions such as pinch-to-zoom, infinite scroll, and tap-to-like were once novel inventions. - These interface patterns have had a major influence on how an entire generation thinks and feels. - The newsletter highlights 10 iconic interactions to examine their broader cultural impact. ## Language Is Culture - Social media and recommendation algorithms help new slang spread rapidly, including expressions such as “6-7,” “aura,” and “rizz.” - Linguist Adam Aleksic explains that algorithms influence not only how people speak, but also how they think and relate to one another. - “Algospeak” has become a measure of virality and a distinctive feature of online communication. ## Gaming Is Culture - Video games have grown from simple experiences like Pong into a $184 billion industry built around expansive worlds, characters, game modes, and side quests. - Despite this complexity, players often navigate games through a small set of controller inputs. - Epic Games UX designer Aashrey Sharma examines how these simple controls enable rich interactions and what they suggest about the future of interfaces. ## Food Is Culture - British Columbia’s small farms are under pressure from factory farming and rising costs, with farmers reportedly leaving the industry at an alarming rate. - Entrepreneur Aaron Veale used Figma Make to build a marketplace connecting local growers with restaurants. - By prompting the AI tool, he produced a working minimum viable product in less than three weeks, demonstrating how AI can help individuals address urgent community problems. ## Fabrication Is Culture - Designer Kelsey Fairhurst combines digital design with hands-on manufacturing to create “softline brutalist” stainless-steel flatware. - Her Forks Plus project grew through years of research and work between a Brooklyn studio and a Cleveland fabrication shop. - The story presents software and design tools as companions to physical making rather than replacements for it. The newsletter’s central recommendation is implicit: treat software as a cultural force, not merely a productivity tool. Designers and builders should consider how the interfaces and AI systems they create will shape behavior, language, creativity, and everyday life.

Read original(opens in new tab)

FigmaAIUser Interface DesignVersion Control+4

cloudflare·Jan 6, 2026·3 min readCurated summary

A closer look at a BGP anomaly in Venezuela

The post examines a January 2 BGP anomaly involving Venezuela’s CANTV network (AS8048). Although the event prompted speculation about government-directed surveillance, the broader pattern—eleven leaks since December—more strongly suggests inadequate BGP import and export filtering. The affected routes, provider-customer relationships, and heavy AS-path prepending are consistent with a configuration or operational error rather than clear malicious activity. ## Background: How BGP Route Leaks Work - BGP directs traffic between autonomous systems (ASes) according to business relationships: - **Customer-provider:** Providers advertise broad Internet routes to customers; customers advertise their own and downstream routes. - **Peer-peer:** Networks exchange their own and customer routes without payment. - These rules produce “valley-free” paths, where traffic generally moves from customers toward providers and then back down toward customers. - A **route leak**, formally defined in RFC 7908, occurs when routing announcements are propagated beyond their intended scope. - A typical leak happens when a customer receives routes from one provider and incorrectly advertises them to another provider, causing traffic to take an inefficient or overloaded path. ## The AS8048 Route Leak - Cloudflare Radar identified AS8048, operated by Venezuelan ISP CANTV, as the leaking network. - CANTV learned routes from AS6762, Italian telecom Sparkle, and redistributed them to AS52320, Colombia’s V.tal GlobeNet. - The leaked prefixes were originated by AS21980, Dayco Telecom, and belonged to the same `200.74.224.0/20` subnet. - Since AS8048 appears to be a provider for AS21980, the leak may reflect incorrect route export policies involving a customer’s prefixes. - The post emphasizes that route leaks are common and are usually caused by mistakes or weak routing controls rather than deliberate attacks. ## Evidence from Routing Relationships - Cloudflare Radar, bgp.tools, and BGPKIT data all indicate a provider-customer relationship between AS8048 and AS21980. - BGPKIT’s relationship analysis showed: - AS8048 was identified as the upstream provider in 9.4% of observations. - AS21980 was almost never identified as upstream. - Although only 9.9% of route collectors saw the two ASes as directly adjacent, the available paths strongly supported AS8048 being AS21980’s provider. ## Significance of AS-Path Prepending - Many leaked routes included repeated instances of AS8048 in their paths. - AS-path prepending is normally used to make a route less attractive and shift traffic away from a particular connection. - A path such as `52320,8048,8048,8048,...,21980` does not mean traffic physically traversed AS8048 repeatedly; the repeated entries are routing-policy padding. - The heavy prepending would have made the leaked routes less preferred, which weakens the case that AS8048 was intentionally trying to attract large volumes of traffic for interception. - The available evidence therefore points more toward poor routing configuration or operational practice than a purposeful man-in-the-middle operation. CANTV’s repeated route leaks and apparent lack of effective routing policies should still be treated as a serious reliability and security concern. However, the post’s evidence supports interpreting this incident as an example of recurring BGP misconfiguration unless further data demonstrates intentional manipulation.

Read original(opens in new tab)

BgpCloudflare RadarAutonomous SystemsInternet Routing+4

aws·Jan 5, 2026Original article

Happy New Year! AWS Weekly Roundup: 10,000 AIdeas Competition, Amazon EC2, Amazon ECS Managed Instances and more (January 5, 2026) (opens in new tab)

The first AWS Weekly Roundup of 2026 highlights a strategic focus on community-driven AI innovation and significant performance upgrades to the EC2 instance lineup. By combining high-stakes competitions like the 10,000 AIdeas challenge with technical releases such as Graviton4-powered instances, AWS is positioning itself to lead in both "Agentic AI" development and high-performance cloud infrastructure. **AI Innovation and Professional Mentorship** * The "Become a Solutions Architect" (BeSA) program is launching a new six-week cohort on February 21, 2026, specifically focused on Agentic AI on AWS. * The Global 10,000 AIdeas Competition offers a $250,000 prize pool and recognition at re:Invent 2026, with a submission deadline of January 21, 2026. * Competition participants are required to utilize the "Kiro" development tool and must ensure their applications remain within AWS Free Tier limits. **Next-Generation EC2 Instances and Hardware** * New M8gn and M8gb instances utilize AWS Graviton4 processors, providing a 30% compute performance boost over the previous Graviton3 generation. * The M8gn variant features 6th generation AWS Nitro Cards, delivering up to 600 Gbps of network bandwidth, the highest available for network-optimized instances. * The M8gb variant is optimized for storage-heavy workloads, offering up to 150 Gbps of dedicated Amazon EBS bandwidth. **Resilience Testing and Governance** * AWS Direct Connect now integrates with the AWS Fault Injection Service (FIS), allowing engineers to simulate Border Gateway Protocol (BGP) failovers to validate redundant pathing. * AWS Control Tower has expanded its governance capabilities by supporting 176 additional Security Hub controls within the Control Catalog. * These controls address a broad spectrum of requirements across security, cost optimization, operations, and data durability. **Hybrid Cloud and Windows Support** * Amazon ECS Managed Instances now support Windows Server for on-premises and remote environment management. * The service uses AWS Systems Manager (SSM) to register external instances, which can then be managed as part of an ECS cluster using Windows-based ECS-optimized AMIs. Developers and infrastructure architects should prioritize the January 21 deadline for AI project submissions while evaluating the M8gn instances for high-throughput networking requirements. Additionally, organizations running hybrid Windows workloads should explore the new ECS Managed Instances support to unify their container orchestration across on-premises and cloud environments.

AI AgentsAmazon Ec2Amazon EcsAws Direct Connect+4

figma·Jan 4, 2026·2 min readCurated summary

Press Start: How Controllers Shaped Video Game Design—and Where Interfaces May Go Next | Figma Blog

Video game interfaces evolved from simple start screens into complex systems of menus, maps, inventories, and customization. Yet the controller’s directional inputs and buttons have remained a consistent foundation, shaping navigation patterns and preserving players’ muscle memory. The article argues that understanding how input devices define interfaces will be essential as AR, VR, and other technologies introduce new ways to interact with digital worlds. ## From Simple Screens to Complex Game Hubs - Early games such as *Tennis for Two*, *Pong*, *PAC-MAN*, and *Super Mario Bros.* offered minimal interfaces, often requiring only a coin insertion or a start button. - Modern AAA games support many features, including: - Multiple game modes - Character customization - Cosmetics stores - Maps and inventories - Quests and settings - These features have transformed games into interconnected hubs of screens, menus, and tabs. - The growth of gaming has helped make it a major cultural and economic industry, supported by livestreaming, esports, and Olympic recognition. ## Controllers as a Design Foundation - From the Atari 2600 to the PlayStation 5, controllers have consistently combined directional controls with buttons. - This consistency allows players to transfer familiar muscle memory between generations of games. - Established controller conventions create predictable navigation patterns for players. - Designers and developers benefit from these conventions because they reduce the need to create entirely new interaction models for every game. ## The Input Defines the Interface - Every platform has a dominant input method that shapes its interface: - Desktop: mouse - Mobile: fingers and touch gestures - Television: remote controls - Mouse interfaces can use small, dense controls because the pointer is fast and precise. - Touch interfaces require larger, more widely spaced controls because fingers are less precise than cursors. - Mobile design also takes advantage of gestures such as tapping, swiping, and pinching. - The article’s broader point is that interface design must reflect the physical capabilities and limitations of the device used to navigate it. ## Preparing for New Forms of Interaction - Game interfaces increasingly connect 2D navigation systems with 3D worlds. - AR and VR controllers may allow players to engage with their physical surroundings as well as digital environments. - As input methods evolve, designers will need to rethink how people move through interfaces, rather than simply adapting existing controller-based patterns. The practical recommendation is to treat input as a core design constraint. By studying how controllers shaped game navigation—and how emerging technologies change physical interaction—designers can build interfaces that feel intuitive across future platforms.

Read original(opens in new tab)

User ExperienceUser InterfaceAugmented RealityVirtual Reality+3

figma·Jan 4, 2026·3 min readCurated summary

Cooking with Constraints: A Designer’s Framework for Better AI Prompts | Figma Blog

Design and cooking both depend on preparation: clear inputs and intentional constraints lead to better outcomes. The article argues that AI models do not need politeness or emotional framing; they need precise instructions that reduce ambiguity. For product designers, structured prompting bridges the gap between probabilistic AI outputs and the repeatable, purposeful results design requires. ## Prompting as Mise en Place - “Mise en place,” or “everything in its place,” means preparing ingredients before cooking—and serves as a useful model for preparing AI prompts. - Effective prompts should establish: - **Clarity** - **Context** - **Constraints** - The author’s framework is **TC-EBC**: - **Task:** What should be built or accomplished? - **Context:** Who is it for and why? - **Elements:** Which features or components are required? - **Behavior:** How should the system respond to user actions? - **Constraints:** What technical, platform, accessibility, or product limits apply? - This approach aligns with broader prompt-engineering guidance emphasizing defined intent, modular construction, and predictable results. ## Why Vague Prompts Underperform - A request such as “build an app that uses pantry photos to suggest recipes” leaves too many decisions to the model. - Polite language and conversational phrasing can bury the actual task without adding useful information. - The resulting prototype may include basic functionality but remain visually generic, uninteresting, and barely beyond a wireframe. ## Applying TC-EBC to a Design Prompt For a pantry-based meal suggestion app, the structured prompt specifies: - **Task:** Build an AI-powered meal suggestion app using pantry and refrigerator photos. - **Context:** Create a home-cooking assistant for households with dietary restrictions. - **Elements:** Include camera input, pantry scanning, dietary settings, meal suggestions, and recipe cards. - **Behavior:** Let users upload photos, scan inventory, apply dietary preferences, and receive recipes. - **Constraints:** Make the experience mobile-first, support iOS and Android, provide accessible UI, and allow multiple household profiles. This structure makes the request easier to scan and gives the model explicit guidance about the app’s purpose, interface, behavior, and limitations. ## Design Requires Structured Uncertainty - LLMs are stochastic, meaning their outputs are probabilistic and variable. - Design, by contrast, depends on precision, consistency, and intentional decisions. - Structured prompts help “collapse uncertainty into structure,” much as a design system provides reusable rules and guidance. - The article presents the TC-EBC prompt as producing a substantially more purposeful prototype than the original one-shot request. A practical recommendation is to treat prompting like preparation for a complex recipe: define the task, provide relevant context, list required parts and behaviors, and state constraints before asking the AI to generate a design.

Read original(opens in new tab)

Design SystemsLarge Language ModelsPrototypingGenerative AI+2