DEV Community: Devanshu Biswas

I Built a Custom Tool Server for Claude in 250 Lines of TypeScript

Devanshu Biswas — Mon, 01 Jun 2026 13:58:11 +0000

Open Claude Desktop. Ask it: "What's on the Wikipedia article about WebAssembly?"

Without any plugin, it'll guess from training data. With the server I'm about to show you, it'll call a tool named wiki_extract, fetch the real article live, and read it to you. Same client. Same model. Different tools. That switchover is the whole point of the Model Context Protocol.

MCP, released by Anthropic in late 2024, is the open standard that finally answers "how do I give an LLM real-world tools?" Before MCP, every AI app rolled its own plugin system. After MCP, you write a server once and every compatible client speaks to it the same way — Claude Desktop, Cursor, Continue.dev, Zed, custom agents you build with the Anthropic SDK.

Today I'm going to walk you through building one. The whole server is 250 lines. The whole thing.

The mental model

┌─────────────────┐   JSON-RPC 2.0   ┌──────────────────┐   HTTPS   ┌──────────────┐
│ Claude Desktop  │ ◄─── stdio ────► │ your MCP server  │ ◄───────► │  Wikipedia   │
│   (client)      │                  │    (Node.js)     │           │   (REST API) │
└─────────────────┘                  └──────────────────┘           └──────────────┘

Three things happen in this triangle:

The client spawns your server as a child process when the app launches.
They talk JSON-RPC 2.0 over stdio — the server reads requests from stdin and writes responses to stdout. The wire format is the same one the Language Server Protocol has used since 2016 (yes, the protocol behind every "Go to definition" feature in VS Code).
The model decides when to call tools. Your server provides the tools, the model picks which to call and with what arguments, the client routes the calls, your server runs them and returns results.

That's the whole protocol.

Step 1: scaffold

mkdir mcp-from-zero && cd mcp-from-zero
npm init -y
npm install @modelcontextprotocol/sdk zod
npm install -D typescript @types/node tsx

@modelcontextprotocol/sdk is the official Anthropic SDK. It does all the JSON-RPC framing for you — you write tool handlers, the SDK speaks the wire format.

Step 2: minimal server with stdio transport

import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js'
import { StdioServerTransport } from '@modelcontextprotocol/sdk/server/stdio.js'

const server = new McpServer({
  name: 'mcp-from-zero',
  version: '0.1.0'
})

const transport = new StdioServerTransport()
await server.connect(transport)
console.error('ready on stdio')   // NOTE: stderr, not stdout!

That's a fully working MCP server. It does nothing useful yet — no tools — but a client can initialize against it and read capabilities. Nine lines.

⚠️ One trap to avoid: never log to stdout. The stdio transport reads JSON-RPC frames off stdout. Any console.log corrupts the wire format and the client drops the connection silently. Use console.error (which goes to stderr) for everything.

Step 3: add a tool

import { z } from 'zod'

server.tool(
  'wiki_search',
  'Search Wikipedia for article titles matching a query.',
  {
    query: z.string().min(1).describe('Search query, e.g. "WebAssembly".'),
    limit: z.number().int().min(1).max(20).default(8)
  },
  async ({ query, limit }) => {
    const hits = await searchWikipedia(query, limit)
    return {
      content: [{ type: 'text', text: hits.map(h => `${h.title} — ${h.url}`).join('\n') }]
    }
  }
)

Five interesting things here:

server.tool(name, description, schema, handler) — that's the entire API. The SDK wires up tools/list and tools/call JSON-RPC handlers automatically.
Zod schema → JSON Schema. The SDK converts your Zod definitions into JSON Schema so MCP clients get parameter docs + validation for free. The model sees the same schema the client sees — it knows what arguments to send.
The .describe() calls matter a LOT. The model reads them as natural language. Better descriptions = better tool selection. "Search query, e.g. 'WebAssembly'" beats "string."
The handler returns content blocks. Each block has a type (text, image, resource_link) and a payload. The model reads them as part of its context.
Async out of the box. Tools can hit databases, call APIs, run subprocess — anything. The SDK awaits and serialises the result.

Step 4: the Wikipedia client

async function searchWikipedia(query: string, limit: number) {
  const u = new URL('https://en.wikipedia.org/w/api.php')
  u.searchParams.set('action', 'opensearch')
  u.searchParams.set('format', 'json')
  u.searchParams.set('search', query)
  u.searchParams.set('limit', String(limit))
  const resp = await fetch(u.toString(), {
    headers: { 'User-Agent': 'mcp-from-zero/0.1 (contact: you@example.com)' }
  })
  if (!resp.ok) throw new Error(`HTTP ${resp.status}`)
  const [, titles, snippets, urls] = await resp.json() as [string, string[], string[], string[]]
  return titles.map((title, i) => ({ title, snippet: snippets[i], url: urls[i] }))
}

Wikipedia's REST + Action APIs are free, no key, no account. They ask one thing: send a polite User-Agent with a contact URL so they can throttle abusers without blocking polite traffic.

Step 5: resources

Tools are things the model calls. Resources are things the client pulls on its own.

server.resource(
  'wiki-trending',
  'wiki://trending',
  { title: 'Trending Wikipedia articles', mimeType: 'text/plain' },
  async (uri) => ({
    contents: [
      { uri: uri.toString(), mimeType: 'text/plain', text: await getTrendingArticles() }
    ]
  })
)

Resources are great for context the client might want to inject without spending model tokens on a tool call first — daily reports, glossaries, config files, recent activity. The model only sees them if the client decides to put them in the conversation.

Step 6: hook it into Claude Desktop

{
  "mcpServers": {
    "mcp-from-zero": {
      "command": "node",
      "args": ["/path/to/mcp-from-zero/dist/index.js"]
    }
  }
}

Drop that into Claude Desktop's claude_desktop_config.json (macOS: ~/Library/Application Support/Claude/, Windows: %APPDATA%/Claude/). Restart the app. Bottom-right tool icon now shows your three tools.

Try: "Use the wiki_extract tool to summarise the article on entropy."

Claude picks the tool, sends the request to your server, your server hits Wikipedia, returns the text, Claude reads it, writes a summary. The whole loop happens inside the chat.

Why MCP matters

If you've been watching the AI-agents wave the last twelve months thinking "every demo has a different tool API," MCP is the answer.

One server fits every client. Build mcp-from-zero once, it works in Claude Desktop, Cursor, Continue.dev, Zed, and any custom agent that imports the Anthropic SDK.
One spec across vendors. Microsoft and OpenAI have both publicly committed to supporting MCP. The major IDE makers shipped it within months.
Capability negotiation up front. Clients tell servers what they support (sampling, completion, logging) before any model call.

This is the USB-C moment for AI integrations. One cable, every device. The reason MCP went from "neat protocol" to "everywhere" in six months is that the distribution model finally fits: build once, ship to every chat / IDE / agent simultaneously.

What this changes for you

Five years ago you'd write a Slack bot. Three years ago you'd write a ChatGPT plugin (deprecated 2024). Last year you'd write a Custom GPT (locked to OpenAI). Today you write an MCP server, push it to npm, and any AI client running on any user's machine can install it.

The code for this demo is on GitHub, with eight step-by-step commits you can follow. Clone it, hook it into Claude Desktop in two minutes, and you've now extended your AI client with a tool you wrote yourself. That's the whole point.

Welcome to MCP.

🔗 Code: github.com/dev48v/mcp-from-zero
📚 Series: TechFromZero — a new technology every day, all free, all open source.

I Compiled Rust to WebAssembly and Made My JavaScript 6 Faster

Devanshu Biswas — Mon, 25 May 2026 05:21:24 +0000

Click the Gaussian blur button on wasm-from-zero.vercel.app.

WASM: 38 ms. JS: 182 ms. Speedup: 4.8×.

That gap is the whole point of WebAssembly. Same algorithm. Same image. Same browser. But one version ran a hot inner loop compiled from Rust through wasm-bindgen to a 12 KB binary, and the other version ran the same loop as JavaScript. The browser optimised both. Wasm won by almost an order of magnitude.

This is the trick that powers Figma, Photoshop on the Web, Google Earth, AutoCAD Web, and a lot of the "wait, that runs in a browser tab?" demos you've seen the last three years. It used to take a six-month port of a C++ engine to ship. Today it takes a Cargo.toml, one wasm-pack build, and an import statement.

The mental model

WebAssembly is a binary format that runs in every modern browser. It's not a programming language — it's an assembly-like target you compile to, the same way you compile to x86_64 or ARM. The languages that target wasm today: Rust, C, C++, Go, Zig, AssemblyScript, Swift, Kotlin, Dart, .NET. Anything with an LLVM backend, basically.

The browser doesn't run your wasm under an interpreter. It JIT-compiles it to actual native machine code, then runs it at near-native speed. The wasm engine in V8 (and SpiderMonkey, JavaScriptCore) is the same engine that runs your JavaScript — it just gets to skip the type-inference + bailout dance JS needs, because wasm is already statically typed.

For pure compute hot loops, that means: no boxed numbers, no hidden classes, no deopts, no GC pauses. Just tight code that does the work the source said to do.

Step 1: write the kernel in Rust

use wasm_bindgen::prelude::*;

#[wasm_bindgen]
pub fn grayscale(pixels: &mut [u8]) {
    for chunk in pixels.chunks_exact_mut(4) {
        let r = chunk[0] as f32;
        let g = chunk[1] as f32;
        let b = chunk[2] as f32;
        let luma = (0.299 * r + 0.587 * g + 0.114 * b) as u8;
        chunk[0] = luma;
        chunk[1] = luma;
        chunk[2] = luma;
    }
}

The #[wasm_bindgen] attribute is the magic. It generates the glue code that lets JavaScript pass a Uint8Array directly into Rust's &mut [u8] — and Rust to write back to the same bytes. No serialisation, no JSON round-trip, no copy across the language boundary.

Why does that matter? Because the canvas pixel buffer is a Uint8ClampedArray. The wasm function gets to point at the canvas's actual memory and rewrite it in place. Zero overhead between the JS world and the Rust world.

Step 2: compile to wasm

docker run --rm -v "$PWD/rust:/work" -w /work rust:1-slim \
    bash -c 'cargo install wasm-pack --locked && wasm-pack build --target web'

The output is a pkg/ folder with three files that matter:

wasm_from_zero_bg.wasm — the actual binary, ~10 KB for the four filters in this demo
wasm_from_zero.js — wasm-bindgen-generated ES module wrapper
wasm_from_zero.d.ts — TypeScript definitions, autogenerated from the Rust signatures

You import it like any other module. No bundler plugin needed (Vite handles the .wasm URL resolution natively):

import init, { grayscale, invert, sepia, blur } from './wasm/wasm_from_zero'

await init()           // one-time: fetch + instantiate the .wasm
grayscale(pixels)      // direct function call from here on

That await init() is the only async work. After it resolves, every filter call is a synchronous function invocation with zero per-call overhead.

Step 3: feed it the canvas

const ctx = canvas.getContext('2d')!
const data = ctx.getImageData(0, 0, w, h)

// Canvas hands us Uint8ClampedArray; wasm-bindgen's &mut [u8] wants
// Uint8Array. Same memory, different TS type — wrap a view, zero copy.
const pixels = new Uint8Array(data.data.buffer)

grayscale(pixels)              // wasm mutates in place

ctx.putImageData(data, 0, 0)   // paint result

That's the whole bridge. Read the pixels off the canvas, hand them to wasm, write the result back. The wasm linear memory and the canvas buffer are the same bytes — the function call is just "go process this 4 MB pointer."

Step 4: race it against JavaScript

The killer demo is to run the exact same algorithm in plain JS and time both. I ported every kernel from Rust to JS byte-for-byte:

export function grayscaleJs(pixels: Uint8ClampedArray) {
  for (let i = 0; i < pixels.length; i += 4) {
    const luma = 0.299 * pixels[i] + 0.587 * pixels[i+1] + 0.114 * pixels[i+2]
    pixels[i] = luma
    pixels[i+1] = luma
    pixels[i+2] = luma
  }
}

Same 0.299, 0.587, 0.114. Same loop shape. Same memory access pattern. The JS engine has every chance to optimise this — and it does, decently. But it can't escape the boxing of pixels[i] * 0.299 (the JS spec says that's a float64 multiplication, even though the result will be stored as a Uint8Clamped). Wasm just multiplies u8 * f32 directly.

On my laptop:

Filter	WASM	JS	Speedup
invert	6 ms	9 ms	1.5×
grayscale	7 ms	14 ms	2×
sepia	9 ms	22 ms	2-3×
blur (3×3)	38 ms	182 ms	4.8×

The pattern: the bigger the per-pixel arithmetic, the wider wasm's lead. invert is 255 - v × 3 channels, so cheap that JS almost catches up. The 3×3 Gaussian blur reads 9 neighbour pixels × 3 channels per output pixel — 27 million multiply-adds on a 1 MP image. That's exactly the shape where wasm pulls ahead.

What this changes

Five years ago, you wrote your image filters in JS and either accepted the slowness or stood up a Python service. Today, you stick the hot loop in a Rust crate, run one build, and ship a 10 KB binary alongside your bundle.

The interesting thing isn't the speedup — it's the distribution model. You're not asking the user to install anything. You're not running a server. The binary just rides along with your JS bundle. The browser caches it. It runs sandboxed by the same security model as JS. It works on every modern browser including mobile.

If you've been holding off on "real" graphics, audio, video, ML, crypto, parsing work in the browser because "it'd be too slow in JS" — that excuse is gone.

The code for this demo is on GitHub, with eight step-by-step commits you can follow. The live version is at wasm-from-zero.vercel.app. Open it. Click Gaussian blur. Watch the speedup card light up.

That's WebAssembly.

🔗 Code: github.com/dev48v/wasm-from-zero
🌐 Live demo: wasm-from-zero.vercel.app
📚 Series: TechFromZero — a new technology every day, all free, all open source.

I Built a Text-to-Image Search Engine That Runs Entirely in the Browser

Devanshu Biswas — Sat, 23 May 2026 21:51:08 +0000

Type "a corgi on grass." Out of 24 photos in the gallery, the corgi rises to the top. Score: 0.31.

Type "something to eat." A bowl of strawberries, a plate of pasta, and a wood-fired pizza take the medal positions. Score range: 0.25 – 0.27.

No server. No API key. No image got uploaded anywhere. The whole pipeline — a 150 MB neural network and 24 image embeddings — lives in a tab in your browser.

This is CLIP, the model that quietly powers a huge slice of modern computer vision. And in 2026, you can ship it on Vercel for free.

The idea behind CLIP

OpenAI released CLIP in 2021 with one beautifully simple idea: train one model to put text and images into the same vector space.

That's it. That's the whole trick.

CLIP has two encoders. The text encoder turns "a corgi puppy" into a 512-dimensional vector. The vision encoder turns a photo of a corgi into a 512-dimensional vector. They were trained on 400 million (caption, image) pairs scraped from the web so that paired text and images end up near each other in that vector space.

Once that's true, you can do search the way a database does it. The distance between the vector for "a corgi puppy" and the vector for an actual corgi photo is small. The distance between "a corgi puppy" and a photo of an astronaut is large. Sort by distance. Done.

"a corgi puppy"  ─▶  text encoder  ─▶  [0.04, -0.12, 0.07, ...]  ─┐
                                                                   ├─▶  cosine sim
[image bytes]    ─▶  vision encoder ─▶  [0.05, -0.10, 0.08, ...]  ─┘

The math at the end is two for-loops and a multiplication:

function cosineSim(a: Float32Array, b: Float32Array) {
  let dot = 0
  for (let i = 0; i < a.length; i++) dot += a[i] * b[i]
  return dot
}

That's it. That's the search engine.

Why this matters

If you understand "embed everything into the same vector space and compare with a dot product," you understand the heart of:

Pinterest's visual search. "Find me more like this."
Stable Diffusion's text conditioning. "Generate this prompt" is "find a region of vector space the model has learned to produce."
Dataset deduplication. "Which of these 50 million images are near-duplicates?" Cluster by vector distance.
Zero-shot classification. "Is this a cat, a dog, or a goat?" Encode the three labels, encode the image, take the closest.
Content moderation at scale. "Is this image semantically similar to the policy violations we've labelled?"

Every one of these has been a multi-million-dollar engineering problem for some company in the last five years. The core trick is what we're about to build in 200 lines of TypeScript.

Step 1: load CLIP into the browser

The thing that used to require a Python server with a GPU now runs in a tab. The library doing this magic is Transformers.js — Hugging Face's port of their Python transformers library to ONNX Runtime in JavaScript.

import {
  AutoTokenizer, AutoProcessor,
  CLIPTextModelWithProjection, CLIPVisionModelWithProjection
} from '@xenova/transformers'

const MODEL_ID = 'Xenova/clip-vit-base-patch32'

const [tokenizer, processor, textModel, visionModel] = await Promise.all([
  AutoTokenizer.from_pretrained(MODEL_ID),
  AutoProcessor.from_pretrained(MODEL_ID),
  CLIPTextModelWithProjection.from_pretrained(MODEL_ID),
  CLIPVisionModelWithProjection.from_pretrained(MODEL_ID)
])

First visit: ~150 MB of ONNX weights stream from the Hugging Face CDN into your browser's Cache API. Every visit after that: a few hundred milliseconds.

Step 2: encode a phrase

async function encodeText(text: string) {
  const inputs = tokenizer(text, { padding: true, truncation: true })
  const { text_embeds } = await textModel(inputs)
  return l2normalise(text_embeds.data)   // 512-d Float32Array
}

The text_embeds field is the projected vector — the one that lives in the shared space. The un-projected hidden state is the wrong vector to compare against.

We L2-normalise (divide by length) so cosine similarity reduces to a dot product. This is the kind of small detail nobody explains in tutorials but matters: without normalisation, your ranking becomes "which image is bright" not "which image matches your query."

Step 3: encode an image

async function encodeImage(url: string) {
  const image = await RawImage.read(url)
  const inputs = await processor(image)
  const { image_embeds } = await visionModel(inputs)
  return l2normalise(image_embeds.data)
}

The processor handles resize → centre-crop → normalisation with CLIP's specific mean/std values. The vision model is a Vision Transformer — it cuts the 224×224 image into 7×7 patches of 32×32 px, treats each patch as a token, runs them through a transformer (yes, the same architecture as GPT), and projects the [CLS] token down to 512-d.

Same 512-d. Same space as the text. That's the whole magic.

Step 4: rank

const queryVec = await encodeText("a corgi on grass")
const imageVecs = await Promise.all(images.map(img => encodeImage(img.url)))

const ranked = imageVecs
  .map((v, i) => ({ image: images[i], score: cosineSim(queryVec, v) }))
  .sort((a, b) => b.score - a.score)

That's the search engine. Eight lines.

Step 5: cache so it stays fast

The model weights cache in the Cache API automatically. But re-encoding 24 images on every visit is ~5 seconds of WASM work for no reason — the vectors don't change. Stash them in IndexedDB keyed by image id + model id:

const STORE = 'embeddings'

async function putCached(modelId: string, imageId: string, vec: Float32Array) {
  const db = await openDb()
  const tx = db.transaction(STORE, 'readwrite')
  tx.objectStore(STORE).put(vec.buffer, `${modelId}::${imageId}`)
}

48 KB for the whole gallery. Warm reloads now feel instant.

What this changes

Five years ago, "text-to-image search" was a paper. Two years ago, it was a Python server with a GPU and an SDK. Today, it's a Vercel deploy.

The line between "real AI engineering" and "a weekend project" keeps moving. Not because the models got smaller — CLIP is still 150 MB. The browser got bigger. WebAssembly. ONNX Runtime Web. IndexedDB. Cache API. The runtime stack ate everything the old Python service used to do.

If you're a beginner reading this thinking "AI is too hard, I'd never build that": you just read the whole thing. The code is on GitHub, every commit walks you through one concept, and there's a live demo at clip-from-zero.vercel.app. Clone it. Open clip.ts. Read the four functions. That's CLIP.

The next time you hear someone talking about "embeddings" or "vector search" or "RAG" or "multimodal" — you know what they mean. Numbers in a 512-d space. Cosine similarity. A dot product.

That's it.

🔗 Code: github.com/dev48v/clip-from-zero
🌐 Live demo: clip-from-zero.vercel.app
📚 Series: TechFromZero — a new technology every day, all free, all open source.

I Built a 3-Agent AI Research Crew in 250 Lines of Python (LangGraph + Free Gemini)

Devanshu Biswas — Thu, 21 May 2026 10:04:31 +0000

You've seen the demos. "Look, our AI hired a research team and wrote you a 50-page report while you brushed your teeth!" Cool. Now show me the code.

It turns out the code is small. Embarrassingly small. The whole pattern — the thing every multi-agent framework on the market sells you a SaaS license for — is three functions piped through a typed dict. Once you see it, you can't unsee it.

So today we're going to build it. From scratch. In about 250 lines of Python. The crew has three specialists:

A Researcher who actually hits the web for real facts.
A Writer who turns those facts into a draft briefing.
An Editor who polishes the draft into something you'd send to a colleague.

You give it a topic. It hands you back a markdown report. And — this is the part the YouTubers skip — the entire stack is free. No OpenAI, no Anthropic, no Tavily, no credit card. Just one free Google API key.

Live demo — click a starter, watch the three stages turn green. Source on GitHub, step-by-step commits.

The lesson under the hype

If you remember nothing else, remember this: a multi-agent system is a state machine where each transition is an LLM call.

That's it. That's the whole field.

You define a shared blob of state — let's call it CrewState. The graph has nodes. Each node is just a function that reads the state, does some work (often by calling an LLM), and returns a partial dict. The framework merges that dict back into the state and decides which node runs next.

       ┌────────────┐    ┌──────────┐    ┌────────┐
TOPIC ─▶│ Researcher │───▶│  Writer  │───▶│ Editor │───▶ REPORT
       │  (DDG API) │    │ (Gemini) │    │(Gemini)│
       └────────────┘    └──────────┘    └────────┘
                  shared CrewState flows through all three

When LangGraph's authors built v0.1, they were essentially asking: what if we took LangChain's "Chain" abstraction but let it have cycles, branches, and persistent state? That's the whole pitch. The graph is the agent.

The state object: where everyone meets

LangGraph is opinionated about one thing: every node has to agree on the shape of the data flowing through. So we type it. Once.

from typing import TypedDict

class Fact(TypedDict):
    source: str
    title: str
    snippet: str

class CrewState(TypedDict, total=False):
    topic: str
    facts: list[Fact]
    draft: str
    final_report: str
    error: str

total=False is the magic. It means every field is optional. The graph starts with only topic set. As each node finishes, it adds its key (facts, then draft, then final_report). LangGraph merges the partial dict back into the state before the next node runs.

Notice what's missing: any reference to LLMs, prompts, or agents. The state is data, not behaviour. Keeping it that way is what makes the whole pattern testable — you can swap any agent for a stub that just returns {"draft": "lorem ipsum"} and the graph still runs.

Agent 1: The Researcher (or, why your LLM needs to leave the house)

The single biggest mistake beginners make with LLM apps is asking the model to remember things. Don't. The model's job is to transform inputs into outputs. The inputs come from your code, calling real APIs.

That's why the Researcher does the search first, then hands the results to the LLM. Not the other way around.

from duckduckgo_search import DDGS

def researcher_node(state: CrewState) -> dict:
    topic = state.get("topic", "").strip()
    with DDGS() as ddgs:
        raw = list(ddgs.text(topic, max_results=5, region="wt-wt"))
    facts = [
        {"source": r.get("href", ""), "title": r.get("title", ""), "snippet": r.get("body", "")}
        for r in raw
    ]
    return {"facts": facts}

That's the whole researcher. Twelve lines. No LLM call. DuckDuckGo's API is free, no key, no signup — perfect for a tutorial. (For production, swap to Tavily or Serper; the pattern doesn't change.)

Why grounded search instead of asking Gemini "what do you know about X?"

Because Gemini will lie about URLs. Every single LLM ever shipped will invent URLs that look real but 404. Don't ask the model for facts. Ask it to summarise facts you got from a tool.

Agents 2 + 3: Why two? Why not one big prompt?

Here's the part that feels wasteful at first. We have research notes. We want a polished report. Surely one prompt — "Write a polished briefing about $TOPIC using these facts" — can do it?

Try it. It produces mediocre output. Always.

The reason is divided attention. Asking a model to simultaneously generate prose AND fix its own structural problems means it does both badly. So we split:

The Writer has one job: produce a 400-500 word draft. Hedges allowed. Markdown sloppy. Just get words on the page.
The Editor has one job: read the draft, fix the structure, prepend a title, cut the flab, ship the final.

This is how human newsrooms work. Reporters file rough drafts; copy editors polish them. Both roles exist because both add value. Multi-agent design is just the same idea applied to LLM calls.

def writer_node(state):
    facts_block = "\n".join(f"- {f['title']}: {f['snippet']} ({f['source']})" for f in state["facts"])
    response = llm.invoke([
        SystemMessage(content="You are a technical writer. 400-500 words, plain markdown..."),
        HumanMessage(content=f"Topic: {state['topic']}\n\nFacts:\n{facts_block}\n\nWrite the draft."),
    ])
    return {"draft": response.content.strip()}

def editor_node(state):
    response = llm.invoke([
        SystemMessage(content="You are a senior editor. Polish, don't rewrite. Add an H1 title..."),
        HumanMessage(content=f"DRAFT TO POLISH:\n\n{state['draft']}"),
    ])
    return {"final_report": response.content.strip()}

System message = how to behave. Human message = what to do. Mixing them produces worse output. This is the single most underrated trick in prompt engineering.

Wiring it: the actual LangGraph part

After all that setup, the LangGraph code is comically short:

from langgraph.graph import START, END, StateGraph

g = StateGraph(CrewState)
g.add_node("researcher", researcher_node)
g.add_node("writer", writer_node)
g.add_node("editor", editor_node)
g.add_edge(START, "researcher")
g.add_edge("researcher", "writer")
g.add_edge("writer", "editor")
g.add_edge("editor", END)

crew = g.compile()
result = crew.invoke({"topic": "How CRISPR works"})
print(result["final_report"])

That's the whole thing. Eight lines define the agent crew. compile() turns the declarative graph into an executor that runs your nodes in order, merging state between them. Once compiled, the same crew object handles every request — it's stateless across invocations, because the state lives in the dict you pass in.

Streaming: because waiting 8 seconds for a spinner feels broken

The sync version works, but the UX is sad. The user clicks a button. A spinner appears. Eight to ten seconds pass. The whole report appears at once.

LangGraph has a stream() method that yields after each node finishes. Same total latency, dramatically better feel:

for update in crew.stream({"topic": topic}, stream_mode="updates"):
    for node_name, partial in update.items():
        yield {"node": node_name, "data": partial}

stream_mode="updates" emits only the diff returned by the node that ran (cheaper than "values", which emits the whole state). Pipe that through FastAPI's Server-Sent Events and the React frontend can render researcher facts as soon as they arrive — while the writer is still drafting. The Render free tier sleeps after 15 minutes, so first hit takes ~30 seconds to wake up; subsequent hits feel instant.

Why this is THE concept to understand before everything else

Every "wow look at this" AI demo from the next six months is going to be a variation on this exact pattern. Replace the Researcher with a code-aware agent and you get Cursor's compose mode. Replace the Editor with a fact-checker and you get Perplexity's pipeline. Replace the linear edges with conditional edges and a feedback loop and you get autonomous agent loops like AutoGPT.

The pattern doesn't change. State + nodes + edges. Three functions, three arrows, one dict. Everything else is marketing.

Once you see it, you can read any "agentic" framework's docs in five minutes flat. CrewAI, AutoGen, LangGraph, Pydantic AI — they all collapse to the same shape. The differences are syntactic sugar around the same core idea.

What to try next

Clone the repo and run it locally. It takes about three commands. Then break it:

Add a fourth agent — a fact-checker that flags suspicious claims in the editor's output and sends it back for revision. (Hint: add_conditional_edges.)
Swap Gemini for local Llama via Ollama. Same .invoke() interface, zero network cost.
Replace DuckDuckGo with a vector search over your own documents. Now you've built RAG.

The same 250 lines, with three different tweaks, give you three completely different products. That is why understanding multi-agent orchestration matters. The hard part isn't the agents — it's seeing the pattern clearly enough to recognise it everywhere.

This is Day 37 of 50 days of from-zero builds. A new technology every day. The full live demo is at langgraph-from-zero.vercel.app; the source is on GitHub. Beginners welcome — every commit teaches one concept.

I Built a 3D Solar System in 300 Lines of React (No Game Engine)

Devanshu Biswas — Tue, 19 May 2026 06:50:30 +0000

Pull up a browser. Drag your mouse. Watch eight planets orbit the Sun, axes tilted, Saturn's rings catching the light.

That's not a game engine. That's not Unity. That's 300 lines of React.

If your mental model of "3D programming" is "scary C++ matrices and a 600-page OpenGL textbook," you're a decade out of date. WebGL has shipped in every browser since 2014. Three.js wraps the boring math. React Three Fiber lets you write the scene as components, the same way you write HTML. The whole pipeline is <mesh>, <sphereGeometry>, <meshStandardMaterial> — three tags, you've made a planet.

Today I'll show you the whole thing.

The core insight: a scene is a tree

Every 3D scene — every Pixar movie, every video game, every product configurator — is the same shape: a tree of objects, where each node has a position, a rotation, a scale, and zero or more children. That's it. The Sun is the root. Earth is a child positioned 9 units to the right. The Moon is a child of Earth, positioned 1 unit further right. Rotate Earth and the Moon comes along for the ride, because it's a child.

In Three.js you build this tree imperatively:

const sun = new THREE.Mesh(geom, mat);
const earth = new THREE.Mesh(geom2, mat2);
earth.position.x = 9;
sun.add(earth);
scene.add(sun);

In React Three Fiber, the tree IS your component tree:

<mesh>           {/* sun */}
  <sphereGeometry />
  <meshBasicMaterial color="yellow" />
  <mesh position={[9, 0, 0]}>    {/* earth, child of sun */}
    <sphereGeometry args={[0.5]} />
    <meshStandardMaterial color="blue" />
  </mesh>
</mesh>

That's the whole conceptual leap. Once you see "the React tree is the Three.js scene graph," the rest is naming things.

The trick that makes orbits cheap

Naïve orbit code looks like this:

useFrame((_, dt) => {
  angle += speed * dt;
  earth.position.x = Math.cos(angle) * 9;
  earth.position.z = Math.sin(angle) * 9;
});

That works, but you're doing two trig calls per planet per frame in JavaScript. 60 fps × 8 planets = 960 sin/cos per second in slow JS.

There's a better way. Put the planet inside a pivot group at the origin. Place the planet at (distance, 0, 0). Rotate the group, not the planet.

<group ref={orbitRef}>                    {/* this group spins → orbit */}
  <mesh position={[distance, 0, 0]}>      {/* planet stays put in local space */}
    <sphereGeometry args={[radius]} />
    <meshStandardMaterial color={color} />
  </mesh>
</group>

useFrame((_, dt) => {
  orbitRef.current.rotation.y += speed * dt;   // ONE addition
});

Now you're doing one addition per planet per frame in JavaScript and zero trig. Three.js's internal matrix update handles the rotation in compiled C++ inside the GPU pipeline. The math still happens — it just happens in the right place.

Same trick for axial rotation: a child group inside the planet rotates on its own Y axis. Tilt the wrapper group on the X axis and Uranus is suddenly tipped 98° like real Uranus. The whole solar system is six nested groups doing addition.

Lighting: three lines, instantly 3D

If you skip lighting, every planet looks flat — like a coloured paper disc. Add one <pointLight> at the Sun's position and use meshStandardMaterial for the planets:

<pointLight position={[0, 0, 0]} intensity={2.5} distance={120} />

<mesh>
  <sphereGeometry args={[0.5]} />
  <meshStandardMaterial color="blue" roughness={0.7} />
</mesh>

meshStandardMaterial is physically-based — it reads the light, bounces it off the surface based on roughness and metalness, and shades the half facing the light bright while the half facing away goes dark. Three lines. Instant 3D.

Pro tip: don't use meshStandardMaterial for the Sun itself. The Sun emits light, it doesn't receive it. Use meshBasicMaterial, which ignores all lights and shows the colour you set, flat. Otherwise you'll have a yellow sphere with a dark side, which looks wrong.

OrbitControls: 80% of the polish for free

Drei (the R3F helper library) ships an <OrbitControls /> component. Drop it in your <Canvas> and you get:

Drag to rotate the camera around the scene
Scroll to zoom
Pinch on mobile
Two-finger rotate

<OrbitControls enablePan={false} minDistance={6} maxDistance={80} />

Three lines, all of "drag to look around" is done. This is the kind of thing that takes a junior developer two weeks in raw WebGL and 30 seconds in R3F. Use the helpers.

HTML overlays beat in-canvas UI

The temptation when you're new to 3D is to put every UI element inside the 3D scene — billboards, sprites, text geometry. Don't. Mount your <Canvas> full-bleed and stack regular HTML on top with position: absolute.

<div className="shell">
  <header className="hero">...</header>
  <Canvas>...</Canvas>
  <aside className="info-panel">...</aside>
</div>

The info panel that slides in when you click a planet is just a styled <aside>. The speed slider is <input type="range">. Your CSS skills transfer 1:1. The 3D part stays focused on 3D.

What I learned actually building this

Real takeaways from an afternoon of this:

1. Three.js is huge but the surface you need is small. The full Three.js bundle is ~600KB. You will use maybe 12 of its 400+ classes. Scene, Mesh, SphereGeometry, MeshStandardMaterial, PointLight, PerspectiveCamera, OrbitControls. That's most of it.

2. Real scale is the enemy. The Sun is 109× the radius of Earth. Neptune orbits ~30× further than Earth. If you use real ratios, the Sun fills the screen and Neptune is a single pixel. Cheat the visuals. Show real numbers in the info panel.

3. useFrame runs 60Hz, so don't allocate. Every frame, that callback fires. If you new Vector3() inside it, you're creating garbage 60 times per second. Either mutate refs you already have, or hoist allocations outside.

4. delta is your friend. R3F's useFrame((_, delta) => ...) gives you seconds since last frame. Multiply your speed by delta and your animation runs the same on a 60Hz laptop and a 144Hz gaming monitor. Without delta, your planets fly off the screen on a high-refresh display.

5. dpr={[1, 2]} is the mobile performance switch. Devices with retina displays would normally render at 3× resolution and tank the FPS. Capping at 2× looks identical to the eye and triples your frame rate on phones.

Why this matters

3D in the browser used to be a specialty — game studios, big agencies, NASA visualizations. It's not specialty anymore. Product configurators, real estate walkthroughs, data visualizations, NFT galleries, classroom physics demos — every web product is starting to have a 3D moment.

R3F is the lever that makes 3D approachable for people who already write React. You don't have to learn imperative scene-graph plumbing. You already know how trees of components work — you're doing 3D, you just have a different leaf type.

So go play. Open the live demo, click each planet, scroll out and look at the layout from the side. Then clone the repo and change a number. Make the Sun blue. Add a moon to Earth — wrap an Earth-sized sphere in an outer group, position the moon (1.2, 0, 0), and watch it follow. That's the entire mental model. You'll be making your own scenes within an hour.

Try it / fork it

🌐 Live: https://threejs-from-zero.vercel.app
🐙 Code: https://github.com/dev48v/threejs-from-zero

This is Day 36 of TechFromZero — a 50-day series where I build one tech from scratch every day with step-by-step commits you can read like a textbook. Yesterday was a voice AI tutor (Web Speech → Gemini → TTS). Tomorrow we're building a multi-agent AI orchestration that has agents argue with each other.

🌐 See all days: https://dev48v.infy.uk/techfromzero.php

Talk to you tomorrow.

I Built a Voice AI Tutor in 200 Lines of Code (and Zero Backend)

Devanshu Biswas — Mon, 18 May 2026 20:11:46 +0000

Open Siri. Ask it a question. Listen to the reply.

That whole experience — the magic that powers Alexa, ChatGPT voice mode, every car assistant, every drive-through screen — is three steps glued together.

Turn microphone audio into text.
Send the text to a brain.
Turn the brain's reply back into audio.

That's it. The whole industry of voice AI is variations on those three boxes. Different brains, different microphones, different voices, but the shape is identical.

Today I'm going to build the whole thing in your browser. No server. No install. No API key except a single free one. Open the tab, click the mic, talk to an AI. Total code: about 200 lines.

The pattern is the actual lesson. Once you see it, you can replace any box with a fancier one — Whisper for transcription, ElevenLabs for voices, your own fine-tuned model in the middle — and the architecture doesn't change.

The three Lego bricks

Let me name them with the boring acronyms so you can search for them later:

STT — Speech-to-Text. Microphone audio → string of words. The expensive option is OpenAI Whisper (best accuracy, costs about a third of a cent per minute). The free option, which I'm using here, is the Web Speech API, which has shipped in Chrome since 2013. You give it a microphone permission and it gives you back text. Zero key, zero upload — Chrome talks to Google's recognizer behind the scenes for you. It's slightly less accurate than Whisper, especially on accents, but for a learning demo the difference doesn't matter.

LLM — the brain. This is the part everyone gets excited about. You hand a string to a Large Language Model and it hands a string back. ChatGPT, Claude, Gemini — they all expose the same shape: send a list of messages, get a message back. I'm using Gemini 2.5 Flash because Google gives it away free at 15 requests per minute. Beginners shouldn't have to wave a credit card to learn how this works.

TTS — Text-to-Speech. String → audio you can play. The fancy option is ElevenLabs, whose voices are so good they sound uncanny. The free, zero-key option is window.speechSynthesis, which has shipped in every major browser since 2014. It sounds robotic, but it's instant and it costs nothing.

Notice the pattern: every brick has an expensive flavor and a free flavor. The interfaces are identical. You can swap one for the other without changing the architecture. That's why this is worth learning.

Wiring the loop

Here's the entire pipeline in pseudocode:

state = "idle"

while user wants to talk:
    state = "listening"
    text = await STT.listen()        # mic open until silence
    state = "thinking"
    reply = await LLM.ask(text)      # 1-2 seconds typically
    state = "speaking"
    await TTS.say(reply)             # plays through speakers
    state = "idle"

The state machine matters more than you'd think. If the user clicks the mic while the assistant is still talking, you need to cancel the playback. If they click while the LLM is still thinking, you need to keep them out. UIs get confusing fast when you have four states and one button. I'll show you the React version in a minute.

The STT brick

The browser ships a class called SpeechRecognition (with a webkit prefix on Safari). The API is event-based, not promise-based, which is a little annoying — but the pattern is straightforward:

const rec = new SpeechRecognition();
rec.lang = "en-US";
rec.continuous = true;       // keep mic open across pauses
rec.interimResults = true;   // stream partials while user talks

rec.onresult = (e) => {
  for (let i = e.resultIndex; i < e.results.length; i++) {
    const r = e.results[i];
    if (r.isFinal) onFinal(r[0].transcript);
    else onPartial(r[0].transcript);
  }
};

rec.start();

Two things to notice. First, interimResults is a gift. It streams text while the user is still talking, so you can show "you're saying..." in real time. It feels alive instead of laggy. Second, resultIndex lets you only walk new results since the last fire — the browser keeps the whole session's results in the results array, but you usually only care about what's new.

The LLM brick

Google's SDK makes this almost embarrassingly short:

import { GoogleGenerativeAI } from "@google/generative-ai";

const ai = new GoogleGenerativeAI(API_KEY);
const model = ai.getGenerativeModel({
  model: "gemini-2.5-flash",
  systemInstruction: "Reply in 1-3 short sentences. No markdown.",
  generationConfig: { maxOutputTokens: 200 },
});

const chat = model.startChat({ history });
const result = await chat.sendMessage(userText);
const reply = result.response.text();

Two design choices worth calling out.

System prompt. I tell the model to keep answers under 60 words. Why? Because the TTS will read every word. If Gemini writes a Wikipedia paragraph, your user is going to sit through 90 seconds of robot voice waiting for the next chance to talk. Voice AIs need to be terser than text AIs. This is a real lesson — half of building voice products is wrestling the model down to a sentence or two.

maxOutputTokens. A hard ceiling. Even if the model decides to ignore the system prompt and ramble, this cuts it off. Belt and suspenders.

The TTS brick

const u = new SpeechSynthesisUtterance(text);
u.lang = "en-US";
u.rate = 1.0;
u.voice = bestVoiceFor("en-US");
speechSynthesis.cancel();   // kill anything currently playing
speechSynthesis.speak(u);

The one gotcha: speechSynthesis.getVoices() returns an empty array the first time you call it. Voices load asynchronously and Chrome fires a voiceschanged event when they're ready. So I wrap voice-loading in a one-shot promise that callers can await. Otherwise your first reply plays in the browser's default voice instead of the nice Google one.

Wiring it in React

The whole React component is a state machine over phase: "idle" | "listening" | "thinking" | "speaking" and a list of messages.

const [phase, setPhase] = useState<Phase>("idle");
const [messages, setMessages] = useState<Message[]>([]);

const startListening = () => {
  setPhase("listening");
  stt.start({
    onFinal: async (text) => {
      stt.stop();
      const userMsg = { role: "user", text };
      setMessages(curr => [...curr, userMsg]);
      setPhase("thinking");
      const reply = await askGemini([...messages, userMsg], text);
      setMessages(curr => [...curr, { role: "model", text: reply }]);
      setPhase("speaking");
      speak(reply, { onEnd: () => setPhase("idle") });
    },
  });
};

The mic button changes label based on phase. Click it during idle to start listening, click it during listening/speaking to stop. The transcript renders as a list of bubbles. That's the whole UI.

What I learned actually building this

A few real takeaways from spending an afternoon on this:

1. Browser TTS quality is better than you remember. The Google voices on Chrome are genuinely fine. They were embarrassing in 2015. They're not embarrassing now. For a learning demo, ElevenLabs is overkill.

2. The pipeline is the lesson, not the tools. When a recruiter says "build a voice agent," they don't mean "use these three specific libraries." They mean "wire mic, brain, and speaker together with a state machine that doesn't get confused." Once you can do that, you can swap parts.

3. Voice changes how you prompt. A system prompt that's great for ChatGPT (gives bulleted lists, uses headings) is terrible for voice. The TTS reads "asterisk asterisk" out loud. Tell the model "no markdown, no lists, one paragraph" or live with the consequences.

4. State machines beat booleans. I started with isListening + isThinking + isSpeaking booleans. Within five minutes I had bugs where two were true at once. A single phase enum makes the impossible states actually impossible. Reach for this earlier than you think.

5. Free tiers are enough to learn on. Gemini's free tier covers ~14,000 requests per day. You will not run out while learning. Don't let "what API should I pay for" stop you from starting.

Why this matters

Every "AI agent" startup right now is some variation of these three boxes plus a loop. Voice tutors, customer service bots, drive-throughs, in-car assistants, accessibility tools. Once you can wire the three bricks, you can build any of them. The hard part is taste — which brain, which voice, which prompt, which moment to interrupt. That's the next ten years of product work, and it's all built on top of the architecture you can spin up in a single afternoon.

So go spin it up. Open the repo. Read the commits one at a time. The first commit is an empty React shell. The seventh commit is the entire app. Each commit is one concept. You'll get more out of reading the seven small steps than reading one huge final file.

Try it / fork it

🌐 Live: https://voice-from-zero.vercel.app
🐙 Code: https://github.com/dev48v/voice-from-zero

This is Day 35 of TechFromZero — a 50-day series where I build one tech from scratch every day with step-by-step commits you can read like a textbook. Yesterday was Stable Diffusion. Tomorrow is 3D in the browser with Three.js.

If you're learning AI and want a low-stakes way to actually ship something — clone the repo, change the model, change the voice, change the system prompt, and you'll have an entirely different demo by lunch. Make it a French tutor. Make it a Dungeon Master. Make it a meditation guide. The Legos snap together however you want.

🌐 See all days: https://dev48v.infy.uk/techfromzero.php

Talk to you tomorrow.

I built a Stable Diffusion playground in 200 lines and zero API keys. Here's how.

Devanshu Biswas — Fri, 15 May 2026 21:01:36 +0000

The first time I generated an AI image, I expected the worst.

A signup page. Email verification. A "free trial" with a credit card on file. A Python SDK that wouldn't install. CUDA. A Hugging Face account.

None of that happened.

I typed a URL into my browser, pressed Enter, and waited five seconds. An image of an astronaut riding a horse on Mars appeared. I had not given anyone an email address. I had not installed anything.

That's the API I built Day 34 of TechFromZero around: a free, zero-auth gateway called Pollinations.ai that hosts Stable Diffusion, FLUX, and a handful of other models behind a beautifully boring URL pattern.

If you've been putting off learning generative AI because the setup looked like Day 1 of a Computer Science PhD, this is your skip-the-cutscene button.

The whole API, on one line

https://image.pollinations.ai/prompt/an+astronaut+cat?model=flux

Hit that URL. You get an image. That is the entire integration.

There is no JSON to parse. There is no SDK to install. There is no token to manage. The image flows from Pollinations' CDN straight into your browser's <img> tag, and your browser doesn't know or care that an AI generated it. As far as it's concerned, it loaded a picture.

Compared to the way the same task usually feels — npm install some-sdk; set ANTHROPIC_API_KEY; add billing; wait for the cold start — this is approximately 100% less ceremony.

What I built

A single-page React app. You type a prompt, click Generate, and an image appears. The app remembers your last 50 generations in localStorage (metadata only — the images live on Pollinations' CDN), lets you favorite the ones you like, lock the seed for reproducible variations, and download any image as a PNG.

I deliberately kept the whole thing one React component (~200 lines). Splitting it across five files and a Redux store would have added zero clarity for the reader and a lot of noise.

Tech: Vite + React 19 + TypeScript + localStorage. Backend: none. API keys: zero. Vercel deploy: static SPA, ~10 seconds.

📸 Try it: stable-diffusion-from-zero.vercel.app
🧑‍💻 Code: github.com/dev48v/stable-diffusion-from-zero

The four parameters that matter

Pollinations supports a fistful of query params. Four of them are the ones a beginner cares about:

`model`

Pick the generator. The defaults you'll actually want:

flux — fast, photorealistic, great default.
flux-anime — illustration / stylised art.
sdxl — Stable Diffusion XL, the classic. Strong on composition.
sd3 — Stable Diffusion 3. Specifically good at rendering legible text inside images. Yes, the AI can write the word "BAKERY" on a shop sign now.
dalle3 — OpenAI's DALL·E 3 routed through Pollinations. Surreal, concept-art-friendly.

`seed`

Same prompt + same seed = same image, byte for byte. This is the most important parameter beginners ignore.

Why? Because once you find a composition you like, you want to iterate — slightly different lighting, slightly different angle, but the same person. Lock the seed, change the prompt by one word at a time, and you can see what a single word does to the model's mental picture.

In the playground, every generation rolls a new random seed automatically. If you find one you like, copy the number, paste it back into the seed input, and lock it for the next try.

`width` + `height`

Pollinations accepts almost any pixel size, but the model was trained on 1024×1024-ish inputs, so it's best at square (1024×1024) and gentle aspect ratios (768×1152 portrait, 1152×768 landscape). Push past 2048 in either direction and you'll start to see weird artifacts — extra fingers, fractal hair, that AI-image uncanny-valley vibe.

`enhance`

Easily my favorite. With enhance=true, Pollinations runs your prompt through a small LLM first, expanding it into a more descriptive version before handing it to the image model.

So when you type "astronaut cat", the LLM rewrites that to something like:

"A highly detailed astronaut cat floating in zero gravity, photorealistic, cinematic lighting, 4k resolution, intricate space suit details, distant Earth in the background"

…and then the image model renders the expanded version. Your three-word prompt looks like it was written by someone who's been making Midjourney art for two years.

Things I learned (and that beginners should know)

Generated images aren't free in the legal sense. Pollinations' terms permit personal use; many model licences (FLUX in particular) restrict commercial use. If you're shipping a product, read the licence of the specific model you're using before you sell anything you generated.

The seed parameter is reproducibility, not randomness. I used to think seed=42 was "the 42nd image". It's not. It's the random-number-generator's starting state. Different prompts with seed=42 produce wildly different images. The seed only "matches" when the prompt is also identical.

Aspect ratio affects content. Ask for "a portrait of a librarian" at 1024×1024 and you'll get the librarian centered with bookshelves around them. Ask for the same thing at 1152×768 and you'll get a wider shot — the librarian plus a reading nook. The model uses the canvas shape as a hint.

enhance makes lazy prompts good. Three words become twenty. The output looks 5× better. For 95% of users this is the right default, which is why my playground turns it on automatically.

How to extend this

A few good next steps if you want to keep going:

Inpainting — Pollinations supports a mask= parameter for editing parts of an existing image. Add a brush tool.
Image-to-image — pass an existing image URL as a starting point. Useful for stylistic transfer.
Batch generation — fire off a 4×4 grid of variations on the same prompt with different seeds. Pollinations is happy to serve in parallel.
Self-host — Pollinations is open source. You can run the inference stack yourself on a GPU and avoid even the implicit dependency on someone else's free infrastructure.

What's next in the series

This is Day 34 of TechFromZero — one new technology every day, built from scratch with detailed commits. Day 35 picks up the AI thread with voice AI (Whisper + Gemini + ElevenLabs).

If you're learning AI from a beginner background and want a curriculum that's actually fun, follow along at dev48v.infy.uk/techfromzero. Each day stands alone — start anywhere.

Generated AI images used to require a CS degree, a GPU, and a credit card. Now they require a browser tab. The barrier to creating with AI is gone. The only barrier left is curiosity.

Try a weird prompt. See what happens.

DEV Community: Devanshu Biswas

I Built a Custom Tool Server for Claude in 250 Lines of TypeScript

The mental model

Step 1: scaffold

Step 2: minimal server with stdio transport

Step 3: add a tool

Step 4: the Wikipedia client

Step 5: resources

Step 6: hook it into Claude Desktop

Why MCP matters

What this changes for you

I Compiled Rust to WebAssembly and Made My JavaScript 6 Faster

The mental model

Step 1: write the kernel in Rust

Step 2: compile to wasm

Step 3: feed it the canvas

Step 4: race it against JavaScript

What this changes

I Built a Text-to-Image Search Engine That Runs Entirely in the Browser

The idea behind CLIP

Why this matters

Step 1: load CLIP into the browser

Step 2: encode a phrase

Step 3: encode an image

Step 4: rank

Step 5: cache so it stays fast

What this changes

I Built a 3-Agent AI Research Crew in 250 Lines of Python (LangGraph + Free Gemini)

The lesson under the hype

The state object: where everyone meets

Agent 1: The Researcher (or, why your LLM needs to leave the house)

Agents 2 + 3: Why two? Why not one big prompt?

Wiring it: the actual LangGraph part

Streaming: because waiting 8 seconds for a spinner feels broken

Why this is THE concept to understand before everything else

What to try next

I Built a 3D Solar System in 300 Lines of React (No Game Engine)

The core insight: a scene is a tree

The trick that makes orbits cheap

Lighting: three lines, instantly 3D

OrbitControls: 80% of the polish for free

HTML overlays beat in-canvas UI

What I learned actually building this

Why this matters

Try it / fork it

I Built a Voice AI Tutor in 200 Lines of Code (and Zero Backend)

The three Lego bricks

Wiring the loop

The STT brick

The LLM brick

The TTS brick

Wiring it in React

What I learned actually building this

Why this matters

Try it / fork it

I built a Stable Diffusion playground in 200 lines and zero API keys. Here's how.

The whole API, on one line

What I built

The four parameters that matter

model

seed

width + height

enhance

Things I learned (and that beginners should know)

How to extend this

What's next in the series

`model`

`seed`

`width` + `height`

`enhance`