Direct visual editing
Work with frames, elements, text, images, layout, components, variables, named styles, pages, comments, and presence.
AI design for existing code
Iterate visually on an existing codebase without pretending the canvas and runtime are the same thing.
Iterel combines a direct Design canvas, project design-system guidance, tracked engine delegation, immutable versions, and an explicit path for reconciling accepted visual work back into code.
Beyond greenfield generation
Many AI UI tools are strongest when they generate a fresh page. Existing products are harder: the design must respect established components, tokens, routes, technical constraints, and work already accepted by the team.
Iterel keeps visual work inside the same project record as coding-agent tasks. People can edit directly in Design, or delegate a scoped change after a tracked task exists, without turning an unreviewed prompt into silent canvas state.
The Design workflow
Work with frames, elements, text, images, layout, components, variables, named styles, pages, comments, and presence.
Use a repository-extracted system, a catalog choice, or Iterel Base, then give design-touching tasks the resulting design pack.
A selection-scoped Design request creates or binds a task before an engine is allowed to mutate canvas state.
Generated changes are sanitized, bounded to the selected scope, and attributed through their task, agent or tool, and session.
Accepted Design work keeps immutable before-and-after versions and a review receipt instead of relying on prompt history alone.
Design-to-code work is an explicit reconciliation round, so the team can inspect what the engine actually implements.
From visual intent to code review
Start from a local folder, repository-backed project, or the project’s current Design state.
Extract the repository’s system when available, choose a catalog, or use Iterel Base as a defined fallback.
Choose the frame or elements the next Design request is allowed to affect.
Bind a task, run the connected engine under the Design mutation contract, and review the resulting receipt and version.
Create the implementation round, inspect exact Changes and Preview, and accept only the code outcome you reviewed.
Design and runtime stay honest
Canvas frames are visual snapshots and editable design objects; they do not hide a browser or carry a Play action.
Desktop Preview runs the exact task worktree with HMR and stops when that managed task runtime closes or changes.
Iterel does not promise invisible bidirectional synchronization. The reconciliation round makes code implementation reviewable.
Questions, answered
Yes. Iterel can start from a local folder or repository-backed project, extract available design-system context, and keep Design work connected to tracked implementation tasks.
No untracked prompt may mutate Design. Iterel creates or binds a task first, constrains the selected scope, and records versions and a receipt around the change.
No. Accepted visual work moves back to code through an explicit Design-to-code reconciliation round, where the resulting files and Preview can be reviewed.
Yes, when the project has an exact usable Figma binding. Figma Import appears under Design +, creates a tracked task receipt, and imports the selected frame rather than granting broad Figma access.
Yes. Machine-local projects include Build and Design, and opening Design does not upload the project. Cloud collaboration and review publication are explicit actions.
Design the existing product
Build and Design are included in unlimited machine-local projects on Free. Opening Design does not upload a local project.