← All use cases

Track down a failing test

Hand Pier a red test and let it dig: reproduce it, trace the failure to its root cause across files, fix it, and confirm the suite is green again.

Pier - billing-worker

TestSettleInvoice fails intermittently in CI. Find out why and fix it.

Let me reproduce it under repeated runs to surface the flake.

Ran go test -run TestSettleInvoice -count=20

--- FAIL: TestSettleInvoice (0.01s)

settle_test.go:48: got status PENDING, want SETTLED

FAIL (3/20 runs)

Reproduced 3 of 20. The settle goroutine isn't awaited before the assertion: a race, not a logic bug.

Edited internal/billing/settle.go (+3 -1)

62- go s.markSettled(ctx, inv.ID)
62+ if err := s.markSettled(ctx, inv.ID); err != nil {
63+ return fmt.Errorf("settle: %w", err)
64+ }

Ran go test -run TestSettleInvoice -count=50

ok internal/billing 0.624s

PASS (50/50 runs)

Root cause was a fire-and-forget settle that the test could outrun. Now awaited and error-checked; 50/50 green. Want me to scan for other go-without-wait calls?

Ask Pier anything… (/ for commands)

sarvam/sarvam-105B (shift+tab to cycle) · / for commands17.2k tokens82%
  1. 01Point the agent at the failing test or paste the CI output.
  2. 02It reproduces the failure locally and reads the code paths involved.
  3. 03It forms a hypothesis, narrows it down, and traces to the root cause.
  4. 04It writes the fix, then re-runs the test and the surrounding suite.
  5. 05You review one diff that explains the bug and proves it's resolved.

A failing test usually points at the wrong place. The assertion breaks in one file while the cause sits in another, and the fix only becomes obvious once you have understood both. A flake is harder again, because it hides behind timing and shared state that you will not catch by reading the code once.

Pier treats it as the investigation it is. It reproduces the failure, reads the code paths involved the way you would, and works across files to tell the symptom apart from the cause. Once it has a fix it does not stop at the one test, it re-runs the surrounding suite so a change here does not quietly break something there. Every step stays on screen and gated, so what you review is a reasoned diagnosis rather than a guess.

An investigation can run long, but it is mostly the agent reading, code, logs, the output of its last attempt, so letting it dig does not run up much of a bill. The cost per task page shows what a debugging session like this actually costs.

Related

Begin here

A gateway between people and intelligence. Join the early-access list and be first to ship with Pier.

$curl -fsSL https://dl.piercode.com/stable/install.sh | sh

1.45k devs and engineers ship with Pier daily