If thereās one quirk Iāve carried with me through years of writing code, itās a stubborn, slightly embarrassing affection for the GOTO statement. I've tried to keep the flame alive, and I think its time to pass the torch to AI!
Source code is transitioning from a document for humans to an intermediate instruction set for machines, writen by machines.
Most projects these days are so complex and heavily structured that no single human can actually know exactly what's happening in every file of a project.
Software has outgrown our capacity to understant it. Not only that, the opace nature of all the frameworks which we are forced to use add to the black box which is actually a modern software application, even if you just consider a simple app on your phone.
If we accept that AI will eventually write and maintain the code, the "prohibition" against GOTO (and structured programming in general) loses its primary justification: Human Cognitive Load. As I've mentioned before, you can even argue that computer languages are also on the way out.
Why the concept of GOTO might make a comebackāor simply cease to matterāin an AI-coded world:
Lets go back to 1968, where Edsger W. Dijkstra wrote "Go To Statement Considered Harmful.".
His core argument was that the gap between the static program (the code on the page) and the dynamic process (what happens when it runs) becomes too wide for a human brain to bridge when execution jumps around arbitrarily.
AI does not suffer from limited short-term memory. It does not "read" code top-to-bottom like a human. It does not get "confused" by jumping from line 10 to line 500 because it holds the entire state space in its context window.
Is Code is becoming "The New Assembly"?
For decades, we moved away from Assembly to C, then to Python/Java, and other languages littered with syntactic sugar to make code more readable for humans, often at the cost of raw performance or verbosity.
Just as humans rarely inspect the Assembly code generated by a C compiler, humans will rarely inspect the Python/C code generated by an AI. If the AI writes it and the AI fixes it, the aesthetic "cleanliness" of the code is irrelevant. The source code becomes a binary artifact, not a literature to be read.
An AI optimizing for pure speed and cycle-count would likely revert to GOTO because it maps closer to the CPUās native JMP (Jump) instructions. If readability isn't a constraint, the AI can strip away the "structured programming tax" we pay for human legibility.
Structured programming often leads to deep nesting (e.g., a loop inside an if, inside another loop, inside a try/catch). This is also hard to read.
A GOTO pattern (often used in the Linux Kernel for error handling) allows for a "flattened" structure. You execute logic, and on error, you GOTO cleanup.
AI doesn't care about indentation depth, but it might "prefer" the generated flat structure because it reduces token count or token complexity. A linear list of instructions with jumps is often shorter (in token terms) than a deeply nested structure with closing brackets and indentation.
When a human modifies a legacy codebase, they usually only understand the specific function they are touching. GOTO is dangerous because jumping out of that function into unknown territory causes side effects the human can't predict.
An AI agent (theoretically) understands the entire repository at once. It knows that GOTO 100 affects a variable used in a module three files away. Because it has "perfect" dependency tracking, the risks of side effectsāwhich define why GOTO is badāare mitigated by the AI's ability to simulate the global state before writing the line.
While the argument above is logically sound for a machine-only loop, it fails in a human-in-the-loop scenario (which is where we are now), because the programmer is still in control of the project, reviewing AI generated code and until this element is removed, AI is forced to code in computer languages designed in a diferent era.
Also, current models such as GPT-4, Claude and others, still work like statistical mirrors, meaning there's a lot of code in the training (if not all) that has been written by humans and therefore, the GOTO usage is low. However, as these models move into more rehinforced learning, the reward will shift and the strategy to achive results will not always align with the way things were done before.
I am arguing the scenario where a few years have passed and we start letting these modern RL models start, convert, write and test the whole program, where the human simply serves as a light specification writer, Q&A, and end-user.
The "No GOTO" rule was a social contract to keep software maintainable. The moment humans stop reading the code, the social contract expires, and the machines are free to JMP (or should I speak ARM and B) wherever they want.
