Will AI Large Model Engineers Be Replaced? A Frontline Developer's Hands-On Breakdown

Will AI Large Model Engineers Be Replaced?

"Will AI large model engineers be replaced?" This is the question a frontline developer and Bilibili UP host raised during a livestream. His answer was direct and candid: It's possible, but not right now.

The UP host describes himself as not a PhD holder, but an engineer with many years of work experience who has always been doing development on the front lines. He mentioned that quite a few people questioned him: "Institutions have PhDs teaching courses—what does a master's student have to teach?" But he believes that academic credentials and the ability to clearly explain engineering practice are two different things—when it comes to finding a job, nobody hires you because of who you studied under; project experience is the hard currency.

During the livestream, he predicted that large model application engineers could potentially be replaced in three years' time, but at the current stage it's still very difficult. The reason is that although the Transformer architecture is already very powerful and there is still room for optimizing the underlying algorithms, the complexity of engineering implementation has far from been fully covered by automation tools.

Transformer Is Powerful, but Engineering Implementation Still Relies on People

The UP host didn't dive deep into the academic details of Transformer, but instead focused on the engineering side. His core judgment is: the reason large model engineers are still difficult to replace right now is not that the models aren't strong enough, but that between the model and going live, there are a large number of steps that require people to break down, supervise, and make decisions.

These steps include dividing project modules, defining code boundaries, choosing testing timing, and designing the code generation workflow. Tools can write code, but "how to make tools write the right code" still depends on engineers' judgment.

This is also a point he repeatedly emphasized: in the AI coding era, programmers who can't use webcoding tools can no longer be considered qualified programmers. Whether you're doing large model engineering development, Java backend, frontend, or testing, webcoding tools are essential skills.

Not Just Codex and Claude Code: The Division of Labor Between Superpowers and Gstack

During the livestream, someone asked: when webcoding, how do you maximize the effectiveness of the tools and make the model more convergent? The UP host's answer was very specific—don't just focus on Codex and Claude Code; also look at the two tools that come before them: Superpowers and Gstack.

His description is that Superpowers is responsible for breaking down complex projects into modules and processes, resulting in a workflow for writing the entire project's code; Gstack then further breaks down any small feature within each module, and during the breakdown process, rules, code preferences, and convergence rules can be defined.

In his words, these two tools "supervise" Codex and Claude Code to do the work, and the results are better. Gstack's core function is to do code layering and code breakdown for a specific module within a project, and set boundaries; Superpowers is for obtaining the overall development workflow for a large project, including which major functional modules to split into, what the requirements are for each module, how modules connect to each other, under what circumstances to do unit testing, and what the code generation workflow is each time.

Of course, he also acknowledged another path: not using Superpowers and Gstack, manually breaking down project modules and subtasks yourself, and then continuously acting as a "supervisor," overseeing Codex and Claude Code generating code in small chunks. This is equally feasible, but demands more investment from the person.

Codex and Claude Code belong to the category of "AI coding agent" tools: users describe tasks in natural language, and the model directly reads and writes files, runs commands, executes tests, and iteratively modifies code in a local or sandboxed environment. Their strength is "given a sufficiently specific task, write the code." But their weakness is also obvious—when facing a real project with hundreds of thousands of lines, without clear task boundaries, the model tends to go off track, miss dependencies, or repeatedly rework. Tools like Superpowers and Gstack fill in at this layer: the former breaks large projects into modules with dependency relationships and development workflows, while the latter specifies code layering, interface boundaries, and convergence rules within a single module, thereby constraining the agent's degrees of freedom within a controllable range. This division of labor between the "breakdown layer + generation layer" is a typical paradigm of the current AI coding toolchain.

From Getting Started to Going Live: The Implicit Position of Synchronous/Asynchronous Architecture

The original title mentioned "synchronous/asynchronous architecture," but the livestream content didn't elaborate on specific technical details. Judging from the context, this is part of the architecture design in a full-stack practical course, closely related to project module breakdown, code layering, and boundary definition. The UP host placed breakdown and boundary setting at the core of tool usage, which precisely shows that architecture decisions—including the choice of synchronous vs. asynchronous—still need to be completed by engineers outside of the tools.

Synchronous and asynchronous are fundamental decisions in backend and full-stack architecture: synchronous calls are simple to implement and have clear call chains, but when encountering slow I/O (databases, third-party APIs, large model inference), they will block threads and drag down throughput; asynchronous calls (message queues, event-driven, coroutines) can improve concurrency and decoupling capabilities, but introduce additional complexity such as ordering, idempotency, failure retries, and eventual consistency. In large model application scenarios, this problem is particularly prominent—model inference often takes several seconds to tens of seconds, and if everything is processed synchronously, APIs easily time out. Therefore, the architecture often adopts a pattern of "synchronous order taking, asynchronous processing, and polling or pushing to get results." Such decisions involve business semantics and capacity trade-offs, and are difficult for code generation tools to complete automatically; engineers still need to clearly define them during the breakdown stage.

Practical Advice for Developers

Based on the viewpoints from this livestream, several practical suggestions for frontline developers can be distilled:

• Webcoding tools are a baseline skill. No matter which direction you're in, if you can't use them, you're already behind.
• Treat breakdown capability as your core competitiveness. Tools handle generation; people define modules, boundaries, and workflows.
• Look ahead on the toolchain. Beyond Codex and Claude Code, tools like Superpowers and Gstack that handle breakdown and rule definition are worth investing time in.
• Stay clear-headed about replacement. The UP host judges it's possible after three years, which means what you should accumulate now is breakdown, architecture, and supervision capabilities, not just raw code output speed.

The UP host said it plainly during the livestream: never tell people "I learned large models from some teacher"; only what you learned yourself in projects counts. In the AI coding era, this statement may hold truer than ever.