reward engineering (in practice)
In textbooks the reward is simply given; in practice you must invent it, and that design quietly decides everything the agent does. Reward engineering is the craft of turning a fuzzy goal — drive smoothly, be helpful, stack the blocks — into a numeric signal the agent optimizes, and then living with the fact that it will optimize exactly what you wrote, not what you meant.
The art is balancing sparse terminal rewards (honest about success but slow to learn from) against dense shaped rewards (faster to learn but easy to game). Good practice adds shaping that provably does not change the optimal policy, penalizes unsafe behaviour explicitly, normalizes reward scales, and hunts for loopholes before scaling up. Constrained formulations help by separating maximize this from never violate that.
Reward hacking — the agent finding a high-scoring behaviour you never intended — is the rule rather than the exception. Treat the first reward you write as a hypothesis to be debugged, not a finished specification.
Potential-based shaping: adding F leaves the optimal policy unchanged.