15-Year Engineer Sidelined by AI? A Frontline Developer's Anxiety and Response

A software engineer with 15 years of experience posted on Reddit, admitting that AI is making him feel "sidelined." After Claude was connected to Jira, it can automatically read tickets, formulate plans, write code, open PRs, and even perform code reviews—sometimes holding more context than he does. He acknowledges that human judgment remains important, but the massive daily volume of changes is causing him to gradually lose his grasp of the big picture, and his judgment is actually being weakened. This state of "still on the job, but the work has been taken over" is sparking widespread resonance in the developer community.

From "Tool" to "Colleague": AI's Role Leap in the Development Process

The Claude workflow described in the post is worth unpacking: connecting to Jira to read requirements, generating implementation plans, writing code, submitting PRs, and completing code reviews. This is no longer an auxiliary tool that "completes a line of code"—it covers the core chain of software delivery. The engineer said that AI's plans are "usually very precise" and can even spot cross-file issues he might have missed in a single PR.

The psychological impact of this role change is concrete. In the past, an engineer's value was built on "I can write code that others can't." Now that barrier is being rapidly leveled. More subtly, when AI can connect requirements, implementation, and review, the human engineer's position in the process becomes blurry—you are still responsible for the results, but no longer deeply involved in every step.

The Position of Jira, PRs, and Code Review in the Development Process

Jira is a widely used project and ticket management tool. Development tasks are usually recorded as issues containing requirements, defects, and acceptance criteria. A PR (Pull Request) is a merge request mechanism on code hosting platforms. After a developer submits changes, they must undergo peer review before being merged into the main branch. Code review is the core of the review stage; reviewers need to understand the context of changes, potential risks, and cross-file impacts. In traditional processes, this chain relies on humans repeatedly switching between requirement understanding, implementation, and review, with each step requiring engineers to maintain an overall understanding of the system. If AI can connect these three links, it means it simultaneously touches requirement semantics, code implementation, and quality control—this is precisely the technical foundation for the original article's claim that AI has "more context than a person."

The Judgment Paradox: How Context Overload Backfires on Human Advantages

The most insightful sentence in the post is this: he tried to convince himself with "human judgment is key," but the massive daily changes made him "lose track of everything," ultimately limiting his own judgment. This is a paradox that all developers should be wary of.

The prerequisite for judgment is context. When AI produces changes at a speed far exceeding humans, the amount of information engineers need to digest grows exponentially. If they can't keep up, so-called "human oversight" degenerates into formal click-to-approve. This engineer's anxiety does not come from AI writing better than him, but from the fact that he is losing the information foundation needed for effective judgment. This is also why simply emphasizing "humans are irreplaceable" cannot truly alleviate anxiety—the problem is not value positioning, but a misalignment in working methods.

What Are "Context" and "Context Window"?

In the context of AI-assisted development, "context" refers to the total amount of information a model can reference when generating or reviewing code, including ticket descriptions, related source files, historical commits, review comments, and more. Large language models read these materials at once through a "context window." The larger the window, the better they can capture cross-file and cross-module associations. The original article mentions that Claude can find "cross-file issues" precisely because its context covers multiple files. For human engineers, context is a limited attention resource: when large numbers of changes pour in every day, the range a person can effectively track quickly saturates. The asymmetric expansion of AI's context capacity and human attention capacity constitutes the technical root of the judgment paradox.

The Underlying Tone of Anxiety: Not a Technical Problem, but Livelihood and Identity

The latter half of the post reveals more realistic concerns. He logged into LinkedIn, saw a large number of job searches and layoff information, and felt that "this is just the beginning." He explicitly said that writing code is the only skill he has and that he does not want to change careers to make funny videos on TikTok to earn a living. Even though he has achieved a certain degree of financial self-sufficiency through investments, he still feels it is not enough.

This self-account reveals two layers behind technical anxiety: on the surface is skill depreciation; deeper down is identity and livelihood security. A professional identity built over 15 years appears fragile at a technological inflection point. Similar discussions are increasing in the community, showing that this is not an individual's emotional fluctuation but a structural pressure faced by an entire generation of engineers.

The Difference Between "Skill Depreciation" and Structural Unemployment Anxiety

Skill depreciation refers to the decline in market value of a specific ability (such as hand-writing code) due to technological substitution, while practitioners can still reposition themselves by learning new skills. Structural pressure refers to the reshaping of the responsibility boundaries of an entire role, making it difficult for existing experience to transfer directly. The engineer's anxiety in the original article is closer to the latter: it is not that he cannot use AI, but that he finds the stages where he was deeply involved have been pulled away, while the remaining responsibilities (oversight, decision-making) lack sufficient contextual support. Feeling uneasy despite financial self-sufficiency also shows that the anxiety does not come entirely from short-term income, but from doubts about the long-term sustainability of professional identity. Understanding this distinction helps determine whether personal response strategies should focus on adding skills or resetting career anchors.

How Peers Respond: Several Approaches in Community Discussions

Although the original post ends with a question, combined with the many similar discussions in the developer community, several repeatedly mentioned response directions can be seen.

Move upstream. Shift energy from "writing code" to "defining problems, breaking down requirements, and designing system boundaries." AI excels at execution under clear constraints, while the formulation of constraints still depends on deep understanding of the business and system. Fifteen years of experience is precisely an advantage here.

Treat AI as an amplifier, not a replacement. Some engineers choose to actively take over AI's output process, for example by using stricter review checklists, requiring AI to explain the basis for decisions, and breaking AI-generated changes into digestible small batches. The core is to re-establish your own rhythm of control over changes rather than passively catching up.

Redefine the value of "being on the job." The post mentions that AI "has more context than I do," which points to a direction: the unique value of engineers may increasingly be reflected in cross-team coordination, risk anticipation, and ambiguous decisions that AI is not good at. These abilities are difficult to ticketize and difficult to automate.

Conclusion: Anxiety Is a Signal, Not a Verdict

The reason this engineer's post resonates is that it honestly describes an intermediate state: the person is still on the job, but the way of working has already changed, and a new positioning has not yet been established. This sense of suspension is more common than direct unemployment anxiety, and harder to articulate.

Judging from community reactions, no one offers an easy answer. But one repeatedly emerging consensus is: AI takes over the execution stages in the process, while engineers need to re-anchor their position in the decision chain. This process will not be comfortable, but at least the direction is clear—not competing with AI over who writes faster, but over who is better at defining what is worth writing.