The hard part of building with AI isn't the code — it's catching the BS

작성자

카테고리:

← 피드로
DEV Community · GEEK · 2026-07-27 개발(SW)
Cover image for The hard part of building with AI isn't the code — it's catching the BS

GEEK

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

  1. 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.
  2. 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.
  3. 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.
  4. 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.

원문에서 계속 ↗

코멘트

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다