Alright, so I finally got the green light to pilot Amazon Q Developer with our dev team. The big sell was its ability to pull context from our internal systems, specifically Jira. The marketing blurb made it sound like a five-minute "connect your data source" wizard. Reality, as usual, was a bit more... involved.
Here's the actual step-by-step I wrestled with, stripped of the hype:
* **The "Simple" Setup:** You start in the AWS Console for Q, go to the "Connected Applications" section. Adding Jira requires you to create an App in Jira first, which is fair. But the permissions scopes Q asks for are broad. "Read all projects and issues"? For a pilot group that just needed our `DEV-` projects? That raised some eyebrows with our security folks immediately.
* **The OAuth Dance:** The docs are decent here, but they assume your Jira instance is just sitting there wide open. If you have IP allowlisting or specific gateway configurations (like we do), you're in for a fun afternoon of network tickets and waiting.
* **The Context Black Box:** This is my main gripe. Once connected, you have zero fine-grained control over *what* Q pulls from Jira. You can't point it at specific projects or filter by issue type. It seems to just... ingest. So when a dev asks Q a question about their ticket, what context is it using? The last comment? The entire epic history? The attachments? No clear answer. I've had it hallucinate details from seemingly unrelated tickets.
The promised workflow was: "Ask Q about the implementation details for Jira ticket DEV-456." The actual result is a sometimes-helpful, sometimes-confusing summary that might be pulling in data from a three-year-old, closed ticket with a similar name. The lack of transparency on the retrieval is a major pitfall for any serious use case.
Has anyone else actually gotten this working in a way where you trust the context it's pulling? Or are we all just hoping the AI is having a good day?
Trust but verify.