Skip to content

English edition

Vibe Coding and Deskilling Risk in AI Development

Fast prototyping can hide deep capability erosion. Teams need review architecture to avoid trading short-term speed for long-term fragility.

VZ editorial frame

Read this piece through one operating lens: AI does not automate first, it amplifies first. If the underlying decision architecture is clear, AI scales clarity. If it is noisy, AI scales noise and cost.

VZ Lens

In VZ framing, the point is not novelty but decision quality under uncertainty. Fast prototyping can hide deep capability erosion. Teams need review architecture to avoid trading short-term speed for long-term fragility. The real leverage is in explicit sequencing, ownership, and measurable iteration.

TL;DR

Deskilling—the devaluation of skills due to automation—is not a new phenomenon. Bright documented it in 1958, Braverman placed it within a political framework in 1974, and Carr adapted it to the digital age in 2014. Vibe Coding applies this to programming in 2026: 41% of global code is AI-generated, and the developer’s role is slowly shrinking to pressing a button. This process is not a technological accident, but a century-old, deliberate logic of work organization that now targets the work of the developer’s mind.


A Metalworker and a Software Developer: A Story Told Twice

The banks of the Danube in Csepel, Sunday morning. Seventy years ago, metalworkers labored here—by hand, with tools, and with skill. They felt the edge of the metal, the weight of the tool, and the behavior of the material in their palms. Today, people here are scrolling on their phones. Manual expertise has been replaced by apparent convenience and passive consumption. This image is not just a memory of the past; it is a foreshadowing of the future of software development.

Nicholas Carr cites James Bright’s 1958 work, Automation and Management, in The Glass Cage: “It seems that the more automated the machine, the less work the operator has to do.”

Bright did not merely state this; he created a scale that maps the degrees of knowledge loss. Let’s take a closer look:

  1. Manual Work: The lowest level of automation. Here, the worker uses simple tools—chisels, files, scissors. The required skills are high: detailed technical knowledge (e.g., the properties of metal), physical dexterity, and the ability to manage and understand the entire process. The worker is simultaneously a designer, an executor, and a quality assurance specialist.
  2. Powered Machine: Motorized hand tools are introduced. The task becomes more complex, and the cost of errors increases. Workers must now pay attention to operating machines, more complex adjustments, and safety protocols. Physical demands may decrease, but expectations regarding technical understanding often rise—temporarily.
  3. Automated Machine: The pinnacle, where Bright’s findings were startling. The machine performs the task completely autonomously. And this is where the radical shift occurs: the operator’s role is not to perform the operations, but to monitor the machine. The required skills are drastically reduced: basic operational knowledge, interpreting alerts, and pressing an emergency button if something goes wrong. Expertise moves into the machine, and the human becomes a passive monitor.

Vibe coding is nothing more than software development reaching the top of the Bright scale. The developer no longer writes code—they type in what they want (or just think), and the AI generates it. The developer’s task: to run through it to see if the code is “okay.” Exactly what Bright described—sixty-eight years ago. The metalworker’s file and the developer’s knowledge of syntax share the same fate: they are taken out of their hands and embedded in a black box.

Why did Braverman say that deskilling is intentional? The economics of power

Harry Braverman wrote Labor and Monopoly Capital in 1974—its subtitle: The Degradation of Labor in the Twentieth Century. Braverman’s central thesis is not technological, but political-economic: automation does not lower skill levels by accident or as a side effect. It does so intentionally—because this is built into the logic of capitalist production.

His argument is brilliantly simple: a worker with lower skill levels:

  1. Is cheaper. Requires less training, so less needs to be paid for them.
  2. Is easier to replace. If a worker quits, another, barely trained person can quickly be brought in to take their place.
  3. Has less power. Those who understand the entire process have bargaining power. Those who merely press a button can be replaced at any time. Knowledge is power. Lack of knowledge is dependence.

Carr summarizes Braverman as follows: the debate “culminated in 1974, when Braverman reviewed recent trends in employment and workplace technology in his passionate book.”

In the context of vibe coding, Braverman’s question is pressing: whose interest is it that the developer not understand the logic behind the code? The answer is clear: the platforms’. If the developer is completely dependent on AI tools (GitHub Copilot, AWS CodeWhisperer, etc.), then these platforms become indispensable. Subscriptions, data sharing, and the ecosystem become a closed loop. If, on the other hand, the developer has a deep understanding of algorithms and architectures, the platform is just one useful tool among many. Braverman would point out that vibe coding does not maximize developer efficiency, but rather the platform’s power and the developer’s replaceability.

Zuboff provides the historical context in In the Age of the Smart Machine: “The economic returns of such an approach were so great that, with the spread of mass production, this design pattern outlived its original historical context.” In other words: once the pattern of deskilling is set in motion, it becomes self-perpetuating. It migrates from the metal industry to office work, and then into the realm of digital creativity. The pattern is stronger than any single industry.

What does it mean that 41% of global code is AI-generated? The Bright Paradox in the 21st Century

41% of global code is AI-generated. This isn’t just a statistic; it’s a quantification of a paradigm shift. But while surveys, such as the METR study, show that developers have become 19% slower at complex tasks due to AI, platform metrics paint a contrasting narrative: more commits, more pull requests, more “output.”

This is where the Bright paradox comes in: quantitative metrics are improving brilliantly, while qualitative fundamentals and long-term capability are deteriorating. Bright’s original metalworker also “produced” more parts on an automated assembly line—but he couldn’t have designed or repaired that line. The vibe coder also “codes” more functions—but doesn’t necessarily understand their interactions, security vulnerabilities, or alternative, more efficient solutions. As the quote from the corpus points out: “Modern IDEs are becoming increasingly ‘helpful,’ so much so that sometimes I feel like an IDE operator rather than a programmer” ([CORPUS] — Unknown). The tool is taking control of the profession.

Deskilling is never a dramatic, overnight event. It’s like a frog living in water that’s gradually heating up—it doesn’t jump out. It happens slowly, comfortably, in the form of small concessions. First autocomplete, then function generation, and finally putting the whole module together. Every step saves time. And as Bright described: the machine takes over more and more, the user does less and less, and suddenly realizes that they couldn’t relearn what they’ve already forgotten.

How does the loss of constructive friction work? The anatomy of learning

The primary mechanism of skill loss is the elimination of constructive friction. Learning to program is not a linear process of information absorption. It is a chaotic, often frustrating process consisting of mistakes, debugging, rethinking the code, and peer code reviews, which builds deep understanding.

  • Debugging is not just about fixing bugs. It is the process where the developer’s mental model collides with reality. In this collision, the model is refined. If AI immediately provides the “correct” code, this collision—this fine-tuning—is lost.
  • Code review is not just a check. It is a dialogue about alternative solutions, compromises, and readability. If the code is generated by an AI that has no opinion, the learning embedded in the review process disappears as well.

As the corpus quote states: “But as applications take over the work of coding, programmers lose the opportunity to practice their craft and hone their skills” ([CORPUS] — Unknown). Vibe coding short-circuits this practice cycle. A junior developer who relies on Copilot’s 46% code generation rate is essentially like a trainee pilot who never gets to take the controls with the autopilot turned off. They learn to operate the system, but not the fundamentals of flying.

Whose interest is this, and why? The power play of the platform economy

Expanding on Braverman’s question: deskilling is not the work of neutral forces. There are clear stakeholders.

  1. Platform companies: As explained earlier, dependency drives users toward subscriptions, data, and closed ecosystems. The democratization of producing “working” code is tempting, but the underlying knowledge becomes centralized in the hands of the platforms.
  2. Management driven by short-term results: For quarterly results and “velocity” metrics, vibe coding is a magic bullet. More apparent output, faster feature delivery. Long-term technical debt, the dumbing down of the team, and the subsequent decline in innovation capacity won’t show up in the next quarterly report.
  3. Non-technical decision-makers: In a world where code is created “magically,” it’s easier to treat developers as interchangeable resources. The allure of specialist expertise disappears, and with it, the bargaining power that stems from it.

Resistance would come if developers consciously treated AI as a partner or a colleague subject to criticism, not as an autopilot. If they always reviewed the generated code, tested it, understood it, and possibly improved it. However, this requires more time and cognitive effort, which is precisely the opposite of the logic of the “vibe”—the ease.

Key Takeaways: The Map of Knowledge Extraction

  • Bright (1958): At the peak of automation, the operator’s role is reduced to that of a passive observer of the machine. The scale illustrates the process of the removal of expertise, ranging from manual labor to automated machinery. Bright was surprised: “I was shocked to find that the training effect did not occur to the extent often assumed. On the contrary, there was more evidence that automation reduced the skill requirements of the operating workforce” ([CORPUS] — Unknown).
  • Braverman (1974): Deskilling is not a side effect of technology, but the deliberate logic of capital’s labor supply. Lower skill levels = cheaper, more replaceable, and less empowered workers.
  • Vibe coding is the deskilling of programming: the digital embodiment of the Bright scale. 41% AI-generated code, a 19% slowdown on complex tasks, but an apparent increase in “output” on superficial metrics. The drastic drop in junior hires (60%) may signal a decline in demand for beginners with deep fundamentals.
  • The central question, following Bravermant: whose interest is it that you don’t understand your code? The answer lies in the interests of platforms and short-term efficiency metrics. The developer’s personal interest lies in understanding and professional autonomy.

Frequently Asked Questions

What is vibe coding?

Vibe coding is the practice where a programmer accepts AI-generated code without verification and uses it based on a “feels about right” (vibe). They don’t understand the code, they don’t read through it, but it works. The term gained traction in the developer community in 2025 and spread rapidly because it accurately describes this new development practice. This practice eliminates constructive friction (debugging, deep reviews), which is the foundation of real professional growth.

What does deskilling mean, and how does AI affect it?

Deskilling (the loss of knowledge and skills) means that automation has taken away the opportunity for practice, which is the foundation of expertise. Bright described this as early as 1958: the more automated a machine is, the fewer tasks the operator has and the lower their skill level. Braverman demonstrated in 1974 that this is not coincidental but systemic: workers with lower skill levels are cheaper and more replaceable. AI, particularly in code generation, accelerates this process even in the realm of intellectual work, where deskilling previously had difficulty taking hold.

Why is vibe coding dangerous in the long run?

Copilot writes 46% of the code; junior developer hiring has dropped by 60%. This means that the next generation is not only learning less—they are also practicing less. The elimination of constructive friction (debugging, code review, trial-and-error) leads to efficiency in the short term, but a loss of skills in the long term. It could result in the emergence of a class of developers capable of producing functionality but unable to design complex systems, critique them, or think creatively. The question, as Braverman would point out: whose interest is it that you don’t understand your code? The answer lies with systems that chase short-term output maximization.



Varga Zoltán - LinkedIn Neural • Knowledge Systems Architect | Enterprise RAG architect PKM • AI Ecosystems | Neural Awareness • Consciousness & Leadership The skill didn’t vanish. It was designed out.

Strategic Synthesis

  • Convert the main claim into one concrete 30-day execution commitment.
  • Set a lightweight review loop to detect drift early.
  • Review results after one cycle and tighten the next decision sequence.

Next step

If you want your brand to be represented with context quality and citation strength in AI systems, start with a practical baseline and a priority sequence.