doloop.io
THE CODE DONKEY · DETERMINISTIC · BRING YOUR OWN MODEL

AI writes code that looks right
and ships broken.

The same function can be right and wrong at once. Read it as an object lifecycle, it is clean. Read it as a security boundary, it is a missing bounds-check. Both readings are real. A model flattens them into one fluent answer and ships the bug.

The code donkey keeps the readings apart and stops on the one that fails, with the line and the rule. Same code in, same verdict out, every run.

Catch Heartbleed below → How it works →

Your AI reviewer has an opinion. Run it twice, get two: 77% one pass, 63% the next, on the same code. The donkey has a verdict, the same code in and the same verdict out, with the rule and the line. Not “that’s just, like, your opinion, man.” A citation you can replay.

The same function, read five ways

Five reviewers read the same OpenSSL function. The object-lifecycle, functional, and performance reviewers rate it fine. The dataflow and security reviewers catch a length field the caller controls reaching a memory copy with no bounds-check. That gap is Heartbleed. It sat in production for two years.

A model that embeds the function into one vector averages the five readings into "mostly fine, some concerns," and writes the same code. The donkey scores the security reading near zero, stops, and cites the reason: the payload is attacker-controlled and reaches the copy size without a check. The fix is one line; the donkey wants it before merge, not after the breach.

Test-drive it: the real Heartbleed function

Below is the load-bearing part of tls1_process_heartbeat from OpenSSL 1.0.1f (CVE-2014-0160). Run the check. Then load the patched version and run it again. Same code in, the same verdict out.

no key, deterministic, nothing stored.
runs the deterministic rules, no model.

How it works

YOUR RULEBOOK

You bring the rules

The invariants, contracts, and policies your code has to hold, each one named and versioned. Your rules sit on top of the public canon of code smells and security patterns.

YOUR TOOLS VOTE

Existing tools are the witnesses

Your compiler, type checker, static analyzer, fuzzer, security scanner, and profiler each get a vote. The donkey records which of them licensed each line, so the verdict carries its evidence.

• A HARD GATE

Blocked, with a citation

Nothing ships until every rule that applies has passed. When one fails you get the name of the rule, the line it broke, and a citation you can replay.

Two runs on the same code and the same rulebook give the same verdict and the same citations. A teammate or a regulator re-runs it and gets your exact result. A record you can audit.

Run it where your code is

From the API, or the CLI, or a pre-commit hook. Your source never leaves your machine; only the verdict does.

  # API
  curl https://api.doloop.io/v1/check-code \
    -H 'content-type: application/json' \
    -d '{"code": "...your function..."}'

  # CLI (installs once)
  pip install doloopio
  doloop check --donkey code -f changed.c && git commit

The theory behind it, for the regulated and academic reader: the Lattice Coder pattern →