For dev-tool teams · agent-ready docs pilot
Find where coding agents get your SDK wrong, and fix it in the docs.
More developers now meet your SDK, API or MCP server through Claude Code, Codex or Cursor. When the agent writes broken code, the developer blames your product. I test three of your onboarding workflows through coding agents, write the docs patches, and rerun them to show what changed.
- 2 weeks
- $1,000 fixed
- 3 workflows you pick
- patches ready for review
Scope a pilot for my SDK Read the 438-run evaluation
Your docs have a second reader now
A person reads your quickstart, gets confused, and opens an issue. An agent reads it, fills the gap with a guess, and the guess compiles. You find out weeks later, if at all.
It guesses what isn't written
The exact shape of a config value, the scope you must request, the order two calls must happen in. If the docs skip it, the agent invents it.
It writes the version it learned
After a breaking change, the model still knows last year's API. Agents keep installing the old package until something in your docs stops them.
It gives up politely
In my runs, agents found the cause of a failure from the log, then wrote "this cannot be fixed from here". The missing line was one sentence.
Nobody files "the agent wrote broken code for your SDK". They file "the docs don't match". It is often the same bug.
What I measured
I gave coding agents real tasks, with a short guide and without it, and graded every run with a hidden script that checked the result, not the agent's report of itself. Nine agent setups: Claude Code (Opus, Sonnet, Haiku), Codex CLI, Gemini and an open model. 438 runs.
A fact missing from the official docs. Without it, three agents got there by web search. With it, every run passed.
A guide that retells the docs did exactly as well as no guide. Rewriting your docs "for AI" is not the fix.
Six tasks across nine setups, without a guide and with one (two wordings of the same guide).
With the guide, the smallest model matched the largest one. The missing fact mattered more than the model.
The pattern: a guide pays off only when it carries what the docs don't say. A missing fact, a fix the agent can diagnose but cannot know, a step it skips, a trap where the obvious code goes. Finding those in your docs is the pilot.
What you get
- Three workflows you pick, each with a written success check: "the app builds and the webhook fires", not "looks right". For example: add your SDK to an app, set up webhooks, connect your MCP server.
- Three agent setups your users actually use, such as Claude Code, Codex and Cursor, with repeated runs in clean environments. Repeated runs on relevant setups beat one run on a long list of agents.
- A failure summary: where each agent got stuck and why, by workflow and setup, with the run logs.
- Docs patches ready for review, as a pull request or a diff. A report adds work for your team; a patch takes it away.
- A rerun after the patches: passes out of runs, before and after, by workflow and setup. Plus the prompts and checks, so you can rerun it yourself after your next release.
- One revision round, with a rerun, after your team reviews the patches.
Two weeks, concretely
| When | What happens |
|---|---|
| Day 1 | A 30-minute call. We agree on the three workflows, the success check for each, and the agent setups. |
| Days 2–5 | Baseline runs on your current docs, including your llms.txt, skills or MCP server if you have them. |
| Days 6–9 | Failure summary and the proposed patches, sent for review. |
| Days 10–14 | Rerun with the patches, one revision round, and the before-and-after numbers. |
What I need from you: access to your docs (public or a staging URL), the three workflows, and one person on your team who reviews the patches.
What the pilot doesn't promise
A guaranteed improvement, or fewer support tickets. Some failures need a product change, not a docs change, and some workflows may already pass. You get the work and the evidence; if a workflow already passes, I'll say so.
Questions you will ask
We can fix our docs ourselves.
You can, once you know where. The hard part is finding the sentence that's missing, and agents don't tell you: they guess and move on. The pilot is the finding, the patch and the proof that it worked.
We already have llms.txt, Context7 or agent skills.
Good, then I test with them in place. The baseline runs use what your users' agents actually get today, and the patches improve it rather than adding another document.
Doesn't the guide just hand the agent the answer?
The rerun uses fresh sessions, and at least one related task that wasn't used to write the patch. If the patch only works on the exact task it was written for, you'll see that in the numbers.
Nobody uses our MCP server yet.
Then the pilot is cheapest now, before the first wave of users meets the gaps. If there's no launch planned and no one owns adoption, it's probably too early, and I'll tell you.
Why are you not promising a number?
Because I'd be making it up. In my evaluation, guides that carried missing facts turned fails into passes, and guides that retold the docs did nothing. Which kind of gap your docs have is what the pilot finds out.
How do we pay?
A fixed price of $1,000, invoiced after we agree on the scope in writing. No subscription, no hourly billing.
Who runs it
I'm Valentina Koniukhova, a developer in Buenos Aires. I run worklore.dev, a library of developer stories that coding agents can execute, and I measure how agents actually use what they read. The work is public:
- When coding agent guides help, hurt, or do nothing: the 438-run evaluation behind the numbers above.
- Check your MCP server in a few minutes: the ten checks agents skip when they test a server.
- How many tools should an MCP server have? 5 to 100 tools, measured in Claude Code, Codex and Gemini.
Tell me which workflow matters most
Send your product and the one onboarding path you most want agents to get right. I'll reply with a scope: three workflows, their success checks and the agent setups. If it isn't a fit, I'll say so.
vkoniukhova@yahoo.com
Every number on this page links to its data, including the runs where the guide did nothing.