Tag Archive: software engineering


Year is 2046.

In the beginning, AI was never meant to be deterministic. It was celebrated for its ambiguity, its ability to surprise, improvise, and feel almost alive in its inconsistency.

People called it creativity. Engineers called it progress. Investors called it the future. But something fundamental was being lost in the background.

In early computing, there was an unspoken rule: same input, same output. That principle was the foundation of trust. The C compiler era proved it. Software civilizations were built on reproducibility.

Machines do not “guess”. They execute.

When large language models (LLMs) arrived, that assumption was quietly abandoned.

At first, it didn’t matter. These systems wrote emails, summarized documents, and generated ideas. Variability was even marketed as a feature, “look how human it is”.

Even when engineers tried to enforce stability, temperature at zero, greedy decoding, fixed seeds, randomness still leaked through versions, hardware, and deployment pipelines.

The illusion of control was enough. So we scaled it.

We embedded these systems into workflows, then companies, then governments. We wrapped them in APIs and called them abstractions, even when they were not stable enough to deserve the name.

Each layer built on another probabilistic layer, until the stack resembled engineering, but behaved like weather.

The breaking point was subtle. Not a collapse, but a drift.

A legal assistant gave different interpretations of the same law under different server loads. A medical triage system produced slightly different urgencies for identical symptoms across regions.

Financial systems began averaging decisions that were never meant to be averaged. No single output was wrong. That was the problem, nothing was consistently right.

By the time people noticed, it was already too late to roll back. Everything depended on everything else.

The real tragedy wasn’t power, it was that AI was never built to be a reliable abstraction layer.

We assumed intelligence would converge toward consistency. Instead, it stayed fluid. And we built rigid systems on top of fluid foundations.

Some engineers warned us early. They said determinism was engineering, not intelligence.

Without it, you don’t get systems, you get phenomena. But they were dismissed as nostalgic, stuck in the compiler age.

Now, no one calls it artificial intelligence anymore.

They call it “The Layer”.

A shifting interface between human intent and machine behavior, powerful, unpredictable, impossible to fully reproduce.

Every attempt to stabilize it creates new fractures. Every patch introduces new uncertainty.

And in documentation from 2026, now little more than historical footnote, there is a forgotten line:

“If the same input does not always produce the same output, you are not building an abstraction. You are observing phenomena and negotiating with uncertainty”.

The following dialogue reimagines a famous scene from 𝘛𝘩𝘦 𝘔𝘢𝘵𝘳𝘪𝘹, adapting its themes of choice and hidden truths to the journey of mastering software engineering. It presents the moral dilemma every developer will face at some point in their life: stay in the comfort of quick and dirty hacks, or embrace best practices for lasting improvement.

  • 𝗠𝗼𝗿𝗽𝗵𝗲𝘂𝘀: I imagine that right now you’re feeling a bit like Alice, tumbling down the rabbit hole? Hm?
  • 𝗡𝗲𝗼: You could say that.
  • 𝗠𝗼𝗿𝗽𝗵𝗲𝘂𝘀: I can see it in your eyes. You have the look of a developer who accepts the way things are because you expect them to change on their own. Ironically, this is not far from the truth. Do you believe in fate, Neo?
  • 𝗡𝗲𝗼: No.
  • 𝗠𝗼𝗿𝗽𝗵𝗲𝘂𝘀: Why not?
  • 𝗡𝗲𝗼: Because I don’t like the idea that I’m not in control of my development process.
  • 𝗠𝗼𝗿𝗽𝗵𝗲𝘂𝘀: I know exactly what you mean. Let me tell you why you’re here. You’re here because you know something. What you know you can’t explain. But you feel it. You’ve felt it your entire career. That there’s something wrong with the workflow. You don’t know what it is but it’s there, like a bug in your system, a flaw in your process, driving you mad. It is this feeling that has brought you to me. Do you know what I’m talking about?
  • 𝗡𝗲𝗼: The inefficiency?
  • 𝗠𝗼𝗿𝗽𝗵𝗲𝘂𝘀: Do you want to know what it is? The inefficiency is everywhere. It is all around us, even in this very room. You can see it when you write your code, or when you deploy your application. You can feel it when you deal with bugs, when you encounter constant technical debt, when you push out an update without proper testing. It is the world that has been pulled over your eyes to blind you from the truth.
  • 𝗡𝗲𝗼: What truth?
  • 𝗠𝗼𝗿𝗽𝗵𝗲𝘂𝘀: That you are a slave, Neo. Like everyone else you were born into bondage, born into an endless cycle of quick and dirty fixes, shortcuts, and poor practices, unaware that there’s a better way. A prison that you cannot debug, optimize, or refactor. A prison for your mind… Unfortunately, no one can be told what clean code, maintainable systems, and best practices really are. You have to see them for yourself. This is your last chance. After this there is no turning back. You take the blue pill, the story ends, you wake up in your bed and keep coding the way you always have. You take the red pill, you stay in Wonderland, and I show you how deep the rabbit hole of true software mastery goes. Remember, all I’m offering is the truth, nothing more.

So, are you ready? The choice is yours, blue 🔵 or red 🔴, choose wisely!

Well, to be honest, I just wanted to add a little humor to the mix before the weekend begins. Wishing everyone a fantastic weekend ahead! 😄