During the development of my project, the assistant has repeatedly failed to maintain consistency with a locked design system (Saira Medium font, specific hex codes, and fixed component dimensions). Despite clear instructions that the top and bottom navigation bars are “locked/unmodifiable,” the system continues to hallucinate or default to internal presets (like Lexend font or non-compliant spacing) instead of performing a literal code transfer.
The core issues identified are:
Instruction Hierarchy Failure: Technical defaults in the model’s architecture appear to override explicit document-based constraints.
Visual Hallucinations: The assistant reports that it is following specific rules while the generated HTML source and visual output show otherwise.
Loss of Rigor: Even after identifying the errors, the system is unable to bypass its “optimization” logic to ensure character-for-character consistency in structural components.
This seems to be a systemic limitation in how the architecture validates and prioritizes user-defined rules versus pre-trained design patterns. Any insights from the development team on how to force strict adherence to design documentation would be appreciated.
Have you tried adding the Do’s and Don’ts section to DESIGN.md? It’s in the spec bug Stitch does not add it.
Also, consider an alternative approach. Working on parts instead of the whole. I’ve given a basic outline here.
Thank you for the response. We’ve already implemented the Do’s and Don’ts section in DESIGN.md — it hasn’t changed Stitch’s behavior. The system continues to override the defined tokens regardless.
Regarding working in parts: we’ve evaluated that approach and it actually increases inconsistency. Each individual generation is a new opportunity for Stitch to reinterpret or override the design system, which multiplies the failure points rather than reducing them.
The root issue remains: Stitch’s internal pipeline actively overwrites user-defined tokens with its own Material Design palette, even when those exact tokens are explicitly defined in the DESIGN.md. This has been confirmed by manually editing the YAML values and observing Stitch restore them to its own defaults.
A full-screen generation with strict token adherence would be far more reliable than a parts-based approach. Is there any way to force the pipeline to treat DESIGN.md as the absolute source of truth?
I agree with pepe_guillen’s explanation.
I’ve been trying to develop an Android application for a couple of weeks now.
Every time I iterate to modify some aspect of a screen, Stitch reverts to its “standard guidelines.” In my case, I can’t prevent blurring/antialiasing.
Even specifying that it shouldn’t change anything that hasn’t been requested still prevents its modifications.
I asked Stitch if there was any way to avoid these “guidelines,” but it said there wasn’t. It gave me alternatives like “literal copy of the screen’s HTML,” “Use the code from SCREEN_XXX as the literal base,” etc. None of these commands ever worked.
It’s really frustrating and wastes a huge amount of time to constantly specify very specific things only to have it either not implement them or display them however it wants.
I apologize if this isn’t clear; I’m using Google Translate (Spanish/English).