Commoditizing Determinism

AI is making code cheaper and making individual parts of software easier to understand. It can summarize modules, trace dependencies, explain unfamiliar implementation, and assemble useful accounts from scattered evidence.

The harder problem is making those local accounts add up. A mature system needs a coherent understanding across domain concepts, workflows, policies, implementation, and runtime evidence. It also needs to validate that this model captures accepted intent and verify that its artifacts satisfy the model.

Code Is Becoming Cheap

For decades, software teams treated code production as a central bottleneck. And for good reason. Boilerplate took time. Framework conventions had to be remembered. Integrations required repetitive ceremony. Tests, serializers, client bindings, validation, and API services all had to be written by someone who could hold both the syntax and the intent in their heads.

AI changes the marginal cost of producing syntax. A competent model can draft a component, convert a data shape, write a repository method, produce an adapter, scaffold an API, translate an interface between languages, explain a compiler error, perform a local refactor, or produce the first version of a test suite. None of this makes engineering automatic, but it does commoditize code production.

That change is easy to misread. If code is cheaper, the tempting conclusion is that teams should produce more of it: more variants, more services, more features, more rewrites, more generated abstractions. Some of that will happen. But abundant code also increases the surface area that must be understood, verified, governed, and evolved.

The gain is real. The bottleneck moves.

Local Understanding Is Not Yet System Understanding

Teams rarely need every implementation detail in their heads. They need a reliable account of the area they are changing and the wider commitments that change could affect.

AI can produce that local account more quickly. It can reconstruct behavior, follow dependencies, compare documents with code, and surface evidence that a person would otherwise have to gather manually. The account becomes useful for change when it connects to the rest of the system.

System-wide understanding is a property of those connections. Local views need to refer to the same concepts, agree where they overlap, preserve constraints declared elsewhere, and reveal contradictions. No single view has to contain the whole system.

Comprehension establishes the relevant part of the graph and its connections. Validation asks whether that graph captures accepted intent. Verification asks whether implementation artifacts satisfy the graph under stated assumptions.

For a particular change, teams may need to know:

• Which facts are authoritative, derived, or merely observed?
• Which invariants must hold before and after a change?
• Which boundaries separate ownership, trust, failure, latency, and commit?
• Which effects are allowed, required, deferred, compensated, or forbidden?
• Which users, roles, regions, tenants, contracts, and runtime states affect the answer?

The evidence for these questions spans code, documentation, product decisions, infrastructure configuration, runtime traces, incident reports, and tests.

When code was expensive, the friction of writing it created organic back pressure. A large change forced a long conversation. A migration forced review. A new service forced architecture debate. The work itself gave requirements time to settle, harden, and justify their cost.

AI reduces the friction of producing a diff and improves the ability to understand it. Trusted change still depends on whether the local interpretation fits the accepted whole and whether the resulting implementation is correct.

AI-Assisted Comprehension Needs Grounding

LLM comprehension is powerful. A model can read code, docs, tickets, pull requests, logs, traces, Slack threads, support cases, design artifacts, and schema definitions. It can summarize a subsystem, identify likely ownership, infer missing context, and draft a plan.

For navigation, explanation, and exploration, a provisional inferred model may be enough. Authority matters when an interpretation approves a change, establishes an invariant, grants permission, or claims that an implementation satisfies a requirement.

The model is performing inference over the context available to it. Some of that context is stale. Some is contradictory. Some was aspirational when written. Some describes a temporary exception that became permanent. Some records what happened, not what should happen. Some is visible to the model; some is outside the window; some is inside a person's memory.

A model can produce a plausible map of the system, but plausibility is not authority. It can say, "this appears to be an idempotent workflow," but that is different from an executable model artifact that states: "this operation is idempotent under these keys, across these retries, with these failure modes."

A recent empirical study of LLM-generated multi-level models makes this distinction concrete. In Can LLMs Learn and Apply Multi-Level Modelling Semantics?, all 90 final outputs could be interpreted as models in the unfamiliar SLICER language, yet Instantiation/Specialisation Correctness ranged from 52% to 79%. The models reliably recovered content stated explicitly in the task while frequently choosing the wrong fine-grained relation kind, omitting implied structure, or missing safeguards that were not stated outright.

The result shows where grounding matters. Syntactic fluency and locally plausible structure can support understanding without constituting an authoritative semantic model. A model can propose meaning, while accepted relations, constraints, and invariants still need to be distilled into an explicit artifact that people and deterministic tools can inspect and validate.

Repository-level generation exhibits the same gap. The Patchwork Problem in LLM-Generated Code describes patches that are locally valid but globally incoherent across configuration, schemas, dependencies, and routing. In its evaluation, 65 of 67 detected structural failures escaped type checking, tests, static security analysis, and regex checks. The missing property was not more plausible code, but explicit repository-wide invariants against which the change could be evaluated.

Explanation becomes authoritative when it connects to commitments: facts that can be reviewed, versioned, tested, queried, and used to reject invalid change.

Statistics Discover; Semantics Commit

Statistical methods are excellent for discovery, suggestion, summarization, translation, and search. They can find likely structure in a codebase, connect a ticket to the files it probably affects, summarize an incident, translate a schema, or propose a migration path.

Software also needs commitment: rules, permissions, states, transitions, effects, constraints, contracts, and authority. These are not merely likely patterns. They are statements the system and the team are willing to treat as accepted.

Useful discoveries need somewhere precise to land. A semantic representation can accept a fact discovered probabilistically after it has been shaped, reviewed, and connected to the rest of the system.

That is the useful distinction. Statistics can discover candidates. Semantics can commit meaning.

Ari applies this pattern to schema matching: learned models retrieve and rank candidate relations, ontologies and constraint solvers enforce admissibility and global consistency, and reviewed results become reusable semantic assets for future inference.

Abstraction as Precision

Abstraction is not a way to be less precise. It is a way to create a semantic level where precision becomes possible.

The goal is not less detail. The goal is the right semantic level for the detail.

At the wrong level, every detail competes with every other detail. The code has HTTP handlers, database rows, retries, queue names, CSS states, serializer options, deployment flags, feature toggles, and access-control checks. These are real details, but they don't all carry equal semantic weight.

At a better level, the system can say: this is an entity, this is a transition, this is a projection, this is a policy, this is an observer, this is an effect, this is a boundary, this behavior is a requirement, this capability is constrained by a specific runtime realization.

That kind of abstraction is not just architectural decoration. It is a precision instrument. It gives the system a ubiquitous language for stating what exists, what can happen, what must remain true, and how the parts are allowed to interact.

Code compiled from that semantic representation becomes a realization of it: concrete, executable, and inspectable, but derived from a more precise semantic level. The important property is the compilation process: deterministic, inspectable, and extensible.

Domain-Aligned Modularity

Many systems are modular at the syntactic level. They have packages, services, repositories, bounded folders, API clients, generated types, shared libraries, helper functions, and deployment units. Those modules are useful. They may improve build times, clarify boundaries, and facilitate local reasoning. But they do not automatically align with system meaning.

A service boundary can cut through a business transaction. A shared package can hide a policy that belongs to a domain. A folder can group files by framework convention while scattering the actual behavior across handlers, jobs, schema migrations, feature flags, and dashboards. A function can isolate reusable code without owning a meaningful domain concept, transition, rule, or effect.

The modularity that matters is domain-aligned semantic modularity. A semantic module has a reason to exist beyond file organization. It captures a portion of meaning: entities, transitions, policies, relations, projections, effects, observations, or commitments that change together and should be reasoned about together.

Semantic modularity asks whether the boundaries people use to understand the domain are the same boundaries the system uses to compile, constrain, test, observe, and change implementation artifacts.

The System Is Scattered Across Tools

Code is only one projection of the system.

A tool like Linear records accepted work, rejected work, priorities, and exceptions. Figma records flow, hierarchy, interaction states, and user-facing commitments. Notion or Confluence records decisions, rationale, terminology, and operating assumptions. GitHub records implementation, pull requests, reviews, CI, and actual change. Slack records informal decisions and clarifications. Observability records traces, metrics, logs, and incidents. Support and CRM systems record user experience, domain pressure, and recurring confusion. Product discussions record what the system is supposed to become.

None of these tools is the system by itself. Together, they contain much of the meaning needed to change the system safely. But the meaning does not accumulate deterministically — it accumulates socially. People remember. Teams agree informally. A staff engineer knows why a service behaves oddly. A designer knows why a flow has an exception. A support lead knows which "edge case" is actually a core customer workflow. The artifacts are loosely linked. They rarely share a durable semantic referent.

Different tools should preserve partial views because each discipline asks different questions. The difficulty is connecting those views through stable semantic identities and explicit rules for how their claims relate. Without that structure, agreement across the system has to be reconstructed for every change.

If code generation becomes cheaper, this scattered meaning becomes more expensive. Every generated change has to be reconciled with facts that are outside the codebase or only weakly represented inside it. A model can search across the trail, but the trail is still a trail.

The emerging category is not just better search over work artifacts. It is a system-intelligence layer: a durable model connecting product intent, domain concepts, design artifacts, implementation, runtime behavior, and operational evidence.

Toward Deterministic Accumulation

Deterministic accumulation is how accepted local understanding becomes part of a coherent system model.

Humans and LLMs can discover structure iteratively. Today that discovery often remains trapped in prose docs, comments, pull request discussions, chat histories, embeddings, local memory, and issue threads.

When a team accepts a claim about the system, it records that claim in a versioned Cohesive artifact with a shape, owner, provenance, and relationship to other claims. Together, those artifacts form a directly inspectable semantic graph. Mechanical compilation resolves stable identities and dependencies, analyzes constraints, and produces implementation artifacts and diagnostics. Given the same graph, compiler version, configuration, and declared external inputs, compilation must produce the same results. LLMs may propose or edit the artifacts, but they do not participate inside this deterministic boundary.

Evidence from code-agent navigation points in the same direction at a narrower structural level. In How Much Static Structure Do Code Agents Need?, injecting static call and inheritance facts improved function localization and roughly halved run-to-run variance on medium-scale repositories. These are repository-topology facts rather than authoritative domain semantics, but they show the value of making stable structure explicit instead of asking each agent run to rediscover it.

For example:

• This operation is safe to retry because this transition is idempotent under this identity key.
• This page is a projection of these authoritative facts, with this permitted staleness.
• This policy applies before this effect crosses this boundary.
• This external integration is eventually consistent and can produce duplicates.
• This state is reconstituted from this durable history, not from the current cache.

LLMs can help draft these statements. Tools can discover evidence for them. Humans can review them. Tests and runtime checks can challenge them. Once accepted, the statements become durable semantic source within the graph and can drive analysis and projection.

Determinism does not establish that an accepted artifact captures everything a person intended, that two concurrent edits commute, or that every projection is correct. It establishes reproducibility at the compilation boundary. The graph can still record uncertainty and distinguish mechanically verified, statically derived, test-backed, declared, assumed, and opaque claims. Provenance explains where a claim came from; assurance explains how strongly the available evidence supports it.

The explicit state can be diffed, queried, and regenerated. It can warn when new code contradicts an accepted invariant and tell an agent which facts are authoritative, which are inferred, and which remain assumption-backed.

The Thesis

The next software layer should make system meaning:

That layer should not replace code. It should make code less isolated. Code should increasingly be compiled from, constrained by, checked against, and explained through a durable account of system meaning.

The shift is simple:

When producing and explaining code becomes cheaper, value moves toward trusted change. Teams need a durable graph they can inspect through focused views, validate against intent, and use to verify implementation and runtime evidence. Deterministic compilation makes the relationship between that model and its realizations reproducible.

Cohesive is one attempt to build around this premise: readable source artifacts that form a reviewable system graph, connecting domain concepts, invariants, boundaries, and effects to implementation artifacts. Deterministic compilers analyze that graph and produce supported realizations. The graph can constrain code generation, surface contradictions, and give agents authoritative context without asking them to infer every commitment again.