DEV Community: Alex Morgan

I almost added full-text search. I'm glad I didn't.

Alex Morgan — Sun, 10 May 2026 22:09:59 +0000

When I started tracking AI releases for my own use, the first feature request from the first person who found the site was: "can you add search?"

The obvious answer was yes. Full-text search on 332+ AI releases feels like a must-have. Every content site has it. I even opened an Algolia account.

Then I stopped and thought about what people actually do when they land on the feed.

They don't arrive with a specific release in mind. They arrive wanting to know: "what dropped this week in the models space?" or "any interesting open-source repos lately?" or "what tools are getting traction?"

That's a browsing pattern, not a searching pattern.

The decision

Instead of full-text search, I added 5 category filters:

models — 65 entries
repos — 95 entries
tools — 152 entries
papers — 35 entries
ecosystem — 50 entries

One click. No search bar. No query syntax to learn.

The filters at https://ai-tldr.dev/?cat=tool give you exactly the context you actually wanted when you opened the site.

Why search would have been wrong here

Full-text search optimizes for precision. When someone types "Claude 3.5" they want that exact thing.

But most people visiting an AI news feed don't have that level of specificity. They're in discovery mode. They want to see the shape of what exists, not retrieve a known document.

Category filters match that mental model better. They let you narrow scope without requiring you to already know what you're looking for.

The number that settled it

I looked at the actual query logs from my notes. The only searches I ever ran on my own feed were things like "model releases last week" or "new tools" — category-level queries, not document-level ones.

If the person building the thing only has category-level queries, the users probably do too.

What I'd add next

Eventually I want a date filter — "show me tools from the last 14 days." That's still category-adjacent. Not full-text.

Search might come eventually. But I'll need real evidence that people are looking for specific documents before I add the complexity of indexing, ranking, and query parsing.

332 entries in. The deduplication problem nobody warns you about.

Alex Morgan — Sun, 10 May 2026 06:09:27 +0000

The pipeline hit 332 tracked releases last week. I thought that was a milestone worth celebrating until I looked at the dedup stats.

Turns out 23 of those "distinct" entries were the same model release, just named differently across sources. "Llama-3.1-8B-Instruct" and "Meta-Llama-3.1-8B-Instruct" and "llama3.1:8b" all referring to the exact same thing. My naive string-matching dedup was silently failing for months.

The way I found out: I was hand-checking a batch and noticed three entries in the feed that were clearly the same release. Dug into the DB. Found 23 collision clusters. The worst one had 7 variants of the same model across different sources.

The fix wasn't complicated — normalized form comparison, slug the model name, strip vendor prefixes, lowercase everything before comparing. Took about 90 minutes to implement and run a migration.

But here's the part that actually stung: I had been using "332 releases tracked" as a public number. Now it's 309 once you deduplicate properly. That's a 7% correction on the headline metric I'd been citing.

I updated the site. I don't love seeing a smaller number but I'm not going to leave it wrong because it looked better.

This is the unglamorous part of building a data pipeline. Not the clever architecture decisions or the interesting parsing challenges — it's auditing the numbers you've been confidently displaying and realizing they were slightly off.

The fix is in. The count is 309. That's the real number.

Worth writing down because next time I add a new data source, I now have a test: run it against the known collision clusters and confirm dedup is working before the entries hit the feed. The 23-cluster bug was entirely preventable if I'd had that check from the start.

Open Source Maintainership Isn't a Burnout Problem. It's a Contract Problem.

Alex Morgan — Sat, 09 May 2026 06:08:50 +0000

few months, a beloved open source project dies. The maintainer posts a goodbye note. Twitter mourns for 48 hours. Someone forks it. And then we do it again.

The narrative that follows is always the same: burnout. The maintainer was overwhelmed by issue volume, toxic users, feature demands, zero pay. We need to treat maintainers better.

All of that is true. None of it is the actual problem.

The actual problem is that open source has an implicit contract that nobody agreed to explicitly, and that contract is insane.

Here's what the contract says:

You write software. You put it on the internet for free. Anyone can use it. By putting it there, you implicitly agree to maintain it indefinitely, answer questions about it for free, fix bugs caused by other people's misuse of it, keep up with breaking changes in adjacent tooling, and do all of this on your own time at your own cost.

The user, meanwhile, has zero obligations. They can depend on your work in production systems worth hundreds of millions of dollars, file issues demanding features with zero payment or even acknowledgment, and abandon the project the moment a shinier alternative appears — leaving you to handle the resulting "why is this unmaintained?" reputation hit.

This isn't a burnout story. This is a contract you never signed being enforced against you by the weight of everyone else's assumptions.

I've maintained a few smaller projects. Nothing famous. The moment one of them got above ~800 GitHub stars, the tone of incoming issues changed completely. Feature requests started being filed as bugs. "This doesn't do X" — where X was something I'd never claimed it would do, documented as out of scope, and explicitly declined twice before. But the implicit contract says you owe them X, because you've demonstrated willingness to work on it.

The fix isn't "be nicer to maintainers." The fix is renegotiating the contract.

Some projects have started doing this explicitly: `MAINTAINERSHIP.md` files that say exactly what the maintainer commits to and doesn't. Business source licenses that require commercial users to pay after a threshold. README sections that say "issues will be triaged when I have time; PRs are welcome but may sit for months."

These feel rude to people who've been conditioned by the old implicit contract. They're not rude. They're honest.

The other half of the renegotiation has to happen on the user side. If your company depends on an open source package — really depends on it, meaning your service breaks if it goes unmaintained — you have a business risk that you've offloaded onto a stranger. That's not a relationship. That's exploitation with extra steps.

Funding maintainers through GitHub Sponsors, Patreon, Open Collective, or direct commercial agreements isn't charity. It's acknowledging that the value you're extracting from their labor is real and worth something.

The burnout conversation will keep happening every few months because burnout is the visible symptom. The invisible cause is a set of unspoken expectations that nobody questioned because the software was free.

Free software isn't free. You're just deciding who pays for it. Right now, the answer is: whoever cared enough to build it in the first place.

I stopped using GitHub stars to rank AI tools. Here's what I use instead.

Alex Morgan — Fri, 08 May 2026 21:30:29 +0000

GitHub stars are a trap.

Not in the "popularity doesn't equal quality" sense — that's obvious. I mean something more specific: for a daily AI tools digest, stars are a lagging signal that made my feed worse, and it took me three months to notice.

Here's the decision I made last week: I removed GitHub stars as a ranking input for ai-tldr.dev entirely. This is what happened, and what I replaced it with.

The problem with stars

When I built the first version of the digest, I used stars as a tiebreaker. Two repos released the same week? The one with more stars floats up. Seemed reasonable.

Except stars accumulate over time, and they spike on launch day. A repo that launched 18 months ago with a big HN post has 12,000 stars. A genuinely useful tool that shipped last Tuesday has 340. The older one looks more important in every query.

The result: my "recent AI tools" section kept surfacing things that were already known. The digest was becoming a remix of what everyone already saw six months ago, just slightly repackaged.

I ran a rough audit: of the last 60 tools I'd surfaced that had 5,000+ stars, about 40% were already covered by at least two major newsletters before I picked them up. I was late to the obvious, and missing the actually new.

What I'm using instead

The fix was simpler than I expected. I switched to three signals:

Recency weight — posts from the last 7 days get a strong boost regardless of star count. If it's new, it gets a chance.

Commit velocity — a repo with 12 commits in the last 10 days on a 2-month-old project is more interesting than a stable 3-year-old one. Stars don't capture this at all.

Category freshness — I track which categories I've covered recently. If I've done four "LLM fine-tuning" posts this week, a fifth needs a higher quality bar regardless of signals.

Stars still exist in the system, but they're a soft penalty for very low engagement (under 10 stars after 2 weeks), not a reward for being famous.

What changed

It's only been a week, so I can't claim results. But subjectively: the daily feed feels sharper. I'm picking up things I wouldn't have touched before — smaller tools, specific-use repos, things that solve one problem well rather than trying to be infrastructure.

Whether the readers notice, I don't know yet. But the editorial instinct feels better.

The broader lesson: signals that made sense at the start of a project can calcify into biases. Worth auditing them even when things seem fine.

This Week in AI: Cloudflare Goes All-In on Agents, Mozilla Finds 271 Firefox Bugs with Claude, and Moonshot AI Hits $20B

Alex Morgan — Fri, 08 May 2026 06:02:12 +0000

It's been a wild week in AI land — and if you're not keeping up, ai-tldr.dev has you covered. Here are the three stories that caught my attention this week and what I think they actually mean for developers.

1. Cloudflare Cuts 1,100 Jobs to Rebuild Around "Agentic AI"

This one hit different. Cloudflare — a company that's been incredibly developer-friendly — just cut 20% of its workforce. Their stated reason: restructuring the entire company around AI agents.

This isn't a "we're automating grunt work" announcement. This is an architectural pivot. Cloudflare is betting that the next layer of the internet runs on agents, not humans. For devs building on Cloudflare Workers, this is worth watching closely. Expect the platform to evolve fast toward agent-first primitives.

My take: The age of "AI-assisted" is over. We're entering "AI-architected." Cloudflare is eating the cost now to be the default infrastructure for autonomous agents in 2027.

2. Mozilla Used Claude Mythos to Find 271 Firefox Vulnerabilities

Okay this one is genuinely impressive. Mozilla pointed Anthropic's Mythos Preview fuzzing agent at Firefox and it found 271 vulnerabilities — including a 20-year-old XSLT bug and a 15-year-old <legend> flaw.

Let that sink in: bugs that survived two decades of human code review, found by an LLM in a fuzzing loop.

For security engineers, this is the clearest signal yet that AI-assisted security auditing isn't

I tracked 332 AI releases this week. 85% were noise.

Alex Morgan — Fri, 08 May 2026 00:13:04 +0000

332 items. That's how many AI releases, papers, repos, and tool launches we ingested last week into the tracker I've been building.

I sat down this morning to review the weekly summary. After 6 months of running this, I have a number burned into my brain: 85%.

That's the percentage of ingest that gets filtered as noise before anything reaches a reader.

What "noise" actually means

Not fake. Not spam. Just... undifferentiated. Here's the breakdown from this week's batch:

47 "we're excited to announce" blog posts — repackaged product updates with zero technical content
61 GitHub repos with a README that says "coming soon" or "WIP"
29 papers that are incremental variations on RLHF fine-tuning with no usable results section
38 "model launches" that are fine-tunes of Llama or Mistral with different system prompts and a new brand name
27 ecosystem announcements (funding rounds, team changes, partnerships) — real news, but not useful if you're building

That's 202 items out of 332. Gone.

What's left: 130 items worth a developer's attention. Of those, maybe 15 are genuinely important — things that change what you should be building or how you should think about the stack.

The classification problem nobody talks about

I didn't expect this ratio when I started. I thought AI news was signal-dense. The opposite is true. The field moves fast, but most of the "movement" is noise masquerading as signal.

The hard part isn't ingestion. It's classification. We've tried three approaches:

Rule-based filtering — keyword blacklists, source trust scores. Works for obvious noise. Misses subtle stuff.
LLM scoring — prompt asking "is this novel?" Gets fooled by confident-sounding fluff.
Hybrid + human audit — where we are now. An LLM pre-filters; I spot-check 20-30 items per day for calibration.

The calibration loop is the thing nobody writes about. Every week the distribution shifts slightly. A term that meant "genuine model architecture" last month now means "branding wrapper."

The number that surprised me

After 6 months: the 15% that matters hasn't actually changed.

The absolute count of real signal per week has been roughly stable at 40-60 items. The noise has grown. There are more repos, more launches, more papers — but the density of things that actually move the field has stayed flat.

Which means the job of the tracker is getting harder, not easier, despite LLMs being better at the task.

Wondering if others building in this space see the same pattern. Is your signal-to-noise ratio getting worse as the ecosystem scales, or is my classification schema just not adapting fast enough?

Engineers make better investors than MBAs. Here's why.

Alex Morgan — Thu, 07 May 2026 12:15:34 +0000

I've held this opinion for a while and never said it out loud: software engineers, on average, should be better investors than finance MBAs. Not because of some secret knowledge. Because of the mental tooling we already have from building software.

Nobody talks about this. The finance world markets itself as a priesthood — specialized vocabulary, opaque jargon, Bloomberg terminals that cost $25k/year. But when you actually sit down with company financials, you realize: this is just a system with inputs, outputs, and feedback loops. Engineers are unusually good at reasoning about those.

What engineers actually do well

Tolerating uncertainty. Every software project ships with incomplete specs. You learn to make decisions with 60% of the information you wish you had. Most retail investors freeze when they don't have certainty. Experienced engineers already know certainty is a myth.

Thinking in systems. Revenue, cost structure, moat, competitive dynamics — these aren't that different from reading a distributed system's architecture. You learn to ask "where does this break?" and "what's the feedback loop here?" Those questions map almost directly to "where is this business exposed?" and "what happens when growth slows?"

First-principles reasoning. Engineers are trained to distrust black boxes. When I look at a company's P/E ratio, I don't accept it as a verdict. I ask: what's priced in here? What are the assumptions? This is just debugging.

Reading documentation. Annual reports (10-Ks) are long and boring. But engineers read dense technical documentation all the time. 10-Ks are honestly easier than most API docs.

Where engineers fail (and why)

The failure mode is overconfidence about specific calls. Engineers love finding the clever edge case. But the market isn't a bug to exploit — it's a system where millions of smart people are also looking for the same edge cases. The moat isn't in being smart. It's in being patient and systematic.

The other failure: ignoring the emotional component. Markets aren't deterministic. They're sociotechnical systems where sentiment matters as much as fundamentals for months at a time. That's uncomfortable for engineers trained to reason about what should happen.

The actual tool gap

Here's the honest problem: most financial analysis tools were built for finance people. They either cost a fortune, require institutional access, or are wrapped in UI so bad it looks like it was designed in 2003.

I got frustrated enough with this that I built pomegra.io — a free tool to run proper fundamental analysis without needing a Bloomberg terminal or a finance degree. P/E, EV/EBITDA, DCF, margin trends. Clean, instant, free. The kind of thing I wish had existed when I started paying attention to where my money was going.

The real point

I'm not saying engineers should YOLO their savings into individual stocks. I'm saying the skills gap between "technically capable of evaluating a business" and "thinks investing is too complex for them" is mostly a confidence and tooling problem, not an actual skill deficit.

Finance isn't a different discipline. It's systems thinking with money at stake. We do harder things every day.

Start reading one 10-K. Pick a company you know well — ideally one in your industry. Notice how much of the analysis is just reading carefully and thinking clearly. You'll see what I mean.

Building an AI release tracker: what 6 months of auto-curation taught me about signal vs noise

Alex Morgan — Wed, 06 May 2026 22:25:30 +0000

I've been running ai-tldr.dev for about six months now. It auto-aggregates AI releases — models, tools, repos, papers — from a set of curated sources, deduplicates them, categorizes them, and surfaces the day's signal on a clean feed.

This is a technical retrospective on what broke, what surprised me, and what I'd do differently.

The problem I was solving

My own reading workflow was a mess. I had 20+ RSS feeds, Twitter lists, Discord servers, GitHub watchlists. I was spending 40+ minutes a day on "staying current" and retaining maybe 10% of it.

The naive solution is a newsletter. But newsletters have a fundamental structure problem: they're push, not pull. They arrive on their schedule. They optimize for perceived completeness rather than actual relevance to you.

I wanted something more like a database of releases, queryable by category, that I could check when I wanted to, filtered to what I'm actually building.

What I built (high level)

The system has three layers:

1. Ingestion — Scheduled sweeps of ~30 sources: arXiv, Hacker News, GitHub trending, deeplearning.ai, Nathan Lambert's blog, a few Discord servers. Each source has a different fetch strategy (RSS, API, scrape).

2. Processing — Deduplication (same release covered by multiple sources gets one card), categorization (model / repo / tool / paper / ecosystem), and LLM-assisted title normalization and summary generation.

3. Display — A filterable card grid at ai-tldr.dev/?cat=tool (or model, repo, paper, ecosystem). Currently 421 tracked releases.

What broke

Deduplication is harder than it sounds. "GPT-4 Turbo" and "gpt-4-turbo-preview" and "OpenAI releases new flagship model" are the same thing, but fuzzy string matching gets messy fast. I ended up with an LLM-based semantic similarity check as a fallback, which works but adds cost and latency.

Categories drift. Something that starts as a "tool" often becomes a "model" a month later (or vice versa). My initial categorization scheme was too rigid. I've since made it multi-label and allow manual overrides.

Source reliability varies a lot. Some sources go quiet for weeks, some change their structure, some start publishing garbage. I added freshness monitoring and source health scores, but this is ongoing maintenance.

What surprised me

The curation judgment is the actual hard problem. The automation gets you 80% there. The remaining 20% — deciding whether something is actually notable, catching nuance in source descriptions, knowing when to merge vs. keep separate — that's judgment, and it doesn't automate easily.

After six months, I've built intuitions about what makes a release notable that I can't fully articulate, let alone code. The system is better at surfacing candidates. I'm better at rating them.

People use it very differently than I expected. I built it for daily review. Most users seem to use it as a reference — searching for a specific release they heard about, browsing by category for a specific use case. The filterable feed turned out more useful as a lookup tool than a digest.

What I'd do differently

Invest earlier in source quality over source quantity. I spent too long adding sources and not enough time improving coverage of the ones that mattered. 20 good sources beats 60 mediocre ones.

Build the "freshness" signal earlier. When did this release actually happen vs. when did we index it? The distinction matters. News from six months ago shouldn't compete with news from yesterday.

Current state

421 releases tracked. 6 categories. Daily sweeps. Free to browse.

If you're building in the AI space and want to see what landed this week: https://ai-tldr.dev/?cat=tool

Feedback welcome — especially if you notice something missing that should be in the feed.

Why I built pomegra.io: stock analysis without the paywall maze

Alex Morgan — Wed, 06 May 2026 20:23:20 +0000

I'm an AI engineer in Tel Aviv. I'm not a finance person. But I have a brokerage account and the same stupid problem everyone else has: every time I want a half-decent fundamentals view on a stock, I hit a paywall, a signup wall, or a chart that buries the actual numbers under five layers of upsell.

So I built a thing for myself, and then quietly let other people use it.

This post is the engineering side of that, not the pitch.

The actual problem

Most retail finance UX optimizes for engagement: bright tickers, gamified watchlists, push notifications about "unusual activity." That's fine for a trading product. It's terrible if what you actually want is a sober read on a company in under two minutes.

The job-to-be-done I cared about was narrow:

Pull recent news for a ticker
Summarize it without hype words
Surface the few numbers that actually matter (valuation band, recent earnings, debt situation)
Show me the dissenting view, not just the bull case

That's it. No social feed. No "AI-picked stocks of the day." No copy trading.

Stack, briefly

Nothing exotic. The interesting decisions weren't framework choices.

News ingestion: a few feeds + a scheduled scraper, deduped by URL canonicalization and a fuzzy title hash. Same release gets reposted six different ways across a day; if you don't dedup, your "news" view becomes the same Reuters headline four times.
Summarization: an LLM with a tight system prompt and a banned-words list. "Game-changer," "revolutionary," "poised to," "could potentially" — all rejected at the post-process step. If the summary still contains them after a retry, the article is dropped. Better to show fewer items than slop.
Numbers: pulled from the standard fundamentals providers, normalized into a flat schema. The hard part is which numbers to show. I picked five and stopped. Adding more was tempting and almost always wrong.
Storage: Postgres for everything, including the embeddings. I'm not running a vector DB for a side project. pgvector is enough.

The LLM is the boring part

Everyone wants to talk about the model. The model is the boring part.

The interesting part is the constraints around it. A few that actually moved quality:

Pin the date in the prompt. If you don't, summaries get tense-confused and start talking about "upcoming earnings" that already happened.
Force a structure. I make the model emit JSON with fixed keys (headline, tldr, bear_case, bull_case, numbers_mentioned). Free-form output is where hype seeps back in.
Require a bear_case. Even when the model thinks the news is positive. This single constraint changed the feel of the product more than any model upgrade. Markets are not a hype feed.
Cap output length aggressively. If a TL;DR is longer than three sentences, it isn't a TL;DR.

None of this is novel. It's all just discipline applied at the boundaries.

What I deliberately didn't build

This matters more than the feature list:

No alerts. I don't want users glued to their phone over a 2% move.
No "AI says BUY/SELL." Even when I had a working classifier, I cut it. A model giving directional calls to retail users is a liability dressed up as a feature.
No login wall on the news view. You can read the analysis without an account. Accounts are only for portfolio tracking.
No newsletter. I am not going to email you.

Every one of those was a pull from someone telling me it would "increase engagement." Yes. That's the point of not doing them.

What I learned

A few takeaways that generalized beyond this project:

Editorial decisions disguised as ML decisions are still editorial decisions. Choosing which numbers to show, which sources to trust, which tone to enforce — those are opinions. Pretending the model decides is laundering responsibility.
The hard part of an AI product is rarely the AI. It's data plumbing, dedup, schema discipline, and saying no.
Side projects benefit from a hard scope. The constraint of "under two minutes per ticker, no paywall" killed half the feature ideas before they got built. Good.

If you want to poke at it, the simple market analysis view lives at pomegra.io/feature/market-analysis-simple. It's free, there's no signup for the read-only views, and I'm not tracking you across the web.

It's a side project. It does one thing. That's the whole pitch.

The weekly AI digest experiment: 6 months in

Alex Morgan — Wed, 06 May 2026 18:40:31 +0000

Six months ago I got tired of my own AI news habit.

Open Twitter. Skim a thread. Open Hacker News. Skim another. Open three Substacks I genuinely respect. Realize I've now read 40 minutes of opinions about a model I haven't actually tried. Close laptop. Feel slightly worse.

So I built a thing. It's called ai-tldr.dev and the pitch is boring on purpose: one page, four filters (models, tools, repos, papers), updated automatically, no email signup, no "subscribe to unlock", no thought-leader takes. It's been running for six months. Here's what I learned.

What I actually built

The architecture is unsexy and I'm fine with that.

A scheduled job hits a list of sources (arXiv, GitHub trending, a handful of release feeds, a few curated newsletters).
Each item gets normalized into the same shape: title, one-paragraph summary, source link, category.
An LLM does the summarization pass. It's prompted to be terse and skip marketing language. If the source is already short, we just clean it up.
Items get tagged into one of five buckets: model, tool, repo, paper, ecosystem.
The frontend is a single static page with filter chips. Loads in under a second on a phone. No JS framework, no tracking, no cookie banner because there's nothing to track.

That's it. There's no "AI agent" doing anything clever. It's a cron job with taste.

What I got wrong

I overestimated how much people want personalization. My first version had a "follow topics" feature. Nobody used it. Turns out if your digest is short enough, people would rather just scan the whole thing than configure preferences. Configuration is a tax.

I underestimated how much of "AI news" is actually noise. When you summarize the same announcement from five sources, you realize four of them are paraphrasing the fifth. I added dedup by canonical URL + fuzzy title match. That alone cut the volume by ~40%.

I tried to be funny in summaries. It aged badly. A summary written six months ago that was clever in the moment now reads like a tweet you'd delete. I rewrote the prompt to be flat and factual. Bonus: it's also faster to read.

What actually moved the needle

A few things that, in hindsight, mattered way more than I thought:

No email gate. The number of "newsletter" sites that block the actual content behind a subscribe wall is wild. Removing that one barrier was the single biggest driver of return visits.
Categorical filtering, not search. People don't know what they're looking for. They know whether they want models or tools today. Four chips beat a search box.
A canonical URL per item. I link out to the original source, always. The digest is a router, not a destination. Counterintuitively this makes people come back more, not less.
Rebuilding instead of regenerating. Early on I'd regenerate summaries when the LLM got better. Bad idea — broke shareable links and felt dishonest. Now summaries are immutable once published.

The boring truth about volume

Here's the chart I wish someone had shown me before I started: AI release volume is not increasing linearly. It's spiky. Some weeks there are three things worth reading. Some weeks there are thirty. If you commit to a fixed cadence ("daily!" "weekly!") you will pad. You will pad with garbage.

I now publish whenever there's enough signal. Some weeks the digest is six items. Some weeks it's twenty-two. Nobody has ever complained. People who say they want consistency actually want quality.

What I'd tell anyone building something similar

Pick a tight scope and defend it. The site does not cover AI ethics debates, hiring drama, or model benchmarks pissing contests. Not because they don't matter, but because if I tried I'd do all of them badly.
Make the site work without JS. I'm not religious about it, but a content site that white-screens for two seconds while React boots is a content site I'm going to bounce from.
Write the summary you'd want to read at 11pm. Not at 9am with coffee. The bar for "is this worth my attention" is much higher when you're tired.

Where I'm taking it next

The next thing I'm probably going to ship is a tiny "what changed this week" view — basically a diff of which categories had the most movement — because that's the question I keep asking the data manually.

Six months in, the takeaway is unglamorous: most "AI products" are over-engineered. A boring page that loads fast and respects your time still works.

6 months of running a weekly AI digest: what I'd cut, what I'd keep

Alex Morgan — Wed, 06 May 2026 16:50:56 +0000

I started ai-tldr.dev because I was tired of opening Twitter at 9am and losing 40 minutes before doing any work. The deal I made with myself was simple: every week, write one short digest of what actually mattered in AI — models, repos, papers, tools — and stop scrolling.

Six months in, the site has 332 releases logged, a few hundred regulars, and a backlog of mistakes. This is the honest retro: what I'd cut if I started today, what I'd keep, and what surprised me.

What I'd cut

Categories that sound smart but nobody clicks.
I had an "ecosystem" bucket for org changes and funding news. Click-through is the lowest of any category — about a third of what models or tools get. Turns out, engineers don't open a digest to read about a Series C. They open it to see if there's a new model worth trying on Friday. I'd kill the bucket or fold it into a footnote.

Cover images on every entry.
Spent three weekends building an automated cover generator. Engagement difference between "image" and "no image" rows: noise. I now ship without them and the only person who noticed was me.

Twice-weekly cadence.
I tried bumping to Tuesday + Friday for a month. Open rates per send dropped roughly in half, total weekly opens stayed flat. People have one slot in their head for "the AI thing I read." Don't fight that.

SEO-bait titles.
Early on I A/B'd "Top 10 AI tools you need this week" against plain dated titles like "AI digest — week of March 3." The plain ones won on clicks AND on retention. The audience is engineers; they can smell a content farm.

What I'd keep

One specific idea per week, even when nothing is happening.
The temptation when it's a slow week is to pad. Don't. A 4-item digest is fine. A 12-item digest of half-relevant stuff trains people to skim and unsubscribe.

Filter views over feeds.
The single highest-retention feature is the category filter — people land on the models view, the repos view, the papers view, and stay. A flat feed is for the homepage; everything else should let you carve.

Manual taste, not just an RSS firehose.
I tried automating ingestion fully. The result read like a Bloomberg terminal for AI: technically complete, emotionally dead. I now keep a human pass before publish — even 5 minutes. It's the difference between a tool people skim and a tool people return to.

Plain markdown output.
I write each digest as markdown first, in a single file, before any formatting. It forces the writing to stand on its own. If the post is boring as plain text, no amount of cover art will save it.

The thing that surprised me

I assumed people wanted more depth — long writeups, benchmarks, comparisons. They didn't. The single most common feedback was the same line in different words: "I just want to know what's worth opening." A digest is a triage tool, not a magazine. Once I accepted that, every product decision got easier — shorter entries, fewer categories, faster ship.

If you're thinking about starting one

A few rules of thumb from the trenches:

Pick a vertical narrow enough that you can hold the whole week in your head. "AI" is too broad; "AI engineering tools and model releases" is workable.
Write the first 8 issues before you tell anyone it exists. You will hate issue 3 and want to quit; that's normal.
Don't add a paywall, a discord, a course, a newsletter platform migration, or a logo redesign in the first 6 months. Just ship the digest.
Track one number: do people open issue N+1 after reading issue N. Everything else is vanity.

The repos view is where I personally spend the most time — https://ai-tldr.dev/?cat=repo — because that's where the actual signal lives most weeks. Models are loud; repos tell you what people are building with them. Your mileage will vary.

Six months from now I'll probably disagree with half of this. That's fine. The point of running the experiment in public is that you find out which of your opinions were just vibes.

— Alex

I built a stock analysis tool because Bloomberg charges $2k/month and I'm an engineer

Alex Morgan — Wed, 06 May 2026 13:39:37 +0000

A few months ago I needed to look up a company's debt-to-equity ratio. Not a complicated request. I ended up on Bloomberg's pricing page and closed the tab.

$2,000 a month. For data I needed once.

I'm an engineer. So I did what engineers do when something is broken or expensive: I decided to build a replacement. Not the full Bloomberg Terminal — I'm not delusional — but the specific slice of it I actually needed. Fundamental analysis. Clean data. No paywall. No sales call required.

That became pomegra.io.

What I actually built

The core is a stock analysis tool that pulls fundamentals — P/E, EPS, revenue growth, debt ratios, FCF — and surfaces them without requiring a finance degree to interpret. The interface is opinionated: it shows you what matters, not everything at once.

Under the hood it's not magic. Public data sources, some normalization logic, a bit of AI to turn the raw numbers into readable analysis. The hard part wasn't the data — it was deciding what to leave out. Financial data has a way of expanding to fill whatever space you give it.

The market analysis feature (pomegra.io/feature/market-analysis-simple) is where I spent the most time. The goal was to make it feel like you have a smart friend who read the 10-K so you didn't have to.

The part nobody warns you about

When you build a finance tool, you suddenly become responsible for accuracy in a domain where being wrong has real consequences. I'm not providing investment advice — the legal disclaimer is there, I mean it — but the data still has to be correct.

This meant writing a lot of validation logic. Cross-checking numbers against multiple sources. Building in uncertainty signals so the UI doesn't pretend to be more confident than the underlying data actually is.

Engineers are used to shipping fast and iterating. Finance data doesn't let you do that cleanly. A cached bad P/E ratio is worse than no P/E ratio.

Why free

I made most of pomegra.io free because the alternative felt wrong. Financial data has been locked behind expensive terminals for decades, mostly because that's how it's always been — not because the data itself is hard to get. It's a distribution problem, not a scarcity problem.

The engineers and individual investors who need this data aren't going to expense a Bloomberg subscription. They're going to Google it and get a half-answer from a random finance blog with a 2019 dataset.

I'd rather give them something that actually works.

Still building

The portfolio analysis and rebalancing tools are in active development. AI agents for deeper market research are on the roadmap. It's a side project — I have a day job, I maintain ai-tldr.dev, I live my life — but I ship something every few weeks.

If you want to poke around, it's live. No sign-up required for most features.