Figma’s Make kits and Make attachments add structured context to AI-generated prototypes, helping them start closer to production reality. Make kits provide design-system guidance through code packages, libraries, styles, and tokens, while attachments bring in project-specific data and requirements. Together, they reduce cleanup and make generated designs more consistent with how products are actually built.
## Make Kits Teach Make About the Design System
- Make kits are reusable packages that combine components or styles with guidelines explaining how they should be used.
- They can use:
- JavaScript components from public npm packages
- Packages from Figma’s secure private registry
- Styles and design tokens from Figma libraries
- Guidelines tell Make not only which components exist, but also how to apply them.
- Instead of starting with generic UI and repeatedly correcting spacing, patterns, and components, Make can begin with production-aligned structures.
- This helps:
- Maintain consistency across forms, dashboards, settings, and onboarding
- Let teams generate work in parallel without drifting from the design system
- Reduce preparation and correction before review
- Engineers can more easily recognize familiar components and focus on evaluating the proposal rather than translating it into their system.
- Figma plans to expand kits to represent more design-system structure, including component structures from Figma libraries.
## Make Attachments Ground Prototypes in Project Context
- Design systems do not capture every project-specific constraint, such as:
- Real data
- Migration requirements
- Edge cases
- Compliance rules
- Legal copy and content
- Make attachments allow users to provide source material directly instead of describing everything in a long prompt.
- Supported materials include:
- PDFs and Markdown files
- CSV and JSON datasets
- Screenshots and images
- Brand guidelines
- Legal copy
- Media and SVG files
- Code and other project assets
- Attachments help Make create prototypes that reflect actual data, validation states, content, and requirements rather than producing an idealized version that omits complexity.
- For example, an onboarding flow can be grounded in real user data, complete legal requirements, and multiple validation states instead of shortened copy and simplified edge cases.
## A More Production-Aligned Starting Point
- Make kits provide the reusable design and code foundation.
- Attachments add the details and constraints unique to a specific project.
- The combination is intended to shorten the distance between an AI-generated prototype and a shippable product, allowing teams to spend less time rewriting and more time refining the experience.
Discord announces **Last Meadow Online**, a multiplayer sequel to *The Last Meadow* from its in-house studio, Big Wump Games. Players join Wumpus to battle Grass Toucher, a dragon that consumes foliage, in a Discord-based massively multiplayer incremental role-playing game. The game is playable directly on Discord desktop for a limited time, with participants earning an exclusive profile badge.
## A New Threat for Wumpus
- After completing the original adventure, Wumpus returns to town to celebrate reaching The Last Meadow.
- The celebration is interrupted by Grass Toucher, a foliage-absorbing dragon.
- Defeating the threat requires cooperation from a large number of players.
## Multiplayer Gameplay on Discord
- Players collaborate with Discord users around the world.
- Available character roles include:
- Paladin, wielding the light
- Ranger, using keen marksmanship
- Priest, providing healing
- Players can also contribute through crafting and other handiwork skills.
- The game is described as a “Discord-Based Massively Multiplayer Incremental Role Playing Game” (DBMMIRPG).
## Availability and Rewards
- *Last Meadow Online* is playable directly within Discord on desktop.
- The game is available for a limited period, through April 7.
- Everyone who helps defeat Grass Toucher receives a limited-edition badge for their Discord profile.
Players are encouraged to join friends and contribute before the event ends, making the announcement both a multiplayer game launch and a time-limited Discord community event.
Amazon ECS Managed Daemons let platform teams independently deploy and maintain monitoring, logging, and tracing agents across ECS Managed Instances. This decouples operational tooling from application task definitions, reducing coordination and redeployment work. ECS ensures daemons are available before applications start and maintains coverage during rolling updates.
## Decoupled Daemon Management
- Platform teams can centrally deploy and update agents without changing application services or rebuilding AMIs.
- Daemons can target multiple or specific capacity providers.
- Each instance runs exactly one daemon copy shared by its application tasks.
- CPU and memory settings are managed separately from application configurations.
- Daemons start before application tasks and are drained after them.
## Deployment and Updates
- Daemon task definitions are created separately in the ECS console.
- A daemon can be associated with a cluster and an ECS Managed Instances capacity provider.
- ECS automatically launches the daemon on every applicable instance.
- Rolling updates use a “start before stop” process:
- New instances launch with the updated daemon.
- The daemon starts before application tasks migrate.
- Old instances are terminated afterward.
- Configurable drain percentages control replacement speed, while automatic rollback improves update safety.
## Technical Capabilities
- Managed daemons use a dedicated `daemon_bridge` network mode to communicate with application tasks while remaining isolated from application networking.
- They support privileged containers, additional Linux capabilities, and host filesystem mounts.
- These features enable host-level monitoring of metrics, processes, and system calls.
- ECS validates and manages daemon-specific task definitions independently from standard application tasks.
## Availability and Cost
- Managed daemon support is available in all AWS Regions.
- There is no additional managed-daemon fee; users pay only for the compute resources consumed by daemon tasks.
- The feature can be configured through the ECS console, APIs, and documentation.
For organizations running many ECS services, managed daemons provide a simpler and more reliable way to operate shared infrastructure agents without involving application teams in every update.
Attackers increasingly target GitHub Actions workflows to steal secrets, publish malicious packages, and spread into additional projects. GitHub recommends reducing credential exposure, hardening workflows, and using automated tools such as CodeQL and Dependabot. It is also expanding trusted publishing, malware detection, and GitHub Actions security improvements in response to campaigns such as Shai-Hulud.
## How attacks begin
- Many supply-chain attacks start by exploiting insecure GitHub Actions workflows.
- Stolen API keys and other secrets can let attackers publish packages from their own machines.
- Malicious packages can then compromise downstream projects and propagate the attack.
## Securing GitHub Actions today
- Enable CodeQL’s GitHub Actions queries, which are free for public repositories, to identify workflow security weaknesses.
- Avoid triggering workflows with `pull_request_target`.
- Pin third-party Actions to full-length commit SHAs.
- Updates should be made by maintainers or Dependabot.
- Treat pull requests that change pinned Actions with suspicion.
- Protect workflows against script injection when using pull-request or other user-submitted content.
- Monitor GitHub’s Advisory Database and use Dependabot malware alerts to detect compromised or vulnerable dependencies.
## Replacing secrets with trusted publishing
- GitHub recommends using short-lived OpenID Connect tokens containing a workflow’s workload identity instead of storing long-lived secrets.
- Cloud providers, package registries, and hosted services can use these tokens to authorize workflow activity.
- Through collaboration with OpenSSF, trusted publishing is supported by npm, PyPI, NuGet, RubyGems, Crates, and other registries.
- Trusted publishing both removes credentials from build pipelines and provides a signal when a package unexpectedly switches away from it.
## Detecting malicious packages
- npm publishes more than 30,000 packages daily and scans every package version for malware.
- Hundreds of newly published packages contain malicious code each day.
- Human review confirms detections before action is taken, helping avoid disrupting legitimate maintainers.
- Even a 1% false-positive rate would affect hundreds of valid package releases daily at npm’s scale.
## GitHub’s upcoming security work
- Attacks such as Shai-Hulud accelerated npm’s security roadmap.
- GitHub is expanding trusted publishing, malware detection and removal, and collaboration with maintainers.
- The company is also revisiting and accelerating its GitHub Actions security roadmap.
- New protections may require workflow changes or create compatibility concerns, so GitHub aims to make the transition gradual and solicits community feedback.
Projects should audit their Actions workflows immediately, eliminate long-lived publishing credentials where possible, pin dependencies, and enable CodeQL and Dependabot. Adopting trusted publishing provides both stronger protection and useful evidence for identifying suspicious package releases.
GitHub Copilot CLI’s `/fleet` command lets multiple subagents work on independent tasks simultaneously rather than completing everything sequentially. An orchestrator decomposes the objective, manages dependencies, dispatches agents, and verifies their results. To benefit from parallel execution, users should define clear deliverables, boundaries, dependencies, and validation requirements.
## How `/fleet` Works
- Breaks a task into discrete work items and identifies dependencies.
- Runs independent items in parallel as background subagents.
- Waits for completed work before dispatching dependent tasks.
- Verifies results and assembles the final output.
- Gives each subagent its own context window while sharing the same filesystem.
- Prevents direct communication between subagents; the orchestrator coordinates them.
## Getting Started
- Run `/fleet <objective prompt>` interactively, such as:
```bash
/fleet Refactor the auth module, update tests, and fix the related docs in docs/auth/
```
- For terminal-based non-interactive use:
```bash
copilot -p "/fleet <YOUR TASK>" --no-ask-user
```
- The `--no-ask-user` option is required when no one is available to answer prompts.
## Writing Parallelizable Prompts
- Define concrete deliverables such as individual files, test suites, or documentation sections.
- Avoid vague requests that make it difficult to identify independent work.
- Explicitly state:
- File or module ownership
- Constraints, such as avoiding dependency changes
- Required tests, linting, or type checks
- List dependencies so the orchestrator can serialize only the necessary work while parallelizing the rest.
## Using Custom Agents
- Specialized agents can be defined in `.github/agents/`.
- Agent definitions may specify:
- Model
- Tools
- Role-specific instructions
- Prompts can assign different agents to different tracks, such as using a technical writer for documentation and the default agent for code.
- If no model is specified, the agent uses the current default model.
## Monitoring Fleet Execution
- Review the initial decomposition to ensure the task has multiple independent tracks.
- Use `/tasks` to inspect active background work.
- Look for progress updates from separate tracks.
- If work is proceeding sequentially, ask Copilot to decompose the task first and report each track’s status and blockers.
## Avoiding File Conflicts
- Subagents share a filesystem without file locking.
- If two agents edit the same file, the last completed write silently overwrites the other.
- Assign distinct files or directories to each track.
- For shared files, use temporary outputs and merge them afterward, or impose an explicit execution order.
Use `/fleet` for well-partitioned work with clear ownership and dependencies. Careful prompt structure is essential: parallelism is most effective when agents can operate independently without competing for the same files.
Cloudflare reports that an independent Big Four accounting firm has confirmed its 1.1.1.1 public DNS resolver continues to meet its privacy commitments. The review was conducted because Cloudflare’s DNS infrastructure has expanded and become more complex since the previous examination in 2020. Cloudflare says it aims to make privacy the default and encourages other public DNS providers to undergo similar independent reviews.
## Renewed Independent Privacy Examination
- Cloudflare launched 1.1.1.1 in 2018 as a fast, privacy-focused DNS resolver.
- A first independent review took place in 2020.
- After major changes to its technology stack and DNS platform, Cloudflare commissioned the same accounting firm to conduct another examination.
- The latest review examined evidence collected after the 2024 calendar year and took several months to complete.
- The resulting report is available through Cloudflare’s compliance resources.
## Confirmed Privacy Commitments
The examination confirmed that:
- Cloudflare does not sell or share public resolver users’ personal data with third parties.
- Resolver data is not used to target users with advertisements.
- Cloudflare retains or uses the requested DNS information, rather than information identifying the person making the request.
- Source IP addresses are anonymized and deleted within 25 hours.
- DNS query information is not combined with other Cloudflare or third-party data in a way that could identify individual users.
## Limited Network Troubleshooting Data
- Cloudflare may use randomly sampled network packets for troubleshooting and attack mitigation.
- These samples represent no more than 0.05% of total traffic.
- The samples can include the querying IP address, but are used solely for operational security and network reliability purposes.
## Scope of the Latest Review
- Unlike the broader 2020 examination, the latest review focused exclusively on privacy commitments.
- The earlier review also covered how Cloudflare handled anonymized transaction and debug logs, known as “Public Resolver Logs.”
- Cloudflare says the use of those logs has evolved, including supporting services such as Cloudflare Radar.
- The company maintains that these changes do not affect personal information or user privacy.
Cloudflare’s practical position is that 1.1.1.1 users should not have to trust privacy promises alone: independent examinations should verify them. It recommends reviewing the published accountant’s report and continues to present 1.1.1.1 as a privacy-first DNS option.
EmDash is presented as a modern, TypeScript-based successor to WordPress, designed for today’s serverless hosting environment. Its central innovation is isolating plugins in sandboxed Dynamic Workers and granting them only explicitly declared capabilities. The project aims to preserve WordPress’s open-source publishing model while addressing plugin security, marketplace dependence, and licensing concerns.
## Modernizing WordPress for Today’s Web
- WordPress powers more than 40% of the Internet but was designed when hosting commonly meant managing virtual private servers.
- EmDash is:
- Written entirely in TypeScript
- Built on Astro
- Serverless, while still deployable on personal hardware or Node.js servers
- Fully open source and MIT licensed
- Intended to remain compatible with WordPress-style functionality without using WordPress code
- Version 0.1.0 is available as an early developer beta for Cloudflare or Node.js deployment, along with an online playground.
## Building on WordPress’s Publishing Legacy
- WordPress democratized publishing and created a large ecosystem of core contributors, plugin developers, and theme developers.
- The authors argue that WordPress will continue to have a role, but newer developers increasingly use Astro and TypeScript frameworks.
- EmDash seeks to provide a similarly accessible, inexpensive, and open publishing platform suited to modern development practices.
## Sandboxed Plugins and Explicit Permissions
- WordPress plugins are PHP scripts with direct access to the site’s database and filesystem.
- This lack of isolation is identified as the source of most WordPress security problems:
- 96% of WordPress site security issues reportedly originate in plugins.
- High-severity vulnerabilities increased substantially in 2025.
- EmDash runs each plugin inside an isolated Dynamic Worker.
- Plugins access platform functionality through capability-based bindings rather than direct access to underlying resources.
- A plugin must declare its required permissions in its manifest, allowing administrators to evaluate permissions before installation.
- The example notification plugin:
- Reacts to content-save events
- Checks whether a post has been published
- Sends an email to editors
- Logs the notification
- Plugins have no general external network access. If network access is necessary, the plugin can request permission for specific hostnames.
- Administrators or platforms could enforce installation policies based on requested permissions instead of relying solely on approved-plugin allowlists.
## Security, Marketplaces, and Licensing
- WordPress.org manually reviews plugins because the platform cannot otherwise guarantee their safety.
- The review queue reportedly exceeds 800 plugins and can take at least two weeks.
- Marketplace reputation, ratings, and reviews therefore become essential substitutes for technical trust.
- Because WordPress plugins run inside WordPress and are tightly coupled to its code, developers may also face GPL licensing constraints.
- The article argues that plugin security creates marketplace lock-in:
- Customers rely on marketplaces to assess plugin trustworthiness.
- Developers may need to distribute code under restrictive licensing terms to participate.
- Hosting platforms inherit the risk of running third-party plugins.
- EmDash’s sandboxing and permission model is positioned as a way to reduce reliance on centralized marketplace approval, though the provided article excerpt ends before explaining the promised “two important properties” in full.
EmDash’s practical recommendation is to use capability-limited, isolated plugins as the foundation for a more secure and flexible WordPress-like ecosystem. Its early beta is intended for developers who want to evaluate that model on Cloudflare or Node.js.
MessagingHub turns chat into a reusable platform rather than rebuilding it for each product domain. It separates domain-specific authentication and business context from common chat capabilities, allowing chatbot, customer-support, direct, and group conversations to share the same infrastructure. Its policy-driven design, modular architecture, and configurable metadata aim to reduce integration complexity while preserving flexibility.
## Why MessagingHub Was Introduced
- Chat requirements vary across chatbots, customer support, one-to-one conversations, and group chats.
- Building each implementation independently increases integration points, system complexity, development cost, and the impact of small changes.
- MessagingHub is designed as a domain-independent platform that can be adopted by multiple services.
- The platform focuses on chat itself while absorbing external requirements through generalized, reusable structures.
- It is currently used by a Japanese food-delivery service for users, drivers, customer-service agents, and restaurants.
## Supported Chat Types
- **Chatbots:** Delivered through a public web URL embedded in a partner service’s webview. Scenarios are created and deployed through an administrative console.
- **Inquiry chat:** A user is matched with a customer-service agent. The partner domain supplies contextual information such as user details and previous consultation history.
- The platform is also structured to support direct one-to-one and group conversations.
## Core Platform Policies
### Authentication and User Identification
- MessagingHub does not manage user accounts or domain authentication.
- Partner systems handle login, registration, permissions, and the decision of whether a user may access chat.
- After authenticating a user, the partner requests a connection token and passes it to the client.
- The client uses the token to establish a WebSocket connection; unauthenticated direct access is not allowed.
- A user is identified by a `client_id`, combining the partner domain identifier with the partner’s user identifier.
- Display names, profile images, and `pushToken` values are supplied and updated by the partner system.
### Service Contexts and Room Types
- A **service context** defines which roles may communicate, such as:
- `Driver2CS`
- `Consumer2CS`
- A **chat room type** defines the conversation structure, such as:
- `USER_DIRECT`
- `USER_GROUP`
- `INQUIRY_CHATBOT`
- `INQUIRY_CHAT`
- The combination of service context and room type controls room creation, participation, and message permissions.
### Room Lifecycle and Data Retention
- General room states progress from `WAIT` or `PENDING`, to `SERVICE`, and eventually to `DISABLE` or `BLOCK`, where sending messages is prohibited.
- Messages and potentially identifying data are encrypted at rest.
- Data can be deleted immediately when all participants leave a room.
- Partners can also configure retention periods for automatic deletion of older data.
## Modular Architecture
MessagingHub is not a monolithic chat server. Its components have clearly separated responsibilities and communicate through loosely coupled events.
- **`connection-manager`**
- Manages WebSocket connections and validates connection tokens.
- Tracks user connection status.
- Helps identify active chatbot scenario connections during `SOFT STOP` processing.
- **`chat-app`**
- Implements core chat logic, including message delivery, room creation, state transitions, and read status.
- Exposes functionality as commands that can be combined for different chat types.
- **`message-router`**
- Determines where recipients are connected.
- Routes messages from the chat server to the appropriate connection-management component.
- **`notification-app`**
- Sends push notifications when recipients are offline or the application is in the background.
- Uses partner-provided `pushToken` values and room-level notification settings.
- **`admin-hub`**
- Manages chatbot scenario editing and deployment.
- Handles agent accounts, roles, service contexts, events, webhooks, monitoring, and statistics.
## Command-Based Chat Flows
- Chat behavior is modeled as composable commands.
- Common commands provide functionality shared across chat types.
- Chatbot and inquiry-chat features add more specialized commands.
- This “building block” approach allows business requirements to be assembled without creating a separate chat implementation for every domain.
## Data Model
MessagingHub separates operational data from core chat data:
- **`chat` database:** Stores users, rooms, participants, metadata, and messages.
- **`chat_operation` database:** Stores operational and administrative information.
Important entities include:
- `chat_user`: Uniquely identifies users by `client_id`.
- `chat_room`: Represents rooms and enforces room uniqueness at the schema level.
- `chat_member`: Connects users to rooms.
- `chat_room_meta`: Stores participant-specific state, including read position, push settings, input restrictions, and room status.
- `chat_log`: Stores encrypted messages in a one-to-many relationship with rooms.
- `prev_chat_log_id` preserves message ordering.
- Room-level first and last message IDs, together with participant read positions, support unread-count calculation.
- Partner metadata such as `system_data`, `search_data`, `user_details`, and `descriptions` is stored as JSON. MessagingHub preserves and forwards it without interpreting its domain meaning.
- Scheduling, event, and webhook history are tracked through tables such as `chat_schedule`, `chat_event_record`, and `webhook_event_record`.
- `service_context`, `chat_event`, and `webhook` configure allowed role relationships, event-message policies, and webhook behavior.
## Chatbot Scenario Management
### Flexible Scenario Structure
- Administrators manage multiple chatbot scenarios through an editing tool.
- Scenarios define messages, selectable options, and answers.
- Webhooks can dynamically generate response content.
- The hierarchical data model supports a broad range of chatbot flows.
### Version Deployment and `SOFT STOP`
Chatbot scenarios transition through:
`WAIT → SERVICE → SOFT STOP → DISABLE`
- A newly deployed scenario becomes `SERVICE`.
- The previous scenario moves to `SOFT STOP`.
- Existing users can finish conversations using the previous version.
- New users are directed to the latest scenario.
- A scheduler periodically checks whether any users still have active connections to the old scenario.
- Connection information is collected from connection-management servers and stored in a shared resource.
- Once no active users remain, the old scenario is disabled and the scheduler stops.
- This provides backward compatibility without disrupting users during deployment.
## Inquiry Chat Metadata and Lifecycle
### Partner-Defined Metadata
Inquiry chat allows partner domains to provide information that helps agents handle cases effectively:
- Search data for finding conversations
- User details shown to agents
- Custom display data
- Event data for surveys or webhooks
- Basic consultation descriptions
- Room settings such as room names and push-notification titles
- Tracking data for identifying and mapping rooms in partner systems
### Room Lifecycle
Inquiry rooms generally move through:
`PENDING → SERVICE → DISABLE → BLOCK`
- `PENDING` represents the period while the user waits for an agent match.
- `SERVICE` is the active consultation period.
- `DISABLE` indicates that the consultation has ended.
- `BLOCK` prevents further messaging after closure.
MessagingHub’s overall approach is to keep the platform’s responsibilities narrow and reusable while allowing partner domains to own authentication, user meaning, and business-specific metadata. For organizations supporting multiple chat scenarios, a policy-driven, command-based platform with separated components and explicit data ownership can significantly reduce duplication and integration risk.
This Figma Make-a-thon showcase argues that software interaction can become more expressive, playful, and socially connective when designers rethink familiar conventions. The winning projects use technology to recreate communal crafts, enable hands-free control, and expand physical experiences beyond traditional limits. Together, they suggest that creativity and emotional connection—not just speed and efficiency—should shape digital experiences.
## Collaborative Embroidery: Common Thread
- Charlota Blunárová’s winning project adapts the tradition of handmade samplers into a shared online canvas.
- Visitors choose thread colors and stitch types, then contribute to a communal embroidery piece alongside strangers.
- The project deliberately imposes constraints: one shared canvas becomes more meaningful as people add to it over time.
- More than 100,000 stitches have been added, turning the site into an evolving, collectively authored artifact.
- Blunárová built the real-time collaboration and canvas interactions in Figma Make despite having no engineering background.
- Her process began with the desired feeling and used visual references, including logos and color palettes created in Figma.
## Hands-Free Interaction: Pucker
- Aleyna Çatak’s “Pucker” replaces tapping and voice commands with head movements and a lip gesture.
- Users tilt their heads to move through an interface, hold still to select an item, and pucker their lips to confirm.
- The concept is designed for situations where users’ hands are occupied, such as cooking, knitting, or designing.
- It also points toward more accessible interfaces that can be operated without touch or speech.
- Pucker uses a device’s front camera for real-time tracking and states that no data is stored or transmitted.
- Çatak describes it as a flexible interaction layer rather than a finished product, potentially adaptable across apps and platforms.
- Her advice is to understand basic coding concepts so prototypes can be refined and troubleshot more effectively.
## A Remote Photo Booth: Duet Booth
- Paige Latimer reimagines the traditional photo booth as a remote, asynchronous experience.
- Duet Booth allows two people in different places—or participating at different times—to take photos that are combined into one photo strip.
- The project preserves the photo booth’s sense of immediacy and shared participation while removing its physical and geographic constraints.
- Latimer recommends concentrating on the core interaction before polishing visual details, giving the rest of the design a strong foundation.
The projects presented in the article demonstrate how Figma Make lowers the barrier to prototyping ambitious ideas. Designers can use it to turn emotional concepts, alternative input methods, and collaborative rituals into working experiences—provided they begin with a clear sense of the feeling or interaction they want to create.
es-toolkit is a modern, TypeScript-first JavaScript utility library designed as a faster and smaller alternative to lodash. Built around ES Modules and independent functions, it can reduce bundle sizes by up to 97% and improve runtime performance by more than 2x. Its `es-toolkit/compat` package provides a 100% lodash-compatible migration path with little or no code changes.
## Why es-toolkit was created
- Toss’s frontend team saw an opportunity to modernize the utility-library ecosystem.
- lodash was designed before ES Modules, advanced JavaScript engines, TypeScript, and bundle size became central concerns.
- es-toolkit was built from scratch with:
- Native ES Module support
- Tree-shaking-friendly independent functions
- Built-in TypeScript definitions
- Modern runtime optimizations
## Bundle size and runtime performance
- lodash-es can include internal helper dependencies even when importing a single function.
- es-toolkit functions are designed to be independent, avoiding hidden dependencies.
- A sample set of five functions—`groupBy`, `keyBy`, `pick`, `omit`, and `debounce`—adds roughly:
- 30 KB with lodash-es
- 1 KB with es-toolkit
- The library reports up to 97% smaller bundles and more than 2x faster execution.
- Specific benchmarks include:
- `sample`: approximately 2,000 bytes in lodash versus 88 bytes in es-toolkit
- `omit`: approximately 11.8x faster at runtime
## Adoption and ecosystem support
- es-toolkit surpassed 10 million weekly npm downloads within 18 months.
- It has been adopted by Microsoft, Yarn, Storybook, IBM, Recharts, Ink, and Dify.
- The article emphasizes that adoption came through independent evaluations and benchmarks rather than major promotional campaigns.
## Migration from lodash
- Most imports can be changed directly:
```ts
import { pick } from 'es-toolkit';
```
- `es-toolkit/compat` provides a drop-in lodash replacement with full compatibility, validated against lodash’s test suite.
- Existing projects can redirect the `lodash` dependency without changing source code:
```json
{
"dependencies": {
"lodash": "npm:es-toolkit@^1.44.0"
}
}
```
- Teams can later migrate from compatibility imports to native es-toolkit imports for additional bundle and performance benefits.
- An official `@es-toolkit/codemod` tool is available to automate migration.
## TypeScript and maintenance
- Type definitions are shipped alongside the implementation and are kept synchronized.
- This avoids the version mismatches and inaccuracies possible with lodash’s separately maintained `@types/lodash` package.
- The project is actively maintained, with regular additions and responsive issue and pull-request handling.
## Project direction
- es-toolkit is part of Toss’s broader open-source initiative.
- Related projects include:
- `overlay-kit` for Promise-based React overlays
- `use-funnel` for type-safe multi-step flows
- `suspensive` for React Suspense primitives
- The library is MIT licensed and installable with `npm install es-toolkit`.
For most lodash users, the recommended approach is to start with the compatibility alias for an immediate, low-risk upgrade, then progressively adopt native es-toolkit imports to maximize bundle-size and performance improvements.
The AWS Sustainability console is a standalone service that centralizes AWS emissions reporting and sustainability resources. It builds on the Customer Carbon Footprint Tool while adding independent permissions, customizable reports, fiscal-year support, and programmatic access. The underlying emissions data and methodology remain unchanged, but organizations now have more flexible ways to analyze and automate sustainability reporting.
## Independent Sustainability Access
- Sustainability professionals can access emissions data without receiving AWS Billing permissions.
- The console uses a permissions model separate from the Billing console.
- Historical emissions data is available back to January 2022 at no additional cost.
## Scope 1–3 Emissions Reporting
- Reports AWS-related emissions in metric tons of carbon dioxide equivalent (MTCO2e).
- Covers:
- **Scope 1:** Direct emissions from controlled sources, such as data center fuel use.
- **Scope 2:** Indirect emissions from purchased energy.
- **Scope 3:** Value-chain emissions, including server manufacturing and data center construction.
- Data can be viewed by AWS Region and service, including Amazon EC2, Amazon S3, and CloudFront.
- Both market-based method (MBM) and location-based method (LBM) calculations are supported.
- The methodology is unchanged from the Customer Carbon Footprint Tool and has been independently verified by Apex.
## Configurable Reports and Fiscal Years
- The Reports page provides preset monthly and annual emissions reports.
- Users can create custom CSV reports by selecting:
- Fields
- Time granularity
- Date ranges
- Services, Regions, and other filters
- Organizations can configure fiscal years that differ from the calendar year.
- Once configured, data views and exports use the organization’s fiscal quarters and reporting periods.
## API and AWS CLI Access
- A new API and AWS SDK support integration with:
- Internal reporting pipelines
- Sustainability dashboards
- Compliance workflows
- Teams can retrieve emissions for specific periods across many accounts without creating a data export.
- Custom account groupings can be used even when they do not match the AWS Organizations hierarchy.
- The AWS CLI command `get-estimated-carbon-emissions` returns emissions values, time periods, units, and model versions for MBM and LBM data.
## Availability and Future Development
- The console is accessible through the AWS Management Console.
- It complements existing Data Exports, allowing users to investigate emissions visually and automate stakeholder reporting.
- AWS plans to expand the console with additional capabilities and publishes feature and methodology updates through its Release notes page.
Organizations can begin using the free AWS Sustainability console immediately to explore emissions trends, create tailored reports, and connect AWS carbon data to existing sustainability processes.
Slack needed better client-side observability while migrating edge services to HTTP/3, which uses QUIC over UDP rather than TCP. Existing SaaS tools and Prometheus Blackbox Exporter could not probe HTTP/3 endpoints, so an intern added QUIC support using Go’s `quic-go` library and open-sourced it. The result unified HTTP/1.1, HTTP/2, and HTTP/3 monitoring while making the capability available to the broader Prometheus community.
## Limitations of Legacy Monitoring
- Slack used a mix of commercial monitoring services and internal tools for network measurements.
- HTTP/3 introduced a major observability gap because it runs over QUIC/UDP.
- Existing SaaS solutions lacked built-in HTTP/3 probing.
- Prometheus Blackbox Exporter had no native QUIC support.
- Without probing at scale, Slack could not reliably measure round-trip times, detect regressions to HTTP/2, or monitor hundreds of thousands of HTTP/3 endpoints.
## Adding QUIC Support to Blackbox Exporter
- Intern Sebastian Feliciano selected `quic-go` because of its adoption and first-class Go HTTP client support.
- The implementation used an `http3.Transport` with TLS and QUIC configuration:
```go
http3Transport := &http3.Transport{
TLSClientConfig: tlsConfig,
QUICConfig: &quic.Config{},
}
```
- The new transport was attached to a standard Go `http.Client`.
- The implementation preserved Blackbox Exporter’s existing configuration and composability patterns.
- Sebastian open-sourced the feature and eventually got it accepted upstream.
## In-House Integration and Operational Benefits
- Because upstream review could take longer than the internship timeline, Slack built an internal system around the new functionality.
- Grafana now provides a unified view of HTTP/1.1, HTTP/2, and HTTP/3 metrics.
- Operators can compare protocol performance and correlate it with other telemetry.
- Improved visibility supports more accurate alerts and faster debugging of HTTP/3 issues.
## Future Enhancements
- **SNI routing tests:** Verify that shared edge infrastructure routes hostnames to the correct backend and presents the correct TLS certificate.
- **End-to-end path visualization:** Map network hops between monitoring agents and endpoints to identify latency spikes or packet loss more precisely.
## Broader Lessons
- Observability should be established before a major protocol or infrastructure migration.
- Filling gaps through open source can benefit both the organization and the wider engineering community.
- Supporting emerging protocols such as QUIC early helps future-proof monitoring systems.
Slack recommends trying the new QUIC functionality in Prometheus Blackbox Exporter and contributing to its continued development.
Meta’s Adaptive Ranking Model scales ad recommendation models toward LLM-level complexity without sacrificing sub-second latency or cost efficiency. It replaces uniform inference with intelligent request routing, selecting the most appropriate model for each user context. Since launching on Instagram in Q4 2025, it reportedly increased ad conversions by 3% and click-through rates by 5% among targeted users.
## The Inference Trilemma
- More complex models require substantially more compute and memory.
- Ads must still be selected and delivered within a sub-second latency budget.
- Simply adding hardware is too expensive for a service operating at global scale.
- Adaptive Ranking Model addresses these competing demands by matching model complexity to each request’s context and intent.
## Three Core Innovations
- **Inference-efficient model scaling**
- Reaches complexity comparable to roughly 10 GFLOPs per token in advanced LLMs.
- Maintains approximately 100 ms bounded latency—an order of magnitude faster than standard LLM inference.
- **Model/system co-design**
- Aligns model architectures with hardware and silicon capabilities.
- Achieves approximately 35% model FLOPs utilization across different hardware types.
- **Reimagined serving infrastructure**
- Uses multi-card GPU systems to overcome the memory limits of individual devices.
- Supports models with roughly one trillion parameters.
## Request-Oriented Computation
- Traditional ranking processes each user-ad pair independently, duplicating expensive user-side computations.
- Request-Oriented Optimization computes dense user signals once per request and reuses them across all candidate ads.
- Request-Oriented Computation Sharing and In-Kernel Broadcast distribute shared embeddings directly within GPU kernels.
- These techniques change scaling behavior from linear toward sub-linear while reducing memory-bandwidth pressure.
- Long user behavior sequences can also be processed once per request and reused across candidates.
- A centralized key-value store avoids duplicating user logs and joins them with training data when needed, reducing storage and serving costs.
## Wukong Turbo Architecture
- Wukong Turbo builds on Meta’s Wukong architecture, which combines:
- Stackable factorization machines
- Sequence learning
- Cross-layer attention
- A **No-Bias** design removes unstable terms, improving throughput without increasing parameter counts or FLOPs.
- Small parameter delegation moves selected parameters from Fully Sharded Data Parallel (FSDP) to Distributed Data Parallel (DDP), reducing network and memory overhead.
- Sparsity-based simplification removes redundant linear-layer components.
- Together, these changes improve numerical stability and throughput while preserving the sub-second inference target.
## Holistic Latency Optimization
- The system also targets feature preprocessing, which can create client-memory pressure and leave GPUs waiting for data.
- The article indicates that Adaptive Ranking Model addresses this bottleneck through end-to-end latency optimization and GPU-based preprocessing, though the provided text ends before detailing the implementation.
Adaptive Ranking Model demonstrates that LLM-scale recommendation intelligence can be practical in real-time advertising when model architecture, request execution, hardware, and serving infrastructure are designed together. Its central recommendation is to avoid one-size-fits-all inference and instead allocate computation dynamically according to each request’s value and complexity.
The post describes how Tyler McGoffin used GitHub Copilot to automate the intellectual work of analyzing coding-agent evaluation trajectories. This led to `eval-agents`, a tool designed to let researchers create, share, and run specialized agents. By making coding agents the primary contributors, the team rapidly added 11 agents, four skills, and workflow support while learning new approaches to prompting, architecture, and collaboration.
## The Motivation: Automating Evaluation Analysis
- McGoffin analyzes coding-agent performance using benchmarks such as TerminalBench2 and SWEBench-Pro.
- Each benchmark task produces a trajectory: a large JSON record of the agent’s thoughts and actions.
- Reviewing hundreds or thousands of trajectories can involve hundreds of thousands of lines of data.
- Copilot initially helped identify patterns, reducing the amount of material requiring manual inspection from hundreds of thousands of lines to a few hundred.
- The repetitive nature of this process inspired `eval-agents`, which automates parts of the analysis itself.
## Project Goals
The project was designed around three objectives:
- Make agents easy for others to share and use.
- Make authoring new agents straightforward.
- Make coding agents the primary mechanism for contributing to the project.
The third goal had the greatest architectural impact. Using Copilot to build the tool also made the repository easier for teammates to understand, extend, and collaborate on.
## An Agent-First Development Setup
McGoffin’s development environment consisted of:
- Copilot CLI as the coding agent.
- Claude Opus 4.6 as the model.
- VS Code as the IDE.
- The Copilot SDK for creating agents, registering tools and skills, and accessing existing MCP servers.
This setup allowed the project to reuse Copilot’s existing agent infrastructure instead of implementing those capabilities from scratch.
## Prompting Strategies
- Agents perform best when treated like capable engineers rather than simple code generators.
- Effective prompts are conversational, detailed, and explicit about assumptions.
- Planning mode should be used before implementation mode, especially for complex tasks.
- McGoffin used stream-of-consciousness descriptions to explain problems and collaborate with Copilot on possible solutions.
- For example, a discussion about preventing agents from weakening regression tests led to protected test areas and human-controlled contract-test-like guardrails.
- The broader lesson is that agents benefit from many of the same practices as human engineers: context, dialogue, planning, and clear constraints.
## Architectural Strategies
An agent-first codebase makes maintainability work especially valuable:
- Refactoring names and file structures improves the repository’s understandability.
- Documentation gives agents the context needed to implement features consistently.
- Additional tests expose and prevent recurring mistakes.
- Removing dead code helps keep agents from copying outdated or irrelevant patterns.
- Work that was traditionally postponed—cleanup, documentation, and test improvements—becomes foundational when agents are responsible for much of the implementation.
## Rapid Team Collaboration
Applying these principles enabled substantial development in a short period:
- Five people contributed to the project for the first time.
- The team created 11 agents and four skills.
- They introduced eval-agent workflows for structured streams of scientific reasoning.
- In under three days, the changes amounted to approximately 28,858 added and 2,884 removed lines across 345 files.
## Practical Recommendation
Teams adopting agent-driven development should invest first in clear architecture, documentation, tests, and conversational planning practices. Agents become substantially more effective when the repository provides strong context and guardrails, allowing developers to focus less on repetitive implementation and more on directing, reviewing, and improving the overall system.
Programmable Flow Protection lets Magic Transit Enterprise customers define custom DDoS mitigation logic for proprietary UDP protocols. Customers write eBPF programs that identify valid and malicious packets, then deploy them across Cloudflare’s global network to pass, drop, or challenge traffic. Currently in beta for an additional cost, the system addresses the limitations of generic blocking and rate limiting.
## Custom Protection for Proprietary UDP
- Existing Cloudflare protections understand established protocols such as TCP, DNS, NTP, RDP, and SIP.
- Proprietary UDP protocols are harder to protect because Cloudflare cannot interpret their application-level payloads.
- Customers can now define what constitutes “good” and “bad” traffic using their own protocol knowledge.
- Programs can drop or challenge invalid packets before they reach the customer’s origin.
## Why Generic UDP Mitigation Falls Short
- UDP is connectionless and optimized for speed, making it useful for gaming, VoIP, and streaming.
- When traffic does not match a known protocol, mitigation typically falls back to:
- Blocking a destination IP and port
- Applying a generic rate limit
- These approaches cannot distinguish legitimate packets from attack traffic, potentially causing lag or connection loss for real users.
- Fixed rate limits may also be inappropriate:
- A network expecting 1 Gbps may need stricter limits.
- A network expecting 25 Gbps may require more permissive thresholds.
## How Programmable Flow Protection Works
- Customers upload custom eBPF programs that run on every packet destined for their network.
- Programs execute in userspace rather than kernel space, providing isolation and flexibility across different customers and use cases.
- Execution occurs after Cloudflare’s existing DDoS protections, preserving baseline security coverage.
- Like kernel-based XDP eBPF programs, these programs:
- Compile to BPF bytecode
- Pass safety and termination verification
- Run inside a lightweight, isolated virtual machine
- Cloudflare provides specialized helpers for:
- Maintaining client state between packet executions
- Performing cryptographic validation
- Sending challenge packets to clients
## Example: Protecting a Proprietary Game Protocol
- A gaming provider running on UDP port 207 could inspect its proprietary application header.
- If the header contains a protocol-specific token, the customer’s eBPF program can:
- Parse the packet
- Extract part of the token, such as its final byte
- Pass packets with the expected value
- Drop packets that fail validation
- This allows legitimate players’ traffic through even when attacks use randomized source addresses, ports, and payloads.
Programmable Flow Protection is best suited to Magic Transit customers whose custom UDP protocols cannot be protected effectively by standard protocol-aware controls. By combining customer-specific packet logic with Cloudflare’s global network and stateful challenge mechanisms, it enables more precise mitigation than blanket blocking or generic rate limiting.
