Rocket Blogs
Engineering
By Dhruv Gandhi
Apr 7, 2026
You already know what you're trying to figure out. Type it. Rocket handles everything after that.
How does Rocket change one component without regenerating the entire app?
What are the 4 edge types in Rocket's Visual Edit dependency graph?
Does Rocket's surgical editing preserve manual refinements made after generation?
When does surgical editing require an LLM call vs. a direct code modification?
How does the three-way triage system decide what to auto-correct vs. surface to the user?
Why do naive "find and update" component edits only work 40% of the time?
What this post covers: How Rocket's Visual Edit system uses a live dependency graph — capturing 4 edge types across style inheritance, layout containment, data flow, and responsive scope — to apply surgical, component-level changes to AI-generated code without regenerating the full app, breaking cascades, or losing manual refinements made since first generation.
Every AI builder lets you build something. The divergence comes at step two: iteration.
You build an app. You spend twenty minutes tweaking the header layout. You adjust the color palette manually. You move a card component. Now you want to change the size of a primary CTA button.
Every AI builder I've seen responds to this the same way: regenerate the whole app.
The result: your twenty minutes of manual refinements are gone. The model produces something new that incorporates your text instruction but doesn't know about the heading adjustment, the card placement, the color you carefully dialed in. It can't — those changes lived in the output, not in the prompt history.
This is a real architectural problem. Not a UX annoyance. An architectural problem that every AI builder currently solves by pretending it doesn't exist.
We built a different answer: surgical editing. Change exactly what was asked. Preserve everything else.
The reason other builders regenerate is that scoped editing in AI-generated code is genuinely difficult.
Take a seemingly trivial change: make the primary CTA button larger. Here's what that actually touches:
Naively applying the change — find the button, update the size — works 40% of the time. The other 60%, something downstream breaks visibly. Maybe not on desktop. Maybe only in the 375px viewport. Maybe only when the user is logged in and a conditional element appears.
The system needs to know about the cascade before it applies anything.
The core of Visual Edit is a dependency graph built from the generated codebase at first-generation time and kept current across every subsequent change.
The graph captures four types of relationships:
1. Style inheritance — which components share CSS variables, which Tailwind classes are shared across components, which values are derived from a parent's computed property.
2. Layout containment — which components are flex/grid parents, which children are sized relative to the parent, which breakpoints are active at each nesting level.
3. Data flow — which components receive props from a shared state, which conditional renders depend on a parent's state, which components are co-located in a context that would be affected.
4. Responsive scope — which breakpoints affect this component, what layout behavior changes at each, what other components change layout at the same breakpoints.
When a change request arrives — "make the CTA button larger" — the system doesn't apply it immediately. It walks this graph from the target node outward, identifies every node reachable through a dependency edge, and classifies each as: unaffected, automatically correctable, or requires a decision.
The change is applied only after this mapping is complete.
Different types of downstream effects are handled differently:
Auto-corrected silently: A sibling in a flex row that needs its margin adjusted because the button grew. The system knows the correct adjustment from the layout containment graph — it applies it with the primary change, no user input needed.
Auto-corrected with note: A responsive breakpoint that needs to shift because the component is now wider at 768px. The system applies the corrected breakpoint and surfaces a note: "Breakpoint at 768px adjusted — CTA was overflowing on tablet."
Surfaced for decision: A Tailwind class shared between the CTA and a secondary button that the user probably doesn't want to change. The system flags it: "This class also applies to the secondary action button — apply change there too?"
The goal: the user asked to change one thing. They should get exactly that change, plus the minimum set of downstream corrections that prevent a broken state, plus explicit visibility into anything ambiguous.
Not every change requires touching the model at all. This is where precision matters.
| Change Type | Dependency Impact | LLM Required | How It's Handled |
|---|---|---|---|
| Color value update | Style inheritance only | No | Direct property substitution |
| Spacing / padding | Style inheritance + possibly layout | No (if isolated) | CSS variable or class swap |
| Font size | Type scale, possibly layout reflow | No (if isolated) | Direct substitution |
| Component size |
For CSS-level changes — a color hex, a spacing value, a font size on an isolated component — the system makes the modification directly. No model call. No tokens consumed. The dependency graph tells us there's no cascade to handle.
For structural changes — swapping a component, changing a layout pattern, adding behavior — the model is involved, but scoped. The input to the model is not "here is the entire codebase, please make this change." The input is the affected subgraph: the target component, its direct dependencies, its parent context, and the specific constraint being modified. Everything outside that subgraph is explicitly marked as out-of-scope.
This scoping is what makes structural edits precise rather than probabilistic. The model is reasoning about thirty lines of context, not three thousand.
The dependency graph also solves the refinement preservation problem.
When the system maps a change, it first reads the current state of the codebase — not the originally generated state, but the current state including every manual refinement the user has made. The graph is built from what's actually there.
When the model is called for a structural change, the affected subgraph it receives already reflects the user's refinements. The model is not re-generating from the original prompt. It is modifying the current code, within the current context.
This means: if you moved a card component manually, then asked to change the data it displays, the card stays where you put it. The system is editing your refined version, not regenerating from scratch.
Request: "Make the hero CTA button larger on mobile."
Step 1 — Target identification. System identifies the CTA button component, locates its source in the codebase, finds the mobile Tailwind classes controlling its size.
Step 2 — Dependency traversal. Graph walk from the button node: the button is in a flex container with a secondary link; the container stacks to column at sm: breakpoint; the column layout has explicit gap values; no shared CSS variables with other components; no shared Tailwind classes with siblings.
Step 3 — Impact classification. Flex siblings: auto-correctable gap adjustment. No breakpoint shift needed for the stacking — the change is confined to mobile size, the breakpoint itself is correct. No data flow implications. No LLM needed.
Step 4 — Application. Update mobile size classes on button. Adjust gap in parent container. Preview updates.
Total: no model call. Zero tokens. Precise change applied with one automated correction. User's other refinements to the hero section — the custom headline they changed, the background image they swapped — untouched.
Visual Edit sits in the same Build layer as the slash commands and chat I described yesterday. The same codebase. The same project session. The dependency graph is built once at first generation and maintained through every subsequent edit — whether that edit came from chat, a command, or Visual Edit.
This is intentional. The system doesn't have separate state for each interaction mode. A change made via Visual Edit is reflected in the graph the command reads. A change made by a command updates the graph Visual Edit walks. The session is the source of truth for the full dependency state of the project.
The framing "surgical editing" isn't a product metaphor. It's an engineering description. A surgical cut is precise, bounded, and leaves everything it doesn't need to touch intact. That's the specification the system is built against.
| Layout containment + breakpoints |
| Sometimes |
| Graph traversal, auto-correct |
| Component swap | Data flow + layout + style | Yes | Scoped LLM call on subgraph |
| Layout restructure | Full containment subtree | Yes | Scoped LLM call on subtree |
| Adding new behavior | Data flow + new dependencies | Yes | Scoped LLM call + graph update |