Radar started as a Friday experiment. Two weeks later it's a working news publication for product and design leaders, built almost entirely on AI automation. It watches 60+ sources, ranks stories, and generates articles, images, headlines, and summaries on its own.
We’re excited to share some of our learnings while building this with an AI-first mindset.
This is an experimental project, in the spirit of the playground work ZURB has always done. Nothing here is a finished product, but building it in the open has taught us a lot about how AI workflows actually come together, and where the humans still belong.
Here's what we're learning, in three parts. Check out the takeaways and conversation with Bryan and Ben.
Part One: Automation
The idea came from browsing around one Friday and asking a simple question. How do you surface news for product and design people in a way that's actually interesting?
The first problem was sourcing.
Where does the news come from, and how do you pull it in cheaply? The answer turned out to be old technology. RSS feeds have been around for years, and they make it far easier to pull content because the format is strict and consistent across sites. So we curated a list of product and design sources and pointed the system at their feeds.
From there, the system indexes every link so it never pulls the same one twice. Smaller, cheaper models label the content with tags like AI terminology, large language models, and machine learning concepts. Those tags help us keep the content specific and relevant. A daily step then groups related links into topics that make sense together.
The build was fast. A working prototype went up in a few hours. Each article costs about 30 cents to produce, which turned a job that would normally take a month or two into something we shipped in two weeks.
The lesson for anyone starting here: break the work into small stages, use the right model for each piece, and let the technology be the driver. We went straight into design before overthinking the plan, found patterns worth keeping, and built out from there. You don't need it all figured out to start.
Automation lessons:
- Start with an experiment, not a plan. The best move was going straight into the technology and using it as the driver, then finding patterns worth keeping.
- Reach for old, boring infrastructure first. RSS feeds are strict and consistent, which made pulling content far cheaper and simpler than a custom scrape.
- Break the work into small stages. Index, then label, then group. Each stage is easy to reason about and easy to fix.
- Match the model to the task. Smaller, cheaper models can handle labeling and tagging; save the expensive ones for where they earn their cost.
- Cost changes what's possible. At roughly 30 cents an article, a month-long build compressed into two weeks. Cheap iteration lets you learn by shipping.
- You don't need it all figured out to start. A working prototype in a few hours beats a perfect spec you never test.
Part Two: Loops
Websites are living things. The hardest part is keeping them fresh. Loops are how we do that, and they come in two kinds.
A system-closed loop runs without a human. Radar isn't one big loop, it's many small ones. Links get pulled hourly from those 60+ sources. An AI labels each one for relevance and filters out what doesn't fit. Another loop compacts the surviving links into headlines. All of it happens continuously, with no ongoing input from us. We predefined it, then tweaked it a few times after seeing what the sources pushed out.
A human-closed loop needs a person. There are two of them, and they're the core of our editorial model. The first is topic selection. The system ranks headlines using an Elo-style arena borrowed from chess, where every new topic starts at 1500 and rises or falls through head-to-head matchups. But a person still picks which story is most worth reading. The second is writing quality. Once a draft generates, a person checks the sources are relevant and the content holds up, then edits headlines and body as needed.
Right now these steps are manual on purpose.
We're defining the human-closed loop so we can eventually hand more of it to a system loop. That means working out the variables. Do screenshots help? Does the agent need access to the repository? Does it need reference to previous fixes? We're not there yet, and that's the point. The learning is in figuring out what actually matters.
A good example of where this heads: our bug loops. Fixes submitted to Jira get turned into pull requests automatically, rated for reliability, then reviewed by a human engineer before merging. Faster work, with the human still making the call.
Here are some of the loops happening
- The watch loop runs hourly. It pulls links from 60-plus sources, an AI labels each one for relevance, and anything below the bar gets filtered out. We still store the rejects so we're not reindexing them, but they never surface. Fully automated. No human touches it.
- The grouping loop takes the surviving links and compacts them into topic headlines. It looks for signal density. If a pile of unrelated articles builds up with nothing connecting them, nothing gets published. Also fully automated.
- The ranking loop is where a person enters. We built an arena where editors judge headlines head-to-head, running on an Elo system borrowed from chess. Pick the stronger topic out of four and the scores adjust. A low-ranked winner jumps a lot, a high-ranked loser drops hard. They don't swap positions outright, but the pressure is real. The system produces the first ranking. Human taste corrects it.
- The generation loop drafts the article, pulls the sources, and makes an image. Then a person checks whether the sources are real and whether the writing is good enough to ship. Right now that's manual. It doesn't have to be.
That's the direction. More automation, built in ways that support human decisions rather than replace them. Loops don't automate the work away. They create a regular cadence, help the people around you see progress, and keep everyone moving forward instead of stuck arguing or waiting on one big release.
Loops lessons:
- Sort your work into two kinds of loops. System-closed loops run without a human. Human-closed loops need a person. Knowing which is which tells you where to spend attention.
- Build many small loops, not one big one. Radar is dozens of small loops stacked up, each doing one job, rather than a single monolithic pipeline.
- Put humans where judgment matters most. For us that's two points: picking the topic and checking writing quality. Everything else is system-closed.
- Keep steps manual on purpose until you understand them. Define the human-closed loop first, learn what actually matters, then hand it to a system loop.
- Automate in ways that support human decisions, not replace them. The bug loop drafts and rates pull requests, but an engineer still makes the merge call.
- Loops don't remove work, they create cadence. They give the people around you visible, steady progress instead of arguing or waiting on one big release.
Part Three: Content and Evaluation
Automation gets the content out. Making it good is the harder problem.
We break each article into pieces and use a different model for each. Opus 4.8 handles the article body and a second revision of the headline, kept together so the piece holds its context. GPT-4o handles the shorter feed summaries, where a smaller prompt does the job. GPT's image models generate the artwork. The prompt that shapes voice and tone lives right in the tooling, so we can adjust it as we go.
The content is written for a busy design or product leader, and the goal is to be straightforward. This is news, so quick and easy to consume beats polished and literary. Each brief summarizes a cluster of sources, links back to the original authors, and adds a deep cut on how it relates to your work plus three questions for your team.
Making the AI outputs better
To make it better, we built a feedback system into the admin view. Every section of an article gets a thumbs up or thumbs down, plus a note. We kept it binary on purpose. We don't fully know yet how we'll process the feedback, so we're capturing it simply now and can change how we capture it later.
That feedback is where the real opportunity sits. We can take the prompt generating a piece and have an agent use the feedback to curate the prompt itself. Over time, the styles and treatments get shaped by the inputs rather than hand-tuned every step. You stop influencing every detail and start cultivating a system that produces results, then shaping those results with judgment.
The imagery is where this gets fun. We leaned into a retro, pixelated, Twilight Zone kind of mood with a limited color palette. The models develop their own recurring habits, windows into other realities, dripping clocks, chairs turned into art, the occasional stray coffee mug. Some of it is bizarre. Most of it is enjoyable to look at, and the feedback loop lets us pull back the things that show up too often.
Content and Evaluation lessons:
- Automation gets content out; quality is the harder, separate problem. Treat it as its own discipline, not a byproduct.
- Use different models for different pieces, and keep related pieces together. We kept the body and headline in one call so the piece holds its context.
- Fit the prompt to the job. A big prompt for the body, a small one for short summaries. Bigger isn't better.
- Put the prompt in the tooling. Being able to edit voice and tone in place makes iteration fast.
- Capture feedback early, even in a rough binary form. You don't need to know how you'll process it yet. Capturing it now means you can change how you capture it later.
- Feed the feedback back into the prompts. The real leverage is having an agent curate the prompt from the feedback, so the system improves instead of you hand-tuning every detail.
- Shift from controlling output to shaping a system. You stop influencing every part and start cultivating results, then apply judgment to what comes back.
The Takeaways
Three areas matter most if you're jumping into this:
- Break the content down and match each model to the piece it's best at, especially as models get more expensive.
- Build small loops before big ones, and put humans where judgment matters most.
- Capture feedback early, even in a rough form, so quality has something to improve against.
You're never going to rely on a single model, and you're never going to control every part of the output. The work is building a system that produces something worthwhile, then shaping it as you learn. We're still figuring it out, and we'll keep sharing what we find.
More of this is on our YouTube channel and in the Glare forum, where we're inviting people into the conversation. Come build with us.
