Make Your AI Read package.json First
Make your AI read package.json and fetch the exact-version docs before it writes framework code. Training data ships deprecated APIs. The model learned your framework at some cutoff date, then stopped looking — so it writes yesterday's syntax with today's confidence, and you find out at runtime.
Why the model guesses
Every LLM has a training cutoff: a point after which it has seen nothing. Frameworks don't check that date before shipping a breaking change. Ask for code against a library that changed last month and the model falls back on the closest thing it knows — an earlier version's method name, a signature that has since gained a required argument, a config format that was renamed two majors ago.
The output looks right because the model isn't aware it's out of date. It pattern-matches to what it learned. The gap is invisible until a hallucinated parameter fails at runtime, or worse, silently does the wrong thing.
The fix: version first, then code
You already have the ground truth checked into your repo. package.json records the exact version of every dependency you installed. Point the assistant at it before it writes anything:
- Detect the stack. The dependency file tells the model what it's working with — React, Next.js, a database SDK, an auth provider.
- Read the exact versions. Not "React" —
react@18.3.1. The pinned version inpackage.json(or the resolved version in the lockfile) is the one your code actually runs against. - Fetch the matching docs. Have it pull the official documentation page for that version, not the latest and not whatever it half-remembers.
- Implement and cite. It writes the documented pattern and links the source, so you can check the claim in ten seconds instead of debugging a changed signature for an hour.
Reading the version yourself
package.json version ranges are not exact by default. Know what each means before you trust one:
| Spec | Example | Means |
|---|---|---|
| Exact | "18.3.1" | Only that version |
| Caret | "^18.3.1" | Compatible: >=18.3.1 <19.0.0 |
| Tilde | "~18.3.1" | Approximately: >=18.3.1 <18.4.0 |
The range in package.json is what you asked for; the lockfile (package-lock.json, pnpm-lock.yaml, yarn.lock) records what actually got installed. When precision matters, point the model at the lockfile's resolved version.
Power move: automate the fetch
Pasting docs by hand works, but it doesn't scale. An MCP server that pulls live, version-specific documentation on demand turns "read package.json, then fetch the docs" into one step the agent runs itself. Tools like Context7 read the requested library and version and inject the current API surface into context — so the model works from real documentation instead of stale memory, every prompt, without you copy-pasting a thing.
Either way, the rule holds: pin the version, fetch the matching docs, cite the source. Docs beat memory.
Resources
- package.json
dependencies& version ranges — npm docs - Semantic Versioning 2.0.0 — what
^and~actually allow - Context7 — MCP server for up-to-date, version-specific library docs
- Model Context Protocol — how agents pull external context
Building an AI feature? Yeda AI designs, audits, and ships production LLM systems.