How I actually use Claude Code and Cowork

I've been writing PHP for a living since 2007, so I've watched a lot of tools get announced as the thing that changes everything. Most of them didn't. When I started using Claude Code and Claude Cowork in 2026, I expected the same arc: a week of novelty, then back to my editor. That's not what happened, but the reason it stuck is more boring and more useful than the demos suggest. The agents didn't replace how I build software. They took over a category of work I was never going to do by hand.

This post is a plain account of where they fit in my stack and where they don't.

The backlog that started it

My wife Fabiola and I travel the US full time in our fifth wheel and run the Nomads Amor YouTube channel. By early this year the channel had 55 videos and the website had almost nothing. Every one of those videos could have been a blog post. Each one had a transcript, a story, and search terms people actually type. But turning a video into a written article is an hour or two of work, and I was never going to sit down 55 times to do it.

That's the shape of task I now hand to agents: well defined and repetitive, stalled for years because no human was ever going to grind through it.

I run my sites on Swiftrics, the website builder I built, and it has an API for creating and publishing content. So the pipeline looked like this. An agent pulls the transcript for a video, drafts a post in my voice from a style guide I wrote, converts the prose into Swiftrics page components, and POSTs it to the site as a draft through the API. I read it, fix what needs fixing, and publish. All 55 videos went through that loop.

The part I like most is the screenshots. A wall of text about an RV repair is dull without pictures, so the workflow matches sections of the draft against the transcript timestamps, seeks to those moments in the video file, and pulls frames to illustrate the post. Picking a usable frame instead of a motion-blurred one took some iteration, but it works, and it's the kind of tedious judgment call that agents handle fine once you've defined what good looks like.

New videos don't pile up anymore either. A weekly cron job checks the channel feed, and when a new video appears, the same pipeline drafts and posts the article automatically. The backlog problem is now a maintenance problem, which is a much better problem.

The side effect I didn't see coming

Here's the part that surprised me. I own the whole stack, from the Swiftrics codebase down to the API the agents call. When you point an agent at your own API and tell it to create real pages over and over, it finds things a human tester never would. Odd component nesting cases. Whitespace handling that quietly broke inline links. Operations I assumed were covered and weren't.

Because the same person runs the content workflow and maintains the platform, the loop is short. The agent hits a gap in the morning, I have a report of exactly what it tried and what came back, and the fix ships in Swiftrics the same day. It turned out to be the most honest API testing I've ever had. An agent doesn't work around a rough edge the way a person does. It hits the edge, fails, and tells you.

If you build a product with an API, I'd recommend this before any formal QA effort: make an AI agent a real user of your own API and watch what breaks.

Where the agents stop

I want to be clear about the boundary, because this is where most of the hype loses me.

Agents don't design my systems. The architecture of Knowledge ERP, the data model in Swiftrics, the decision of what to build next, that's still me, and I don't see that changing soon. When I've tried handing an agent an open-ended design problem, I get something plausible that I end up reworking anyway. The thinking is the job. I'm not delegating the job.

Agents also don't publish. Everything the pipeline creates lands as a draft, and a human decision pushes it live. That's a deliberate line, not a technical limitation. My name is on these sites. I've caught drafts that got a detail wrong or flattened a story into something generic, and the only reason those never went public is that review is mandatory, not optional. The agent's output is a starting point that's usually most of the way there, and the last stretch is exactly the part readers notice.

And I still write code myself, daily. Claude Code is good at the mechanical middle of a task once I've decided what the task is. It's not the one deciding.

Claude Code vs Cowork: which I use for what

I started with a simple rule for splitting work between the two, and it didn't survive the year. Here's where things landed for me, as of October 2026.

How I started

At first the split was easy. Claude Code was for code: my software projects and my websites. Anything that wasn't code went to Cowork. The biggest example was my audiobook project, Underfoot, a fantasy series written and voiced by AI. It wasn't a codebase and it didn't need to run in a folder on my computer, so Cowork seemed like the natural home for it.

Why I moved almost everything to Claude Code

Over time I moved more and more work into Claude Code, and the reason was access. It runs on my computer, it has its own workspace there, and it can run more programs. Cowork, in my experience, is more boxed into its own environment.

The audiobook is where I ran into that. The voice step needed to do something it couldn't do through the MCP connection in Cowork. When I ran the same job as a Claude Code session, it worked. (The full story of that series is its own post.)

What Cowork is still good for

Cowork has something Claude Code can't give me: it's there when my computer is off. My RV route workflow lives in Cowork. I give it the turn-by-turn directions file from RV Life, it adds stops along the way, like Love's and other places an RV can stop, and it builds a Google Maps link that I use for the actual turn-by-turn navigation. Because that lives in Cowork, I can work on a route from the road with the laptop off.

My Claude Code projects live on my computer. When it's off while we're driving from one place to the next, they're unavailable.

The other thing Cowork does well for us is sharing. I set up a couple of Nomads Amor projects in Cowork that don't keep most of their memory inside Cowork. Instead, their instructions say where the knowledge lives: a specific Google Drive folder, which they reach through Composio. How things work, how we do things, our spreadsheets and the "database" are all stored there.

Fabiola has her own Claude account and her own Cowork project, set up the same way and pointed at the same Drive folder through Composio. So the two of us can effectively work on the same project from two different accounts, with the same memory, the same instructions and the same spreadsheets. Either of us can make updates to our website and our YouTube channel from there.

I expect this to change soon as Cowork evolves. For now, though, it's a handy way for two accounts to share one knowledge base.

As I understand it, Cowork runs in the cloud, and I've seen hints that it's moving there completely. I'm not sure about that part, so treat it as my impression and nothing more.

Where it stands today

Today almost everything I do runs in Claude Code. My development-team AIs each run in their own Claude Code session. So do my "management" AIs, the ones that coordinate other Claude Code sessions instead of writing code. They need to actually start processes on my computer, and I don't think Cowork could do that. Running my company this way deserves its own write-up, so more on that another time.

Only a couple of things are still in Cowork, partly because that's where they already were. The route planner is the one I'll keep there, because I want it to work with the computer off. Even that may matter less soon. My plan is to keep my computer on all the time, even while we're traveling.

How I'd choose between them

Whether the work is code turned out to be the wrong question for me. That was my original rule, and the audiobook broke it. What matters is what the work needs to reach and when it needs to run.

If it needs your files, the programs on your machine, or the ability to start processes there, I'd use Claude Code. That has been nearly all of my work, including some I expected to be fine in Cowork. If it needs to be there when your computer isn't, that's the job where Cowork has kept its place for me.

What I'd tell another developer

Start with the work you've been avoiding for years because it's too repetitive to face, not the work you enjoy. For me that was 55 unwritten blog posts, not my core product code. Batch content work and anything that needs a hundred similar-but-not-identical passes is where agents earn their keep immediately, and the stakes are low enough that you can learn their failure modes safely.

Then keep your hands on the two ends. You define the task and the standard going in, and you review what comes out. Everything between those two points is negotiable. The picture that's emerged for me isn't an AI that builds software while I watch. It's closer to having a tireless assistant for the grind, running under rules I wrote, on a platform I built, shipping nothing without my sign-off.

That division of labor is doing real work on my sites every week. If you want to see what it produces, the Nomads Amor articles are the output of everything described here, and the rest of what I build is on my projects page.

It has since taken over where we drive, too. I stopped building our RV routes by hand for exactly the reason I stopped writing those articles by hand: the work was repetitive, I kept putting it off, and the standard I wanted was easier to write down than to apply 55 times.

None of this is free, and the number surprised me when I finally added it up. I measured where my AI budget actually goes, and the split between the work above and everything else was not what I would have guessed.