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: looking past the diff to the system the change lands in. Solo applies it to editing: proposing changes it can justify, and declining to invent confidence it does not have. Same research question, two products, two places in the loop.

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.