# Obsess Over the Details Again: Why I Rebuilt the Design Tool for the AI Era. By Angie Hemans (@angiehemans) · Published 2026-07-24 Canonical: https://voce.com/@angiehemans/obsess-over-details-design-tool-for-ai-era-dr0kjo --- For most of my decade-long career as a UX designer and developer, I was stuck in a repetitive, maddening loop. I would spend weeks obsessing over a design: perfecting the hierarchy, the rhythm of the spacing, and the elegance of the transitions, only to see it "come back" from engineering almost right, but fundamentally not. The hover state was missing. The border-radius was off by two pixels. The spacing didn't quite breathe the way I’d intended. It was a near-perfect success that unexpectedly felt like a failure, and for years, I believed this was just the cost of doing business. In July 2026, even as design token adoption has become a standard professional practice, handoff remains the single largest friction point in digital product development. This isn’t a people problem. I’ve worked with brilliant developers who cared deeply about the work. It is a tools problem. We have built an industry on the "handoff," a term that implies a clean transition but in reality functions like a game of telephone played across a canyon. Design lives in one world; code lives in another. Until we acknowledge that design and code are the same medium, we will continue to build on top of a category error. I built [Scamp](https://www.scampdesign.app) because I got tired of shouting across that canyon. ## Why handoff is a category error In the current industry landscape, the boundary between design and code is blurring. Designers are increasingly using AI agents like Claude to generate UI directly in code or utilizing Figma's advanced export features. As noted in recent [discussions on the shift toward designing in code](https://www.linkedin.com/posts/filyin_designing-in-code-sounds-like-low-level-activity-7467840161008193536-KJJI), these "shortcuts" often still fall into the category error of treating design as a one-way delivery. They assume that if you can just output the code, the problem of collaboration is solved. AI-generated code often misses the "canvas" intentionality that designers need to thrive. While agents can produce functional components, they lack the direct visual logic required to refine, experiment, and apply the final 10% of polish. Similarly, Figma exports often create a persistent feedback loop where design intent is lost the moment a developer or AI agent edits the code downstream. The "source of truth" remains a static file, disconnected from the living production environment. Scamp solves this by saving the design as the actual code substrate. It provides a full canvas editing experience where every visual adjustment is a direct modification of production-ready React and CSS. This creates a continuous human-AI-developer loop: designers have the power to work alongside developers and AI agents to refine a design until it achieves a level of unique, human-grade polish that no standalone AI agent could build on its own. ## Bridging the gap with production code I built Scamp to stop the guessing. Instead of creating a picture of a button, Scamp allows you to design the button using the same primitives the developer will use. When you adjust a margin or a padding value in Scamp, it isn't just an arbitrary number in a database; it is generating [clean CSS modules and TSX components](https://scampdesign.app/docs/code-output) that are production-ready. ![](https://convex.voce.com/api/storage/d7092646-54ed-4d5c-93c3-d5b19155b8b9) The core philosophy of Scamp is bi-directional synchronization. In many traditional handoff tools, the "source of truth" dies the moment the code is written. If a developer makes a change in the CSS to fix a bug, that change rarely finds its way back to the design file. In Scamp, the code and the design are linked. You can design visually, see the [code output updated in real-time](https://scampdesign.app/docs/code-output), and know that what you see on your canvas is exactly what will appear in the browser. This approach solves the "Production-Ready Chaos" that many design teams face. We no longer need to write exhaustive documentation explaining how a responsive grid should behave because the grid is defined by actual Flexbox and Grid logic within the tool. We are moving from a world of "handoff" to a world of "synchronized shipping." ## An Integrated Design Environment (IDE) for the AI era One of the first things users notice when they open Scamp is the command line. It is not hidden in a submenu: it is an integral part of the layout, accessible via a simple shortcut (Ctrl+\`). While putting a terminal in a design tool might feel like a provocation, it is actually the key to creating an Integrated Design Environment (IDE) for designers. By building an IDE, I wanted to create a parallel to the Integrated Development Environments that engineers have used for decades. Developers have VS Code; designers now have Scamp. This environment brings together the visual canvas, a robust theme builder, direct access to CSS for those who want it, and a built-in terminal that serves as a portal for any AI agent you choose to work with. Whether you prefer Claude Code, Codex, or a custom internal agent, you can run them directly within the Scamp terminal. Because the terminal has direct access to your local project files, your agent can scaffold out entire sections of a design or suggest high-fidelity edits to existing components in real time. This openness prevents you from being locked into a single proprietary feature set: if a better model comes out tomorrow, you just run it in your Scamp terminal and keep building. This realization prompted me to build Scamp as an open-source project. I believe that the tools we use to build the web should be as open as the web itself. We should not be locked into proprietary file formats that make it impossible for agents or developers to work on our designs. Scamp is my way of saying that the future of design is a shared, agent-friendly workspace where the medium is always the code. ## Designing with a "yes-code" philosophy Whenever I talk about Scamp, the most common objection I hear is that we shouldn't "force designers to code." There is a lingering myth that bringing design closer to implementation might stifle creativity or require hours of debugging. I want to be clear: Scamp at no point requires you to look at, write, or even think about code. You can use Scamp exactly like you use Figma, focusing entirely on the visual canvas. I lovingly call Scamp a "yes-code" platform because you can build in it with the ease of a "no-code" tool, but it saves your work as real, usable, and editable production code. It gives you the power of code without the prerequisite of learning syntax. While Figma import is coming soon, Scamp is built to be the place where you construct the final, production-ready "source of truth" components that actually ship. You can start with your existing design tokens, but the platform is designed for building the production reality of the product. This is a spectrum of participation rather than a binary choice. Scamp isn't about writing code; it's about designing in the language of the final product. For those who want to move fast without touching the terminal, the visual workspace provides high-fidelity control. For those who want to dive deep into the CSS, the editor is right there. By removing the wall between the two, we actually free designers to be more creative because they no longer have to worry if their "wild idea" is even possible to build. This approach is becoming central to [modern design and development strategies](https://enosta.com/insights/modern-software-design-and-development-a-2026-strategy): you know the design is buildable because you have already built it. #### Traditional Handoff - Design and code are separate silos - Source of truth dies at the point of handoff - Design intent is often lost or drifted - Static files require heavy documentation #### Scamp IDE (yes-code) - Design and code are the same production medium - Integrated Design Environment with live sync - Terminal portal for any AI agent - Built-in theme builder and CSS access ## Shipping, not handing off The goal of Scamp isn't to add another step to your workflow; it's to remove three of them. When your design tool speaks the same language as your production environment, the concept of "handoff" disappears. You aren't giving someone a sketch and hoping for the best; you are collaborating on a living product. As an open-source project published under the [Business Source License (BSL)](https://scampdesign.app), Scamp is built to integrate with existing developer workflows. Because it is local-first, your project is simply a folder of plain TSX and CSS Module files that you can place directly into your existing Git repositories and commit like any other code. If you are a design manager looking to reduce friction on your team, or a designer who is tired of seeing your work lose its soul in translation, I invite you to try Scamp. It is free, open source, and built by someone who spent ten years in the same frustrating loop as you. We can do better than "almost right." We can build tools that respect both the designer's intent and the developer's craft. Let's stop handing off and start shipping together.