# We Left Framer > Source: > Published: 2026-05-27 17:11:38+00:00 ·By Nick Lane-Smith # Why we left Framer Or: how I learned to stop worrying and love agentic design. **If you're shipping a software product in 2026 and your product can't be driven by an agent, you're cooked.** Not every workflow has to move to agents. Anything a single human can hold in their head will stay where it is. The workflows leaving drag-and-drop interfaces are the operational ones, where a team grinds through repetitive composition work for hours a day. Drag and drop isn't broken, but it can no longer compete with what a team and an agent can do together. Every minute a founder spends nudging boxes in a canvas is a minute not shipping the demo video. Every hour a designer spends rebuilding the same component in a visual editor is an hour off the next campaign. That tradeoff used to be fine when the alternative was "ask an engineer." The alternative now is "ask Claude," and Claude is 10x smarter than most of us, 100x faster than all of us, and can work on 10+ different asks at once. The rest of this post is about how we learned this the expensive way. ## The Framer experiment We picked Framer for the Babou marketing site for the reasons everyone picks Framer: visual canvas for the design half, code components for the engineering half. My brother Matt and his team is the design half, and the bet was that Framer's friendly interface would keep him in the driver's seat while I assembled everything around him. The first feature we tried to build was the navbar, which isn't exotic: two dropdowns split by audience, Features for technical buyers, Creative for marketers, each with labeled items, descriptions, icons, and hover states. In a Next.js codebase this is a couple hundred lines of component code. In Framer it became four approaches and a closed door. ## Approach zero: drag and drop it myself I'm no deep-Framer expert, but how hard can a drag and drop web builder be? I've been using them since Dreamweaver. I started where you'd expect. Drop in a rectangle. Round the corners. Drop in some text for the brand. Drop in a few text links. Drag, click, nudge. Logo on the left, items on the right, the orange CTA at the end. **Ten minutes in, with no agent in the loop, I'd already burned what's probably the equivalent of three hours of agent time.** And the easy part was the part I'd just finished. The mobile breakpoint, the dropdown panels, the hover states on every item, the contextual inspector that opens every time you click something, the variant swapping between them. Doing all of that by hand the way a designer would was going to take days. Time for some agents! ## Approach one: import an off-the-shelf nav Drag and drop was out, so I'd cheat the design problem by starting from someone else's work. The Framer marketplace has several reasonable nav components, so we picked one, dropped it into the project, and pointed Claude Code at it. The plan was to bash on it through the Framer MCP until the labels, icons, and links matched what we wanted. Claude couldn't change the labels, because linked component instances in Framer don't expose their internals through the API. `getChildren()` on a linked instance returns an empty array, you can only set the controls the component author exposed, and neither the labels nor the icons were exposed as controls. The only escape hatches were "detach the instance," which severs the link to the source and leaves you with a static frame, or "open the Framer UI and edit by hand," which defeats the whole reason we were trying to drive Framer programmatically. ## Approach two: build it from scratch through the MCP If the marketplace component was closed, fine, we'd build our own. Claude burned about three hours on this through the Framer MCP. The output was a slow accumulation of opaque hashed identifiers. Every node Claude created came back with a string like `Hb53M8VtK` or `Ay5dA8cmr` , and the only way to do anything later was to maintain a hand-curated map of which hash meant which thing. About two hours in I opened the file Claude was keeping. This is what programming a UI through the Framer API actually looks like. No naming layer, just hashed strings everywhere, mapped by hand to whatever you happen to remember about the layout. The component's hover state, which was the whole point of having a dropdown, couldn't be set through the API at all. Framer interactions, the things that fire on hover or click and modify sibling state, are an editor-only feature. There is no programmatic way to wire "when I hover the nav item, show the dropdown." You open the Framer UI, click the element, and set the interaction in the inspector. By hour three I'd had enough: Yes, I yell at my coding agents all the time. Am I the only one? ## Approach three: write our own CLI I gave Claude one hour to write a custom `pnpm infra framer` CLI that talked to the Framer Server API directly, no MCP in the middle. The CLI worked: faster, cleaner to drive, got further into the build before failing for the same underlying reason. The Framer Server API itself can't set interactions, can't link a component to another component's state, can't set animation transitions on variants, can't create SVG nodes, and can't modify the internals of linked instances. `setHTML` is blocked, `setAttributes({ font })` silently fails, and component instances expose their props as hashed strings like `UO5clYVeQ` that you discover by inspecting the rendered tree. The full list of these gotchas runs 162 lines in our post-mortem. ## Framer hasn't shipped an MCP While we were grinding through all of that, I noticed something else: the Framer MCP we'd been using isn't from Framer, it's a community plugin written by someone outside the company. In May of 2026, a venture-backed design tool whose entire pitch is that code and design live together has not shipped a first-party agentic interface. If you're a software company in 2026 and you haven't put one in front of your product, you are not paying attention. Your customers are using Claude Code and Cursor and Codex right now. Every product they have to leave to drive your tool by hand is a product they're going to use less of. ## The decision This is the message I drafted for the team on the way out: The next morning I scaffolded a Next.js app under `apps/web` , and the rest of the dev team jumped in to help. By the end of that day we had every page we'd planned for Framer plus three we hadn't, all of it on Tailwind for styling, Framer Motion for animation (the part of Framer the company everyone loves, fully OSS and works anywhere), MDX for content, and Fly.io for hosting with per-PR preview builds. The price of the switch was the one I'd been hoping to avoid: the code is now the design surface, and a non-engineer can't just open the canvas and drag things around. Except, it turns out, they kind of can. ## The process Matt now drives most of his design work through Claude Code. He describes the design, looks at the result in his browser, and iterates. The feedback loop is seconds, not the minute-to-hour-long round trips Framer was costing us. Framer's API gap unlocked a different design process. Because each iteration is now a sentence to Claude instead of a manual rebuild, we stopped picking the first design that worked. For the new navbar we generated twelve variants in parallel, the design team reviewed them, debated, and picked five, then we generated four or five more passes on each of those five and narrowed again. We locked in our whole design in an afternoon, across two meetings. That process isn't possible in a drag-and-drop tool, and it isn't really possible in code without agents either. It only works when the design surface is something an agent can drive at full speed. More on how that process actually works in the next post. For now, if you're picking a tool to build something operational in 2026, ask whether an agent can drive every meaningful part of it through a first-class API before you ask whether the visual editor is good. If the answer is no, the tool is borrowing time it doesn't have. These are the kinds of problems we're working on at Babou: bringing marketing and visual design into agent workflows as first-class citizens, not as bolt-ons. If you want to talk about any of this, or you're trying to solve a version of it inside your own product, [get in touch](/contact). We're also hiring 🙂