August 28, 2026 · 4 min read

The tool I was an expert in couldn't be automated

Framer approved me as an official Expert on 7 April 2025. Four months later I started rebuilding my practice so that a model could do the building, and the productized end of it moved off Framer. It now ships as TasteLed, where a client's structured brief becomes a specification, a build and a staged site.

I want to be exact about the scope, because the tidy version is wrong. I didn't leave Framer. aethrdesign.com is a Framer site today. What moved was the productized build, and the reason it had to move was never about whether the model was good enough yet.

A model could write a component. It couldn't write a page.

In 2025, the assumption around me, and mine too, was that going AI-native meant putting AI inside the tool you already had: better prompts, faster iterations, the same canvas.

Framer had a real code surface even then. You could write a code component in React and TypeScript, drop it onto a page and give it property controls, and I had built plenty of them. What the tool didn't give a model was a page it could write. A Framer project lived in a document you edited by pointing at it. There was no page file for a model to open, no diff to read afterwards and nothing that failed when the model got it wrong. A code component was an island inside a page; the page itself was out of reach.

What blocked a generated build wasn't the model's judgment. It was the lack of a place for the model to be wrong out loud.

A machine needs a boring medium

So the productized build moved to code, and the design document became a file. The build starts from a JSON specification validated against a schema and compiled into a typed Next.js codebase.

Two things can refuse it, and they refuse different mistakes. The schema knows what a section is: invent a section type and the specification is rejected before anything is written to disk. The compiler knows what a section needs: omit a required prop and the build names the file and the line. Neither is clever, and that is the point. I wanted failures that were boring and reproducible, the opposite of the canvas, where a wrong decision just sits there looking finished.

What I hadn't expected was that writing the specification format would be design work, and a fair amount of it. A services section takes a heading, an optional subheading and a list of items. Each item may carry an icon, and an unknown icon name falls back to a set default instead of failing the build. I used to make decisions like those by arranging rectangles on a canvas and explaining them to a developer. Same judgments, different reader.

The design document, now: 284 lines describing what a section is allowed to be, written to be read by a model.
A dark code editor showing SPEC-FORMAT.md, with markdown prop tables defining the services and portfolio section types — each row a prop name, its type, whether it is required, and a one-line description — followed by the list of icon names the section accepts

The move happened inside a pipeline that was already delivering client sites, and all nineteen of my delivered client websites came through it as it matured. On Maxematics, AI produced the high-fidelity MVP we iterated from and implemented each round of feedback while I set direction and reviewed it. Two decisions stay with people: I review the specification, and the client approves the staged build. The Aethr Design case study covers that pipeline in full.

Framer caught up, and the split stayed anyway

In June 2026, Framer published a command-line tool for connecting AI agents to Framer projects, and I use it. The constraint I described above belongs to the period when I made the move, and it is no longer the whole truth about the tool.

The split survived that, which is how I know it was never really a tooling argument. Where a person is deciding at every step by looking at the result, direct manipulation is still the faster instrument, and a canvas is the best direct-manipulation surface anyone has shipped for the web. Where a build starts from a brief and has to be checked before anyone reviews it, a versioned specification is the better medium. Custom work goes wherever it fits, which is why the Maxematics rebuild is code and my own practice site is not.

Automatable and appropriate are different tests, and I had been quietly treating them as one.

The practice's own site, still built in Framer, where I want direct visual control.
The aethrdesign.com home page: the AethrDesign wordmark in white over a dark hero with a violet particle-glow ring, a service list at right, and a Lead Designer card

What the Expert approval actually bought

There is a version of this story where the approval turns out to be worthless, a credential in a tool the work has since walked away from. That isn't what happened.

What the Framer years taught me wasn't Framer. It was what a page owes its reader: which sections a small business site needs and which are there because everybody has one, how much a hero can carry before people stop reading, and when a testimonial is evidence rather than decoration. Every one of those judgments now sits in a specification format that has nothing to do with the software where I learned them.

An expert in a tool is really an expert in a set of decisions. Those carry over. Not much else does, and I spent a while believing the reverse.

Related Writing