vict00r99
Joined 8 months ago
Karma
2
Submissions
7
Member since
Feb 14
Recent submissions
Comment · 8 months ago
You don't map the types, you map the behavior.
Define a behavioral contract (inputs, outputs, edge cases) with test cases, and let each language handle types idiomatically. `dict[str, Any]` becomes `Record<string, unknown>` in TS, `map[string]interface{}` in Go, `HashMap<String, Box<dyn Any>>` in Rust. You don't force one type system onto another.
For dynamic languages, type hints document intent but tests enforce the contract. If the function accepts the specified inputs and produces the specified outputs, the contract is satisfied, regardless of whether types are checked at compile time or runtime.
What do you think?
Comment · 8 months ago
AI coding tools generate different code every time for the same requirement.
RUNE is a specification pattern that fixes this: define a function's signature, WHEN/THEN behavior rules, and test cases upfront.
Give the same spec to any AI tool — the generated code has the same behavior.
It's a pattern, not a framework. Works as YAML files or Markdown sections. Any language, any AI tool, no installation.
Includes 7 skills (markdown files you load into your AI tool) for the lifecycle: create specs, validate, refine, generate tests, detect drift, reverse-engineer from code, multi-language generation.
This is the GitHub project: https://github.com/vict00r99/Rune-stone
Comment · 8 months ago
Hey!Really interesting approach
I’m going to try it in one of my CI pipelines
Quick question: how granular is the allowlist matching, is it exact domain only or do you support wildcards and subdomain patterns
Comment · 8 months ago
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.
Comment · 8 months ago
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.
Building resilient systems and exploring how AI transforms software development. Passionate about infrastructure, data platforms, and empowering engineering teams through automation and intelligent tools.