C / C++Fast
Built to be close to the machine, for programmers who counted cycles.
Your AI can say it did the work. Devlish lets you prove it.
The failure is not just that models are nondeterministic. It is the whole execution environment: workflows that live in mutable prompts, tools that are opaque, permissions that are conversation instead of enforcement, and answers that cannot be traced back to the work. Devlish replaces that with a program you can read, constrain, test, and replay.
Each one is a snapshot of what developers needed. None of them were designed for the operator who will never look at the code at all.
C / C++Built to be close to the machine, for programmers who counted cycles.
RustBuilt to stop memory bugs, for programmers who audit unsafe blocks.
Python / RubyBuilt for programmer productivity, still assuming a programmer.
JavaScriptBuilt to run anywhere a page loads, read by web developers.
JavaBuilt to run on any OS, maintained by teams of engineers.
Today the person responsible for the outcome may never read the underlying code, ever. The AI writes it, the AI runs it, and the human accountable for the result gets a chat message. No existing language was designed for that person.
Devlish's rule: if a step can be deterministic, remove it from the model. If it requires judgment, expose it as a named checkpoint. Everything around the checkpoint becomes compiled behavior with an identity, declared effects, enforced boundaries, assertions, evidence, and replay.
The difference is not the model. It is whether the work exists as an inspectable program or as a vanished conversation.
Today's agent harness
Reviewing the answer proves nothing about the underlying work. A convincing no-op and a successful run look the same.
With Devlish
Same input, same output, every run. When someone asks "how do you know?", you replay it.
This is the real compiler and VM, running in your browser via WebAssembly. Your code compiles and executes locally; it is never uploaded.
Press ⌘/Ctrl + Enter to run. Programs execute in an isolated sandbox with no network or file access beyond what you pass in.
Each of these runs in the playground above. Load it, change a value, run it.
Encode regulatory tests, like the IRC Section 45 energy community bonus, as programs an attorney can read and an auditor can trace.
Load the energy community exampleVerification workflows that decide approve, escalate, or deny, with the decision logic sitting in plain English instead of buried in a script.
Load the claims triage exampleGive an agent a structured tool interface over MCP. Checkpoints pause a running program for AI or human review before anything irreversible happens.
Load the invoice exampleGive a policy a versioned identity and an effective date. Every run of a governed rule leaves a tamper-evident audit trail you can replay.
How governed rules workThe trust gap between what agents claim and what users can verify shows up across the literature.
Models dynamically choose which APIs to call, when, and with what arguments. The tool chain is decided at run time, not reviewed in advance.
Read on the Why page → ICLR 2025Tool-calling agents are measurably inconsistent across repeated attempts at the same task. The next run may not match the last one.
Read on the Why page → NeurIPS 2024Tool-enabled agents create prompt-injection and unsafe-action risks. Conversational permission is not a security boundary.
Read on the Why page → CHI 2023Microsoft researchers found non-experts struggle to bridge natural-language intent and generated Python. Reading the answer is not reading the code.
Read on the Why page → IEEE VL/HCC 2023Potentially incorrect generated code requires new inspection mechanisms designed for end users, not just for developers.
Read on the Why page → The argumentThe full case: why the execution environment, not just the model, is the failure, and what an inspectable verification layer has to provide.
Read the Why page →The question in every row: can the person accountable for the outcome verify the work?
| Property | Devlish | Agent prompts + skills | AI-generated code | Rules engines |
|---|---|---|---|---|
| Non-engineer can read the effective program | Yes, the English is the source | No, prompts and markdown scattered across a session | No, code the operator cannot review | Partly, through a vendor UI |
| Same input, same output, every run | Yes, compiled and deterministic | No, next run may use different tools and reasoning | Depends on what was generated that day | Yes, inside an opaque engine |
| Effects declared before execution | Yes, Program Manifest, enforced | No, conversational permission prompts | No, full system access | Vendor controlled |
| A no-op is detectable by a non-programmer | Yes, empty logic is visible in readable source | No, a confident answer covers it | No, plausible return values hide it | Rarely, rules hidden behind config |
| Runs leave replayable evidence | Yes, audit trail + byte-for-byte replay | No, the transcript is not the work | No, unless you build it yourself | Sometimes, logs without replay |
| LLM can write it and call it | Yes, MCP server + structured JSON | Yes, that is the problem | Write yes, call as a governed tool, no | No tool interface |
| You own the source | Yes, plain text files in your repo, MIT runtime | Sort of, prompts drift and fork | Yes, but unreadable to the owner | No, locked in the platform |
Devlish came out of a specific, recurring pain. I run a company that handles IRS Section 6418 tax credit transfers, and our compliance rules lived in Python that the compliance team could not read. Every rule existed twice, once in a policy document and once in code, and the two drifted until an audit found the gap.
So I built a language where the readable English version is the only version, and the run itself produces the evidence. It has since run real energy community validations, receipt processing, and invoice reviews. It was born in production, not a lab.
— Andrew Dubinsky, founder of DealStar
Send a note and it lands in Andrew's inbox directly. Early-adopter access, integration questions, or feedback all welcome.