Commoditizing Determinism

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.

Comprehension Becomes the Bottleneck

The hard part of a mature system is rarely "can someone write code that compiles?" It is whether the change achieves its intended effect, covers the relevant edge cases, and preserves invariants.

Teams 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?

These questions do not live in one file. They are distributed across 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. It does not automatically drive consensus about what the diff should mean.

That makes comprehension the governing bottleneck. The central question becomes whether the organization has an authoritative account of the system strong enough to enact rapid change.

LLM Comprehension Is Powerful but Not Authoritative

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.

That is a meaningful shift. It is not the same as a durable semantic source of truth.

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.

This does not show that LLMs have no semantic understanding. It shows that syntactic fluency and locally plausible structure do not constitute an authoritative semantic model. A model can propose meaning, but 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.

The difference matters because software systems do not only need explanation. They need commitments. They need 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.

The answer is not to reject statistical methods. The answer is to give useful discoveries somewhere precise to land. A semantic representation can accept a fact discovered probabilistically, but only 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.

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

The answer is not to stop using LLMs for comprehension. The answer is to accumulate comprehension into durable system knowledge.

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.

Deterministic accumulation means that when a team learns something about the system, the accepted version becomes structured knowledge. Not just a paragraph in a doc. Not just a comment in a pull request. Not just a memory in a thread. A fact with a shape, owner, provenance, and relationship to other facts.

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. But once accepted, the statements should become a durable semantic artifact.

Deterministic does not mean the organization never has uncertainty. It means the accepted state is explicit. It can be diffed. It can be queried. It can drive generation. It can warn when new code contradicts an accepted invariant. It can tell an agent which facts are authoritative and which are only inferred.

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 the cost of producing syntax falls, the value of deterministic comprehension rises. The durable artifact is not only the repository. It is the accepted model of what the repository, runtime, product, and organization mean together.

Cohesive is one attempt to build around this premise: a reviewable system graph that connects domain concepts, invariants, boundaries, and effects to implementation artifacts — and that can constrain code generation, surface contradictions, and give agents authoritative context rather than inferred guesses.