I don't hand off designs anymore. I ship PRs
A year ago I couldn't open a terminal. Today I design inside production codebases, and the fence I thought stood between design and code turned out to be about tools, not about careers.
Arely Rivera3 min read

A year ago, I didn't even know how to open a terminal properly.
I knew GitHub existed and I technically had an account, but words like branches, worktrees, or pull requests felt like a completely different career reserved strictly for engineers.
Today, I design directly inside production codebases. I open PRs, inspect CI pipelines, and build interfaces in code. And soon, I'll be speaking at Rails World about how we built a framework for AI to generate UI directly from design systems inside a repository.
All of this changed in under 12 months.
I didn't switch professions. I'm still a Product Designer.
What changed is that I stopped believing design ends where the code begins.
The handoff trap
For years, my workflow followed an unquestioned routine: research, wireframe, design components in Figma, document edge cases, and hand it off.
Once the link was sent, my job was technically "done". But in reality, I was fully dependent on someone else to translate static mockups into what users would actually experience.
If something lived outside Figma, I assumed it wasn't my territory:
- GitHub? Developer stuff.
- The terminal? Absolutely not.
- The codebase? Why would I even open it?
I thought learning code meant pausing my design career to become a full-stack engineer. I didn't want to be mediocre at two professions, so I stayed safely on my side of the fence.
Then AI erased the fence entirely.
From fear to a 7,000-line pull request
My first steps weren't sophisticated. I wasn't orchestrating complex agents; I was pasting ChatGPT output into Claude Code, breaking local setups, and asking senior engineers endless basic questions.
Then came my first real PR: over 7,000 lines of code changes.
I was terrified of breaking production. But pushing that PR unlocked something fundamental: it led directly to creating the Onion Design Framework—a methodology we designed to give LLMs structured context to build UI directly inside a codebase.
AI didn't turn me into a backend engineer. It gave me the leverage to design in the real medium.
Static pixels lie. The browser tells the truth
Designing directly in code ruined traditional mockups for me. Here's why:
- Designing a system vs. pictures of a system: Updating dozens of Figma frames after a layout change is painful manual labor. In code, a systemic rule updates the whole product instantly.
- The browser exposes reality: Prototypes simulate experiences, but the browser is the experience. Real responsiveness, layout shifts, edge cases, and awkward transitions only surface when you touch the actual medium.
Handoff is no longer a game of visual telephone—it's co-creation on the exact same artifact.
(And for stakeholders who don't read PRs? We use AI to automatically generate lightweight HTML handoff previews with visual diffs and documentation, keeping communication seamless without duplicating design work.)
AI didn't take my job. It moved the bottleneck
Stepping into the codebase didn't make me fear AI replacing designers. It did the opposite: it highlighted where human judgment actually lives.
An AI agent can dump thousands of lines of UI code in seconds. But it lacks:
- Taste
- Context
- Business constraints
- User empathy
When software production becomes trivial, the bottleneck shifts from producing pixels to strategic judgment—deciding what actually deserves to be built.
I still use Figma and FigJam every day for quick exploration and visual brainstorming. But I no longer treat it as the final destination of my design work.
If I could speak to my past self, I wouldn't tell her to become a developer. I would tell her to stop letting unfamiliar tools define the boundaries of her craft.
I didn't become a developer.
I expanded where I can design.
Found this useful? Pass it on.


