We Gave an AI 32,000 Tokens and It Still Couldn't Build Five Working Screens :

The Setup

LYFYE Builder generates working, multi-view software prototypes from a plain-language brief — real markup, real styling, real wired-up behavior, produced in one browser session. The obvious architecture is the one everybody starts with: one generation call that writes the whole document. Models are fluent in HTML, CSS, and JavaScript; the demos everyone has seen produce impressive single pages. So we set a hard product bar — the output must be operable, every advertised view reachable, every control wired — put a quality gate in front of shipping anything, and pointed the single-call architecture at a two-surface, eight-view prototype with a 32,000-token output ceiling.

The First Wall: Truncation Eats the End, and the End Is the Behavior

It did not fit. And the way it failed matters more than the fact that it failed: generation stopped at the ceiling with nine of ten views built and wired — and the tenth view plus the entire behavior script missing. In an HTML document, the script lives at the end, and the end is what truncation takes. The result looked substantially complete and was operably dead. We tightened the scope to a bounded five-view slice and verified the model was asked for only those five. It still stopped at the ceiling before the behavior was wired. That was the first real lesson: an output ceiling is not a prompt problem, and 'ask for less' has a floor. Below some size, the thing you are asking for is no longer the product.

The Seductive Fix That Made It Worse

The diagnosis suggested an elegant fix: if truncation always eats the end, put the important part first. Write the behavior script in the head, as one delegated listener, so no amount of truncation can remove it. We shipped that directive and ran the same benchmark once. Before the change: 46,603 characters generated, with the tail lost. After: 33,274 characters — the generator spent its budget on the head block and truncated before emitting any markup at all. Both surfaces and all eight views were simply absent. Reordering does not create capacity; it only chooses which end of the document truncation destroys, and losing the markup is worse than losing the script. We reverted the same day, with the numbers in the commit message. That was the second lesson, and it generalizes: within a fixed ceiling, prompt cleverness rearranges the failure. It does not remove it.

What Actually Worked: Partition, Don't Push

The fix that held was architectural. Instead of one call writing everything, the plan is split deterministically — simple arithmetic over the already-decided solution structure, deliberately not another model call — into modules of at most three views each, grouped so a split lands between workflow steps rather than through one. Each module gets its own bounded 16,000-token call, writes CSS scoped to its own namespace so it cannot restyle its sibling, and the first module returns the shared design foundation that the second receives by reference. On the custom-software benchmark this passed cleanly, with room to spare:

• Module one: 9,563 output tokens used — 6,437 tokens of headroom under its ceiling. Complete, validated.
• Module two: 11,296 output tokens used — 4,704 of headroom. Complete, validated.
• Assembled artifact: 49,210 characters, 21 declared actions, 42 bound interactive elements, quality and operability gates passed, and a user journey traversable across both surfaces.

The Boundary That Stopped Us: Five Screens That Didn't Fit

Then we pointed the same architecture at a mobile-first product: a parent-facing app with four screens plus a one-screen school console — five screens, 32,000 tokens of total output budget across the two module calls. The four-screen mobile module spent its entire 16,000-token budget and hit the ceiling, truncated. The retry produced a complete response that failed schema validation. The second module never ran. A four-screen module did not fit the same budget that three-view modules had passed with thousands of tokens to spare — and the retry failing validation showed a system straining at a boundary, not a transient hiccup. This was not a bug to fix; it was a genuine capacity-versus-partition boundary, and pretending otherwise would have meant either shipping truncated software or quietly raising ceilings, which is a spend decision, not an engineering reflex.

The Discipline Underneath: Gates That Can Say No

The reason we can tell this story with numbers is the part we would recommend to anyone before any of the architecture: instrumentation and gates that refuse to flatter. Our pipeline records whether generation stopped at the ceiling, and truncated output is failed before any other verdict — a truncated response that happens to parse can never slip through as success. Failed attempts record structured diagnostics (which views were missing, whether the script arrived) rather than a generic error. And when the evidence said the mobile rail wasn't ready, the honest move was to freeze it — preserve the benchmark record, stop investing, and let real commercial demand decide whether completing that rail is the next priority. A validation gate that cannot say no is decoration. Ours said no, and that is why the passing benchmark means something.

What This Means If You're Evaluating AI Code Generation

Whether you are building a generation product or buying one, the same questions separate honest systems from lucky demos:

• Ask what happens at the output ceiling. Every model has one. If the answer is 'we haven't hit it,' the system hasn't generated anything big enough to matter yet.
• Ask whether validation can reject truncated or malformed output — and whether it ever has. A gate that has never failed anything is not evidence of quality.
• Distrust extrapolation from single-page demos. In our runs, a four-screen module exhausted the exact budget that three-view modules passed with headroom. Impressive small outputs say little about complete products.
• Prefer architectures that partition work into bounded, verifiable units over prompts that ask one call to do everything. Capacity problems are solved by structure, not phrasing.
• Watch for measured headroom. Teams that can tell you their tokens-of-margin per generation are managing the constraint. Teams that can't are meeting it in production.