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.
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.