What a design engineer decides when agents do most of the typing
This site's repository has 744 commits from seven months, and 649 list Claude as co-author. What kept it coherent was a short list of decisions written down where every session reads them, and checks that fail when one is broken.
The repository behind this site has 744 commits from the last seven months, and 649 of them list Claude as co-author, which means most of the typing in this project was never mine and the project still holds together. It holds together because of a short list of decisions I made once and wrote down where every session reads them, plus checks that fail when one of those decisions gets broken.
Where the old line came from
For a long time design and engineering were separate jobs because the tools made one side cheap and the other expensive. Drawing a screen cost an afternoon and building it cost a sprint, so we put different people on each side of that gap and invented the handoff to carry intent across it. One essay on the rise of the design engineer argues that the split existed because of tooling limits and that the bottleneck has moved from execution speed to judgment. The claim matches my own work: when a running prototype costs an afternoon, the scarce skill is knowing whether the thing is right.
The numbers on designers crossing the line are easier to cite. In Designer Fund's AI in Design 2026 report, half of surveyed designers said they have shipped AI-generated code to production and 65% said they are taking on more product or engineering work. The same report found that 73% of designers feel expectations rising while only 28% of leaders say their company has formally updated how it evaluates, pays or hires, so a lot of people are doing the new job against a ladder written for the old one.
A color system that three copies had broken
The decision that shows the job most clearly on this site is the color system. Before 2026-09-27 the light, OS-dark and manual-dark themes were three hand-written copies of the same palette, and they had drifted apart. The commit that replaced them builds every color from one source file, expands it into twelve-step scales, solves the text steps for contrast and emits all three themes from that single source. It also introduced scoped surfaces: a colored area redefines the background, text and foreground variables for everything inside it, so text on a hue always takes that hue's own on-color. That fixed a real dark-mode bug on the portfolio pages, where white text sat on light pastels.
Most of what I did there was decide, and almost none of it was typing. I chose twelve steps per family, chose that contrast gets solved by the build instead of eyeballed, and chose that a colored region owns its text color. The agent wrote the code. A design engineer is the person who can state those choices precisely enough for an agent to carry them out and then read the result to see whether they held.
A count that only goes down
The same commit added a ratchet, a test that counts raw color literals in the source and fails if the number rises. The count was 219 literals in 43 files when it landed and 62 in 27 files after the migration it describes. A ratchet suits this work because it encodes a direction without demanding a finished state: nobody has to fix everything today, and nobody can add to the pile either. The repo has 107 test files under src, and the ones that matter most are the few that hold a design decision in place.
The rules around the system
The written rules protect the same ground. Icons come from a single registry in src/icons, portals mount to the app shell's portal roots instead of document.body, and Radix internals get no !important overrides. Each one sits at a place where a system comes apart one reasonable-looking change at a time, and a designer sees that kind of drift in a screenshot long before an engineer sees it in a diff. The reuse rule that sits at the top of that file has its own history, told in writing the CLAUDE.md for a design system.
What to ask for
When you hire for this role, ask the candidate for the three rules they would write for an agent working in your product and the check that would fail if the agent broke each one, because the answer shows whether they know where your product comes apart and how they would find out. The same question works on a ladder: if the senior row never mentions writing the checks, it rewards the output that agents now produce for free. The hiring side of this is in how to hire a designer when you're not sure what you need, and the older version of the handoff problem is in the design-to-engineering handoff is broken.
Be the first to rate this article.
Let's work together.
Open to select projects and collaborations — design systems, accessibility, and AI-native product work.