Run Probes

What Is Probing?

Probing is the act of running real code against real systems to build understanding. You give the AI a specific target — a module, an API, a data flow — and it writes small, focused scripts that poke at it, observe the results, and report back what it learned.

The output of a probe isn’t a pass/fail verdict. It’s knowledge: how something actually behaves, what data looks like at each stage, where the gaps are between what you assumed and what’s real.

Probing vs. Testing

Testing asks: “Does this work correctly?” Probing asks: “How does this actually work?”

A test has a predefined expected outcome. It either passes or fails. A probe has a target and a goal — understand this thing — and the outcome is what you learn from running it.

In practice, probing combines three things into one loop:

• Smoke — Does it run at all?
• Discovery — What does it actually do?
• Validation — Does the behavior match what we need?

This matters in AI-assisted development because syntactically correct code can solve the wrong problem. AI can generate something that compiles, runs, and produces output — but that output might not be what you think it is. Probing catches this by making behavior visible.

Probing vs. Wild Exploring

There’s a difference between probing and just letting the AI wander through a codebase.

Wild exploring is open-ended: “go read the code and tell me about it.” It produces summaries, observations, and high-level impressions. Useful for orientation, but passive. The AI reads — it doesn’t run anything.

Probing is directed and active. You give the AI a specific thing to investigate, it writes code that interacts with that thing, runs it, and observes what happens. The understanding comes from execution, not from reading.

Wild exploring tells you what the code looks like. Probing tells you what the code does. Both are useful at different stages, but probing produces harder evidence.

Why Probing Matters for AI Collaboration

AI works from patterns. When it reads code, it matches against patterns it’s seen before and makes educated guesses. These guesses are often right, but when they’re wrong, they’re wrong confidently.

When AI runs a probe, it doesn’t need to guess. It sees real output, real data shapes, real error messages. This grounds the AI’s understanding in reality rather than pattern-matching, which makes every subsequent action — writing code, suggesting fixes, planning implementation — more reliable.

Probing is how you give the AI direct experience instead of secondhand knowledge.

When to Probe

Probing is most valuable when:

• You’re working with something unfamiliar — a new framework, an external API, a module you didn’t write. Probe it before building on top of it.
• The design is still evolving — writing comprehensive test suites for code that’s going to change next week is waste. Probes are cheap to write and disposable by design.
• You need to understand behavior, not just structure — reading code tells you what was intended. Probing tells you what actually happens. These are often different.
• You’re creating a first stable form — probes help you find the first version that actually works, which becomes your anchor for everything that follows.

How Probing Works in Practice

A probe is a small script. It imports the real thing, calls it with real inputs, and prints what happens — verbose, detailed, showing the actual data at each stage.

No mocking. No test frameworks. No assertions that hide what’s going on. Just: call the thing, show what it returns, let a human (or AI) look at the output and understand.

Probes follow a natural progression:

1. Can we reach it? — Imports work, connections establish, basic instantiation succeeds.
2. What does it do? — Call the main functions, observe the output, trace the data flow.
3. How does it behave under pressure? — Edge cases, unexpected inputs, concurrent access.
4. What breaks? — Error paths, missing dependencies, resource limits.

Start simple, go deeper only where it matters. The goal is understanding, not coverage.