What if an AI coding agent could research documentation before generating code instead of relying entirely on what an LLM already knows?
That question led me to build a research-first AI coding agent using Context.dev, TypeScript, OpenCode, and OpenRouter on my Mac mini.
Most coding workflows begin with a prompt: describe a feature, ask an AI model to implement it, and then review the output. But for real-world development, having a plausible answer isn't enough. APIs change, libraries introduce breaking changes, and implementation details can vary between versions. Without relevant documentation, an AI-generated solution can look correct while missing important details.
I wanted to experiment with a different approach: research first, plan second, generate code third.
The idea was to build an agent that searches the web for relevant technical sources, retrieves useful documentation, creates a research brief, and passes that context to an LLM before generating an implementation plan and proposed code.
For the research layer, I used Context.dev. OpenCode helped me integrate the workflow into a TypeScript project, while OpenRouter provided access to an LLM through an OpenAI-compatible API.
To test the workflow, I gave the agent a practical task:
Build a TypeScript HTTP client with retry handling and timeouts.
Rather than immediately generating code, the agent researched HTTP client implementations, retry strategies, and timeout handling. It then produced a structured implementation plan and proposed TypeScript source files.
In this article, I'll walk through how I set up the project, integrated Context.dev, connected the LLM, tested the workflow, and handled some of the issues I encountered along the way.
This is an experiment in making AI coding workflows more research-driven—not a claim that generated code is automatically correct. I'll also explain what worked, what still needs validation, and what I would build next.
I started by setting up a standalone TypeScript project on my Mac mini for building an AI coding agent powered by Context.dev. The goal is to create an agent that researches official documentation before writing code.
mkdir -p ~/projects/context-coding-agent
cd ~/projects/context-coding-agent
npm init -y
npm install context.dev dotenv
npm install -D typescript tsx @types/node
npx tsc --init
The project initialized successfully, and all dependencies were installed without reported vulnerabilities. npm did flag an approval warning for the esbuild install script, which I will resolve before running the application.
I chose TypeScript for the implementation, tsx for running code during development, and dotenv for environment variables locally.
After initializing the project, I configured the npm scripts, created the source directory, and added a .gitignore file to keep dependencies, environment secrets, and generated files out of version control.
Run the following commands in the terminal:
npm pkg set type="module"
npm pkg set scripts.dev="tsx src/index.ts"
npm pkg set scripts.check="tsc --noEmit"
mkdir -p src
touch .env .env.example .gitignore
Then add the following entries to .gitignore:
node_modules/
.env
dist/
coverage/
Verified the file using cat .gitignore. The output confirmed that all four entries were present.
To let the coding agent access live web data, you need a Context.dev API key.
Context.dev offers a free sign-up tier advertised as including 1,000 credits per month, so check your account's current plan and usage limits before running requests.
Next, open the project directory in your terminal and add the API key to your .env file:
nano .env
Add the following line, replacing the placeholder with your actual key:
CONTEXT_DEV_API_KEY=your_actual_api_key_here
Save the file and exit the editor. In Nano, press Ctrl + O, then Enter, and finally Ctrl + X.
I used OpenCode, an AI coding agent, to integrate Context.dev into the project. After configuring the API key in .env, I opened OpenCode in my project directory and pasted the setup prompt generated by Context.dev.
The prompt instructed OpenCode to inspect the codebase, configure the SDK, implement the web research workflow, and verify the integration with one real API request.
The implementation includes a centralized wrapper in src/context/client.ts for API requests, authentication, retries, and credit tracking. The research module in src/research/researcher.ts searches the web, ranks relevant URLs, retrieves page content, and prepares a research brief before the agent begins planning.
OpenCode also created automated tests and a dry-run mode to validate the workflow without consuming API credits.
Before testing the agent with a live API request, I ran the type checker, automated tests, and dry-run workflow to validate the implementation.
Run the following commands from the project directory:
npm run check
npm test
npm run dry-run
The type check completed without errors, and all 34 automated tests passed.
The dry run exercised the research and planning pipeline using fixture data, without making live Context.dev requests. It demonstrated how the agent derives search queries from a coding task, ranks relevant URLs, collects page content, and generates a research-backed implementation plan.
The sample task was to build a TypeScript HTTP client with retry handling and timeouts. The resulting plan included documentation references, implementation steps, failure-handling considerations, and code examples.
Because this run used fixture data, the displayed sources and credit figures are simulated rather than results from a live API request. This makes the dry run useful for testing the workflow without spending API credits.
With the local checks passing, the next step is to verify the research workflow against the live Context.dev API.
With the CLI argument issue fixed, I ran the agent on a practical coding task:
npm run dev -- "Build a TypeScript HTTP client with retry handling and timeouts"
The agent started by researching the web instead of immediately generating code. Context.dev returned eight relevant sources, including the Ky HTTP client repository and documentation covering retries and timeouts.
The research module ranked the results, retrieved two pages in full, and passed the gathered information into the planning stage. The agent then produced a five-step implementation plan covering documentation review, API design, core logic, error handling, and tests.
This run used eight Context.dev credits, leaving 966 credits available. Because no LLM API key was configured, the planner ran in offline mode and returned a research-backed plan with reference implementations rather than creating finished source files.
This confirmed that the main research-and-planning workflow was running end to end. The next step is to connect an LLM so the agent can use its research to plan and generate code, then verify that code with tests.
The research workflow was working, but the planner was still running in offline mode. To take the project further, I connected an LLM through OpenRouter so the agent could use its research findings to generate a structured implementation plan and source code.
I configured the OpenAI-compatible API settings in my local .env file:
OPENAI_API_KEY=your_openrouter_api_key
OPENAI_BASE_URL=https://openrouter.ai/api/v1
OPENAI_MODEL=minimax/minimax-m3.1-flash:free
I kept the API key in .env rather than hardcoding it into the source code. The project already supported OpenAI-compatible chat completions, so I could connect OpenRouter without introducing another SDK.
Next, I tested the API connection directly. After resolving an empty-response issue caused by the model's reasoning and output limits, I adjusted the request to use low reasoning effort and a deterministic temperature.
I then ran the project checks:
npm run check
npm test
The TypeScript check passed, and all 45 automated tests passed.
With the LLM connection working, I ran the same coding task again:
npm run dev -- --mode llm "Build a TypeScript HTTP client with retry handling and timeouts"
This time, the agent completed the research phase and passed the collected documentation into the LLM planner. Context.dev returned 10 sources, and the agent read two pages in full. The research included the Ky HTTP client repository, documentation on retries and timeouts, and guidance on handling transient HTTP failures.
The LLM generated a four-step implementation plan covering:
It also produced proposed source files: src/http-client.ts and src/index.ts. The generated HTTP client included configurable timeouts, retry limits, exponential backoff, and support for caller-provided cancellation signals.
The final output confirmed that the planner was running in LLM mode rather than falling back to the offline planner.
This was an important milestone: the agent could now research relevant documentation first, use that research to generate an implementation plan, and produce code artifacts for review.
The generated code still needs its own validation before being integrated into a real project. In particular, retry behavior, non-JSON responses, timeout handling, cancellation, and compatibility with the existing project structure should be tested.
With both research and LLM-based planning connected, the next step is to validate the generated code and improve the agent's ability to test its own implementations.
Building this research-first AI coding agent gave me a practical way to explore how web research and LLM-based code generation can work together.
The key idea is simple: instead of asking an LLM to generate code immediately, I built a workflow that researches relevant documentation first, retrieves useful source material, and passes a research brief to the planner before generating an implementation plan and proposed code.
Using Context.dev, TypeScript, OpenCode, and OpenRouter, I was able to take the project from initial setup to a working research-and-planning workflow with LLM-based code generation.
The experiment also exposed some of the challenges involved in building coding agents. Model responses need to be handled carefully, generated code needs independent validation, and a successful plan does not automatically mean the implementation is correct.
At this stage, the agent can research technical topics, generate a structured implementation plan, and produce code artifacts for review. I have not yet integrated the generated HTTP client into the project or verified it with dedicated implementation tests.
There are several improvements I would explore next:
The long-term goal is to move beyond an agent that researches and proposes code toward one that can implement a task, validate its work, and explain the decisions behind its changes.
For now, this project is a useful starting point for experimenting with research-backed coding workflows—and a reminder that generated code still needs engineering judgment.
If you're building AI coding agents, I'd be interested to hear how you're handling documentation retrieval, code validation, and the gap between generating a plausible solution and verifying that it actually works.
Like | Follow | Subscribe to the newsletter.
Connect with me on:
GitHub: https://github.com/Ayush7614
LinkedIn: https://www.linkedin.com/in/ayush-kumar-984443191/
Twitter: https://x.com/AYUSHKUMAR82274
Substack: https://substack.com/@felixayush
Dev.to Blog: https://dev.to/ayush7614
Personal Blog: https://neural-verse-peach.vercel.app/
Website: https://ayushbuilds-dev.vercel.app/