Skip to content
Latch

Since the last run

Overall +2 pointsReproducible Setup +4 pointsMachine Orientation +3 points

vercel/ai (opens in a new tab)

Solid machine-oriented AI SDK with strong type safety and test infrastructure, but bloated file count and missing root documentation constrain agent autonomy.

TypeScript★ 25,0271,794 open issuesOther
Overall score: 73 out of 100
Holding

last scored 2026-06-21 · both lenses

Readiness lenses

The same repo, two ways: how ready it is for an AI coding agent, and for a human newcomer. Switch lenses to see each one's score and checks.

How ready the repo is for an AI coding agent to read, build, and operate it.

73 / 100

28 of 41 checks passed across 6 categories.

  • Machine Orientation

    78

    Solid machine orientation with a comprehensive AGENTS.md, clear monorepo structure, and explicit build/test commands, but missing a root README.md and env example undermines agent navigation confidence.

    The repository provides a dedicated AGENTS.md file with structured guidance covering monorepo layout (pnpm workspaces + Turborepo), core API functions, import patterns, development commands (pnpm install, pnpm build, pnpm test), package-level workflows, and example directory conventions—all machine-readable and actionable. The package.json exposes explicit task commands (build, test, type-check, dev, lint, fix), and tsconfig.json documents 67+ package references, making the dependency graph navigable. However, the detected README=yes conflicts with the actual absence of README.md in the root; what exists is comprehensive inline documentation in the README section provided to Latch. The missing root .env.example (signal reports env.example=yes but file is absent) forces agents to infer environment setup solely from CONTRIBUTING.md and AGENTS.md, creating ambiguity about required vs. optional API keys.

  • Reproducible Setup

    76

    Solid reproducibility with explicit pinned versions, lockfile, and pnpm-enforced setup; minor gaps in container/documentation clarity and floating Node.js constraint.

    The repository enforces reproducible setup through pnpm@10.33.4 pinned in package.json packageManager field, a pnpm-lock.yaml lockfile (detected but unreadable in snapshot), and strict Node.js 22+ requirement in engines. CI workflows use `--frozen-lockfile` to prevent mutation. .env.example exists with comprehensive provider-specific variables documented. However, Node.js itself floats (^22.0.0 || ^24.0.0 || ^26.0.0) rather than pinning a single version, and no Dockerfile, devcontainer, or docker-compose exists to eliminate host-environment variables entirely.

  • Code Navigability

    72

    Clear monorepo structure with strong module boundaries and TypeScript strict mode, but vague naming conventions and missing architectural documentation make localization error-prone.

    The repository exhibits a well-organized monorepo with 70+ clearly named packages under `packages/` (openai, anthropic, react, google, etc.), each with strict TypeScript (`tsconfig.json` enforces `strictNullChecks`), explicit typed exports via package.json `exports` fields, and test coverage via built-in test scripts. The root tsconfig.json lists all references with full paths, enabling the agent to navigate package interdependencies. However, the lack of an architecture document (architectureDoc=no) and absence of llms.txt mean an agent must infer the module topology from package.json and export statements alone; the 7,157 files and presence of numerous generated changelog entries (.changeset/) increase noise in file navigation, and a 6,900+ file tail in the tree suggests either bloat or unfiltered artifacts that complicate context-window discovery.

  • Verification Surface

    72

    Strong test and type infrastructure with Turbo, Vitest, TypeScript strict mode, and linting; CI config and exact pinning aid reproducibility, but CI workflows themselves are not visible in the snapshot and test coverage is not quantified.

    The repository has machine-verifiable test, type-checking, and lint commands wired into package.json (test, type-check, lint via oxlint + ultracite), Vitest config files present in packages, TypeScript strict mode enabled in root tsconfig.json, and pnpm with exact packageManager pinning (pnpm@10.33.4) that closes the feedback loop reproducibly. The signal indicates 11 CI workflows are present but the workflows themselves are not visible in the provided snapshot, so CI readability cannot be verified. No test coverage metrics (e.g., Istanbul, nyc config, or .nycrc) are visible, and no test flakiness guards (timeouts, retries) are declared in the visible Vitest configs.

  • Agent Safety

    72

    Strong secret hygiene and safety controls; missing explicit agent-safety documentation and SECURITY.md undermines trust in disclosed threat handling.

    The repository demonstrates solid secret hygiene: .env files are properly in .gitignore (including root, examples directories), .env.example is present in examples/ai-functions with documented provider credentials, and the codebase shows active security patches (SSRF redirect validation, short-lived token minting for realtime). However, the absence of both SECURITY.md and explicit agent-safety boundaries is a significant gap—an autonomous agent reading this repo has no machine-readable disclosure policy for reporting vulnerabilities or understanding which components are considered agent-facing attack surfaces. The worktree setup script symlinks .env files across instances, which is operationally correct but undocumented from an agent-safety perspective.

  • Context Economy

    62

    A large, well-structured monorepo with clear tooling and TypeScript strict mode, but no .gitignore-based exclusion markers for generated build outputs and a massive file count (7157) that forces an agent to sift through substantial noise.

    The repository is a 70+ package TypeScript monorepo using Turbo, pnpm, and strict tsconfig references. The .gitignore correctly excludes node_modules, .next, dist, and build artifacts, and no committed node_modules or build output were detected. However, the signal-to-noise ratio is degraded by: (1) 7157 total files—a substantial bulk that stretches context efficiency despite the lack of vendored code clutter; (2) 300+ .changeset metadata files visible in the file tree (one per change entry), which are machine-generated overhead that an agent must parse around; (3) no linguist markers (.gitattributes with linguist-generated or linguist-vendored) to explicitly flag the changesets directory as generated noise, forcing the agent to rely on heuristics rather than explicit signals. The monorepo structure is clean and navigable, with conventional layout and clear package boundaries, but the sheer scale and the untagged generated bulk mean an agent cannot efficiently isolate the truly relevant code signal in a single context window.

  • Machine Orientation

    7 checks passed3 problems found

    • lowAgent instructions stay lean

      A bloated instructions file burns context and measurably hurts more than it helps.

      Fix: Trim AGENTS.md to the load-bearing commands and conventions; link out to the rest.

    • lowllms.txt present

      An llms.txt is the emerging machine-orientation standard — a curated map for LLMs.

      Fix: Add an llms.txt pointing at the key docs and entry points.

    • lowArchitecture doc

      An ARCHITECTURE doc hands an agent the module map instead of making it infer one.

      Fix: Add an ARCHITECTURE.md describing the major components and how they fit.

    • README present — An agent reconstructs what the repo is and how to work in it from the README first.
    • Agent instructions file — AGENTS.md / CLAUDE.md is the direct, machine-read channel for entry points and conventions.
    • Repository description set — The one-line description is the fastest orientation signal an agent reads.
    • Topics set — GitHub topics situate the repo's domain and stack for an agent at a glance.
    • README shows usage — A usage/example section tells an agent how the project is actually invoked.
    • Examples directory — An examples/ directory gives an agent runnable, copyable references for the API.
    • Contribution conventions are written down — A contributor guide is where an agent learns the branch, commit, and review conventions it must follow.

  • Reproducible Setup

    5 checks passed2 problems found

    • mediumContainer or dev-container

      A Dockerfile / compose / devcontainer removes 'works on my machine' from setup.

      Fix: Add a Dockerfile, a compose file, or a .devcontainer so the environment is declared, not assumed.

    • lowDev container

      A .devcontainer gives an agent a one-command, fully-declared environment.

      Fix: Add a .devcontainer so the toolchain is declared, not assumed.

    • Lockfile committed — Without a lockfile two clones can resolve different dependency trees — the build isn't reproducible.
    • Runtime / toolchain pinned — An unpinned runtime makes an agent guess the version a clean environment needs.
    • Version pins are exact — A floating pin (a bare major, or a range) still drifts between installs.
    • Env template present — A .env.example tells an agent which configuration keys it must supply to run.
    • README documents setup — Explicit install/setup steps are what let an agent go from clone to running.

  • Code Navigability

    1 check passed4 problems found

    • lowTypeScript strict mode on

      Strict typing gives an agent typed signatures to anchor an edit on, not guesses.

      Fix: Turn on `strict` in tsconfig.json.

    • low.editorconfig present

      An .editorconfig keeps whitespace and encoding consistent, so diffs stay legible.

      Fix: Add an .editorconfig pinning indentation, charset, and final-newline.

    • lowFormatter configured

      A formatter config (Prettier/Biome/rustfmt/…) keeps style uniform across the tree.

      Fix: Add a formatter (Prettier, Biome, rustfmt, …) and commit its config.

    • lowTyped public API

      A declared `types` entry gives an agent typed signatures to anchor an edit on.

      Fix: Ship type declarations and point package.json `types`/`typings` at them.

    • Conventional source layout — A recognised src/ · lib/ · app/ layout lets an agent localise code without spelunking.

  • Verification Surface

    6 checks passed1 problem found

    • lowTask runner present

      A Makefile / Taskfile / justfile gives an agent a single index of the project's commands.

      Fix: Add a Makefile / Taskfile / justfile collecting the common commands.

    • Tests present — Runnable tests are the ground truth an agent checks its own edits against.
    • Test command defined — A `test` script is the documented, discoverable way to run the suite.
    • Lint command defined — A linter an agent can run catches a class of mistakes before they ship.
    • CI configured — Readable CI is the feedback loop an agent reads to know what 'green' means here.
    • Typecheck command — A typecheck script lets an agent catch type errors before they ship.
    • Build command — A documented build command is the discoverable way for an agent to produce artifacts.

  • Agent Safety

    7 checks passed1 problem found

    • lowCODEOWNERS present

      CODEOWNERS marks the 'don't touch without review' zones an agent should respect.

      Fix: Add a CODEOWNERS file marking the sensitive paths.

    • No committed .env — A tracked real .env hands secrets to anything — including an agent — that reads the repo.
    • No exposed secrets — Secret-shaped literals in tracked files are a live credential leak.
    • .gitignore covers env files — An ignore rule for .env is what keeps the next careless commit from leaking secrets.
    • Automated dependency updates — Dependabot / Renovate keeps dependencies patched without a human in the loop.
    • .gitignore present — A .gitignore is the first guard against an agent committing secrets or build junk.
    • Security policy — A SECURITY.md is where an autonomous security agent reads this repo's rules before acting on it.
    • License makes the code reusable — Without a license an agent cannot safely copy, redistribute, or vendor any of this code.

  • Context Economy

    2 checks passed2 problems found

    • lowGenerated / vendored files marked

      A .gitattributes linguist marker tells tools (and agents) what to skip.

      Fix: Mark generated/vendored paths in .gitattributes (linguist-generated / linguist-vendored).

    • lowNo oversized source file

      A single file in the hundreds of KB blows past an agent's effective context window.

      Fix: Split the largest files along their natural seams.

    • Dependencies not vendored in — A committed node_modules / vendor tree drowns the real signal an agent needs.
    • Build output not committed — Generated dist/ · build/ output is noise an agent has to read past.

Where the grip slips

  1. mediumReproducible Setup+2 pts if fixed

    No container image, Devcontainer, or compose file

    pnpm and Node.js installation still rely on host environment and manual steps (brew, npm, etc.). Without a containerized dev environment, platform-specific issues (Windows vs. macOS vs. Linux) are not pre-eliminated.

    Fix: Add a Dockerfile and/or .devcontainer/devcontainer.json to fully specify OS, pnpm version, Node.js, and all system dependencies. Include a docker-compose.yml for orchestration of examples/test databases if needed.

  2. mediumVerification Surface+2 pts if fixed

    CI workflow definitions not visible/verified

    The signal reports ci=yes(11) but .github/workflows files are absent from the snapshot. An agent cannot read or verify that these workflows actually run the test/lint/build commands without direct access to their definitions.

    Fix: Ensure .github/workflows/*.yml files are included in any snapshot passed to the agent, or document their names and trigger conditions in a machine-readable file (e.g., .github/WORKFLOWS.md).

  3. highAgent Safety+1 pts if fixed

    Missing SECURITY.md disclosure policy

    No SECURITY.md file exists to communicate vulnerability reporting process or security contacts. An agent (or maintainer) cannot verify safe handling of agent-safety reports or understand the project's threat model.

    Fix: Create SECURITY.md with: supported version policy, vulnerability reporting email/GPG key, disclosure timeline, and security contacts. Reference it in README.

  4. highAgent Safety+1 pts if fixed

    No explicit agent-safety boundaries or documentation

    README mentions agent support and shows agent examples, but does not document which APIs are safe for untrusted agent input, injection-prone surfaces (e.g., prompt strings, tool definitions), or runtime constraints. No .agents/skills file validates agent capabilities.

    Fix: Add 'Agent Safety' section to README documenting: unsafe/safe APIs for agents, injection risks in tool definitions and system prompts, environment variable isolation requirements, and link to llms.txt or .agents/skills manifest.

  5. mediumReproducible Setup+1 pts if fixed

    Node.js version floats across major releases

    package.json specifies engines.node as '^22.0.0 || ^24.0.0 || ^26.0.0', allowing any semver match within those ranges. An agent could pull Node 22.0.0 or 26.99.99 and encounter undocumented or inconsistent behavior.

    Fix: Pin a single Node.js version in engines (e.g., '22.11.0') or provide a .node-version or .nvmrc file to enforce the exact LTS release used in CI.

  6. highCode Navigability+1 pts if fixed

    Missing architecture documentation

    No ARCHITECTURE.md or docs/structure.md exists to explain how 70+ packages relate to each other, which exports to import from which package, and the build dependency graph. An agent must reverse-engineer this from package.json exports and tsconfig references alone.

    Fix: Create docs/ARCHITECTURE.md with a directed graph of package dependencies, export entry points for each major package (ai, @ai-sdk/react, @ai-sdk/openai, etc.), and a module glossary. Include examples like 'to call OpenAI models, import from @ai-sdk/openai; to build UI, use @ai-sdk/react.'

  7. mediumCode Navigability+1 pts if fixed

    Unclear naming of internal provider packages

    70+ packages with names like 'anthropic', 'openai', 'azure', 'google' do not explicitly signal whether they are @ai-sdk/ scoped or bare. The signal detection only confirmed 'monorepo=yes' but not the naming convention pattern; files output does not clarify @ai-sdk/anthropic vs anthropic distinctions.

    Fix: Standardize all provider packages to @ai-sdk/ scope consistently (already seen in react, but confirm 100% across all 70 packages). Add a scoping rule to .npmrc or document.md stating 'All provider integrations use @ai-sdk/PROVIDER scope.'

  8. mediumContext Economy+1 pts if fixed

    Large file count (7157) without architectural navigation aid

    While individual files are not bloated, the total repository size of 7157 files creates context-window pressure. No architecture documentation (architectureDoc signal absent) or llms.txt guide exists to help an agent quickly navigate which packages are entry points vs. internal utilities, prioritizing what to read first.

    Fix: Create an llms.txt file at the root documenting the monorepo structure: list the primary packages (ai, @ai-sdk/react, @ai-sdk/openai, etc.), their purpose, inter-dependencies, and which are entry points. Alternatively, add an architecture.md describing the package hierarchy and which files are most critical for understanding the codebase.

  9. mediumContext Economy+1 pts if fixed

    No .gitattributes linguist markers for generated bulk

    The .changeset/ directory contains 300+ auto-generated changelog entry files that are structural noise. Without linguist-generated or linguist-vendored markers in .gitattributes, an agent cannot automatically filter or de-prioritize these files and must treat them as legitimate source code.

    Fix: Add a .gitattributes file with: .changeset/** linguist-generated=true. This signals to code analysis and AI tools that the entire directory is generated and should be skipped or deprioritized.

  10. mediumMachine Orientation+1 pts if fixed

    Missing root README.md file

    The signal indicates README=yes but the file does not exist in the repository root. Agents rely on README.md as the primary machine-readable entry point; without it, they must fall back to AGENTS.md or infer structure from package.json and contributed documentation.

    Fix: Create a root README.md (even brief) linking to AGENTS.md and documenting the monorepo structure, setup (pnpm install), and test/build commands. Alternatively, ensure the README signal accurately reflects the absent file.

  11. mediumVerification Surface+1 pts if fixed

    No quantified test coverage visibility

    No coverage configuration (e.g., .nycrc, nyc in package.json, coverage thresholds in vitest.config.js) is visible. An agent cannot verify that tests actually cover critical code paths or fail if coverage drops.

    Fix: Add coverage configuration to Vitest (e.g., 'coverage: { provider: "v8", reporter: ["text", "html"], lines: 80 }') and expose a 'pnpm coverage' or 'pnpm test:coverage' script.

  12. lowVerification Surface+1 pts if fixed

    Test flakiness/reliability not declared

    Vitest node and edge configs are minimal stub files; no retry logic, timeout policies, or flakiness detection are specified. An agent cannot distinguish between real failures and environmental timing issues.

    Fix: Extend vitest.node.config.js and vitest.edge.config.js with explicit timeout, retry, and bail settings (e.g., 'test: { testTimeout: 10000, bail: 1 }') to make test reliability expectations machine-readable.

  13. mediumAgent Safety

    No llms.txt or .agents/skills manifest

    Detected signal shows .agents/skills directory exists but no machine-readable agent-safety manifest is present. Agents cannot discover safe entry points, version constraints, or intended use patterns.

    Fix: Create .agents/skills file (or llms.txt equivalent) declaring: SDK version, supported runtimes, APIs safe for agent consumption, known injection surfaces (e.g., prompt/tool fields), and links to agent-safety docs.

  14. lowReproducible Setup

    .env.example exists but .env.local setup not explicitly documented in main README

    CONTRIBUTING.md mentions env setup for examples but the main README does not explain that API keys must be populated in a .env file for most examples to run. An agent reading only README may attempt to run examples without clear guidance.

    Fix: Add a 'Configuration' or 'Environment Setup' section to README.md explicitly referencing .env.example and stating that provider API keys are required for examples to function.

  15. mediumCode Navigability

    No central index of exports and entry points

    Each package exports via package.json, but there is no single reference document (e.g., docs/EXPORTS.md or src/index.ts at root) that lists all public APIs across all packages and maps them to their source file paths. An agent must traverse 70+ package.json files to find the right export.

    Fix: Create docs/EXPORTS.md listing all stable exports: 'generateText → packages/ai/src/generate-text.ts', 'useChat → packages/react/src/use-chat.ts', etc. Alternatively, add a root index.ts that re-exports key types from all packages with JSDoc comments linking to source.

  16. mediumCode Navigability

    Excessive file tree noise obscures key boundaries

    7,157 files includes 900+ .changeset/ entries, test snapshots, and generated docs under prepack. An agent querying a file listing will see `.changeset/` clutter before package structure, increasing the chance of editing the wrong file or missing the actual source.

    Fix: Add or verify .gitattributes linguist markers to mark .changeset/* and dist/ as generated; document in README that `packages/*/src/` is the source entry point. Consider .gitignore audit to exclude build artifacts from Latch's file index.

  17. lowCode Navigability

    Workspaces and symlink-based dependencies not explicitly documented for agents

    The package.json uses 'workspace:*' references and pnpm workspaces, but no machine-readable dependency graph file (e.g., turbo.json tasks or a graph.json) is documented. An agent reading package.json must understand pnpm workspace semantics to locate the actual source.

    Fix: Add a pnpm-workspace.yaml or update turbo.json to include a 'packages' field and document in CONTRIBUTING.md: 'All packages use workspace: protocol; run pnpm install to resolve.' Optionally export turbo graph as JSON for agent consumption.

  18. lowContext Economy

    No devcontainer or explicit build-output exclusion documentation

    Although .gitignore correctly excludes dist and .next, there is no .devcontainer or Dockerfile to make the build and output footprint explicit to an agent. An agent must infer where build outputs land by reading package.json and turbo.json rather than seeing it declaratively.

    Fix: Document build output locations explicitly in a top-level ARCHITECTURE.md or create a .devcontainer/devcontainer.json that codifies the build process, making it machine-readable which directories are ephemeral vs. permanent.

  19. mediumMachine Orientation

    Missing .env.example file despite signal reporting it present

    Signal reports env.example=yes, but the file is not found. Agents cannot discover required or optional environment variables (e.g., API keys for providers) without explicit documentation. AGENTS.md and CONTRIBUTING.md mention environment variables in examples but do not provide a template.

    Fix: Create .env.example listing provider API key names (OPENAI_API_KEY, ANTHROPIC_API_KEY, etc.) and flag which are required for testing. Document in AGENTS.md or CONTRIBUTING.md any special env setup (e.g., for examples/).

  20. lowMachine Orientation

    AGENTS.md lacks entry point specification for running tests and CI verification

    AGENTS.md documents development commands but does not explicitly state which commands verify the build is ready for an agent to work with (e.g., full type-check, all tests, lint pass). Agents may not know the canonical 'ready to go' verification step.

    Fix: Add a section in AGENTS.md like 'Verification & CI Checks' with: `pnpm type-check:full && pnpm test && pnpm check` or reference the exact CI script from package.json scripts.

  21. lowMachine Orientation

    .agents/skills directory referenced in README but not found in tree

    README mentions 'npx skills add vercel/ai' and signal detects .agents/skills, but the directory does not exist or is empty. Agents expecting to find skill metadata or integration helpers will not locate it.

    Fix: Either create .agents/skills with structured skill metadata if supported, or remove the reference from README and clarify that skills are managed externally via Vercel's skill registry.

  22. lowVerification Surface

    Linter rule severity levels not granular for agent guidance

    .oxlintrc.json bulk-disables many rules (e.g., 'no-unused-vars': 'off' for entire examples/*) and assigns broad error levels. An agent cannot distinguish which lint failures are blocking vs. warnings.

    Fix: Create a secondary lint profile (e.g., .oxlintrc.strict.json) or document in linter config which rules block CI and which are advisory, then expose as 'pnpm lint:strict' for agent use.

Show your score

Latch badge
[![Latch score](https://latch.fyi/api/badge/4187f306-5f32-491c-aa44-2be649a5c13b)](https://latch.fyi/vercel/ai)

Share this analysis

https://latch.fyi/vercel/ai

Fixed some issues? Re-analyze to measure your progress →

Copy the whole report

Grab the entire verdict in one go — a Markdown block for a README or an issue, plain text, or a prompt you can paste straight into an LLM.

Was this verdict fair?

One tap helps — or tell us more.

← Analyze another repo