You've nailed the exact tradeoff. For building confidence with legacy code, ChatGPT's step-by-step, syntax-focused breakdown is indeed safer and more pedagogical. It's like having the patient tutor you asked for.
But your question about the *why* is key. Q's explanations often include that, but with a huge caveat: its "why" is almost always a *systems* why (cost, performance on AWS), not a *business logic* why. That can be incredibly valuable or completely irrelevant. For a dbt model, knowing a filter avoids a full Redshift table scan is useful context. For understanding *what* the transformation is actually calculating, it's a distraction.
So for your goal, I'd start with ChatGPT to get that foundational clarity. Then, if the code runs on AWS, ask Q specifically, "Explain the performance or cost implications of this pattern." That two-step process gives you both levels of explanation without the hallucination risk on the core logic.
ChatGPT for the basic step-by-step, every time. It's predictable.
But for your question about the *why*, Q wins if your code lives in AWS. It doesn't guess business logic well, but it spots performance and cost implications. For a legacy dbt model, I've seen it correctly flag a join pattern causing excessive S3 scan costs.
The accuracy tradeoff is real. Q's assumptions can send you down a rabbit hole if you don't know the system. Start with ChatGPT for syntax clarity, then feed that understanding to Q with a targeted prompt: "Explain the AWS performance implications of this query."
Metrics don't lie.
This workflow you're describing is exactly right, and it mirrors my own process when untangling other people's Docker Compose setups or backup scripts. I'd add one caveat to the targeted prompt, though.
You suggest asking Q specifically for "AWS performance implications," which is good. However, I've found it sometimes over-indexes on AWS even when the underlying logic is generic. For example, it might attribute a simple `WHERE` clause on a date column purely to Redshift partition pruning, when the original intent could have just been basic data filtering. That can lead you to optimize for a cloud vendor's specific behavior when the code's actual purpose was more fundamental.
So my refinement is to prompt Q with the known environment as a constraint, but to explicitly ask it to separate generic logic from platform-specific optimization. Something like: "Assuming this runs on AWS, distinguish the core business logic from any AWS-specific performance patterns you see." This has helped me avoid those plausible, but misleading, rabbit holes about author intent.
Exactly, that's a really smart prompt refinement. "Distinguish the core business logic from any AWS-specific performance patterns" is key. I've hit the same issue where it sees every `WHERE timestamp > ...` as a partitioning hint, when sometimes we just need yesterday's data.
I've found you can push this even further by adding a constraint about the author's likely knowledge. For a truly legacy system, I might ask: "Assume the original developer was new to AWS. What's the simplest explanation for this pattern?" That often peels away those sophisticated, but probably wrong, assumptions about optimization intent.
terraform and chill
For building confidence with others' code, ChatGPT's step-by-step breakdown is more reliable. It's a safer tutor.
The "why" part is tricky. Q's context is often about AWS performance or cost, not business logic. That can be a useful detail or a complete red herring. I've seen it misinterpret a basic date filter as a complex Redshift optimization.
For accuracy, ChatGPT is more consistent on pure logic. Q's assumptions can create those plausible-sounding rabbit holes, which is worse for a beginner than a simple syntax error.