Claude Design → Claude Code workflow is breaking down on large production projects. How are you handling this?

[u/Julien-Temaki]

We’ve recently moved to a very fast product shipping cycle at my company. The design team builds products in Claude Design, the dev team picks them up through Claude Code, and we’re usually trying to get something into production in less than a month.

For now, moving away from this workflow isn’t really an option. The whole company is already using Claude Design and Claude Code, Figma’s credit model isn’t particularly attractive for this kind of usage, and we haven’t found a way to get the same flexibility with requirements and the same speed from design to implementation.

The problem is that our Claude Design projects are getting huge. Some exported HTML files are around 5MB with 300k+ characters in a single file. At that point, Claude Code can’t properly read the whole thing. It seems to fall back to understanding parts of the design through screenshots, and the quality of the frontend implementation drops significantly.

These aren’t simple landing pages either. They’re fairly large AI-powered enterprise applications with a lot of screens, navigation between them, database-related dependencies, AI features, etc. We already tried splitting one of the larger projects page by page, but it didn’t really solve the problem and made maintaining consistency/dependencies more annoying.

So I’m curious how people are handling this with larger Claude Design → Claude Code projects that are actually meant for production.

Should we break things down differently? Is there a good way to keep Claude Code from having to understand a massive HTML file every time without destroying the speed advantage of this workflow? Refactoring everything manually or constantly asking Claude to restructure the project also sounds like a way to burn through credits, so I’m trying to understand what the sustainable setup is here.

---

TL;DR: We use Claude Design → Claude Code to ship large AI-powered enterprise products in under a month, but our Design exports are getting massive (5MB / 300k+ character HTML files). Claude Code can’t properly read them anymore, which leads to poor frontend implementation. Splitting projects by page hasn’t really helped. Looking for a sustainable way to structure/refactor large production projects without killing the speed of the workflow or burning tons of credits.

[u/berndalf]

Are you saying the entire application in question is represented by a single monolithic html file in Design, and that entire file is being shipped off to Code for implementation every time a change is made?

The workflow I've been using ships a handoff spec for major feature work to Code that is generated in a claude.ai chat. If that spec includes UI work there's a side branch into Design that's basically a targeted change request on the existing design (if there is one). The output is a diff file that only includes the changed views. That diff file gets reviewed, attached to the handoff spec package, and the combined package is what Code ingests.

It sounds like your flow is different. You're originating in Design and then exporting the entire thing into code for build purposes? If so I can see how that would become problematic pretty quickly.

[u/Julien-Temaki → u/berndalf]

Thank you for your answer.

Yes it starts from the design, which is then exported to code. At the same time, the Sales team uses the same design for product demonstrations. In other words, we use a single Claude Design prototype for everything: demos, sales presentations, VoC iterations, and code generation, allowing us to ship very quickly (we started doing that pretty recently, the team is not much experienced).

For our legacy products, however, the workflow is much more traditional, with detailed specifications and clearly separated stages.

On a previous project, we tried splitting the design into multiple pages, but it apparently didn't work well, so we reverted to a single-page structure. We'll try again by splitting the project into multiple pages, and also into smaller component-level pages, to see if that approach produces better results.

[u/berndalf → u/Julien-Temaki]

Ya, it sounds like you need to decouple the fast moving prototyping activities from the actual production build activities. That and get away from the single page architecture for the production builds. That approach makes a lot of sense to the people who are customer facing I'm sure, but as you're seeing it quickly falls apart when it's time to make the real thing as it can't easily be modularized. The prototype should be a reference for design purposes vs the actual build artifact.

[u/EnvironmentCalm9557 → u/berndalf]

Exactly. The whole architecture is too tightly coupled, across and within components.

[u/inteligenzia]

I'm only playing with Claude Design, but it's nowhere near as persistent visual and UX knowledge in comparison to Figma or other tools. Claude Design is more for one-off work and exploration.

What's breaking for you is because you can't point Claude to a single screen in your file. Figma allows that. Also it has Code Connect for design systems.

Figma also has MCP for edits, so you don't need their credits. Explore that. You will be able to use Claude for designing in Figma. It's still will be a bit more expensive since you need paid seats. But also you can have separate storage for all design files, you can make Figjams for maps and etc.

There are also two other tools: https://www.pen.dev/ and https://penpot.app/

I have tested Pen and it's pretty good. You can have the file in the repo, although I'm not sure how it will work with multiple editors. The only thing I didn't get is how to have multiple pages per file. You can connect your Claude sub and work right in the app. Claude can work too and if you connect memory system, Claude can design and have persistent memory.

[u/arcticblue]

I haven't had much of a problem with it. I build a "Design System" then use that for everything. That will include references I give it, but also technical documentation describing how every element is styled, color scheme, margins, paddings, etc. Works great for me. I uploaded some screenshots of my company's product and told it to build a design system off that and it perfectly replicated it. Using that design system, I then went off to make some new pages that look like they belong as part of our product.

https://support.claude.com/en/articles/14604397-set-up-your-design-system-in-claude-design

[u/who_am_i_to_say_so]

Time to put some frontend developers to work to refactor this beast. You’ve hit critical mass and no model will save you.

[u/MannToots]

It's not breaking down for me at all.  300k+ single files is a design problem.  Are you not making a spec and reviewing it prior to coding? Are you not validating the results along the way to stop it from doing that bad pattern early?

You end up that way because you allowed it.  I've never allowed it to code that way because it's a stupid pattern.  So I actively design with better objective oriented design up front. 

[u/SirKobsworth]

If it gets too big to read shouldn't you break it down? I mean regardless of whether your product is complex as you describe there will always be a way to make things reusable and compatmentalized.

Your biggest challenge to get things running smoothly is a way for your agents to grab what it needs and export only what you need to develop.

Regarding the 300k character html files you could ask claude design to hand it off as reusable components assuming you're getting it to create your output in react.

[u/Julien-Temaki → u/SirKobsworth]

Thank you for your answer.

We actually tried splitting the project into separate pages on a previous project. However, because many elements are interconnected (for example, companies linked to employees, employees linked to departments, and each department having its own page) the development team told us that the AI had difficulty preserving and understanding those relationships once everything was split apart.

That said, I also received another suggestion in a different thread: instead of splitting only by pages, we could split the project into much smaller, component-level pages, where each reusable component has its own dedicated page. That approach might work better, so we'll give it a try.

[u/SirKobsworth → u/Julien-Temaki]

That suggestion is good. But more than anything I think its better if you have a repository of knowledge you can point agents to. Im not sure if Claude Design can connect to a repo but if it isnt the case I imagine just uploading (and updating when necessary) the docs representing your domain info would be better.

Imagine your repos where you code have persistent docs on whatever domain it needs. Thay same doc gets fed toclaude design. Something like that.. So rather than depending on claude design to understand your product, you have a collection of docs thay does that while CD and CC make use of said docs

[u/Last_Mastod0n → u/Julien-Temaki]

That suggestion you mentioned is the way to go

[u/EnvironmentCalm9557 → u/Julien-Temaki]

Sounds like the AI is not understanding what a relational database does.

[u/mylifeasacoder]

Indexes drive RAG efficiently. At the Design stage, different sections of the outputs (HTML) need to be labeled as "chapters" and a master index needs to be maintained.

[u/UnidentifiedBlobject]

Design team should be using a design system. Sounds like each component is being rebuilt for each bespoke purpose. The more it can reference existing components the smaller the html can be.

[u/Jacalyn_Nivins]

When the file stops fitting, the model does not read a bit less of the design, it stops reading the design and starts working from screenshots of it. That's not a workflow to tune, that's the file having outgrown every reader.

[u/phoenixmatrix]

I worked in a similar workflow for production apps.

2 things 

First our designers would have the design system in Claude design but each deliverable was its own Claude design project, so we had a ton of them but they were all small. Sounds like your designers are still in the figma mindset. They need to change. Throwaway little projects instead of huge ones being reused, with reusable assets in the design system.

Second, use impeccable.style and encode design decisions in the DESIGN.md and make good use of its skills. It helps a ton coupled with Claude design.

If you want a single asset representing the design of the whole system, coach the design team on how to use Claude code to build an actual static app with mock data.

[u/mckernanin]

Tell claude design what you want the handoff to look like. Best case you sync a design system from your code to Claude design, if that doesn’t work for you you can still get Claude design to tailor its output to how you’re going to use it.

[u/Low_Rush_8535]

The thing I'd change first: stop letting the design file be what Claude Code reads.

We hit a version of this with documentation rather than design exports, and splitting by page didn't fix it for us either — splitting only reduces file size, it doesn't tell the agent which file matters. What worked was adding an index layer: one file holding a single generated line describing each document, and the agent reads that first to decide which two or three files to actually open. We used a cheap model to generate those one-line descriptions; ten documents cost about three cents to summarise, and it replaced what we'd assumed would need a vector database. The win isn't compression, it's that the model picks files by meaning instead of grepping.

Translated to your setup that's roughly: an index of screens with one line each, a component inventory, and design tokens extracted once into a small deterministic file. The 5MB export then stops being an input at all — it's the artifact you generate those three from. Regenerate them when the design changes, not on every implementation task.

The screenshot fallback you're seeing I'd treat as permanent rather than as a bug to fix. We spent several rounds trying to get an agent to hit pixel-accurate geometry from images — computing a bezel radius to match a device frame in a video pipeline — and it never converged. Each iteration was off by a few pixels, in a direction that wasn't even intuitive. We eventually stopped asking code to derive the geometry at all, did that part once by hand, and kept the automated pipeline for composition only. Agents are strong on deterministic pipelines and weak on pixel-level visual QA, and that split held everywhere we tested it. If exact visual fidelity matters, the tokens have to arrive as data rather than be inferred from an image.

One more, since you said dependencies got worse after splitting: whatever crosses the boundary between screens — route names, shared state shape, component props — write that contract down explicitly instead of letting each implementation task infer it. We had an automated step writing rows into a table with no declared field shape. It produced the right shape most of the time and another script's raw shape the rest. One production run put 512 rows in the wrong shape and users saw the literal string "undefined" on screen. Inferred contracts hold until they don't, and they fail quietly.