Bikes without Cyclists

AI has got me concerned that we've stopped learning how to ride bicycles. Not a literal bicycle but a symbolic bicycle. Bicycles let us move faster than any animal while relying on nothing other than our own motor input. Any tool that amplifies our abilities is a bicycle. A computer is a "bicycle for the mind", so is language and books.

All "bicycles" require skill to use and ultimately demands we become attuned to its mechanics. There is really no other way to learn how to ride than "pedal, steer forward and balance". We only need to get sufficiently calibrated and coordinated. Formal education is very valuable but every artist, pianist, writer, coder, designer, trader, entrepreneur will say their abilities are fundamentally automatic and feelings-based.

Automation, if adopted without thought, makes it significantly more challenging to develop a feel for things, and that can have problematic outcomes. I explore two case studies on what happens when we forgo deep contact with our work, and how I've slowly adopted a pretty transferable mindset for overcoming this.

Part I: AirFrance 447 & Why Automation Makes Us Less Capable

In 1983, Lisanne Bainbridge outlined a fundamental irony in automation. She noted that as control over systems becomes less hands-on and more automated - just as flying a plane has depended more on autopilot - the human operators become less capable of taking over when there is a malfunction, and the malfunctions appear on average in more difficult scenarios.

An often cited and tragic manifestation of this was the fatal crash of Air France 447 over the Atlantic in 2009. The airspeed sensors mounted on the outside fuselage started to ice over at 29,000 feet. This isn't threatening or dangerous on its own. It turns off autopilot (as the readings can't be trusted) and returns control to the pilots.

So despite no actual imminent danger, it is hard to make sense of the following fatal decisions of pilot Bonin that led to the crash. He raised the pitch of the airplane, and due to the low air density at high altitudes, the plane lost substantial speed and started to stall. The lift keeping the plane in the air disappeared and the plane dropped. Instead of aiming down to reclaim speed, Bonin continued to lift the nose of the plane up, worsening the situation.

He was attempting a maneuver akin to take-off or aborting a landing, but it was woefully inappropriate at their altitude. Once the other pilots figured out their colleague's mistake, it was too late to correct.

You may be thinking this can be written off as a case of human-error. Maybe you are thinking further automation might save us from this in the future: "People always make mistakes and if we can eliminate that, that would be ideal!". But the automation that substitutes the majority of control does not work perfectly 100% of the time, as the freezing of sensors on AF447 illustrates. A human operator must still supervise and monitor a dashboard of lights and gauges, and take over when alerts start firing.

For now, humans must work alongside automated machines.

Bonin was the least experienced pilot with 2900 hours of flight time. That still sounds like quite a lot but we need to factor in the number of hours actually controlling a plane. Autopilot handles close to 99% of the flight time, largely everything except take-off and landing. The irony is that autopilot denied Bonin the manual flight hours needed to develop the instincts to cope with that malfunction.

Automation is making it more difficult to acquire and retain the core competencies and know-how that manual tasks required. Practitioners (if that is still an appropriate term for system operators) are no longer engaging with "easy tasks" on a day-to-day basis. They are losing the low-stakes, built-in training that is necessary to be prepared in higher-stakes scenarios.

What I think we get muddled is that automating a task does not make the relevant skills valueless. Autopilot does not mean the pilots don't need to know how to fly a plane. AI-assisted cancer diagnosis does not mean doctors don't need to know how to detect tumours from scans. The deep intuition and knowledge that those skills prime in the brain are needed in decision making. Without them, decision making becomes an under informed guessing game.

Part 2: Manager Mode & Delegation

We've already identified that the bane of our problem is that we've become alienated and distanced from the work, as "we just don't do it anymore". Automation means "a machine does it". But the issue existed before when "another person does it". Automation is just another form of delegation.

Delegation of work, either internally down a tall org chart or externally to consultants or plants in foreign countries, has often been cited as a potential trigger for company decline.

One such company in crisis was Airbnb during Covid. At an off-the-record talk given at a Y Combinator event in 2024, the founder and CEO Brian Chesky looked back at the company's recent decline and radical reformation. His talk triggered a cascade of Silicon Valley essays on the solution that rescued and catapulted the company to even greater growth than before the pandemic. The solution was called "Founder Mode".

In short, a startup begins with the ebullient founder having a tight leash on all work and workers. The company grows and so does the sum of the problems. At some point, the details overwhelm and the founder must start to delegate.

The default MO companies transition to, referred to as Manager Mode, was to also switch to a highly detail-scarce operating model that treats "subtrees of the org chart as black boxes". The CEO, as the proponents would claim, should no longer concern themselves with the microscopic workings of the company. No need to know the recipe of Coca Cola as long as you're confident a subordinate does (at least in part). Your job is just to ensure the output of every person and plant is accounted for.

But Chesky argues for a natural alternative called Founder Mode where the CEO decides to deeply concern themselves with the details and get in close contact to how the drink is made. Instead of being blind to the black boxes of each department, founders like Jobs would employ "Skip-level" meetings. They would go straight down to the tips of the company limbs and acquaint themselves intimately with the specifics of the employees work.

Hence the founder returns to a similar kind of close-contact they had when the company was first started.

Delegation is necessary (how else can you run a 1000+ company) but the extent to which we continue to be calibrated with the fine-workings of the system is a decision we are free to make.

Part 3: Student Mode

The core lesson of Founder Mode extends beyond big cooperations and I believe should be relatable to you too. Remember, it is fundamentally a response to the drawbacks of delegation. And in the coming years of AI, we all might be moving to a higher level of management and personal outsourcing.

I am already. My title as a software engineer now resembles a "manager of junior coders". With tools like Conductor, Claude Code, Cursor and Codex, a great deal of my time is spent in an inbox, spinning up self-contained environments for the AI agents to execute my plans.

Obviously all my decision making is not being outsourced, but AI does help me skip the hours of largely predictable typing that comes after a solution is designed.

It is with this saved time that I have learned I must be most deliberate. At first, it may seem seductive to spend this on even more work, managing more agents and getting more done. Why not just schedule 5-10 tasks in parallel? If you've tried this, you will know that our mental bandwidth is too skinny to effectively keep tabs on so much at once. You'll end up exhausting yourself switching context, slow down and maybe become no more productive than when you were doing each task in sequence.

Instead, I strongly advocate for the more disciplined "student" approach when consuming your idle time. I split this up into two types of blocks: "Library Time" and "Lab Time".

Library Time

Automation will get you close but never to 100%. In building Janus, I've had to face many problems that exceeded my skill set. Sometimes it was within reach of AI (such as designing elegant user interfaces), and in other cases was AI-unsolvable.

I had often deferred facing these problems, preferring to fast-forwarding to the next ticket of work, but like anything you run away from, the problems caught up. One such bug, which I will briefly explain, was never properly solved by AI and until I assumed the mindset of going into the library and immersing myself in books, I could not solve it.

What Was the Problem

Janus would occasionally experience a lack of available database connections. Because their data could not be fetched from the database, users were effectively locked out of the product. Worse, I couldn't even connect to the database to free up connections. This issue was temporary though and would usually resolve itself after maybe 20 minutes. Because of (fortunately) increased use of the product in February 2026, the issue had been grown in intensity to the point where it must be solved.

Whenever I or the AI would inspect the code, everything had always seemed to be reasonably set up. There are 50 available connections to the provider (Supabase) and my application should have had a hard limit preventing it from going above 15 connections. Therefore, it was always a puzzle to me and my coding agent why this problem existed in the first place.

What I did to Solve it.

In all honestly, I had very basic grasp of what the database configuration was doing under the hood. There were still many terms I lacked a detailed and compelling understanding of. To give you a flavor of their ostensibly esoteric and specific nature, I had to read into:

• PGBouncer and server-side connection pooling
• Client-side pooling
• Postgres's connection state

My protocol for learning this, which I will go into detail in another post, involves following a set of high priority questions until I become satisfied with my new understanding. In a few hours of inquiry, I had uncovered the misconception in my understanding, been able to trace the flow and mechanics of the problem, wrote a targeted solution (remarkably only a single line config change), added additional observation to track the issue going forward, and deployed.

I am aiming to prioritize more of these deep excursions, not only because it leverages and develops my competitive advantage, but because the work is intensely interesting! In delegating the mundane changes to AI, I can spend more time working on the more critical and demanding problems. It's important to note that I still made the proactive decision to go into that "library" and think deeply.

It's satisfying but still difficult work, and the attraction of ease and passivity might sway you to forfeit this challenge. Unless you have another valid use of that time, you will also be forfeiting the opportunity to further your own abilities and reap the splendid satisfaction of achieving the once unachievable.

Lab Time

There is another activity I continue to spend my time as a developer doing and that is meticulously reviewing work.

After the AI finishes its attempt at executing my vision, I take additional time to critique each line. Any detritus introduced by lazy editing (such as cramming all the work in a single file instead of organizing the code cleanly across many) is noted and either corrected by hand or through a follow up prompt.

This slightly longer pass through the work not only allows me to hop back in the driving seat and experience the motion of coding, but also ensures the entire work meets a higher, more aspirational standard.

This is closest to the original advice Bainbridge gave for addressing the atrophy of operator skills. Her work drew from control theory where the operator's proficiency is measured by how smoothly and accurately they can set the knobs on the machinery. Her main solution to regain an rich internal model is to reintroduce manual operation back into the process. By forcing a step in the process to be manual, I'm trying to keep my code critic taste buds sharp.

Choose Adventure

Let's conclude.

We've identified the irony of our predicament: as we automate tasks, we also distance ourselves from the practice that creates and preserves valuable skills.

We've also identified the typical shape of how this manifests: With managers who can hardly do the work they manage. This might be:

• The management consultant as CEO who doesn't know how the goods are made
• The restaurant owner who's never stepped foot in a kitchen
• The pilot who doesn't actually 'fly' at high altitudes
• (Increasingly) The software engineers who have never typed a line of code.

If you keep delegating, at what point do you not need to actually do anything at all? And if we all do this and direct our orders at the machine, will we collectively cease to be good at anything? Will our wilting competencies reduce us to a comfortable but purposeless people like the Eloi in H.G. Wells' Time Machine?

AI won't turn us into frail folk. With all this productive time we are recouping with automation, the choice to go outside and learn to ride the bike, or stay indoors and do nothing, is still our own. So go out and wobble on the bicycle. And once you stop falling off, then you will know how to ride a bike.