A new Filibuster. Coming soon.
Filibuster,
your agentic
application-level
reliability engineer.
Your agent writes the feature and the test.
Filibuster exposes the assumptions behind them.
You decide what the application should do.
The tests passed.
Who chose the rules?
You asked for a feature. Your agent chose an implementation and wrote assertions. Some of those choices are product decisions you never made.
Filibuster runs the test under dependency failures, makes the consequences visible, and brings those decisions back to you.
Send customers a text confirmation when their ticket purchase is confirmed. Add an end-to-end test and check it with Filibuster.
The test buys one ticket. Every failure and recovery happens inside the application. No second request from the customer.
“Send a text confirmation” leaves a lot unsaid.
What should happen when checkout or a notification fails?
Claude runs the loop.
You make the product calls.
Ask for the feature in conversation. Claude handles the setup, implementation, test and Filibuster run. When a behavior needs your decision, the question and execution evidence sit side by side.
Set up the supported tooling. Write and run the test. Explore failures. Explain the outcome and recommend choices.
Inspect the execution. Say what should happen. You do not need to write the fault scripts or diagnose the payment API.
Apply your decision to the app or test. Replay the failure and retained cases. Continue, then explain the refined requirements and remaining gaps.
Green or red,
the decision is yours.
An assertion verdict tells you whether the code matched the test. These recorded executions ask the next question: did the test describe the behavior you actually wanted?
- 01 / THE TEST PASSED
Confirm an assumption.
Checkout fails cleanly. The assertions pass because Claude already allowed that outcome. Should it be allowed?
- 02 / THE TEST FAILED
Refine the expectation.
The ticket is booked, but the customer sees an error. Is the purchase allowed to stand, or must the app change?
- 03 / THE TEST FAILED
Repair the application.
The customer is charged but gets no ticket. The selected requirement needs a code change, then replay.
THE HEALTHY EXECUTION
The feature works when every dependency responds.
Claude’s test makes one purchase request. One charge, one order, the booked seat, two accepted emails and one accepted text.
Loading saved execution…
Read Claude’s explanation and the recorded decision
Claude’s saved explanation, excerpted from the actual run.
Condensed display of recorded questions and options; the linked original preserves the full wording. Choices were accepted under the operator’s instruction to follow recommendations. These controls display the saved decision; they do not submit a new answer.
A passing test captures one execution.
It establishes the observed healthy result. It leaves open what the application should do when a dependency fails.
Interactive HTML rendered from saved executions. This page does not run new tests. Follow the complete story →
“Is this allowed?”
is a product question.
The agent can inspect the implementation and recommend a repair. You decide the behavior the original request left open.
Finish the paid purchase.
In this run, Claude inspected the payment API, added a status lookup for the existing payment and completed booking when that payment had succeeded. The test verified one charge, one order and one ticket.
Keep this completed purchase.
The checkout reply was lost, but the ticket was booked and messages were accepted. The user chose to keep the purchase despite the error response. Claude changed the conditional test expectation; the application stayed the same.
Find. Clarify. Change. Verify.
- 01
Claude runs the test.
Filibuster records the healthy execution and explores dependency failures.
- 02
Claude shows the outcome.
Read the explanation beside the execution and its business effects.
- 03
You specify the behavior.
Answer the business question. Decide what is allowed or what should happen instead.
- 04
Claude changes and replays.
The agent updates the app or test, then rechecks the failure and retained cases.
Here’s what you asked for.
Here’s what you decided it means.
“Send customers a text confirmation when their ticket purchase is confirmed.”
- Failure before any charge: allow an error with no purchase or notifications; the seat stays reserved. Unpaid provider records may remain in the reviewed setup failures.
- Checkout completed, reply lost: the purchase and required messages stand, even though the customer sees an error.
- Payment completed, reply lost: check the existing payment’s status and finish booking when it succeeded.
- Purchase completes: keep one charge, one linked order and the booked ticket.
- A selected email send fails: allow that missing email, while preserving the purchase and the other required messages.
- Text unavailable before acceptance: retry once internally and verify exactly one accepted text.
- The reviewed text timeout occurs: allow no text, while preserving the purchase and both emails.
One reserved-seat purchase test. One injected fault per execution. Message acceptance by local receivers, not delivery to a real phone or inbox. Two-fault combinations, separate customer retries and database failures remain outside this result.
Read the recorded outcome and remaining gaps →
Build with your agent.
Specify with evidence.
See the feature, the test, the failures and the decisions.
Public packages and installation instructions are coming next.