When AI Can Write Code, Engineers Shouldn’t Worry About the Tech
“When the founder of Claude Code announced the complete phase-out of handwritten code by 2026, the tech world erupted with debates about ‘whether programmers will lose their jobs’—but the real danger lies with those who still measure an engineer’s worth by ‘whether they can write code.’”
This statement suddenly made me realize that we might have entirely missed the bullseye of this technological revolution. The reason Boris Cherny’s declaration deserves this late-night deep dive isn’t because it predicts the maturity of AI-generated code (that’s already consensus), but because it’s the first time someone has put a knife to the throat of the entire software development paradigm: When AI can produce compliant code, the core value of human engineers will shift from “implementation ability” to “definition ability.” This isn’t just a tool upgrade—it’s a cognitive revolution from “how to build” to “what to build.”
Step One: Decoding the True Meaning of Vibe Coding
The oft-mentioned concept of “Vibe Coding” in public reports is, at its core, a new collaboration interface. It’s neither about letting AI fully take over development (which would lead to catastrophic abstraction leaks) nor about humans continuing to write for loops (which wastes human problem-solving potential). Instead, it establishes a dynamic “intent-feedback” loop: Engineers describe the “vibration frequency” (vibe) of business logic in natural language, AI generates executable code in real time, and humans continuously calibrate “vibration deviations” to control system behavior. In this model, teams no longer need traditional roles like “product manager-architect-programmer”—everyone becomes a “problem definer.”
Step Two: Why Cross-Domain Teams Are Inevitable
When code implementation becomes a deterministic problem solvable by AI, the team’s core conflict shifts from “how to translate requirements into code” to “how to ensure the requirements themselves are correct.” This demands that every member possesses:
1) The ability to understand the essence of the business
2) A framework for dissecting ambiguous problems
3) The discernment to judge AI output quality
A recent real-world case from a multinational team (note: no fabricated details here, just illustrating the trend) caught my attention: Their frontend engineers started joining user interviews, while backend engineers began asking in requirement meetings, “What emotional pain point does this feature address?” This shift is far more telling than “whether to use Copilot”—it signals a complete restructuring of role competency models.
The Problem: We Overvalue Tech, Undervalue Cognition
Current discussions about AI programming suffer from two fatal misconceptions:
1) Treating code generation accuracy as the core metric (in reality, once accuracy crosses a certain threshold, marginal returns plummet)
2) Assuming engineers only need to learn “how to give AI instructions” (like thinking photographers only need to press a shutter button).
The real turning point is this: When implementation costs approach zero, the ability to determine “what to implement” becomes the scarce resource. That’s why Cherny emphasizes a “whole-team” transformation—future technical barriers won’t lie in tool usage but in problem definition.
What Really Matters: Building a New Value Framework
I later dug into human-computer interaction research and found a counterintuitive conclusion: When AI handles deterministic tasks, humans need deeper domain expertise. This isn’t a paradox—only those who know “where machines might fail” can design reliable validation mechanisms; only those who understand “why a business needs this feature” can avoid generating flawless but useless code. This means engineer evaluations will undergo three fundamental shifts:
- From “lines of code” to “problems discovered”
- From “technical stack depth” to “domain understanding density”
- From “individual delivery” to “collaborative calibration efficiency”
The Most Common Misconception
The most dangerous cognitive bias is treating this as a simple “tool upgrade.” When cars replaced horse-drawn carriages, the key wasn’t whether coachmen learned to drive—it was that the entire transportation system needed rebuilding. Parents still preaching “master STEM to thrive anywhere” might be raising future “coachmen”—when AI solves all deterministic problems, what’s truly valuable is:
- The intuition to ask the right questions
- The ability to recognize ambiguous patterns
- The mental resilience to endure uncertainty
In the end, this means technological democratization won’t eliminate engineers, but it will ruthlessly淘汰 those who only “translate clear requirements into code.” Over the next three years, instead of agonizing over whether to learn prompt engineering, focus on honing your “problem嗅觉”—Can you smell the rot in business logic before AI does? Can you spot hidden abstraction leaks when everyone else says “this is fine”? These are the real moats for tomorrow’s technologists.