Explore the language and its design at onus-lang.org.

Onus is a programming language, and a development environment I’m building around it, that explores a question I keep coming back to as both a developer and a CTO: what gives me sufficient grounds to approve code generated by a model?

I use coding assistants daily and find them extraordinary. But the responsibility for what we ship still belongs to people. As the volume of generated code grows, I want a better basis for judging it than reading ever larger diffs and hoping I’ve spotted everything that matters.

Onus puts more of that basis into the language itself. Function interfaces describe the capabilities code can use, the effects it may have, and the behavioural promises it must keep. Those constraints apply through the functions it calls. A model can rewrite an implementation within the agreed boundaries; changing those boundaries is a separate decision for a human.

The compiler also records how obligations are discharged: through proof, a runtime check, or an explicit assumption about something outside its control. That distinction matters. A promise from an external service isn’t the same thing as a property the compiler has proved, and a reviewer needs to know which they’re relying on.

The planned workbench will turn those compiler records into a review experience. I want to see whether a change needs more authority, weakens a promise, or introduces a new assumption, and use that evidence to decide where closer inspection is needed.

The compiler is already written in Onus. Building the workbench in Onus comes next. This is an experiment in making the grounds for approval clearer; it doesn’t remove the need to judge whether the requirements themselves are sufficient.

I’ve written more about the motivation and the questions I want to investigate in Introducing Onus — The Code Is Generated, The Responsibility Is Still Mine.