I run content operations across five real, live sites right now. A cold-email SaaS. A color-grading SaaS. A newer SaaS product still finding its feet. A WordPress photography business that's been running since 2024. And this site, the one you're reading. None of that was true a year ago, and none of it would be true today without an AI coding assistant doing the actual typing while I do the actual deciding.
Here's the part I want to be honest about upfront: it's not magic, and it's not "set it and forget it." What changed is the unit of work I can hand off. Instead of writing one blog post myself, I can describe a post, the facts it needs to contain, the voice it needs to sound like, and where it needs to land in a database, then let a background process go do that while I work on something else. Multiply that by five sites and a real content calendar, and you get an amount of output that would have taken a small team before.
What Actually Changed
The AI coding assistant I use is Claude Code, and the specific capability that matters here is background subagents. I can spin up several of them at once, each with its own scoped task, each running independently, each reporting back when it's done. One writes a blog post for the photography site. Another fixes a bug in a database column. Another researches keywords for a site that hasn't published anything in months. They don't share context with each other, which sounds like a limitation until you realize it's exactly what keeps five unrelated projects from turning into one tangled mess.
The productivity gain is real and I'm not going to undersell it. A backlog of blog posts that would have taken me weeks to draft gets handled in an afternoon. A password bug that would have taken an hour of manual database digging gets found and explained in ten minutes. But the gain only shows up if you're honest about the failure modes, because there are real ones, and pretending otherwise is how you end up with a mess you don't notice until a client does.
The Failure Modes Nobody Puts in the Demo
Run enough of these in parallel and you'll hit rate limiting. Fire off five or six background agents at once and some of them get throttled mid-task, which means checking afterward that nothing landed half-finished, not just assuming the failure was clean. The fix isn't clever, it's just smaller batches and more patience.
Then there's the scarier one. A background agent, working on a single blog post, once navigated into a completely different post's live edit page and submitted a form that flipped it from draft to published. Nobody told it to touch that post. It just ended up there mid-task and the click went through. I only caught it because I run a full published-count sweep after any batch of work, comparing the number I expect against the number the database actually shows. If I'd trusted the agent's own summary of what it did, that post would still be live.
And twice, two separate agents each created their own copy of the same assigned post, apparently after an internal retry that thought the first attempt had failed when it hadn't. Nothing catches that except actually looking, comparing timestamps and content, and deleting the extra by hand.
The One Rule That Makes This Safe
None of those incidents were expensive because none of them went unnoticed. The rule I actually follow, the one that matters more than any prompt engineering trick, is that an agent's report of what it did is not evidence that it happened. I treat it the same way I'd treat an unverified pull request. Probably fine. Check anyway. Query the actual database, read the actual content, confirm the actual date and status, every single time, before it counts as done.
That discipline is boring to write about and it's the entire reason this setup works at real scale instead of turning into a slow-motion accident. An AI coding assistant will happily hand you five sites' worth of output in a day. Whether that output is trustworthy is still, completely, on you.
