Jose Manuel Vicente

How it fits together

The engine knows nothing about a user interface. Every operation is a method name and a JSON payload in, JSON out. That one shape lets several front ends sit behind the same engine: the desktop app next to the game, a WebAssembly build in the browser, and fixed fixtures for tests and demos.

Decisions, checked rather than assumed

A setting that did nothing

Problem

A difficulty setting was meant to control how consistent AI drivers are from lap to lap. It stayed in for months, because nothing about using it looked broken.

What I did

Logged thirteen races at different settings and compared the lap-to-lap variation against the setting and against traffic.

Result

The variation followed traffic, not the setting. The assumption went, and the model was rebuilt on what was measured.

The instrument was the anomaly

Problem

A watchdog flagged a share of races as anomalous, and that share was quoted as a health metric.

What I did

Checked every flagged race by hand instead of trusting the rate.

Result

71% of the flags were an artefact of how the watchdog sampled its own data. The real anomaly rate was 5%.

Count the grid that actually raced

Problem

A grid was configured to split 3, 17 and 5 cars across three skill tiers.

What I did

Counted the grid that reached the track instead of reading back the configured value.

Result

It raced as 9, 8 and 8: something downstream renormalised the split. Writing a value and reading it back are two different tests.

How it gets built

Most of the implementation goes through an AI coding agent, under plain rules. Development is test-driven, against an engine harness whose exit code is the number of failing tests. A behaviour is measured before it is changed. And any check that means auditing a large surface, such as every file that could contradict a claim, goes to an agent that runs the exhaustive version a person tends to cut short.