Answer
How do you prevent a coding agent from inventing APIs?
Make it read the interface before using it, and run the code before offering it. Asking it not to invent does nothing.
Give it the actual interface definition to read, and require the code to run before it is offered. An invented method survives instruction and does not survive compilation, which is why the fix is mechanical rather than verbal.
The invention has a clear cause. The shape of the code demands a call with a particular purpose, and the system produces the most plausible thing of that shape. Where the real interface matches the plausible one, this looks like knowledge; where it does not, the same process produces something that is well named, correctly typed in appearance, and absent. Nothing distinguishes the two cases from inside the output.
The first control is supplying the real definition. The type signature, the header, the documentation page for the version in use, the source file. This changes the operation from recall to reading, and reading is reliable in a way recall is not. In practice, pointing the agent at the installed package rather than describing what you want from it removes most of this class outright.
The second is execution. A compiler, a type checker or a test run refutes an invented interface immediately and unconditionally. Any workflow where the code is offered without having been run is one where this whole class of error is passed to the reader, and a great deal of frustration attributed to model quality is actually attributable to that missing step.
The third is version specificity, which is the case supplying the definition does not always solve. A method that existed in an earlier release, was renamed, or is present in a different package with the same name will produce code that is correct for something and wrong for you. Naming the versions in use, and preferring the installed source over documentation found by searching, resolves most of it.
The fourth is the search-first habit for anything unfamiliar. An agent instructed to locate the definition before calling something it has not seen in this codebase behaves differently from one that calls first and repairs afterwards. This is a cheap instruction and it is one of the few instructional controls that works here, because it changes the sequence of actions rather than asking for a disposition.
What does not work is asking for certainty. Instructions not to invent, or to only use interfaces you are sure exist, change the hedging in the surrounding prose and not the generated call, because the call is produced by the same process either way. This is the same pattern as elsewhere: the fix operates on inputs and verification, not on instruction.
A method that does not exist is a guess with excellent spelling, and only the compiler is unimpressed by spelling.
Siddharth Sharma, Context Theory
Related questions
Does giving the agent internet access fix this?
Partly, and it introduces a version problem: documentation found by searching is frequently for a different release than the one installed. The installed source or the local type definitions are a better authority than anything retrieved, because they are the thing the code will actually run against.
Why does it happen more with less common libraries?
Because the plausible shape and the real shape diverge more often where there was less material to generalise from. The practical consequence is to be stricter about supplying definitions in exactly the areas where you are least able to spot an error yourself, which is the opposite of what usually happens.
METHOD
Every figure below carries its source and the date it was verified. Nothing on this page is asserted.
The numbers on this page.
| What | Value | Specific to |
|---|---|---|
| Close rate — response under 5 minutes vs over 24 hours | 32% vs 12% | Category-wide |
| Sub-15-minute compliance — automated routing vs manual only | 62.5% vs 39.1% | Category-wide |
Optifai speed-to-lead benchmark · n=939 companies · Q2 2025–Q1 2026 · verified
2026 speed-to-lead benchmark · verified
What is specific to this page.
| Kind | Claim | Check it against |
|---|---|---|
| Software | An invented interface is produced by the same process as a correct one — the most plausible call of the required shape — so nothing in the output distinguishes the two, which is why the fix must operate outside the generation. | Comparing a correct and an invented call from the same run for any difference in confidence or form. |
| Workflow | Supplying the installed type signature, header or source converts the operation from recall to reading, and pointing at the installed package rather than describing the desired behaviour removes most of this error class. | Running the same task with and without the interface definition supplied and counting non-existent calls. |
| Response | Compilation, type checking or a test run refutes an invented interface unconditionally, so any workflow presenting code without execution passes this entire error class to the reader. | Checking whether presented code has been compiled or run before being offered. |
| Constraint | Documentation retrieved by search is frequently for a different release than the one installed, so local type definitions and installed source are a stronger authority for version-specific correctness. | Comparing a retrieved documentation page's version against the version recorded in the project's dependency manifest. |
Each row would be wrong on another industry's page. Where a sourced figure exists it is in the table above instead; these are the constraints that shape the work and do not happen to be numbers.
Start with the measurement.
Reading about a benchmark is not the same as knowing your own number. The audit produces yours, measured rather than estimated.
$497 · delivered in 5 business days · credited against month one