React

63 posts

figma3 min readCurated summary

How To Move Fast Toward the Right Thing | Figma Blog

AI has made software execution dramatically faster, but it has not made judgment easier. The article argues that teams must deliberately decide what is worth building, provide agents with strong context and constraints, and preserve a distinct human point of view. Otherwise, polished prototypes can create hidden tech debt and increasingly average products. ## AI Accelerates Execution, Not Clarity - AI can quickly produce polished, production-like outputs, but apparent polish may hide weak decisions and fragile implementation. - Large language models often fill in missing requirements themselves, causing prototypes to fail under real-world constraints. - **Cognitive surrender** describes accepting AI-generated decisions without scrutiny or independent deliberation. - Teams should follow a “consideration imperative”: pause to understand the problem and define the right outcome before accepting the first plausible solution. ## Context Has to Come First - Agentic engineering shifts developers from manually writing every line of code to expressing intent clearly and directing AI. - Effective intent requires: - **Deterministic layers**, such as tests, type checks, and validation, to catch model errors consistently. - **High-signal context**, including specifications and documented components. - **Clear interfaces**, so agents understand how systems and components connect. - Tools such as Figma MCP’s Code Connect can provide agents with real production components, including props and variants, rather than forcing them to infer implementation from pixels. - Investing in design systems and documented decisions gives agents a precise vocabulary and guardrails, producing more consistent output, leaner code, and less technical debt. ## Good Can Still Be Average - AI tends to generate work that resembles common patterns in its training data, or work that is “in distribution.” - Typical AI-generated results—geometric gradient logos, familiar presentation fonts, or rounded-corner cards—are competent but interchangeable. - When teams repeatedly accept adequate results, their judgment can narrow from asking “What should this be?” to choosing “Which option is least wrong?” - As AI raises the baseline of acceptable work, products can become unremarkable unless people deliberately define what makes them distinctive. ## The Point of View Needs to Be Yours - AI can improve execution, but it cannot replace a team’s responsibility to establish intent, standards, and a meaningful perspective. - Without a clear point of view, the model’s default assumptions determine both what gets built and how it looks. - Moving quickly is valuable only when speed is paired with careful consideration, strong context, and deliberate choices. Teams should treat AI as an execution partner—not as the source of product judgment. Define the problem, encode decisions in systems and safeguards, and challenge generic outputs before shipping.

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

The Monorepo Hope Edition: One Year to Bring a Despairing Repo Back to Hope

Toss argues that a monorepo alone does not guarantee a consistent or efficient frontend development experience. The real problem was dependency-version fragmentation across services, which made installations slow, platform changes risky, and upgrades difficult. Toss addressed this by introducing shared dependency “catalogs,” standardizing core libraries while preserving controlled, gradual upgrades. ## Toss’s Frontend Development Environment - More than 100 frontend engineers maintain products inside and outside the Toss app. - Despite the large number of products, services use nearly identical versions of React 19, Next.js 15, TypeScript, bundlers, and linters. - A shared monorepo makes it easier to: - Maintain a consistent development environment. - Share code across services. - Propagate platform-wide changes. - Give users access to features such as React Concurrent Mode and Server Components. ## Problems with an Unmanaged Monorepo - Services used widely different dependency versions, including outdated React and supporting libraries. - This created fragmented developer experiences: - Some services had fast development servers and modern APIs. - Older services were slower and harder to develop. - Dependency installation could take more than a minute even with caching. - Platform teams struggled to test shared libraries across many React and library versions. - Service developers avoided upgrades because compatibility risks and migration costs were high. - Older services consequently became locked into outdated dependencies. ## Why Toss Rejected a Polyrepo Strategy - Splitting the monorepo into separate repositories could reduce the size of each individual project and improve installation times. - However, polyrepos would not solve the main issues: - Development environments would remain fragmented. - Shared-code development and updates would become more expensive. - Differences between services could become even more pronounced. - Toss concluded that improving dependency management within the monorepo was preferable to abandoning it. ## Simplifying the Dependency Tree - The central issue was that services selected different versions of the same core libraries. - Toss identified roughly 10–20 commonly used libraries, including: - React - Component libraries such as TDS - Jotai - TypeScript - ESLint - Standardizing these dependencies could: - Reduce installation time. - Provide a consistent developer experience. - Make platform-library testing more predictable. - Enable automated migration scripts and compatibility layers. - Lower the cost of adopting breaking changes. - In practice, developers usually chose libraries rather than requiring specific versions, making centralized versions practical. ## Dependency Catalogs - Toss defined recommended versions as a shared **Catalog** using pnpm or Yarn workspace configuration. - Services reference catalog-managed dependencies with the `catalog:` protocol instead of specifying independent versions. - Named catalogs can support different release channels, such as: - `stable` - `beta` - Toss initially included essential dependencies such as React, Next.js, TypeScript, TDS, and the Toss App SDK. - Catalog packages had to be tested in representative service environments before release. - New services automatically referenced the latest catalog. - CI detected cases where developers accidentally bypassed catalog versions. - Existing services were migrated collaboratively with their code owners. - Catalog changes were released as new versions and rolled out gradually rather than modifying a shared version in place. - Upgrade scripts and AI Skills reduced the effort required to migrate services. ## Results After Full Adoption - Dependency duplication fell substantially: - `.pnp.cjs` shrank from 96 MB to 15 MB, an approximately 84% reduction. - Development-server startup improved from 26.7 to 20.3 seconds, about 23% faster. - Full dependency installation decreased from 528.4 to 249.9 seconds, about 52% faster. - Developers gained greater confidence that catalog packages had already been tested in real services. - Centralized version control reduced incompatible transitive dependencies, such as one package requiring version 1 while a service used version 2. - Better dependency visibility made large architectural improvements safer, including work involving RSC, TypeScript 7, Rspack, and end-to-end testing. - Services could adopt improved platform packages more consistently and with less upgrade friction. The practical recommendation is to retain the monorepo, but enforce a curated set of shared dependency versions through catalogs, CI checks, staged releases, and automated migration tooling. This combines the sharing benefits of a monorepo with a more predictable and maintainable development environment.

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

Better Code, Fewer Tokens: The Benefits of Code Connect in MCP | Figma Blog

Code Connect improves how coding agents translate Figma designs into production code by supplying real design-system components, imports, and prop values. Figma’s evaluations found that Code Connect reduced median task duration by 19.6%, lowered token usage by 29.5%, and increased code quality by one point on a 1–4 scale. The central conclusion is that better design-to-code context helps agents work faster while producing code that fits existing codebases. ## The Problem: Visually Correct but Technically Wrong Code - Without production context, agents often: - Rebuild interfaces from basic primitives. - Invent components that already exist. - Choose the wrong design-system component. - Spend extra tokens searching, debugging, and rewriting. - Figma’s MCP server normally provides a React representation of the design through `get_design_context`. - This output may match the visual design but does not explain how the design maps to a company’s actual component library. ## How Code Connect Enriches MCP Responses - Code Connect links Figma components to their real implementations in a codebase. - With Code Connect templates configured, MCP responses replace generic React markup with production-relevant snippets. - Agents receive: - Correct component imports. - Accurate component names. - Appropriate property values. - Code that reflects the company’s design system. - For example, generic markup for a tab control can be replaced with an existing component such as: ```tsx <SegmentedControl value="design" options={["Design", "Code"]} /> ``` ## Coinbase Case Study - Coinbase’s Design Systems team adopted Code Connect as engineers increasingly used coding agents. - Without Code Connect, agents sometimes fabricated alternatives, such as constructing a stepper from progress bars. - With Code Connect, agents received literal imports and accurate code representations for Coinbase Design System components. - Coinbase reported improved output quality and reduced token usage. ## Evaluation Results - Figma created an evaluation harness that ran identical design-to-code tasks: - Once without Code Connect. - Once with Code Connect templates. - The evaluation covered 27 test cases. - It measured: - Code quality. - Token consumption. - Task duration. - The tests used two React-based design systems: - Simple Design System (SDS), Figma’s example system. - Figma Pattern Library (FPL), a larger internal system. - Across the tests, Code Connect produced: - **19.6% lower median task duration** - **29.5% lower median token usage** - **A one-point increase in code quality on a 1–4 Likert scale** Teams using coding agents for design-to-code work should connect their Figma components to production implementations through Code Connect. Providing exact component context reduces guesswork and tokens while helping agents produce maintainable, design-system-compliant code.

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

Stacked sessions and pull requests in the GitHub Copilot app

GitHub Copilot’s stacked sessions let developers split large, dependent changes into smaller pull requests while preserving their order. Cassidy Williams demonstrates this by modernizing a decade-old React application, recovering from an incorrect branch choice, and then starting a separate `react-bootstrap` replacement on top of the styling work. The approach made a difficult modernization more manageable and reduced the temptation to create an unwieldy “everything” pull request. ## Modernizing a Legacy Application - Williams’ personal dashboard had accumulated outdated dependencies and patterns: - React 15 - Less - An old version of `react-bootstrap` - Updating the application manually had previously seemed too time-consuming. - She used the GitHub Copilot app to plan a frontend modernization focused on: - Replacing Less with Tailwind or vanilla CSS - Improving accessibility and responsiveness - Modernizing dependencies - Cleaning up links, inputs, labels, wrapping, and container widths - Claude Opus 4.8 helped formulate the plan, while GPT-5.5 provided a review. - The initial attempt failed because the work began from the wrong branch. ## Recovering from the Wrong Branch - Williams discovered that an old `dev` branch already contained partial modernization work and was the version she actively used. - The new session had incorrectly branched from `main`, creating compatibility problems. - Rather than discard the work, she asked Copilot to: - Close the incorrect pull request - Start a fresh session from `dev` - Port the styling and accessibility changes onto that branch - Copilot handled the branch and pull request transition, preserving useful decisions from the failed attempt. ## Investigating Legacy Warnings - Testing exposed warnings involving: - `findDOMNode` - `componentWillReceiveProps` - The outdated code was largely coming from `react-bootstrap`, not Williams’ own application code. - She used Plan mode to compare upgrading or migrating existing components with removing the library. - Copilot recommended replacing `react-bootstrap` entirely. ## Stacking Dependent Sessions - Replacing `react-bootstrap` represented substantial scope beyond the current styling work. - Williams chose to submit the existing work first, then create a second session branched from it. - The new session would: - Build on the completed styling changes - Replace `react-bootstrap` - Produce a separate pull request - Eventually merge into `dev` after the first pull request - This structure keeps each change easier to review and test while maintaining the dependency between them. The practical recommendation is to use stacked sessions for large, related modernization efforts: isolate coherent tasks into separate pull requests, branch later work from earlier changes, and avoid allowing AI-assisted development to turn every improvement into one oversized change.

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

Building a Group Video Calling Service Inside a LINE App with AI, Without a Web Engineer

LINE’s LIFF enables web services to run directly inside the LINE app, turning a LINE Official Account into an interactive service platform rather than merely a notification channel. The LINE Planet team demonstrated this by building a group video-calling service with only a PM and an Android engineer, without a web engineer. The core architecture combines a LIFF web app, a small token-issuing app server, and LINE’s managed authentication and WebRTC infrastructure. ## Services Enabled by LINE OA and LIFF - **Professional consultations:** One-to-one video sessions with lawyers, financial planners, counselors, and other experts. - **Remote education:** Scheduled video lessons with separate rooms for multiple teachers and students, including screen sharing. - **Interactive live broadcasts:** Events for 500 to 10,000 simultaneous participants, including audience members joining conversations as panelists. - **In-game voice chat:** Real-time communication with LINE friends without switching to another app. ## Overall Architecture - **LIFF** provides the in-app web interface and automatically exposes LINE login information such as `userId` and `displayName`. - **LINE Planet** handles WebRTC media processing and global network infrastructure. - **The web app** uses the LINE Planet SDK to implement the group call experience. - **The app server** issues LINE Planet access tokens. - Firebase Cloud Functions can provide the app-server layer without managing separate server infrastructure. - The developers are responsible mainly for connecting these components; LINE handles authentication, media transport, and much of the underlying infrastructure. ## Required Preparation - Use Node.js 20 LTS or later with npm. - Deploy over HTTPS; local development can use ngrok. - Create a Business ID, developer account, and Provider in the LINE Developers Console. - Create a LINE Official Account and enable its Messaging API. - Create a LINE Login channel under the same Provider and register a LIFF app. - Record the LIFF ID because it is required for initialization. - Set the LINE Login channel to **Published** for the `shareTargetPicker` API, which supports inviting LINE friends. - Request a LINE Planet Console account and service ID from the LINE Planet team. ## Designing and Generating Room IDs - LIFF can collect call setup information and register it with the app server, reducing the amount of pre-call configuration. - Users can join simply by entering or following a room ID. - The example generates a random 16-character alphanumeric ID using `crypto.randomUUID()`. - If a `roomId` query parameter exists in an invitation link, the app restores and uses that room instead. - The same design can later support fixed rooms based on interests or automatically generated rooms for user groups. ## Building the Preview Screen - The preview screen lets users check their camera and microphone before entering a call. - Instead of directly calling `getUserMedia`, the example uses PlanetKit’s `MediaStreamManager`. - A single `MediaStreamManager` instance is reused from preview through the conference, avoiding repeated permission requests. - Camera input is created with `createMediaStream()` or replaced with `changeVideoInputDevice()`. - Microphone muting changes the audio track’s `enabled` flag, preventing another permission prompt in mobile webviews. - Mobile users can switch between front and rear cameras by resolving the appropriate device ID. - The sample UI includes camera and microphone toggles, camera-flip controls for mobile devices, and an “Enter” action. - The article notes that the sample focuses on the essential flow; production applications still need stronger security, error handling, and performance optimization. The practical recommendation is to treat LIFF and LINE Planet as managed building blocks: implement the web call interface and a minimal token server, while relying on LINE for user identity and PlanetKit for real-time media.

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

Building Accessibility Into a Canvas-Based Product | Figma Blog

Figma’s canvas-based rendering enables performance features such as infinite zoom and real-time collaboration, but it removes the browser’s built-in accessibility support. To restore that support, Figma built a synchronized “Mirror DOM” that represents the canvas in ordinary DOM elements for screen readers and keyboard users. The system combines an internal accessibility tree, React-rendered mirror elements, bidirectional selection syncing, and announcements for non-navigational changes. ## Why Canvas Requires a Different Accessibility Strategy - Figma renders designs on a canvas rather than with traditional HTML and DOM. - This improves performance but leaves the browser’s accessibility tree nearly empty. - Unlike a conventional web app with semantic elements such as `<button>`, `<p>`, and `<img>`, Figma’s canvas effectively has only one focus-holding `<input>`. - Without additional work, screen readers cannot navigate or meaningfully interpret the layers in a Figma file. ## Synthesizing an Accessibility Tree - Browsers normally derive an accessibility tree from the DOM, semantic HTML, ARIA attributes, and computed state. - Figma created its own internal accessibility tree to provide equivalent non-visual information for each design layer. - Each layer receives an accessible summary describing the role and content a screen reader should announce. - Summaries vary according to context: - In prototypes, editing-related layers can be omitted, while text and interactive roles are preserved for viewers. - In editing mode, structures such as autolayout frames need to remain available. - The tree is flattened by removing omitted nodes and connecting their relevant descendants. - Figma builds the tree initially, then applies surgical updates as documents change instead of rebuilding everything. ## Rendering the Mirror DOM - A recursive React component converts the internal accessibility tree into DOM elements. - Each component subscribes to accessibility data for one design layer and renders its role, label, and children. - React’s incremental updates help keep DOM changes minimal as the design changes. - The resulting elements are invisible to sighted users but available to assistive technologies. ## Synchronizing Canvas and Screen Reader Interaction - Figma maintains bidirectional synchronization between the visual canvas and the Mirror DOM. - Selecting a layer on the canvas moves focus to the corresponding DOM element. - When a screen reader user navigates the Mirror DOM, Figma updates the canvas selection accordingly. - This connects non-visual navigation with the editor’s visual state. ## Announcing Changes - A separate announcement system communicates changes that are not primarily navigational. - It reports actions such as nudging objects, switching tools, and other updates that would normally be apparent visually. - Together with the Mirror DOM, these announcements help screen reader users understand both the document structure and ongoing editor activity. Figma’s approach shows that accessibility can be rebuilt for canvas applications by maintaining a semantic representation alongside the rendering layer. Applications that prioritize canvas performance should provide a synchronized accessibility model rather than relying on the canvas itself to expose meaning to assistive technologies.

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

Start Anywhere, a Magazine by Figma | Figma Blog

Figma’s 2026 *Start Anywhere* magazine explores how new tools are expanding the ways people begin and develop creative work. Its central argument is that as motion, code, and AI become more integrated into the design canvas, creative workflows are converging and becoming more expressive. Rather than prescribing one starting point, Figma encourages designers of all experience levels to choose an entry point and keep exploring. ## A Magazine About Design’s Changing Landscape - The magazine was created for Config 2026 by No Ideas, featuring work by several artists and designers. - Figma’s annual publication aims to capture what matters in design beyond rapidly changing product releases. - This year’s theme reflects the difficulty—and freedom—of writing about tools that evolve quickly. - The enduring principles are curiosity, patience, and understanding what something is before focusing on what it does. ## More Materials on the Canvas - Figma Motion introduces a timeline directly into the canvas, allowing designers to work with movement alongside components, variables, and collaborators. - Motion design principles remain important even as tools become easier to use: - Timing and mechanics give movement meaning. - Foundational craft helps designers make better creative decisions. - Code is also moving into Figma’s shared multiplayer environment. - Code layers allow teams to explore design and implementation side by side, making code a more direct part of the design process. ## The Design-to-Code Loop - As work moves fluidly between code and canvas, design and development workflows increasingly converge. - The magazine examines how this connected process can: - Enable faster experimentation. - Support multiple directions in parallel. - Improve collaboration between designers, engineers, and AI-focused teams. - Carry ideas more smoothly from early exploration into production. ## AI as a New Path from Idea to Product - AI tools are changing where product work begins and how ideas move through the development process. - The magazine presents examples from four organizations using AI in different ways. - These approaches suggest that AI can influence: - Ideation and initial exploration. - Product design and iteration. - The transition from design concepts to working software. - The continuity of ideas through production. ## Imagining Future Human–Computer Interaction - The “Future states” section asks what it might mean to reduce the gap between human and machine intelligence. - Contributors imagine software that interacts in more human-centered ways, including: - Interfaces that respond to users’ emotions. - Systems that help people anticipate the consequences of decisions. - New forms of interaction beyond traditional interfaces. ## Who the Magazine Is For - The publication addresses: - Beginners with ideas but no clear starting point. - Experienced practitioners looking for new creative possibilities. - Anyone who wants to produce effective design efficiently. - Its three covers represent different prompts and entry points into the same broader questions. The practical message is to start wherever the most interesting possibility appears—whether in design, motion, code, or AI—and continue iterating. The tools may change quickly, but curiosity and strong creative fundamentals remain useful across every workflow.

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

From Prompting to Workflows: Boosting Frontend Development Productivity with AI

Frontend development is increasingly shifting from a coding problem to an orchestration problem. Requirements, designs, documentation, discussions, and existing code are scattered across tools, while LLMs can now connect these sources through repeatable workflows. The article argues that structured, reviewable workflows—rather than clever one-off prompts—are the key to scaling AI-assisted development and improving implementation quality. ## From Prompting to Repeatable Workflows - A prompt may produce a useful result once, but it does not create a reusable process. - A workflow defines a repeatable path from inputs to outputs: - Collect context from Jira, Confluence, Slack, and the codebase. - Summarize the actual requirements. - Identify ambiguities and unresolved decisions. - Propose an implementation plan. - Wait for human review before modifying code. - The LLM acts as the engine executing the workflow. - LY Corporation’s Noah MCP connects systems such as Jira, Confluence, Slack, and GitHub, allowing AI agents to access real organizational context instead of relying on manually copied prompts. - Once established, the same workflow pattern can be applied across many tickets, even when the specific inputs differ. ## Example: Planning a List Page The example Jira ticket requests a list page with search, filtering, sorting, and role-based filter visibility. - In the traditional process, a developer manually: - Reads the Jira ticket and identifies missing details. - Searches Figma for loading, empty, and no-results states. - Finds role-based filter rules in Confluence. - Searches Slack for prior decisions. - Inspects the codebase for reusable hooks and components. - Copies findings into notes and assembles an implementation plan. - Implements the feature, resolves bugs and edge cases, and submits a PR. - An AI workflow performs these steps systematically before coding. - The generated plan identifies: - A new `FeatureListPage` route and `FeatureList` component. - Reuse of `useTableFilters` and `useUrlState`. - Existing API support through `GET /api/<feature>`. - URL synchronization for filters, sorting, and pagination. - Role-based visibility using `useCurrentUserRole()`. - Required loading, empty, and no-results states. ## Surfacing Hidden Requirements The workflow improves quality by exposing information that might otherwise appear late in development. - A Slack decision establishes that filter and sort state should use URL parameters rather than `localStorage`, enabling shareable and reloadable views. - Existing hooks such as `useTableFilters` and `useUrlState` are discovered before new code is written, preventing unnecessary duplication. - Unresolved questions are explicitly listed for human review, including: - Whether filter and sort state belongs in URL parameters or `localStorage`. - Which empty-state design should be used when Figma contains multiple variants. - Resolving these questions early reduces rework during implementation or PR review. ## Closed-Loop Verification The workflow should continue after coding rather than stopping when the first implementation is complete. - The agent compares the implementation with the original plan. - It runs: - Type checks. - Linting. - Related unit tests. - Relevant smoke tests or local verification flows. - It reports: - Successful checks. - Failures that were fixed. - Items that could not be verified automatically. - UI screenshots or state notes. - Remaining risks before opening a PR. - This creates a closed-loop development cycle in which AI not only writes code but also validates its work against the intended requirements. Teams should treat AI as a workflow and context-orchestration layer, not merely a code generator. The most effective process gathers information across systems, obtains human approval for the plan, implements with existing project patterns, and automatically verifies the result before review.

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

Config 2026: New Materials, New Tools and a More Expressive Canvas | Figma Blog

Figma’s Config 2026 focuses on making the canvas a more expressive, collaborative environment where code, motion, shaders, generative plugins, and Weave tools work alongside traditional design layers. The company argues that code is a design material rather than a separate discipline, and that AI should support—rather than replace—human creativity. New features aim to let teams explore ideas faster while keeping design, implementation, and collaboration connected. ## Code Layers on the Canvas - Figma is introducing code layers, allowing any design layer to become an interactive code layer with one click or a prompt. - Teams can duplicate code layers and explore multiple directions side by side, just as they would with design frames. - Code layers support collaborative workflows including riffing, commenting, and iteration within the same Figma file. - Designers can extract code-generated designs back into editable design layers. - When changes are made to the design, a single click updates the corresponding code layer. - Early access is expected to begin in July 2026 through the Figma beta waitlist. ## Motion as a Core Design Material - Figma Motion brings animation directly into Figma Design, reducing the need to move between separate tools. - Its timeline includes keyframes, presets, and other controls for creating motion from scratch or adding animation to existing designs. - The Figma agent can generate an initial motion concept for designers to refine. - Motion can become part of a design system: an animation applied to a component can carry across screens and collaborators’ files. - In Dev Mode, developers can inspect the complete timeline, including timing values, easing curves, and keyframes. - Animation can be copied as CSS, JSON, or React-ready code. - Motion is MCP-compatible, allowing animated frames to be passed directly to coding agents. - Export formats include MP4, WebM, Animated SVG, and GIF, with additional formats planned. ## A More Unbounded Canvas - Figma describes the canvas as more than a place to store work: it is intended to connect ideas, tools, collaborators, and implementation. - The company’s broader Config strategy is to provide composable materials that let users experiment at the speed of their thinking. - Upcoming capabilities include shader fills and effects, generative plugins, Figma Weave tools, and expanded Figma agent functionality. - Figma argues that AI has lowered the barrier to creating, but people—not AI—will raise the creative ceiling through experimentation and bold expression. Figma’s direction is to unify design and development in one collaborative workspace. Designers and developers should use the new materials selectively: code layers for interactive exploration, Motion for reusable animation systems, and the canvas as a shared environment for rapid iteration from concept through implementation.

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

Code on the Figma Canvas | Figma Blog

Figma is introducing code layers, making interactive code a collaborative object directly on the Figma canvas. Teams can generate, import, compare, edit, and convert code and designs in both directions, bringing designers and developers into one shared workflow. The feature aims to make experimentation and design-to-code iteration more visual, collaborative, and accessible. ## Creating and Sharing Code on the Canvas - Users can add a code layer from Figma Design, convert an existing frame into code, or ask the Figma agent to generate an implementation. - Projects can begin from templates, natural-language prompts, imported GitHub repositories, or uploaded local folders. - Code generated in Figma Make can be brought into Figma Design as a code layer. - Interactive code becomes part of the shared file, allowing teammates to inspect, comment on, and refine it together. ## Exploring Multiple Alternatives - Code layers work like duplicated design frames, allowing teams to explore several working alternatives side by side. - Designers can move, resize, and adjust elements while seeing the corresponding code update immediately. - Prompts can generate new versions while preserving the original. - Teammates can collaborate on the same code layer through comments and additional prompts. ## Moving Between Code and Design - The **Extract designs** feature converts a code layer’s current state into editable Figma layers. - Teams can extract a single screen, a particular state, or an entire user flow. - Design edits can then be applied back to the code layer, enabling fluid movement between visual design and implementation. ## Editing and Shipping Code - Users can open the code editor, annotate desired changes, ask the agent to implement them, or edit the code manually. - Once approved, the updated implementation can be converted back into a code layer and pushed to the project repository. - The resulting changes remain visible to the wider team on the Figma canvas. ## Availability - Code layers are rolling out in closed beta over the following weeks. - Interested users can request early access through Figma’s Config beta sign-up. Figma’s code layers are intended to make the canvas a shared space for designing, testing, and refining real interfaces. Teams interested in combining visual collaboration with AI-assisted development can request beta access and evaluate the workflow against their existing design and repository processes.

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

7 Tips for Using Figma Make Credits More Efficiently | Figma Blog

Figma argues that efficient AI prototyping is less about writing longer prompts and more about setting up projects carefully, limiting changes, and knowing when to edit manually. The first prompt should establish a strong foundation, while follow-ups should describe precise deltas. For minor visual or code changes, direct editing is often faster and cheaper than another AI request. ## Build a Strong First Prompt - Treat the initial prompt as a complete project brief. - Include: - The project goal and context - Key elements and behaviors - Constraints and exclusions - A clear definition of what “done” means - Use follow-up prompts as deltas that explain: - What should change - How it should change - What should remain unchanged - For larger projects, work in stages: - Establish the structure first - Add logic and behaviors - Refine content and visual polish afterward - Keep follow-ups tightly scoped. Combine requests only when they affect the same component or logic. - Specific instructions such as “Update the calendar component” or “Edit `tokens.ts`” are more efficient than vague requests like “Redo it.” ## Prefer Manual Edits for Small Changes - Use Figma Make’s **Edit tool** for minor adjustments such as: - Changing spacing - Removing an element - Adjusting text - Direct edits avoid spending credits on changes that do not require a new design solution. - Use **Go to source** when the relevant value is dynamic or unavailable in the preview. - Press **⌘F** to search the code for a specific tag or data source. - Start with `App.tsx`, then inspect other `.tsx` files in the component folder if necessary. - Direct source editing is particularly useful for repeated components or content populated from lists.

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

What the Design-to-Code Loop Unlocks | Figma Blog

AI is bringing design and engineering into a more continuous, bidirectional workflow. Instead of treating code as an expensive final step, teams can use functional prototypes, editable designs, and AI assistance to explore behavior and visuals together. The result is broader participation, faster learning, and a shift from mechanical translation between design and code toward more semantic collaboration. ## AI Makes Code Part of Design Exploration - Code was traditionally costly and difficult to revise, while design allowed cheap, broad exploration. - AI reverses that relationship by making functional wireframes easier to create and iterate. - Designers can explore interaction and behavior—not just static layouts—then move work between code and canvas. - AI can translate between the two mediums in a way that preserves intent and structure rather than simply converting files or syntax. ## A More Bidirectional Collaboration Model - Code-based workflows tend to move in one direction and are often constrained by the patterns already present in a codebase. - Figma’s canvas gives teams space to reconsider assumptions and explore radically different directions. - Designers and developers can work from the same evolving artifact instead of repeatedly handing work off. - AI lowers participation barriers: people without access to an internal design system can import a live product into Figma as editable frames and begin contributing. ## Lower Learning Curves for Designers and Developers - AI turns steep technical learning curves into gradual ramps by providing a capable starting point. - People can learn frameworks, routes, React, and other concepts in the context of real work rather than abstract exercises. - Designers can extend beyond previous technical limits into areas such as shaders, 3D, and custom tools. - Deeper specialization remains possible, but the initial investment is much smaller and learning becomes more contextual. ## Curiosity as the New Differentiator - When AI tools become broadly available, access to technology alone is less likely to distinguish practitioners. - Curiosity and taste become more important: people who actively experiment can discover new possibilities. - AI functions as a patient tutor, reducing the friction of learning tools, frameworks, syntax, and development environments. - Staying effective requires continually exploring what can be built rather than relying only on existing technical expertise. The design-to-code loop is therefore less about replacing designers or developers and more about making experimentation and collaboration accessible across disciplines. Teams should treat AI as both a creative medium and a learning partner, moving freely between canvas and code while preserving room to question the initial direction.

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

Agents that remember: introducing Agent Memory

Cloudflare’s Agent Memory is a managed, retrieval-based service designed to give AI agents persistent memory without continuously expanding their context windows. It addresses context rot by extracting useful information from conversations, retaining it across sessions, and retrieving synthesized answers when needed. The service is intended for production agents that run for weeks or months, where fast ingestion, affordable retrieval, and durable knowledge matter more than benchmark performance alone. ## The Challenge of Agent Memory - Larger context windows—even beyond 1 million tokens—do not eliminate context rot; excessive context can reduce model quality. - Aggressive pruning creates the opposite risk: removing information the agent may need later. - Existing memory systems vary widely: - Managed services versus self-hosted frameworks - Raw database or filesystem access versus purpose-built APIs - Full-context approaches versus retrieval-based systems - Benchmarks such as LongMemEval, LoCoMo, and BEAM help compare systems but may encourage overfitting to clean datasets that do not reflect long-running production workloads. ## Cloudflare’s Retrieval-Based Approach - Agent Memory is a managed service with an opinionated API. - It extracts and retrieves relevant information instead of exposing agents directly to a filesystem or database. - This approach is intended to: - Reduce token usage and cost - Improve retrieval performance - Support temporal reasoning, supersession, and instruction following - Keep memory operations out of the agent’s main reasoning context - Cloudflare expects programmatic querying to be useful for specialized edge cases, but not as the default interaction model. ## Memory Profiles and Core Operations Memory is organized into named profiles that can be shared across sessions, agents, and users. - `ingest`: Processes a conversation and extracts memories, typically during context compaction. - `remember`: Stores one important fact explicitly, often through direct model tool use. - `recall`: Runs the full retrieval pipeline and returns a synthesized response. - `list`: Lists stored memories. - `forget`: Removes a specific memory. For example, an agent can ingest a conversation containing a user’s preference for pnpm and dark mode, explicitly remember an operational fact such as an increased API rate limit, and later recall that the user prefers pnpm over npm. ## Integration and Supported Architectures - Agent Memory is available through a binding in Cloudflare Workers. - Agents running outside Workers can use the REST API. - The Cloudflare Agents SDK integrates it with session compaction, memory creation, and retrieval. - It can support: - Individual coding or personal agents - Self-hosted frameworks and managed agent services - Autonomous background agents that must survive restarts - Custom agent harnesses - Shared knowledge between engineers, agents, and tools - Shared profiles can preserve coding conventions, architectural decisions, and other organizational knowledge that might otherwise be lost during context pruning. ## Practical Recommendation Agent Memory is positioned as a default persistent-memory layer for production agents: use ingestion during compaction, explicit remembering for critical facts, and retrieval when the agent needs historical context. Its private beta is particularly aimed at long-running, multi-session workloads where maintaining useful memory is more important than simply fitting more text into the context window.

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

Build a personal organization command center with GitHub Copilot CLI

Brittany Ellich built a personal organization command center to reduce the friction of switching between numerous apps. Using GitHub Copilot for planning and implementation, she created a working first version in one day. Her experience suggests that AI-assisted development makes it easier to turn everyday frustrations into practical, customized tools. ## The Problem: Digital Fragmentation - Brittany wanted to consolidate information scattered across roughly a dozen applications. - Her goal was a calm, visual workspace suited to her learning style and the way she organizes information. - The project became a personal command center for bringing disparate work and productivity tools together. ## Planning and Building with AI - Brittany uses a “plan-then-implement” workflow. - During planning, Copilot interviews her about requirements and behavior until they form a sufficiently detailed plan. - Copilot then implements the system based on that plan, reducing guesswork and making development smoother. - The first version was completed in a single day alongside her normal work. ## Her Development Workflow - She uses VS Code Agent Mode for synchronous work, generally running up to two non-competing agent workflows. - She uses Copilot Cloud Agent for asynchronous, well-scoped tasks such as bug fixes and technical-debt cleanup. - This division lets her focus personally on work requiring close oversight while agents handle lower-risk background tasks. ## Technology Stack - **Electron** for the cross-platform desktop application. - **React** for the interface, components, and state management. - **Vite** for development tooling and hot module replacement. - **Tailwind CSS** for styling. - **WorkIQ MCP and CLI** for accessing Microsoft 365 data, including calendar information. - The application also uses ElevenLabs for its voice assistant. Although Brittany had wanted to build an Electron app, she learned relatively little about Electron because Agent Mode handled most of the implementation. She later simplified the repository manually to make it suitable for public release, noting that agents tend to add code more readily than remove it. ## Getting Started The project is available as the open-source `command-center-lite` repository. Running it requires Node.js 18 or later, GitHub Copilot CLI for WorkIQ setup, a Microsoft 365 account for calendar synchronization, and an ElevenLabs account for voice features. The broader recommendation is to start building solutions for small, personal problems. AI tools can accelerate both learning and implementation, making experimentation with unfamiliar technologies far more accessible.

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

Add voice to your agent

Cloudflare’s experimental `@cloudflare/voice` package adds real-time voice to existing Agents SDK applications without requiring a separate voice framework. Voice interactions use the same Durable Object, WebSocket connection, tools, and SQLite-backed history as text interactions. The package provides ready-made STT and TTS integrations while keeping provider interfaces open for alternative speech, telephony, and transport systems. ## Voice Support for Existing Agents - `withVoice(Agent)` enables full conversational voice agents. - `withVoiceInput(Agent)` supports speech-to-text-only features such as dictation and voice search. - React applications can use `useVoiceAgent` and `useVoiceInput`. - Framework-independent clients can use `VoiceClient`. - Built-in Workers AI providers include: - Deepgram Flux for continuous speech-to-text - Deepgram Nova 3 for speech-to-text - Deepgram Aura for text-to-speech - Developers can get started without external API keys. ## Minimal Server and Client Setup - A voice agent extends a class created with `withVoice(Agent)`. - The server configures a transcriber and TTS provider, then implements `onTurn()`. - `onTurn()` receives the user’s transcript and returns the agent’s response. - React clients can display: - Connection status - Interim and finalized transcripts - Conversation messages - Start, end, and mute controls - Non-React applications can connect through `@cloudflare/voice/client`. ## How the Voice Pipeline Works - The browser captures 16 kHz mono PCM microphone audio. - Audio streams over the agent’s existing WebSocket connection. - A continuous STT session remains active for the duration of the call. - The speech-to-text model detects completed utterances and produces stable transcripts. - Each transcript is passed to `onTurn()` for application or LLM logic. - The response is synthesized into audio and streamed back to the client. - Streamed responses can be sentence-chunked so audio begins playing before the full response is complete. - User and agent messages are persisted in the Durable Object’s SQLite database, surviving reconnections and deployments. ## Extensible Provider Architecture - The package is designed not to lock developers into one fixed voice stack. - Small provider interfaces allow speech, telephony, and transport providers to build integrations. - Developers can mix and match components based on their application’s requirements. - Voice therefore becomes another interaction mode for the same stateful agent rather than a separate application architecture. Cloudflare’s approach is best suited to developers who already use the Agents SDK and want to add conversational voice while preserving existing state, tools, persistence, and connection patterns. Since the package is experimental, teams should evaluate provider support and API stability before relying on it in production.

Read original(opens in new tab)