An agent consistently generates overly verbose commit messages — each message contains 5-7 sentences describing implementation details when the team standard is a single-line imperative statement under 72 characters. The agent's system prompt says: 'Write clear, descriptive commit messages that help developers understand the changes.' Analysis of 200 failing cases shows no tool errors or context issues. Which revision to the agent's instruction would MOST effectively correct this behavior?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Telling the agent to be 'concise and not excessively long' is like telling a junior developer to 'write good code' — it sets no target they can aim for. Effective instruction revision gives a format template, a hard character limit, a concrete example, and an explicit exclusion list. Ambiguity is the enemy of consistent agent behavior; precision is the fix.
Full explanation below image
Full Explanation
The original instruction 'Write clear, descriptive commit messages that help developers understand the changes' is ambiguous in two critical ways: 1. 'Clear and descriptive' in natural language often means detailed and thorough — the opposite of the team's one-line standard 2. No format constraint: without a maximum length, line count, or format specification, the agent defaults to what it considers 'helpful,' which is typically more content rather than less
Effective instruction revision follows the principle of maximum constraint specification:
1. Format template: '<verb> <what was changed>' eliminates ambiguity about structure 2. Hard numeric constraint: '72 characters maximum' is objective and verifiable — the agent can self-check compliance 3. Concrete example: 'Add null check to user authentication handler' shows the exact style expected, conveying length, verb tense, and level of abstraction simultaneously 4. Explicit exclusions: 'Do not include implementation details, reasoning, or multi-sentence descriptions' closes the specific loopholes the agent was using
Option A ('should be concise and not excessively long') is still relative and vague — it does not define what 'concise' means quantitatively and still leaves room for 3-sentence commit messages. The word 'excessively' is especially undefined. Option C (truncation agent) treats the symptom without addressing the root cause in the instruction. Truncated multi-sentence messages would be semantically incomplete rather than properly formatted. Option D (fine-tuning) is a significant investment that is disproportionate to the problem — this is an instruction quality issue, not a model capability issue. Fine-tuning is appropriate when the model lacks the capability, not when the instruction lacks precision.