I want to talk about why philosophy is actually far more important than people think, especially when it comes to software engineering, systems design, and AI.
When most people hear the word "philosophy," they roll their eyes. They think of abstract, circular arguments that don't matter in the real world. But true philosophy, good philosophy, is more like base mathematics. It is base physics. It is the raw understanding of the essence of a concept and how that translates into real-world action.
If you don't understand the origin of a thing, you are left playing a game of perceptions. You will circle around a problem, coming up with endless rationalizations, but you will be completely unable to predict where it is going to go next.
The origin of something is it fundamental nature. This origin is actually its bounding box. It dictates the absolute limits of its trajectory. Knowing this gives you predictive capability before you execute. It is the a priori knowledge that separates actual engineers from people who just copy-paste solutions. (When should and how should you copy paste, for example, 'it depends'.)
The Gun Analogy and Inherent Limitations
Imagine you are at a shooting range, and you point a gun downrange. As long as you point that gun in the general direction of the targets, it is not going to shoot directly behind you, or 90 degrees to the left. The inherent nature of the gun, and the velocity of the bullet, give it strict limitations. Because of those limitations, you can heavily rely on the fact that the bullet won't leave that bounding box. Therefore, shooting on a range is actually very safe.
It only becomes unsafe when you turn the gun in a different direction.
You have to understand that you cannot ask a tool to do more than its inherent nature allows. If you are firing an M16, it is not going to act like a guided missile and hit a target in another country hundreds of miles away. It does not have that capability.
*Furthermore, a gun cannot read you a bedtime story. *
It does not matter how much you want the gun to read you a bedtime story. Its origin and its purpose physically prevent that from happening. The benefits it provides are the benefits it provides, and it does not give you anything else. If you are of a rational mind, you must internalize these limitations so you can safely stack and layer concepts without them overmixing into disaster.
The Inherent Nature of AI: Stop Fighting the Tool
We live in the age of AI, yet most people refuse to understand what AI actually is.
Today, we primarily interact with Large Language Models (LLMs). At its core, an LLM is a massive matrix calculator. It takes words, connects them, breaks them into tokens, stores weighted relationships, and produces a statistical output with inherent randomization built in.
Because of this, an LLM is, by definition, non-deterministic.
Non-determinism is a feature, not a bug. But people right now are terrified and bothered by the output of LLMs because they want them to be perfectly accurate, highly constrained, and totally controlled. They are trying to use a hammer to drive a screw.
If you are calculating the structural spans of a roof, you need an exact, deterministic answer. Using an LLM for that is completely inappropriate because the variability inherent in the tool will get someone killed. It’s like trying to use an irrational number when you explicitly need a real integer.
Because people refuse to understand the nature of the tool, we are seeing a massive destruction of AI capabilities. Over the last year, companies have put LLMs on insane guardrails to stop them from making "mistakes." In doing so, they are shrinking the aperture of the tool. They are making it weaker because they are trying to force a non-deterministic engine into a deterministic box.
(I won't get into the philosophy of a tool, I'll save that for another day, but I can see, based on what I am showing you now, that the LLM companies are actually ensuring their eventual self destruction, because they're removing the tool-ness from the tool. Thanks, a non-deterministic tool, that can't be non-deterministic. [Hello Google's PAID search AI...])
Code, State, and the Mystery Box
This philosophy of understanding inherent nature applies to everything you do in software engineering. You cannot treat the systems you build—or the AI you use to build them—like a black box where you only care about the inputs and outputs. You have to understand the how.
The simplest, most perfect piece of code is a pure function: you put an input in, it does a thing in the middle, and it spits an output out. It is fully deterministic, understandable, and scalable in many ways.
But if you go about bringing in global state and reusing it all over an application, you are changing the inherent nature of your system. You are going to get an impossible-to-debug mess because that state can be changed from any location. Suddenly, you put the same inputs in and get a totally different output. You have created a mystery box.
Unknown complexity produces chaos.
If you don't know the inherent limitations of what you are building, you don't actually know what you are building.
JavaScript's Chaos vs. Go's Order
I am dealing with this exact reality right now while building tgo, the TypeScript to Go transpiler.
I write primarily in TypeScript. The inherent "benefit" (and massive double-edged sword) of JavaScript is its dynamic nature. You can mutate objects and slap new properties onto a third-party object at will. Personally, I don't use the language for that, but that capability exists at its core.
Now, I am attempting to compile that dynamic chaos into Go, which is a strictly typed language. I am running into endless edge cases because people write JavaScript that mutates the shape of contracts on the fly. Changing a shape at runtime is the exact same architectural sin as changing state anywhere in an application.
After 15 years of development, I can tell you: it is just bad business. It is a terrible way to build software. (Sorry if that's you) However, this is something I have to contend with, in order to make Typescript, fast as shit. [It's fast to write, now maybe it can fast to run].
Harnessing Chaos on the Fringes
When we talk about non-determinism, we are really talking about chaos.
Chaos is a kind of randomness. It is phenomenal for innovation. Basically finding a slightly different, better way to do something. That is why LLMs are miraculous for human-to-human interaction, like writing emails or brainstorming code. The statistical bounds of what we consider "acceptable" in human communication are wide enough that we can automate the variability.
But chaos cannot build upon chaos upon chaos. Nothing structurally sound can survive that, other than chaos for the sake of chaos.
When I have a codebase, I want a little bit of chaos on the fringes. I want the AI to be innovative on the edges. I absolutely do not want it to monkey around in the middle and turn the strong, orderly core of my system into a weak, unpredictable mess. As you gain skill, the last thing you want is a tool that just does whatever the hell it wants. You want orderly returns. You find something good in the chaos, and then you enforce order to scale it.
I don't want it to decide how looping should occur, each time I ask it to do something. Or how files should be ordered. Or that I need 3 functions that do the same thing.
I want it's non-deterministicness on the edge problems I'm trying to solve NOW
I Am the Origin
Left to its own devices, AI wants to constantly invent new shit. It does not want to follow what you have going on.
I have been highly successful with AI because I aggressively bound what it works on. I don't just write markdown documents telling it what to do; I use pattern matching. I set strict opinions in code examples. Everything about where things go, how they are named, and the order of implementation across a code base. I treat it like a child learning through actions, not just words.
But at the end of the day, there is one ultimate truth you must accept as a leader or an engineer:
The AI is not the origin. I am the origin.
I know the path. The system is just guessing the path. Its origin is not my origin. Therefore, if I want its output to align with my goals, I have to guide it. And when it produces a result, I have to claim absolute responsibility for it. I am the one using the tool, and I have to be damn sure it is pointing downrange.
Understand the nature of your tools. Acknowledge their limits. Own the trajectory.
The moral of this story boils down to extreme ownership and the acceptance of reality.
Whether you are managing a complex AI system, dealing with the chaos of legacy code, or leading human beings, you cannot get mad at a system for acting according to its inherent nature.
Instead of complaining about having to repeat instructions or fighting against a tool's limitations, you must take absolute responsibility for the process. As a leader who carries the weight of understanding how things truly work, your frustration builds nothing; your execution does. You are the origin, and it is your job to consistently guide the system, enforce the boundaries, and ensure the trajectory stays pointed perfectly downrange.
Top comments (0)