I've worked closely with engineers for years, so I've always understood the product side of shipping. I knew how features moved from idea to release, how teams worked together, and where quality could slip.
What I hadn't done myself was actually take something through the implementation workflow inside a real enterprise codebase: setting up a dev environment, working in a repo, opening a PR, and getting it merged.
This started from a pretty familiar frustration.
Sometimes a feature launches looking polished, but a few weeks later I notice a small UI issue that starts bothering me every time I see it. Usually, I write a ticket, hand it off to engineering, and it gets picked up when the team has time. That makes sense. There are always bigger priorities.
But tools like Claude Code started to change that equation.
I had already been experimenting with AI-assisted coding in my personal time, including building this website, so I wanted to see how far I could take that in a real product environment at Clio. After some collaboration with my team, I got my local dev environment set up so I could safely work in the codebase without breaking anything. A lot of the tooling and terminology I'd heard for years finally clicked once I had to move through it myself.
Choosing a first PR
For my first PR, I picked a simple UI copy fix.
At Clio, we have products called Clio Grow and Clio Manage. In some parts of the UI, they were still being referred to more casually as just "Grow" or "Manage." It's a small detail, but product naming consistency matters, especially as the suite evolves.
So I used Claude Code to help find the relevant files and make the updates.
What was actually interesting
The interesting part wasn't really the code change itself. It was everything around it.
Getting something shipped in an enterprise codebase means working through a lot more than just the fix: local setup, repo workflow, PR creation, automated checks, debugging, reviews, and all the little points where something can go wrong.
Claude helped me through that process, but I still had to do the important parts: define the problem clearly, review the changes carefully, QA the output, and respond to feedback from engineers. It was real collaboration with AI as a tool, without outsourcing my judgment.
An hour or so later, I had two reviews, some feedback, some more debugging, and finally… I was ready to merge my first PR.
I was so incredibly pumped by that breakthrough. It genuinely felt like I had just discovered the internet.
What changed for me
Before, I would spot a UI issue and write a detailed ticket. Now, for certain front-end and product polish issues, I can often go from identifying the problem to helping ship the fix directly. In some cases, that now takes me about as long as it used to take just to write the ticket.
That's what excites me most about AI-assisted building.
Not that designers need to become engineers, and not that AI removes the need for technical review. It doesn't. But it does expand what a designer can responsibly own. It creates a much smaller gap between noticing a problem and getting it fixed.
For me, shipping this PR was less about "learning to code" and more about learning how to close that gap faster.
P.S. I'm looking forward to reading this again in six months, when all of this already feels outdated.