
I'd written Cowork off as a tool for non-developers. Then I rebuilt a $30/month app as a morning workflow and changed my mind.
Yesterday I wrote about the mental model I've landed on for how I work with AI tools based on the working mode I'm in. One thing I'm experimenting with right now is how I work with Claude Cowork. After a few initial experiments, I'm immediately seeing Cowork as a co-pilot, not an autopilot — there when I'm at my desk hammering on repeatable tasks, freeing me to put my time toward work that requires judgment rather than plain execution.
I want to share a little about the first experiment I ran with Cowork, which has surprised me at how effective it has been.
A while back I built a little social media filtering tool called paredown. The idea was to ingest posts from my Twitter lists, run them through AI-powered filters, and surface only what was actually relevant to me. It actually did a decent job — finding posts and scoring them based on the relevance of the unique context I'd configured.
But it wasn't as effective as I'd hoped overall, and it was clunky. It depended on a scraping service I was paying $30/month for, and the lists had to be public, which was its own problem. The friction kept me from actually using it.
I'd been noodling on how to improve it: more filters, better sources, less friction. And I had a hypothesis that this might be something Cowork could handle better than the app I'd built.
So I rebuilt the whole thing as a Cowork workflow in a morning. It's not just reading my lists anymore — it also does dynamic discovery based on whatever I tell it to look for that day, flags potential new accounts worth following, and keeps memory across sessions. And because it's right in front of me, if I need to tweak something, I just start a new conversation and the scheduled task runs a little differently the next time.
That distinction — app job vs. co-pilot job — is worth unpacking. Part of what pushed me toward rebuilding paredown as an app originally was the era of the personal app mentality — and I still believe in that. But the more time I spend thinking about when apps make sense, the clearer the line becomes.
Build an app when you need to collaborate, distribute, or share the mechanism with other people. Build an app when the thing needs to run on a schedule you're not around for. Cowork has immediately felt like the better fit here because this is work I'm going to action on while I'm sitting at my desk — and it doesn't matter if that job ran while I was taking a day off, because day-old social posts aren't worth responding to anyway.
I initially wrote Cowork off as not for developers — not for me. I figured it was a productivity tool for non-technical users and I could just use Claude Code for everything. That was wrong.
What I missed is that Cowork fills a gap Claude Code doesn't. Code is for building. Cowork is for doing — executing multi-step workflows where the work itself isn't software development. There's a whole category of stuff I do every day that falls into that bucket, and I'd been either doing it manually or ignoring it.
The content engine I'm building this week is the clearest example. Writing a blog post, creating a thumbnail, uploading a video to YouTube, posting on three social platforms — that's not a development task. It's a repeatable workflow. And having a co-pilot run alongside me while I do it is genuinely faster than doing it alone.
I'm writing this after just a couple of days with this new mental model, so I don't have strong conclusions yet — but the early signals are strong. I'm going to keep looking for new use cases where Cowork can remove repeatable tasks from my day and help me stay focused on work that actually requires my thinking.
Much more to come. And now, back to building!