How do programming agents reshape engineering, products, and design?

God Translation Bureau is a compilation team under 36Kr, focusing on fields such as technology, business, workplace, and life, and mainly introducing new technologies, new ideas, and new trends from abroad.

Editor's note: Code has become a cheap commodity, and PRD is becoming redundant waste paper. When programming agents eliminate the "implementation cost", the bottleneck in software development is shifting from coding to high - intensity review. In this job collapse, you either evolve into an all - around builder or defend the moat of systematic thinking. This article is from a compilation.

For software companies, the core of EPD (Engineering, Product, and Design) lies in creating high - quality software. Although the roles are clearly divided, the ultimate goal is to produce functional software that can solve business problems and is usable by users. Ultimately, all these outputs are code. We must recognize that the results built by EPD functions are essentially code, because... The emergence of programming agents has suddenly made code writing extremely simple. So, how will this change the roles of EPD?

Process transformation:

• PRD (Product Requirement Document) is dead

• The bottleneck shifts from "implementation" to "review"

• Long live PRD

Impact on roles:

• Generalists are more valuable than ever

• Programming agents become a necessity

• Excellent PMs become outstanding, while mediocre PMs become worse

• Everyone needs to have a sense of product

• The threshold for specialization is higher

• You either become a Builder or a Reviewer

• Everyone thinks that programming agents enhance their own roles the most - and they are all right

PRD is dead

Before the Claude era, PRD (Product Requirement Document) was the center of software development. The EPD process was roughly as follows:

• Someone (usually a product manager) has an idea

• The product manager writes a PRD

• The design team creates a prototype based on the PRD

• The engineering team converts the prototype into code

This is not an absolute rule (in startups, these steps are often intertwined, and top - notch builders can handle multiple tasks simultaneously), but this is the textbook way of development.

This model is necessary because developing software (and creating prototypes) requires a lot of time and effort. Therefore, to improve efficiency, specialized functions were created to handle these tasks. As the division of labor became more refined, the need for cross - functional communication emerged. The PRD is the basis for this communication. It initiates the entire process, then flows like a waterfall to the design, transforming flowery words into beautiful UI and smooth UX, and finally the engineering team turns it into reality.

Programming agents have changed all this. They can directly generate functional software based on an idea. When I (and others) say "PRD is dead", what we really mean is that the traditional software development model starting with writing a PRD is obsolete.

The bottleneck shifts from "implementation" to "review"

Now anyone can write code, which means anyone can develop products. But this doesn't mean that what is developed has a reasonable architecture, solves the right problems, or is easy to use. Engineering, product, and design should become reviewers and arbitrators in these areas. The problem is that the generated code is not always "excellent". The role of EPD has become to review and ensure that it reaches the level of "excellence". "Excellence" has multiple meanings:

• From an engineering system perspective, is the architecture reasonable: Is the code scalable, high - performance, and robust?

• From a product perspective, is it well - thought - out: Does it solve the user's pain points?

• Is the design excellent: Is the interface simple and intuitive?

Since the cost of creating the initial code version is so low, we see more prototypes being created. These prototypes then become the focus, to be reviewed jointly by product, engineering, and design.

The problem is - it's too easy to generate code. In the past, writing code took a long time, so as a reviewer, you only needed to review a limited number of projects at any given time. But now, since anyone can write code, the number of ongoing projects is skyrocketing. We've seen that (in all three functions), the bottleneck has become "review" - that is, receiving prototypes and ensuring they are "good".

Long live PRD

The pre - Claude software development era with preset PRDs is gone. But documents describing product requirements are still crucial.

Suppose someone has an idea and quickly develops a prototype. How does this prototype enter the production environment? It needs to be reviewed by other members of EPD. In this process, having a written document is always very helpful, and often essential. When others review, how do they know if a piece of code is a mistake or intentional? It depends on the intention. Therefore, some form of intention communication is needed. I think the traditional PRD process (PRD → prototype → code) is dead, but the text describing product requirements is still very much alive. Before handing it over for review, this associated document should be an essential companion to the prototype.

The most standard format is a document, but there are also some interesting ideas, such as communicating requirements by sharing the Prompt used to create the function. What if future PRDs are just structured, versioned Prompts?

Generalists are more valuable than ever

By generalists, I mean people with a keen intuition for product, engineering, and design. These people have always been valuable and influential, but with the support of programming agents, their value has been magnified. Why? Because communication is the most difficult part of all processes, and it slows things down. A person who can handle product, design, and engineering simultaneously can move faster than a three - person team because they save on communication costs.

In the past, when "implementation" was the bottleneck, generalists still needed to communicate with others to complete their work. Now, they only need to communicate with agents. This means they can have a much greater impact on their own than before.

Programming agents become a necessity

As programming agents reduce the implementation cost, using them has become inevitable. People who can embrace agents can do more work independently:

• PMs who embrace agents can directly develop prototypes to validate ideas without writing specifications and waiting for a long time;

• Designers who embrace agents can directly iterate in code instead of just tinkering in Figma;

• Engineers who embrace agents can shift their focus from "implementation" to "systematic thinking".

Embracing programming agents is a must because it's not difficult. If you don't do it, you'll be replaced by those who can.

Excellent PMs become outstanding, while mediocre PMs become worse

Good product thinking is more valuable than ever - you can develop something truly useful. And bad product thinking is more destructive than ever. Even if someone has a lousy product concept, they can come with a prototype, but it may be a useless or poorly - conceived function. These prototypes now require more review - from engineering, product, and design. This consumes a lot of time and resources. In addition, pushing these prototypes into the production environment also creates inertia ("Since it's already written, just merge it!"). This risks making the product worse or bloated.

Systematic thinking is a core skill that needs to be honed

In a world where execution costs are low, systematic thinking has become the key to differentiation. You should focus on improving your systematic thinking and establishing a clear mental model in specific areas:

• Engineering: Have an excellent mental model of how to design the architecture of services, APIs, and databases;

• Product: Have an excellent mental model of what users really need (not what they verbally want);

• Design: Have an excellent mental model of why certain things look and work well.

Systematic thinking has always been important - so what has changed? The implementation cost has dropped significantly. This means it's easier than ever to implement something, but that doesn't mean it's excellent. Good systematic thinking allows you to ensure that you build the right thing in the early stage and also enables you to review others' work in the later stage. Both of these mean that becoming an excellent systematic thinker has become even more important.

Everyone needs to have a sense of product

Programming agents still need someone to give them instructions on what to do. If you instruct them to build the wrong thing, you're creating junk for others to review. Knowing what to let the agents build (i.e., "product sense") is a basic requirement, otherwise, you'll drag the whole team down. This is true for engineering, design, and (obviously) product positions.

A large part of EPD's work now is to review prototypes. If you have a sense of product, the review will be much easier, even when reviewing design or engineering. If you don't have a sense of product, you need an extremely detailed product document to accompany the prototype. If you have a sense of product, with just a minimal specification, you can understand the function intention, thus accelerating communication, review, and delivery.

The threshold for specialization is higher

You need to know how to use programming agents and have a sense of product. All roles are merging. Role overlap has always existed. Design and product have long been inseparable - in companies like Apple and Airbnb, designers also serve as product managers. The role of "Design Engineer" is also very popular in companies like Vercel.

This doesn't mean there's no room for specialization. A senior engineer who only thinks about system architecture is still very valuable. Similarly, a PM who hasn't learned "vibe coding" but has a clear mental model of customer problems and construction priorities is also valuable. The same goes for a designer who can understand and simulate user paths and interactions in Figma.

But the threshold for specialization is much higher. You not only have to be excellent in your field but also have extremely fast review speed and excellent communication skills. Moreover, there may not be that many such positions in any company.

Either become a developer or a reviewer

We see two different types of roles emerging in EPD.

The first type: Builders. These people have good product thinking, are proficient in using programming agents, and have basic design intuition. Under given constraints (test suites, component libraries), they can turn small functions from ideas into outputs and build runnable prototypes for large functions.

The second type: Reviewers. For large and complex functions, detailed EPD reviews are required. This has a high threshold - you must be a top - notch systematic thinker in your field. You also have to work at a high pace because there are a large number of projects to review.

If you're currently an engineer, you should either strive to become a system design expert, be proficient in reviewing architectures, and aim for the reviewer role... or try to improve your product/design skills and become a developer.

If you're in the product or design field, you either have to have an excellent product/design mental model and focus on review, or dive into programming agents and improve your coding skills.

Interestingly, the roles are collapsing, and all EPD members can find their positions in the above coordinates. The roles are starting to merge - engineers have more time to think about product and design, while product and design can write code.

Everyone thinks that programming agents enhance their own roles the most - and they are all right

There's an excellent post on Twitter about the people who benefit the most from programming agents:

These people can intuitively understand existing products, know where they are weak, where they shine, and how to iterate to make them sharper.

The rarest type of these people is at the intersection of culture and deep - level technology, and they are truly "bilingual" talents. They understand both the technical possibilities and can distinguish which cultural trends are real and which are just passing fads. The result of this combination is the difference between a product that "feels natural" and a product that "feels pieced together".

This post is an excellent summary of this new world and has gone viral. Part of the reason is that everyone who reads it thinks it's about themselves or their positions. I've seen product managers, designers, design engineers, and founders retweeting it... Everyone thinks it applies to themselves and their roles.

And they're probably all right! I think the best and most exciting thing about this new world is that background doesn't matter as much. I truly believe that such talents can come from product, design, or engineering backgrounds. This doesn't mean everyone can become such a person - it's easier said than done. Truly "unicorn" talents are rare.

Get involved in the construction. This is an exciting era :)

Translator: boxi.