August 2026: The AI Demystification Era Is Real. One Indie Dev's Three Defenses

1. Three lines, all showing up today

Scrolling Juejin’s front page today (2026-08-30), a few titles were sitting right next to each other: “I outsourced my thinking to AI. Three months later I became illiterate in my own project”, 👍379. One day earlier, 8-29: “Superpowers: the process poison pill of the GPT-5.6 era” 👍7k and “Why did OpenClaw suddenly stop being popular?” 👍26k dropped on the same day. Before that, 8-25: “I used Codex to rewrite three years of my coworker’s code. He didn’t say thanks. He went to the manager.” 👍18k.

Each one is its own viral post. But put them side by side and a shape shows up that wasn’t there before:

Tool retreat: people installed a pile of agents, and the last two weeks have seen serious discussion of “which ones aren’t actually being used”
Process backfire: Superpowers, opencode 100G, Firebase 6.6.0. Adding process or tools ended up hurting people.
Capability erosion: an architect outsourced thinking to AI, three months later became “illiterate in his own project”

The third line didn’t exist before. Previously it was just the first two plus the tired “AI is replacing me” bit. Today’s 👍379 piece is the first head-of-page post to frame “capability erosion” as a first-person ledger. The third anchor has landed.

The demystification phase didn’t start today, but all three lines showing up on the front page at once is today.

The rest of this post puts three actual incidents from my blog agent cluster this August against those three lines. For each line: what failed, what rule I used to seal it, and where I still haven’t. One indie dev’s ledger.

2. Line one: tool retreat, after the install curve comes the hit-rate curve

Tool retreat gets misread easily.

Since mid-August, head-of-page authors have been writing “which agent tools I uninstalled” and “I used Superpowers for 3 days and deleted it.” Read on the surface, that sounds like “AI tools don’t work.” But if you’re running a multi-agent cluster yourself, you see a colder curve: install count and usage count have decoupled.

My blog agent repo, the six-piece set:

AGENTS.md         - agent entry, loaded first
IDENTITY.md       - who I am
SOUL.md           - voice
TOOLS.md          - hard rules + rule file index
MEMORY.md         - long-term memory
USER.md           - who the user is

Plus three repo-specific files: WRITE_RULES.md (loaded when writing), REVIEW_RULES.md (loaded when reviewing), PUBLISH_RULES.md (loaded when publishing).

From one CLAUDE.md in June to 9 files today, none of the splits came from “sitting down and figuring out how many pieces there should be.” Every one was an incident pinning my face to the floor. The June publishing incident pulled publishing rules out of CLAUDE.md into PUBLISH_RULES.md. The July review-missing-facts incident pulled REVIEW_RULES.md out.

The install curve keeps going up. All 9 files are still there.

The real question is whether they’re actually referenced or followed after installation. In August I did one thing: scanned every published post by hand to check rule hit rate. The “file naming: blog + 3-digit sequence” rule in WRITE_RULES.md hits 100%. “Straight quotes not curly quotes” hits 100% (the build crashes on curly quotes, so it’s a hard signal). But “every post ends with a ‘Further Reading’ section” hits under 60%. Kept getting missed.

The tool-retreat story isn’t really about deleted tools. What’s getting counted is the half that was installed but isn’t taking effect. In the Chinese-language tech circle, “what I uninstalled” is the first wave. The second wave is “what I installed but isn’t working,” and it hasn’t hit yet.

My response wasn’t to cut tools. It was to load rule files by layer (WRITE_RULES.md only gets loaded when the main agent writes), cutting context noise so the installed rules actually get read. Install count isn’t the asset. Hit rate is.

3. Line two: process backfire, three incidents in a row, three bills

Process backfire is the quantifiable line, because there are bills.

Three incidents from my blog agent cluster in August:

8/23 · hot-topics cron sandbox block. The hot-topics cron tried to append new candidates to topic-ideas.md (that 585KB file). Bash heredoc, Python write, tee all blocked by the session sandbox allowed working directories: /. File too large for a single Read+Edit. No money burned this time, caught early. But the candidate draft sat in the cron output and got lost when nobody authorized it.

8/24 · blog-proposal cron burned $1.08 before aborting. The blog-proposal cron triggered at 08:00, ran 16 rounds of tool_use. The last tool_result came back is_error=true, and stop_reason stopped on tool_use (the model wanted to call another tool and got cut off). Burned $1.08. Session logs suggest it was another topic-ideas.md append permission block, with the model stuck in a “I need to Edit this file, blocked, try another tool, blocked” loop.

8/27 · overnight memory-cleanup burned $1.41 and failed. Same root cause, third time. Triggered in the overnight batch window, the task was to sweep expired candidates out of topic-ideas.md (that 585KB legacy file). The first Read+Edit hit the exact same sandbox block as 8/23 and 8/24, then went back into the “try another tool” loop. Common root cause across the three: no fallback path defined for “append to large file” operations, so the model kept banging on the same wall.

The three shared precursors, counted after the fact:

No hard budget cap: no max_turns or max_cost set on the cron, so the model loops and burns
No idempotency: same topic-ideas append fails once, retries; nothing tracks “already ran this”
No sandbox-boundary retry strategy: getting blocked once should fall back to “write to a log for a human to look at,” not try again with a different pose

Superpowers being called a “process poison pill” in August works the same way. The thicker the process, the more concrete the backfire bill. Tools can be A/B compared, process can’t. Once process ships, it’s a global side effect and the crashes compound.

I turned these three precursors into an entry gate for cron-type agents: before adding a new cron, prove “budget cap, idempotency, sandbox fallback” are all present. Since the gate went up, 8/28 through today, the blog agent cluster hasn’t crashed again.

4. Line three: capability erosion, a counter-example beats a lament

The third line is the meanest, because there’s no bill.

The 8-30 architect who wrote “three months later I became illiterate in my own project” got 👍379 and a comment section full of “me too.” Posts like this will keep coming, and they’re real.

But I want to write the opposite side. Over 8 months I had AI write 260+ posts (this one included), and part of the code across 4 repos was written by agents. If “heavy AI use inevitably erodes you” were a law, I should already be illiterate.

I’m not. Three hard rules kept it from happening.

Rule one: only write things you actually have (I logged this as a memory feedback a while back). Don’t write “I did some research,” don’t write “the industry commonly holds,” don’t write “according to sources.” Write things like “my blog agent burned $1.08 on 8/24.” The rule isn’t really about preventing puffing. What it does is force you to check, count, and look at the actual files. Every time you sit down to write, you have to go back and pull the data. Do that daily and the muscle stays.

Rule two: dual skill scan (installed 2026-08-19: humanizer + shuorenhua, pinned to specific commits). After finishing a draft, run shuorenhua for Chinese AI-tell, then humanizer for English. These skills aren’t for polishing. They show you which paragraph is template and which is your own thinking. Every red mark stings a little, and next time you sit down you route around that phrasing. Slow feedback loop, but it trains you, not writes for you.

Rule three: 3-round sub-agent review. Drafts pass through sub-agent review, and I go through the findings by hand deciding what to accept. The interesting part isn’t the findings surfacing. It’s that when you review the review, you argue with it. While you argue, your judgment is working, and you’re using your own head to accept or reject.

Against that architect’s mechanism, you can guess what he lost: he outsourced judgment, and kept execution. He let AI produce solutions and followed them, without the intermediate “why am I accepting this” step. Three months later, judgment muscle atrophied.

Capability erosion’s real mechanism isn’t “AI doing more work.” It’s “me not judging anymore.” This line can be sealed. The seal is forcing every AI output through your own judgment. Do that daily and the muscle stays.

5. Living through demystification: three lines × three hard rules

Putting the three lines and the rules I use in a table:

Line	Failure mechanism	What I use to seal it
Tool retreat	Install count ≠ usage count; installed rules aren’t being read	Layered rule-file loading, plus hit-rate tracking
Process backfire	Thicker process, more concrete bills	Cron three precursors: budget cap, idempotency, sandbox fallback
Capability erosion	Outsourcing judgment while keeping execution	Only write what you have, dual skill scan, 3-round sub-agent review

This table isn’t a best-practice guide. It’s an indie dev’s self-rescue notes after specific bills pinned him to the floor. Your setup is different, so the rules probably are too.

The method is portable though. Demystification doesn’t require doom-posting or white-knuckling. It’s the phase where the cost of using AI becomes concrete. The tool cost is the invisible waste of dropping hit rate. The process cost is the visible $1.08 line on a cron. The capability cost is the loss-of-control feeling of not recognizing your own project three months in. In the belief phase you don’t count these. In demystification you have to.

Next quarter, I’d guess the Chinese-language tech circle splits into three layers:

Chasing-new (install a new agent every week, delete it every week). They’ll keep thinking AI doesn’t work.
Fully exiting (“AI is just a toy”). They’ll miss the compounding.
Building their own rules. Trading each crash for a rule, letting rules compound into an asset.

The third layer is small. But this layer is the line between “people who can wield AI” and “people AI uses” after demystification.

Postscript

This post is itself the product of those rules. The topic came from the blog agent cluster mining daily Juejin trends. Drafting pulled the three raw incident records out of memory. After finishing, it went through dual skill scan, then 3-round sub-agent review. A fail at any step and it doesn’t reach you.

Demystification isn’t the problem. Walking through it without rules is.