My AI Agent Said the Code Blocks Were Done. Sanity Disagreed.

An AI coding agent telling you a task is "done" is not the same as the task actually working. I found this out firsthand while adding code block support to this blog's Sanity CMS — my agent installed the right plugin, edited the right files, ran the type checker, reported success, and the feature was still broken. Here's exactly what happened, and the one habit that would have caught it sooner.

The task

I'd just published a blog post with a few SQL snippets in it, and they were rendering as plain wrapped text — no formatting, no syntax highlighting, not even copyable as a distinct block. I asked my coding agent to fix it: add proper code block support to the Sanity schema, and render it nicely on the frontend.

The agent's report

It moved fast. It installed @sanity/code-input and react-syntax-highlighter, registered the plugin in the Sanity config, added the new code type to the post schema, built a custom renderer component with a dark theme and a copy button, and ran npx tsc --noEmit to confirm no type errors. It reported complete success and told me to go test it.

What actually happened

I converted the existing SQL text into the new code block format and opened the post. Everything rendered fine, except the code snippets — they were just gone. No error on the page, no crash, just empty space exactly where each snippet should have been. Studio told the real story:

Invalid Portable Text value
Block with key b8 is of type code, which is not allowed by the schema.

So Studio itself was refusing to recognize the very type the agent had just added.

The investigation

The obvious next step was to assume the schema edit was wrong. It wasn't. My agent re-checked both files directly: the post schema's body field genuinely included { type: 'code' } in its array of allowed types, and sanity.config.ts correctly imported and registered the codeInput plugin. The code, on paper, was completely correct. Type checking had passed. And Studio still rejected the data at runtime.

The actual root cause

Sanity Studio was embedded directly inside the Next.js app, running through npm run dev — and that dev server had been running continuously for about 35 hours. Next.js's fast refresh handles component and page edits well, but schema structure and plugin registration changes are a different category: they get baked into the Studio's in-memory configuration at boot, and hot reload doesn't re-run that boot process. The fix had nothing to do with code at all. It just needed a cold restart.

Why this is worth writing down

None of this was the agent lying or hallucinating. Every individual claim it made was true: the plugin was installed, the schema was edited correctly, the type checker did pass. The gap was between "the checks I ran passed" and "the feature works end to end." A type checker verifies your TypeScript compiles — it has no idea whether a long-running dev server has actually loaded your new plugin into memory. That's a category of failure no static check catches, and it's exactly the kind of thing that only surfaces when a human actually opens the tool and looks.

What I'd tell you to do differently

• Treat "I've successfully implemented X" from an agent as a claim to verify, not a fact to file away — especially once multiple tools (a build step, a type check, an actual UI) all have to agree for the feature to really work.
• After any schema, plugin, or config change — not just a component edit — restart the dev server before testing. Hot reload is not guaranteed to cover structural changes.
• When something silently fails with no visible error, check the tool that actually owns that data — in this case, Studio's own validation message named the exact block and the exact reason immediately, once I looked.
• A passing type check or a clean build is real signal, but it's a subset of "working," not a synonym for it.