BobTrace

Every engineering team inherits broken services. A microservice starts returning 500s, the original author is gone, there are no logs at the right level, no tests, and no documentation of what the code is supposed to do. The standard response is to spend hours reading source code, forming theories, and making changes that may or may not reproduce the original failure with no way to prove the fix actually works. bobtrace solves this by reversing the order: collect evidence first, then read code only where the evidence points. The problem is not that developers lack debugging skills. It is that they have no structured record of what the code actually did at runtime what inputs reached which function, what it returned, how long it took, and exactly where it failed. Without that record, every debugging session starts from zero, relies on intuition, and produces fixes that cannot be verified without manually re-running the same broken scenario. The solution is a three-layer Python tool. The first layer is an AST-based injector: one command points at any directory of Python files and adds a `@bob_trace` decorator above every function. The decorator records each call's inputs, outputs, errors, and wall time into a structured JSONL file, grouped by request into a complete call tree. The injection is fully reversible `eject` restores the source files to their exact original bytes. No framework changes, no middleware, no configuration. It works on any Python service. The second layer is an analysis engine that reads those traces and answers specific questions: which function is the root cause of each error, grouped by exact raise location; where is time actually going and which call pattern looks like an N+1 query; what does the full call tree for a given request look like. The engine exposes these as seven tools over the Model Context Protocol, the open standard for connecting AI agents to external data sources. The third layer is an AI agent configuration for IBM Bob. When a developer reports a broken service, the agent is constrained to call `diagnose` before opening any source file. It then calls `generate_regression_test` to write a pytest file from the recorded runtime inputs — a test that fails while the bug still exists and passes once it is fixed. Only then does it read the relevant source lines and make the minimal change. The test proves the fix. Target users are engineers who inherit services they did not write a common situation in any organisation that has grown through acquisition, team turnover, or accumulated technical debt. They interact with bobtrace through a single inject command, their normal workflow of running the service, and then either the CLI or their AI assistant. No new infrastructure is required. What makes it unique is the constraint it places on the agent: evidence before source, test before edit. Most AI coding tools start by reading files and generating plausible-looking changes. bobtrace forces the opposite order, which means the fix is grounded in what the code actually did, not what it appears to do, and the regression test means the fix can never silently regress. The result is a workflow that takes an unknown broken service and produces a diagnosed root cause, a failing test pinned to real production inputs, a minimal fix, and a passing test without speculation.