Drive manually
On the 30th of August, 2000, a train flew out of the tunnel at a station in Paris, and, without stopping, rolled on through into the tunnel. It was clear that the train was speeding, and speeding severely. It entered the tunnel without stopping, and then derailed. Luckily, there were no fatalities.
The investigation was able to establish that the train’s speed was above the maximum permitted on that section of track by 20 km/h, if not more. How could this happen, given that the Paris Metro has been equipped with automatic speed control since the early 70s?
It turned out that while the automatic control system was in place, it hasn’t been operational for 8 months. And it turned out that the driver of the accident train was not able to drive the train manually well enough, has lost concentration and - consequently - caused the train to accelerate way above the permitted speed.
Since the accident, the RATP has instated a rule for the Paris Metro drivers that, even with a present and functioning ATC (automatic train control), at least one trip up- and down the line per day should be performed under manual operation, with the driver controlling braking and traction.
The concept is not unfamiliar for airlines, either. For example, one airline requires its pilots to fly manual (without the use of autopilot) starting at a relatively high altitude - watch the clip from Pascal here - which is especially relevant on their long-haul fleet, where flights are long and consist mostly of supervising automation, so not losing the motor and cognitive skills is vital!
Another well-known example comes from the world of nuclear power plants. In many facilities, operators are required to periodically run through manual control drills, where they must operate critical systems without the aid of automated safety and regulation mechanisms. The drills are often mandated by regulatory authorities and are a core part of ongoing operator certification.
How is this relevant for us?
In our brave new world of LLM prowess, multiple people notice that with abundant LLM output that the “magic box” is all too eager to spew out, the skills we don’t exercise frequently - like, ahem, writing the damn code - tend to wither. Do enough LLM-assisted coding and they may even start to atrophy completely. There is no question whether we are becoming dependent on the LLMs - there is a question of the cost of that dependence and the extent, given how the immense amount of compute it consumes is essentially subsidized.
It is no surprise, then, that if the LLM is not available (bad connection, running out of costs, model provider is experiencing issues) finding ourselves writing code can pose a challenge! And it’s not a “millennial gets annoyed at discomfort” thing at all – it is the case of humans failing to operate in an environment with tool substitutions! It is a fairly classic problem.
So since I’ve started doing a lot of LLM-assisted coding, my mantra has become that I will do at least 30 minutes of actual manual coding. I specifically forbid the LLM from making code changes for me, but ask it to “reason” with me instead. To do so, I use this finishing sentence in the prompts:
Do not write any code, explain the approach to me first.
Afterwards I will go and either very carefully (and selectively) copy and paste the LLM’s proposition into the editor, or even type it out by hand.
Make it a habit to drive manually, regularly – and if needed force yourself to do so. It may save your bacon down the line.