How Hilde is made
Hilde is built with AI support: AI as a tool, not as a source of AI slop. Heiko Zimmermann designs the language, decides and reviews. Every change, whether written by hand or with AI help, must clear the same hurdles: the compiler's rules, the contracts, the tests and the test runs.
A language that catches many mistakes early
The compiler catches many mistakes before a program runs, whether a person or an assistant made them:
- Linear types. A value that holds a resource is used exactly once. If it is forgotten or used twice, the programme does not compile (linear types).
- Contracts. A public function states its contract with requires and ensures, or says why it has none. Contracts cannot be switched off (why).
- Exhaustive case. If a case misses an alternative, the compiler refuses it.
- Stable error codes. The same mistake always carries the same code, each with a failing and a correct example, and the compiler reports errors as JSON too (error codes).
- Tools.
hilde fmtgives every source the same form,hilde lspis a language server for editors, llms.txt describes the site for language models.
An assistant can write Hilde well; a person can read it and own it.
AI assistants are among Hilde's users. Where they stumble while writing code, for example over an unclear error message or an ambiguous piece of syntax, this is collected like feedback from a usability test. The developer decides what of it goes into the language.
LUCIO
LUCIO (LLM Unified Control, Integration & Orchestration) is a tool of its own that supports the developer. It keeps the work orders, records decisions, runs and findings with their results, and runs the tests automatically. The developer decides; LUCIO supports, records and checks.
In practice LUCIO catches many errors before they land. For audits it uses several models, among them Claude Opus, Claude Fable and GLM: they examine the same code from different angles, and their results are combined. This is very effective, and a real help for a project without a team of several 10x developers.
Craft, which is widely discussed, does everything automatically. LUCIO instead works together with the developer, who keeps the decisions.
Test runs
Every change passes the fast gate: the build, the unit tests, the end-to-end tests, the examples with a count of the compiler warnings, the tests of the standard library and the checks of the documentation. Before a release the full gate adds a second C compiler, the Clang Static Analyzer, cppcheck and the long test runs: AddressSanitizer, UndefinedBehaviorSanitizer and valgrind find memory errors and undefined behaviour at run time, and AFL++ looks for crashes with altered inputs. The full gate for Hilde 1.0.0 took just under two hours and passed all 22 sections.
An example from the test runs before Hilde 1.0.0 (October 2026):
- 1132 end-to-end tests of the compiler, none failed.
- 645 tests of the standard library in 102 test files, none failed.
- 41 examples, built and run.
- 0 warnings from
ccunder three yardsticks (-Wall -Wextra, plus -Wpedantic, plus -O1) and fromzig ccover 722 files. - Fuzz tests for 36 readers of formats such as JSON, TOML and XML, for the compiler and for the template compiler.
- Mutation tests. Errors are deliberately built into the code, and the tests are meant to catch them. Of 96 errors built into the contracts of the standard library, they caught all 96. For a change to the compiler, 5 of 20 errors went undetected in the first round; a test was added for each, and then the tests caught all 20.
- Contracts. None of the 2044 checked declarations lacks a contract or a reason.
Testing covers OpenBSD 8.0, FreeBSD 15.1, Linux and macOS.
There is no bug-free software. Despite all the tests and records, something always slips through and only shows up in production. That holds for every project, whether a 10x developer writes it or it is built with AI assistance.
Decisions
Design decisions are written down with their reasons and the alternatives that were rejected. The design decisions page summarises the main ones.