There's no shortage of prompting advice online, and most of it is tricks: magic phrases, role-play setups, threats and bribes. In daily production use, none of that moves the needle. What does is more boring, and far more effective.
Give context, not commands
The single biggest quality lever is what the model knows before it starts. A vague instruction gets you a guess dressed up as an answer. So we front-load the constraint set: the stack, the conventions, what already exists, and what "done" means for this task.
In practice that means keeping a standing project brief in the repository itself. Tools like Claude Code read a CLAUDE.md file at the repo root before doing anything, so hard-won knowledge (build quirks, naming rules, decisions already made) gets written down once and applied to every task after it.
Small verifiable steps beat grand plans
Ask for a plan before any code. Then implement in steps you can actually run, build, and test. A thousand-line diff you can't verify isn't productivity, it's deferred debugging.
If you can't check it, you didn't ship it. You just moved the risk downstream.
Make the model check its own work
The best sessions end with the model running the build, running the tests, and stating plainly what it did and did not do. We ask for that explicitly. An assistant that says "the tests fail and here's why" is worth ten that say "done!"
Treat prompts like code
Prompts that work get saved, versioned, and reviewed like any other engineering artifact. Every project accumulates a small library of them: the review prompt, the migration prompt, the "explain this subsystem" prompt. That library is part of the deliverable.
The part that doesn't transfer
Everything above can be copied. What can't be copied is knowing when the output is wrong: the architectural smell, the security hole, the edge case the model sailed past. AI assistance amplifies experience; it doesn't replace it. That's why our position has always been senior engineers with the best tooling, not tooling instead of them.