# I Built AI DevList Because Finding AI Content Is No Longer the Problem

> Source: <https://dev.to/younes_bentlili_9480340f/i-built-ai-devlist-because-finding-ai-content-is-no-longer-the-problem-502b>
> Published: 2026-08-16 17:47:49+00:00

There is no shortage of AI content.

Actually, we probably have the opposite problem.

Every day there is:

As an engineer, I don't struggle to find AI content anymore.

I struggle to decide:

What is actually worth my time?

That's why I built **AI DevList**.

**Not another AI news newsletter**

I don't want AI DevList to become a summary of everything that happened in AI during the week.

There are already excellent newsletters doing that.

The focus is much narrower:

**resources that are useful for people actually building AI systems.**

The main topics are:

The goal is not to publish 50 links.

If an issue contains 10–15 genuinely useful resources, that's enough.

**Curation alone isn't enough**

When I first announced the project, someone gave me a very good piece of feedback:

Curating content is useful, but the real value comes from adding context.

I agree.

So every resource selected for AI DevList now has two parts.

**1. What is it?**

A short, neutral description of the resource.

No marketing rewrite.

No exaggerated claims.

**2. Why we picked it**

This is the important part.

For example:

Why we picked it

Stateless MCP isn't just a protocol detail. It changes how remote MCP servers can be deployed and scaled, removing part of the session-management complexity that infrastructure teams previously had to handle.

Or:

Why we picked it

Adding a SKILL.md file doesn't guarantee that an agent will reliably discover or follow it. This benchmark is interesting because it evaluates the complete model + harness + skill combination rather than treating skills as static prompt files.

That's much closer to what I personally want when someone recommends a technical article to me.

Don't only tell me what it says.

Tell me why I should care as an engineer.

**My current curation workflow**

The workflow is deliberately simple.

Discover resources

↓

Filter obvious noise

↓

Read / inspect the source

↓

Check technical relevance

↓

Categorize

↓

Write a short description

↓

Add "Why we picked it"

↓

Human review

↓

Publish

AI helps with discovery and preparation.

It does **not** decide what gets published.

That's an important distinction for me.

I don't want to build an automatically generated newsletter that summarizes whatever happens to rank highly that week.

The final selection remains editorial.

**What makes a resource worth selecting?**

I'm currently using a few simple questions.

**Is it technically credible?**

Primary sources, engineering blogs, research papers and serious open-source work get priority.

**Does it solve a real engineering problem?**

Observability, reliability, security, evaluations, context management, orchestration, infrastructure, cost...

Not just demos.

**Can someone apply something from it?**

Even research becomes much more interesting when it changes how we think about architecture or implementation.

**Is it saying something new?**

Ten articles repeating the same product announcement don't deserve ten slots.

Is it worth 10 minutes of someone's time?

This may actually be the most important criterion.

Attention is expensive.

**The first issue**

I'm currently preparing AI DevList #001, which will be published on August 23.

Some of the topics I'm reviewing include:

I'm intentionally keeping the first issue relatively small.

I'd rather publish **12 strong resources than 40 average ones.**

**This is also an experiment**

AI DevList is a small project.

The application itself is intentionally boring:

The interesting problem isn't the software.

It's whether consistent technical curation can become useful enough that engineers return every week.

Over the next few months, I want to learn:

I have added click analytics from the beginning so I can answer some of those questions with data instead of intuition.

**If you're building AI systems**

You can subscribe here:

The first issue comes out on August 23.

And if you publish a technical article, paper, open-source project or tool that you think AI engineers should see, there is also a submission page:

I'm especially interested in feedback from engineers:

**What would make a curated AI engineering weekly genuinely useful enough for you to read every week?**