Sure. I ran a direct comparison during development.
Without RUNE: I asked Claude to write a "validate_password" function twice in separate sessions. First time it required 1 special character and returned a bool. Second time it required 2 special characters and returned a tuple with the error message. Same prompt, same model, different behavior. I did the same with "validate_phone". In the first session it accepted dashes in the number, in the second session it rejected them. Completely different parsing logic. Now multiply that by a team where each developer uses a different AI tool.
With RUNE: I wrote specs for the same functions with explicit WHEN/THEN rules, edge cases, and expected error messages. I generated implementations in different sessions and compared them against reference implementations from weeks earlier. Same behavior every time. Not identical code, variable names and style vary, but the same contract. Same inputs produce the same outputs, same errors, same edge case handling.
What surprised me most was the spec validation step. It caught bugs before any code was written. In one case the BEHAVIOR section defined an error message with quotes around a parameter, but the TESTS section expected it without quotes. That kind of mismatch would normally show up as a flaky test in CI weeks later. The spec caught it at design time, before a single line of code existed.
That’s basically the value. Without RUNE the AI makes reasonable but inconsistent choices every time. With RUNE those choices are locked down in a spec, and the AI follows them. The spec becomes the source of truth instead of the model’s temperature.
this seems interesting, do you have an example of a use case that you found it helped with? (Red green pattern where without RUNE, it failed)?
Sure. I ran a direct comparison during development.
Without RUNE: I asked Claude to write a "validate_password" function twice in separate sessions. First time it required 1 special character and returned a bool. Second time it required 2 special characters and returned a tuple with the error message. Same prompt, same model, different behavior. I did the same with "validate_phone". In the first session it accepted dashes in the number, in the second session it rejected them. Completely different parsing logic. Now multiply that by a team where each developer uses a different AI tool.
With RUNE: I wrote specs for the same functions with explicit WHEN/THEN rules, edge cases, and expected error messages. I generated implementations in different sessions and compared them against reference implementations from weeks earlier. Same behavior every time. Not identical code, variable names and style vary, but the same contract. Same inputs produce the same outputs, same errors, same edge case handling.
What surprised me most was the spec validation step. It caught bugs before any code was written. In one case the BEHAVIOR section defined an error message with quotes around a parameter, but the TESTS section expected it without quotes. That kind of mismatch would normally show up as a flaky test in CI weeks later. The spec caught it at design time, before a single line of code existed.
That’s basically the value. Without RUNE the AI makes reasonable but inconsistent choices every time. With RUNE those choices are locked down in a spec, and the AI follows them. The spec becomes the source of truth instead of the model’s temperature.
I’d really love your feedback. If you’re building with AI, try defining one real function using RUNE and compare the output across tools.