The AI Firehose Is Not a Learning System

I read five AI newsletters before lunch.

A new model from Anthropic. An open-source project that thousands of people starred overnight. Three tools I'd never heard of that apparently everyone was already using.

By noon I had a list of twelve things I wanted to try. By the end of the day I had tried none of them, and the list had grown to fifteen.

I closed my Mac feeling less capable than when I opened it.

That's the trap.

The Firehose Is Real

I want to be clear: this isn't a "just ignore it" piece. The new stuff coming out every day is genuinely impressive. These are not all incremental updates. A lot of them are real capability jumps that create real value.

That's what makes it so hard.

It's not noise. It's signal. There's just way too much of it.

Every day I see something and think: I should try that. I should learn that. I should integrate that into my workflow.

Not only because I "should," but because I genuinely want to.

The list of things I want to try grows faster than I could ever work through it.

The Real Cost

The thing is: I'm not sitting around.

The last few weeks I've spent 30+ hours a week actually building. Shipping things, solving problems, deep in the work. This isn't a productivity issue.

But the overwhelm is still there. It runs in the background like a process eating up CPU. I'm making progress, but part of my brain is convinced I'm falling behind because I haven't tried that new framework, that new model, that workflow someone posted about.

That's the real cost. The firehose doesn't always stop you from working. Sometimes it does something more annoying: it makes the work you're already doing feel insufficient.

Three Things That Helped

I haven't fully solved this. But here's what seems to be working for me.

1. Start from active problems, not tools. Over the past few months I went deep on building small web apps with Google's Antigravity using both the Gemini and Claude models. I also played with Claude Code, Codex, and a bunch of open-source IDEs, but I stayed with one main setup long enough to actually build things.

I learned more about what AI-assisted development feels like from that one stretch than from months of reading about it.

At the same time, I had to learn the fundamentals around the work: secret management, SSH, firewalls, ports, server configuration, deployments. Boring DevOps stuff few people post about. But now I have infrastructure I actually understand, and I can run my own web apps and open-source tools on it.

That knowledge doesn't expire as quickly as tool impressions do.

2. Limit the active tool stack. Instead of skimming ten tools, I settled on a couple and got genuinely familiar with them. Their shortcuts. Their quirks. Their edges. That compounds in a way that tool-hopping never does.

3. Keep systems portable. The goal isn't to use every tool. It's to keep switching costs low enough that trying something better does not become a migration project.

In practice, I keep projects simple and portable whenever possible. When I build a new site, I prefer static files I can deploy to Coolify, Cloudflare Pages, or Vercel in under two minutes. No vendor lock-in. No migration dread. When something better comes along, I can actually use it.

A Tool Intake System

The useful move for me has been to separate noticing a tool from adopting it.

Those used to feel like the same thing. I would see a tool, feel the spike of curiosity, and immediately add it to the mental pile of things I was now "behind" on.

But noticing is cheap. Adopting is expensive.

So now the intake is lighter. Interesting tools can sit in a backlog. Some are just links. Some become notes. A few get tested when they connect to something I'm already building.

That distinction matters. A backlog gives curiosity somewhere to go without letting it hijack the day.

The point isn't to become rigid. I still want to try new things. I just don't want every interesting launch to become an obligation.

Fast Implementer, Not Early Adopter

I've made peace with the fact that I don't need to be at the frontier. Most of us don't.

The more valuable skill isn't being first to every launch. It's being able to pick up new capabilities quickly when they actually matter for the work.

That's a different muscle. It's not about knowing everything that shipped this week. It's about having enough depth with the tools and systems around you that when something genuinely relevant drops, you can integrate it fast.

The people who seem most productive with AI aren't the ones who try everything. They're the ones who stopped trying to keep up and started getting good.

Keeping up is a weak goal.

Getting good enough to absorb the right thing quickly is much more durable.