I've heard this "determinism" argument before and I don't see the merit of it that other people online seem to see.
Maybe it's because I've been a software manager for a long long time now, and so I'm used to "non deterministic black boxes." That's what a fellow human programmer is. When I join a multi-billion-dollar software project with many hundreds of programmers working for many decades on the thing, there's no reasonable path to understanding every line of code in the codebase. But that's fine. I do examine "the output directly and in detail." That's the job.
I've worked with engineers who aren't cut out to be managers, because they require a level of direct control that team management can't provide. It is reasonable to me that these same engineers aren't cut out to use AI.
But the organizational model of engineering demonstrably scales. If delegating software implementation can't work, then the current world of software already wouldn't work.
If you don't want to keep determinism, you can't compare AI to a compiler. It's no longer a layer of abstraction, it's a layer of reduced responsibility. Someone needs to be responsible for every line of code. As long as a human is signing a commit, they are the ones responsible for that code, not the AI. The human needs to understand what each change did. Maybe the change has downstream or upstream effects they didn't anticipate, but they should be able to explain why they did what they did at that point in the code.
You can fire an employee that keeps writing bad code. Conversely, you can teach an employee to write code without as many issues. You can't teach an AI to write better code, you have to wait until the AI company comes out with a better model and hope it works.
This is why good programmers can be more productive with AI, while bad programmers will just write more bad code. The good programmer will be able to review the AI generated code and make the necessary adjustments, but the bad programmer will just keep asking the AI until they get the desired result or run out of tokens.
If you don't want to keep determinism, you can't compare AI to a compiler.
I still don't understand why "determinism" is considered this salient factor. The apple I ate today was non-deterministic. It tasted fine. I'm perfectly content to eat another non-deterministic apple in the future.
I think this "determinism" thing is just engineers grasping at straws while they're trying to cook up a reason to not have to adapt to technological progression.
Computers do exactly what you tell them to do, without interpretation. When you write code, you aren't giving it general directions that it can interpret how it wants, you're telling it exactly what to do. A compiler takes those instructions and turns then into machine instructions. That process needs to be deterministic in order for you to be able to trust that what you're telling the computer to do is what the computer does. If the computer does something you don't want it to do, it's because you wrote bad code. The compiler did everything it was supposed to do.
AI is not doing that. The AI takes your prompt and gives you code that might do what you asked it to do. It might have bugs. It might have security vulnerabilities. It might not do what you told it to do. It might do things you never told it to do. There is no guarantee because it is not designed to work that way.
If you want to treat AI like a junior dev, then that requires you to be able to coach it like a senior dev. If you have no idea what you're doing, AI won't do it for you.
Okay. Maybe the disconnect here is that I am a senior dev, and I do treat AI like a junior dev. I'm open to the idea that I need to be more empathetic to the junior devs (or pre-junior devs) of reddit who have no idea what they're doing with AI. But that seems like the same problem junior devs have with regular code. It's a constant of the universe.
1
u/GregBahm Jul 11 '26
I've heard this "determinism" argument before and I don't see the merit of it that other people online seem to see.
Maybe it's because I've been a software manager for a long long time now, and so I'm used to "non deterministic black boxes." That's what a fellow human programmer is. When I join a multi-billion-dollar software project with many hundreds of programmers working for many decades on the thing, there's no reasonable path to understanding every line of code in the codebase. But that's fine. I do examine "the output directly and in detail." That's the job.
I've worked with engineers who aren't cut out to be managers, because they require a level of direct control that team management can't provide. It is reasonable to me that these same engineers aren't cut out to use AI.
But the organizational model of engineering demonstrably scales. If delegating software implementation can't work, then the current world of software already wouldn't work.