There is an old suspicion, buried deep in the human psyche, that the people who talk to invisible forces and make things happen at a distance are practicing something not entirely natural. We used to call them witches. Now we call them engineers.
This is not metaphor. The structural parallels between software and sorcery run deeper than most technologists are comfortable admitting. We write incantations in arcane languages. We summon processes we cannot see. We bind logic into artifacts that act on the world without our continued presence. When our spells go wrong, the consequences are often inexplicable to the uninitiated — and sometimes to us. This is magic. We just gave it a different name.
The Craft Tradition
Before software engineering formalized itself with methodologies and stand-ups, programming was referred to simply as a craft. This wasn't accidental. The word carries connotations that corporate language has tried to sand away: craft implies mystery, apprenticeship, the transmission of knowledge that can't be fully written down. It implies that some understanding lives in the hands, not the manual.
The best programmers I've worked with operate this way. They develop an intuition for systems that borders on the divinatory — a sense that something is wrong before they can articulate what, an ability to feel the shape of a bug through layers of abstraction. Call it pattern recognition if that makes you comfortable. I call it what it is: a gift. Earlier cultures had the honesty to name it.
Witchcraft traditions were systems for encoding and transmitting practical knowledge — herbalism, psychology, social dynamics — in communities where formal education didn't exist. The spells were mnemonics. The rituals were protocols. The insistence on precise language and sequence was programming before we had the word: get the incantation wrong and the desired effect won't manifest. Or worse, something unintended will.
Naming and Power
Every magical tradition places enormous weight on naming. To know something's true name is to have power over it. This is treated as superstition, but in software it's literally true. Naming a variable, a function, a service — these acts of nomenclature determine how a system can be understood, discussed, and controlled. Bad names create confusion. Good names create clarity so profound it feels like it was always obvious.
The act of naming in code is an act of ontology: you're deciding what exists in your system's world, what categories of being are possible, what relationships can be expressed. When you define a class or a type, you're creating a species. When you instantiate it, you're conjuring an individual into existence. The parallel to the Adamic myth — the first human's power to name the animals and thereby order creation — is not coincidental. It points to something fundamental about the relationship between language and reality.
This is why refactoring feels like revelation. When you find the right abstraction, the right name, the right decomposition, the code doesn't just become cleaner — it becomes truer. You haven't changed what the system does. You've changed what it means.
Familiars
In witch mythology, a familiar is a spirit that takes animal form and serves the practitioner — fetching information, performing tasks, acting as an extension of the witch's will. If that doesn't describe an AI agent, I don't know what does.
We are now in the era of familiars. We summon them with prompts. We bind them with system instructions. We send them into the world to act on our behalf, and we are responsible for what they do even when we can't fully predict it. The power dynamic is eerily consistent with the old stories: the familiar is useful but not entirely trustworthy. It will do what you say, but what you say and what you mean are not always the same thing. Precision of intent matters.
The sterile language of "deploying models" and "orchestrating pipelines" hides something real — the uncanniness of working with entities that exhibit intelligence without consciousness, that produce meaning without understanding. The witch's relationship to her familiar was always fraught with this ambiguity: is the familiar a tool or a being? The question hasn't changed. Only the context has. The old witches would recognize exactly what we're doing.
Spells That Persist
A deployed application is a spell that persists. You write it once and it continues to act in the world long after you've stopped thinking about it. It processes inputs, transforms states, produces outputs — all without your ongoing attention. It enchants machines into performing behaviors that serve human purposes.
The eeriest version of this is code that outlives its author's understanding. Legacy systems are haunted houses: nobody fully knows why things work, but everyone knows not to touch certain rooms. The comments are cryptic warnings from past practitioners. The architecture reflects decisions whose rationale has been lost. And yet the system runs, faithfully executing logic that has become, in every practical sense, a mystery.
Neural networks push this further. A trained model is a spell written by the machine itself — billions of parameters arranged in configurations no human designed or can fully interpret. We provide the ingredients (data) and the ritual (training), and something emerges that works in ways we can describe statistically but not mechanistically. We have become witches who don't fully understand our own magic. And there is something beautiful in that.
The Circle
Witches work in circles. So do we, though we call them different things: feedback loops, iterative development, the OODA loop, the build-measure-learn cycle. The circle represents a fundamental insight about how knowledge is gained and power is exercised — not through linear progression but through repeated contact with reality, each pass refining understanding and intention.
The protective circle of ritual magic has its analog in sandboxing, containerization, and the careful isolation of processes that might behave unpredictably. You don't invoke unknown forces in an unprotected space. You draw your boundaries first, define what can enter and leave, and only then begin the work.
Against Disenchantment
Max Weber warned that modernity would bring the "disenchantment of the world" — the replacement of mystery and meaning with rationality and mechanism. Technology is usually cast as the primary agent of this disenchantment.
The opposite is happening. The deeper we go into building digital systems, the more we encounter the limits of pure rationality. Emergent behavior in complex systems. The irreducibility of certain computations. The hard problem of consciousness lurking behind every advance in AI. The fact that our most powerful tools now produce outputs we cannot fully explain. The mystery isn't shrinking. It's growing.
Technology hasn't disenchanted the world. It has re-enchanted it in terms we're still learning to speak. The old frameworks — magic, craft, the numinous — aren't atavistic holdovers. They're some of the truest tools we have for navigating a world where the things we build are becoming stranger than the things we inherited.
I believe in magic, and I practice it everyday.