techlist.io
KREN

Techlist.io - Korean Tech Blog Curator

github3 min readCurated summary

Turn one giant AI-generated pull request to a reviewable stack

Coding agents can rapidly produce complete features, but they often deliver them as enormous, shallow pull requests that are difficult to review and slow to merge. GitHub’s stacked pull requests address this by decomposing a feature into small, dependency-ordered layers. The result is a reviewable chain of changes that preserves context while reducing maintenance and merge conflicts. ## The Problem with Giant AI-Generated Pull Requests - A seemingly simple product-search feature may include: - A data model and seed data - An API route and validation - Client integration and UI states - Coding agents commonly generate all of this in a single 1,000-plus-line pull request. - Large pull requests: - Become difficult to review thoroughly - Cause reviewers to lose context - Receive lower-quality feedback - Take longer to merge - Are more likely to land under-reviewed Traditional alternatives are also imperfect: one large pull request harms reviewability, while a manually maintained chain of smaller pull requests creates synchronization work and conflict-management overhead. ## Stacked Pull Requests - Stacked pull requests break a feature into logical, dependent layers. - Each pull request focuses on one concern and remains small enough for reviewers to understand. - Later layers build naturally on earlier, already-reviewed work. - Different layers can be assigned to specialized reviewers, such as data or UI owners. For the product-search example, the proposed stack is: - **L1 – `feat/catalog-data`**: Typed catalog, seed data, validation, and data access; based on `main` - **L2 – `feat/search-api`**: Validated `/api/products/search` endpoint; based on L1 - **L3 – `feat/chat-grounding`**: Connects chat to the API and real product data; based on L2 - **L4 – `feat/grounded-ui`**: Adds product citation cards and UI states; based on L3 ## Setting Up the Stack - Choose the stack base first, because CI checks and merge rules are evaluated against it. - Place foundational work closest to the base and dependent work above it. - Install GitHub’s CLI extension: ```bash gh extension install github/gh-stack ``` - Teach coding agents how to create and manage stacks: ```bash gh skill install github/gh-stack ``` Alternatively: ```bash npx skills add github/gh-stack ``` - Ensure CI is configured, since every pull request layer is checked against the stack base. ## Assigning Agents to Layers The example uses separate agents with strict scope boundaries: - **L1:** Data modeler agent - **L2:** Backend agent - **L3:** Frontend agent - **L4:** Frontend agent This division encourages each agent to produce a focused pull request rather than reconstructing the entire feature in one pass. ## Recommended Workflow The development process starts with the foundational catalog layer and proceeds upward through the dependency chain. Agents work autonomously within their assigned scope, while each completed layer can be reviewed independently before subsequent layers are evaluated. Stacked pull requests are a practical way to preserve the productivity benefits of coding agents without sacrificing review quality. Teams should define clear layer boundaries, establish the stack base, assign appropriate reviewers or agents, and run CI for every layer.

Read original(opens in new tab)
CI/CDGithubAPI DesignCoding Agents+2
cloudflare3 min readCurated summary

The Agent Development Lifecycle has arrived on Cloudflare

AI has made software implementation dramatically faster, exposing bottlenecks in testing, deployment, maintenance, and operations. Cloudflare argues that software development must evolve from the human-centered SDLC to an Agent Development Lifecycle (ADLC), where agents manage the full process rather than merely generate code. This requires software factories with APIs, observability, scalability, permissions, reproducibility, and self-improvement built in from the start. ## AI Has Overloaded the Traditional SDLC - The SDLC typically covers planning, design, implementation, testing, deployment, maintenance, and retirement. - AI has made implementation cheaper and faster, overwhelming downstream activities: - Open-source maintainers face huge volumes of issues and pull requests. - Production teams must handle software delivery at unprecedented speed. - Many organizations still use agents only for coding while humans perform validation, review, deployment, monitoring, and bug triage. ## From Software Teams to Software Factories - A software factory accepts inputs such as: - Production errors - Customer bug reports - Feature ideas - Agents then autonomously build, improve, deploy, and manage software. - The goal is to reduce human involvement in routine coordination and reserve human time for design, customer understanding, judgment, and creativity. - Cloudflare treats agents as customers and provides APIs that let them interact with its products and services across the SDLC. ## Requirements for Agent-Driven Development Software factories must redesign human-oriented processes so agents can operate safely and independently: - **Programmatic:** Every operation needs a reliable API; manual “ClickOps” cannot support agents. - **Horizontally scalable:** Each agent should receive isolated, production-like preview environments. - **Reproducible:** Systems must reproduce complex conditions, such as device, network, or geographic variations. - **Real-time and push-based:** Events should trigger agents instead of relying on humans to inspect dashboards. - **Atomic:** Changes must be independently testable, releasable, observable, and reversible. - **Permissioned:** Agents need controlled access and mechanisms to safely escalate permissions when necessary. - **Self-improving:** Agents must learn from prior work and operational experience. ## Cloudflare’s Initial ADLC Tools Cloudflare describes several projects intended to extend agents beyond code generation: - `@cloudflare/ci`: CI/CD infrastructure designed to operate across millions of repositories, self-heal, and spawn agents for complex tasks using Cloudflare Workflows. - OpenTelemetry traces in local development: Gives agents production-like observability through Wrangler and the Cloudflare Vite plugin. - Cloudflare Agents and Agent Traces: Provides tools for observing, maintaining, and improving agents. - AI-enforced engineering standards: Applies best practices across products, systems, and specifications. - An Astro software factory: Automatically triages, reproduces, verifies, and fixes GitHub issues to reduce the project’s issue backlog. ## Autonomous Software Requires Purpose-Built Infrastructure - Traditional SDLC tools and linear GitHub Actions workflows are designed around human decision-making and do not cover the complexity of autonomous software delivery. - Agents must handle subjective requirements, cross-functional dependencies, production risks, and operational feedback—not just run tests and open pull requests. - Like autonomous vehicles, software agents need specialized sensors, feedback systems, controls, and remote intervention capabilities rather than being placed in systems designed for humans. - The relevant standard is not whether an agent succeeds most of the time, but whether it can achieve the reliability and safety required for production. The practical recommendation is to treat agents as participants in the entire software lifecycle. Organizations adopting AI at scale should build the APIs, observability, isolation, permissions, event systems, and feedback loops needed for safe software factories—not simply add agents to existing human workflows.

Read original(opens in new tab)
AI AgentsCI/CDCloudflareGitHub Actions+3
cloudflare3 min readCurated summary

Run CI/CD for millions of repos — on your platform, on Cloudflare

Cloudflare is bringing code storage, CI, and deployment together on its platform. Its CI SDK turns Cloudflare Workflows into TypeScript-defined pipelines that can build, test, and deploy repositories stored in Artifacts. The approach supports both platform-managed CI for customer applications and custom workflows, while adding isolated execution, caching, parallelism, and optional AI-powered self-healing. ## Cloudflare-Hosted CI/CD - Artifacts provides versioned code storage capable of supporting millions of repositories. - Artifact push events can directly trigger Workflow executions through a new `events` configuration field. - A CI job can: - Build code in an isolated environment - Run linters, typechecks, and unit tests - Cache dependencies between steps - Automatically fix failed steps with an AI review agent - Deploy only after successful validation ## CI/CD as a Cloudflare Workflow - A traditional CI/CD pipeline is essentially an ordered sequence of Workflow steps. - Instead of complex YAML configuration, developers can define pipelines in TypeScript using `step.do()`. - The CI SDK combines Workflows with the Sandbox SDK to run commands safely and independently. - Workflow retries and timeouts manage state and failures without requiring developers to call the Sandbox API directly. - Push-triggered jobs no longer require separately configuring event subscriptions, queues, and consumers. ## Dependency Caching and Parallel Execution - An initial install step can download dependencies and tools such as bundlers, linters, and test runners. - Cache inputs can include files such as `package.json` and `bun.lock`. - The resulting sandbox snapshot is stored in an R2 bucket and reused by later steps. - Build, lint, test, and typecheck steps can run concurrently with `Promise.all()`. - A deploy step runs only after all required checks complete successfully. ## Platform-Managed and Custom CI - Platforms can define one reusable CI/CD pipeline for applications created by their customers. - Platform-owned code and customer code can use different pipelines while remaining in the same namespace. - Customers who need specialized behavior can define their own Workflow and run custom CI on their repository. - Both managed and custom CI pipelines can operate simultaneously. ## Extensible and Self-Healing Pipelines - Developers can import `CIWorkflow` from `@cloudflare/ci` and define their own workflow. - Each build or validation step runs in a separate isolated sandbox. - Workflows can invoke an AI agent when a build fails. - The agent can diagnose issues, apply a fix, and push a commit for approval. - Cloudflare provides a self-healing CI example through Project Think. Cloudflare’s recommended model is to treat CI/CD as ordinary TypeScript Workflow code: install dependencies once, run checks in parallel, and deploy only after success. This gives platforms a reusable default pipeline while preserving the flexibility for individual teams or customers to customize their own builds.

Read original(opens in new tab)
CI/CDCloudflareTypeScriptWrangler+3
cloudflare2 min readCurated summary

Your agent can now debug Workers with local tracing

Cloudflare now enables `wrangler dev` and `vite dev` to automatically capture OpenTelemetry traces for local Worker requests. Coding agents can discover the Local Explorer API, query traces and logs, inspect local resources, and debug failures without extra SDKs, configuration, or temporary logging. This lets agents diagnose and verify fixes locally before deployment. ## Automatic Tracing for Local Development - Wrangler and the Cloudflare Vite plugin capture traces for local Worker invocations. - Tracing requires no application code changes, SDK installation, or observability setup. - Instrumentation covers: - Outbound `fetch` requests - KV, R2, D1, Durable Objects, Queues, and other bindings - Fetch, scheduled, and queue handlers - Custom application spans - Miniflare collects runtime events and console output, then stores correlated OpenTelemetry traces and logs in a local SQLite-backed Durable Object. ## Agents Discover the Local Explorer API - When a supported coding-agent session is detected, the development server displays the Local Explorer API URL and trace-query endpoint. - The API exposes an OpenAPI schema, allowing agents to discover available operations dynamically. - Agents can query read-only traces and logs using SQL, then inspect or modify local Worker state and bindings. - Local resources available for inspection include D1, KV, R2, Durable Objects, and Workflows. ## Diagnosing and Verifying Failures - In an example `POST /api/orders` request: - KV successfully retrieves the active cart. - A D1 insert fails because the `delivery_window` column is missing. - The Queue is never called. - Without traces, an agent must add logs around each operation and repeatedly reproduce the request. - With traces, it immediately identifies the failed D1 operation, checks the local schema, applies the existing migration, reruns the request, and confirms success through a new trace. - The entire debugging cycle happens locally, without deployment or temporary instrumentation. ## Local Explorer for Human Developers - The browser-based Local Explorer displays the same telemetry available to agents. - Developers can inspect request spans, timing, attributes, errors, and correlated console logs. - It runs on the same localhost origin as the Worker. - Open it by pressing `e` in Wrangler or visiting `/cdn-cgi/explorer`. ## Getting Started - Update the relevant dependency: - `wrangler@latest` - `@cloudflare/vite-plugin@latest` - Continue asking agents to debug Workers locally as usual; trace access is provided automatically. Cloudflare’s recommendation is to use local tracing as part of the normal agent-driven development loop, giving agents structured runtime evidence to diagnose problems and validate fixes before deployment.

Read original(opens in new tab)
ObservabilityCloudflare WorkersDurable ObjectsSqlite+4
cloudflare3 min readCurated summary

Introducing: Cloudflare Agents

Cloudflare is introducing Agents, a unified platform for deploying, observing, and improving hosted AI agents. Its first major feature is agent tracing, which exposes model calls, tool execution, token usage, approvals, subagents, and underlying Cloudflare infrastructure in one view. The goal is to help developers diagnose agent failures, understand costs and latency, and use operational data to continuously improve agent behavior. ## Agent Tracing Adds Visibility - Traditional telemetry can show that an HTTP request succeeded while hiding agent-level failures, such as: - Choosing the wrong tool - Passing stale context to a subagent - Entering a token-consuming retry loop - Cloudflare’s agent-aware traces capture: - Agent invocations - Model calls and token usage - Tool executions and results - Approval or pause events - Supported subagent calls - These agent spans appear alongside existing Workers telemetry for fetches, KV, D1, Durable Objects, and other infrastructure. - Initial integrations support Think, Flue, and AI SDK through OpenTelemetry-compatible tooling. ## Reviewing Agents in the Cloudflare Dashboard - A new Agents view lists observed agents, traces, sessions, instances, runs, and token usage. - Developers can inspect agent behavior through: - **Session replay**, which reconstructs recorded conversations - **Trace waterfalls**, which show execution timing and nested operations ## Session Replay - The Messages tab displays: - System instructions - User messages - Model reasoning - Tool calls, arguments, and results - Final responses - Replay is based on captured data and does not re-execute the agent. - It can reveal malformed tool arguments, inappropriate tool choices, subagent handoffs, retries, and context that influenced later decisions. - Think, Flue, and AI SDK provide `storeMessages` and `storeTools` controls to determine whether message and tool payloads are recorded. - Payload capture can be disabled when data may contain personal information, secrets, or other sensitive content. ## Trace Waterfalls Connect Agent and Infrastructure Activity - Traces show how much time each part of a turn consumed and how operations relate to one another. - A parent agent can be connected to nested subagents, model calls, tools, and Cloudflare resources. - Example operations include: - A parent `TravelPlanner` invocation lasting 2.72 minutes - An `itinerary_builder` subagent using 1.83 minutes - Model calls with duration and provider-reported token usage - Tool executions - D1 queries and KV writes triggered by those tools - Nested tracing makes it possible to follow work from the original agent through delegated tasks and the infrastructure each task used. ## Enabling Agent Tracing - Enable tracing in `wrangler.jsonc`: ```json { "observability": { "traces": { "enabled": true } } } ``` - Setup then depends on the agent stack: - **Think and Flue:** Emit agent, conversation, turn, model, and tool telemetry through their tracing integrations. - **AI SDK:** Wrap the SDK with Cloudflare’s `wrapAISDK()` adapter. - **Custom harnesses:** Use Cloudflare’s custom spans API and OpenTelemetry’s Generative AI semantic conventions. ## Broader OpenTelemetry Support - Cloudflare plans to support the OpenTelemetry API directly inside Workers. - Frameworks that already emit standard Generative AI spans will eventually work in the Agents view without Cloudflare-specific adapters. - Standard agent and conversation identifiers will allow Cloudflare to group spans into agents and sessions. - This complements Cloudflare’s existing ability to export OpenTelemetry data by allowing Workers to accept standard telemetry directly. ## OpenTelemetry Export - Agent telemetry is not restricted to Cloudflare. - Traces can be exported to OTLP-compatible observability providers by configuring a destination in the Worker’s Wrangler configuration. Cloudflare’s initial Agents release focuses on making AI behavior inspectable rather than treating agents as opaque application requests. Developers should enable tracing, choose payload retention carefully for privacy, and use session replay and nested traces to identify correctness, latency, cost, and orchestration problems.

Read original(opens in new tab)
Cloudflare WorkersDurable ObjectsOpentelemetryWrangler+4
cloudflare3 min readCurated summary

How we built a software factory to drive Astro’s GitHub issue count to zero

AI-powered software factories can address a pressing open-source problem: maintainers are overwhelmed by the flood of AI-generated issues, pull requests, and security reports. The Astro team built an automated triage pipeline that reproduces bugs, diagnoses causes, creates fixes, and ships preview releases for verification. After several months, it reduced Astro’s open issues from more than 200 to roughly 30 without mass-closing or ignoring reports. ## Building an Issue-Triage Skill - The team began by automating issue triage, one of the most time-consuming parts of open-source maintenance. - The workflow mirrors manual debugging: - **Reproduce:** Clone the reporter’s reproduction repository and confirm the problem. - **Diagnose:** Instrument the code and add logging to identify the root cause. - **Verify:** Check tests, documentation, and comments to determine whether the behavior is actually a bug. - **Fix:** Turn the reproduction into failing tests, implement a solution, and deploy it. - Each phase runs in an isolated AI subagent to reduce the tendency to force a solution. - Subagents communicate through a sequential `report.md` file containing their findings. ## Running the Pipeline in GitHub Actions - The workflow is driven by GitHub issue labels rather than a separate internal database. - New issues begin with `triage needed`; verified fixes eventually move to `fix verified`. - The pipeline reconstructs its state from labels and existing issue comments. - When a fix is ready, it: - Creates a preview release using `pkg.pr.new`. - Posts the diagnosis, logs, and installation instructions to the issue. - Lets the original reporter test the patch. - Opens a linked pull request after confirmation. ## From a Repository Workflow to Flue - The team recognized that the process was not inherently tied to GitHub. - Its core structure consists of: - An external event. - A sequence of isolated subagents. - Separate reasoning and execution permissions. - Durable workflow state. - This generalization became **Flue**, an open, platform-agnostic framework for agent workflows that can respond to GitHub events, Slack messages, cron jobs, or webhooks. ## Effects on Maintainer and Community Work - Automation did not make the Astro team less connected to users. - Instead, it freed maintainers to spend more time: - Engaging with the community in Discord. - Participating in RFCs and feature discussions. - Collaborating with contributors. - The system is designed to resolve most incoming issues, while failures are treated as signals that the codebase needs improvement. ## Using Agent Failures to Improve the Codebase Agent mistakes often reveal problems that would also challenge human developers: - **Opaque abstractions:** Component boundaries are unclear. - **Missing documentation:** Important implementation decisions are unexplained. - **Insufficient testing:** Critical behavior lacks adequate unit tests. - For example, the bot repeatedly changed an HMR-related condition and caused regressions because the logic was poorly documented and under-tested. - Adding a precise comment clarified the intended behavior, after which the bot stopped making the same incorrect change. - Fixing these weaknesses improves both future automation and human maintainability. ## Extracting the Workflow into a GitHub Action - Initially, the triage system was embedded in the Astro monorepo, making changes risky and difficult to test. - The team separated it into the standalone `triagebot-action` repository. - This enabled independent testing and safer updates to Flue and the workflow. - The action now supports Astro and has been adopted or forked by other teams building their own automated development pipelines. The practical lesson is to start with a narrow, repeatable maintenance task, isolate agent responsibilities, make all reasoning auditable, and use failures to improve documentation, architecture, and tests.

Read original(opens in new tab)
AI AgentsOpen SourceGitHub ActionsAstro+4
cloudflare3 min readCurated summary

Announcing Cloudflare Wallets: The programmable wallet for the agentic Internet

Cloudflare is introducing Wallets to help AI agents discover, test, and pay for APIs without relying on humans to handle registration, billing, and API keys. Account Wallets will fund agent-controlled Virtual Wallets with configurable spending limits, while stablecoin micropayments through the x402 protocol enable machine-native transactions. Cloudflare also proposes human-readable wallet identities so merchants can recognize agents and their sponsoring organizations. ## The Challenge of Agent Onboarding - APIs are typically designed for humans, requiring login pages, payment methods, and manual API-key generation. - Agents lack: - Stable identities for signing up. - Native payment mechanisms. - As a result, agents often abandon API evaluation and delegate onboarding back to humans, limiting agentic commerce. ## Cloudflare Wallets and x402 Payments - Users can claim a Cloudflare Wallet handle that provides a persistent username for interactions with merchants. - Wallets will support: - Storing stablecoins. - Purchasing APIs, content, and other services. - Receiving funds. - Cloudflare’s Monetization Gateway will let eligible customers sell APIs and content through the x402 protocol. - x402 attaches micropayments directly to HTTP requests, supporting uses such as AI inference, data access, and content consumption. ## Account Wallets and Virtual Wallets - **Account Wallets** - Belong to human Cloudflare account owners. - Can be funded and drained by the owner. - Delegate spending authority to agents through Virtual Wallets. - **Virtual Wallets** - Are designed for agents and accessed through API keys. - Let agents spend independently within owner-defined limits. - Can enforce allowances, merchant allow lists, and maximum transaction sizes. - This structure gives agents autonomy while preventing uncontrolled spending. ## Enabling Low-Risk Exploration - Agents can try dozens or hundreds of APIs with inexpensive x402 micropayments. - Spending caps make autonomous experimentation safer: a small budget can support many low-cost trials. - Organizations could assign policies such as a $100 weekly AI-inference budget to each employee or agent. - Agents exceeding their limits can request a human override. - Administrators can review unusual spending, raise limits, or provide one-time funding when appropriate. - Cloudflare plans to support traditional funding and withdrawals in selected regions, with stablecoin self-funding available to eligible users. ## Building a Two-Sided Agentic Market - Monetization Gateway gives merchants tools to sell resources directly to agents. - Wallets add the buyer-side infrastructure needed for agents to purchase APIs, MCP tools, and content. - Together, these systems aim to create a machine-native marketplace where agents can transact without constant human intervention. ## Persistent Agent Identity - Merchants often cannot tell which person or organization an agent represents. - This makes it difficult to provide trials, credits, or other benefits without enabling abuse through large numbers of agents. - Wallets linked to Cloudflare accounts through `cloudflare.pay` will let agents optionally identify themselves. - An identity such as `research.example.cloudflare.pay` could indicate both the agent and its associated organization. - Agents may remain unidentified, while merchants can choose whether to prioritize known identities. ## Human-Readable Identifiers - Cloudflare compares agent identity to VPN use: an unidentified agent is not necessarily malicious but may need to establish greater trust. - Existing systems such as Web Bot Auth can associate agents with cryptographic keypairs. - Cloudflare Wallet handles would make those otherwise opaque identifiers easier for humans to recognize. - The proposal intentionally avoids defining a complete identity or verification standard, focusing instead on a simple, memorable naming layer. Cloudflare’s Wallets are intended to give agents both the ability to transact and the freedom to explore services safely. Account-level controls, Virtual Wallet spending policies, and optional persistent identities could provide the foundation for a more autonomous but accountable agentic economy.

Read original(opens in new tab)
AI AgentsAgentic CommerceStablecoinsX402+4
cloudflare3 min readCurated summary

How Cloudflare enforces engineering standards using AI

Cloudflare built the Codex to turn scattered engineering knowledge into governed, machine-readable standards that both engineers and AI agents can apply consistently. It now supports code reviews, technical design reviews, and incident reviews, with AI systems flagging nearly 230,000 violations and blocking about 16,000 merges. The central approach is to combine human-owned RFCs with structured extraction, staged enforcement, and context-aware agents. ## Why Cloudflare Built the Codex - Engineering guidance previously existed across formal documentation, repositories, chat, and individual experience. - Engineers struggled to determine whether guidance was current, authoritative, or relevant. - Growth made it difficult for anyone to know every standard or for reviewers to check every requirement. - The Codex provides a shared source of truth that can be retrieved and applied at the point of work. ## Governance and RFC Workflow - The Codex is divided into domains such as: - Architecture and control plane systems - Security and reliability - Programming languages including TypeScript and Rust - Each domain has an owner responsible for content quality and consistency. - Standards follow an RFC format using RFC 2119 terminology: - **SHOULD** for recommendations - **MUST** for mandatory requirements - Employees can propose RFCs through structured merge requests. - Proposals undergo increasingly broad review before domain-owner approval. - Approved RFCs are published to an internal Astro-powered site. - Enforcement is deliberately separated from approval: - Approved standards can generate findings. - Only enforced standards can block merges. - This gives teams time to adopt requirements and implement enforcement mechanisms. ## Structured Standards for Agents - Feeding all 60-plus RFCs directly into an LLM would consume too much context and reduce accuracy. - A dedicated agent extracts SHOULD and MUST statements into structured JSON. - Each statement includes: - A stable slug - RFC and domain metadata - Requirement level - Section and source link - Stable identifiers allow Cloudflare to track requirements across RFC revisions, systems, monitoring, and exception handling. - Cloudflare moved from concise Markdown extraction to JSON to enable filtering and progressive disclosure. - Future metadata may identify which SDLC stage applies, such as design, implementation, or runtime. ## AI Code Review - The AI code reviewer retrieves relevant statements first and loads complete RFCs only when more context is needed. - Approved-RFC findings are non-blocking recommendations. - Violations of MUST requirements in enforced RFCs can withhold approval or block a merge. - Since launch, the reviewer has: - Flagged nearly 230,000 violations - Withheld approval for almost 16,000 violations ## Faster Code Review Alternatives - Full AI reviews generally take several minutes because they use coordinators and multiple agents. - To reduce remediation delays, Cloudflare is also developing mechanically verifiable checks. - Language-specific Codex requirements can be distributed through custom linter configuration packages. - TypeScript was the first language to receive Codex linter support, alongside standardization on oxlint. The Codex’s practical value comes from connecting governed human standards to automated enforcement. Cloudflare’s staged RFC lifecycle, stable statement identifiers, and combination of AI review with fast linters provide a scalable way to preserve engineering knowledge while reducing review inconsistency.

Read original(opens in new tab)
Large Language ModelsTypeScriptRustAstro+4
discord2 min readCurated summary

Squircles, Styles, and Spacing: How Your Feedback is Helping Improve Mobile

Discord is updating its mobile app to align more closely with the refreshed desktop experience. The changes introduce consistent themes and shape conventions, improve accessibility and customization, and simplify the chat bar. The overall goal is to make Discord feel familiar and consistent regardless of platform. ## Desktop Themes Come to Mobile - Mobile now includes all four desktop base themes: - Light - Ash - Dark - Onyx - Ash restores the classic dark appearance with improved contrast for accessibility. - Onyx provides true black AMOLED backgrounds instead of dark gray, potentially reducing battery use on OLED displays. - Users can adjust contrast and saturation through Accessibility settings. - Nitro users’ voice and video tile backgrounds now match their selected profile theme across desktop and mobile. ## More Flexible Theme Customization - Users can choose which Light and Dark themes activate based on their device’s appearance mode. - The “Same as Device Theme” option is available under Appearance settings. - Device-theme synchronization takes priority over “Sync Across Devices.” - Themes such as Mint Apple for Light mode and Noir for Dark mode can be assigned to different times of day. ## Consistent Shapes Across the Interface - Discord now follows a simple visual rule: - People, including friends and bots, use circular avatars. - Servers and apps use squircle-shaped icons. - The distinction helps users identify people versus things while scanning lists. - Rounded corners on buttons, inputs, and containers have also been standardized. - Direct messages and group DMs remain circular to preserve their “friend circle” identity. ## A Less Crowded Chat Bar - The chat bar has been reorganized to create more space for composing messages. - Emoji, Gift, Voice Message, and frequently used quick actions remain visible near the right side. - Threads and app usage have moved into the **+** menu. - Long-pressing **+** provides a shortcut to any action without opening the full menu. - Although Threads and Apps now require an additional tap, the long-press gesture is intended to keep them readily accessible. Together, these updates make mobile Discord more visually consistent with desktop while giving users greater control over themes and preserving quick access to common actions.

Read original(opens in new tab)
Design SystemsDiscordAccessibilityDark Mode+3
meta4 min readCurated summary

GEM Training: How Meta Doubled the Efficiency of Its LLM-Scale Ads Foundation Model

Meta’s Generative Ads Recommendation Model (GEM), which powers ad recommendations across Instagram and Facebook, now trains at LLM scale across several thousand GPUs. By co-designing kernels, numerical precision, parallelism, networking, and memory management, Meta doubled end-to-end training efficiency to 20–25% Model FLOPs Utilization (MFU) while increasing training compute fourfold in 12 months. The work shows that recommendation models require infrastructure specifically adapted to their hybrid architecture and data patterns rather than a direct reuse of LLM techniques. ## GEM’s Architecture and Training Challenges - GEM combines: - Trillions of sparse embedding parameters. - Billions of dense parameters. - Sequence features, such as user activity history. - Non-sequence features, such as user location and ad representations. - Different feature groups use customized attention mechanisms while still supporting cross-feature learning. - Recommendation workloads differ substantially from typical LLMs: - User histories have highly variable lengths, making padding inefficient and potentially wasting up to 50% of computation. - Attention patterns are asymmetric, including long sequences with short windows and long queries with short key/value sets. - Small embedding dimensions and normalization layers create memory-bound operations. - CTR and CVR optimization are numerically sensitive, so aggressive low-precision training can harm model quality. ## Scaling Across Thousands of GPUs - GEM’s distributed training latency is determined by the slowest rank and the larger of its local computation or communication time. - Efficient scaling requires: - Computation to dominate communication. - Communication to overlap with computation without resource contention. - Minimal activation recomputation. - Balanced workloads across GPU ranks. - GEM makes these requirements difficult because: - Trillion-scale sparse parameters generate substantial communication. - Different layer types provide uneven opportunities for communication overlap. - Long sequences and large activations pressure GPU memory. - Jagged inputs create changing load imbalance and stragglers. ## Separating Compute and Scaling Efficiency - Meta measures end-to-end efficiency with: - **E2E MFU = Local MFU × Scaling Ratio** - **Local MFU** measures how effectively one GPU uses its compute hardware, including Tensor Cores and memory hierarchies. - **Scaling Ratio** measures how much single-GPU performance is retained across thousands of GPUs. - This framework separates: - Kernel design and numerical precision issues affecting individual GPUs. - Parallelism, networking, memory, and load-balancing issues affecting distributed training. ## Compute-Efficiency Optimizations - Meta developed recommendation-specific GPU kernels, including: - Jagged Flash Attention (JFA) for variable-length sequences. - Generalized Dot-Product Attention (GDPA). - BlockAttention. - These kernels are designed around GEM’s irregular shapes and asymmetric attention patterns rather than conventional LLM assumptions. - Mixed ultra-low-precision training, including MXFP8 for attention and MLP layers, improves throughput while accounting for recommendation models’ numerical sensitivity. - The kernels and precision recipes are customized to exploit the architecture of the latest-generation GPUs. ## Scaling-Efficiency Optimizations - Meta uses topology-aware five-dimensional parallelism to distribute GEM efficiently. - Dense parameters use: - Two-dimensional Fully Sharded Data Parallelism (FSDP). - Expert Parallelism. - Sparse parameters use fully sharded two-dimensional model parallelism. - These strategies are co-designed with Meta’s multi-tier network hierarchy to reduce communication overhead. - Streaming Multiprocessor (SM)-free collectives help communication run with less interference from GPU computation. - The overall design targets communication overlap, memory constraints, load balance, and the differing behavior of dense and sparse parameters. ## Results - GEM’s end-to-end training efficiency increased to 20–25% MFU. - Efficiency doubled over a 12-month period. - Total training FLOPs increased fourfold. - The results demonstrate that recommendation foundation models can reach LLM-scale training, but only through coordinated hardware and software optimization across kernels, precision, parallelism, networking, and memory. For large recommendation models, LLM infrastructure provides a starting point but is not sufficient. The practical recommendation is to optimize compute and distributed scaling as separate but connected problems, using workload-specific kernels, carefully validated low precision, topology-aware parallelism, and communication strategies tailored to sparse and dense model components.

Read original(opens in new tab)
Large Language ModelsRecommendation SystemsDistributed TrainingGpu Optimization+3
aws2 min readCurated summary

AWS Weekly Roundup: Price reduction of GPT models in Bedrock, CloudWatch managed collectors for Prometheus metrics, and more (August 3, 2026) | Amazon Web Services

The AWS Weekly Roundup highlights major updates in AI pricing, observability, multicloud networking, identity resilience, and data lakes. The biggest change is an up to 80% price reduction for OpenAI GPT‑5.6 Luna models in Amazon Bedrock, alongside several managed services that reduce infrastructure and operational overhead. ## Lower Bedrock Pricing for GPT‑5.6 - Effective July 30, GPT‑5.6 Luna inference prices dropped by 80%. - New pricing is: - $0.20 per million input tokens - $1.20 per million output tokens - GPT‑5.6 Terra prices decreased by 20%. - The reductions apply automatically and require no customer action. ## Managed Prometheus Monitoring in CloudWatch - Amazon CloudWatch now provides fully managed Prometheus collectors. - Customers can collect metrics from: - Amazon EKS - Amazon EC2 - Amazon ECS - Amazon MSK - Amazon OpenSearch Service - This removes the need to deploy and maintain custom Prometheus scraping agents. ## Private Multicloud Connectivity with OCI - AWS Interconnect for Oracle Cloud Infrastructure is now generally available. - It enables resilient, scalable private connections between AWS and OCI. - Traffic avoids the public internet, improving security, performance, and reliability for multicloud workloads. ## Multi-Region IAM Identity Center - IAM Identity Center can now replicate its built-in Identity Center directory across Regions. - During a primary-Region disruption, users can continue accessing AWS accounts through provisioned entitlements in additional Regions. - Previously, multi-Region support was limited to deployments using external identity providers. ## Variant Support in S3 Tables - Amazon S3 Tables now supports Apache Iceberg V3’s Variant data type. - Variant provides native, high-performance support for semi-structured data. - Suitable use cases include IoT sensor data, application logs, and schema-flexible payloads without storing everything as JSON blobs. ## Additional AWS Resources - New AWS CLI single-line commands simplify installation and upgrades across platforms and CI environments. - A deployment guide covers running Moonshot AI’s Kimi K3 on SageMaker HyperPod and Amazon EKS. - Amazon MSK Express brokers can deliver Kafka data to Apache Iceberg streaming tables on S3 Tables, with throughput of up to 10 GB/s. - AWS Summits and AWS Community Days offer upcoming opportunities for cloud and AI learning and networking. AWS users should review the new Bedrock pricing, consider managed CloudWatch collectors to reduce monitoring maintenance, and evaluate the multicloud, identity, and Iceberg updates for architectures requiring greater resilience and scalability.

Read original(opens in new tab)
Amazon BedrockApache KafkaApache IcebergAmazon Cloudwatch+4
kakao1 min readCurated summary

Beyond AI That Speaks Well: Making Kanana-o Speak the Way Users Want

The provided content does not include the blog post’s body. It only contains the title, author links, navigation, and search interface, so the article’s technical argument and conclusions cannot be summarized reliably. ## Available Information - **Title:** “Beyond AI That Speaks Well: Making Kanana-o Speak the Way Users Want” - **Topic indicated by the title:** Improving Kanana-o’s voice-generation capabilities to produce speech according to user preferences. - **Authors:** martin.gale, abigail.r, and edwin.ai - **Missing:** The article’s main sections, implementation details, experiments, and conclusions. Please provide the full article text or its URL content for a detailed summary.

Read original(opens in new tab)
AIMachine LearningKanana OSpeech Synthesis
kakao4 min readCurated summary

From AI That Speaks Well to AI That Speaks Exactly as Desired: Advancing Kanana-o Voice Generation

Kanana-o’s latest speech-generation improvements target two goals: faster, more efficient synthesis and more precise adherence to user instructions. Kakao addresses these through LM-SPT, a speech tokenizer that separates semantic and acoustic information while reducing the token rate from 25 Hz to 12.5 Hz, and through online reinforcement learning. Together, these changes enable Kanana-o to generate natural speech more efficiently and control characteristics such as speed, pitch, tone, and volume more reliably. ## Goals for Kanana-o’s Speech Generation - Improve real-time performance by shortening speech-token sequences and simplifying decoding. - Move beyond merely natural speech toward speech that follows explicit user preferences. - Support control over: - Speaking speed - Voice quality and tone - Pitch and intonation - Volume - Emotional and conversational style - Combine better speech representation with instruction-following training. ## Limitations of the Original System - The original Kanana-o represented speech with 25 discrete tokens per second. - Its Voice Token LM generated these tokens sequentially based on text responses and conversation context. - Speech reconstruction required two stages: - **Token-to-Mel:** Convert speech tokens into a mel-spectrogram. - **Mel-to-Waveform:** Convert the mel-spectrogram into a waveform. - The tokenizer captured linguistic content effectively but did not explicitly represent acoustic properties such as voice timbre, pitch, intonation, speed, or emotion. - Long token sequences increased generation latency and computational cost. - The two-stage decoder, often involving iterative diffusion or flow-matching inference, made the pipeline difficult to optimize for real-time services. ## LM-SPT: A More Efficient Speech Tokenizer - LM-SPT stands for **LM-aligned SPeech Tokenizer**. - It compresses speech to 12.5 frames per second—half the original rate—reducing the number of sequential prediction steps. - It represents both: - **Semantic speech tokens:** The spoken content aligned with text and conversational context. - **Acoustic speech tokens:** Voice-specific details such as timbre, pitch, intonation, and speaking rate. - This separation allows the language model to generate content and acoustic characteristics more independently and controllably. - LM-SPT uses: - Two encoders for semantic and acoustic information - One semantic codebook - Multiple acoustic codebooks - A Split Residual Vector Quantization structure ## Semantic Speech-Resynthesis Distillation - Training only for waveform reconstruction does not guarantee that semantic and acoustic information remain separated. - Earlier systems commonly distilled representations from self-supervised models such as HuBERT or WavLM. - That approach can suffer from: - Misalignment between phonetic representations and higher-level language-model semantics - Loss of information when matching models with different frame rates - LM-SPT instead uses a **Semantic Speech-Resynthesis Distillation** method: - Reconstruct speech using only semantic tokens. - Compare the original and reconstructed speech with a pretrained speech encoder aligned to language-model representations. - Train the semantic tokens to preserve the same meaning without requiring exact frame-by-frame teacher alignment. - This approach helps retain meaningful content even at the lower 12.5 Hz token rate. ## Simplified Speech Decoding - During normal tokenization and reconstruction, the system does not require a heavy pretrained speech encoder. - A lightweight learned encoder is sufficient. - The final decoder uses semantic and acoustic tokens together to reconstruct the waveform directly. - This removes the intermediate mel-spectrogram stage and replaces the previous two-stage process with a lighter single-decoder structure. - As a result, the system reduces both language-model generation length and waveform reconstruction complexity. ## Instruction Following Through Online Reinforcement Learning - LM-SPT provides the representation needed to control acoustic features at the token level. - Kanana-o also applies online reinforcement learning to teach the speech-generation module to follow diverse vocal instructions. - The objective is to balance: - Accurate compliance with requested speaking styles - Natural and high-quality audio output Kakao’s approach combines a lower-rate, semantically and acoustically structured tokenizer with reinforcement learning for instruction adherence. The result is intended to make Kanana-o faster and more suitable for real-time use while allowing users to specify not only what the system says, but how it says it.

Read original(opens in new tab)
MultimodalKanana OSpeech SynthesisLm Spt+3
cloudflare3 min readCurated summary

Your agent needs a computer, not a container — introducing @cloudflare/computer

Cloudflare argues that scalable AI agents need their own computer-like environment—filesystem, shell, tools, and execution capabilities—rather than isolated access to ad hoc tools. Its early-preview `@cloudflare/computer` package abstracts across isolates, containers, and browsers while sharing a durable filesystem. The goal is to provide scalable, efficient compute for potentially hundreds of millions or billions of concurrent agents. ## Why Traditional Containers Do Not Scale - Coding agents work best when they can inspect files, run commands, install packages, modify code, and test their changes. - Giving every agent a dedicated container is too resource-intensive for large-scale deployments. - The industry is increasingly demanding CPU compute because agent workloads require substantial execution capacity in addition to GPU-based model inference. - Cloudflare believes agent infrastructure must move beyond conventional container-per-agent architectures. ## Isolates and On-Demand Containers - Cloudflare’s isolates start and stop quickly, scale horizontally, hibernate while idle, and can preserve agent state. - Durable Objects can host the agent loop and invoke containers only when heavier computation is necessary. - This architecture combines: - Isolates for lightweight, scalable coordination and file operations. - Containers for Linux environments, npm, native binaries, and other resource-intensive tasks. - Cloudflare wants to hide the complexity of combining these primitives from application developers. ## A Shared, Durable Filesystem - `@cloudflare/computer` gives each agent a declaratively initialized workspace containing the files and tools needed for its task. - Agents can select the most suitable execution environment: - Isolates for file manipulation, data processing, or Git operations. - Containers for commands requiring Linux, npm, or native binaries. - All environments operate on synchronized copies of the same source filesystem. - The filesystem can work with Git repositories, storage buckets, and arbitrary files. - File operations can be performed through Code Mode or Bash. - Operations are gated, audited, and observable, enabling fine-grained permissions and a record of agent activity. ## Using `@cloudflare/computer` - A workspace can be attached to any Durable Object to provide virtual filesystem and execution capabilities. - Installation uses: ```bash npm install @cloudflare/computer ``` - A `Workspace` is initialized with Durable Object storage and can be connected to an agent framework such as `@cloudflare/think`. - The example describes a bug-triage agent that: - Works in `/workspace/repo`. - Reproduces and investigates bugs. - Applies focused fixes when appropriate. - Runs verification commands. - Reports changes, commands, and verification results. - The package supports multiple execution backends, including Cloudflare Containers, and allows developers to implement custom backends. Cloudflare is presenting `@cloudflare/computer` as an open-source experiment and is seeking feedback from customers building agents at scale. Its practical recommendation is to use isolates as the default execution layer and attach containers only for tasks that genuinely require them, while sharing a controlled, durable workspace across both.

Read original(opens in new tab)
TypeScriptCloudflare WorkersDurable ObjectsIsolates+3
cloudflare2 min readCurated summary

Workers RPC now works across Python and JavaScript

Workers RPC, originally based on Cap’n Proto RPC, is expanding from JavaScript-only communication to seamless JavaScript–Python interoperability through Cap’n Web. Workers can call methods, pass objects and functions, propagate exceptions, and use native language types without schemas, dependencies, or significant performance overhead. The result is a multi-language system that can be used much like a local library. ## Cross-Language RPC in Workers - JavaScript Workers can call Python Worker methods, and Python Workers can call TypeScript methods. - Objects, functions, streams, and live remote objects can be passed between Workers. - A Service binding is the only required configuration. - RPC calls return promises in JavaScript/TypeScript and futures in Python. - Exceptions propagate back to the call site. - Most calls run in the same thread, providing near-zero overhead compared with local execution. - The implementation is open source through `workerd` and `workers-runtime-sdk`. ## Automatic Type Conversion - RPC supports Structured Cloneable values as parameters and return values. - Common types are converted into native equivalents, such as JavaScript `Date` to Python `datetime`. - JavaScript objects can correspond to Python dictionaries, while Python keyword arguments can represent JavaScript options objects. - Functions can cross the language boundary; invoking a transferred function creates a reverse RPC call to its original Worker. ## Pyodide’s Role - Python Workers use Pyodide, a WebAssembly-compiled CPython runtime. - Pyodide’s Foreign Function Interface translates common values automatically: - Python `int` and `float` → JavaScript `Number` - Python `bool` → JavaScript `Boolean` - Python `dict` → JavaScript `Object` - Python `list` → JavaScript `Array` - Types that cannot be directly converted, such as custom classes and functions, are represented by proxies that forward property access and method calls. ## Handling Worker-Specific Objects - Standard Web API objects such as `Request`, `Response`, `Blob`, and `File` do not have direct Python equivalents. - Pyodide initially exposes these values as JavaScript proxy objects. - Although proxies remain functional, they expose JavaScript implementation details to Python developers and make the API less natural. - The project therefore requires an additional conversion layer to provide Python-friendly representations of Cloudflare Workers objects. ## Practical Implication Cross-language Workers RPC lets teams combine Python and JavaScript services without manually designing APIs or serialization formats. Developers can use each language’s native calling conventions while the runtime handles translation, proxies, and communication behind the scenes.

Read original(opens in new tab)
TypeScriptPythonJavaScriptCloudflare Workers+4