Home
May 30, 2026
View All

Figma Make Goes Local, Cursor's Auto-Review, and LangSmith's Self-Healing Agents

The Short Version#

Three things happened this week that are quietly changing how AI tools handle the human-in-the-loop problem: Figma Make connected to local codebases, Cursor shipped a run mode that requires fewer approval prompts, and LangSmith launched an agent that watches your production traces and files its own bug reports. The common thread is that each product is trying to extend the autonomy window without losing user trust.

Figma Make - Visually Edit Your Local Codebase#

Source: https://www.figma.com/join-waitlist-make/ Credibility: High (first-party changelog, dated May 28, 2026)

What happened: Figma Make shipped a significant expansion: you can now connect it directly to your local codebase. From there, you can prompt contextually on specific files or components, and Make applies visual edits that map back to real code. This is a new release that goes well beyond Make's earlier web-only prototyping mode. It's now a desktop-app feature that bridges the gap between Figma's design surface and a live engineering repo.

Key capabilities:

  • Connect Make to a local codebase via the Figma desktop app
  • Prompt on specific files or components in context, not just blank-canvas generation
  • Visual edits that write back to actual code, not just static Figma frames
  • Works within your existing design system and component structure (the earlier Make launch emphasized design system awareness)

Why it matters for PMs: This is the clearest signal yet that Figma is positioning Make as a tool for existing products, not just greenfield prototypes. The "local codebase" connection changes the use case from "spin up a quick mockup" to "propose a real UI change to a real file." That's a fundamentally different product. It means designers and PMs can now propose changes that are already grounded in the actual code, reducing the handoff friction that kills most design-to-dev workflows. It also raises a real question about who this tool is for: the designer who wants to push changes, the PM who wants to prototype a real flow, or the engineer who wants visual feedback on a component. That ambiguity is both an opportunity and a UX challenge Figma will need to resolve.

Critical questions:

  • How does Make handle conflicts when the local codebase has diverged from what's in Figma? Merge conflicts at the visual layer are a new class of problem.
  • Is the local connection read-only for context, or does Make write changes back automatically? The changelog says "visually edit your codebase," which implies write-back, but the trust implications are significant.
  • Who owns the prompt history and edit log? If a designer pushes a change that breaks a component, who's accountable?
  • Does this work with any stack (React, Vue, Swift) or only frameworks Figma explicitly supports?

Action you could take today: If your team uses Figma and ships a web product, join the Make waitlist and specifically ask whether it supports your stack. Then map one specific handoff pain point in your current design-to-dev flow that this could address, so you're ready to pilot it with a concrete use case rather than exploring generally.

Cursor - Auto-Review Run Mode#

Source: https://cursor.com/changelog/auto-review Credibility: High (first-party changelog, dated May 29, 2026)

What happened: Cursor shipped Auto-review, a new run mode designed to let the agent work for longer stretches without requiring manual approval on every tool call. The mode applies specifically to Shell, MCP, and Fetch tool calls. Calls that are on an allowlist run immediately. Calls that can be sandboxed run in a contained environment. Calls that are neither get flagged for human review.

Key technical details:

  • Three-tier execution model: allowlisted (auto-run), sandboxable (auto-run in sandbox), and flagged (requires approval)
  • Applies to Shell, MCP, and Fetch tool calls specifically
  • Designed to reduce interruptions during longer agentic workflows
  • Users configure the allowlist, so trust scope is user-defined, not Cursor-defined

Why it matters for PMs: The hardest UX problem in agentic coding tools isn't capability, it's interrupt frequency. Every approval prompt breaks flow and re-introduces cognitive overhead. Cursor's three-tier model is a real attempt to solve this without going fully autonomous, which would be too risky for most production work. The allowlist approach puts trust decisions in the user's hands and makes the trust model explicit. This is worth watching as a pattern: rather than a single "let it run" toggle, you get graduated autonomy based on call type and sandboxability. That's a smarter design than binary approve/reject.

Critical questions:

  • Who manages the allowlist in enterprise settings? If a team shares a Cursor config, do they share the allowlist, or is it per-user?
  • What happens when a sandboxed call has side effects that weren't anticipated? How does Cursor communicate that to users?
  • Does Auto-review mode change how Cursor logs or explains what it did? More autonomy requires better audit trails.
  • How does this interact with multi-step agentic tasks where an early sandboxed call sets up a later non-sandboxable one?

Action you could take today: If you use Cursor for any scripting or agentic tasks, test Auto-review mode on a low-stakes workflow this week. Pay attention to which calls end up flagged, and whether the three-tier categorization matches your intuition about what should require approval. That gap between your mental model and Cursor's is useful signal for understanding agentic trust design more broadly.

LangSmith - Engine: The Agent That Watches Your Agents#

Source: https://www.langchain.com/blog/introducing-langsmith-engine Credibility: High (first-party LangChain blog, dated May 28, 2026)

What happened: LangSmith shipped Engine, an agent that monitors your production traces, automatically clusters failures into named issues, and proposes targeted fixes and additional eval coverage. It also shipped Mission Control, a separate product for teams running self-hosted LangSmith on Kubernetes, which adds in-cluster config, preflight checks, health views, and diagnostics. These shipped alongside LangSmith Sandboxes going GA (covered in prior updates).

Key capabilities:

  • Watches production traces continuously, not just on-demand
  • Clusters failures into named, groupable issues (not just raw logs)
  • Proposes targeted fixes for detected failure patterns
  • Suggests additional eval coverage based on observed failure types
  • Mission Control handles operational Kubernetes concerns separately: preflight checks, health dashboards, diagnostics

Why it matters for PMs: The mental model here is significant. LangSmith Engine is essentially a QA PM for your agent system, one that reads every production trace, groups failures by pattern, and tells you what to fix and what to test next. If you're shipping agentic products, the biggest operational challenge isn't building the agent, it's knowing when it's quietly failing at scale. Engine is a direct answer to that. The "proposes fixes" piece is particularly interesting because it closes the feedback loop in a way that's usually manual: observe failure, identify cause, write fix, add regression test. Engine is trying to automate that loop. The obvious risk is that teams start trusting the proposed fixes without understanding them, which creates a different category of fragility.

Critical questions:

  • What's the latency between a failure occurring in production and Engine surfacing it as a named issue? Real-time vs. batch matters a lot for response time.
  • How does Engine determine what a "fix" looks like? Is it suggesting prompt changes, code changes, or evals? All three have very different trust implications.
  • Does Mission Control require changes to how LangSmith is deployed, or is it a management layer on top of existing Kubernetes configs?
  • How does Engine handle false positives, i.e., things it clusters as failures that are actually expected edge case behavior?

Action you could take today: If your team runs any LangSmith-instrumented agents in production, map your current failure triage process: who sees the traces, how failures get categorized, and how long it takes to go from observed failure to shipped fix. That's the baseline Engine is trying to compress. Understanding your current cycle time is the first step to evaluating whether Engine actually helps.

Vercel - Function Invocations Now Billed Per Unit#

Source: https://vercel.com/changelog/function-invocations-now-billed-per-unit Credibility: High (first-party changelog, dated May 29, 2026)

What happened: Vercel changed how it bills for function invocations. Pro and new Enterprise customers are moving from package-based pricing to per-unit pricing. Existing customers pay the same effective rate through the end of their current billing cycle.

Key details:

  • Applies to Pro and new Enterprise customers
  • Existing customers grandfathered through current billing cycle
  • Per-unit replaces package-based, meaning cost scales directly with usage rather than in step-function increments

Why it matters for PMs: Pricing model changes from packages to per-unit almost always affect product decisions in two ways: teams that were "buying ahead" to stay in a package tier can now right-size, and teams that were using packages as a budget ceiling lose that natural throttle. For anyone building AI features on Vercel (especially Vercel AI SDK or v0-generated apps), function invocation costs are a real budget variable. Per-unit pricing makes cost more predictable at low volumes and more concerning at high volumes. It's worth auditing your current invocation patterns before the billing cycle switches.

Critical questions:

  • Is the per-unit rate actually equivalent to what package customers were paying at typical usage levels, or does it benefit only low-usage customers?
  • Does this change affect Vercel Sandboxes (which also run functions)? The changelog covers Sandbox Docker support separately, but pricing interaction is worth checking.

Action you could take today: Pull your last 30 days of Vercel function invocation data and estimate what your bill would look like under per-unit pricing vs. your current package. If you're running any AI features that generate spike traffic, model the worst-case month.

Quick Hits#

The Thread#

The autonomy dial is becoming a product feature. Cursor's three-tier run mode, LangSmith Engine's automated failure clustering, and Figma Make's local codebase connection are all solving the same underlying problem from different angles: how much can you extend the AI's working window before a human needs to check in? This week showed three distinct design patterns for that dial: allowlists (Cursor), automated observability with proposed fixes (LangSmith), and context-grounded editing (Figma). None of them go fully autonomous. All of them reduce the friction of staying in the loop. That's the design space that's maturing right now.

Sit With This#

Cursor's Auto-review mode uses a three-tier trust model: allowlisted calls run freely, sandboxable calls run contained, and everything else requires approval. The user sets the allowlist, so trust scope is user-defined rather than tool-defined.

For your product: If you were designing the human-in-the-loop controls for an agentic feature in your product, what would your equivalent of the allowlist be? What actions would you let run automatically, what would you sandbox, and what would always require approval? Where would your users draw those lines, and would they draw them in the same place you would?