What it means for software to reason

For most of the last decade, “AI for code” meant prediction: finish the line, suggest the import, rename the symbol. That work matters. It is also not the interesting limit. The interesting limit is whether software can hold a working model of a system — what a change is for, what it touches, what it breaks — and use that model when it acts.

Call that reasoning, for lack of a better word. Not mysticism. Not a claim that models “think.” A practical bar: can the tool justify a decision in terms of the codebase you actually maintain, and can it say when it cannot?

That bar is what Intuitum is organized around. Diffuse applies it to review, Runframe to agent-driven software delivery, and 𝑒 to coding in the terminal. Three products, each built around real repositories rather than isolated prompts.

Comprehension does not arrive as a feature flag. It arrives as infrastructure — indexes, graphs, provenance, evaluation — that makes a repository legible to the machines writing against it. The products are how that infrastructure meets a developer. The lab is where we decide which parts of the problem are worth hardening.

We will write here as the work clarifies: what we are measuring, what we are refusing to claim, and what we learn when a tool that is supposed to reason fails in public. If you are building adjacent systems, or living inside the ones we ship, this is the record.