If someone says something happens and the code says something else, the code wins.
You're implementing quicksort. The actual algorithm is a conceptual piece of math. You write the code. But sometimes the code produces output that isn't sorted.
The code "wins" in that whatever the code says is what actually happens. But the code is wrong. It must be edited to match the algorithm. The _algorithm_ is the thing that is proven correct; the _algorithm_ is what we wanted to execute. The code is a representation of the algorithm.
So code is just a notation. But one that is executable. In your example, the code is working, it’s just not what you intended. The issue is not the code, the issue is that you don’t know code well enough to “speak” your algorithm.
And that is the main issue with a lot of LLM users. They are translating specs (which they do understand) to code (that they do not understand) and then relying on superficial outputs to see if they got it right. While also telling fluent speakers that they should follow the same workflow. At least with human languages, the other party may detect discrepancy and the fact that you’re not a native speaker. But a computer will execute things blindly.
The necessary work is more than just the deliverable. Even a simple patch implies an indefinite number of other approaches not-taken, and sometimes not-taken for good reasons.
Sometimes we explicitly document those, sometimes we trust that a human expert decided against them. Those other aspects of work still exist, even if they are getting skipped/mismanaged with LLMs.
Thus the push to use LLMs has felt a little bit like being a fluent French speaker being told that all of the best French writers are using google translate to write French translated from English now.