Commoditizing Determinism | Cohesive Systems
⌘ KSearch Cohesive Systems
All siteSite pagesKnowledge graph<br>Ready
Search Cohesive Systems<br>Find product pages, building blocks, technical articles, and graph definitions.
↑↓ Navigate · Enter OpenEsc Close
AI is making code cheaper and making individual parts of software easier to<br>understand. It can summarize modules, trace dependencies, explain unfamiliar<br>implementation, and assemble useful accounts from scattered evidence.<br>The harder problem is making those local accounts add up. A mature system<br>needs a coherent understanding across domain concepts, workflows, policies,<br>implementation, and runtime evidence. It also needs to validate that this<br>model captures accepted intent and verify that its artifacts satisfy the<br>model.
Core Thesis<br>Cheap code and AI-assisted comprehension increase the value of a durable<br>system graph.<br>The graph connects local understanding through shared identities,<br>relationships, constraints, and provenance. It supports validation of the<br>resulting model and provides requirements against which implementations can<br>be verified.
Code Is Becoming Cheap<br>For decades, software teams treated code production as a central bottleneck.<br>And for good reason. Boilerplate took time.<br>Framework conventions had to be remembered. Integrations required repetitive ceremony.<br>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.<br>AI changes the marginal cost of producing syntax.<br>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,<br>explain a compiler error, perform a local refactor, or produce the first version<br>of a test suite. None of this makes engineering automatic, but it does commoditize code production.<br>That change is easy to misread. If code is cheaper, the tempting conclusion is<br>that teams should produce more of it: more variants, more services, more<br>features, more rewrites, more generated abstractions. Some of that will happen.<br>But abundant code also increases the surface area that must be understood, verified, governed, and evolved.<br>The gain is real. The bottleneck moves.<br>Local Understanding Is Not Yet System Understanding<br>Teams rarely need every implementation detail in their heads. They need a<br>reliable account of the area they are changing and the wider commitments that<br>change could affect.<br>AI can produce that local account more quickly. It can reconstruct behavior,<br>follow dependencies, compare documents with code, and surface evidence that a<br>person would otherwise have to gather manually. The account becomes useful for<br>change when it connects to the rest of the system.<br>System-wide understanding is a property of those connections. Local views need<br>to refer to the same concepts, agree where they overlap, preserve constraints<br>declared elsewhere, and reveal contradictions. No single view has to contain<br>the whole system.<br>Comprehension establishes the relevant part of the graph and its connections.<br>Validation asks whether that graph captures accepted intent. Verification asks<br>whether implementation artifacts satisfy the graph under stated assumptions.<br>For a particular change, teams may need to know:<br>Which facts are authoritative, derived, or merely observed?<br>Which invariants must hold before and after a change?<br>Which boundaries separate ownership, trust, failure, latency, and commit?<br>Which effects are allowed, required, deferred, compensated, or forbidden?<br>Which users, roles, regions, tenants, contracts, and runtime states affect the answer?<br>The evidence for these questions spans code, documentation, product decisions,<br>infrastructure configuration, runtime traces, incident reports, and tests.<br>When code was expensive, the friction of writing it created organic back<br>pressure. A large change forced a long conversation. A migration forced review.<br>A new service forced architecture debate. The work itself gave requirements<br>time to settle, harden, and justify their cost.<br>AI reduces the friction of producing a diff and improves the ability to<br>understand it. Trusted change still depends on whether the local interpretation<br>fits the accepted whole and whether the resulting implementation is correct.<br>AI-Assisted Comprehension Needs Grounding<br>LLM comprehension is powerful. A model can read code, docs, tickets, pull<br>requests, logs, traces, Slack threads, support cases, design artifacts, and<br>schema definitions. It can summarize a subsystem, identify likely ownership,<br>infer missing context, and draft a plan.<br>For navigation, explanation, and exploration, a provisional inferred model may<br>be enough. Authority matters when an interpretation approves a change,<br>establishes an invariant, grants permission, or claims that an implementation<br>satisfies a requirement.<br>The model is performing inference over the context available to it. Some of that context is...