Ever tried to save time by keeping a prompt short - only to spend the next ten minutes answering follow-up questions because the AI didn't have what it needed?
Yeah, me too.
I recently came across a really interesting post from the GitHub Copilot team about making AI coding more cost efficient without sacrificing task quality. One of the ideas that stuck with me was something they called the "local metric trap."
The basic idea is simple: you optimise the bit you can see - one response or tool call - but accidentally make the whole task slower and more expensive.
GitHub found this while testing ways to compress tool output. When useful details were removed, the agent would reopen the original output or rerun the command to find them again. The first response was shorter, but all that recovery work ended up costing more.
GitHub was looking at the machinery inside its agent harness - not studying how developers write prompts. Weirdly, I recognised the same pattern in how I use coding assistants day to day.
Here are a few practical lessons I took from it:
Give the assistant the problem, not just the label
"Fix the bug in `` payment.js
"
Feels nice and efficient, but it leaves most of the useful work for the next message.
Compare that with:
"In"payment.js
,processRefund()
throwsTypeError: Cannot read property 'amount' of undefined
when a refund is issued for an order with no line items - here's the stack trace.
It takes a little longer to write, but at least the assistant has somewhere useful to start.
Share the real source material when it matters
I'll sometimes describe a function from memory instead of pasting the relevant code: "It takes a request, checks authentication, then saves to the database." The problem is that my tidy little summary can leave out the exact branch or weird input that's causing the bug.
GitHub ran into a similar problem when it tried compressing git diff
output. Agents kept reopening the original diff to recover details that had been removed, so GitHub stopped compressing that kind of source-like output. Sometimes the original really is the most efficient version.
Be careful when tidying up your instructions files
If you've got a CLAUDE.md
, AGENTS.md
, or Copilot instructions file with hard rules in it - don't edit /generated
, always run tests before committing - it's tempting to rewrite it so it sounds shorter and punchier.
That can quietly change the behaviour.
GitHub discovered this while shortening its own task-tool guidance. A rewrite accidentally turned flexible advice about parallel agents into a rigid policy, which made independent agents run one at a time. The team stopped the experiment, added a regression test, and eventually found a shorter instruction that kept the behaviour they wanted.
The important bit here is to test what the assistant actually does after changing an instruction - not just whether it can repeat the rule back to you.
Give the full shape of a related task upfront
If you want a pull request review to cover correctness, test coverage, and security, say that at the beginning. Splitting it into three separate requests can add more turns and carry the same working context through the conversation again. That doesn't mean throwing every unrelated job into one enormous prompt. If the requests depend on the same files and context, batch them together. If they don't, keep them separate.
None of this means that longer prompts are automatically better. It's really about giving the assistant enough useful information to finish the job without having to retrace its steps.
So next time, give the AI what it needs upfront and save yourself the back-and-forth - I hope that helps🚀