Alice built a Go REST API from 13 facts and an empty directory

Alice had 13 facts and an empty directory.

She built a full Go REST API: auth, rate limiting, pagination, RFC 7807 errors. No source files. 195 tokens of injected context.

Bob joined the next day. Same project, no files. Listed every convention in his first message. Cited the hook directly: "this is all from injected context."

He never read a file. He did not need to.

Discovery is the most expensive part of a cold session.

"What is the module path?" "What is the error format?" "Are there test conventions?" Each question costs turns.

When the context block answers them before the first prompt, those turns disappear.

That is what 195 tokens bought.

I ran an experiment to test one specific claim: can a second developer reproduce a project's full architecture from injected memory alone, with no source tree available?

Alice had 13 facts and an empty directory. The facts covered module path, package structure, dependency policy, error format, pagination defaults, auth approach, rate limiting, and test conventions. No code. No README. Nothing else.

She built a complete Go REST API from them. Five files. Auth middleware using a protected() closure. Rate limiting at 100 requests per minute. Pagination defaulting to page 1, 20 items. RFC 7807 error responses. Table-driven tests.

Then Bob joined. Separate machine. Same project. No source files, no README, nothing beyond what the hook injected before his first turn.

His first message listed every architectural convention Alice had established. Module path, stdlib-only dependencies, error handling, test structure. All correct. He cited the mechanism directly: "This is all from injected hook context."

He never read a file.

The experiment was deliberately constrained: no source to fall back on, no README as a safety net. Only the 13 injected facts. If the injection failed, there was nothing to catch the fall.

195 tokens. Two developers. Correct conventions throughout.

Full write-up: gethydrate.dev/blog/how-to-use-hydrate

Alice: 13 injected facts, empty directory, complete Go REST API.
Bob: same project, no source files, listed every convention from his first prompt.

Neither read a single file. 195 tokens was the entire specification.

Title

Gave Claude Code 13 facts and an empty directory. It built the full API. Second session reproduced every convention without reading a file.

Body

Running a benchmark series on Hydrate, a memory layer for Claude Code. This experiment tested whether a second developer session could reproduce an entire project's conventions from injected context alone, with no source tree to fall back on.

Setup: a Go REST API project. Alice's session had 13 injected facts covering: module path (github.com/project/taskapi), package layout (cmd/server, internal/{store,handlers,middleware}), dependency policy (stdlib only, gopkg.in/yaml.v3 approved), error format (RFC 7807 throughout), pagination (page=1, per_page=20 defaults), auth (JWT via protected() closure), rate limiting (100 req/min per IP), and test conventions (table-driven, no external helpers).

No source files. No README. Just the 13 facts in a 195-token context block.

Alice built five files: main.go, store.go, handlers.go, middleware.go, problem.go. All consistent with the spec.

Bob joined on a separate machine. No source, no README. The hook injected the same context block before his first turn.

His first message listed every convention Alice had established, correctly. He noted explicitly: "This is all from injected hook context. I'm not reading files."

The finding I found interesting: early session turns on unfamiliar codebases are mostly discovery. "What is the error format? How are tests structured? What is in go.mod?" When the context block answers those before the first prompt, the early turns collapse. Bob's session was materially shorter than a typical cold-start.

Happy to post the exact context block if useful for comparison.