Newzle: a daily news puzzle that builds itself

At a glance

• What it is: a daily fill-in-the-blank word game built from a real news headline. Live at every load, fresh every morning.

• The point of the project: to build a product that runs itself, one that makes editorial judgment calls and authors usable content unsupervised, and stays reliable doing it. Not a demo; a machine that's been making its own decisions daily for months.

• Result: running autonomously for ~90 days. 92 unattended runs, zero manual editing. A fresh puzzle every morning from whatever the news happens to serve up (a shipwreck 3D-mapped underwater, a viral round raccoon, an AI-security exploit, a World Cup halftime show). The app keeps only the last 7 puzzles live; the pipeline behind it has simply never stopped.

• Running cost: effectively zero. Deliberately architected to stay inside free tiers: free-tier AI API, free CI, static hosting.

Why I built it

Anyone can build a small app with AI coding tools now; that's not the interesting question. I wanted to answer two harder ones, by shipping, not in theory.

First: can I build a product that runs itself, one that makes the judgment calls a human normally would, and produces something genuinely usable at the other end? Not a script that shuffles input into output, but a system that reads the day's news, decides which story is worth telling, and authors a fair, playable puzzle from it. Editorial taste, creative writing, quality control (the human parts), handed to an automated flow and trusted to come out right.

Second, and this is the real design problem: how do you make something non-deterministic behave reliably in production?Something you can trust to run every single day, unsupervised, on inputs you can't predict: a live news feed that might serve up anything. An LLM is a creative, improvising component; putting one at the center of a system that has to just work every morning forces you to confront every way it can go wrong. I wanted that problem in my hands.

A daily news puzzle was the perfect vehicle. It needs fresh content (a live feed), real editorial and language judgment (the part only an LLM does well), and, critically, it has to be *correct* every time, because a broken puzzle is simply unplayable.

Try today's puzzle for yourself at 👉 newzle.app

What the player sees

• A real news headline appears with 5 words removed, and not just any headline: the one picked as the most surprising, delightful "wait, really?" story from that day's news feed.

• Below it, a bank of 15 words: the 5 correct answers plus 10 decoys pulled from *plausible alternative stories*. Fill all 5 slots in 3 tries or fewer.

• Two difficulty modes hide 4 or all 5 slots.

• Finish, and you get a short summary of the real story plus a link to the source.

Simple to play. The interesting part is that no person chooses that story or writes any of it: the editorial call that a human editor would normally make is itself made by the pipeline.

The machine behind the game

Every puzzle is produced by a 9-stage pipeline that runs start-to-finish on its own. Some stages are plain code; the creative stages are AI API calls. The design principle throughout: let the AI do only what needs creativity, and wrap it in code that checks its work.

Five AI calls, each with a narrow job, chained together, with code doing the fetching, filtering, and final validation. Splitting the creative work into small, single-purpose steps is what makes each one checkable.

Designing for a component that improvises

This is the heart of the project, and the part most relevant to designing AI flows. An LLM will occasionally return the wrong shape, hallucinate a word that isn't in the sentence, time out, or produce a puzzle that's technically valid but unfair. A system that runs unattended can't hope none of that happens; it has to assume it will and catch it.

Here's how the safety is layered.

Guardrails in plain code, before the AI ever runs

The cheapest problems get solved without spending an API call. A keyword blocklist strips anything about death, violence, disasters, or hard-sell product deals so the daily puzzle stays light. A paywall blacklist drops sources a player couldn't read. A recency filter keeps only the last 48 hours, with a graceful fallback to the wider pool if too few stories qualify, so the pipeline never starves.

Retry loops for overloaded APIs and off-script answers

Every AI call sits inside a retry loop: if the API is overloaded, it backs off and tries again, up to ten times, rather than failing the day's puzzle over a transient blip. One creative step goes further: if the model writes a sentence but then lists a "hidden word" that isn't actually in that sentence, the code catches the contradiction, appends a correction to the prompt, and asks again. The system talks the model back into line.

Contracts, not vibes, for the AI's output

The creative stages don't return free text. The exact output format is specified in the API call itself: each request carries a response schema (which fields, which slots, which words, ranked by importance) and tells the API to return JSON only. So the model is constrained at the source, shaping its answer to the contract as it generates, rather than me hoping a free-form reply happens to be parseable. Anything still malformed is caught at the door, before it can corrupt the puzzle downstream. This is a different safeguard from the validation gate below: one constrains what the model can say, the other checks whether what it said is actually correct.

A final validation gate that can't be skipped

Before anything publishes, code re-derives the puzzle from scratch and checks the hard rules the AI can't be trusted to guarantee: every hidden word appears verbatim in the sentence, no decoy accidentally equals a real answer, the 15-word bank contains no duplicates.

If the AI's chosen combination fails, the code rebuilds a valid one itself. It can, because the raw material is already on hand: a step earlier the pipeline generated six candidate decoy stories, not two, and the AI's only job was to pick and rank the best three. So when its pick doesn't validate, the code searches every combination of three from that pool and takes the first that holds up. If none does, the pipeline aborts rather than ship a broken game. The AI proposes; the code disposes.

Choosing the right model and the right amount of thinking per task

Not every step needs the same horsepower, and matching the tool to the job is both a quality decision and a cost one. Every call has three knobs: which Gemini model, how much thinking it's allowed, and its temperature (how much freedom it has to improvise, from `0` for repeatable up to higher values for creative). I set each knob per task, and kept the whole thing inside the free tier while doing it.

I picked these models by testing, not by spec sheet, and that produced a result worth calling out. The puzzle-generation steps are the hardest part of the whole pipeline: they have to obey several constraints at once (words that must appear verbatim, a strict output schema, decoys that stay plausible but never slip into near-synonyms). That is exactly where a newer model generation earned its place. `gemini-3.1-flash-lite`, despite being the smaller "lite" variant, followed those tight constraints more reliably than the older full-size `gemini-2.5-flash`, which I kept for the editorial judgment calls where it was already strong. On the work that mattered most, a newer generation beat raw size.

How it's built, and how it stays running

I built the whole thing (React frontend, the multi-stage Node pipeline, the prompt design, the validation logic) with AI-assisted coding. That let one designer reach well past classic front-end work into prompt engineering, schema-constrained generation, and defensive validation. But the achievement isn't that AI helped me write the code; it's what the code does once I step away from it.

Stack: React + Vite + Tailwind frontend · Node pipeline · Google Gemini API · deployed as a static site with analytics.

Automation: a scheduled CI job runs the pipeline every morning, commits the new puzzle, and redeploys, with no server to maintain and a manual "force regenerate" switch for when I want to intervene. It has fired ~91 times over ~90 days with only 1 manual regeneration (I still need to fix a bug 😅).

What it proves

Newzle is small as a game and deliberately ambitious as a system. It has run itself for ~90 days, and it quietly demonstrates the two things I set out to prove:

• I can build a product that makes its own judgment calls and creates something usable: reading the news, deciding what's worth telling, and authoring a fair puzzle, unsupervised, where a human used to sit.

• I can design AI flows that survive contact with production: decomposing a creative task into checkable steps, wrapping a non-deterministic model in code that validates, retries, and self-corrects, and matching model and reasoning effort to each job so it runs reliably every day, on unpredictable inputs, at zero cost.
  
  

A different surprising story every morning, chosen and written by a machine that knows how to catch its own mistakes. That trustworthy autonomy, not the game, is the design work I'm proud of.