Verified against GitHub Copilot Chat · 2026-08-08
Get Copilot Chat to explain a gnarly legacy function the way a teammate would, not a syntax tour
A targeted /explain-style prompt for one confusing piece of legacy code, aimed at the actual reason it's confusing and the business logic behind it, instead of a line-by-line narration of syntax the reader already knows.
The prompt
Ready to copy — highlighted parts are example details you can swap.
Explain the following code the way a senior teammate would talk me through it at my desk, not the way a syntax reference would describe it line by line. I have it selected in the editor / referenced via #file, so read the actual implementation, not just the function signature. CODE TO EXPLAIN calculateProratedRefund() in billing/refunds.ts WHY THIS IS CONFUSING It multiplies the refund amount by 0.9722 partway through and I can't find any comment explaining where that number comes from. WHO'S ASKING A backend engineer three weeks into the team, comfortable with TypeScript but new to this billing subsystem. BUSINESS CONTEXT IF RELEVANT We changed our refund policy from 30-day to 28-day windows about a year ago, so some of this might be leftover from that. Skip explaining what a for-loop or an if-statement does — assume I can read the language itself. Spend the explanation on the part I actually flagged as confusing: why the code takes the shape it does, not what each line executes in isolation. If a chunk of logic only makes sense as a workaround for something else — a bug in a library, a constraint from an older version of an API, a business rule that isn't visible anywhere in the code itself — say that explicitly rather than describing the workaround as if it were the most natural way to write this. If you can't tell why a particular section exists from the code alone, say so directly instead of inventing a plausible-sounding rationale; a wrong explanation stated confidently is worse than an honest 'I can't tell why this branch exists from what's shown, it might be defensive code for a case that no longer happens.' Give me: what this code is for in one sentence, then walk through the confusing part specifically, then flag anything that looks like it could be a latent bug or dead code rather than intentional logic — but label that section clearly as a side observation, not the main explanation, so it doesn't get mistaken for what I actually asked about.
Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
Copilot Chat's default /explain behavior tends toward a structural walkthrough — describing control flow and syntax in the order it appears — because without a stated target it has no signal for which part of the code the reader already understands versus which part is the actual source of confusion, so it hedges by covering everything at roughly even depth. Naming the confusing part specifically redirects that effort: the model can spend its explanation budget on the one branch or magic number that prompted the question instead of splitting attention evenly across code the reader can already read fine, which is the single biggest difference between an explanation that feels like a wasted read and one that actually resolves the question. The instruction to say 'I can't tell why this exists' rather than inventing a rationale matters specifically for legacy code, where Copilot Chat has a documented tendency to generate a plausible-sounding justification for arbitrary-looking logic — a magic constant or an odd conditional — because plausible narrative completion is what a language model does by default when no comment or commit history explains the real reason; without an explicit permission to say 'unclear,' the model will produce a confident-sounding but fabricated explanation rather than flag the actual gap in available information. Separating the flagged side-observations (possible dead code, latent bugs) from the main explanation prevents a specific confusion where a reader asked 'what does this do' gets an answer that quietly pivots into 'here's a bug I found instead,' burying the original question under an unrelated finding the reader didn't ask for in that message.
What you get back
This function prorates a refund based on how many days into the billing period the cancellation happened. The 0.9722 multiplier at line 42 isn't explained anywhere in this file or its git blame context available to me — it doesn't match a clean fraction of 28 or 30 days, so I can't confidently tell you where it comes from; it may be a rounding artifact from the old 30-day policy that was never recalculated after the switch to 28-day windows you mentioned. Separately, flagging as a side note: the early return on line 12 looks like it could skip the proration entirely for annual plans, which may or may not be intentional.
Verified against
GitHub Copilot Chat 2026.08 · 2026-08-08
Changelog
- 2026-08-08 — Initial publish, verified against GitHub Copilot Chat 2026.08.
Need this built into your business?
If a prompt isn't enough — custom software, built and maintained for you — that's Scult's day job.
EXPLORE CUSTOM SOFTWARE
