The Build-of-the-Week

An AI Newsletter that cuts through the daily noise, Judges its work and assigns you homework to keep you ahead

Last Tuesday a staff engineer I respect dropped a paper in our team Slack. “Worth everyone’s time,” he wrote.

I’d read it three days earlier. My AI newsletter surfaced it on Saturday, tagged it [deep, high-value], and told me what to do about it. It got even weirder from there. At one point, the newsletter told me how to fix its own grading logic. More on that below.

---

Keeping up with AI in software engineering right now feels like a race to be first: a new model every fortnight, a new agent framework every week, four newsletters, two Discords, and a feed that punishes you for sleeping. If you’re in law, medicine, finance, or design, you’re watching the same flood hit your field, just a few months behind. Reading harder doesn’t work. I built this thing out of exhaustion. The trick I realized that works is to spot the signals and go deep. The actual “T” Shaped engineer. Evaluate, Establish , Engage and Erling Haaland this new era in Software.

The idea was simple, with AI doing everything from hiring humans to making GTA 6 in couple hours. I was sure Claude Cowork was enough for something as simple as cutting through the noise in the AI Industry and deliver a newsletter aimed towards my goals and help me have a job long term by learning by building or at least be the first to say “Hmm This seems interesting.. <insert new AI development link here>” in my teams Slack channel.

And Cowork was certainly..enough..Until the prompt got to be over 2,000-words long and with needing my laptop to be awake for the runs to happen, the price creeping up , the advent of open source models like GLM-5.2 and not wanting to be a hostage to the big LLM providers, I realized this was easier as a pipeline solution. Why call an LLM when it can be solved by an IF clause.

Fetch, grade, distill, build, repeat. That’s the whole design. Every morning the pipeline does deterministic content fetching via APIs, RSS feeds, Google Searches, based on my own defined sources (Hackernews, ArXiv, Hugging Face etc). The links and dates are checked for recency, validity and duplicity. A model grades the output and a second model audits the picks. Every week the pipeline runs an SQL call over what survived and tells me what’s actually trending, not what’s noisy in the wild. Then it assigns me one weekend-sized project tied to the top trend, my preferences, and logs it so there’s a visible record of me *building* through the noise instead of just reading about it.

How it works:

1. The Setup

A pipeline on GitHub Actions, runs every morning and 5 things happen:

1. Fetch. Five sources (HackerNews, Hugging Face, ArXiv etc), ~125 candidates, zero LLM calls. Plain code.

2. Curate. One model reads all 125 and decides keep or drop.

3. Store. Survivors become rows in SQLite. State accumulates.

4. Grade. A second model gates and judges what made it through.

5. Ship. A dated digest gets committed back to the repo.

The LLM never browses, never remembers, never checks its own work. It gets a stack of candidates and one job: what deserves the front page for this particular reader? Who this Newsletter is aimed at (The reader persona) and what they care about (The industry lanes) lives in a YAML file. The file also contains additional filtering criteria like a 30-day recency rule, and a three-part lens every kept item must clear:

**hot** (momentum across multiple sources),
**deep** (matters in a year), or
**high-value** (moves my career).

Prompts are compiled from the config. Change the YAML, change the newsletter. Swap the lanes and persona and the same machine becomes a biotech digest, a legal-AI digest, a design-tools digest. The pipeline is generic.

2. The grading: gates, then a judge

For every way the output can be bad, ask one question first: can code catch this, or does it need judgment?

Code catches most of it. Every run it gates on the following:

- Links must be real. HTTP check, catches hallucinated URLs
- News must be new. 30-day window, missing date fails too
- Advice must name a real tool, if it suggested it as part of the content to integrate it as micro experiment to build.
- Categories must be mine. / No source can be silently skipped.
- No repeats from the day before or last week.

Failures flag, they never block: a gated run still ships with a ⚠️ block on top listing what failed. Evals that block get disabled the first morning they’re annoying; evals that narrate get kept.

What code can’t catch is then sent to a second, cheaper model, never the same model that curated this list. It scores each kept item 1–5 against the same lens (Hot, Deep, High Value, Passes all Gates), one item per call so scores don’t anchor on neighbors, logged with a one-line rationale. The judge gets a voice, never a veto: LLM judges are noisy, and a noisy score is a terrible gatekeeper but a great trend line.

Here’s the part I enjoyed the most. I didn’t get the above rule about not anchoring on neighbors and not sending it back to the same model ,from a blog post. I got it from the newsletter itself. Its densest trend over two straight weeks was judge unreliability: BabelJudge measuring position and verbosity bias without human labels, Preference Leakage showing judges silently favor their own model lineage, practitioners converging on “an uncalibrated judge is not an eval.” The pipeline’s research dictated the pipeline’s own design. The loop audited the loop.

You can check the health of the pipeline using a single command.

It is a regression detector for the whole system. Swap the curator to a cheaper model, rewrite the persona and the trend tells you whether quality moved or you just shuffled words, before you feel that vibes are off.

3. The payoff: trends, and a build that closes the loop

Daily digests are table stakes. The weekly run is where the state earns its keep.

Because every kept item is a database row: source, lane, axes, date. The weekly job can then ask the only question that separates signal from noise: **what showed up more than once, across more than one source, this week?** One paper is a paper. The same idea appearing on arXiv, HN, and a practitioner blog in seven days is a trend. That’s a SQL query plus one LLM call to synthesize over the results.

Then it does the thing which I hated as a child but understood its need as an Adult. It assigns homework. One build-of-the-week. Weekend-sized, tied to the top trend, and gated by a prior-art rule: the proposal *must* name the existing framework or harness it extends, or it fails an eval check. No “build an eval platform from scratch.” I don’t want to build something that already exists.

Every assignment lands in a tracker table with a status - idea, building, shipped. So the pipeline never re-suggests what I’ve already done, and the tracker itself becomes the artifact. A repo where the digests, the trend lines, and a growing list of `idea → shipped` rows live side by side is a public record of compounding, and it’s the difference between consuming AI news and metabolizing it.

Reading is input. The loop closes at output.

Repo - If you want to fork it, extend it or create your own Newsletter.

So: what's sitting in your idea → shipped column right now? I'd rather hear what you're building through the noise than what you're reading about it.