Can designers make code changes without knowing how to code?

Yes. Frontman connects to your running application and lets you click any element in the browser to select it. You describe the change you want in plain language — "make this spacing tighter," "swap this to our secondary color" — and Frontman traces the element back to the source code, makes the edit, and verifies it via hot-reload. No file names, no code syntax, no terminal commands.

Will this break our design system?

Frontman is aware of your component tree and design tokens. It edits the actual component source, not a one-off override, so changes stay within your system's structure. Every change produces a standard code diff that goes through your team's normal review process before merging.

How is this different from Figma-to-code tools?

Figma-to-code tools generate new code from designs. Frontman edits your existing codebase — the real components your users see in production. It works with whatever you already have: your framework, your design tokens, your component library. Nothing is regenerated or overwritten.

Does engineering still review the changes?

Absolutely. Every change Frontman makes is a normal code diff — a pull request that your engineering team reviews, approves, and merges through your existing workflow. Designers and PMs get to initiate changes; engineering keeps full control of what ships.

AI Coding Agents Are Blind to UI

You spot a spacing issue on the pricing page. The cards feel too cramped — the padding inside each feature block needs to breathe. You know exactly what’s wrong. You’ve known for two weeks.

You open a Jira ticket. You annotate a screenshot in Figma. You tag the frontend team. The ticket lands in the next sprint planning. A developer picks it up eight days later, asks a clarifying question in the ticket comments, you answer, they ship it the following Wednesday. Fifteen days for a change you could point to with your finger.

This is not a process problem. This is an access problem.

TL;DR: Designers and PMs can see what’s wrong in the UI but can’t fix it without filing a ticket and waiting for engineering. Frontman bridges that gap — you click any element in your running application, describe the change in plain language, and the AI traces it back to the source code, edits it, and verifies the result via hot-reload. The change goes through code review like any other PR. Your design system stays intact. Engineering keeps control. Shipping gets faster.

The Bottleneck No One Talks About

Your team has a mature design system. Tokens for spacing, color, and typography. A component library your engineers built and maintain. Figma files that mirror what’s in production. The system works.

What doesn’t work is the last mile. The gap between “I can see this needs to change” and “this change is live.” That gap is not a design problem or an engineering problem — it’s a handoff problem. And it costs your team weeks of calendar time on changes that take minutes to describe.

Every visual change — a spacing tweak, a color adjustment, a copy update, a component variant swap — follows the same path: designer or PM notices it, files a ticket, engineer context-switches into it days later, asks clarifying questions because the ticket lost nuance, ships it, designer reviews, requests a small adjustment, engineer context-switches again.

Multiply that by every team touching the product. Multiply it by every sprint. That is your design velocity.

Why AI Coding Agents Don’t Solve This

You might think AI coding agents like Cursor, Claude Code, or Copilot could help. They can’t — at least not for this.

These agents operate on source files and terminal output. They read code, but they never open a browser — the runtime context gap in action. They never see the rendered page. The information they need for visual changes — which element is which on screen, what the computed spacing actually is, how components map back to source files — exists only in the running browser.

For an engineer who already knows the codebase, this means some guesswork and a few rounds of correction. Annoying but workable.

For a designer or PM, it’s a wall. You would need to know the file name, the component structure, the class naming convention, and the build system — just to describe to the agent what you’re looking at. That is exactly the knowledge gap the ticket was supposed to bridge.

What Framework-Aware AI Changes

Frontman takes a different approach — what we call framework-aware AI. Instead of reading files and guessing what the UI looks like, it hooks into your framework — Next.js, Astro, Vite — and connects to the running browser. It has access to:

The live UI — the actual rendered page, not a code approximation
Your component tree — which component renders which element, mapped back to source files
Computed styles — real resolved values, not token names or class strings
Hot-reload — instant visual verification that the change looks right

You click an element. You say what you want. Frontman traces that element through the component tree to its source, makes the edit, and confirms the result rendered correctly.

You don’t need to know the file name. You don’t need to know the code. You point and describe.

What This Looks Like in Practice

Here is the current flow for a spacing change in your design system:

Designer: *notices card padding is too tight on pricing page*
Designer: *opens Jira, writes ticket, annotates Figma screenshot*
Engineer: *picks up ticket 8 days later*
Engineer: "Did you mean the inner padding or the card wrapper?"
Designer: *replies next day with clarification*
Engineer: *ships the change*
Designer: *reviews* "Close, but can we also bump the gap between cards?"
Engineer: *context-switches back, ships a follow-up*
Total: ~15 days

Here is the same change with Frontman:

Designer: *clicks the card content area in the browser*
Designer: "Make the padding inside these cards more spacious"
Frontman: *reads current spacing from the live element*
          *traces it to PricingCard component source*
          *edits the component, hot-reload fires*
Designer: *sees the change instantly* "That's it."
Designer: *opens PR for engineering review*
Total: ~5 minutes + review time

Same outcome. Same code review process. Same design system integrity. Fifteen fewer days on the calendar.

Your Design System Stays Safe

This is usually the first concern: “If non-engineers can edit code, won’t they break our component library?”

Three things protect your system:

Frontman edits components, not overrides. It traces clicked elements back through the component tree to the actual source component. It edits the real thing — not a one-off style override that breaks the next time someone updates the system.

Every change is a standard code diff. Frontman produces a pull request. Your engineering team reviews it, comments, requests changes, or approves it — exactly like any other PR. No code ships without engineering sign-off.

The AI sees your component boundaries. Frontman understands which element belongs to which component. It won’t edit a shared Button component when you meant to change the spacing in the specific card layout that contains it. It respects the architecture your engineers built.

Common Concerns

“Our codebase is too complex for non-engineers to touch.” That’s the point — they don’t touch the codebase. They interact with the running UI. Frontman handles the translation from “this element on screen” to “this line in this file.” The complexity stays where it belongs: in the tools, not in the workflow.

“Figma is our source of truth. Changes should flow from design to code.” Frontman doesn’t replace Figma. For net-new design work — new pages, new components, major redesigns — Figma stays the starting point. Frontman handles the long tail: the spacing tweaks, token adjustments, responsive fixes, and copy changes that pile up in your backlog because they’re too small to justify a full design-to-handoff cycle but too important to ignore.

“What about changes that need to propagate across the system?” When Frontman edits a shared component, the change propagates everywhere that component is used — same as when an engineer edits it. Your team can review the blast radius in the PR diff before merging. For design token changes, the same principle applies: the AI edits the token definition, and the system handles propagation.

“We tried low-code/no-code tools before. They generated unmaintainable code.” Frontman does not generate code. It edits your existing code — the same files, the same components, the same conventions your engineers already maintain. The output is a clean diff that follows your codebase’s patterns because it’s modifying code that already follows them.

The Bigger Picture

This is not about saving time on one padding change. It is about who gets to participate in shipping product.

Today, your design system is a shared language — but only engineers can write in it. Designers and PMs can describe changes. They can annotate screenshots. They can file tickets. But the act of making a change requires engineering time, and engineering time is the scarcest resource at every growing company.

When anyone who can see a problem can also fix it — with full code review, within your existing system, respecting your component architecture — the bottleneck shifts. Engineering reviews diffs instead of translating tickets. Designers iterate at the speed of their own judgment. PMs ship copy and layout tweaks the same day they notice them.

The wall between “people who can describe a change” and “people who can make a change” disappears. Not because you lowered the bar — because you gave everyone the same tool your codebase already understands.

Try Frontman — works with your existing project and design system. Read about how Frontman keeps your code safe or see how it compares to Cursor and Claude Code.