Unvibe the Vibe: Learning by Deconstruction in the Age of AI

In an earlier essay, I stated that the integration of AI into my teaching activities has significantly improved my productivity. At that time, some of the issues I encountered with this increased productivity were limited to overzealous and premature optimization and small hallucinations, all of which could be resolved fairly quickly. However, as I integrate AI into more complex research workflows, two deeper problems emerged.

First, as tasks become more complex, AI agents are conditioned to overcompensate. The generated code becomes cautious to a fault and is filled with redundant checks and defensive structures. The more code is generated, the more surface area there is for subtle errors and hallucinations. Second, and more concerning, I also find myself in the same place that I warned students about, the Zone of Cognitive Overreach. I was using code that I could not fully explain. As the generated solutions began to touch areas outside my expertise, I could follow the structure, but not the reasoning.

I begin addressing the first problem by slowing down and working through the generated code deliberately. This helps me identify redundancies, remove unnecessary layers, and catch hallucinated logic. However, something else happened in the process. As I deconstructed these systems, I began to understand the underlying mechanics more clearly, even in areas where I lacked formal training. In other words, I am also resolving the second problem slowly. At some point, it became clear that this was not just debugging. I was learning by deconstruction, an approach that is made possible and increasingly necessary in the age of AI.

The Illusion of Competence through Productivity

Through my AI integration process, I realize that what initially felt like increased productivity was, in part, masking a deeper issue. Being able to generate working code is not the same as being able to understand why the code works in the first place. AI-assisted workflows produce code quickly and in volume. Modern state-of-the-art models will produce code that runs and passes quality assurance tests. It is very easy for us to mistake output for competence. This raises a deeper concern for education: if students can produce working systems without fully understanding them, what exactly are we teaching them to learn?

This concern is not new, and faculty responses have been mixed. Some have returned to more traditional approaches, emphasizing hand-written code or restricting AI use in an effort to preserve foundational skills while others (myself included) treat AI use as a baseline and raise the bar on the numbers and complexity of assignments. Both responses are insufficient. AI is becoming part of the environment in which our students will work, and avoiding it risks leaving them unprepared. At the same time, uncritical and indiscriminate use of AI leads directly to the illusion of competence. Perhaps the challenge is not to choose between allowing or banning AI but to find the right balance. Students must still learn by constructing systems to build foundational understanding, but they must also learn by deconstructing AI-generated code to develop judgment. This is no longer simply a question of pedagogy, but a consequence of a fundamental shift in the learning environment itself.

From Scarcity to Overproduction

Programming education has historically operated under scarcity. Before the age of AI (prior to 2020), students had limited examples and were often forced to construct solutions themselves. Even with Google and Stack Overflow, usable code was often partial and context-dependent. The learning process was slow, frustrating, and sometimes inefficient, but it served an important purpose. Beyond building theoretical and practical knowledge, it also trained judgment. Students learned the why and how of design decisions because they had to make those themselves. In other words, scarcity forced students to acquire knowledge through building, and in doing so, they encountered friction. That friction, representing failure, backtracking, and confusion, was not incidental, but formative. Now, overabundance reduces that friction. Students can arrive at working solutions without going through the process of failure and recovery that once shaped their understanding.

Today, we face the opposite condition. AI systems can generate an abundance of plausible solutions on demand. This shift toward overproduction has given rise to what is called vibe coding, which means generating and accepting code based on surface plausibility rather than deliberate reasoning. In practice, this leads to a high-output, low-inspection workflow. Large volumes of code are generated quickly with the expectation that something will work. With the latest advances in state-of-the-art models, something almost always does. In education, this removes much of the traditional friction, the mechanism through which judgment developed. Even with the best intentions, students can accelerate the construction process through minimal AI usage such as code suggestion, completion, and preemptive error checking. As a result, they are no longer limited by their ability to construct solutions, but by their ability to make sense of them.

At first glance, this might resemble a greater emphasis on code reading. If examples are plentiful, then perhaps learning can happen by studying and understanding them. Code reading has always been an important skill, and AI can now generate examples at a scale that was previously impossible. However, reading code is not the same as deconstructing it. Reading focuses on following the logic of a program and understanding what it does. Deconstruction goes further, asking why the code is structured in a particular way, whether that structure is necessary, and how it might be simplified or improved. It requires judgment, not just comprehension. This distinction matters because AI makes it easy to confuse the two. When code runs and explanations are readily available, it is easy to feel that we understand the system when we have only followed it. Without deliberate critique and refinement, code reading risks reinforcing the illusion of competence rather than correcting it.

This overproduction leads to a growing gap between what students can generate and what they can meaningfully assess. As this gap widens, development judgment is at risk of weakening for CS students. In the age of AI, the modern pedagogical bottleneck is no longer the ability to produce code. It is the ability to evaluate, refine, and ultimately take ownership of it.

Unvibing the Vibe

If vibe coding is the acceptance of code based on how it feels, then unvibing is the deliberate restoration of judgment. Unvibing, or deconstructing, involves aspects such as inspecting generated code before accepting it, questioning design choices even when the system works, and removing redundancy rather than adding features. In educational terms, this suggests a shift from generating code to evaluating and critiquing code.

Unvibing is not simply reading and identifying errors in large amounts of code, but achieving a deeper and more systematic understanding of how components work together. To unvibe, we first have to vibe (generate) the code with AI. After the first test run and cursory read, it is time to deconstruct (unvibe) the code. Some of the most important questions are not about the code itself. Was the prompt properly expressed? Did we accidently expand or reduce the scope of the results due to our phrasing? One example would be deciding whether to bake code directly into a Dockerfile image (at production stage) or do host mounting via Docker Compose for easy development. Manual UML visualization of vibe code is another part of unvibing. For example, through UML diagrams, we could learn that the generated error checking of variables inside internal function is correct but redundant if those variables come from parameters that were properly sanitized elsewhere. Instead of relying on errors to reveal knowledge gaps, students are asked to interrogate working systems and explain why a solution works, identify what is unnecessary, and to decide what should be kept. The challenge is no longer fixing what is broken, but recognizing what should not have been built that way in the first place. In this sense, unvibing restores the kind of cognitive effort that was once provided by scarcity, but does so deliberately rather than accidentally.

It is important to note the construction remains a critical part of the learning process. Students cannot meaningfully critique what they have never built. Without a foundation, refinement becomes superficial. The implication here is that we are not choosing between construction or deconstruction but to rebalance them within the curriculum. This raises a practical question: should this rebalancing be horizontal, with construction emphasized early and deconstruction later, or vertical, with both present at every stage? Interestingly, the same AI that causes the potential weakening of development judgment might also provide the means to help strengthening it.

Conclusion: From Production to Judgment

Before AI, computing students developed understanding primarily by learning how to build working systems. The arrival of AI has made the construction process significantly easier, but in doing so, it has exposed another skill that was previously developed implicitly: judgment.When construction is no longer the bottleneck, judgment becomes the constraint. The challenge, then, is not to resist AI or to return to earlier forms of learning, but to adapt. We must recognize that the center of expertise has shifted, from producing code to evaluating and refining it. In that sense, the goal is not to eliminate the vibe, but to help students learn when and how to unvibe.