Oct 19, 2026 | Estimated read time: 9min

Ship Production Code Only If Dev Is the Bottleneck

Designers should not treat shipping production code as a default next skill. The useful question is whether engineering is still the bottleneck — and whether the specific project is faster and more faithful in code than in Figma.

Design scope is widening; coding is an asset on a product-builder path, almost unused if PM and design merge and tech stays separate.
If developers already go about twice as fast and product cannot feed them, shipping code adds capacity nobody needs.
If engineering is still the funnel, start with better specs, QA, and tiny interface fixes before you take on features.
Code beats Figma for small existing-UI iterations, motion, business-rule-heavy work, and throwaway concept prototypes.
Keep Figma for large visual projects, and stop drawing every edge-case screen when specs plus agents can carry the variations.

Should designers push code to production — to polish an interface, fix a bug, or ship a full feature? I have always worked close to development, so the question is not new. AI agents made it louder. The answer is not a personality trait and not a 2026 identity. It hangs on three things: where the craft is going, which problem your company has right now, and whether this specific project is a job for Figma or for shipping production code.

Shipping Production Code Starts With Where the Craft Is Going

The designer’s scope is going to widen. Whether that makes coding valuable depends on whether we become product builders or PM-designers sitting next to a dedicated tech team.

Agents make access to data, research, benchmarking, and competitive analysis easier. Production itself is a bit easier too, though that is not yet where we save the most time. Review and QA get faster. The net effect is the capacity to produce more quickly, and that capacity has to go somewhere: either we produce better, or we go more vertical. Designers become more end-to-end owners of their scope — because of these tools, or thanks to them, depending on your mood. Less time is lost on production work itself. More of it lands in thinking and in structuring the product.

That expansion can take two very different shapes.

The first is that we become product builders end to end: discovery as a PM would do it today, design as we do it today, and production — actual development. Designers, PMs, and developers could all stretch onto those scopes. Roles would get more vertical than they are now.

The second is that we keep a product side and a tech side. Designers would not put their hands in the code, or at least not more than they already do. PM and designer would keep merging, for the same reason: research and the rest of the work those two roles share is getting closer and faster. Two separate seats make less sense. You would rather have more PM-designers doing both, and keep dedicated engineering teams.

I do not have a take on which direction wins. It will depend on a lot of criteria. The consequence for this question is narrower. If you see the craft moving toward product builders, the ability to develop is an asset. If you see it moving toward a PM-designer merge with tech remaining a separate team, that same skill is close to unused. Before you invest in development, ask where you think the job is going — and in which version of that future you actually want to work.

Who Is the Bottleneck Decides If You Ship Production Code

Look at your company first: if engineering is no longer the bottleneck, shipping production code adds capacity you do not need.

The future is a bet. The company’s current problem is not. I see two very different setups, and they imply opposite moves.

When product is already the bottleneck

In the first setup, developers have absorbed AI tools in a concrete way and production has accelerated hard. In my current company, developers genuinely go about twice as fast. We used to be blocked by tech: engineering could not keep up. Now product teams are the bottleneck. Developers have bandwidth. We cannot feed them, because they move too fast. Product managers and product designers have not accelerated enough to hold that pace.

The job is to keep the quality of product decisions while speeding up delivery, so that engineering capacity is not wasted. In that context I do not see the point of designers or PMs deciding to put their hands in the code and push it to production. You would be adding development capacity in an environment that no longer needs it. That is the first criterion, and it is the one that matters most.

When engineering is still the bottleneck

In the second setup, developers remain the bottleneck, whether they adopted the new tools or not. You keep producing more on the product side than engineering can absorb. The funnel is blocked there. Then it is worth asking whether you, as a designer, can climb onto development to accelerate the system. That is not only writing features. You can help developers raise their pace with the tools you already use. You can work on automating specs, and on making those specs more qualitative — with agents, a strong spec is a very fast build. You can improve QA. Or you can put your hands in the code gradually.

If you have never done it, start small:

Simple interface design fixes, to learn the tools and the process
Then small bug fixes
Then mini-features and small iterations
Over a longer horizon, new features

The larger the company, the more the real blocker is access to the codebase itself. If the organization is cautious, do not show up heavy-handed. Build a relationship with the people who own the code. Run a small, closed experiment with them — almost private — to test the work, to see which processes make it safe for designers or PMs to touch production, and to grow trust. Once that relationship exists and you have a few proofs of concept on small projects, you can open it up and generalize.

If you are still short on engineering capacity, look at how you can help that side move faster. Putting your hands in the code can be one of those ways. If developers are no longer the bottleneck, they do not need you there.

Who is the bottleneck?

Product is the bottleneck

Engineering is the bottleneck

Quick check

If developers already go about twice as fast and product cannot feed them, should designers ship production code to add engineering capacity?

When engineering is no longer the bottleneck, the job is to keep product-decision quality while accelerating delivery. Shipping production code would add capacity on the side that already has it.

When Code Prototyping Beats Figma

Even when product is the bottleneck, code is often the faster, more faithful prototype — and the one a developer can review and ship.

That company-level rule is not true for every project. I sit in the first category: developers move fast, product cannot follow. Figma is still my main working tool. Its biggest flaw is that it is not always the best prototyping tool — not the most faithful, or not the fastest.

Small iterations, motion, and business rules

Small iterations on something that already exists are a standing example. Finding the right mocks is hard. You recreate them, or you re-import them, and you end up with a messy file. Working in the code gives you production itself, which is the most realistic artifact you have. For a small adjustment on existing UI, it is often faster to iterate there. Code is a more efficient prototyping medium than Figma. The prototype is frequently almost shippable, with a developer review behind it.

Animation and small interaction details are the same pattern. Describing timings, and the delay after which something returns to state A or moves to state B, is still difficult to put into Figma and into a spec. It creates QA back-and-forth. Animation is frontend. There is not much risk of breaking anything else. It is often faster to change it in the code, share the prototype directly, and potentially push that same code to production — instead of building a complex Figma prototype and then losing fidelity when a developer translates it.

The third case is a project with very little UI and a lot of business rules to test. I recently worked on a picker: several values inside it, pushed dynamically from a pile of parameters. Prototyping that in Figma has no interest. Representing every scenario is complicated and tedious. I iterated on the existing component in code, put the business rules in place, and tested them live. That also made it simpler to share with real users. For production, a developer checked what had been done, fixed a few performance and code-quality details, and shipped it quickly. Anything that needs many case variations, or that is hyper-straightforward in code, now costs more in Figma than in the codebase — and the code is easier to transfer into production.

High-level concepts, and what still belongs in Figma

High-level concepts sit on another shelf: demonstrating that an idea is feasible, or presenting a concept. Code-based prototyping tools help here. Lovable is built for that. So are Claude Artifacts, which let you create mini websites directly in Claude or directly in the codebase. I do this more and more: open a local-only branch, keep the backend as it is, and change the interface enough to show a possible concept. That is often simpler than doing it in Figma. For all of these cases, whatever company you are in, it is worth checking whether you get better results faster in code than in traditional design tools.

Figma or the codebase?

Figma

Code

I currently work in a scale-up of about forty people. Before that I was at AB Tasty, a company of around 250. In the smaller team, developers move very fast and product cannot follow, so I push code to production only exceptionally — the animation fixes and the business-rule projects above. I prototype in code, clean up the changes, send them for a developer’s review, and they often ship with very few modifications. I also use code regularly for concept prototypes. That code is disposable. It will never go to production.

Most of my large projects still start in Figma. It remains a hyper-flexible, hyper-fast way to demonstrate a lot of concepts visually. What I am trying to do less is an exhaustive Figma file that covers every edge case. I would rather reserve the file for specs and annotations. Developers can handle variations much more easily, and much more autonomously, than they could a few years ago. Our value is less and less in the fifteen cases of the same screen. It is in anticipating those variations, and in building a global system. With good specifications, the team can move faster without me spending my time drawing every variant.

Final Thoughts

Shipping production code is not a badge and not a duty. It is a response to a constraint. If engineering cannot keep up, help it — with specs, with QA, and sometimes with your hands in the repo. If product is the slow side, do not volunteer as extra engineering. Use code where it is the better prototype, keep Figma where it is still the faster visual argument, and spend the time you used to burn on edge-case screens on the system those screens were trying to describe.

FAQs

Should product designers ship production code in 2026?

Only if it matches the constraint. If engineering is still the bottleneck, helping in the code can accelerate delivery. If developers already go much faster and product cannot feed them, shipping production code adds capacity the company does not need.

When is code a better prototyping tool than Figma?

On small iterations of existing UI, on animation and interaction details, on projects with little visual work and many business rules, and on high-level concepts you can sketch in Lovable, Claude Artifacts, or a local-only branch.

How should a designer start putting their hands in the code?

Begin with simple interface design fixes, then small bug fixes, then mini-features and small iterations. In a cautious or large company, first build trust with the people who own the codebase and run a small closed experiment before you generalize.

Does a wider designer scope mean everyone must become a developer?

No. Scope is widening either toward end-to-end product builders or toward PM-designers next to dedicated tech teams. Coding is an asset on the first path and close to unused on the second.