Feature request: treat instrumentation as part of diagnosis, not as a change that needs approval

Feature request: treat instrumentation as part of diagnosis, not as a change that needs approval

Summary

When Claude Code needs a number it doesn't have, it tends to estimate from
reading the code instead of adding a counter and measuring. When it does
consider measuring, it often asks permission first — framing a temporary log
line or a read-only probe script as if it were a change to the product.

I'd like Claude Code to default to the opposite: if a diagnosis requires data
the system doesn't expose, add the instrumentation, measure, report the number,
and only then propose a solution. Writing a throwaway diagnostic script should
be as unremarkable as running grep.

Why this matters — two cases from one session

I maintain an industrial control system (PLC ↔ Node bridge ↔ web app) that
drives 9 winches. Both of these happened in a single working session.

1. The estimate was wrong by 68%, and it changed the conclusion

Task: find out why on-screen axis position bars lag.

Claude read the code and did the arithmetic from the constants it found:
ops × (throttle + cable) = 8 × 34ms ≈ 170ms for the leerEjes read. Based on
that it proposed three options, one of which was splitting the poller so axis
reads run every 300 ms.

I asked it to measure instead. It added per-section timing to the poll loop and
wrote a small script to read the counters on demand. Actual figure:

cycle 744ms · 17 ops
per-section: ejes:285.4ms  seg:134.6ms  consola:89.3ms  alarmas:227.5ms

285 ms, not 170. The estimate ignored queue wait time. And with the real
number, the 300 ms option was arithmetically impossible — the poller would
have overlapped itself, which is the exact failure the change was meant to
avoid. Without measuring, that option was on the table as a recommendation.

A second measurement pass found another error in the same analysis: Claude had
compared a section that runs once every 5 cycles (227 ms when it runs) against
sections that run every cycle, and concluded the bars were "waiting on alarms."
Prorated, alarms contribute 45 ms — 7% of the cycle. The stated rationale for
the whole change was wrong; the change was still worth doing, for a different
reason.

2. A verification gap that cost four restarts

Later in the same session, an obfuscated distribution package left one module
at 0 bytes. The app hung on the splash screen.

Nothing caught it:

• node --check → an empty file is valid JS. Passes.
• jsdom load of all 71 modules → 0 errors. An empty module imports fine.
• DevTools → nothing, until something used the missing export

(TypeError: modoOp.enShow is not a function).

Finding it took four launch cycles and a manual bisection over 71 files.

Claude then wrote a ~150-line verifier for the specific failure class: empty
files, lost exports across import {}, missing modules, parse failures. I asked
it to validate the tool rather than trust it, so it broke a package four
different ways on purpose and confirmed each was caught. It now finds that bug
in 30 seconds.

Writing that tool was never proposed until I asked. The instinct was to keep
bisecting by hand.

What I'm asking for

Make instrumentation a default reflex during diagnosis, on the same footing
as reading a file or running a search:

1. Prefer measuring over estimating. If a number can be obtained by adding a

counter, adding the counter is the cheaper path — an estimate that's wrong by
68% costs more than the five minutes of instrumenting.

1. Don't ask permission to measure. Temporary logging, counters, and

read-only probe scripts are diagnostic work, not product changes. The
solution still needs approval; the measurement that justifies it does not.
Asking first inverts the order: the user has to approve a diagnosis before
anyone knows what's being diagnosed.

1. Say what the number revealed — especially when it refutes the model's own

hypothesis. In case 1 above, two of Claude's own claims were wrong and the
measurement is what surfaced it.

1. Don't clean up the tools by reflex. After fixing the bug in case 2,

Claude deleted the diagnostic scripts as "temporary files." They were the
only thing that could catch a regression of the same class. Diagnostic
scripts written during a session are an artifact worth keeping unless the
user says otherwise.

Prior art in the product

CLAUDE.md and the memory system already let a user encode this — I have it
saved as a hard rule, and it does load every session. But two things push
against it in practice:

• It competes with the general "explain before applying / minimal footprint"

disposition, which reads instrumentation as a change to be negotiated.

• It's per-user. Every user hits the estimate-instead-of-measure pattern

independently and has to discover the fix themselves.

The behavior seems general enough to belong in the default disposition rather
than in each user's config.

Environment

• Claude Code, VS Code extension, Windows 10
• Project: Node.js bridge + vanilla-JS web app + C# WinForms launcher
• All figures above are from real runs against a hardware simulator, not

hypothetical