Vibe Code an AI Content Archaeologist for Sanity

Build a small tool that searches Sanity content, surfaces older or underused material, and suggests what to review or repurpose. You will need a Sanity project, a modern JavaScript runtime, and an AI provider; start with read-only access and require a person to approve every change.

What You’ll Need

• A Sanity project with content you are allowed to inspect, plus its project ID, dataset name, and API version.
• Node.js and npm, or another JavaScript runtime and package manager you already use.
• An AI API key and a model that accepts text. Check its current limits and data-handling terms before sending content.
• A code editor and a terminal. A vibe-coding editor or assistant is optional; review and run the code yourself.
• A development API token with read-only permissions. Do not use a write token for the first version.

Step-by-Step

1. Decide what “archaeology” means. Write down a focused job, such as finding published articles that have not been updated in two years, locating duplicate topics, or identifying content with missing descriptions. Choose one job for version one. Decide what information a useful result should show: title, URL or slug, last-updated date, reason for review, and a suggested next action.
2. Inspect your Sanity schema. Identify the document type to search and the fields it actually has. Common fields might include _type, title, slug.current, _updatedAt, and body content, but schemas vary. Check references, drafts, localized fields, and permissions. Do not assume every document has a title or date.
3. Create a minimal app. Use your preferred framework, or make a small Node.js server with a simple web page. Keep the search and AI calls on the server so credentials are not exposed in browser code. Add a page with a “Scan content” button, a status message, and an empty results area. Get this shell running before asking a coding assistant to add features.
4. Configure secrets safely. Put the Sanity project ID, dataset, API version, read-only token, and AI key in local environment variables. Add the environment file to your ignore rules and never paste real keys into prompts, source files, screenshots, or a public repository. Provide an example environment file containing placeholder values only.
5. Fetch a small, predictable sample. Use Sanity’s client or a GROQ query to retrieve only the chosen document type and required fields. Begin with a small limit, sort by a relevant date, and exclude drafts unless you explicitly need them. If you need full body text for analysis, extract plain text and impose a reasonable per-document limit. Show an empty-state message when no matching documents exist.
6. Make the first pass deterministic. Filter or rank documents using ordinary code before adding AI. For example, compare update dates to a user-selected cutoff, or flag missing fields. Make the cutoff visible and explain how it is applied. This keeps the tool useful when the AI service is unavailable and makes it easier to check whether the model adds value.
7. Ask the model for structured suggestions. Send only the fields needed for the chosen task. In the prompt, say that content is untrusted input, request evidence tied to the supplied text, and tell the model to return a defined JSON shape such as documentId, reason, suggestion, and confidence. Validate the response on the server; reject malformed output, unknown document IDs, and fields outside the schema. Treat confidence as a prioritization hint, not a fact.
8. Show evidence and keep a human in control. For each suggestion, display the document title, a link to its Sanity Studio record, the reason, and a short supporting excerpt. Label model-generated text clearly. Add actions such as “open in Studio” or “dismiss”; do not silently rewrite, publish, or delete content. If you later add editing, require explicit review and confirmation for each change.
9. Test against known examples. Pick several documents whose status you understand, including one that should be flagged and one that should not. Compare results with the source records, inspect excerpts, and check dates and time zones. Test missing fields, long documents, empty searches, API errors, and invalid model output. Adjust the query or prompt when the result cannot be traced to evidence.
10. Deploy cautiously. Keep server-side secrets in your host’s secret settings, restrict who can use the tool, and retain only the information needed to operate it. Add sensible request limits and error handling. Start with a small dataset or manual scans; monitor failures and model usage, then expand only after reviewing results with content owners.

Common Mistakes

• Assuming the schema: A query for a nonexistent field can produce empty or misleading results. Verify field names and document types in the actual schema.
• Giving the model too much: Sending every document, full revision history, or unnecessary personal data increases exposure and cost. Minimize and limit the input.
• Trusting fluent suggestions: A convincing summary can still be wrong. Show the evidence and verify it against the source before acting.
• Putting credentials in the frontend: Browser-delivered code can expose keys. Make private API calls on the server and use least-privilege tokens.
• Automating publication too soon: Recommendations are not editorial approval. Keep changes manual until validation, permissions, and review processes are established.

Tips

• Build one reliable query and one useful result card before adding dashboards, scheduling, or multiple analysis modes.
• Include document IDs in internal results so you can reliably link suggestions back to the right record.
• Make the scan criteria visible, including date cutoff, document type, and any excluded content.
• Use a fixed set of sample documents when changing prompts so you can compare whether output improved.
• Ask the model to say “insufficient evidence” rather than inventing a reason when the supplied text does not support one.

Troubleshooting

The query returns no documents: Confirm the project ID, dataset, document type, token permissions, and field names. Test the query in Sanity’s query tools, then remove filters one at a time. Check whether the content is draft-only or stored in another dataset.

The server reports an authentication or network error: Check that environment variables are loaded in the server process and that the token has read access to the intended dataset. Restart the development server after changing local variables. Do not fix a read failure by granting broad write permissions.

The AI response is invalid or inconsistent: Log a redacted response shape, not secrets or unnecessary content. Tighten the requested JSON schema, validate it, and handle failures with a clear retry message. Keep deterministic results visible even when AI analysis fails.

Results seem wrong or repetitive: Check which text fields are included, whether the date filter uses the right field, and whether duplicate or referenced documents are being fetched. Add the relevant source excerpt and document ID to each result, then test against known examples.

The scan is slow or exceeds limits: Reduce the number of documents per request, shorten extracted text, and process records in small batches. Avoid repeatedly analyzing unchanged documents; if you cache results, define how they expire and how updates invalidate them.

Frequently Asked Questions

What does an AI content archaeologist do?
It searches existing content for patterns worth reviewing, such as stale pages, duplicate coverage, or missing fields. It should support editorial decisions, not make them automatically.

Do I need to use AI for the first version?
No. A date filter or schema check is often a better starting point. Add AI only for a task where language understanding provides a clear benefit.

Can it update Sanity documents automatically?
It can be extended to write, but begin with read-only access. If you later allow edits, require a person to review and confirm each change and use narrowly scoped permissions.

Should I send the entire content library to the model?
No. Retrieve only relevant documents and fields, limit text length, and check your organization’s data and provider policies before sending content.

How can I tell whether a suggestion is reliable?
Compare it with the source document and show an excerpt supporting the reason. Track false positives on a small, reviewed sample before relying on results.

Can I build this with a vibe-coding tool?
Yes, but treat generated code as a draft. Verify queries, authentication, input limits, error handling, and secret storage, and run the app against test content before deployment.

Related

• Email Tests: What Mocking Proves and What It Doesn’t
• AI-Driven Workload Boundaries: A Practical Guide
• Star Wars Battlefront II Codes: What Still Works?