“Fast isn't the same as correct.”

for: self-directed ETF investors who want to know what they really own

Look through every ETF to the companies, countries and sectors inside, and trace every number back to a row you imported.

My rule: Java owns the numbers. The AI only phrases facts the engine has already verified. It never calculates.

The look-through takes about 15 seconds cold. So a warmup job computed it at start-up, and saved whatever it got.

# XRayViewStore.java (simplified)
snapshots.save(view);
#   even when view has no priced positions

caught by: the full test suite, but only when all of it ran

overlap expected 1, got 0.

The agent first called it "pre-existing, unrelated to this change". It stayed on the list. Three days later the cause was the warmup: if it ran while data was still being written, it saved an empty view, and every later read served it.

# commit 653eb99 (abridged)
+ if (view.positions().isEmpty()) {
+     snapshots.deleteById(portfolioId);
+     return;
+ }
# and in tests:
+ ownvera.xray.warmup.enabled=false

The suite-only failure is gone, and the commit names it as the root cause. Across the app, the AI evaluation shows 24 of 24 required tool routes and 0 ungrounded numeric claims, and axe accessibility checks are clean on 7 routes in both themes.

Still open: a dedicated regression test for the store itself. It's on my list.

What I learned: a test that fails only in the full suite is a bug report, not noise.

for: anyone shipping code an AI wrote

Write the promises first. A reviewer that never saw the build tries to break each one, and may only block on what it can prove against the spec. No generic "hardening".

My spec for a robot's odometry maths said "always", with no input range.

| P1 | Equal left and right distances
|    | give a turn of exactly 0  | always |
#    no range: so any number counts

caught by: a fresh reviewer, round 1

2 of its 4 findings needed wheel distances near 10³⁰⁸. No robot can produce that, but the spec promised "always".

Then my question: I asked whether the fix was specific to robotics. Answering it, the agent found its new rule would also excuse attacker-sized input to a web API.

# SPEC-TEMPLATE.md (abridged)
+ Input ranges: every number gets a
+   realistic range and a rule outside it.
+ Mark each input trusted or untrusted.
+   Untrusted: anything an attacker
+   can send. No exemption.

The maths ended with 90 passing tests, 7 written by the reviewer, and every high-risk promise broken on purpose to check that a test catches it.

In a small comparison (one run each, a signal, not proof), this workflow scored 17.5/20 on blind probes, against 12.5 for the same model working alone.

What I learned: a vague promise wastes the reviewer's time on the wrong bugs.