In the Age of AI Programming, Are Programmers Really "Getting Cooked"?

Industry Anxiety Sparked by a Viral Reddit Post

Recently, a Reddit post titled "We're cooked" rapidly gained traction in the developer community. The poster described a daily routine that many peers found both enviable and unsettling: log in to work, spend 30 minutes writing prompts for Claude and reviewing its generated code, then attend meetings, and spend the rest of the time tinkering with personal projects. He admitted he hadn't seriously written code in a year, yet was completing twice as many story points as his colleagues—his manager even regarded him as a "10x engineer."

The absurdity of this situation lies in the fact that while he enjoys the enormous leverage AI provides, he is also consumed by deep self-doubt: "I sacrificed everything to become a good developer—should I go get a plumber's license now?" At the end of the post, he asked what many are thinking: how much time do we have left?

What Kind of Coding Work Does AI Actually Replace?

Breaking down this case carefully reveals that AI doesn't replace all programming activities—it replaces the code generation phase. Large models like Claude excel at outputting well-structured, syntactically correct functions or modules based on natural language descriptions, which happens to be the most time-consuming and repetitive part of traditional development. The poster can easily complete double the story points because he has transformed "writing code" into "reviewing code."

But this doesn't mean engineering skills have become worthless. Reviewing AI code requires quickly identifying logic flaws, edge cases, performance bottlenecks, and security risks—these abilities remain the moat of senior developers. The problem is that when generation becomes cheap, the bottleneck shifts to review and debugging. Many teams find that AI can write 80-point code, but the last 20 points take more time than writing from scratch.

Story Point is a unit used in agile development to estimate the relative complexity of a task, rather than absolute work hours. It typically references the Fibonacci sequence (1, 2, 3, 5, 8, etc.) and is determined collaboratively by the team through planning poker and similar methods. The core assumption of story points is that estimates should be based on the relative size of effort, complexity, and risk—not on how many hours something specifically takes. Because of this, story points are inherently subjective and cannot be directly compared across different teams. In the context of AI-assisted programming, the limitations of story points are further amplified: a developer can use AI to quickly generate large amounts of code, making a task appear "done," but code quality, maintainability, and subsequent rework costs are not factored into the estimate. The poster's claim of completing twice as many story points as his colleagues only shows that he appears more productive within his current team's estimation system—it doesn't directly equate to twice the real engineering value.

Companies' "Late Realization" and the Illusion of Efficiency

The poster made a key observation: "Companies have caught up, but reflection takes time." This statement reveals the typical rhythm of enterprise AI adoption—embrace the tools first, then adjust processes, and only finally redefine performance metrics.

Currently, most companies still measure output using story points, lines of code, and PR counts—metrics that are easily "inflated" with AI assistance. An engineer skilled at writing prompts can generate large amounts of seemingly decent code in a short time, but the system's long-term maintainability, architectural consistency, and technical debt may quietly deteriorate.

More subtly, the "10x engineer" in a manager's eyes might just be a prompt engineer plus a fast reviewer. This efficiency gain is real, but is it sustainable? When everyone learns to use AI, this comparative advantage disappears.

Technical Debt is a metaphor coined by Ward Cunningham, referring to a team choosing suboptimal solutions for short-term speed, which requires additional costs to fix in the future. Like financial debt, technical debt "accrues interest"—the longer it goes unaddressed, the more expensive it becomes to fix. AI-generated code is particularly prone to creating hidden technical debt: it may be syntactically correct and pass tests, but leave hidden risks in architectural consistency, error handling, logging standards, and edge cases. When this code floods the codebase and reviewers let it through because "it looks fine," debt accumulates silently. More dangerously, traditional technical debt is usually the result of deliberate developer decisions—the team at least knows "we owe here." But debt under AI assistance is often scattered across numerous micro-decisions, lacking unified documentation and awareness. By the time the system shows performance degradation or frequent failures, tracing and repaying the debt becomes significantly harder.

The Plumber's License Is a Metaphor, but the Direction Is Wrong

The joke about "getting a plumber's license" in the post reflects tech workers' fear of skill depreciation. But equating AI programming with "programming is dead" is an overreaction. Historically, high-level languages, frameworks, and cloud services all triggered similar anxiety—only to raise the level of abstraction.

What AI programming tools truly change is the weighting of developer skill sets. The ability to write boilerplate code is depreciating, while the value of system design, requirement decomposition, quality control, and cross-team communication is rising. The fact that the poster can complete his work in 30 minutes actually shows he has the ability to translate vague requirements into precise prompts, as well as the eye to quickly judge code quality—this isn't "not knowing how to program," but rather that the form of programming has changed.

Level of Abstraction is a key concept for understanding the evolution of programming. From machine code to assembly language, then to high-level languages, frameworks, and cloud services, each technological leap has raised the level of abstraction: developers no longer directly manipulate low-level details but describe intent in ways closer to human thought, with the toolchain handling translation and execution. AI programming tools continue this trend, using "natural language description" as the new abstraction entry point. But raising the abstraction level doesn't mean low-level knowledge becomes irrelevant—on the contrary, when abstraction layers leak (such as performance issues, security vulnerabilities, or boundary anomalies), people who can drill down and pinpoint root causes remain scarce. The poster can complete his work in 30 minutes precisely because he stands at a sufficiently high abstraction level while retaining the ability to review downward. Simply interpreting AI programming as "programming is dead" essentially equates "writing code" with "programming," ignoring the migration of programming activities across abstraction levels.

How Much Time Do We Have Left?

The poster asked "How much time do we think we have?" There's no unified answer, but we can look at it by role.

For junior developers, the path of entering the industry purely through grinding algorithm problems and writing CRUD is narrowing, because AI excels at exactly this kind of work. For mid-level developers, pressure will gradually increase if they don't proactively move upstream (architecture, product understanding) or downstream (operations, security). For senior developers, AI is leverage rather than replacement, but they need to re-prove that their value lies not in writing code itself, but in judgment.

As for the time window, rather than guessing "how many years are left," it's better to watch two signals: first, whether companies start directly assessing performance based on AI output; second, whether hiring demands shift from "can write code" to "can review and design." These two signals have already appeared in some companies, but full-scale adoption will take time.

Turning Anxiety into Concrete Action

Facing the impact of AI programming, vague anxiety is meaningless. More practical approaches are:

Redefine your core competencies—replace "how much code can you write" with "how complex a problem can you solve." Proactively take on tasks requiring cross-module coordination and trade-off decisions—things AI can't independently accomplish in the short term.

Become a quality gatekeeper for AI code—delve into code review, testing strategies, and security auditing, making AI output more reliable through your hands. This is one of the scarcest skills right now.

Stay in touch with fundamental principles—even if you don't write code daily, understand the basics of runtime, networking, data structures, and system design. Otherwise you can't judge whether AI's proposed solutions are reasonable.

The poster updated at the end saying he's working on a personal project called DebriefReconstructed, which is actually a positive signal: when daily work is compressed by AI, the freed-up time can be used to explore more creative directions. Rather than asking "how much time do we have left," ask "what am I going to do with this time."

One-line Summary

AI replaces the code generation phase; developers must pivot to review, design, and judgment, turning anxiety into concrete action.

Paragraph Summary

Starting from the viral Reddit post "We're cooked," this article explores whether AI programming is plunging programmers into a skills depreciation crisis. The core argument: AI mainly replaces code generation, while review, debugging, and system design remain moats—but the bottleneck is shifting from writing code to reviewing it. Companies still use old metrics like story points to measure output, leading to overestimated efficiency and neglected technical debt. AI changes skill weightings: boilerplate coding depreciates while requirement decomposition, quality control, and cross-team communication rise in value. Different seniority levels face different impacts—junior entry paths are narrowing, while seniors must re-prove their judgment. The response: become a quality gatekeeper for AI code, maintain understanding of fundamental principles, and use freed-up time to explore creative directions.