Context
At Perforce, I am the product design lead for two products in the ecosystem: P4 DAM, an asset management platform, and P4 Plan, which is a bit like Jira but built for Perforce products.
P4 itself is a version control system, much like GitHub. Game studios typically use Perforce because it handles huge, enterprise-scale projects, then layer on tools like DAM and Plan. That is the world this work sits in.
Like a lot of companies in this new AI world, there were internal redundancies. Front-end capacity on my product dropped from six developers to two. That is a 66.67% cut. You would expect product delivery to fall by about the same. Instead, the product released 25% more features per quarter than the same quarter the year before, before I had joined the team and before any of this workflow existed. That number comes from my PM, and he says the quality held.
Figma handoffs were simply taking too long to implement with the two developers left. I knew I needed to change how I worked. At the time the company had granted a generous Claude Code allowance, and I decided I really needed to lean into it.
The strategy
Every feature still starts the same way, with a discovery pass I run with my PM: the problem, why now, how success will be measured, who the users are, the constraints, the timeline, and the risks. None of that changed. What changed was everything after it.
I installed P4 DAM locally and worked like a real developer on real product code. Pushing code to branches, getting code reviewed and working in the same ways and standards as the senior developers.
I still needed the same quality of handover Figma used to give. So I generated spec files, handover documents, and other outputs through skills and agents I built. Developers reviewed code that worked in some areas and did not work fully in others. I do not think anyone has fully cracked designing working code yet. Even so, clarification questions dropped by about 50% per feature. I measured that through refinement sessions: they went from about an hour to about 30 minutes, so I could cover roughly twice the features in the same time.
Despite working in code, I took full responsibility for the front-end features I owned. Developers reviewed the final output rather than reconstructing it from Figma. The process was faster, produced more features, and needed less rework than the workflow from six months earlier.
Proof point 1: Product execution
One of the features I released was realistic lighting in P4 DAM. I replaced the flat grey background in the asset viewer, the one that made 3D models look dull, with switchable image-based environments, so users and reviewers could judge shape, materials, and quality in realistic lighting.
It was not a hands-off job either. Claude generated lighting controls that compiled, but it ignored the existing Force UI tokens: the toggles looked right and were the wrong components. I rewrote that part by hand with the correct CSS so the developers got a clean handover, and I pushed the controls into the sidebar so the feature was actually visible rather than buried. That is the honest shape of this workflow. The AI covers the bulk, and I catch what it gets wrong.
Proof point 2: Process innovation
Shipping features myself was only half the job, so I turned the approach into reusable Claude skills and agents that generate the specs and handover notes. One of them won Best Designed at the company’s annual AI hackathon in 2026, and other teams across the business now use it.
The outcome
In the end, access to Claude Code became a functional delivery system. When the team shrank, output stayed high and went beyond what seemed possible: more features with less capacity, at a quality my PM stands behind.
