
I drop down a level when a problem resists
I started with systems, kernels, schedulers. Plan 9 as a school of thought. I stayed there out of a taste for verifiable detail: a CPU cycle does not argue.
Today I help teams build with AI, from inference engines to agentic systems, for those who cannot settle for an API call. The same discipline as at the CPU-cycle level, applied to models. That way of working is what matters most, ahead of any list of what I have done.
How I work
Measure before forming an opinion. Before a line of assembly, the bandwidth reached against the machine's theoretical maximum. Before trusting a model, what it actually produces, measured. The opinion comes after the measurement.
Never take a model at its word. An agent that looks like it works has not proven that it works. I keep enough distance to say that what I built is not optimal and I go looking for where it breaks.
Apparent simplicity is the finished product, not the starting point. A prompt that seems obvious, where changing a comma breaks everything, is a prompt iterated and measured hundreds of times. What looks simple is often what took the most work.
Reproducible or nothing. When I publish a result, I give you everything to replay it in one command. I hand you all you need to prove me wrong.
Understand before optimising. A system you optimise without understanding produces noise. I start by understanding what is going on. Only then do I touch it.
What the teams I work with find useful is not a model that knows everything. It is a way of working with models that holds up under load and under audit.
Where it comes from
I have been writing code since childhood. First program at six on a ZX81, Z80 assembly at fourteen. I made it my job in 1996, at Uruk. Since then, C, C++, Go, JavaScript and Rust every day, with an affinity for the low levels: assembly (x86_64, SPARC, ARM, RISC-V, Z80), processor architecture, operating systems. More recently, FPGAs (Verilog, VHDL).
I contributed to Plan 9, the successor to Unix from Bell Labs. Hardware drivers, then a bug fixed in the 9vx scheduler, a component that had nonetheless been mathematically validated. The fix has never been replaced.
I have worked on systems where failure is not an option. A library of trigonometric functions in Sparc assembly for the European Space Agency's ERC32 processor, precision required down to 10⁻¹⁵. A memory protection deployed on several tens of millions of machines, zero crashes. A signature-less antivirus, from kernel driver to network filter, for the French Navy and the Ministry of Justice. The same reflex every time: understand what is really happening, measure, do not guess.
Today
I am building a local LLM inference engine, optimised for the CPU, in Rust and hand-written assembly (AVX-512, NEON). Where performance actually breaks: memory bandwidth, latency, cache hierarchy, execution ports. A sovereign engine, resource-frugal, controlled end to end. This site is my notebook: I write what I have just understood, not what I have known for ten years. I document this work in a series of technical articles. I also write about what AI changes in our craft, in particular the developer's responsibility for generated code.
Work together
If you want technical guidance on a project (architecture, performance, AI strategy), you can book a session at meet.dremml.com. My detailed background is on my CV.
Philippe Anel