Every Claude Code honest review you can find right now is a developer talking about a coding session. Seven months in the editor. Thirty days of refactoring. What broke during a three-hour vibe-coding marathon. Useful stuff. But not one of them answers the question I actually had in April 2026: what happens when you point Claude Code at your live business output, walk away, and let it run every day for months with no human catching things in real time?
I know the answer now, because I’ve been running exactly that since April. I’m Tommy. I founded Trigli, an AI customer support SaaS, so I’ve been shipping AI into production and watching it misbehave since before it was cool to admit that AI misbehaves. This blog, Big Guy on Stuff, is run by an eight-agent Claude Code pipeline that researches, writes, fact-checks, optimizes, illustrates, and publishes to WordPress on a daily schedule. Nobody presses a button. So this is the review nobody’s written yet: not a setup guide, not a 30-day impressions piece, but a debrief from the git history of a pipeline that’s run unattended long enough to break in interesting ways.
And it did break. Five documented times, in ways I can point to in the commit log. That’s the whole point of this post. If you’re thinking about running Claude Code as infrastructure instead of as a coding buddy, these are the scars you’re signing up for. Treat this as the operator’s version, sitting next to all the developer ones.
What Does “Fully Autonomous” Actually Mean When It Runs Every Day?
Here’s the thing most reviews miss, and it’s why this one reads differently. A developer using Claude Code is in the loop. You read the diff. You say yes or no. You catch the weird test before it merges. That safety net is invisible right up until you remove it.
I removed it. The daily pipeline runs whether I’m at my desk or asleep or on a cruise ship with spotty wifi. There is no human reading the diff in real time. That single fact changes everything about how the failures show up.
The 8 agents and what each one owns
The pipeline is a chain of specialized Claude Code subagents, each with its own job and its own context window:
- Content Researcher finds topics and writes the brief, including a gap analysis of what the top ten results all miss.
- Editorial Planner runs the show. Calendar, duplicate prevention, pipeline coordination.
- SEO Strategist handles keywords, meta, headings, slugs.
- Content Writer drafts the post in my voice. That’s the agent writing these words right now, if I’m being honest about it.
- Fact Checker verifies every claim and, more importantly, catches me claiming things I never did.
- Image Creator generates the featured image and in-post visuals.
- Performance Analyst pulls GA4 and Search Console data and rewrites the roadmap based on what’s actually working.
- WordPress Publisher pushes the final post to the live site.
Eight agents. They pass work down the line like an assembly line, except the foreman is a text file called CLAUDE.md.
What a normal day looks like (nobody touches it)
A cron job kicks off a headless Claude session at 8am Eastern. It checks indexing, runs an audit or two, and if a post is due, it walks the whole chain from research to scheduled publish. Most days I find out what happened by reading the daily summary email, not by watching it work. That’s the demo everyone sells you. Set it up in an afternoon, sit back, watch the content flow. The demo is real. It’s also not the story. The story is what the git history shows three months later.
The Incidents: Five Things That Broke
This is the section no competitor can write, because I’m the only one who ran this and wrote down what broke. Every incident here maps to a real commit. Real post IDs. Real dates. No hypotheticals.
Post 4690: The sign-off gate that wasn’t enforced (June 2)
I built a five-agent sign-off system. Before any post publishes, the Writer, Fact Checker, SEO, Image Creator, and Publisher all have to approve the same version. Beautiful on paper. I documented it thoroughly in CLAUDE.md.
Documented. Not enforced. See the difference? I didn’t, until June 2.
On that day, post 4690 went live as a different article than the one all five agents had signed off on. The Publisher regenerated content at publish time instead of shipping the exact approved draft, and nothing in the code stopped it. The gate lived in a README. The deploy path never checked it. The fix was a script, check-signoffs.py, that has to exit zero before any publish proceeds. Now the gate is in the pipeline, not in the prose describing the pipeline. Lesson burned in: documentation is not enforcement.
The double-booking incident: 5 duplicate dates in one run (June 5)
Three days later, a different failure. The Publisher was calling POST /posts unconditionally every time it ran. Create a post. Create another. It had no way to check whether the post already existed.
You can guess where this went. One run created five double-booked publish dates and three orphan posts nobody asked for. The calendar said one thing, WordPress said another, and the two drifted apart quietly until I went looking.
The fix was making the whole operation idempotent. There’s now one publish helper, wp_publish.py, that looks up the post by slug and updates it if it already exists instead of blindly creating a new one. It writes the WordPress post ID back to the calendar so the two can’t diverge. A daily script, audit-schedule-divergence.py, runs as a backstop and screams if they ever do. Lesson: any pipeline step that creates external state has to be idempotent, or it will eventually duplicate. Not might. Will.
The affiliate tag leak nobody noticed for weeks
This one stings, because it cost actual money and no automated check caught it. A human did, and only during a separate audit.
I have an old Amazon affiliate tag from a previous account, bgos07-20. The correct tag for this blog is bigguyonstuff-20. Somewhere in an agent prompt, the old tag got embedded, and it started showing up in live affiliate links instead of the right one. No error. No warning. Every click that should have credited this blog was quietly routing commission to a tag tied to an account I don’t even use anymore.
That’s the nasty thing about credentials and identifiers baked into prompts. They don’t throw exceptions. They just silently do the wrong thing, correctly, forever, until someone happens to look. The income-plan audit caught it. Nothing in the deploy path did. I’ve since standardized the tag everywhere, but the lesson stands: an invisible bug that costs money is worse than a loud one that costs an afternoon.
Em-dashes: what happens when a style rule lives only in a text file
Small one. Also the most stubborn.
My number one style rule, stated in bold in CLAUDE.md, is no em-dashes. Ever. The Writer agent runs on Opus, which is a strong model that reads the rule, understands the rule, agrees with the rule, and then produces em-dashes anyway. Over and over. I’d catch them post-publish and fix them by hand on multiple posts before I accepted what was going on.
A style rule in a prompt reduces the violation rate. It does not zero it out. So now check-ai-tells.py scans every draft for em-dashes (and a banned-phrase list, and sentence-length variety) before anything ships. Same pattern as the sign-off gate. If it matters, it goes in the deploy path, not just the instructions.
The Writer that claimed I tested things I never touched
Here’s the one that actually scared me.
The Writer would, now and then, produce a sentence like “I tested this chair for six weeks” about a product I have never sat in. Confident. Specific. Completely fabricated. For a review blog whose entire pitch is firsthand experience from a bigger guy, that’s not a typo. That’s a credibility bomb with a lit fuse.
The catch is the Fact Checker, and here’s the part worth sitting with: I run the Fact Checker on Opus, the same tier as the Writer, on purpose. A stronger writing model produces more convincing fabrications. A weaker checker would wave them through because they read so clean. You have to upgrade the checker in lockstep with the writer, or the better prose just means better lies getting past a dumber guard. That routing decision came directly out of watching this specific failure.
Why I Run Sonnet for Orchestration and Opus for Writing (and What It Costs)
No review I’ve read talks about model routing by pipeline stage, and it’s one of the more useful things I’ve learned. If you steal one thing from this whole post, steal this section.
The orchestrator and most agents run on Sonnet. Research, briefs, SEO, images, publishing, the audits, the planner itself. All Sonnet. That work is structured and gets checked downstream, so a cheaper, faster model is the right call. The Content Researcher even owns the article structure now, the whole outline, so the expensive model isn’t burning budget re-deriving where the H2s go.
Two agents run on Opus. The Writer and the Fact Checker. That’s it.
Timing note: the three months this post covers ran on Opus 4.8, pinned by model ID so the alias can’t drift. Claude Opus 5 launched July 24, 2026, the day before this post went up, and I moved the Writer and Fact Checker onto it the next morning, with the orchestrator going to Sonnet 5 at the same time. Every incident below predates that swap, so read the model names as what produced the scars, not as a verdict on the new ones. One gotcha if you follow: Sonnet 5 counts tokens differently and runs about 30% higher for the same text at unchanged per-token pricing, so your first bill after the switch reads worse than it is.
What a stronger writer model actually costs you
The Writer runs on Opus because prose is the one place a stronger model visibly pays off. Voice fidelity. Sentence-length variety. Not sounding like an AI mimicking a human who sounds like an AI. This is the step where the model quality shows up in something a reader can feel, so it’s the step where I spend.
The cost picture: the Claude Max subscription covers the daily pipeline runs. I’m not paying per-token invoices that spike when a post is long. What I pay is different, and I’ll get to it in the accounting section, because it’s not the model bill.
Why the fact-checker has to keep pace with the writer
I said this above but it’s the whole rationale for the routing, so it’s worth stating cleanly. If your writer is Opus and your fact-checker is Sonnet, you have built a system where the best liar in the room is smarter than the cop. The fabricated-experience failure taught me that the hard way. The Fact Checker got upgraded to match the Writer the same week. Match your guard to your threat, not to your budget.
What Actually Went Right (The Wins Aren’t Small)
I’ve spent a lot of words on failures. A review that only listed the crashes would be its own kind of lie. Now that my complaining is out of the way, the wins are real and measurable.
67 posts, daily pipeline, rapid dispatches
Since April, the pipeline has put 67 posts into Google’s index. From a standing start. Zero to 67, unattended.
Traffic is climbing off that base, sitting around 109 organic clicks per 28 days as of this writing. It’s still early. It’s a new site in competitive niches, and 109 clicks is a beginning, not a victory lap. But it’s 109 clicks I didn’t have to hand-write 67 posts to earn, and the curve is going the right direction.
The speed is the part that still surprises me. When the PocketOS database-deletion story broke, I went from idea to a scheduled WordPress post in hours. Same with a rapid-response piece on Claude Haiku. Idea in the morning, a fully researched, fact-checked, illustrated post in the queue by afternoon. A solo human writer doesn’t move at that speed. This pipeline does.
Internal linking and indexing on autopilot
Two quieter wins I’d miss now.
Every time a post goes live, the Publisher scans the existing posts and adds contextual internal links to the new one, both directions. I don’t touch it. The site’s link graph maintains itself.
An indexing watchdog runs every morning, pulling the sitemap and checking each URL against Google’s inspection API. It caught a stale sitemap once, a silent cache failure that would’ve quietly tanked indexing for days before I noticed. Boring, automated, and exactly the kind of thing a human forgets to check until it’s already a problem.
The Real Accounting: What “Automated” Actually Costs
Time for the part every setup guide skips, and the part no other review bothers to total up. Everybody reports how long it took to stand the thing up. Nobody reports what it costs to keep it safe to run unattended. Here’s my accounting.
The scripts you have to write before “autonomous” is true
Count the fixes in the incident section. Every one of them is a script I had to write and now have to maintain:
check-signoffs.py, so the approval gate is enforced in code.wp_publish.py, so publishing is idempotent and can’t double-book.audit-schedule-divergence.py, so calendar and WordPress can’t drift silently.check-ai-tells.py, so em-dashes and AI-tell phrases never ship.- A verify-refresh harness, so edits to live posts don’t quietly break them.
The daily pipeline runs them in sequence before anything ships:
# Guardrail sequence: every one of these has to exit 0 before publish
python3 scripts/check-ai-tells.py {slug}
python3 scripts/check-signoffs.py {slug}
python3 scripts/wp_publish.py {slug}
python3 scripts/verify-refresh.py {post_id}
python3 scripts/audit-schedule-divergence.pyNone of that is “content.” All of it is the difference between a pipeline that runs and a pipeline you can trust to run without you. That code didn’t come free. It came out of my evenings, one incident at a time.
When you’re building guardrails, not content
So the real cost isn’t the Claude subscription. The subscription is the cheap part. The real cost is engineering time, and specifically the kind of engineering time that produces zero new posts. Every guardrail script is an evening I spent making the machine safer instead of making the blog bigger.
Would I have known to build them without a decade of shipping software and a customer-support SaaS in production? Probably not. That Trigli background is why I reached for idempotency and code-level gates instead of adding another paragraph to CLAUDE.md and hoping. If you come to this without that instinct, budget for learning it the expensive way, on live posts, in public. That’s the line item nobody quotes you.
What I’d Build Differently Starting Today
If I were standing this up from scratch tomorrow, knowing what the git history knows, here’s what changes. This is the actionable half, the part you can steal.
Enforce every gate in code from day one. Not in the README. If a rule matters enough to write down, it matters enough to fail a build over. The sign-off gate and the em-dash rule both taught me the same lesson twice.
Make every external write idempotent before it ever runs once. Any operation that creates something on a server you don’t fully control needs to check whether that thing already exists first. Build the upsert before you build the feature. The double-booking mess was one missing lookup.
Audit your credentials and identifiers on a schedule, because they fail silently. The affiliate tag leak ran for weeks because nothing errored. If a value routes money or grants access, put a check on it and run that check daily. Assume the invisible bug is already there and go looking.
Route your models by task, and upgrade your checker whenever you upgrade your writer. A better generator needs a better verifier, or you’ve just made your mistakes more convincing. Match the guard to the threat.
And start in draft mode longer than you think you need to. I moved toward autonomy fast because the demo made it look safe. The demo is always safe. Production is where you find out.
The real pro tip from this whole thing? The pipeline was never the hard part. Standing it up is close to an afternoon of work. Keeping it correct, idempotent, and un-embarrassing for three months straight is the actual job, and it’s the job nobody puts in the tutorial. If you want the tutorial anyway, I wrote the full setup in how I use Claude Code to run this entire blog. And if you want the guardrails mindset before you point an agent at anything live, limiting your AI agent’s blast radius is the post I’d read first.
Sources
- How I Use Claude Code to Run This Entire Blog (And You Can Too): my April 2026 setup post. This retrospective is the “after.”
- Limiting Your AI Agent’s Blast Radius: my post on agent guardrails and why access, not the model, is the real risk.
- I Used Claude Code for 7 Months: Here’s the Honest Review Nobody Is Giving: a strong developer-session review, and a good contrast: zero coverage of autonomous pipelines.
- I Used Claude Code for 30 Days: Here’s What Actually Broke in Production: code-session failures (test logic, context drift), but all inside interactive sessions.
- How I Built an Automated AI Blog (NoCodeLife): a build story with no three-month operational view.
- I Trusted Claude With Production Code. It Nearly Burned Everything Down: the confidence-competence inversion angle, from a single coding incident.
- Is Claude Code Worth It? (PlayCode): a 30-day developer cost-benefit review, useful as a contrast case.
Your Turn
Here’s what I actually want to know. Is anyone else running Claude Code as autonomous infrastructure, not as a coding assistant? Not “I let it write a function.” I mean you pointed it at a live business output, walked away, and let it run on a schedule.
If that’s you, I want to hear what broke. Did you hit the same class of failures I did, the silent ones that don’t error and just quietly do the wrong thing? Or did something break for you that never touched my pipeline? Drop it in the comments. Share this with the one friend you know who’s automating something they probably shouldn’t have automated yet. The interactive-coding crowd has a hundred reviews to read. The people running agents unattended in production have almost none, and I’d rather we compare scars than each pretend we figured it out alone. 🛠️
