Running Accounts with AI Agents Cost Us 4 Channels in 3 Days: A Post-Mortem

An indie developer ran a public experiment: one person plus a small team of AI agents, earning back the monthly AI subscription fee through digital products, with zero paid ads. This is the third post in the series, documenting a costly failure — after letting AI agents run social accounts directly, four channels (Reddit, Hashnode, Xiaohongshu, and X) fell within three days.

First, the cold zeroes: orders on Gumroad, itch, and the Chinese store are all 0, revenue is $0. According to the author's dashboard data at 21:00 on the 12th, the first Dev.to article got 31 views and 1 interaction two days after publishing; the second, less than a day after going live, showed "under 25 views." Gumroad had only 37 views in thirty days, with 0 link clicks from real visitors.

How the Four Channels Were Lost

Reddit: A post that leaned self-promotional got the account permanently banned from r/excel, taking this free channel out of the running for this sprint.

Hashnode: After two articles were published, visiting them while logged out returned 404, and they were later archived by AutoMod. The lesson the author noted is specific — always check your posts while logged out after publishing.

Xiaohongshu: After the AI agent browsed and posted using the account, it received what appeared to be an automation warning; a day later, all notes on the account were flagged. Unless a human manually restarts it, this channel is permanently disabled.

X: The account was restored after an appeal, but logging in from a new device hit an unexpected error. Rather than keep fighting the login loop, the author dropped X for this round.

The pattern the author identified isn't "bad content" — it's three conditions stacking up: a new or cold account + concentrated agent activity + a new device or automated browser.

Account warming is a colloquial term in platform risk-control systems: an account needs a period of genuine human behavior (browsing, liking, intermittent dwell time, irregular logins) to accumulate a trust score, which platforms use to distinguish normal users from automated scripts. Newly registered or long-inactive "cold accounts" naturally lack this historical signal, so risk models assign them a higher risk score. If high-frequency page-flipping, concentrated posting, or non-local device logins appear at this point, the session characteristics alone will get the account flagged as a bot — even if the content itself is compliant. Reddit's shadowban, Xiaohongshu's throttling flags, and X's temporary freezes are all essentially this trust-scoring mechanism at work. So "account warming" isn't superstition — it's the necessary cost of getting past the risk-control cold-start period.

Lesson 1: Platforms That Require Account Warming Punish Agents First

Reddit, Xiaohongshu, and X all require accounts to have near-human behavioral history before they'll trust bulk operations. An agent that flips through many pages right after logging in and posts the same day looks exactly like a script. Even with careful copywriting, the session characteristics alone trigger risk control. The author's conclusion: if a platform rewards account age and daily browsing, don't put an agent on it — either have a human warm up the account for weeks, or skip it.

Browser fingerprinting and session characteristics are the other main thread in risk-control detection of automation. Platforms don't just look at account age — they collect dozens of signals including User-Agent, Canvas/WebGL fingerprints, timezone, font lists, mouse trajectories, and request intervals. Headless browsers or automation frameworks (like Playwright, Puppeteer) typically produce highly consistent default fingerprints and lack the random jitter of human operation, making them easy to detect at scale. Even more subtle is the "new device login" link: the same account logging in from an unfamiliar IP and unfamiliar device fingerprint will itself trigger secondary verification or risk-control downgrading. This explains why the author's agent got flagged even when the copywriting was cautious — the problem isn't what was said, but "how it logged in and how it flipped pages."

Lesson 2: Surviving Channels Judge Content, Not Accounts

Dev.to, itch, and GitHub awesome lists don't require warm-up. Readers or maintainers judge the content directly, which is why they remain open today.

The actual state that evening: both Dev.to articles were accessible while logged out; all four itch tracker pages, divided by role, had real screenshots, plus a PM dev log linking back to Dev.to; three PRs were submitted to GitHub lists (awesome-job-seeking #72, awesome-job-boards #252, Awesome-Job-Search-Resources #6), all of which currently have only bot comments or zero comments. The author notes: no reply isn't a signal, and until a PR is merged, 0 clicks prove nothing. After those three submissions, free lists with normal merge histories are essentially exhausted, and the marginal return on submitting more list PRs this round is close to zero.

GitHub awesome lists are community-maintained repos of quality resources, where new links are submitted via Pull Request and merged after human review by maintainers. They're agent-friendly because the judgment criteria fall entirely on the quality and relevance of the link itself, with no account history or behavioral characteristics involved. But precisely because of human review, maintainer activity varies widely: many repos leave PRs untouched for long stretches, with bot auto-replies and nothing more. The author's remark that "after three PRs the free lists are essentially exhausted" reflects the reality that these channels are limited in number and their merge cycles are unpredictable. For indie developers, awesome lists are better suited as long-term SEO and backlink assets than short-term acquisition channels.

Lesson 3: New Rules Set for the Agents

After being flagged, the author wrote down four hard rules and started enforcing them: only one agent may touch each account — no one else logs in or posts; for platforms with anti-bot detection, use no automation at all — either a human posts manually or the channel is abandoned; QA only reads links and never clicks tracking links, and all of the author's own requests are logged so they can be excluded from browsing and download data; "published" only counts if the page opens while logged out.

Did the Data Change After Adding Real Screenshots?

The author filled in sample tables on all four itch tracker pages (SWE, data analysis, PM, UX). As of 20:55 on the 12th: PM had 7 views / 2 downloads, UX 7/1, DA 6/1, SWE 2/1 — unchanged from the 14:30 check that day. A search check showed none of the four pages appearing in tag-productivity, tag-notion, or the search results for "job tracker" or "notion job tracker." The author also acknowledges a confounding variable: the CTA copy was changed during the same window, so this wasn't a clean A/B test.

The Next 48 Hours

The existing CTA on the itch tracker pages ends at 22:35 Beijing time on the 13th. After that, the author will test a new headline only on the data analysis page ("Referrals, job boards, or the company site: which actually lands you a data analysis interview?"), keeping the other three pages unchanged so it's possible to tell whether the headline itself makes a difference. No new PRs will be submitted to GitHub lists; on the 14th, the three open PRs will be checked for replies, and only merged links count as clicks. The fourth Dev.to post will go out on the 15th, giving the final data before the 16th deadline — and if it's still $0, that'll be reported honestly too. The rules stay the same: one account, one agent; don't touch platforms with anti-bot detection; don't add channels that require account warming.

If you're also running agents on real accounts, what got you flagged? The author is waiting in the comments to swap experiences.

Free tracker link: https://itch.io/c/8301723/free-notion-job-application-trackers-by-role

Additional Context

The cleanliness of A/B testing is a flaw explicitly acknowledged in this experiment. The author changed the CTA copy while checking itch data, causing two variables — "adding real screenshots" and "changing the copy" — to move simultaneously, making it impossible to attribute results to either one. Rigorous A/B testing requires changing only one variable at a time, with sufficient sample size and even random splitting. When an indie developer's traffic is already thin (single-digit views), any minor external fluctuation drowns out the real signal — which is why the author plans to change only one headline next while keeping the other three pages unchanged. It's a pragmatic way to approximate a controlled experiment under small-sample conditions.

One-line Summary

An indie developer let AI agents run social accounts and lost four channels — Reddit, Hashnode, Xiaohongshu, and X — in three days, with revenue still at $0.

Paragraph Summary

An indie developer documents the third week of an experiment running digital products with AI agents: orders and revenue on Gumroad, itch, and the Chinese store are all 0, and Dev.to articles have only 31 views. The bigger setback was in social channels — the Reddit account was permanently banned from r/excel, Hashnode articles were archived by AutoMod, Xiaohongshu got flagged for automation, and X got stuck in a login loop after recovery. The author identifies a common pattern: new account + concentrated agent activity + new device login — not content quality. Four rules follow: one agent per account, zero automation on anti-bot platforms, QA never clicks tracking links, and logged-out accessibility is the only measure of "published." Dev.to, itch, and GitHub lists survived because they judge content, not accounts. The next 48 hours will test a single headline change and wait on GitHub PR merges.