Make the
technical
click.
I’m Himanshu, a developer and technical storyteller. I turn what I build into explanations, demos, and starting points other developers can use.
Read my workOne task.
A trace you can follow.
An agent can make several model calls. A trace keeps those calls connected, so you can see which step failed or switched models.
From the build
to the byline.
I write about the parts I had to figure out: instrumentation, memory, and the gap between what a tool declares and what it does.
We instrumented an AI agent swarm with SigNoz, and its own telemetry told us we were wrong about almost everything
Six lessons from tracing DevSwarm: provider routing, model budgets, review quality, and the queries behind the findings.
I built a trust firewall for my AI agent’s memory — on Cognee’s four verbs
How ContextFirewall audits recalled facts, plus the embedding, provider, and secret-scanner bugs encountered along the way.
Your MCP Server Says It Is Read-Only. Who Checked?
Following a tool’s claims all the way to its behavior, with Airlock.
Give developers
something to try.
An explanation is more useful when the reader can open the source, run an example, and follow the result.
From semantic HTML to reviewed WebMCP tools
discover → review → ship → verifyFollow a tool
from page to agent.
Graft makes WebMCP inspectable: compile a page, see why each tool was proposed, review its contract, and export an adapter.
The repository includes an owner-site example and an integration with OmniDev’s Agent Lab. Developers can trace how the contracts become callable tools on a separate site.
Walk through a failure
and its recovery.
ScrapeSentry’s recorded demo follows a broken scraper through drift detection, quarantine, a reviewed repair, and verification. The walkthrough connects each operator action to the underlying contract checks.
Watch the ScrapeSentry walkthroughI like the moment
someone says,
“oh, now I get it.”
My route into developer relations is through building. I work on agent memory, MCP tools, and backend systems, then explain the decisions in public.
I’m interested in helping developer-tool teams turn product knowledge into useful docs, technical articles, sample apps, and demos.
Start with a real questionGive the reader a reason to care before introducing the API.
Make the example inspectableShow the code, the output, and the limits.
Leave a useful next stepA command to run, a repo to explore, or a question worth testing.