The More Vibe Coding Takes Off, the More I Respect Old-School Software Engineers

A developer shared on Reddit his misadventure of using Claude to vibe-code a reverse reimplementation of classic software. He set out to apply first principles to strip away so-called "code fat," only to be humbled by the extremely tight code that an older generation of engineers had written under severe hardware constraints. The story resonated because it punctures a popular narrative: AI coding makes writing software easier than ever before—but making software good is still another matter entirely.

A reverse reimplementation hits the wall of reality

The developer's starting point was fairly typical: he had an almost obsessive sensitivity to code bloat, so he picked a few of his favorite classic programs, reverse-engineered their structure, and then used Claude to vibe-code his own versions from scratch. The goal was clear—use first principles to restore the essence of the tools, remove redundancy, and build cleaner, lighter replacements.

Things quickly spiraled out of control. He described the process as "taking an absurd amount of time and burning through a massive number of tokens," making it a complete loss from both a financial and psychological standpoint—it would have been simpler to just buy the legitimate software. More importantly, when he actually dug into the internals of those programs, he saw a picture diametrically opposed to his expectations—there was almost no "fat" to trim.

The value of this experience lies in its honesty. Much of vibe coding's appeal comes from the thrill of "quickly seeing something run," but once the goal shifts from "it runs" to "it runs better," the speed advantage is quickly eaten up by the cost of understanding and trial and error.

Vibe coding is a term coined by Andrej Karpathy in early 2025 that quickly went viral. It refers to developers mainly describing intent to an AI in natural language, letting the model generate and iterate on code, and acting more as a reviewer and direction-setter rather than writing every line by hand. Its typical workflow is "describe—generate—run—feedback—regenerate," shifting the focus of programming from syntax details to intent expression and result verification. This model's efficiency advantage is most obvious in the exploratory stage, when starting from zero with vague requirements, but it naturally brings two problems: first, the quality ceiling of generated code depends on how strict the prompting and review are; second, developers can easily keep layering new code on top without fully understanding the generated results, so later debugging and refactoring costs are deferred rather than eliminated.

There isn't a wasted byte in old software

The author's core insight is that the older generation of software was born under extremely brutal hardware constraints. Memory allocation, cache locality, computational overhead, and even the size of the binary itself—every byte had a reason to exist. Engineers back then had no room to waste resources; hardware forced them to write code from first principles.

This explains a counterintuitive phenomenon—the older the software, the less "fat" there is to cut. You go in with ambitions of optimization and streamlining, and you come out with nothing but admiration. In his post, he wrote that he has tremendous respect for the old-school developers who hand-wrote tight, ruthless code.

This deserves another layer of thought. Modern development environments offer abundant memory, powerful CPUs, and layer upon layer of abstraction frameworks, at the cost of blunting developers' awareness of underlying resources. When AI generates code, it inherits exactly this "resource-abundant" default assumption—it excels at stacking up reasonable but not necessarily essential structures, and is not good at making trade-offs on every single byte, because the latter requires a deep understanding of the specific runtime environment rather than pattern matching.

Cache locality refers to arranging memory access so that adjacent or recently used data is physically close and temporally close, thereby hitting the CPU's various cache levels and avoiding expensive main memory access. In older software, this was a core optimization technique carefully arranged by hand: data structure layout, traversal order, and memory pool design all had to be considered around cache line size and hierarchy. Modern high-level languages and frameworks often leave memory layout to the runtime and garbage collector, developers rarely perceive cache behavior directly, and compiler optimizations and hardware prefetching mask most of the cost. But once you enter performance-sensitive paths—hot loops, real-time processing, embedded systems—cache locality is still the key to order-of-magnitude differences, and this kind of optimization depends precisely on deep analysis of specific hardware and data access patterns, which is hard to obtain through pattern-matching-style code generation.

Where are the boundaries of vibe coding?

The author's attitude does not reject vibe coding; he explicitly says the technology is "amazing." What is really being questioned is its applicable boundaries.

• Suitable scenarios: prototype validation, glue code, personal small tools, quickly turning ideas into something runnable. In these scenarios, speed is the greatest value, and the minimum bar for code quality is not high.
• Difficult scenarios: performance-sensitive systems, resource-constrained embedded environments, and core infrastructure that needs long-term maintenance. In these areas, every bit of efficiency comes from a precise grasp of hardware, and this is exactly where vibe coding is weakest.

In his post, he deliberately omitted the specific software names and details, on the grounds that he "didn't want to get caught." Behind this joke is also the gray area of reverse engineering itself—the line between learning purposes and infringement is not always clear.

Glue code refers to the part of the code that connects two existing systems, libraries, or services. It does not carry core business logic itself; it is only responsible for bridging work such as format conversion, call orchestration, and error propagation. It usually has a short lifecycle, straightforward logic, and is not performance-sensitive, yet it accounts for a considerable proportion of actual development work, making it one of the scenarios with the highest returns for AI-assisted generation. In contrast is core infrastructure code: it is depended on by many downstream systems, needs long-term evolution, and every change can trigger cascading effects, so its requirements for correctness, maintainability, and resource overhead are far higher than those of the glue layer. Distinguishing these two types of code is a practical criterion for judging "what can be safely handed to AI and what must be checked by humans."

The collision of two engineering cultures

Putting this in a broader context, it is really a contrast between two engineering cultures. Old-school engineers' code is a product of constraints: limited memory, limited compute, limited storage, every design decision forced into trade-offs. Modern AI-assisted development is a product of abundance: plenty of tokens, plenty of compute, and developers are more inclined to iterate quickly rather than refine carefully.

Both cultures have their rationality. Software born in an environment of abundance iterates quickly and covers a wide range, something the old-school approach could hardly achieve. But the efficiency mindset forged under constraints is what is most easily lost in an environment of abundance. What is truly worth pursuing may not be taking sides, but rather, while enjoying the speed of vibe coding, retaining a sensitivity to resource overhead—knowing when to let AI write freely and when to take over by hand those critical, tight parts where waste is unacceptable.

That developer paid a high price for this realization, and this realization is precisely the part that AI cannot yet complete on his behalf.

One-line Summary

A developer's failed attempt to reverse-reimplement classic software with Claude reveals the boundaries of vibe coding.

Paragraph Summary

A developer used Claude to vibe-code reverse reimplementations of several classic programs, trying to use first principles to cut redundancy, but ended up spending a lot of time and tokens with little to show for it—it would have been easier to just buy the legitimate versions. The reason is that old software was born under severe hardware constraints, where every byte had a reason to exist and there was almost no redundancy to remove. The author thus points out the boundaries of vibe coding: it suits prototypes, glue code, and personal small tools, but struggles in performance-sensitive, resource-constrained, and long-term-maintenance scenarios. AI-generated code inherits the default assumption of abundant resources, excelling at stacking reasonable structures but not at byte-by-byte trade-offs. The article frames this as a collision between a culture of constraint and a culture of abundance, arguing for retaining sensitivity to resource overhead while enjoying the speed.