Coding Agents Setup

Purpose and Scope

Coding-agent setup is about making an AI-assisted development environment accurate, fast, and aware of the exact AI SDK version in your project. The first-party getting-started page targets agents such as Claude Code, Codex, OpenCode, Cursor, and similar tools, and it recommends a workflow built around three layers: install the official AI SDK skill, install the package so source and docs are available locally, and add DevTools when you need visibility into requests and tool loops. This page explains that workflow and connects it to the public package README and the experimental harness package for more advanced agent runtimes.

Sources: content/docs/02-getting-started/09-coding-agents.mdx, packages/ai/README.md, packages/harness/README.md

The important distinction is that a coding agent is not the same thing as an application agent. A coding agent helps you edit, inspect, and refactor a repository. An application agent is code you build with the AI SDK, such as a tool-loop agent, a harness-backed agent, or a workflow agent. The setup described here improves the first category while pointing to primitives used by the second. The AI SDK README frames the package as a provider-agnostic TypeScript toolkit for AI-powered applications and agents across UI frameworks and Node.js, which is the baseline your coding assistant should understand before it writes code.

Sources: packages/ai/README.md, content/docs/02-getting-started/09-coding-agents.mdx

Relevant Source Files

content/docs/02-getting-started/09-coding-agents.mdx — Defines the first-party coding-agent setup path: install the AI SDK skill, use bundled docs and source from node_modules, and optionally register DevTools telemetry during local development.
packages/ai/README.md — Describes the main ai package, Node.js requirement, installation command, skill recommendation, unified provider architecture, and basic agent-oriented examples.
packages/harness/README.md — Documents the experimental @ai-sdk/harness package, HarnessAgent, sandbox requirements, session lifecycle, sandbox configuration hooks, and bridge-backed adapter expectations.

Core Primitives

The smallest useful setup starts with the official skill. In the AI SDK docs, a skill is described as a lightweight markdown instruction file that an agent can discover and load on demand. That matters because the agent does not need the whole documentation corpus in context all the time. Instead, progressive disclosure lets the agent start with a name and description, then pull in deeper instructions only when the task is about the AI SDK. For day-to-day repository work, this keeps prompt context focused while still giving the agent specialized knowledge when it needs to choose APIs, wire tools, or debug streaming behavior.

Sources: content/docs/02-getting-started/09-coding-agents.mdx

The next primitive is the installed package itself. Once the ai package is in a project, the getting-started page says the agent can inspect bundled source and documentation under local package paths, so it can verify signatures and examples without internet access. This is especially valuable in SDK work because public APIs change across major versions. A coding agent that reads the installed package is less likely to hallucinate an option from a newer documentation page or an older example. It can use the local source tree as the authority for the project it is modifying.

Sources: content/docs/02-getting-started/09-coding-agents.mdx, packages/ai/README.md

DevTools is the observability primitive for local development. The coding-agent guide describes AI SDK DevTools as a way to capture LLM requests, responses, tool calls, token usage, and multi-step interactions, then inspect them in a local web interface. That is useful for humans and coding agents because many AI SDK bugs are behavioral rather than syntactic: a tool may receive the wrong input, a model may stop too early, or a multi-step loop may produce an unexpected intermediate result. The docs explicitly warn that DevTools is experimental and intended for local development, not production deployment.

Sources: content/docs/02-getting-started/09-coding-agents.mdx

Quickstart Flow

Install the skill first when the repository will be edited by a supported coding agent. The documented command is intentionally repository-centric: it adds the skill from the AI SDK repository and places it in the selected agent’s skills directory. The guide notes examples such as agent-specific directories and symlinks when more than one agent is selected. Use the noninteractive flag in automation and the agent-selection flag when you want a universal or specific target. After this step, an agent that supports the Agent Skills format can discover the skill automatically during AI SDK tasks.

npx skills add vercel/ai
npx skills add vercel/ai -y
npx skills add vercel/ai -a amp

Sources: content/docs/02-getting-started/09-coding-agents.mdx, packages/ai/README.md

Then install the SDK dependency that your application code will actually use. The package README states that local development requires Node.js 22 or newer and a package manager, and it shows the main package installation. The getting-started page provides equivalent commands for common package managers. Installing the package is not only a runtime requirement; it also gives your coding agent local evidence for the installed version. After installation, ask the agent to inspect the local docs and source before making major changes, especially when it is adding streaming, tool calling, structured output, or provider-specific options.

pnpm add ai
npm install ai
yarn add ai
bun add ai

Sources: content/docs/02-getting-started/09-coding-agents.mdx, packages/ai/README.md

If you are debugging generation calls, add DevTools and register telemetry near application startup or in the local development entry point you use for experiments. The documented registration imports registerTelemetry from the main package and DevToolsTelemetry from the DevTools package, then registers the integration globally. After registration, telemetry is enabled automatically for AI SDK calls. Keep this setup out of production configuration, because the docs call it experimental and local-development oriented. A practical pattern is to gate registration behind an environment check so the coding agent can observe behavior locally without changing deployment behavior.

import { registerTelemetry } from 'ai';
import { DevToolsTelemetry } from '@ai-sdk/devtools';
 
registerTelemetry(DevToolsTelemetry());

Sources: content/docs/02-getting-started/09-coding-agents.mdx

System-to-Code Mapping

For most application work, the coding agent should begin with the main AI SDK APIs rather than harness internals. The package README demonstrates generateText, structured output through Output.object, unified provider strings through AI Gateway, and direct provider packages such as OpenAI, Anthropic, and Google. It also shows a ToolLoopAgent example with a shell tool backed by a sandbox command runner. That example is the bridge between ordinary model calls and agentic application behavior: the model can request a tool, the application validates and executes that tool, and the result returns to the loop.

Sources: packages/ai/README.md

Harness setup is for a different tier of coding-agent integration. The harness README marks the package experimental and describes HarnessAgent plus a harness specification and sandbox interface. Its example constructs a HarnessAgent with a harness adapter, an identifier, system instructions, a Vercel sandbox, sandbox configuration hooks, host-side tools, and harness-specific options. This is not required to install the coding-agent skill. Use it when you are building or running a coding-agent runtime through the AI SDK, especially with bridge-backed adapters that need a sandbox provider capable of exposing ports.

Sources: packages/harness/README.md

The harness session lifecycle is also important for long-running coding tasks. The README shows creating a session, generating a response, streaming another prompt over fullStream, and then cleaning up in a finally block. It documents detach for parking a bridge-backed session, stop for saving state and stopping the sandbox, and destroy for cleanup without keeping resume state. Sandbox hooks divide preparation into reusable bootstrap work and per-session work. Keep bootstrap expensive and cache-aware, keep session setup idempotent, and always clean up sessions so coding-agent experiments do not leave sandboxes running.

Sources: packages/harness/README.md

Implementation Notes and Next Steps

A good coding-agent prompt should tell the agent which layer it is allowed to change. For example, ask it to use the installed skill and local package docs before modifying an AI SDK route, but separately ask for a harness design if the task involves Claude Code, Codex, Deep Agents, or other harness-backed runtimes. The official provider docs describe these harness adapters as experimental bridge-backed integrations, and the repository harness README reinforces the sandbox and session requirements. Treat that area as fast-moving: pin package versions, prefer small experiments, and review generated diffs carefully.

Sources: packages/harness/README.md, content/docs/02-getting-started/09-coding-agents.mdx

Recommended next steps are practical. First, install the skill in repositories where coding agents will work on AI SDK code. Second, install the ai package and ask the agent to consult local node_modules docs before choosing APIs. Third, register DevTools only for local debugging when you need request and tool-call visibility. Finally, read the adjacent pages on installation, provider choice, agents, tool calling, sandbox, and the harness reference depending on whether you are building a normal AI application, a tool-loop agent, or a sandboxed coding-agent runtime.

Sources: content/docs/02-getting-started/09-coding-agents.mdx, packages/ai/README.md, packages/harness/README.md

Ask a question...