To get an agent to do work for you, you first need to know what LLMs are good at and what they aren’t. Skip that, and you end up either giving up on things that would have worked, or pushing on things that never will. An LLM takes instructions in natural language, and it moves exactly as precisely as those words are specific. That’s why the word “engineering” is attached here. It’s not just conversation — it’s the craft of designing instructions so the result you want actually comes out. And the first layer of that craft is prompt engineering.
“Be specific with your instructions.” You’ve heard it somewhere. But until you’ve actually run an agent yourself, you don’t really understand why it’s true.
Being vague is convenient in the moment. “Fix this for me.” Three words and you’re done. Being specific, on the other hand, is a hassle. You have to look up file paths, check the values you want changed, and your instruction grows to three lines. The problem is what happens after you skip that hassle. If the agent guesses wrong about what to fix, you look at the result, explain again, wait again, and when it misses again, you explain again. The time you saved by talking short comes back multiplied as rework. The vague one-liner is the most expensive instruction there is — not measured by the seconds it takes to say, but by the cost that comes back later.
Say “fix the config file in this project,” and the agent has no idea how many candidate config files it needs to dig through. It has to ask whether you mean package.json, .claude/settings.json, or tsconfig.json — and if it guesses wrong, it edits a file you never meant to touch. Instead say “raise the PreToolUse hook timeout in @.claude/settings.json from 20 to 30 seconds,” and the file, the location, and the new value are all already decided. Nothing to ask back, nothing to guess wrong.
There are a few concrete, hands-on ways to be specific.
Don’t describe files in words — select them directly with @. Not “you know, that config file,” but @src/config.ts. For folder-level work, point at the folder with @. The time the agent spends wandering around figuring out where to start shrinks. If you have criteria, don’t paraphrase them — hand them over as-is. Not “clean this up reasonably,” but the actual policy, the actual numbers, the actual conditions.
Errors work the same way. Don’t explain “it threw an error when I ran it” — paste the error message whole. The moment I summarize, information gets shaved off. The original text is the most accurate thing there is.
Don’t hand off big tasks straight away. Say “show me your plan first,” and you can catch the direction before it drifts. Fixing one line at the planning stage is far cheaper than looking at ten modified files and saying “that’s not what I meant.”
Last, completion criteria. Put “what to look at to know it’s done” into the instruction itself. Something like “fix it, run the tests, and it’s done when they pass.” With this, the agent verifies its own output before finishing. The final check is still mine, of course. But the minimum verification is already done by the time it reaches me, so I’m far less likely to open the result, see an error screen, and have to instruct all over again.
In the end, specific instructions are hassle paid in advance. Spend a little more when you speak, and you erase the time spent re-explaining after a result goes sideways. Prompt engineering sounds like a grand name, but this is all it takes to start.