DEV Community: Zugo

Our AI builder said "done" when the output matched a regex

Zugo — Sun, 02 Aug 2026 07:04:40 +0000

We build Zugo, which turns one written sentence into a running game, site or app. For a while, the thing that decided whether a build had succeeded was this:

function htmlComplete(text) {
  return /<\/html>/i.test(text);
}

A closing tag. That was the gate. If the model emitted </html>, the turn was a success, the green tick appeared, and the credits were charged. Whether the page actually opened was not part of the decision, because at the moment we charged, nothing had mounted the document anywhere.

If you are building anything that generates code, this is the trap. Writing the file is easy to observe. Whether the file works is not, so it quietly stops being what "done" means.

Why a tag balance check does not save you

Our second-line check counted opening and closing tags. Its own header admitted what it was: a balance check, not "it renders." A document can be perfectly balanced, end in </html>, and throw on the first line of its first script. That build billed as a complete success.

Worse, the failure was invisible in exactly the way that costs the most trust: the tick went green the instant the stream finished, and the real answer arrived seconds later. Measured on our own paths, that gap is 2.6s for a site, 4.2s for a game and 6.2s for a React app, plus one silent re-mount if the first verdict is bad. So a broken build showed a green tick over a blank white frame for up to about twelve seconds. Long enough to read it as the product lying to you and close the tab.

You cannot watch the document from outside

The obvious fix is to wrap the preview in an error boundary and listen. That does not work here, and the reason is worth knowing if you sandbox generated code.

The preview frame is sandbox="allow-scripts" with no allow-same-origin. That gives it an opaque origin, which is the whole point: a generated document must not be able to reach the host app, its storage or its session. But the same wall means the host cannot see inside. A React error boundary around the preview catches nothing from the document. If a user ever sees our error boundary, the editor crashed, not their build.

So the listener has to live inside the frame, which means we inject it.

The harness, and the two details that make it work

We prepend a small script to the generated document that reports error, unhandledrejection and console.error back to the host via postMessage. Two details decide whether it is worth anything.

It has to be in <head>, ahead of everything the build wrote. Our first version appended the hook before </body>. A script that threw during load ran before any listener existed, so the loudest failures were exactly the ones nothing reported. The ordering is now pinned by a test that asserts the hook's index is lower than both </head> and any script the build placed in the body.

A console.error is not a failure. React logs ordinary development warnings through console.error, and "each child in a list should have a unique key" is not a broken app. So the harness reports it as a separate field:

var ce = console.error;
console.error = function () {
  rep({ logErr: [].map.call(arguments, s).join(" ").slice(0, 400) });
  return ce.apply(console, arguments);
};

Everything downstream that decides pass or fail checks if (d.logErr) return; before it counts anything. The warning is still recorded, it just never fails a healthy build. Collapsing these two into one channel is how you get a verifier that cries wolf until people stop reading it.

A verdict may get worse, never better

The last rule is the one I would keep if I had to throw the rest away. Verdicts only travel in one direction:

if (tn.files !== vFiles || (tn.rendered && (!tn.rendered.ok || v.ok))) return tn;

Once a build has been marked bad, no later signal is allowed to mark it good. A second render, a retry, a re-mount, an error that happens not to repeat: none of them can promote a failure back to a success. Combined with a 9 second window after mount during which errors still count, this closes the obvious escape hatch where a flaky build eventually reports clean and the user is told everything is fine.

And the green tick now waits. Between "the stream finished" and "the frame answered" the UI says it is checking whether the build opens. Neutral, not a claim. We would rather show uncertainty for three seconds than certainty that turns out to be wrong.

The general shape

The bug was not the regex. The regex was fine at what it did. The bug was letting the cheap observable stand in for the expensive one, because the expensive one arrives late and the cheap one is available right now.

Three questions worth asking about your own pipeline:

What does your success signal actually observe? Not what it is named after.
Does anything irreversible, like billing, happen before the real answer arrives?
Can a failure ever be promoted back to a success by a later, quieter signal?

If you want to watch the version with the harness in it, Zugo is free to try, and the templates are all real builds you can open and edit.

We published 1,360 blog posts in five days. Google indexed 69.

Zugo — Sun, 02 Aug 2026 06:37:53 +0000

We took a blog from 84 posts to 1,360 in five days, across six languages. The biggest single day was 515 posts. Google's verdict, measured in Search Console the morning after the last batch: 69 indexed, 43 discovered and not indexed, the rest not even discovered. Publishing is not the bottleneck. Here is what actually was.

"Discovered, currently not indexed" is a verdict, not a bug

That status is Google saying it knows the URL exists and has decided not to spend crawl budget on it. No console setting changes that. I went through every togglable thing in Google Search Console, Bing Webmaster Tools and Yandex Webmaster to be sure. What each console gave us:

Action	Effect
Resubmit sitemap	Bing went from 11 known URLs to 1.1K
Raise Bing crawl rate to max	more requests allowed, not more indexing
IndexNow ping	1,068 URLs accepted in seconds
Yandex recrawl queue	150 URLs per day, hard cap
Google request-indexing	~10 URLs per day, hard cap

All of it is discovery. None of it is authority. A thousand pages that nothing links to are a thousand pages Google will get around to eventually, or not.

The mistake that cost the most

Every one of those 1,360 pages was reachable only from one hub. The hub listed all of them, so it looked fine. It is not fine.

A hub with 250 cards divides whatever authority it has by 250. To reach a post, a crawler loads a 257 KB page and walks a flat list. There is no path between posts, so nothing pulls a crawler deeper than one hop from the hub.

What we changed: a ring, not a top-six

The obvious fix is a "related posts" block. The obvious implementation is wrong.

If every post links to the top six in its group, six pages collect a thousand inbound links and the rest collect zero. That is a funnel, not a mesh.

A ring fixes it. Sort the group, then post i links to posts i+1 … i+6, wrapping around:

list.sort((a, b) => a.slug.localeCompare(b.slug));
for (let i = 0; i < n; i++) {
  const picked = [];
  for (let k = 1; k <= 6 && k < n; k++) picked.push(list[(i + k) % n]);
  related.set(list[i].slug, picked);
}

Every post now has exactly six outgoing and about six incoming links. A crawl that starts anywhere reaches everything. Internal links per page went from 10 to 16, and no page is an orphan by construction rather than by care.

Sort by slug, not by date. Dates change when you move a post, and a date-ordered ring rebuilds itself completely on the next publish, changing every internal link on the site at once.

The other thing worth doing

Structured data you already qualify for. Our engine supported FAQPage from day one through a frontmatter field. Out of 1,360 posts, 40 had filled it, carrying 42 questions between them. A capability that 97% of your own content walks past is close enough to a missing one.

The articles already had question-shaped subheadings with an answer paragraph under each. Google's rule for FAQPage is exactly one thing: the question and the answer must be visible on the page. They were. So the schema is now derived from the rendered article instead of a field:

const re = /<h[23][^>]*>([\s\S]*?)<\/h[23]>\s*<p[^>]*>([\s\S]*?)<\/p>/gi;

Only headings that actually end in a question mark qualify. Turning a statement into a question would mean marking up something the page does not say. Result: 1,157 pages carrying 8,217 questions, none of it invented.

What we are still waiting on

Honest ending: none of this has moved rankings yet, and it would be a lie to claim otherwise a day later. Discovery is fixed, the mesh is built, the schema is real. The remaining gap is external links, which no amount of engineering produces.

If you are in the same position, the order that matters is: make every page reachable from more than one place, submit properly once, then go get links. The consoles are the smallest of the three.

We write this stuff up while building Zugo, which turns a written description into a working game, site or app. More of the measured kind on the blog: what AI builders cannot do and how long a build actually takes.

Two h1 tags on 500 pages: the bug that lives between two correct halves

Zugo — Sat, 01 Aug 2026 22:20:43 +0000

Our blog grew from 84 posts to 1,360 in a day. Then I read one live page instead of the source, counted tags, and found two <h1> elements on 500 of them. Both halves of the code were correct. Their sum was not, and no test could see it.

Where the second heading came from

The post template prints the title from frontmatter:

<h1>${esc(fm.title)}</h1>

Every article starts with its own heading, because that is what a markdown document looks like:

# How to build a CRM without code

marked turns that into another <h1>. Nothing in either file is wrong. A markdown document that opens with a level-one heading is correct markdown. A template that prints the page title as the page heading is a correct template. The defect exists only in the output, which is the one artifact nobody was testing.

Why the tests were green

The suite had guards for the corpus and guards for the renderer:

Guard	What it read	Would it catch two h1?
corpus checker	the `.md` files	no, markdown was valid
template tests	the component	no, template emits one
build	exit code	no, build succeeded

Every one of them passed, forever, while a thousand pages shipped a broken heading hierarchy. Search engines get to pick which heading is the page title in that situation, and screen readers announce a structure that does not exist.

The fix is one line, in one place

Not in 500 files. The markdown is not at fault, so editing it would be fixing the wrong thing.

const html = marked.parse(body)
  .replace(/<h1(\s[^>]*)?>/g, "<h2$1>")
  .replace(/<\/h1>/g, "</h2>");

Demoted rather than deleted: if the body heading ever diverges from the frontmatter title, the text stays on the page instead of vanishing silently.

The part worth stealing

The gate runs on the finished page, not on the inputs:

const h1s = (page.match(/<h1[\s>]/g) ?? []).length;
if (h1s !== 1) fail(`${slug}: ${h1s} h1 tags, expected exactly one`);

It is three lines and it catches a whole class. I verified it by mutation: remove the demotion and the build fails on the first article, which is the only evidence that a green gate means anything.

Counting things that must be unique is cheap and it works for more than headings. canonical, title, og:url all have the same property: exactly one, always, and a duplicate is invisible until someone looks at the output.

The general shape

When both sides of a seam look correct and the result is wrong, check the output, not the inputs. I hit the same shape twice more the same week: a checker that read the source and passed while the built HTML was broken, and a guard that fired on correct text because it matched a substring instead of a structure.

If your site generator has a template and a content directory, you probably have a version of this. It costs one command to find out:

grep -c '<h1' dist/some/page/index.html

I write about this kind of thing while building Zugo, which turns a written description into a working game, site or app. The blog has more of the measured-not-guessed variety, for example what AI builders cannot do and whether AI-built sites are accessible.