Apologies for the delayed send tonight -- it was a busy weekend. Mrs. Prosaic Times and I saw Joe Jackson, and I also spent a lot of time with Claude Code.
There is no such thing as vibe coding, at least for anything important. Coding agents will hard code anything (maybe they are allergic to parameters?) and will always default to procedural over declarative language. Relying on a system prompt is like sending a policy memo to a toddler -- it might be amusing but doesn’t change behavior much. If you want to enforce an architectural standard, create a deterministically fired hook. And if I hadn’t wired up a skill to apply the five whys to root cause analysis, I might have gone batty.
What was I working on? How to think about GenAI and entropy.
From the outside building a system looks simple. You just need some data and some rules to act on that data:
If a customer buys product x, charge her USD 20.00
If a passenger is on the manifest let him on the plane
If a user has rights to a document, let her open it
But we live on Planet Earth. Even before you start to deal with issues like scale, resiliency and security, the data and business rules prove much fuzzier than the simple examples we sketch out on a whiteboard.
Entropy makes enterprise technology expensive and frustrating
In many domains, who is the customer and what is the product can be uncertain; the data may be incomplete; the rules for applying discounts or granting access to resources may get dizzingly complex. A couple of weeks ago, I suggested:
Information systems use a simplified model of an entropic world to derive analytic insights and automate business processes. The more entropic the domain the more expensive it is to build the system and/or the less faithfully it reflects the underlying reality.
Much of the frustration we have with enterprise systems derives from the gap between entropic reality and the deterministic systems we use to model it — that’s why companies spend hundreds of millions of dollars paying to create intricate business rules for their ERP platforms and why account executives complain they hate using CRM applications.
Naturally GenAI doesn’t make a messy world any less messy, but it reduces the cost of reflecting reality in formal information systems (e.g. by converting entropic user requirements to deterministic code or converting free text to structured data). This makes it economical to expand analytics and automation in a way that would not have been economical even a year ago.
Many companies succeeded in automating low-entropy business processes a decade ago or more. Origination systems for consumer credit cards and underwriting systems for personal auto insurance tend to work pretty well. Systems to support provisioning treasury services for large enterprises work less well.
How to look for entropy
So in making decisions about funding and designing AI systems you want to understand where the entropy exists in your business system and how AI could help you ameliorate the challenges it creates -- so I wired up a methodology for assessing business domains for entropy. Again -- I just would not have gotten there without my 5-whys skill.
There are eight markers of entropy
Data opacity: ambiguity, incompleteness, lack of structure and heterogeneity
Rule/path complexity: discretion, rule volume/velocity, path variance, rule interdependency
You can use these markers to score domains — here I did it for governance, risk and compliance in cybersecurity, but the same markers can apply to any business domain.
Here’s the rationales for the scores for Security Governance:
Ambiguity: Governance frameworks provide defined structure, but determining what “adequate governance” means for a given organization’s risk appetite and maturity level involves genuine interpretation — the data exists, but the correct read of it is contestable.
Incompleteness & Unreliability: Governance functions operate on formal documentation — policies, board minutes, audit findings, program metrics. The evidence base is largely complete and verifiable; the bottleneck is not data gaps but the effort of assembly and analysis.
Lack of Structure: The inputs to a governance assessment are almost entirely unstructured — board presentations, committee minutes, risk appetite statements, policy documents, external audit reports.
Heterogeneity: Multiple frameworks coexist (NIST, ISO, CIS, COBIT, SOC 2), but they are generally reconcilable — different naming conventions, not fundamentally incompatible schemas. Moderate cross-system joins, not deep structural incompatibility.
Discretion: Governance decisions — which risks to formally accept, how to rate program maturity, whether to grant policy exceptions — require professional judgment. The framework bounds that judgment but does not eliminate it; edge cases and proportionality calls are routine.
Path Variance: Governance workflows vary sharply by industry, regulatory regime, board composition, and organizational structure -- and often include different paths for different types of issues or questions
Rule Interdependency: Governance rules are densely interconnected — a change in risk appetite cascades to control selection, exception thresholds, audit scope, and reporting requirements. Policies reference standards that reference frameworks that reference regulations; downstream effects of any single rule change are hard to trace.
Rule Volume & Velocity: The regulatory surface is expanding rapidly — SEC cyber disclosure rules, DORA, NIS2, state privacy laws, updated NIST CSF 2.0. Governance teams must continuously track a high and growing volume of requirements that change on timescales shorter than most policy review cycles.
These markers don’t just tell you where to spend — they tell you how to build.
Ontic entropy needs tools that organize context for a human decision, not tools that try to make the decision instead; more automation doesn’t shrink a gap that has no single right answer.
Epistemic and representational entropy point to a different design: instrumentation, ingestion, agentic conversion — the missing piece is data, not judgment, and GenAI’s job is to make structured data cheaper to produce.
Rule-side entropy is a formalization problem, not a data problem: the rules already exist, scattered across policy documents, regulatory text, and precedent — GenAI’s job there is to ingest that material and derive deterministic rules from it, so path variance and rule interdependency get resolved once in code instead of re-litigated by hand every time a case comes up.
If you don’t understand the entropy you face, you might invest in the wrong place or you might build the wrong system — a judgment-support tool for a data problem, or an automation pipeline for a problem that was never going to reduce to a rule.
Appendix: Entropy markers
You can think of entropy in terms of three dimensions
Source: What is the underlying reason for the uncertainty
Degree of uncertainty: How much uncertainty remains after collection of all available facts
Possible mitigation: How GenAI can help bridge the gap between messy reality and formal system
Data opacity
Ambiguity
Description: There are multiple plausible interpretations — the world itself doesn’t have a single answer.
Examples: What stage in the pipeline is this deal in? Who is the decision maker for a corporate customer?
Source: Ontic — the uncertainty is real, not a data gap; more information may provide context, but won’t resolve the question definitively
Degree of uncertainty: Persistent: uncertainty remains above zero even with all available evidence
Possible mitigations: Use GenAI to collect and organize the data required for human judgement. You may not be able to mathematically derive what stage the deal is in, but at least you can know who has provided input on it
Incompleteness and unreliability
Description: Data needed to answer the key question is missing, outdated, or contradicted by another source.
Examples: Incomplete and out of date information about critical systems stored in CMDB
Source: Epistemic — the missing data could in principle be found or the conflict resolved, but right now it isn’t there.
Degree of uncertainty: Approaches maximum — the data that would resolve the question is absent or irreconcilably contradictory.
Possible mitigations: Use GenAI to collect additional information (i.e. by instrumenting processes) or to address anomalies and flaws by inferring patterns
Lack of structure
Description: Information exists but is encoded in formats a system cannot read — email, PDF, voice, handwritten notes.\
Examples: Clinical treatments stored in free text notes. Business cases stored in spreadsheets or word processing documents.
Source: Representational — the information exists and is possibly determinate, just historically expensive to access (i.e. would require an analyst to spend hours converting unstructured text to structured data)
Degree of uncertainty: Artificially high — you can eliminate it entirely, though it has been historically expensive
Possible mitigations: Use agentic data ingestion to convert unstructured text to machine-readable structured data that you can use to derive analytic insights from or transact against
Heterogeneity
Description: Relevant data is split across systems with incompatible formats that cannot be automatically joined.
Examples: Enterprise counterparty exposure spread across trading, lending, and derivatives systems with different identifiers; claims data split across billing, underwriting, and adjudication systems.\
Source: Representational — the information exists and is possibly determinate, just historically expensive to reconcile
Degree of uncertainty: Artificially high — you can eliminate it entirely, though it has been historically expensive
Possible mitigations: Use GenAI to interrogate differences across data sets and create connections to a shared schema
Rule/path complexity
Discretion
Description: The goal and the facts are known, but the correct action cannot be reduced to a rule — professional judgment fills the gap.
Examples: There is no set of imaginable rules for addressing the concerns of an angry corporate customer — requires instinct and tact
Source: Ontic — this is not an information problem; you can’t even define a specific set of actions to pick from
Degree of uncertainty: Remains above zero even with complete information — two experienced practitioners given the same situation arrive at different but equally defensible answers.
Possible mitigations: Use GenAI to capture information and provide humans with additional context required for exercising discretion
Path variance
Description: Cases of the same type require materially different handling — different workflows, skills, or systems depending on the specifics.
Examples: Trade settlement — handling varies by instrument type, counterparty jurisdiction, and settlement method; insurance claims — standard auto, total loss, disputed liability, and catastrophe each require different workflows.
Source: Formalization — converting complicated rules to formal language is possible, but historically expensive
Degree of uncertainty: Ultimately reducible, but historically expensive
Possible mitigations: Use agentic software engineering, which changes tradeoffs about how many rules you can automate economically
Rule interdependency
Description: Rules cannot be evaluated independently — the outcome of one governs which others apply, or multiple rules conflict for the same input.
Examples: Union contracts with grandfathered provisions that modify base rules that themselves modify exception rules; tax deductions subject to phase-outs that interact with alternative minimum tax calculations.\
Source: Formalization — sorting out the interactions among rules is possible but historically expensive
Degree of uncertainty: Ultimately reducible, but historically expensive
Possible mitigations: Use GenAI to reason across the full rule dependency graph; surface conflicts and identify the permissible path when rules interact.
Rule volume and velocity
Description: The rule set is too large to manually search or too frequently updated to keep encoded guidance current.
Examples: Thousands of new potential security rules requiring assessment against a specific asset inventory to determine whether it applies and how urgently; cloud security benchmarks updated quarterly as new services launch, meaning previously compliant configurations go stale without any change on the organization’s part
Source: Formalization — a large rule set is expensive to capture; a fast-changing one means captured rules go stale before teams can update them.
Degree of uncertainty: High because finding and applying the right rule is expensive — not because the answer itself is unclear.
Possible mitigations: Semantic indexing of the full rule set; automated
