People Who Write Great Code Actually Struggle with AI? The Washing Machine Theory Reveals Why

The Counterintuitive Phenomenon: The Better Your Code, the Harder It Is to Embrace AI Programming

As AI programming tools mature, a fascinating paradox is emerging: those who write the best code are often the ones who struggle most to embrace AI programming. This isn't a capability problem—it's a mindset trap.

A creator who originally worked in backend development shared his personal experience. Without any iOS development knowledge, he used Cursor paired with the Claude 3.5 model, combining screenshots and prompts to have AI fully implement the product ideas in his head. Cursor is an AI-native code editor built on the VS Code architecture that deeply integrates large language models into the development workflow, supporting AI assistance across the entire pipeline—code generation, refactoring, debugging, and more. Claude 3.5 is a large language model from Anthropic that excels particularly at code generation tasks, capable of understanding complex context and producing structured code. Together, they allow developers to describe requirements in natural language, paste screenshots, or even verbally explain ideas, and have AI directly generate runnable code—transforming the traditional "line-by-line coding" approach into a new paradigm of "requirement description + iterative refinement."

Meanwhile, the professional iOS developers around him maintained a skeptical attitude toward AI programming tools from 2024 through 2025—"This doesn't work, that doesn't work, you still have to write it yourself in the end."

The Washing Machine Theory: Why Expertise Becomes an Obstacle

This creator proposed an elegant metaphor—the Washing Machine Theory.

His mother still insists on hand-washing clothes to this day. If you suggest she use a washing machine, she'll turn around and "prove" why it's inferior: the machine doesn't clean properly, it takes dozens of minutes while she can finish in five. Within her cognitive framework, hand-washing is "superior" to machine-washing in every dimension.

Professional developers' resistance to AI stems from the exact same psychological mechanism. They have a mature "filtering logic"—when they see AI-generated code, their first instinct is to find flaws: naming conventions aren't standard, architecture isn't elegant, edge cases aren't handled. These judgments may be individually correct, but the problem is that they reject an overall efficiency leap because of localized imperfections.

This phenomenon has deep roots in psychology. The Sunk Cost Fallacy is a classic concept in behavioral economics, describing how people tend to stick with their current path because they've already invested significant time, energy, or money—even when switching to a new path is clearly superior. For senior developers, years of accumulated coding techniques, architectural experience, and toolchain proficiency constitute an enormous "cognitive sunk cost." Additionally, the "expert blind spot" effect is at play: when someone achieves high proficiency in a domain, they unconsciously apply that domain's evaluation criteria to all new things, overlooking the possibility that new tools might create value in entirely different dimensions. This explains why top engineers dismiss AI code's overall value because it's "not elegant enough."

In contrast, people who can't code don't have this "professional filter." They jump in directly, get first-hand feedback, and iterate quickly. By the time professional developers finally "come around," these people have already covered significant ground on the AI-assisted development track.

Imperative Thinking vs. Declarative Thinking: The Cognitive Divide in AI Programming

Behind this phenomenon lies a deeper cognitive difference: the opposition between imperative thinking and declarative thinking.

The creator used an elevator example to illustrate: you're on the 3rd floor, the elevator is on the 5th floor, and you want to go to the 10th floor.

• Declarative thinking: Press "up"—I want to go up, just state the intent
• Imperative thinking: Press "down"—I need to bring the elevator down to me first, I need to control every step

The evolution of programming languages itself is a journey from imperative to declarative: from binary machine code, to assembly instructions (MOV A, B), to C, to Java, to Python—each generation moves closer to natural language, closer to "declaring intent" rather than "controlling process."

From a computer science perspective, imperative programming requires developers to explicitly specify every step of program execution, with C and assembly language as typical representatives. Declarative programming only requires describing "what result you want," leaving the underlying system to determine how to achieve it—SQL, HTML, and React's JSX are all classic examples of declarative approaches. This divide between paradigms runs throughout the entire history of computer science. Every elevation in programming abstraction level—from punch cards to assembly, from assembly to high-level languages, from procedural to object-oriented—reduces the amount of detail developers need to control, letting people focus more on "intent expression." AI programming can be seen as the extreme extension of this abstraction path: developers only need to declare intent in natural language, and the model handles translating intent into concrete implementation.

AI programming is the latest step on this evolutionary path. But many engineers have an imperative mental model: I need to actively control everything, every line of code must be in my grasp—only then do I feel secure. This obsession with "keeping your hands on the steering wheel" is precisely the biggest obstacle to embracing AI programming tools.

The Renovation Metaphor: Should Developers Be Clients or Contractors in the AI Era?

If we compare software development to home renovation, AI programming is essentially changing your "contracting" model.

Renovation comes in full-service, partial, and bare-bones packages. People with strong control needs want to select materials themselves, draw blueprints themselves, supervise construction themselves—monitoring both soft and hard furnishings throughout, insisting every design follows their specifications.

Traditional developers are in exactly this state: from architecture design to code implementation to testing and deployment, every step must be done personally. AI programming requires you to learn to be the "client"—your focus should be on the final result, not every hammer swing during construction.

The creator admitted that this transition was "painful." He described himself as a perfectionist with code cleanliness obsessions and extremely high demands for program control. But he gradually realized that a boss's perspective is "gray"—a boss doesn't need to know how every line of code is written, may not even understand many product requirements in detail, but controls things at a higher level.

Breaking Free from Determinism Dependency: Redefining the Technical Professional's Role

The creator raised a key concept: the trap of determinism dependency.

The thinking habits engineers develop through long-term training pursue certainty—code must be predictable, logic must be traceable, systems must be white-box transparent. This is a virtue in traditional development, but in the AI era, it can become shackles.

Traditional software engineering emphasizes the "white-box" principle—every component of a system should be understandable, debuggable, and traceable. This thinking is rooted in decades of engineering practice: from formal verification to unit testing, from code review to architecture documentation, everything serves the core goal of "certainty." However, large language models are fundamentally probabilistic systems—their outputs have randomness, and their internal reasoning processes are opaque "black boxes." This creates a fundamental conflict with the deterministic thinking engineers have long been trained in. Accepting AI programming, to some extent, means accepting a "probabilistically correct" way of working: the code may not be optimal, but with rapid iteration and human review working together, overall output efficiency far exceeds traditional approaches. This requires engineers to shift from "pursuing single-instance perfection" to "pursuing systematic efficiency."

His colleagues didn't truly begin to change until early 2025, when they were struck by a new wave of AI capabilities. He himself, having let go of control earlier, was already "all AI."

More importantly, this process gave him an entirely new perspective:

"I won't let myself be too much like an engineer anymore. I don't want to define myself as a backend developer—I'm just myself. I want to build useful products and create valuable content."

This is perhaps the most profound change AI programming brings: it doesn't just improve coding efficiency—it redefines the role of technical professionals. When code is no longer the bottleneck, your value is no longer "writing code" but "thinking clearly about what to build" and "judging whether what's been built is good."

Final Thoughts

The "Washing Machine Theory" reveals something that extends far beyond AI programming—it's a pattern of human nature that appears during every technological paradigm shift. The more comfortable someone is in the old paradigm, the harder it is to leap into the new one—because they have too much "sunk cost" to let go of, too much "muscle memory" to rebuild.

But the direction of history is clear: from machine code to natural language, from imperative to declarative, programming has always been moving toward becoming more "human." AI isn't the endpoint, but it's the biggest single leap on this path. The question isn't whether AI is good enough—it's whether you're willing to let go of the steering wheel and focus on what truly matters.