Problem
Arko began with a problem I experienced as a designer who also codes: designing an interface and implementing it meant working in separate environments. I wanted the control of visual design tools without maintaining a separate representation of what the application would eventually become.
The people I'm designing for are designer-engineers: people who build React interfaces, edit Tailwind classes, tokens, and component props, and move constantly between the rendered result and the exact source behind it. Every handoff between a design file and the codebase is a chance for the two to drift apart.
AI raised a second question: asking an agent to make a change can help with implementation, but I didn't want every adjustment to require another prompt. Designers still need to see the result, make precise visual changes, and understand what changed underneath. They also need to know whether a change has actually been made or only proposed.
The design problem was not simply to add AI to a visual editor but to answer a harder question: how do I connect planning, AI-assisted implementation, and hands-on refinement without taking control away from the designer?
Constraints
I design and build Arko myself, so scope and reuse matter: it targets one platform, Apple Silicon Macs, and reuses established open-source pieces where they aren't the product, namely Chromium through the Chromium Embedded Framework (CEF), the code_forge editor package, an Alacritty-based terminal renderer, and the Forui component kit. The Agents chat is built on a Codex client from my separate codex-ide project. I build Arko with AI coding agents, guided by a written roadmap, architecture rules, and recorded verification for each feature. My work centers on the product experience, the architecture, and integration rather than on training models or recreating every underlying tool.
The project's source code is the hardest constraint, because a rendered element might come from a shared component, a value passed in from elsewhere, or one specific use of a component, and changing what you see can mean changing every place that component appears. A visual control can't assume that everything visible can be safely rewritten, so Arko has to know which edits it can make precisely and leave the rest to code. I made that a rule: an element rendering correctly never means it's editable.
Live rendering raises the performance bar, since each responsive frame on the canvas is a real Chromium page served by the project's own development server and several are on screen at once. Direct manipulation still has to feel immediate: a drag or an Inspector change can't wait on the page, the compiler, or the disk before the designer sees a response.
Continuity shapes the experience as well: moving between the canvas, the code editor, planning tools, and chat shouldn't lose a selection, an unsent message, or the context of a task.
AI introduces a further boundary, because proposed changes must stay separate from the live project until they're reviewed, even when the designer has unsaved edits open. Conflicting edits and uncertain outcomes need explicit handling, and a completed agent response isn't proof that the resulting interface works.
Product Direction & Decisions
I kept Arko design-first as AI became part of the product, building chat into a workspace where people move between describing intent, inspecting changes, and directly manipulating the interface instead of letting it become the entire experience. I was just as deliberate about what Arko isn't: a Figma-to-code exporter, a separate design-document tool, a no-code generator, a general-purpose IDE, or an AI chat wrapper. That direction led to the seven decisions below.
- I kept visual editing connected to the actual project.
The Design workspace renders the running application rather than a mockup, so each frame is the project's own page, and Desktop, Laptop, Tablet, and Mobile frames can sit side by side on one canvas. Supported visual edits become exact changes to project source and show up in every frame. Peek Source opens the selected element's code, ready to edit, in a panel below the canvas. View Source jumps to the same lines in the code editor, and Back to Design returns to the same canvas and selection. I also separated Edit and Interact modes, so selecting an element and using its behavior are distinct actions. - I defined "feels like Figma" as behavior I could test.
Because designers judge a canvas by feel, I turned "Figma-grade" into five properties that could each be tested. Instant: a gesture gets a visible response without waiting on the page, the compiler, or the disk. Ordered: edits apply in the order they're made, and none is silently dropped. Truthful: once things settle, Layers, Inspector, canvas, and source agree, with no placeholder flashes along the way. Reversible: Undo and Redo restore byte-identical source and the previous selection. Observable: every operation completes, is rejected, or is cancelled, with a reason. In practice, Inspector style changes preview on the live frames before the source edit commits, layer moves run through an ordered queue that keeps working even when a preview page has crashed, and I only accepted the drag motion after comparing it with a Figma reference recording. - I made it explicit what an edit will touch.
In React, one component can appear in many places, so selecting something inside a component instance still reveals its exact source while the instance only offers the overrides its code supports: text, images, and styling the component accepts through its props or className. Structure and layout changes go through Edit Component, which opens the shared definition with an "Affects all uses" label, so the scope of a change is never a surprise. The Properties section reads simple props and variant options declared in the component's source. Anything Arko can't change precisely stays one click away in Peek Source instead of being guessed at. - I made AI follow the task without replacing the workspace.
Agents shares the right-hand rail with the Inspector, so the conversation sits beside the canvas, code, or plan rather than taking over the screen. Conversations, drafts, and a reply that's still streaming persist as people move between workspaces, and they can return to manual controls whenever they need precision. Sending a message attaches context from the current view: the selected elements and their source in Design, highlighted code in Develop, the selected page or part of a flow in Plan, and the stylesheet in Theme Studio. That context is captured at send time, so moving elsewhere doesn't silently redirect a task that's already running. A conversation can also switch between Codex, Claude Code, and Gemini and keep its history and pending changes. - I made review the step between a proposal and a change.
By default, agents work in Review edits mode, inside a separate copy of the project that includes the designer's current unsaved edits. The agent can write only to that copy and has no network access. Read only and Full access are explicit choices, and Full access is never restored automatically after a reconnect. When a turn finishes, Arko freezes the proposal and shows a Review changes card, with line counts Arko calculates itself rather than taking the agent's word for it. The diff opens in the center with the conversation still beside it. People can apply one file at a time, reject the rest, or close the review and come back later; closing isn't rejecting. Applied files go through the same edit history and autosave as visual edits, so Undo works the same way. If the result of an apply is ever uncertain, Arko shows Check apply outcome instead of guessing. - I connected user flows to implementation intent.
In Plan, Flows lets people map a user goal as a flowchart of screens, decisions, actions, inputs, and outputs, joined by labeled branches, with notes plus optional flow details and acceptance criteria. A screen can point to an existing page or stay planned. Each flow is saved as a file in the project, so Git and other tools can read it, and it can be exported as JSON, Mermaid, or an implementation brief. Build with AI starts a fresh conversation with the whole flow as a named attachment and an editable instruction. The instruction asks the agent to follow the existing architecture, reuse bound screens and routes, preserve the authored branches and criteria, ask about missing requirements, and report changed files, assumptions, the checks it actually ran, and unresolved criteria. A repeated screen state shouldn't automatically become another page. If the flow changes before sending, the attachment has to be refreshed first. - I kept design-system control alongside AI assistance.
Theme Studio manages shared tokens, light and dark values, and reusable themes while ordinary project CSS stays the source of truth. It edits the custom properties in the project's stylesheet in place and keeps a design-token JSON file beside it in sync. Themes can be saved for all projects or just one, and imported or exported as plain CSS for shadcn and tweakcn. The Inspector's color controls offer the project's own named colors. This gives people direct control over visual consistency instead of making every design decision depend on another AI request.
Solution
Arko supports a connected workflow in which people plan the experience, request implementation help, review the proposed changes, and refine the result visually, across five workspaces that share one project and a right-hand rail for precise controls and AI.
Workspace | What it's for |
|---|
Plan | A sitemap of every page with notes, page properties, and site SEO settings, plus Flows for user journeys |
Design | Live responsive frames of the running app, with Layers, Elements, and Assets on the left |
Theme Studio | Tokens, light and dark values, and reusable themes |
Develop | A focused code editor with TypeScript intelligence, search, Git changes, Problems, and a terminal |
Web | The running app in a full browser, with Chromium DevTools and a Safari (WebKit) option |
Inspector and Agents | The shared right rail: Style, Actions, and Settings controls, or AI conversations |
People can start with a page in Design or a journey in Flows, and Agents receives the relevant context while editable tasks produce proposals in an isolated copy. The review surface shows the source differences before anything is applied. Applied files that had no unsaved edits are saved automatically and reach every frame through the project's hot reload. If the designer already had unsaved edits in a file, the applied change joins them and the file stays unsaved until they save it.
From there, people can inspect the rendered result, adjust supported layout, typography, and component properties, and use Theme Studio for shared visual decisions. Peek Source keeps the implementation in reach, and Interact mode lets them check the interface's actual behavior.
These are connected tools rather than a mandatory sequence, so a designer can work visually without AI, use AI for a specific implementation task, or move into code when a visual control isn't the right fit.
How it's built
Arko is Rust-first: a Rust engine owns the project, including files and saving, source analysis, edit planning and version checks, language services, the project's development server, and the agent processes. Flutter, with the Forui component kit, draws the interface and turns gestures into explicit requests to that engine. Each design frame is a Chromium page rendered by a separate, supervised process and composed onto the canvas as a GPU texture, so a page that crashes can be reloaded without restarting Arko. There is no separate design file for the interface: every visual or AI change resolves to an ordinary edit in the project's own code.
The first version, started in April 2026 with React and Tauri, proved the workflow, but its React interface was too slow for the direct manipulation Arko needed. Flutter was faster in my spikes, with a GPU-accelerated shell that also ran a capable code editor, so I moved the interface to Flutter in August 2026 and kept Rust as the engine. I migrated in vertical slices, retiring each old path once its Flutter replacement was verified, rather than rewriting everything at once.
Impact
Arko hasn't been publicly released, so I don't have adoption or productivity metrics yet; what I can show is a working application and recorded evidence for specific behaviors.
- A working macOS application, developed since April 2026 and rebuilt on Flutter and Rust from August 2026.
- Five workspaces plus the shared Inspector and Agents rail, all working on the same project's source code.
- Three agent providers (Codex, Claude Code, and Gemini) in one shared chat with reviewed source changes.
Area | Recorded evidence | Not yet established |
|---|
Visual editing | Drag motion accepted against a Figma reference recording. Two Undo steps restored all 14 fixture files exactly. Layer moves kept working with all three preview pages crashed. | End-to-end input-to-display timing |
Real projects | Page and layout navigation passed native checks on five Vite, TanStack Start, and React Router fixture projects. | Full page and layout authoring; other project types (Next.js is out of scope) |
AI review | One authenticated Codex turn on a controlled HTML/CSS fixture left the live files untouched until review, then applied the reviewed change. Real-account checks with Claude Code and Gemini covered edit, review, apply, Undo/Redo, follow-ups, and resume in disposable projects. | Acceptance in the running app's interface; release qualification for each provider |
Release | None yet | Code signing, notarization, accessibility, and performance targets |
These results establish specific working behaviors rather than universal correctness or production readiness, and the outcome I can support is the implemented workflow: a designer can plan a journey, hand it to an agent with its context, review the proposal file by file, and keep refining with visual and source controls.
Reflection
This project reinforced that integrating AI is an interaction-design problem as much as a technical one. The important decisions happen around the model: what context is supplied, when a change becomes real, how people inspect it, and how easily they can take over.
It also taught me to write quality down, because "feels like Figma" and "safe to edit" only became useful once they were properties I could check, and those definitions now guide decisions as much as the visual design does.
The next validation priority is whether those boundaries are understandable in practice: can a designer tell what the agent is working from, distinguish a proposal from an applied change, and confidently refine the result? Answering that, alongside release work on performance, accessibility, and packaging, comes next.
Arko's direction is not to replace design judgment with prompting but to connect planning, implementation, and direct manipulation so designers have more ways to shape the same working product.