Causality, learning and Software
In Einstein's Special Relativity, time sets a frontier to pass information to observers (causality). Time is the way to allow causality, learning is a consequence of causality and time.
The relationship between something that happens or exists and the thing that causes it; or the idea that something can cause another thing to happen or exist.
Learning is the effect on causality in us, humans. Learning needs time and causality.
Physical Causality: The Ray and the Cow
In physics, we can see causality as a direct causal link. The event of the ray (the cause) triggers a physical change in the cow (the effect).
The Cause: A concentrated energy ray strikes a cow.
The Effect: The cow ceases to live.
The Mechanism: The transfer of energy (heat or electricity) disrupts the biological functions of the cow. This is an information interchange with very bad effects to the cow.
In philosophical terms, this is often called Token Causation. It is a specific, “singular” event where if you removed the ray, the cow would still be standing.
Informational Causality: Learning and Human Behavior
This is a more complex, indirect causal chain. Here, the effect isn’t a physical strike, but a change in human decision-making based on information.
The Cause: Humans observe or learn that “Rays during storms kill cows.”
The Effect: Humans seek shelter during storms.
The Mechanism: This is Probabilistic Causality. Learning the information changes the probability of a human’s future actions. The information acts as a “reason,” which then causes a physical movement (running for cover).
If you think about the ways human learns:
Linguistic Learning (Reading & Writing)
Visual and Spatial Learning
Auditory Learning (listening)
Kinesthetic Learning (Tactile)
Talking with others (social learning)
Self-study, reflection
All of them are triggered by a cause that moves you to learn from it, this is the reason why physics says that information cannot travel faster than light speed.
Time and space exists below light speed. Anything going faster than that breaks causality, observers will not react into the cause, because will not see the effects and no learning will happen.
The Tachyonic Antitelephone
In Einstein’s Theory of Special Relativity, the speed of light is the universal speed limit for information. If a particle existed that could travel faster than ligh, a hypothetical particle called a tachyr, it could be used to send a message into the past.
How it breaks causality:
Observer A sends a message to Observer B using a faster-than-light signal.
Because of how time and space are linked (Relativity), if Observer B is moving at a certain speed away from Observer A, the signal will appear to arrive at Observer B before it was even sent from Observer A’s perspective.
Observer B could then send a reply back immediately.
The reply would reach Observer A before Observer A ever sent the original message.
Learning is a consequence of causality because it relies on the brain’s ability to detect and store patterns of cause and effect. If the universe were not causal—if things happened randomly without any preceding reason—learning would be impossible because there would be no "rules" to figure out.
All of this to say that learning is a process that depends on time and velocity.
AI, software and learning
Let’s link all of this with the promise of being able to build software systems within minutes through AI.
Let’s imagine a future with these premises:
There is an AI able to create completed complex software systems through natural language anyone could write within seconds.
This AI is able to rewrite the whole system once and again.
The time in this scenario has been reduced to seconds (almost zero), let’s then talk about the person who wrote the prompt. What that person learned about how the software has been done?. The answer is simple, nothing.
In fact architects has this problem. This is the reason why is so difficult playing the architecture role, becaus of the architect elevator.
In the current world we talk about verification. Verification is a way to learn, we read the code. But bad news we don’t have the ability of verifying thousand of lines of code in minutes, not in days, not in years.
We cannot verify the output of a machine building a whole system reading code, because all the time gained by the machine is lost by the human reading the code.
In this scenario we just moved the constraint.
If learning is impossible in this scenario, do we care?
Is it important to understand how things has been done?
No, if everything is right. But what means that everything is right?.
Have you been in a conversation with stakeholders talking about individual understanding of a copy in a web application?
Some people saying one thing while others understood something different because natural language is vague, not deterministic.
Have you been in incidents in production where the discussion between people was basically if the effect was a feature or a bug?
Bugs or defects are not always very different from features, bugs are just a label we set to a behavior we agree as a group is not what we expected.
Is it possible to create a machine or an AI to detect that a system has bugs?, short answer no. This is much more complicated than the Halting Problem, checking that a system ends or not. And bad news, we cannot build any system that resolves the halting problem in a finite time.
There are problems that are undecidable. If we could build a perfect Bug Detector, we could technically use it to solve the Halting Problem. Since we know the Halting Problem is unsolvable, a perfect, universal Bug Detector is mathematically impossible.
While we can’t build a machine that finds all bugs in any system without fail, we can build AI and tools that find many bugs in most systems.
We bypass the impossible theoretical wall using two methods:
Heuristics and Static Analysis: Tools look for “smells” or patterns known to be buggy. They don’t need to understand the whole logic; they just see a pattern that usually leads to a crash.
Bounded Verification: Instead of checking if a system works for infinity, we check if it works for a specific set of parameters.
But this means we need someone to decide, what is a bug, what is not. Is this a bug or a feature?. Is this smell a problem, or it is not?.
Then what is the risk of not having anyone that learned how the system was done?.
To be unable to surgically resolve the bug or the defect.
Then we could say, I don’t care I don’t need to learn it, because I don’t need to fix it.
AI will fix it because I will prompt it the wrong behavior and I will explain the correct one, and it will recreate the software again right in seconds.
Then we are talking about a way to specify the system once and again to make our AI to create the correct system. Nowadays spec driven development is a try on this.
Let’s go back to time, bugs, learnings, causality. Spec driven development cannot be something static, needs to change, the one that is maintaining this is a human.
The one that learned from those specifications and the feedback of the outside world is the human.
This means that in this new world we need to create a way to maintain a higher level specification of the system, closer to the behavior (the essential complexity) hiding the details (accidental complexity) of how we build software nowadays. We have to read more to Brooks (No Silver Bullet).
This is exactly what it was promised by higher level software languages in the past. In the old times, without AI, we created compilers that basically do that. They recreate the system once and again based on higher level specifications closer to the essential complexity of the software and hiding details (accidental complexity). Or we thought we were doing that.
We are just creating a new higher level software language and there will be humans specialized on it, but please don’t call them developers, it’s not fancy.
Regarding the article, that ray and the cow example, while quite unfortunate for the bovine, brilliantly highlights token causation versus our probabilistic human learning.