Techlist.io - Korean Tech Blog Curator

aws3 min readCurated summary

Amazon SQS turns 20: Two decades of reliable messaging at scale | Amazon Web Services

Amazon SQS has spent two decades helping distributed systems communicate asynchronously without tightly coupling services. While its core purpose remains unchanged—decoupling producers and consumers, buffering traffic, and isolating failures—its scale, security, integrations, and workload support have expanded significantly. Recent improvements also make SQS suitable for high-throughput, multi-tenant, and AI-driven architectures. ## SQS’s Core Role in Distributed Systems - Producers place messages in queues and continue processing without waiting for consumers. - Consumers process messages when they are ready, preventing slow or unavailable services from causing cascading failures. - Customers use SQS to: - Decouple application components - Absorb traffic bursts - Improve resilience when individual services fail - Coordinate independent services and AI agents ## Higher Throughput for FIFO Queues - High-throughput FIFO mode launched in 2021 at up to 3,000 transactions per second per API action. - Capacity increased progressively to: - 6,000 TPS in 2022 - 9,000 TPS in 2023 - 18,000 TPS later in 2023 - Up to 70,000 TPS per API action in select Regions - The FIFO in-flight message limit grew from 20,000 to 120,000 in 2024, enabling more concurrent processing. ## Stronger Security and Access Controls - SSE-SQS launched in 2021, providing server-side encryption with AWS-managed keys and eliminating customer key-management requirements. - Encryption became the default for newly created queues in 2022. - Attribute-based access control was introduced in 2022, allowing permissions to be based on queue tags rather than static resource policies. ## Improved Message Recovery and Integration - Dead-letter queue redrive became available in the SQS console in 2021. - SDK and CLI APIs—including `StartMessageMoveTask`, `CancelMessageMoveTask`, and `ListMessageMoveTasks`—followed in 2023. - FIFO queue redrive support was added later that year. - JSON protocol support reduced processing latency by up to 23% for 5 KB payloads while lowering client CPU and memory use. - SQS queues can connect directly to EventBridge Pipes, enabling routing to many AWS services without custom integration code. ## Larger Messages and Fairer Queuing - The Extended Client Library for Python allows payloads up to 2 GB by storing message data in Amazon S3 and sending a reference through SQS. - In 2025, the native maximum message size increased from 256 KiB to 1 MiB for standard and FIFO queues. - Fair queues help prevent one tenant in a shared standard queue from delaying others. Producers provide a message group ID, while consumers require no changes. ## SQS for AI Workloads - SQS can buffer requests to large language models and regulate inference throughput. - Queues also help coordinate autonomous AI agents that operate as separate services. - These use cases apply the same established messaging model to more complex, distributed AI systems. Amazon SQS’s recommendation remains straightforward: use asynchronous queues when systems need loose coupling, burst management, and resilience. Its newer throughput, security, recovery, integration, and fairness features extend that pattern to larger and more demanding applications.

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

AWS Weekly Roundup: AWS Builder Center at 1 year, Network Scanning in Security Hub, Loom for AWS, and more (July 13, 2026) | Amazon Web Services

AWS’s weekly roundup highlights the first anniversary of AWS Builder Center and its expansion into a broader learning and experimentation ecosystem. It also introduces major security, AI, container, database, and developer-tool updates, including internet reachability scanning, Azure support in Security Hub, Hugging Face integration with SageMaker, lower GPU management fees, and Aurora DSQL change data capture. The overall direction is toward more integrated, governed, and accessible cloud development workflows. ## AWS Builder Center Turns One - Launched on July 9, 2025, Builder Center has expanded from a community hub into an ecosystem with: - Sandbox environments - Workshops and the Builders’ Library - Community Spaces, profiles, badges, and streaks - AWS regional capability listings - Saved items, article series, availability notifications, and GitHub/Amazon sign-in - In its first year: - 5,548 authors published 6,448 articles. - Articles received more than 10.4 million page views. - Builders earned 99,226 badges. - The community submitted 565 feature wishes, with 10 already delivered. - The most popular articles covered MCP and Strands Agents, Linux migration with Kiro, and multimodal AI for neurological screening. ## Free AWS Sandbox Environments - Builder Center now offers free, pre-provisioned AWS accounts for workshop exercises. - Each sandbox: - Remains active for eight hours. - Automatically removes the account and resources afterward. - Requires no personal AWS account, credit card, or manual cleanup. - Users can have one active sandbox and request one sandbox per week. ## Security Hub Adds Network and Azure Coverage - Security Hub Network Scanning probes AWS and Azure environments from the public internet. - It identifies: - Public IP addresses, virtual machines, and load balancers. - Reachable ports. - Services operating behind those ports. - Each reachable port produces a finding, which Security Hub Exposures correlates with other configuration and security findings. - Existing customers can enable the feature by account, Region, or organization policy; it is enabled by default for new customers. - Network Scanning is included with Security Hub Essentials at no extra cost. - Security Hub also now evaluates Azure VMs, container images, Function Apps, and identities for vulnerabilities, misconfigurations, and internet exposure. ## SageMaker Studio and Hugging Face Integration - Users can deploy or customize supported Hugging Face models in SageMaker Studio with one click. - New customers receive automatically configured Studio environments for: - Fine-tuning and reinforcement learning with custom reward functions. - Model evaluation. - Deployment to SageMaker or Bedrock endpoints. - Verified customers receive default GPU access to G5, G6, and G4dn instances, while quota usage is visible in Studio. ## Lower GPU Management Fees - Starting July 1, 2026, EKS Auto Mode and ECS Managed Instances reduced accelerated-instance management fees: - G-series: 35% reduction. - P-series and Trainium: 60% reduction. - Existing customers receive the reductions automatically. - EKS adds accelerator-aware node repair and parallel image pulling. - ECS provides GPU metrics through CloudWatch Container Insights and monitors GPU hardware health. ## Aurora DSQL Change Data Capture - Aurora DSQL CDC is generally available and streams insert, update, and delete events to Kinesis Data Streams. - The events can synchronize microservices, invoke Lambda functions, or feed S3, Redshift, and OpenSearch through Firehose. - CDC is designed to avoid database performance impact and requires no infrastructure management. ## Tools for Governed AI Agents - Loom for AWS is an open-source platform for deploying and managing Strands Agents on Bedrock AgentCore Runtime. - It includes: - Identity-provider integration and RBAC/ABAC. - Lifecycle management for agents, memory, MCP servers, and agent-to-agent connections. - Automated tagging for cost attribution. - Agent Registry integration and human approval for sensitive actions. - The Claude apps gateway provides centralized access, policy, and spending controls for Claude Code and Claude Desktop. - It supports OIDC identity providers, per-user and per-group spending caps, managed request settings, and routing through Amazon Bedrock or Claude Platform on AWS. - AWS MCP Server now supports browser-based OAuth using AWS Console or CLI credentials, including IAM federation and IAM Identity Center, with short-lived tokens and automatic refresh. AWS’s updates favor managed services that reduce operational work while strengthening security and governance. Teams should evaluate Builder Center sandboxes for training, enable Security Hub’s broader scanning where appropriate, and consider the new AI-agent controls and managed GPU options for production workloads.

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

Modernizing the Meta Ads Service With an Open-Source Kernel Scheduler

At Meta’s scale, small latency regressions can materially affect ad relevance, ranking, and revenue. When Linux kernel 6.9’s EEVDF scheduler reduced ad-serving performance, Meta used sched_ext to deploy a workload-specific BPF scheduler without modifying the kernel. The solution reduced p99 ads-retrieval latency by 28%, saved 3.28 MW of power, increased ads ranked by 1.1%, and enabled further improvements through rapid user-space updates. ## Why Ads Latency Matters - Meta’s ads platform processes more than 5 million requests per second, or over 400 billion requests daily. - Lower p99 latency allows more relevant ads to be retrieved and ranked within each request. - General-purpose schedulers such as CFS and EEVDF balance CPU usage without understanding which threads are most important to ad delivery. - Ads-specific scheduling can prioritize work on the critical request path while deferring less-sensitive tasks. ## The Kernel Upgrade Problem - During a move from Linux 6.4 to 6.9, Meta found that EEVDF introduced a latency regression. - The regression reduced the number of ads ranked in responses. - Some servers had to remain on Linux 6.4, creating operational fragmentation and technical debt. - sched_ext provided a way to address the regression without waiting for another kernel release. ## How sched_ext Customizes Scheduling - sched_ext is an upstream, BPF-based framework that entered Linux 6.12. - It lets developers implement scheduling policies in BPF programs responding to events such as: - Thread wake-ups - Run-queue insertion - Dispatching the next thread - CPU idle-state transitions - Meta’s policy divides CPUs into two dynamically sized pools: - Latency-critical request-path threads - Less latency-sensitive background work - Keeping related work on the same CPUs improves L3 cache locality and reduces DRAM access. - The scheduler is loaded by a user-space binary, so new policies can be deployed by restarting the scheduler process rather than rebuilding the kernel. ## Performance and Operational Results The initial deployment on the largest ads-serving server type achieved: - 28% lower p99 latency on the ads retrieval path - 1.1% more weighted ads ranked - 3.28 MW of fleet-wide power savings Two subsequent policy updates produced additional gains: - A further 60% reduction in service p99 latency - 18% fewer timeout errors on the critical path - Delivery in days instead of the months typically required for kernel changes ## From Fix to Optimization Platform - sched_ext gives Meta an independent scheduling-development path alongside upstream Linux evolution. - BPF updates support rapid experimentation with: - Cache-aware thread placement - ROI-based executor routing - NUMA-aware scheduling - Because sched_ext is upstream, other organizations can implement workload-specific policies without maintaining a Linux kernel fork. - Meta plans to use application-level hints, such as request importance, to adjust scheduling slices and queue priority dynamically. sched_ext demonstrates that application-aware scheduling can produce measurable business, latency, and energy benefits. For workloads with priorities that general-purpose schedulers cannot see, an extensible BPF-based scheduler offers a practical way to optimize continuously without coupling improvements to kernel release cycles.

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

Introducing Precursor: detecting agentic behavior with continuous client-side signals

Precursor is Cloudflare’s new client-side, session-based system for detecting bots and agentic automation through continuous behavioral signals. Unlike one-time challenges, it evaluates interactions across an entire user journey, making automation harder to imitate while reducing friction for legitimate users. It complements Turnstile by extending behavioral detection beyond sensitive checkpoints such as login, signup, and checkout. ## The Visibility Gap in Bot Detection - Cloudflare analyzes more than 1 trillion requests daily across over 20% of the web. - Turnstile runs nearly 3 billion times per day and provides risk-based verification at important application endpoints. - However, point-in-time challenges offer limited insight into how users and bots behave throughout the rest of a session. - Precursor addresses this gap by continuously observing interactions across an application. ## Why Session Behavior Matters - Modern bots can execute JavaScript, operate real browsers, and pass individual CAPTCHAs. - Sustaining believable behavior over a complete session is substantially more difficult. - Precursor uses accumulated behavioral signals to improve detection precision. - This can reduce unnecessary challenges for legitimate users while increasing the cost and complexity of bot operations. ## Human and Automated Interaction Patterns - Human mouse movement reflects physical and cognitive constraints: - Wrist and forearm movement produce curved paths. - Clicking involves a delay after seeing an interface element. - Hand tremors create subtle physiological oscillations. - Automated interactions often reveal: - Straight-line movement or mathematically ideal curves. - Unusually precise clicks. - Repeated velocities, origins, timing, and movement rhythms. - Individual actions may appear plausible, but patterns across a full session can expose automation. ## How Precursor Works ### Injection and Data Collection - Cloudflare dynamically injects a compact, obfuscated JavaScript bundle into HTML responses passing through its network. - No additional configuration, third-party embedding, or network connection is required. - The script observes signals such as: - Pointer movement - Keyboard timing and activity - Focus changes - Page visibility - Events are serialized, buffered in memory, and periodically sent for analysis. ### Edge-Side Evaluation - Cloudflare deserializes the incoming data and runs multiple evaluators against the behavioral streams. - Evaluators cross-reference signals to identify inconsistencies. - Examples include checking whether: - Pointer activity matches page visibility duration. - Keyboard events occur while a text field is focused. - The results are consolidated into detection signals that influence bot scoring. ### Session Integration - Signals accumulate across the session rather than resetting with a page refresh or new challenge. - Session metadata also supports: - Shadow-mode heuristics - Session analysis - Predicted-versus-actual completion comparisons - Session delinquency heuristics - These observations help improve detection and adjust a session’s bot score. ## Privacy by Design - Precursor collects only information considered necessary for detecting automation and abuse. - Keyboard behavior is recorded as timing and rhythm, not the actual keys pressed. - Signals are evaluated as aggregate behavioral patterns. - Data is used internally by Cloudflare’s detection systems and is not exposed in customer dashboards or linked to accounts, identities, or persistent profiles. ## Session-Based Analytics - Cloudflare is introducing session-oriented views in Security Analytics alongside Precursor. - These views shift analysis from isolated requests to complete visitor journeys. - The provided article excerpt ends while beginning to describe these dashboards. Precursor is best understood as a complement to Turnstile: continuous, privacy-conscious session analysis can detect automation that passes individual challenges while reducing reliance on aggressive interruptions for genuine users.

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

[AI Hackathon Review] Hackathons in the AI Era and the Role of Humans: AI’s Plans and Human Strategy

The provided content is not a substantive tech blog post. It consists of NAVER D2 site navigation links and a copyright notice, so there is no technical argument, discussion, or conclusion to summarize. ## Site Navigation - Links to: - D2 News - About D2 - NAVER Developers - DEVIEW - OpenSource - D2 STARTUP FACTORY - Includes a “Hello world” item. ## Copyright - Copyright © NAVER Corp. All Rights Reserved. No technical content or practical recommendation is present in the supplied text.

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

Better tools made Copilot code review worse. Here’s how we actually improved it.

Copilot code review became more expensive and less effective after GitHub replaced its specialized exploration tools with shared `grep`, `glob`, and `view` tools. The tools themselves worked correctly, but their general-purpose instructions encouraged broad repository browsing rather than focused pull request investigation. After rewriting the instructions around diff-first review workflows, GitHub achieved roughly 20% lower average review cost without reducing review quality. ## Why the Tool Migration Regressed - Copilot code review previously used specialized tools for: - Listing directories - Searching files and directories - Reading code - These tools often returned matching lines along with surrounding context, which suited earlier models that made fewer tool calls and needed more context per request. - GitHub migrated to the shared Unix-inspired tools used by Copilot CLI and other products: - `glob` replaced `list_dir` - `grep` replaced `search_file` and `search_dir` - `view` replaced `read_code` - The migration aimed to reduce duplicated implementations and let improvements benefit multiple Copilot products. - Offline benchmarks showed higher review costs and fewer useful comments after the migration. ## Repository Browsing Instead of Pull Request Review - Execution traces showed the agent: - Searching broadly - Guessing file paths - Reading large sections of code - Finding more things to search - Carrying unnecessary context into later reasoning - This workflow is reasonable for a coding assistant asked to understand an unfamiliar repository. - It is inefficient for code review, where the agent should begin with the pull request diff and investigate a specific potential problem. - Excessive tool output increases token usage because returned file contents remain in the agent’s context window. - Broad exploration can also make the review less focused by mixing relevant evidence with unrelated code. ## The Difference Between Coding and Reviewing - A coding assistant may need to map a large area of a repository before editing code safely. - A reviewer typically asks targeted questions based on the diff, such as: - Where is the changed function called? - Is a modified configuration key used elsewhere? - Does a similar test or helper already exist? - What is the smallest code range needed to understand the behavior? - Copilot code review has a narrower objective: - Start from the pull request diff - Determine whether the change introduced a real issue - Gather only the evidence needed to confirm or dismiss that issue - The shared tools were designed for broader interactive workflows, so their instructions unintentionally encouraged the wrong behavior in the review agent. ## Instructions Were the Real Fix - GitHub concluded that changing tools was not enough; the agent’s workflow instructions also had to change. - The revised instructions emphasized: - Diff-first investigation - Targeted searches - Minimal surrounding context - Narrow evidence gathering - Avoiding unnecessary repository-wide exploration - With these workflow changes, the shared tools became more effective for review rather than merely reproducing their coding-assistant behavior. - The result was approximately 20% lower average review cost while preserving review quality. The practical lesson is that tool quality cannot be evaluated separately from the instructions and workflow guiding an agent. Shared tools can work well across products, but each use case needs instructions that match its task—in this case, focused, evidence-driven pull request review rather than broad repository exploration.

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

Improving Smart Tiered Cache for public cloud regions

Cloudflare’s Smart Tiered Cache efficiently routes cache misses through one optimal upper-tier data center, but anycast and regional cloud origins make latency-based selection unreliable. Smart Tiered Cache for Public Cloud Regions addresses this by using a customer-provided cloud region hint to choose geographically appropriate primary and fallback tiers. The result is better cache efficiency, fewer origin requests, and reduced cross-continent “hairpin” traffic. ## Smarter Tiered Cache Topology - Smart Tiered Cache is available on all Cloudflare plans at no additional cost. - It selects a single upper tier based on real-time latency when an origin has a fixed, unicast IP. - Previous enhancements added support for: - **R2**, selecting an upper tier near the bucket’s actual location. - **Load Balancing**, selecting one tier for an entire pool so origins share cache content. - The new feature extends this approach to public cloud origins hosted on AWS, GCP, Azure, and Oracle Cloud. ## Why Anycast Origins Cause Problems - Anycast and regional unicast IPs represent cloud provider front ends rather than one physical origin location. - Multiple Cloudflare data centers may appear equally close to the same IP, preventing reliable selection of one upper tier. - The wrong selection can cause hairpin traffic. For example, an origin in Singapore might be assigned to an upper tier in Chicago, forcing Asian users’ requests across the Pacific and back. - This can add hundreds of milliseconds, increase origin connections, and reduce cache hit ratios. - Cloudflare detects likely anycast origins by comparing probe latencies against the physical limits imposed by the speed of light. - When anycast is detected without additional information, Smart Tiered Cache safely uses multiple upper tiers instead of pinning traffic to one. ## Configuring a Cloud Region Hint - In the dashboard, go to **Caching > Tiered Cache > Origin Configuration**. - Select an origin IP and choose **Set Region Hint**. - Enter a region such as: - `aws:us-east-1` - `gcp:europe-west1` - Hints can be configured individually or applied in bulk. - The same configuration is available through the API and Terraform. - Dashboard hints are currently available only for IPs Cloudflare has identified as anycast. - The initial release supports AWS, GCP, Azure, and Oracle Cloud, with more providers planned. ## How Region-Based Selection Works - Cloudflare periodically downloads each provider’s current IP range files. - These files map cloud regions to their active IP prefixes, allowing Cloudflare to track subnet changes. - Cloudflare matches those prefixes against an upper-tier database updated through latency probing every 15 minutes. - Each matching subnet contributes a weighted vote for its current upper-tier assignment. - The strongest signal determines the region’s primary upper tier. - Primary and fallback tiers are always placed in different Cloudflare points of presence to avoid a single-PoP failure eliminating both options. ## Practical Recommendation For public cloud origins behind anycast or regional unicast IPs, configure the correct cloud region hint through the dashboard, API, or Terraform. This lets Smart Tiered Cache retain a single, nearby primary tier while maintaining a separate fallback, improving cache efficiency and avoiding unnecessary cross-region traffic.

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

One Million Events per Second: Implementing End-to-End Encryption with Apache Kafka in the LINE App

LINE handles billions of messages daily, including highly sensitive personal data. While Kafka already provides TLS, authentication, and authorization, those controls do not protect message contents stored in brokers from privileged access. LY Corporation therefore introduced Kafka client-to-client end-to-end encryption, keeping payloads encrypted from producers through consumers while supporting large-scale traffic, flexible consumers, and minimal overhead. ## Limits of Kafka’s Existing Security Model - TLS protects data in transit between clients and brokers. - SASL authenticates clients before they connect. - ACLs control which users or groups can publish to or consume from topics. - These mechanisms primarily control access and communication channels; broker-stored payloads may still exist in plaintext. - End-to-end encryption adds a defense-in-depth layer by encrypting data at production and decrypting it only at authorized consumers. ## Record-Level Encryption - LY Corporation chose record-level rather than batch-level encryption. - Batch encryption offers better compression and lower CPU overhead, but would require modifying Kafka client internals because standard extension points operate at the record level. - Record encryption works with Kafka interceptors, serializers, and deserializers without modifying existing Kafka clients. - Using standard APIs also improves compatibility with future Kafka upgrades, despite somewhat larger messages and reduced compression efficiency. ## DEK–KEK Key Architecture - Payloads are encrypted with a symmetric AES-GCM data encryption key (DEK). - The DEK is encrypted with an ECC-based key encryption key (KEK), using ECIES and the `secp521r1` curve. - KEKs are managed through a key management service (KMS). - Producers use the KEK’s public key, while authorized consumers obtain the private key from KMS. - This hybrid approach: - Avoids the high cost of encrypting large payloads with asymmetric cryptography. - Keeps message size effectively independent of the number of consumers. - Separates encryption and decryption permissions according to the least-privilege principle. ## Encrypted Kafka Message Structure - **Key:** The existing Kafka message key remains unchanged for partitioning. - **Header:** Contains the KEK identifier and the DEK encrypted with that KEK. - **Body:** Contains the payload encrypted with the DEK. - Embedding metadata directly in each message avoids dependencies on external databases or caches. - Consumers identify the appropriate KEK, decrypt the DEK, and then decrypt the payload. ## Producer and Consumer Architecture ### Producer Encryption - Interceptors generate or select the DEK and place the encrypted DEK in the message header. - A wrapper serializer encrypts the serialized payload with the DEK. - The interceptor and serializer share the DEK through `ThreadLocal`, since they run on the same thread. - DEKs are cached for a limited period rather than regenerated and re-encrypted for every message, reducing asymmetric cryptographic overhead. ### Consumer Decryption - Consumers retrieve authorized private KEKs from KMS. - The deserializer reads the encrypted DEK from the header, decrypts it with the private KEK, and decrypts the payload. - Consumers cache encrypted-DEK/plain-DEK pairs, allowing repeated messages from the same producer to bypass redundant DEK decryption. - The existing deserialization process is wrapped so decryption occurs before normal deserialization. ### KMS Operations - Topic owners generate and register KEK key pairs. - Producers retrieve public keys, while authorized consumers retrieve private keys. - New consumers must request access to the private key and receive approval from the topic owner. - KMS manages key distribution, access control, and key rotation. ## Scaling Optimizations ### Shared KEKs - Assigning a unique KEK to every consumer would cause message headers to grow with the consumer count. - This would reduce Kafka batch sizes and increase network, CPU, and memory usage, especially for topics reaching up to one million messages per second. - Multiple consumers therefore share a single KEK, keeping the header size constant. - The trade-off is reduced per-consumer key isolation, mitigated through: - KMS authorization controls. - Mandatory periodic key rotation. - Centralized key management by the topic owner. ### Zero-Downtime Migration - During migration, encrypted and plaintext messages must coexist. - The consumer deserializer checks whether encryption metadata exists: - If headers are present, it decrypts the message. - If headers are absent, it processes the message using the existing plaintext path. - The migration sequence is: - Deploy compatible consumers first. - Enable producer encryption after all consumers support both formats. - Monitor the plaintext-message ratio and complete the migration once it reaches zero. - Producer encryption is intended to be enabled progressively rather than switched to 100% immediately, reducing the risk of unexpected performance or cryptographic failures. ## Practical Conclusion Kafka’s built-in security controls should be supplemented with payload-level encryption when brokers handle highly sensitive data. A record-level AES-GCM design combined with DEK–KEK key wrapping, KMS authorization, caching, shared KEKs, fallback processing, and gradual rollout provides a practical balance between confidentiality, scalability, and operational continuity.

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

How Decagon Uses AI For Design System Saturation | Figma Blog

Decagon built its Deco design system to maintain quality and consistency as its AI-powered customer service platform scaled. By connecting Figma, Storybook, coding agents, and Figma MCP, the company reduced design-to-code friction and enabled agents to produce higher-fidelity implementations. The result is a shared design language and a continuous loop between design and engineering. ## Building a Design System for Quality at Scale - Decagon initially had no formal design system, while its product and team were expanding rapidly. - Inconsistencies across the platform weakened the polish expected by enterprise customers. - Designers and engineers created Deco together, addressing implementation details early, including: - Focus-mode behavior - Disabled, read-only, error, and warning states - Placeholder decisions - Existing code patterns and edge cases - Deco grew into an organization-wide Figma library with hundreds of components, styles, and variables. - Library analytics recorded tens of thousands of component insertions in 30 days, indicating broad adoption. - The system provides: - A single source of truth for design and implementation - A shared vocabulary between designers and engineers - Faster screen assembly from reusable components - Greater consistency across teams and product areas ## Connecting Design and Code with Figma MCP - Before MCP, designers exported specifications, developers interpreted them, and discrepancies were discovered during review, creating repeated back-and-forth. - Decagon moved its design-system components into Storybook so engineers and coding agents could work from precise, documented implementations. - The team created coding-agent skills that: - Require agents to use approved design-system components - Help designers add new components while keeping Figma and code aligned - With Figma MCP enabled, agents can access design specifications, code context, and the Figma canvas within the same workflow. - Designers can provide a Figma link to a coding agent, which uses design context and maps the requested interface to Deco components. - This produces high-fidelity starting points and speeds up iteration while reducing divergence between the intended design and the final code. Decagon’s experience suggests that design systems become significantly more valuable when they are connected directly to development tools and AI agents. Maintaining synchronized component libraries across Figma and code can help fast-moving teams scale without sacrificing consistency or implementation quality.

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

How GitHub gave every repository a durable owner

Michael Recachinas is a Staff Security Engineer at GitHub who leads large-scale security initiatives. His work focuses on vulnerability management, secure development lifecycle tooling, and developer-first security automation. Throughout his career, he has built scalable systems designed to make secure choices easier for development teams. ## Professional Focus - Leads security programs at GitHub. - Specializes in: - Vulnerability management - Secure development lifecycle tooling - Security automation designed for developers ## Engineering Approach - Builds systems that operate at large scale. - Focuses on integrating security into developers’ workflows. - Aims to make secure practices the easiest and most natural choice. Overall, the passage presents Recachinas as a security engineering leader focused on scalable, practical, and developer-friendly solutions.

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

Why we cannot wait for better post-quantum signature algorithms

RSA and elliptic-curve signatures will eventually be vulnerable to sufficiently powerful quantum computers, so organizations cannot delay migration until ideal post-quantum algorithms arrive. ML-KEM already protects much of Cloudflare’s traffic from “harvest now, decrypt later” attacks, while ML-DSA is currently the practical choice for post-quantum signatures despite its larger keys and signatures. Better schemes are being developed, but they will not be standardized and deployable in time for the initial transition. ## The urgency of post-quantum migration - NIST standardized ML-KEM encryption and ML-DSA signatures in 2024 after an eight-year international competition. - Cloudflare reports that most of its traffic already uses ML-KEM. - Post-quantum signatures are still needed to protect authentication systems from quantum-enabled attacks. - Cloudflare aims to be fully post-quantum secure by 2029. - The authors argue that deployment must begin with currently available algorithms: - “You go to war with the algorithms you have, not the ones you wish you had.” - Future signature research remains important because current options have substantial performance, size, and implementation drawbacks. ## Comparing the candidate signature algorithms - The candidates include: - Existing classical algorithms such as RSA and elliptic-curve signatures, which are quantum-vulnerable. - ML-DSA and other already standardized or soon-to-be-standardized post-quantum schemes. - Nine candidates advancing to the third round of NIST’s signatures on-ramp. - Comparisons focus on variants relevant to TLS at the 128-bit security level. - The measurements cover: - Public-key and signature sizes. - Signing and verification speed. - Implementation concerns and side-channel resistance. - Some algorithms have important operational limitations: - FN-DSA and SQIsign are difficult to implement with fast, timing-safe signing. - LMS requires state to be maintained securely between signatures. - Certain SLH-DSA variants are intended for only a limited number of signatures. ## No single post-quantum “all-star” - Ed25519 remains the strongest all-around performer when quantum resistance is ignored. - It offers particularly favorable: - Public-key size. - Signature size. - Signing speed. - Its verification is slower than some alternatives but remains fast enough for most applications. - Post-quantum schemes instead fall into two broad groups: - **Specialists:** Excellent on particular metrics but unsuitable for general use because of other weaknesses. - **Generalists:** More balanced schemes such as ML-DSA, which avoid extreme weaknesses but do not match elliptic curves overall. ## SQIsign: compact signatures with slow signing - SQIsign is attractive for bandwidth-sensitive applications: - 148-byte signatures. - 65-byte public keys. - Smaller than RSA-2048 and close to elliptic-curve sizes. - Its disadvantages include: - High mathematical and implementation complexity. - Slow signing and verification. - Difficulty achieving efficient, timing-side-channel-resistant signing. - Progress since 2024 has significantly simplified SQIsign and improved verification speed. - Secure signing is still unlikely to become fast enough for common online uses such as TLS handshakes. - It may be better suited to offline applications where signing is infrequent and verification matters more, including: - Certificate-authority signatures. - DNSSEC. - SQIsign is based on isogenies, a category that attracted concern after SIKE was catastrophically broken. - The authors distinguish the schemes: - SIKE already had known security concerns and used problematic torsion points. - SQIsign does not use those torsion points. - The best known SQIsign attacks are generic brute-force attacks, resembling attacks against well-chosen elliptic curves. - Isogeny mathematics still has a large attack surface, but the authors consider SQIsign’s security outlook stronger than that of structured multivariate schemes. - The authors see significant promise in SQIsign but caution against standardizing it prematurely. The practical recommendation is to begin the post-quantum transition with ML-DSA rather than waiting for smaller or faster alternatives. New schemes such as SQIsign may eventually serve specialized use cases, but they must undergo further cryptanalysis, standardization, implementation work, and deployment before they can replace today’s available algorithms.

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

GPT-5.6 is Now Available in Figma Make | Figma Blog

GPT-5.6 is now available in Figma Make, where Figma says it improves both the speed and quality of AI-generated prototypes. The model is designed to produce stronger first passes, preserve existing designs more faithfully, and recover from errors without stopping. Figma’s examples suggest it can move teams from prompts or static designs to functional, responsive prototypes with less iteration. ## Faster exploration and error recovery - GPT-5.6 can turn complex prompts into working prototypes quickly, helping teams explore multiple ideas in one session. - In Figma’s stock-tracking app evaluation, it created: - An interactive dashboard - Sample prices and performance data - Keyboard shortcuts and search - A dark, gothic visual style - The model is described as more token-efficient, helping users make better use of Figma Make credits. - When builds encounter errors, GPT-5.6 can investigate and self-heal instead of stopping. Figma reports that it independently diagnosed and fixed a blank build. ## Faithful design-to-code conversion - GPT-5.6 can build prototypes from existing design specifications or Figma Design files. - In a nature sound player test, it preserved: - Layout and visual hierarchy - Spacing, proportions, and styling - A multi-track timeline and sound library - It also implemented functional interactions, including: - Play, pause, and skip controls - Working audio playback - Multiple playable tracks - Audio-responsive visual effects ## Higher-quality first passes - Figma says GPT-5.6 produces polished initial prototypes with functional interactions and responsive layouts. - A bookshelf e-commerce example included: - Product descriptions, measurements, and care information - Populated information dropdowns - An interactive product photo library - A clickable navigation menu - The prototype adapted reliably across different screen sizes without additional prompting. - Stronger first passes allow teams to spend more time refining ideas collaboratively rather than repairing basic implementation problems. GPT-5.6 is available through Figma Make’s model selector. Users can select it directly in Make and consult Figma’s help center for guidance on choosing and using AI models.

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

SensorFM: Towards a general intelligence and interface for wearable health data

SensorFM is a large foundation model designed to turn wearable-device signals into a reusable representation of human physiology. Trained on more than one trillion minutes of multimodal data from five million people, it performs well across 35 health-related prediction tasks while requiring relatively few labeled examples. The authors argue that scaling both data and model size enables a general-purpose interface for wearable health data rather than isolated, task-specific models. ## The challenge of wearable health data - Wearables continuously capture heart rate, movement, temperature, blood oxygen, sleep, and related signals. - Interpreting these measurements is difficult because: - Baseline physiology and lifestyle vary substantially between individuals. - Reliable labels such as diagnoses, lab results, and validated questionnaires are costly and difficult to collect. - Traditional models usually target one health outcome at a time and generalize poorly. ## Training on more than a trillion minutes - SensorFM was trained on de-identified data from five million consenting participants collected between September 2024 and September 2025. - The dataset includes: - More than 100 countries and all 50 U.S. states. - Over 20 Fitbit and Pixel Watch models. - More than two billion sensor-hours of data. - The model processes 34 minute-level features from: - PPG - Accelerometry - Electrodermal activity - Skin temperature - Altimetry - These signals represent heart rate, heart-rate variability, blood oxygen, sleep, movement, skin conductance, and temperature across full days. ## Learning from incomplete sensor recordings - SensorFM uses self-supervised masked reconstruction rather than relying on medical labels. - Its Adaptive and Inherited Masking framework treats naturally missing data as part of the learning problem. - This avoids: - Imputing gaps, which can introduce bias. - Discarding incomplete windows, which wastes real-world data. - The resulting representation is explicitly aware of missingness and can learn from fragmented wearable recordings. ## Scaling data and model capacity - Experiments varied training data from roughly two million to two billion sensor-hours and model size from 100,000 to 100 million parameters. - Larger models trained on more data consistently improved both reconstruction and downstream health prediction. - The largest model: - Reduced reconstruction loss by 31% compared with the smallest version. - Improved classification performance by an average of 9% in AUC. - Improved regression performance by 21% in Pearson correlation. - Won on 33 of 35 downstream tasks. - Scaling data and model size together produced near-linear gains with no observed saturation. ## One representation across many health domains - SensorFM was tested on 35 tasks from three prospective studies involving 13,985 participants. - The tasks covered: - Cardiovascular health - Metabolic risk - Mental health - Sleep - Demographics - Lifestyle - With the encoder frozen and only a lightweight linear head trained, SensorFM embeddings outperformed engineered-feature supervised baselines on 34 of 35 tasks. - Larger models appeared to learn physiologically relevant demographic and individual differences without being explicitly given demographic inputs. - The model showed particular value for difficult-to-measure conditions such as depression and anxiety. - It also reached strong performance with relatively small quantities of labeled data, addressing a major constraint in healthcare modeling. ## Automated adaptation through an agentic “classroom” - The authors introduce a collaborative system of LLM agents intended to automate the creation of prediction heads. - This approach aims to reduce the manual work traditionally required for: - Feature engineering - Architecture selection - Hyperparameter tuning - The supplied article excerpt ends while introducing this system, so its detailed workflow and results are not described here. SensorFM demonstrates that large-scale, missingness-aware pre-training can produce a broadly useful representation of wearable physiology. Its strongest practical promise is label-efficient adaptation across many health applications, potentially providing a foundation for personalized health agents and more general wearable-data interfaces.

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

How to Lead Design Teams Through the AI Era | Figma Blog

Jen Dunnam argues that design leaders should respond to AI-driven change with calm, deliberate experimentation rather than panic. The fundamentals of design remain human-centered, so teams should prioritize clear thinking, strong principles, and the ability to turn insights into products. Her approach emphasizes investing in emerging talent while hiring and developing designers who can challenge assumptions. ## Lead with Calm - Leaders should steady their teams instead of adding to the urgency already felt by ambitious designers. - Break AI-related change into manageable steps: - Choose an approach. - Experiment with appropriate tools. - Refine design principles. - Learn from the results. - Designers should avoid chasing every new capability simply because it is novel or impressive. - AI may transform workflows, but designing for human needs remains the central responsibility. ## Hire for Critical Thinking - Dunnam would invest more heavily in designers fresh out of school, many of whom are disadvantaged by today’s pressure to ship quickly. - Pair early-career designers with experienced practitioners who can help turn ideas into shippable products. - Look for researchers who can move beyond gathering insights and contribute decisively to product direction. - Critical thinking has become especially valuable as AI tools make polished but potentially shallow solutions easier to produce. - Interviewers should ask candidates: - Where did they disagree with a stakeholder? - How did they push back? - What product decision still bothers them? - These questions reveal whether candidates can challenge attractive but poorly reasoned solutions. Dunnam’s practical recommendation is to keep teams grounded in human-centered design, combine emerging and experienced talent, and hire people with the judgment to question what appears easy, polished, or technologically exciting.

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

Green DevOps: Why carbon measurement belongs in your CI/CD pipeline

CI/CD pipelines consume energy and generate emissions that standard pipeline metrics do not reveal. The post argues that measuring this impact is the first step toward reducing it, recommending Eco CI for job-level measurements and Carmen for infrastructure and application-level analysis. Both tools integrate with GitLab pipelines with minimal effort and can improve sustainability, performance, and cloud costs. ## Why CI/CD Carbon Measurement Matters - Modern teams run hundreds of jobs daily, including increasingly resource-intensive AI-assisted testing and automation. - Each job has an energy and carbon cost that is usually absent from pipeline logs and architecture diagrams. - Green DevOps involves measuring emissions per pipeline, service, and Kubernetes workload to guide engineering decisions. ## Measuring Emissions at Different Layers ### Pipeline-level measurement with Eco CI - Eco CI measures energy consumption and carbon emissions for individual CI/CD jobs. - It runs as lightweight Bash scripts without additional servers or databases. - Teams can identify expensive jobs, track emissions over time, and add a carbon badge to a project README. - Because it works within existing pipelines, it is a practical starting point. ### Infrastructure and application measurement with Carmen - Carmen, the Carbon Measurement Engine, uses the Green Software Foundation Impact Framework. - It measures emissions from virtual machines, Kubernetes pods, and application workloads. - Reports are provided per component in CSV format and distinguish: - Operational carbon from energy consumption - Embodied carbon from hardware manufacturing and disposal - Outputs such as `EnergykWh` and `TotalCarbonGramsCO2eq` can be imported into Grafana, FinOps dashboards, or custom tools. - Carmen helps teams compare emissions across services, such as an API gateway versus a data-processing layer. ## Adding Carbon Reports to GitLab - Both tools can be integrated through `.gitlab-ci.yml`. - A Carmen job can: - Use a Python 3.12 image - Install Node.js, npm, Git, and the Impact Framework toolchain - Clone and install the Carmen project - Run `carbon-daemon` - Store generated reports as GitLab artifacts - Carmen can run as a separate, non-blocking job, keeping carbon measurement outside the critical delivery path. ## Turning Visibility into Engineering Improvements - Eco CI may reveal that integration tests produce unusually high emissions because dependencies are reinstalled on every run. - Adding dependency caching can reduce runtime, emissions, and CI costs without architectural changes. - Carmen can expose idle infrastructure, such as deprecated services still running in a staging Kubernetes cluster. - Decommissioning unused workloads eliminates both their operational and embodied carbon costs. ## Business and Regulatory Benefits - Emissions data creates a baseline for future reporting requirements, even when a company’s absolute footprint is relatively small. - Carbon-efficient systems are often faster and cheaper because they use fewer compute resources. - Caching, right-sizing runners, and removing idle services support both sustainability and FinOps goals. - Regulations such as the EU’s CSRD, along with enterprise procurement requirements, are increasing pressure for supply-chain and cloud-emissions reporting. Teams can start with Eco CI on one GitLab pipeline, then add Carmen for infrastructure-level visibility. Measuring carbon alongside runtime and cost makes sustainability a practical part of everyday engineering rather than a separate initiative.

Read original(opens in new tab)