When I drive, there isn’t much else I can do. My hands are on the wheel, my eyes are on the road, and my mind is on the next turn. Driving demands presence. It’s slow, but it’s focused. The biggest risk? Distractions.
When I fly, I get somewhere much faster — and I get time back. I can read, write, think. The hours in the air become surprisingly productive. But flying comes with a different kind of risk: what if I got on the wrong plane? I’d arrive at the wrong destination — fast.
Of course, that rarely happens. There are systems in place — boarding passes, gate agents, announcements, seat assignments — both automated and human — to make sure I end up where I intended to go.
The Parallel to Writing Code
Writing code by hand is a lot like driving. There isn’t much else I can do while I’m deep in it. It demands focus, attention to detail, and the willingness to slow down when things get tricky. The risk is distraction — context-switching, notifications, losing my train of thought.
When AI writes the code for me, it’s more like flying. Things get done faster. I arrive at a working solution sooner. And I get time back — time I can use for thinking, reviewing, planning, or mentoring.
But the question that keeps nagging me is the same one from the flying analogy: what if we’re on the wrong plane?
Getting to the Wrong Place — Fast
Speed is only valuable if you’re heading in the right direction. AI can generate code quickly, but if the understanding is wrong, or the design is off, or the intent wasn’t clear, we end up building the wrong thing. Fast.
So the real question becomes: what systems do we put in place to prevent that?
When flying, the systems are layered — automated checks, human verification, redundancy at every step. In software, we need something similar:
-
Clear conversations and shared understanding before we start generating code
-
Code reviews that go beyond syntax and ask, “Is this solving the right problem?”
-
Automated tests that validate not just behavior, but intent
-
Short feedback loops with stakeholders, so we course-correct early
-
Reflection time — stepping back to ask whether the direction still makes sense
These aren’t new ideas. But they become more important as delivery speed increases. The faster we can build, the more critical it is to know what we should be building.
The Cost of Going Too Fast
There’s another side to this I’ve been noticing in myself: the exhaustion of sustained speed.
After a stretch of high-productivity days — where AI is helping me move through tasks quickly, where the code is flowing, and the pull requests are stacking up — I hit a wall. Not a dramatic one. Just a quiet signal that I need to slow down.
To stay sharp, I need to take breaks. Not just the “step away from the screen” kind, but intentional shifts in the type of work I do.
After intense days, I balance with calmer ones. Things like:
-
Updating NuGet packages — routine, low-stakes, but still useful
-
Improving my “parallel work” process — organizing how I juggle multiple streams of work
These aren’t glamorous tasks. But they’re restorative. They let my brain recover while still moving things forward. It’s like the difference between sprinting and walking — both get you somewhere, but you can’t sprint all day.
Flying With Intention
AI gives us speed. That’s real, and it’s valuable. But speed without direction is just motion. And speed without rest is just burnout.
The opportunity isn’t just to go faster. It’s to use the time we get back wisely — to think more carefully, to review more thoroughly, to rest when we need to, and to make sure we’re on the right plane before we take off.
Leave a Reply