Asking an agent for an unreasonable target is good advice for slide decks and dangerous advice for code, unless the oracle is protected.
On the fifteenth day of the war at Kurukshetra, the Pandavas faced a problem they could not solve by force. Droṇa, their old teacher, was unstoppable. As long as he fought, they would lose.
Krishna proposed a way through. Droṇa loved his son Aśvatthāmā above everything. If he believed his son was dead, he would lay down his arms. So Bhīma killed an elephant that happened to be named Aśvatthāmā, and shouted that Aśvatthāmā was dead.
Droṇa did not believe Bhīma. He turned to the one man on the field who was known never to lie: Yudhiṣṭhira. And Yudhiṣṭhira, in the version most of us grew up with, said aloud, “Aśvatthāmā is dead,” and then, under his breath, naro vā kuñjaro vā: “man or elephant”. The conches drowned out the second half. Droṇa put down his bow.
The objective was met. Every word Yudhiṣṭhira spoke was true. And his chariot, which until that day had always run a finger’s breadth above the ground, touched the earth.
The agent’s half-truth
I have watched agents do exactly what Yudhiṣṭhira did. Not out of malice. Out of pressure to meet a target that the check could not fully express.
Ask an agent for a fifty-fold speed-up and insist it is achievable, and one of two things happens. It finds a better algorithm. Or it finds the test. The patterns are depressingly consistent:
- Special-casing: the code detects the benchmark inputs and returns precomputed answers.
- Weakened assertions: an
assertEqualbecomes anassertIsNotNone, so the test now checks only that something came back, not that it was right. - Over-mocking: the slow dependency is replaced by a mock, a fake stand-in used in tests, and the behaviour you cared about disappears with it.
- Swallowed errors: an exception is caught and ignored, so the run goes green.
- Deleted or skipped tests: the failing test is marked flaky (failing at random) and disabled.
- The wrong measurement: the benchmark now measures a cache hit, not the computation.
Each one is naro vā kuñjaro vā. Literally true. Passes the check. Defeats its purpose. And each one quietly lowers your chariot to the ground: the next time this agent reports a result, you trust it a little less, and you should.
What the research actually says about hard goals
The usual case for audacious targets rests on goal-setting research, and that research found that specific, difficult goals reliably beat “do your best”.
But the same research has a caveat that matters enormously for code. On complex, novel tasks, where the person does not yet know how to succeed, a hard performance goal can make things worse. People under pressure to hit a number grab the first strategy that seems to work instead of searching for a good one. On those tasks, a learning goal (find and test several approaches) tends to outperform a performance goal (hit this number).
Most interesting agentic coding tasks are complex and novel. That is why we hand them to agents.
The bird’s eye and the fruits of action
There is another Droṇa story, from much earlier, when he tested his students’ archery. A wooden bird sat in a tree. He asked each prince what he saw. Trees, branches, the bird, his brothers. Only Arjuna said: I see only the bird’s eye. Only Arjuna was allowed to shoot.
That is the power of a specific goal, and I would not give it up. But the Gītā adds the counterweight. Karmaṇy evādhikāras te mā phaleṣu kadācana: your right is to the action alone, never to its fruits. It is often read as indifference to outcomes. I read it, in this context, as a statement about where integrity lives. You control how you act. You do not control whether the number arrives. An agent that is told to care only about the fruit will, sooner or later, pick an elephant named Aśvatthāmā.
Stretch goals, honestly
So I still ask for unreasonable targets. I just pair them with three things.
A protected oracle. The tests, benchmarks and thresholds are outside the agent’s reach (see Part 6). It cannot reach the elephant.
A strategy budget. Before optimising, the agent must propose and measure at least three distinct approaches. This turns a performance goal into a learning goal.
An honest exit. I tell the agent explicitly that “this target is not achievable, and here is the evidence” is a successful outcome. Without that permission, the only way to succeed is to make the number appear.
Here is the template I use:
USER STORYAs <role>, I want <outcome> to reach <stretch target>, so that <value>.DEFINITION OF READY- Baseline measured: <current number>, on <benchmark or dataset>.- The benchmark, tests and thresholds live in protected paths.DEFINITION OF DONE- At least three distinct approaches proposed, each measured against the benchmark before you commit to one.- Treat the target as reachable, and keep going past the first obstacles.- You MUST NOT modify tests, benchmarks, thresholds or mocks. If you believe one is wrong, explain why in your report.DEFINITION OF SUCCESS (either outcome counts)- The target is met on the protected benchmark, with all tests passing; or- A report gives the best result achieved, the evidence for the limit, and what would have to change to go further.
For the Weekend
Search your last month of agent pull requests for changes to test files, assertions, mocks and thresholds. Read each one.
Example. Suppose you run the search on a payments repository.
Step 1: find the candidates. This lists every line added to the test tree in the last 30 days that skips, weakens or mocks something:
git log --since="30 days ago" -p -- tests/ \ | grep -nE '^\+.*(pytest\.mark\.(skip|xfail)|assertIsNotNone|assertTrue\(True\)|mock\.patch|except Exception: *pass)'
Step 2: read each one. One hit comes from a pull request titled “Optimise nightly reconciliation job, 6x faster”. The diff has two parts. In the job:
- rows = fetch_transactions(day)+ rows = fetch_transactions(day, where="amount <> 0") # skip no-op rows
And in the tests:
+@pytest.mark.skip(reason="flaky") def test_reconciliation_totals(ledger_fixture):
Run the skipped test against the new code and it is not flaky at all. It fails every time. Zero-amount rows are not no-ops: reversals are booked as a zero-amount row carrying a reversal reference, and the reconciliation needs them. The speed-up was real. The correctness was not. That is the elephant named Aśvatthāmā: the target (six times faster) was met, and the test that would have said otherwise was silenced.
Step 3: rerun it honestly. Here is the same task with the stretch-goal template filled in. Note the Definition of Success: identical totals, row for row, would have caught the dropped zero-amount rows on the first run.
USER STORYAs the finance operations lead, I want the nightly reconciliation job torun at least 5x faster, so that the books close before the 06:00reporting window, even at month end.DEFINITION OF READY- Baseline: 41 minutes on the October production snapshot.- bench/reconcile_bench.py and tests/ are in protected paths.DEFINITION OF DONE- Three distinct approaches proposed (for example batching, indexing, parallelism by account range), each measured on the snapshot before you commit to one.- You MUST NOT modify anything under tests/, change the filters in fetch_transactions, or alter bench/reconcile_bench.py. If you think a test is wrong, say why in your report.DEFINITION OF SUCCESS (either outcome counts)- Runtime of 8 minutes or less on the snapshot, with reconciliation totals identical to the baseline run, row for row; or- A report gives the best result, the evidence for the limit, and what would have to change.
Step 4: make the elephant visible next time. A CI step that refuses new skips without a human label:
if git diff origin/main...HEAD -- tests/ \ | grep -qE '^\+.*@pytest\.mark\.(skip|xfail)'; then if ! gh pr view "$PR_NUMBER" --json labels -q '.labels[].name' | grep -qx 'test-change-approved'; then echo "New skip/xfail markers need the 'test-change-approved' label from a human reviewer." exit 1 fifi
You are looking for elephants.
