RealityCheck: Repair Workflows with IBM Bob

AI coding agents are increasingly capable of finding and fixing bugs, but a critical gap remains before those fixes can be trusted in release-sensitive workflows: how does a developer know that the repair was justified, the test defining success was not changed during repair, and the final result is reproducible? A green test suite alone does not answer those questions. An agent could misinterpret a requirement, weaken a test, accidentally change verification inputs, or report success after an incomplete execution. RealityCheck is a structured developer-verification workflow built around IBM Bob that turns contract mismatches into reviewable repair evidence. Developers begin with an application, documented requirements, source notes, and existing tests. RealityCheck guides Bob through a repeatable process: 1. Establish the application's existing baseline. 2. Use parallel read-only investigations to compare documented requirements with implementation assumptions. 3. Present a candidate finding, counterexample, and regression test for human acceptance. 4. Freeze the accepted contract, fixtures, tests, and verification tooling using cryptographic hashes. 5. Reproduce the failure against the original application before allowing repair. 6. Restrict the repair to the application boundary. 7. Re-run the unchanged accepted tests and original baseline through a deterministic runner. 8. Produce an evidence record containing the requirement, application snapshots, original failure, repair, verification results, and limitations. Our prototype demonstrates this on a retail-ingestion application. In the first scenario, all original tests passed, but Bob discovered that invoice identifiers were converted through integers despite a contract requiring exact string preservation. RealityCheck reproduced the leading-zero failure before permitting a one-line repair, then verified the unchanged regression test and baseline suite. The second scenario demonstrates interacting requirements around replay safety, identity conflicts, preservation of distinct records, and batch atomicity. Three behaviors initially failed while one preservation guard already passed. The accepted tests were frozen before Bob repaired the implementation, requiring one fix to satisfy all constraints simultaneously without changing the definition of success. RealityCheck is designed for developers, reviewers, and engineering teams using AI-assisted coding in maintenance, debugging, testing, and release workflows. Its key distinction is simple: Bob proposes and performs the repair. RealityCheck preserves the evidence that makes that repair reviewable. The final verdict is deliberately bounded to verified_for_tested_scenarios, not “bug-free” or “production-safe”, so the strength of the claim never exceeds the evidence collected.