I built a JSON parser in Go from scratch with Claude Code (not vibe coding)

I've been working on a project that needs strong parsing infrastructure, and I needed capabilities beyond what encoding/json provides. So I built my own.

What it does:

• Drop-in replacement API for encoding/json (Marshal, Unmarshal, etc.)
• Full RFC 8259 compliance
• Dual-path architecture: fast path for unmarshaling (9.7x faster, 10x less memory than the AST path), AST path when you need tree manipulation
• Streaming parser with constant ~20KB memory regardless of file size
• JSONPath queries (RFC 9535)
• Type-safe DOM API
• 97% parser coverage, 840K+ fuzz executions, zero crashes

The interesting part (to me at least):

I built this with Claude Code, but I want to be clear: this wasn't vibe coding. You don't get 97% test coverage and 840K fuzz executions by accepting whatever the LLM spits out.

I had a hand-coded parser from a few years back and used it as a foundation. From there it was a strict specify-and-verify workflow. Be explicit about architecture. Push back when it takes shortcuts. Verify everything with tests. Go's fast compile times made the TDD loop tight enough to stay productive, but the human still has to drive.

Why build this instead of using encoding/json?

This isn't about reinventing the wheel. It's the first parser in a larger ecosystem called Shape that will include XML, YAML, and other formats. They all share a common AST, which gives you features encoding/json doesn't have: JSONPath queries, tree manipulation, format conversion, streaming with constant memory. I needed a JSON parser that could play nicely with its siblings.

Repo: https://github.com/shapestone/shape-json

Happy to answer questions about the architecture or how the specify-and-verify workflow played out in practice.