Systemic efficiency: software should be as solid as a well-drafted contract

I spent years split between two crafts that, at first glance, don't speak to each other: law and software engineering. Over time I realized they solve the same problem. A well-drafted contract and a well-designed system do the same thing - they turn uncertainty into predictable behavior. The only difference is the language.

That's where the thesis behind my work comes from, and it'll show up here often: systemic efficiency.

What systemic efficiency is

It isn't optimizing a function. It isn't swapping one database for a faster one. Local optimization almost always moves the bottleneck instead of removing it - you shave 200ms off a query and lose an afternoon explaining why the monthly report is still late.

Systemic efficiency means looking at the whole system - code, process, people, and incentives - and removing friction at the level where it actually matters. Sometimes the answer is technical. Often it isn't: it's a manual step nobody ever questioned, an approval that exists out of fear, a piece of data captured three times because three teams don't trust each other.

The junior engineer asks "how do I make this work?". The senior asks "does this need to exist at all?". Systemic efficiency lives in the second question.

What law teaches about systems

A good contract lawyer doesn't write for the happy case. They write for the day something goes wrong: who's responsible, by when, with what consequence. A contract is, at its core, a catalog of failure modes with pre-agreed responses.

Production software demands exactly the same posture. Code that only works on the happy path isn't a system - it's a demo. What separates the two is explicitly handling what happens when:

• the external dependency goes down at the worst possible moment;
• two processes try to write the same record at the same time;
• the data arrives malformed, duplicated, or simply late;
• the person on the other end does something "nobody would ever do".

A contract clause and an error handler are the same instinct: name the failure before it happens and decide, calmly, what will be done about it. Learn to draft contracts and you learn to design systems that don't wake anyone up at 3 a.m.

AI doesn't change the thesis - it raises the stakes

I work with AI-first architecture because language models are the biggest efficiency lever to appear in my career. But a lever multiplies force in both directions. AI applied to a messy process doesn't produce efficiency: it produces faster mess that's harder to audit.

That's why my work rarely starts with the model. It starts with the boring question: what exactly is the decision this system makes, and based on what? Once that's clear - once the problem has been drafted with the precision of a clause - AI comes in to accelerate something that was already solid. Without it, AI becomes one more source of ambiguity in a place that already had too much.

In high-precision sectors - law, medicine, finance, engineering - this discipline isn't fussiness. It's the difference between a tool people trust and one they switch off after the third mistake.

Why discipline comes before technology

I've trained jiu-jitsu for years, and the belt teaches something the keyboard confirms every day: results are a consequence of correct repetition, not of inspiration. Solid systems aren't born from a brilliant insight; they're born from hundreds of small, disciplined decisions - naming things well, handling the error, writing the boring test, refusing the shortcut that saves an hour today and costs a week three months from now.

Philosophy fits the same line. Before asking how to build, it's worth pausing on what are we optimizing, and in service of whom. Technology is a means, not an end. The best architecture in the world in service of a poorly defined goal is just well-organized waste.

What to expect here

This blog is the notebook where I record those decisions as they happen - not in theory, in practice:

• Architecture and systemic efficiency: where friction actually lives and how to remove it at the right level.
• Applied AI: what works in a real product, no hype and no mystery.
• The law-technology bridge: what each craft teaches the other.
• Discipline and systemic thinking: the part no tool solves for you.

No fixed schedule. When a decision is worth the note, it'll show up here - drafted with the care of a clause, I hope.

• Renan