A game called Pathogenic launched on July 16. It's a roguelike where you play as a parasite inside the human body. By launch day, I had a full wiki for it live: guides, databases, patch notes, the works.
I'm not a developer. I'm a product manager. I don't write code. I used an AI coding agent (Claude Code) to build the whole thing — Next.js, Cloudflare Workers, SSR, the content pipeline, all of it.
And the experience taught me something that I think gets lost in the "AI will replace developers" discourse:
The code was the easy part. The hard part was catching the bullshit.
What "building with AI" actually looks like
Here's my actual workflow. I don't open an editor. I open a terminal and talk to an AI agent in plain language — English, actually Chinese most of the time, since that's my first language. I say things like "rewrite the beginner guide to be more player-facing" or "the Co-op page needs a troubleshooting section." The agent writes the code, edits the data files, runs the build, runs the tests, deploys to production.
It's fast. Shockingly fast. A full guide page — 1,200 words of content, structured data for SEO, optimized images, internal links, FAQ section — takes maybe 20 minutes from idea to deployed.
But here's what nobody tells you: the AI will confidently write things that are wrong, and they'll look completely right.
The content quality trap
My wiki covers game mechanics. Things like "how does Overcharge work" and "what's the Brain boss weak to." These are factual claims. If I publish wrong information, players lose trust instantly.
Early on, I told the AI to research how Burn damage works in the game. It came back with a beautifully written explanation — specific organelles, damage numbers, stacking rules. Sounded perfect.
None of it was real.
The AI had pulled fragments from medical literature (pathogenic bacteria, burn wounds) and a completely different board game called "Pathogenesis" and woven them into something that looked authoritative. If I'd published that, the wiki would have been dead on arrival.
So I built a rule: every claim has to link to a source. Official patch notes, developer replies, or community gameplay videos. If I can't source it, I don't publish it. The AI does the research; I verify the research.
Where it got real
Last week, a player commented on my Steam guide. They said: "There is a shop in the Brain area."
My guide said there was no shop. I had written that confidently, based on the fact that a gameplay video I watched didn't show one. The AI had helped me write it.
The player was specific: the shop barely gives you currency, but the parts are always legendary tier.
I had two choices: trust the player's comment and change my guide, or verify first.
I almost changed it immediately. My instinct was "a player who's actually played the Brain knows more than I do." But then I caught myself. One comment isn't verification. I searched for independent confirmation. Couldn't find any. The video I'd watched didn't mention a shop either — but that's not the same as confirming there isn't one.
So I changed the wording to something neutral: "finish your build before entering the Brain." Not "there's no shop" and not "there is a shop." Just practical advice that works either way.
That's the job. Not writing content. Not writing code. Catching the moments where something sounds right but isn't confirmed, and making a judgment call.
What I actually spend my time on
If I'm honest, the split looks like this:
- 20% telling the AI what to build
- 30% reviewing what it produced
- 30% verifying facts against sources
- 20% arguing with the AI about tone
That last one is real. The AI writes in this weird "helpful assistant" register — everything is "comprehensive" and "seamless" and "it's worth noting that." I spend a lot of time saying "stop sounding like a wiki editor, sound like a player who knows the game."
The code part? I barely think about it. The agent handles the build, the deployment, the SEO headers, the structured data. It even caught a regression once — I changed a shared component and it broke another guide page. The agent noticed before I did.
What I'd tell someone starting the same thing
- The AI is fast but not trustworthy. Treat it like a brilliant intern who occasionally hallucinates. Every factual claim gets verified. Every "I checked the sources" gets re-checked by you.
- Pick a niche with verifiable facts. A game wiki works because there are patch notes, developer posts, and gameplay videos to check against. If I were building a marketing blog, I don't know how I'd verify anything.
- The quality bar is yours, not the AI's. The AI will happily publish a 2,000-word guide that's 80% correct and 20% fabricated. That 20% will destroy your credibility. You have to be the one who catches it.
- Engage with your community. The player who corrected my Steam guide did me a favor. I learned something. And when I thanked them and said "I'll verify this," it built more trust than if I'd just silently changed the text.
The site
If you're curious: Pathogenic Game Wiki. It has guides for the Brain route, Brain Boss fight, Overcharge mechanics, a Burn build, Co-op setup, and a beginner guide. Every claim links to its source. The ones that aren't confirmed say so.
I'm not claiming this is the future of development. I'm saying: for a non-coder with a clear content vision and a strict quality bar, the tools are finally good enough to ship real things. The bottleneck moved from "can I build this?" to "is this actually correct?" — and that's a much more interesting problem.
Top comments (7)
"The bottleneck moved from 'can I build this?' to 'is this actually correct?'" — same trajectory here. I'm a non-developer too; I've built a pile of internal tools with AI, and the building stopped being the constraint a long time ago. Verification is the whole job now, and your 30% fact-checking line is the honest version of a number most people don't publish.
The one risk I'd flag is in that number rather than your process, because it's the failure I actually lived: 30% isn't stable. It's high while the AI is visibly wrong, and it quietly drops as the output starts looking reliable — which is precisely when a confident fabrication gets through, because it arrives looking exactly like the last fifty correct ones. I had a checker of my own sitting green for weeks while it was silently mis-scoring six files, and I never opened the report. Not because I don't verify — because it looked fine, and a fluent green never asks to be opened. My discipline failed in the one shape it can't see.
So the thing I'd add to your four habits: make one of them not depend on you remembering. Yours are all human-executed — source-linking, re-checking, hedging — and those degrade in exactly the direction attention degrades. For a wiki the cheap version might be a script that fails the build on any factual claim without a source link, so the rule holds on the days you're tired rather than only on the days you're careful. Your Steam commenter is the other half of that, and you already treat corrections as claims to verify rather than accept, which is the part most people skip.
This is a great point! and your six-file example is exactly the kind of failure my “30% fact-checking” number does not fully capture.
The dangerous moment is not when AI looks unreliable. It is when it has looked reliable for long enough that we stop opening the green report. “A fluent green never asks to be opened” is a very accurate way to put it.
I agree that the missing habit is to move verification out of memory and into the workflow. Fail the build when claims have no source, automate whatever checks can be automated, and still review a random sample of outputs that look completely fine.
In other words, verification should not depend on how suspicious I happen to feel that day.
Thanks for pushing the argument one step further. I think this is an important addition to the article.
The random-sample item is the one I don't have, and reading your list made me see why that's a real hole rather than a nice-to-have.
Everything I've automated shares one limitation: I can only plant failures I already know are failures. My scanner gets seeded with known-bad patterns, my guards get deliberately broken to prove they still fire — but every category of mistake I've never encountered has a permanent, invisible 100% pass rate in that setup. Gates only cover the space my imagination already reached. Sampling output that looks completely fine is the only step on your list that can find something I wasn't looking for, because it goes in with no hypothesis at all. That's a different job from verification, and I'd been treating automation as if it covered both.
The trap I'd flag, using your own closing line: random sampling is the most memory-dependent habit on the list. Nothing prompts it. There's no failure to react to — by definition you're inspecting things that look fine, on a day when nothing is wrong, which is exactly the state in which I reliably don't do optional work. So it has to be scheduled and countable the same way the automated checks are: N samples a week, logged, and the absence of the log is itself the alarm. Otherwise "review a random sample" quietly becomes "review a sample when I feel uneasy," which is the dependency you just named. Thanks for the exchange — the sampling point is going into my setup, and it's the part I'd have never arrived at alone.
ngl that part about hallucinations is so real. spends 2 hours debugging only to realize the ai just made up a library that doesnt exist lol
Yep, totally get it, AI hallucinations are the worst
ngl the hallucination part is the worst, spent like three hours yesterday debugging a library function that didn't even exist lol
ngl the hallucination part is the worst. feels like i spend more time debugging the ai's logic than actually writing the features lol