DEV Community: GEEK

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

GEEK — Mon, 27 Jul 2026 05:00:00 +0000

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.

Gemma 4 VRAM Requirements: The hardware guide I wish I had

GEEK — Fri, 03 Apr 2026 10:56:58 +0000

Running Gemma 4 locally is amazing, but hardware mismatch is the #1 reason for a bad experience.

I've compiled a practical guide for the different Gemma 4 tiers based on real-world VRAM usage:

E2B / E4B : Perfect for 8GB RAM laptops and workflow validation.
26B A4B : The sweet spot for 16GB-24GB GPU users.
31B : For those who need reasoning quality on 24GB+ hardware. Check out the full breakdown and the Ollama setup guide here: Gemma4Guide

I also included specific optimizations for Apple Silicon (M1-M4) unified memory. What are you running Gemma 4 on? Let's discuss in the comments!

How I Built a Free Derivative Calculator with Next.js 15 & React 19

GEEK — Sun, 18 Jan 2026 09:23:11 +0000

The Problem
I recently needed a reliable derivative calculator that could show step-by-step solutions . While big tools exist, they often lock the detailed steps behind a paywall.

I decided to build my own free tool to solve this. It was also the perfect challenge to push the limits of Next.js 15 and React 19 in a real-world application.

👉 Try it here:Derivative Calculator

The Tech Stack
I wanted the app to be instant and responsive. Here is the stack I chose:

Framework: Next.js 15 (App Router)
UI: React 19 + Tailwind CSS
Math Engine: A custom implementation using nerdamer for symbolic differentiation.
Performance: Web Workers for off-main-thread calculations. ### The Biggest Challenge: Performance Calculating the derivative of a complex nested function (like sin^2(e^(2x)) ) involves heavy recursive processing.

Initially, running this logic on the main thread caused the UI to freeze . The input would lag, and the browser would become unresponsive for a few milliseconds.

The Solution: Web Workers

To fix this, I moved the entire math engine into a Web Worker . This architecture allows the React UI to remain buttery smooth (60fps) even while the engine is crunching through massive equations in the background.

Here is a simplified look at how the architecture works:

// The main thread sends the math expression to the worker
const handleCalculate = async () => {
  setLoading(true);

  // Offload to Worker with a safety timeout
  const workerRes = await computeDerivativeInWorker({
      expression: inputExpression,
      variable: 'x',
  }, {
      timeoutMs: 8000 
  });

  if (workerRes.ok) {
      setResult(workerRes.result);
  }
  setLoading(false);
};

Key Features
Besides performance, I focused heavily on the UX:

Step-by-Step Breakdown: The app explains the Chain Rule, Product Rule, and Quotient Rule as they are applied.
Interactive Graphs: I integrated function-plot to visualize the function and its derivative instantly.
Smart Input: Handling math input on the web is hard. I optimized the parser to handle implicit multiplication (e.g., understanding that 2x means 2*x ) to make it user-friendly. ### Why I'm Sharing This I built this tool to help students and developers who need quick, free math verification.

I'm currently looking for feedback on the User Experience (UX) .

Does the step-by-step explanation make sense?
Is the graph interaction intuitive? Give it a try and let me know what you think in the comments!

👉 https://derivativecalculatortool.online