When Cars Became Computers: A Metaphor for AI-Assisted Development

In the early 2000s, my parents took us on a road trip to Glacier National Park in Montana. We made the journey in our new (used) family van: a green Dodge Caravan whose reputation was soon to become "a lemon". I was a teenager and didn't pay a lot of attention to the details of what was happening around me, but I do remember how the van kept overheating. It ran fine on the interstate, but anything under 40MPH had the car's temperature gauge rising into unsafe zones.

I remember stopping in some small town in Montana to get it checked out by a mechanic. He checked it out, took it for a test drive, etc., and told my Dad the reason the car was overheating was because the idling fan wasn't turning on. At higher speeds, like on the interstate, that was fine because there was enough airflow to keep the engine cool but at lower speeds the car would overheat.

The mechanic said he didn't know why the fan wasn't turning on. There was nothing wrong mechanically from what he could see. But he couldn't fix it. He told my Dad that this was one of those increasingly common "computerized" cars that you have to hook up to another computer to diagnose the source of the issue. And he didn't have one of those computers.

So we continued on our way. The rest of the trip required my Dad taking "the long way around", like back roads where he could keep up his speed in order to avoid the car overheating. It was all very amusing to us as kids, almost thrilling because Dad had a legitimate excuse to drive fast (suffice it to say, Mom did not like this).

Once the trip was over and we returned home, my Dad was able to get the car in to a dealer where they hooked up the car's computer to another computer to diagnose and fix the issue. I don't really remember the specifics, but the issue was seemingly some failed digital sensor that prevented the idling fan from turning on. Once the sensor was replaced, things worked again.

Computers talking to computers.

Growing up in an era that shifted so many things from analog to digital, mechanical to electronic, I've thought about this trip a lot. And I'm thinking about it again in this new era of building software with LLMs.

I think about that mechanic. This guy who grew up around mechanical cars that could be physically inspected, diagnosed, and repaired. So much of his experience and knowledge unusable in the face of a computerized car. You can tell when a mechanical switch has failed with your eyes, but not a digital one. You need a computer to help you understand the computer.

Will this be my future? If a codebase was made with the assistance of an LLM, will its complexity and bugs only be inspectable, understandable, diagnosable, and fixable with an LLM?

"Hey, can you help me, there's a problem with my codebase?"

"Ok, I can confirm the issue, but I can't fix it without hooking your codebase up to an LLM."

This metaphor captures something profound about the transition we're experiencing in software development. Just as cars evolved from purely mechanical systems to complex computerized machines, our codebases are evolving from human-readable logic to AI-assisted architectures that may become increasingly opaque to traditional debugging approaches.

The mechanic in Montana represents a generation of developers who built their careers on understanding systems through direct inspection and mechanical reasoning. When faced with a computerized car, his decades of experience became less relevant. The problem wasn't visible to the naked eye or accessible through traditional diagnostic methods.

Similarly, as we increasingly rely on LLMs to generate, refactor, and optimize code, we may be creating systems that are fundamentally different from what we've built before. Not necessarily more complex in terms of lines of code, but more complex in terms of the decision-making processes that created them.

When an AI assistant suggests a particular architectural pattern or implements a feature in a specific way, it's making thousands of micro-decisions based on patterns it's learned from millions of examples. These decisions may be optimal, but they may also be opaque. The "why" behind certain implementations might not be immediately apparent to a human reader, even the original developer.

This raises important questions about the future of software maintenance and debugging. Will we need specialized AI tools to understand and modify AI-generated code? Will the ability to "read" code become less important than the ability to "query" it effectively?

The transition from mechanical to computerized cars didn't eliminate the need for mechanics—it transformed what mechanics needed to know. Today's automotive technicians are as much computer specialists as they are mechanical experts. They use sophisticated diagnostic tools, understand electronic control units, and interpret data streams rather than just listening to engine sounds.

Perhaps software development is undergoing a similar transformation. The developers of the future might be less like traditional programmers and more like AI operators—people who know how to effectively communicate with and direct AI systems, how to interpret their outputs, and how to guide them toward desired outcomes.

This doesn't necessarily mean that traditional programming skills will become obsolete. Just as modern mechanics still need to understand basic mechanical principles, future developers will likely still need to understand fundamental concepts like algorithms, data structures, and system design. But the day-to-day work might look very different.

Instead of writing every line of code manually, developers might spend more time reviewing AI-generated code, providing high-level direction, and focusing on system architecture and user experience. Debugging might involve working with AI tools that can analyze code patterns and suggest fixes, rather than manually tracing through logic.

The story of that overheating van also highlights an important transitional period. There was a time when some cars were computerized and others weren't, creating a gap between what different mechanics could handle. We might be in a similar transitional period with software development, where some projects are AI-assisted and others aren't, creating different skill requirements and tooling needs.

As we navigate this transition, it's worth considering how we can preserve the best aspects of traditional software development while embracing the benefits that AI assistance can provide. How do we ensure that code remains understandable and maintainable, even when it's generated with AI help? How do we train the next generation of developers to work effectively in this new paradigm?

The mechanic in Montana couldn't fix that van, but he could have learned to use the diagnostic tools. The question is whether we, as developers, will be willing to adapt our skills and approaches as our tools evolve. The future of software development might not be about replacing human developers with AI, but about creating a new kind of developer who can effectively bridge the gap between human intent and AI execution.

Just as cars today are both mechanical and computerized systems that require different kinds of expertise to maintain, our future codebases might be both human-designed and AI-generated systems that require new approaches to understanding and modification. The key will be ensuring that we don't lose the ability to understand and control our own creations, even as they become more complex and AI-assisted.

The road trip continues, and like my Dad taking the long way around to avoid overheating, we may need to find new paths forward as we navigate the transition to AI-assisted development. But with the right tools and approaches, we can keep moving forward without burning out our engines.