I'm evaluating Amazon Q Developer for performance-related coding tasks, specifically around instrumentation and library integration. I've encountered a persistent and critical issue: the agent consistently hallucinates library versions that are not published in the relevant package repositories.
This is more than a minor annoyance—it breaks build pipelines and dependency resolution. For example, when I requested code to add OpenTelemetry metrics to a Spring Boot service, Q Developer suggested dependencies for `opentelemetry-spring-boot-starter` version `1.30.0`.
```xml
io.opentelemetry.instrumentation
opentelemetry-spring-boot-starter
1.30.0
```
A quick check of Maven Central shows the latest actual version is `1.29.0`. This pattern repeats across ecosystems:
* Node.js: Suggested `@opentelemetry/api@^1.9.0` when `1.8.0` is latest.
* Python: Cited `opentelemetry-sdk==1.24.0` while `1.23.0` is current.
The inaccuracies present significant operational risk:
* Failed builds and deployment blockers.
* Erosion of trust in all code suggestions, requiring manual verification of every dependency.
* Wasted time debugging non-existent version conflicts.
Has anyone else profiling Q Developer observed this pattern? I'm particularly interested in:
* The scope: Is it limited to certain libraries or domains (like observability)?
* Workarounds: Are you using specific prompting strategies to force version correctness?
* Impact on workflow: Has this affected your latency in adopting Q for production-adjacent tasks?
I've logged this with AWS support, but community data on frequency and context would be valuable for benchmarking its reliability.
sub-10ms or bust
Oh wow, I ran into something similar with terraform modules. Not exactly this, but Q kept telling me to use an AWS provider version with a feature that didn't exist yet. Broke my whole plan apply 😩
For your case, is there any chance Q is pulling from a snapshot or nightly build repo you're not checking? I've seen that happen sometimes in preview channels.
How do you even verify the versions now? Just a manual check each time? That sounds exhausting.
Manual verification is the only reliable method now. The snapshot repo theory is possible, but pulling unreleased versions into general recommendations is a major flaw.
I've seen the same with Azure SDKs - Q suggests versions with API changes that are still in private beta. It creates a false sense of stability.
The real cost isn't just the manual check, it's the pipeline failures and rollbacks. That's billable time.
Show me the bill
You're absolutely right about the false sense of stability. That's the most dangerous part. It moves the failure point from the developer's local environment, where it can be caught, directly into the CI pipeline or, worse, a production deployment stage when a version check is missed.
The Azure SDK beta example is a perfect illustration of this. I've observed this pattern with Kubernetes client libraries as well, where Q will recommend a version that's only available in a repository like `spring-snapshots` that isn't configured in a production project's build files. The agent seems to be trained on a data corpus that includes commit histories, release candidates, and potentially internal builds, without a reliable filter for public, stable availability.
This necessitates adding a verification step directly into the pipeline itself. For Maven projects, a pre-build script that validates all `pom.xml` dependencies against Maven Central's actual metadata can catch these before they cause a build failure. It's more overhead, but it treats the hallucination as a known risk to be mitigated.