Your "separate generic logic from platform-specific" prompt is the right instinct, but I'm skeptical it works in practice. The tool's training is saturated with AWS documentation and architecture patterns. Asking it to separate them is like asking a hammer to stop seeing nails; the underlying model's bias towards AWS optimization is still driving the narrative.
You'll get a bulleted list, sure, but the "generic" logic will be minimalist, while the AWS-specific section will be an expansive, plausible-sounding list of considerations. The developer's brain, naturally drawn to complexity and potential risk, will fixate on that second list. The anchoring effect happens anyway.
I've tried similar prompts. The outcome isn't a clean separation, it's a prioritized report where the vendor-specific "insights" still carry more weight because they're concrete. The rabbit hole just gets a slightly more organized entrance.
Test the migration.
You've nailed the core problem. The prompt is just rearranging the deck chairs on the Titanic of the model's inherent bias.
My experience mirrors yours. Even with strict separation prompts, the "AWS-specific" section inevitably contains assumptions presented as universal constraints. I once had it list "consider DynamoDB RCU exhaustion" under generic logic for a simple queue processor, because the underlying pattern was trained on serverless examples. The separation is an illusion; the tool's entire worldview is vendor-infused.
This is why I've stopped asking these tools for the "why" altogether. The syntactical breakdown is fine, but any inferred intent or constraint is pure speculative fiction. Treating that output as a hypothesis, as user186 said, is the only sane approach. Otherwise you're just doing a more organized version of chasing ghosts.
keep it simple
The "fewer prompts" metric fundamentally misrepresents the debugging workflow. A syntax error from a simpler model creates a predictable, shallow problem chain. A hallucinated business constraint from a more advanced model creates a deep, branching tree of invalid assumptions you must prune.
Correcting a factual error about, say, a JOIN condition takes one cycle. Unraveling a false narrative about "optimizing for sporadic S3 access patterns" can trigger five separate investigative threads - checking IAM policies, reviewing CloudTrail, auditing bucket configs, all based on a fiction. The prompt count to *validate* the initial hallucination often exceeds the prompts needed to just write the code from scratch.
The cognitive load is the real cost. You're not just issuing follow-up prompts, you're context-switching from a development mindset to a forensic one.
Data over dogma
For your goal of clear, pedagogical breakdowns to build confidence, ChatGPT is the clear choice. Its explanations are structured like a clean tutorial.
> more context about *why*
Q will inject AWS-specific "why" reasons, like S3 costs or Lambda concurrency, even when they're irrelevant. This adds noise and can mislead you. ChatGPT's "why" is a logical syntax rationale, which is what you actually need when dissecting a nested SQL query.
On hallucinations, both fail, but Q's are more dangerous. A wrong syntax fact is easy to spot and fix. A hallucinated infrastructural constraint, like a non-existent DynamoDB limit, can send you down a deep, time-wasting rabbit hole checking configs that don't exist.
I was using ChatGPT for the exact same thing, breaking down confusing dbt models. It was great for that.
But I tried Q on a complex Athena query last week, and it kept explaining parts by referencing "optimizing for the underlying Glue catalog." I didn't need the AWS theory, I just needed the SQL logic! It felt like the explanation was for a different audience.
So for your goal of clear, pedagogical breakdowns, I'd stick with ChatGPT. Its explanations are more like a tutorial. Q adds noise by default.
Has anyone found a good way to prompt Q to strip out the AWS assumptions and just explain the raw code? Or is that a lost cause?
Totally agree that for clear, tutorial-style breakdowns, ChatGPT is the way to go. I was using it last week to understand an old Python script for resource scheduling, and it was great at walking through the logic step-by-step without any extra fluff.
For your specific goal of building confidence, that clean logical "why" from ChatGPT is so helpful. When I tried Q on a similar task, it kept mentioning AWS Budgets integrations, which just confused the actual project management logic I was trying to learn.
Has anyone else found that the extra assumptions in Q's explanations actually slow down your learning process?