I direct AI coding agents to ship tested software — and I measure whether what I build actually works.
Claude Code · MCP · evals · data audits · Vienna
Most of the code in my repositories was written by AI coding agents — mainly Claude Code — under my direction. My part: I write the specification, set the constraints (project instructions, hooks, permissions), decide what gets tested, review the result and reject what does not hold. Release decisions and every claim on this page are mine.
Before a number or a plan is accepted, a separate review round with adversarial instructions tries to break it; that is how the withdrawn result under Measurement was caught. I have not yet run this setup inside an engineering team — that is the job I am looking for.
Made the same way (coding agents under my direction); each entry links to the public result.
- CAM-LDS analysis scripts
(AIT Austrian Institute of Technology, Oct 2026): three commits, accepted
into
main— a prompt script that samples the log lines again in every repetition, as Sect. 5.1.2 of the CAM-LDS paper describes; a script that reproduces the numbers in the repository README's clarification of the paper's stability results (identical prompts in 89 of 198 attack steps); and README notes on data set versions andattack_times.csv. - PAIEC 2026
(NeurIPS 2026 competition, Stanford AIMS, Oct 2026): competition entry with
report and code — a text-free predictor of whether an AI system answers a
benchmark item correctly, with a confirmatory re-run on fresh seeds under
rules frozen before the runs. It includes an audit of the training data
release: the public baseline loader saw only 60 of 156 graded benchmarks,
because the Hugging Face Hub file listing returns the first 100,000 of
385,266 files. I reported this to the organisers and prepared evidence packs
and patches at their request; the public part (lists and three proposed
patches) is in
audit/.
Every test count comes with the command that reproduces it:
git clone https://github.com/christian140903-sudo/<repo> && cd <repo>
npm ci && npm test| Failure it catches | Project | Tests (Node 22, fresh clone) |
|---|---|---|
| Agent memory that loses its history or keeps injected instructions as if they were facts | soul-mcp — memory server for MCP clients; quarantines injected instructions, records provenance; on npm | 374 passing (last verified 2026-10-08) |
An agent reports success: true, but nothing changed |
postcondition-mcp — checks whether the world changed, not whether the agent said so; on npm | 55 passing (last verified 2026-10-09) |
| A skill or agent behaves differently after a model update and nobody notices | behaviorlock — drift gate that compares recorded runs against contracts, without an LLM judge | 73 passing (last verified 2026-10-08) |
| A rule that must hold during an agent run is broken silently | agent-invariants — fail-closed checks for conditions that must stay true | 36 passing (last verified 2026-10-08) |
Referenced by MediaPlural/agent-proven
(its agent-regression skill points to behaviorlock) — a pointer in another
project's documentation, not a usage report.
Status, plainly: built since February 2026, next to a full-time job outside IT. soul-mcp is on npm (current release 4.0.2); postcondition-mcp, behaviorlock and agent-invariants are small v0.1 releases from July 2026. No external users are documented for any of them yet. Passing tests establish only what they cover.
- Two flaws found in my own evaluation harness (Aug 2026): a grader bug, which was fixable, and unequal format instructions between the two arms, which were not. I withdrew the registered result the same day, before it left the project, and discarded the experiment. One registered number I still cannot reproduce exactly from the stored answers. Raw data not yet published.
- A null result from my own evidence inventory (Aug 2026): plain runtime attachment without skills gave no quality gain on 20 tasks at 2.7× the cost (one model, descriptive); the skill effect is unmeasured. Raw artefacts not yet published.
Earlier experiments (Feb–Sep 2026) are archived; details on request.
Self-taught, based in Vienna. I work full-time outside IT, in sales and advisory work, and before that in dispatching — explaining technical things to non-experts is my day job. I started building with Claude Code in February 2026.
If a number on this page does not reproduce, please open an issue in that repository — for the contributions to research code and data, in this profile repository.