"Do You Still Read the Code?"

There is a notable difference between the question "Do you read the code?" and "Do you still read the code?". The latter implies a theory that reading code is becoming obsolete, similar to memorizing phone numbers or using paper maps. I extensively utilize AI in my software development, and I deliberately read what it generates.

This approach is a conscious decision in how I want to build software during my work, where responsibility for the committed and deployed code is expected. Other individuals make different choices, often with meticulous consideration. However, we have started sharing codebases without fully agreeing on the implications of either path.

It is challenging to predict which approach will ultimately prevail, as the question assumes the matter has been settled. While creating a functional application has become easier in recent times, understanding its long-term maintenance costs due to changes in requirements, developers, and tools takes significantly longer. We are making commitments regarding team work methods, and their consequences will only become apparent later.

There seem to be two dominant approaches to using AI in programming today. Accelerators employ AI to assist in translating their understanding into code. They aim to retain enough comprehension of the implementation to explain the reasoning behind the translation from intent to code, predict the consequences of changes, and maintain the resulting model and its implementation.

Reading the generated code is part of this commitment. For accelerators, language models and tools function similarly to text editors and their plugins: they facilitate coding at a faster pace. They invest in their continued ability to explain and modify the implementation. Large changes are slow to review, a generated diff that incorrectly implements a model is rewritten, and cognitive debt accumulates whenever the team's comprehension falls behind the generation process.

Vibecoders, on the other hand, aim to delegate implementation and its ongoing revision to AI. Their focus shifts towards specifying the desired behavior, providing context and domain knowledge, and establishing methods to determine if the outcome is satisfactory. Understanding every implementation detail is no longer their intended outcome.

Vibecoders rely on language models to abstract away implementation, placing them in the same category as compilers and frameworks: there should be no need to comprehend technical details. They invest in their capacity to specify, regenerate, and evaluate code. The distinction lies in the developer's relationship with the output, rather than the amount of code the model writes.

An accelerator may generate most of a feature's lines while still grasping what is built, taking ownership of the underlying reasoning. A vibecoder might invest considerable time in refining a specification and its acceptance criteria while treating the resulting implementation as disposable. Being an accelerator does not necessitate knowing the answer before querying the model—you can use generated code to explore an unfamiliar problem, as long as understanding is something you intend to acquire before the code is committed to the master branch.

There is also a third group that rejects AI for programming altogether. The objections I have encountered mostly revolve around legal (typically copyright-related) or ethical concerns, though they merit a serious discussion and are outside the scope of this analysis. Notably, I have not encountered an organization building commercial software that avoids AI for engineering reasons, believing that generated code makes their software worse and ultimately costs more than it saves.

If you work in such an organization, I would be keen to learn about it. My preference stems from my view of programming as essentially applied pure philosophy. Programming is akin to using programming as a tool to express, explain, and adapt a model—a kind of knowledge that enables a person to not only perform an action but also to understand it, answer related questions, project future scenarios, and adapt accordingly.

The programmer who possesses this theory can explain the program's relationship to the world it helps manage, demonstrate how the solution fits within real-world affairs, and adapt it when circumstances change.