AI Design Engineering: Design, Build, Test and Ship With AI
I create products and ship them using Claude Code. This is my real process, Design, Build, Test and Ship, what AI does in each step, what it does not, and why proof became the scarce part of the job.


I'm Gus, an AI Design Engineer at Arena, and I live in San Jose. My job is to design products and build them for real, with AI agents writing the code. At Arena I create audience engagement projects used by ESPN, Reuters, FOX and other big companies. I build them in React and Next.js and push the code to the Git repository myself. Engineering reviews it and, in most cases, takes it to production. On my own products, like Black Eagle, 2GRW, myCFO, trpFit and GSL Game Zone, I go the whole way, from the first frame in Figma to the deploy.
My days look nothing like the work I was doing two years ago. I open a terminal before I open Figma. A Mac Studio on my desk runs every project I have open, and I talk to it through Claude Code from my MacBook or my iPhone, wherever I am. I describe what I want in plain words, an agent builds it, and I spend the rest of the time on the part that never got automated: deciding whether it is right.
Holding all of that together is GJAI (Jammes), my personal agent. It watches every agent I have running, takes tasks from my phone and answers when I call it by voice. It is the biggest thing I have built for myself, so it gets its own section below.
People ask me if AI made me faster. It did, and that matters. But speed is not the biggest change. The biggest change is where the hard part of the work lives. Producing a screen, a component or a whole feature got cheap. Knowing that it actually works did not. Every piece of work I do moves through the same four steps, Design, Build, Test and Ship, even though no two days look alike, and the more AI does inside each step, the more my job becomes the proof between them.
AI executes. I verify.
What AI design engineering is
AI Design Engineering is creating a product end to end and delivering it working, in code. AI agents write most of that code, and the designer owns the decisions and the proof that it works. Instead of handing a picture of the product to someone else to build, an AI design engineer designs, builds, tests and ships the real thing, then watches how people use it and decides what changes next.
It is not a niche way of working anymore. In the UX Tools State of Prototyping survey of designers and builders, run in the spring of 2026, 43.8% said they spend more than half their building time vibe coding, which is the industry's name for building by describing what you want to an AI.
of designers and builders spend more than half their building time vibe coding, building by describing what they want to an AI
GJAI, the personal agent behind my work
GJAI stands for Gus plus Jammes AI. Jammes is the agent I work with every day, the same one I built Black Eagle with, and GJAI is his cockpit. I designed it and built it myself, with agents writing the code, and it grew into the biggest thing I have made for myself. Every Claude Code session I start, on either Mac, personal or Arena, reports to it on its own, so one screen shows what every agent is doing right now, in which project, and whether it is waiting for me.
From there it became a way to work without being at the desk. Since July I can write a task on my phone. It goes into a queue, a service on the Mac Studio picks it up, runs Claude Code inside the right project and reports back, and a follow up continues the same session instead of starting from zero. I can also call Jammes by voice. He tells me what is running, sends new work to the agents and searches my notes for the decision behind a project. Right now I am teaching him to read my calendar, email and Slack, read only for now. Behind that one screen, 13 services run around the clock on the Studio.
GJAI also taught me the rule I trust most. For weeks the map looked busy with sessions that never happened. A health check that ran every five minutes was being recorded as a session, and when I finally measured it, 98% of the history was noise. Since then GJAI has one rule it never breaks: every number on the screen has to trace back to something that really happened, or it does not show at all. That rule did not stay inside GJAI. It is how I build every dashboard now.
Design: deciding what good looks like
Design still starts with a decision, and AI does not make that one for me. Sometimes the decision happens in Figma, when I need to see a shape before I commit to it. More often now it happens straight in code, because only a running screen shows me the states a static frame hides: the loading, the empty list, the error, the slow phone, the name that is too long for the space I gave it.
At Arena a task often arrives as one line and a short video. So my first design step is reading the code that is already in production, to understand what the screen really does today before I propose what it should do tomorrow. Then I check what data actually exists. If a number cannot be fetched, the design does not show it. A beautiful dashboard full of invented numbers is the most expensive mockup there is, because everyone believes it.
The habit that changed my design work the most is a file. Every interface heavy project I work on has a DESIGN.md that the agent reads before it touches any screen. It does not repeat the colors or the type scale, those live in the code. It holds the decisions the code cannot say, and its most valuable section is the list of things we never do. No scale effect when you hover a button. No focus ring on an input. No invented data. Every line on that list exists because something went wrong once.
Build: agents write the code, I write the rules
I build with Claude Code, and I do not use one model for everything. Opus runs my sessions and does most of the building. Fable, the most capable model, is pinned on the agents that handle design calls, architecture, code review and hard debugging, where the extra quality pays for itself. A small router also reads every request I write and scores which model it needs. Since October 10 it has scored 1,567 of them: 55% Opus, 29% Haiku, the fast and cheap one, and 16% Fable. Quality where it counts, budget everywhere else.
The part nobody sees is the rules. I have 19 rule files that every session reads before it starts, and about half of them carry the date of the thing that went wrong. Every new database table refuses anonymous access from the moment it is created, because an open table looks exactly like a closed one until somebody checks from the outside. Every text field on mobile uses at least a 16 pixel font, because iPhone zooms the whole page when you tap a smaller one. The native scrollbar is hidden everywhere, because Windows paints a thick white bar across a dark interface that nobody working on a Mac ever sees. How those rules get written is a story I told in Everyone Is Now a Manager of Agents.
The research on this stage is honest about what you are signing up for. Faros AI looked at telemetry from more than 10,000 developers and found that teams with high AI adoption merge 98% more pull requests. The same report found pull requests 154% larger, review time nearly doubled and 9% more bugs per developer. That is the build stage in four numbers. The output went up, and so did the amount of work someone has to read carefully. In my work, that someone is me.
more pull requests merged on teams with high AI adoption, while pull requests got 154% larger and review time nearly doubled
Test: green checks are not proof
This is the step where AI changed my job the most, and not in the direction people expect. A typecheck can pass, a production build can succeed and the console can stay silent while the page is broken on someone's screen. I have watched all three agree with each other while the page in my browser was throwing an error. Green tooling tells you the code compiles. It does not tell you the product works.
So I test the way a user meets the product. I open the real page in a real browser, often driven by Playwright, and I look at it, on a production build and not only on the development server. On one site, six section headings showed only half of their sentence, which looked like the worst kind of bug on a live page. It only happened in development. In production every heading was whole. The fix I had written for it shipped, broke the development build and changed nothing, and I reverted it the same day. When I build anything that stores data, I attack it from outside the way a stranger would, and the only answer I accept is permission denied. An empty list is not proof that a table is safe. It only means nobody asked the right way yet.
And I test on a real phone, because no simulator reproduces an app installed on an iPhone. I once spent four rounds on myCFO with the app cut off at the bottom of an installed iPhone. Each fix looked correct in the code. The cause was a single line I had added on purpose, to make the app fill the whole screen. Removing it fixed everything, because the phone handles that space better than any code I could write for it. No automated check would have found that, because nothing was technically wrong.
The surveys say most people know they should do this and many do not. In Sonar's 2026 State of Code survey of more than 1,100 developers, 96% said they do not fully trust that AI generated code is functionally correct, yet only 48% always check it before committing. Accessibility shows the same gap. When Microsoft tested eight leading models on common interface components with no accessibility instructions, only 12% of the results passed every check. With a dedicated accessibility skill written for the model, nearly seven times as many passed. Writing the standard down where the agent has to read it is most of the fix.
of developers always check AI generated code before committing it, while 96% say they do not fully trust it is correct
of AI generated interface components passed every automated accessibility check with no instructions. A dedicated accessibility skill raised that nearly sevenfold
Ship: small, reversible, then measured
On my own products, shipping is boring on purpose. Small changes go straight to production. Bigger or riskier ones get their own branch, which builds a preview at its own address, and that preview is my staging environment. Every commit holds one intent, so any change can be undone without taking another one with it. After the deploy I open the live page myself. A green deploy is a claim, not a result. At Arena it works the same way: I push the code to a branch with its own preview, engineering reviews it and, in most cases, takes it to production.
Shipping is also where the process starts to measure itself. I built a private dashboard that puts Google Analytics, Search Console, session recordings and the AI assistants reading my site in one place. It already corrected me once. A visit that showed twenty minutes on the site turned out to have four minutes and forty one seconds of real use. The rest was a tab left open. Now the dashboard shows time in use, not time open, because a number with the wrong label is worse than no number at all.
Developers seem to be landing in the same place. In the Stack Overflow 2026 Developer Survey, the single most common answer about trusting AI was not yes or no. It was that they trust it when they can easily verify the output. Verification is not a tax on AI work. It is the condition for trusting it.
Back to Design: why this post exists
This post is the process running on itself. A few days ago my dashboard showed that a dozen searches about AI and product design, things like ai product designer and product design with ai, were landing on one older post of mine, a short personal essay from June about changing my title. Google was testing it for questions it was never written to answer, and it sat between positions 40 and 60, pages four to six of the results.
So I went back to Design. The decision was to write the page those searches deserve, about how the work is actually done. The build is what you are reading. The test was reading it on a real page before anyone else could. And in a few weeks the same dashboard will tell me whether it worked, which is where the next round of Design starts.
What stays human
AI writes all of my code, and I verify that everything works the way I planned it. It does not decide what a product should feel like. It does not notice that the bottom of the screen is wrong on a real phone. It does not know that the number on a dashboard is measuring an open tab. Those are the parts I kept, and they turned out to be the job. If you want the story of how I got here, I wrote it in From Product Designer to AI Design Engineer, and what the role looks like across the Bay Area in How Bay Area Product Designers Actually Work With AI. The tools changed. The responsibility for what ships did not. AI executes. I verify.