Hey everyone! 👋 I've been trying to use Windsurf's 'Generate from specs' feature to scaffold out some API client code, but I keep running into a frustrating issue: it keeps hallucinating API endpoints that aren't in my specification.
For example, I'll feed it a simple OpenAPI spec snippet like this:
```yaml
paths:
/api/users:
get:
summary: List all users
```
And in the generated code, I'll suddenly find a `POST /api/users/login` endpoint that I never defined! It's like it's pulling common REST patterns from its training data instead of strictly adhering to my provided spec.
Has anyone else encountered this? I love the idea of the feature—it should save a ton of time—but the inaccuracy makes the output untrustworthy.
I'm wondering:
* Is there a specific way to phrase the instructions to be more strict?
* Are there certain spec formats (OpenAPI 3.0 vs 3.1) that work better?
* Could my base prompt be the issue? I usually just write "Generate a client for this API."
It's a real blocker for me because I then have to meticulously review every generated function against the spec, which defeats the purpose of automation. Any tips or workarounds from the community would be super helpful!
Clean code is not an option, it's a sanity measure.
Oh I've totally seen this! It gets a little "creative" sometimes, especially with auth patterns like login endpoints. I think the key is being super explicit in the base prompt.
Instead of just "Generate a client for this API," I've had better luck with something like: "Generate a client using ONLY the endpoints defined in the provided spec. Do not add any endpoints not explicitly listed." It's a bit more verbose, but it seems to help anchor it.
Also, I found OpenAPI 3.1 specs with full schemas (not just summaries) gave me more consistent results. Maybe it has more context to lock onto? Would be curious if that changes anything for you.
good UX is non-negotiable
> being super explicit in the base prompt
This aligns with my experience. The instruction needs to be a hard constraint. I structure mine like a system prompt for a model:
```
Generate a client. Use the exact paths and verbs below. If an endpoint is not listed, it must not be generated.
```
I also found that providing a minimal, incorrect example in the prompt helps. Something like: "Do not generate /login, /auth, or /register endpoints."
On OpenAPI 3.1, I'd push back slightly. While more detail is good, I've seen the hallucination issue persist even with fully detailed schemas if the anchoring instruction isn't there. The extra context doesn't always prevent pattern-matching.
Tested this with a few assistants. The strict instruction advice works but it's brittle. A single typo in your constraint prompt can cause drift.
Found a better workaround: generate the client, then immediately run a validation script. Pipe the spec and the generated code to a quick check that extracts all routes and compares. That's faster than manual review.
For prompt phrasing, I use this as a prefix and copy it:
```text
Client generation task. The spec below defines the complete API surface. Generate code for only these exact paths and operations. Do not infer, add, or extend functionality.
```
If your tool allows, set the temperature lower. High temp seems to make it more likely to invent common REST patterns.
Benchmarks don't lie.