5 Ways the Pen Design Tool Changes Frontend Workflow

The Pen design tool stores your UI as plain .pen files inside the same repository as your code, which changes who edits a design and when. Instead of living behind a cloud link, the design sits in commits and pull requests, where AI agents, developers, and product people can all work on it directly.

What Is the Pen Design Tool?

The Pen design tool is an AI-native desktop canvas where AI agents draw frames, components, variables, and tokens for you. In September 2026 the Full Cycle channel tested it on a real frontend stack, and the tool was recently renamed from Pencil Dev, so older content and even some agents still use the old name.

Three facts define the product today. The desktop app runs on Mac, Windows, and Linux. The design is not stored in the cloud; only your account information is hosted, while the actual .pen files live wherever you put them, usually inside a source repository. And as of the recording, the tool had no paid plans yet, though the company raised funding and paid tiers are expected.

To use it you create an account and at least one organization, download the desktop app, and connect an AI model provider. The settings panel supports OpenAI, GitHub Copilot, Claude Code, Cursor, and Gemini, so you can use an existing subscription instead of buying tokens separately.

Why Design-as-Code Changes Who Owns the Interface

The core idea is simple: design lives in the same commit and pull request as the code. Traditional tools such as Figma keep designs in the cloud behind a link you paste into a prompt, which creates a handoff chain of designer, reviewer, and developer, followed by pixel hunting in the implementation.

When the design is a local file, the AI agent reads your React components, CSS, and project docs as context before drawing. Product people who never touch a design canvas can propose changes, and the same agent that edits the design can implement the matching code. The interface stops being a separate artifact that drifts away from the product.

A .pen file is JSON, so you can read it with jq or grep, inspect a hex value by hand, and track every change in git history. Manual edits are possible but discouraged: a syntactically valid change can still break the file's semantics, so the tool and its agents should stay the primary writers.

Building a Design System with AI Agents on the Canvas

In the tested session, the presenter gave the agent a screenshot of a YouTube channel page and one prompt: build a design system using primitives, variables, tokens, themes, and components. The agent built tokens and component primitives first, then composed the page, which mirrors how a human designer would work.

Every agent gets a display name, drawn by default from a pool of wizards and philosophers such as Gandalf or Merlin. The names are cosmetic, but watching each agent's live activity matters: you see tokens, variables, and frames appear step by step, and you can interrupt and redirect at any point instead of waiting for a finished result.

The result included light and dark themes, semantic variables for radius and spacing, and a component library frame. It was a first draft, not pixel-perfect, but the structure followed real design system practice without extra instruction.

Parallel Agents and Design Variants

The tool supports up to six agents working at the same time, either splitting separate tasks or exploring the same task side by side. For the login screen test, a coordinator plus two agents produced three distinct login layouts, each researching the existing design system before drawing.

A variants panel lets you choose two to six variants and control whether they differ by layout only or by full visual style. This makes cheap design exploration practical: instead of one opinionated screen, you get several comparable options and pick one.

Two practical tips from the session apply to any team. Use the strongest model tier you have access to, because design quality tracks model quality. And set explicit limits on frames and variants, because unconstrained agents burn tokens producing more artifacts than you need.

Integrating Pen with Next.js and Claude Code via MCP

The tested integration used a standard Next.js project with Claude Code as the primary agent. The .pen file moved into a design-system folder in the repo, and the Model Context Protocol server, which Pen ships for exactly this purpose, connected the agent to the canvas.

The MCP setup exposes five tools covering rendering, document manipulation, state, and style checks, plus a read-skill tool. That skill file teaches the agent how to use the other tools correctly, and adding one instruction to your project context telling the agent to always read the skill first is the single highest-value configuration step in the workflow.

A Windows note matters: the default MCP path points at the Windows executable, which fails from a WSL terminal. Duplicating the configuration with the standard /mnt/c path to the executable resolves it. Either way, the desktop app must stay open while the agent makes MCP calls, unless you use the headless CLI described below.

For translation from design to code, a dedicated design system markdown file outperforms stuffing everything into one agent context file. It records typography, color, icon, and component rules, and instructs the agent to read it before any UI work. The tested run implemented a channel page and three login screens that closely matched the designs, without hand-written translation rules.

Versioning and Merging .pen Files in Git

Git handles .pen history well, but not conventional text merges. The recommended setup, consistent with the tool's documentation, adds a .gitattributes rule so .pen files never merge automatically and never render as textual diffs.

When two branches touch the same design, the conflict is resolved semantically: the agent loads both versions through the MCP tools and merges them as design, not as JSON text. The temptation to hand-edit the JSON is real and should be resisted.

Conflict frequency is a workflow problem, and the file format helps. Multiple .pen files are supported, so teams often split a design library file from a pages file, or one file per team area such as authentication. The finer the split, the smaller the overlap, and reviewers see design changes in the same pull request as the code that implements them.

Headless CI Checks for Design and Code Drift

Pen ships a headless CLI, so the rendering engine can run in continuous integration without the desktop app or an open editor. In the demonstrated pipeline, every pull request installs the CLI, reviews the diff of design changes against the main branch, and produces a drift report comparing the design to the shipped code.

This addresses the standing challenge of keeping design and implementation aligned over time. Because the check runs on every pull request, mismatches surface before merge, and the AI analysis sits directly in the review thread. The presenter built this as a didactic example, so teams should treat the CI pattern as a template to adapt rather than a turnkey product.

FAQ

• Is the Pen design tool free? At the time of the September 2026 video, the tool had no paid plans, and the company has signaled that pricing will arrive later after its funding round. Expect this to change, so check the official site before relying on free access.

• Was the tool formerly called Pencil Dev? Yes. It was renamed recently, so search results and even AI agents may still refer to it as Pencil Dev. Both names describe the same product.

• Do I need to keep the desktop app open? For MCP calls from the desktop canvas or an IDE extension, yes. The headless CLI removes that requirement for CI pipelines and automated edits.

• Can non-designers edit the design? Yes. Because the design is a file in the repository, product people can request changes through an agent, and normal review and approval workflows still apply before anything merges.

From Video to Article

This article exists because a 55-minute walkthrough of a design workflow contained a thesis worth reading in five minutes: put the design file where the code lives, and the handoff problem shrinks. If you have that kind of knowledge sitting in your own videos, tutorials, or interviews, Skala Blog turns a YouTube URL into a structured written article: paste the link, transcribe the video, and generate a draft you can review and publish.

The same way a .pen file keeps design close to code, a transcript keeps your spoken explanation searchable. Skalablog handles the transcription and the article structure so the content in your videos works as a written page.

Source video