Save Tokens, Save Time: Practical Tips for Coding Effectively with AI

The more I use an AI coding assistant for everyday work, the more I realize its effectiveness isn’t just about how smart the AI is, but about how well I communicate with it. This isn’t a generic tips list you can find anywhere — these are lessons I picked up from my own mistakes, one at a time.

Ambiguous instructions are expensive, not just in tokens

Early on, I’d give short instructions like “build a login form” without spelling out the scope. The result was often over-engineered — email validation with a complex regex I never asked for, state management more complicated than needed, error handling for scenarios that would never happen in a small internal project. It took a few rounds of correction before I realized: the more ambiguous the instruction, the more the agent “fills the gap” with assumptions that don’t necessarily match what I meant. Now I make a habit of stating scope explicitly — “simple login form, just email and password, no remember-me or social login” — and the result lands much closer to what I had in mind on the first try.

An AI that sounds “confident” isn’t the same as one that’s correct

This one still stings a bit. There was a time the agent said “I’ve tested it, the function works correctly” — but when I checked manually, it turned out it had just read the code and reasoned about it logically, not actually run the test. The bug only surfaced when I tried it by hand in the browser. Since then I never trust an “it works” claim without seeing the test output myself — a command that was actually run, a result that actually came out, not a summary that sounds plausible.

Enough context reduces iterations, not just “politeness”

I used to be stingy with context — only handing over the one relevant function, to save tokens. That backfired: the agent guessed at conventions used elsewhere in the codebase, and the result often didn’t match existing patterns. Now I more often let it read two or three related files plus one example of an existing pattern, and the total tokens spent on that upfront context is usually cheaper than the tokens spent on three or four rounds of correction from a wrong guess.

Backups aren’t for “just in case,” they’re for “will definitely get used”

One incident made this a hard rule for me: the agent was refactoring a config file, and somehow got carried away and deleted a few unrelated lines that had nothing to do with the task — just gone, without me asking. Luckily I was working on a clean git branch, so it was just git diff and reverting the unnecessary part. If I’d been working straight in the working directory without granular commits, I wouldn’t have known exactly what changed. Small commits before handing the agent a big task stopped being a nice habit and became a requirement.

Not every token saving is a good one

Ironically, I’ve also overcorrected the other way — cutting context too aggressively to save tokens, then having to repeat the same instruction several times because the agent forgot a constraint I mentioned at the start of the session. The balance isn’t “as lean as possible,” it’s “enough that it doesn’t have to guess.” That’s something I’m still calibrating per project, since every codebase has a different level of context complexity.