DEV Community: GEEK

What Actually Happens When You Run `npx @deepseek-ai/dsh web`

GEEK — Mon, 17 Aug 2026 12:29:33 +0000

DeepSeek Harness (DSH) got a lot of attention for being usable with a single line:

npx @deepseek-ai/dsh web

That opens a local Web UI at http://127.0.0.1:3080. It genuinely works. But "it started" and "I know what I'm running" are different things, and the answers to the obvious follow-up questions — why is it asking for an API key, why is the composer locked, what does "everything is a plugin" mean for me, is a random plugin safe — are spread across four different files in the official repo.

I've been assembling a reference site for DSH, which meant reading all four closely. This post connects them. Every claim below is from the official docs; I'm just holding the pieces together.

1. `dsh` is a launcher, not the app

The CLI spec describes itself precisely:

The dsh command is the product launcher for profiles: ordered stacks of plugin-bundle patch layers under the user's own overrides.

When you run npx @deepseek-ai/dsh web:

The launcher parses only its own flags (src/args.ts owns the grammar; bin.ts loads only the selected runner). Invalid commands, options from another mode, config errors, and boot failures exit nonzero — good news if you script around it.
web is an alias for --profile web, which boots a profile living under $DSH_HOME/profiles/web.
The web and headless profiles auto-initialize from shipped templates on first use. That's why zero-config works. Any other profile name must be created through dsh plugin.
A detail people miss: your current working directory becomes the default filesystem root. "The dsh process uses its invoking directory as the default filesystem location." Where you launch from is not a neutral choice.

2. "Everything is a plugin" is a layering system, not a slogan

Each profile directory holds a package.json (with a dsh.profile manifest listing ordered bundles) and a cordis.patch.yml (your override layer). The final plugin tree composes in this order:

each bundle's patch, in dsh.profile.bundles order
→ the profile's own cordis.patch.yml
→ the home-level $DSH_HOME/cordis.patch.yml
→ --patch command-line overlays

Bundle resolution: built-ins first (@deepseek-ai/dsh-base, dsh-web-app, dsh-headless, installed with dsh itself), then the profile's own node_modules — which is exactly where third-party plugins land.

This architecture explains both halves of the DSH experience:

The flexibility: swapping models, tools, session storage, even the UI is a config change, not a fork.
The warning: the README capitalizes "THERE WILL BE COMPATIBILITY-BREAKING CHANGES." When the whole product is a composed tree, any layer's interface change ripples upward. In developer preview, that's structural, not attitude.

3. The three gates of first run

Gate 1: API key. Settings → Models, paste, save. Three details worth knowing:

No restart needed. "Model changes take effect on the next request without restarting the server." Just use it.
Keys are write-only: after saving, the UI only ever shows a redacted descriptor. You can't read it back.
The key lives in $DSH_HOME/.credentials.yaml; settings retain only a credential reference. Keep that in mind before you sync or screenshot config directories.

Gate 2: workspace. The guide is blunt: "The session composer remains unavailable until a workspace is selected." The composer is locked, not broken — click Choose workspace, add the directory you launched dsh from, and select it. The agent reads, edits, and runs commands around that workspace, and the UI asks for approval on operations that require it under the active permission policy.

Gate 3: the first task. The official guide suggests:

Summarize this repository and identify its main packages.

It's a good first prompt because it's read-only and easy to verify by hand. Get one read-only task fully working before you let an agent touch code.

4. The vision-model gotcha

If you add a custom model by hand, DSH treats it as text-only by default: "A model you entered by hand is treated as text-only until it says otherwise." To accept images, declare the modality on the model in $DSH_HOME/settings.yaml:

llm-pi-ai:
  providers:
    my-gateway:
      apiKeyEnv: GATEWAY_API_KEY
      api: openai-completions
      baseURL: https://gateway.example/v1
      models:
        - id: vision-preview
          input: [text, image]

And the sharper edge, straight from the docs: DeepSeek's own chat-completions route is text-only and cannot be configured otherwise. Vision requires a custom provider with a vision model, or a community plugin. Most people learn this only after an attachment gets refused.

5. Third-party plugins are npm packages

The plugin command's mechanics are one sentence in the CLI spec:

dsh plugin --profile <name> <pnpm args>

It forwards your args to pnpm inside the profile directory. A third-party plugin is a regular npm dependency running under your user permissions. Same threat model as any npm install: think postinstall scripts, env vars, network access. The Awesome list explicitly says listing ≠ security review.

Before installing, check at least: the repo's activity, the license, what its install scripts do, and which capabilities it actually needs (files, shell, network, credentials). The official discovery surface is the GitHub dsh-plugin topic — the README asks plugin authors to tag their repos with it.

6. Preview-era survival kit

See the composed tree without booting anything:

dsh --profile web --dump-default-config   # what the default composition is
dsh --profile web --dump-config           # what YOUR composition actually is

This is the most underused debugging command in the whole CLI. "Is my config even in the tree?" — answered statically.

One-shot, no UI:

dsh --profile headless "Inspect the repository and fix the failing tests."

Runs a fresh persisted session, prints the final answer, exits. Scriptable by design.

Python SDK: pip install deepseek-harness-sdk ships a bundled runtime — no system Node.js required. Two caveats from the guide: the checked-in example composition runs danger-full-access (use a disposable checkout or container), and its persistent PTY backend needs POSIX, so no Windows agents in that composition.

Wrapping up

None of this is secret — it's all in the repo. It's just spread across the README, the CLI spec, and two guides, and nothing links the launcher to the first-run experience end to end. Once you see the shape — launcher → profile → layered plugin tree → workspace-gated session — the individual behaviors stop being surprising.

I maintain a community reference for exactly this kind of thing — install paths, a curated plugin directory with permission notes, compatibility and troubleshooting pages, organized around "finish your first real task": deepseekharness101.com. The plugin directory and troubleshooting section are the most-linked pages.

Docs will drift — it's a preview. The mechanisms won't. Good first run.

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