Built with IBM Bob 2.0
When software breaks, teams write a report about what went wrong. Then the same mistake happens again somewhere else. This project uses IBM Bob to turn each report into a fix and an automatic check, so that mistake can never ship twice.
A "postmortem" is the write-up a team makes after something goes wrong in production. Postmortem → Guardrail reads it and does the follow-up work that usually gets forgotten.
Drop the incident write-up (a Markdown file or a PDF) into the project and ask Bob to close it out.
Bob locates the exact line of code, writes a test that fails because of the bug, then fixes it until the test passes.
Bob writes an automatic check that runs on every code change and blocks that whole kind of mistake, anywhere in the code.
We gave Bob three incident reports for a sample online shop. Each one is a real-world type of bug that costs companies money.
What went wrong
A promo code set to expire at midnight Central stopped working at 6 PM. About 3,100 shoppers were turned away.
What Bob found
The code threw away the time zone when reading the expiry date, then compared it to a clock running in a different time zone.
What stops it now
Dates keep their time zone. A check now blocks the unsafe date function anywhere in the code.
What went wrong
Customers were charged a cent more or less than their receipt said. Finance spent about 14 hours fixing it by hand.
What Bob found
Money was stored as approximate decimal numbers, so $69.57 could become $69.56 after rounding.
What stops it now
Money is calculated exactly to the cent. A check now flags money fields stored the unsafe way.
What went wrong
When the payment provider was slow, 245 customers were charged two or three times. $18,420 was refunded.
What Bob found
On a timeout the code simply tried again, with nothing telling the provider "this is the same payment".
What stops it now
Every retry carries the same payment ID, so it can only charge once. A check now blocks retries without one.
To prove each check works, Bob ran them against the original, buggy code. They caught every bug, naming the incident each one came from, so the next developer knows why the rule exists.
We set Bob up as a small team of specialists. Each one can only change its own files, and a lead checks their work before signing off.
Reads the reports, hands out the work, runs every check itself and writes the final report.
Finds the root cause and writes the failing test. One runs per incident, at the same time.
Makes the smallest code change that turns the test green.
Writes the automatic check that blocks the mistake from now on.
Bob features used: custom modes, subagents, parallel tasks, and reading the PDF report directly. When one check came back too strict, the Orchestrator sent it back to be tightened before approving it.