The Illusion of Determinsim

Sign in<br>Subscribe

A few months ago, I participated in a company-wide hackathon with a group of data engineers. The project was straightforward enough: build tooling to automate some of our data modeling conventions – tasks like auto-generating documentation, scaffolding schema files, and enforcing naming patterns. The kind of stuff that everyone agrees should be standardized but nobody wants to do by hand.<br>During one of our syncs, one of my teammates pushed back on using LLMs for code generation. And that's when the room split:<br>"LLMs are non-deterministic. We can't guarantee the outputs."<br>"Humans are non-deterministic too. That's the whole reason we're building this tool."<br>The first concern is valid. LLMs are indeed probabilistic, and you can run the same prompt twice and get different results. But the second response was harder to dismiss. We were building a tool to enforce consistency that humans had failed to maintain, yet hesitating to use AI for fear it might not be consistent enough.<br>That contradiction stuck with me, and I think it points to something bigger than the hackathon.<br>The implicit hierarchy<br>Much of the skepticism around AI in engineering workflows rests on this assumption:<br>Humans → predictable, reliable, consistent. The deterministic baseline.<br>AI → probabilistic, unpredictable, risky. The non-deterministic wildcard.<br>We hold these two systems to wildly different standards. AI's variance gets flagged as "unreliable." The variance baked into our own work goes mostly unexamined.<br>But look at any sufficiently large codebase. In theory, it should be deterministic. We write schemas, define naming conventions, create style guides, PR templates, review processes. We build systems that are supposed to make the "right way" obvious.<br>In practice, most codebases are an accumulation of local decisions made by different people with different contexts and different interpretations of the same rules. The same business logic gets implemented three different ways depending on which team touched it. Naming conventions drift. Folder structures diverge — not because of a deliberate migration, but because someone started doing it differently and the pattern stuck.<br>"Deterministic" is a generous description of what humans actually produce.<br>Broken windows all the way down<br>In The Pragmatic Programmer, this is called the broken windows theory: once visible disorder enters a system, it changes what people believe is acceptable inside that system. An inconsistency becomes a pattern. A shortcut becomes the new convention.<br>There's empirical support for this in software engineering specifically. In 2022, researchers found that developers working in systems with higher tech debt density were significantly more likely to introduce additional debt themselves (Alfayez et al., 2022). The mess is contagious. Existing disorder doesn't just persist; it reproduces.<br>And this isn't unique to code. In Noise: A Flaw in Human Judgment, Kahneman et al. found that professional judgment is far noisier than anyone expects – radiologists disagree with their own prior readings of the same X-ray about 20% of the time (!!). These are trained professionals applying structured rules under real constraints, and the variance is still enormous.<br>We don't skip steps or drift from conventions because we're careless. We do it because humans aren't deterministic systems either. We get tired and overwhelmed. We forget conventions we haven't touched in six months. We bring habits from previous jobs and apply them without realizing it. We copy the nearest file that looks close enough and treat it as the current standard.<br>The mirror effect<br>We figured out where this argument lands the hard way. Early in the hackathon, we pointed our tooling at documentation generation: have the LLM read a dbt model and produce a standardized description for each column.<br>The outputs were all over the place. One run would describe a column as:<br>the unique identifier for the order<br>the next as:<br>primary key referencing the orders table<br>the next as:<br>order ID<br>Technically all of these descriptions were correct, but also inconsistent in exactly the way we were trying to fix. The instinct was to blame the LLM. But when we looked at the existing human-written documentation, it had the same problem – same inconsistencies, spread across hundreds of files where nobody noticed.<br>The naming convention enforcer was worse. We wanted it to flag non-standard column names, but first we had to define what "standard" meant. We had created_at, creation_date, and date_created all living in production, depending on which team had built the model. The LLM couldn't enforce a convention that didn't exist. And neither could we (humans).<br>The parts that worked well were the most constrained: scaffolding new schema files from a template, generating test configurations from a fixed set of rules. When the inputs were clear and the expected output was well-defined, the LLM was...