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?