All posts

12 August 2026 — AI

Deterministic or probabilistic

A language model will write you a protocol parser in seconds, and you will not be able to prove it correct. A compiler will take longer and you will. The interesting question is which job each one should have.

Open Markets Initiative · 7 min read

Ask a language model for an ITCH parser and you will have one before you finish reading this sentence. It will look right. It will probably compile. Whether it handles the venue's particular flavour of implied decimal places on a field you did not think to mention is a question you can only answer by reading every line of it — at which point you have done the work anyway, just in the least pleasant order.

Ask a compiler for the same parser and you wait longer, and you get something duller: output that is a pure function of a specification, identical on every run, wrong only in ways that are wrong for every venue at once and therefore findable.

Neither of those is a general-purpose answer. They fail in opposite directions.

Model-generated

Deterministic generation is strong exactly where you would expect. The output is readable because a template wrote it, maintainable because nobody hand-patches it, and fast because the generator knows the field widths at compile time and can emit fixed offsets rather than runtime lookups.

Its weakness is adaptability, and the weakness is real. Anything the model cannot express, the generator cannot emit. A venue that does something genuinely novel needs a change to the intermediate representation — traits, rules, a new dependency kind — and that change has to be made by a person who understands what it will do to the other twenty-nine venues sharing the model. That is slow by design, and it is the cost of the guarantee.

AI-generated

Language models invert the profile. Adaptability is the whole point: describe an edge case in prose and get a plausible handler, with no schema change and no coordination with anything else.

Maintainability is where it collapses. Generated code with no generator behind it is just code — it has no source of truth to regenerate from, so the first time the venue revises its spec you are diffing prose against an artifact nobody can re-derive. Readability lands in the middle, usually good line by line and inconsistent across files. Performance is the same story: idiomatic, rarely the fixed-offset arithmetic you actually wanted on a hot path.

Combined

The useful arrangement is not a contest. It is a division of labour along the line where each side's guarantee actually holds.

Put the model in front of the compiler, where the input is a PDF a human would otherwise have to read. Extracting field tables from a badly typeset specification is exactly the sort of judgement work that a language model is good at and a parser is not. What comes out is not code — it is a proposed normalization, reviewable as a diff against the intermediate representation.

Then let the compiler do what it does: take that reviewed model and emit the dissector, the C struct, the C# class. The output is deterministic again, because the probabilistic step ended before code generation began.

Where the line sits

The rule is narrow enough to state in one sentence: a language model may propose what the specification says, and may never decide what the generated code does.

Everything upstream of the intermediate representation is interpretation, and interpretation is reviewable — a human reads the proposed model, compares it to the published spec, and accepts or rejects it. Everything downstream is mechanical, and mechanical work should be reproducible byte for byte.

Blur that line and you lose the property the whole pipeline exists for. If a model touches the generator's output, then regenerating is no longer safe, diffing no longer tells you what changed, and "the parser matches the spec" goes back to being a claim rather than a fact.