Introduction

The release of Gemma 4 and Cursor 3 marks not only another leap in AI technology but also a quiet rewriting of the core logic behind product decision-making. As AI makes coding easier, the real challenge has shifted from “how to do it” to “what to do”—the cost of poor decisions is being amplified by technological leverage. This article delves into the productivity revolution from execution to judgment, revealing four key capability upgrades that product teams must master in the AI era.

If the past two years saw AI rewriting programmers’ input methods, with the advent of Gemma 4 and Cursor 3, AI is now rewriting the entire chain of decisions a company makes regarding “what to do, what not to do, what to prioritize, and how to validate that we are not wrong.”

This is more important and dangerous than the question of whether AI will replace programmers.

Faster code writing usually just means increased efficiency; however, if incorrect requirements, wrong priorities, and misunderstandings of users are also written, executed, and launched quickly, then AI brings not a productivity revolution but rather a more efficient waste: the industrialization of pseudo-demands.

The discussion around Gemma 4 and Cursor 3 should not stop at the excitement of “stronger models” and “better agents.” What truly deserves industry attention is that as model capabilities, local deployment, long context, function calling, parallel agents, and cross-repo collaboration converge, the bottleneck of software production will shift upwards. The question will no longer be “who writes faster” but rather “who judges more accurately.”

As of December 2024, China’s internet user base reached 1.108 billion, with an internet penetration rate of 78.6%; mobile internet users numbered 1.105 billion, accounting for 99.7% of internet users; and generative AI product users reached 249 million. For China’s mobile internet industry, this means the market is no longer an early-stage experimental field but a mature competitive arena with high penetration, high substitution, and high expectations. In such an environment, any erroneous judgment amplified by AI will be exposed more quickly and settled more swiftly than before.

This article aims to discuss not whether “Gemma 4 is strong” or “Cursor 3 is worth using” but rather a more critical industry question: Why did Gemma 4 and Cursor 3 explode, but the real rewriting is not of code, but of the product decision chain?

I. Why Gemma 4 and Cursor 3 Became Industry Turning Points

Let’s first look at Gemma 4.

Google officially defines Gemma 4 as its “strongest open model to date,” emphasizing that this generation is designed for advanced reasoning and agentic workflows. Gemma 4 is licensed under Apache 2.0 and offers various sizes, including E2B, E4B, 26B MoE, and 31B Dense; it natively supports function calling, structured JSON output, and system instructions; large models support 256K context, while edge models support 128K context; it covers over 140 languages in native training; and it can handle images, videos, with some sizes supporting audio input. Google also highlights that the quantized version can run on consumer-grade GPUs, and the edge version can be deployed on devices like smartphones, Raspberry Pi, and Jetson Orin Nano.

The true importance of these parameters is not how much stronger it is than the previous generation but that it sends a clear signal: the value focus of open models is shifting from “try it out” to “truly embedding it into workflows and product systems.”

Many teams previously viewed “small models” as merely lower-tier versions of large models, suitable for demos, corner cases, or local toy projects. However, Gemma 4 demonstrates the opposite direction: when long context, function calling, multimodal capabilities, structured output, offline code, and edge deployment are compressed into more deployable model scales, small models become more than just a compromise when large models are too expensive; they evolve into execution units that can genuinely enter IDEs, local agents, business processes, and terminal devices.

Now let’s look at Cursor 3.

Cursor defines Cursor 3 as “a unified workspace for building software with agents.” While this sounds like product marketing, it actually corresponds to a paradigm shift. The core change in Cursor 3 is not merely “better completion” or “smoother chat”; it reconstructs the entire interface and mental model into an agent-first approach: supporting multi-repo layouts, seamless switching between local and cloud agents, allowing multiple agents to run in parallel, and integrating the workflow from commit to merged PR into a more direct interface. The new interface allows multiple agents to run in parallel across different repos, environments, locally, in the cloud, or even via remote SSH.

This means the paradigm of AI coding is shifting from “I write, you complete” to “I describe, you execute; I supervise, you advance in parallel.”

In other words, AI’s role is transitioning from code completion to workflow execution.

Gemma 4 represents a model foundation that is easier to embed into systems and more suitable for local and agent scenarios; Cursor 3 represents an agent interface that resembles a workspace and a software production operating system. One lowers the barrier to capability deployment, while the other raises the abstraction level of task execution. Together, they naturally shift the bottleneck of software production upwards.

Thus, the simultaneous focus on Gemma 4 and Cursor 3 is not merely two isolated product events but an industry signal: From now on, the core contradiction in software development is shifting from “how to write code faster” to “how to define requirements more accurately.”

II. What Becomes Expensive When Code Becomes Cheaper

The answer is: poor decisions.

GitHub’s research on Copilot has at least proven one simple yet important fact: AI coding tools can significantly enhance development efficiency. In a controlled experiment, 95 developers were randomly grouped to complete the same JavaScript HTTP server task, with 45 using GitHub Copilot. The group using Copilot completed the task 55% faster than the non-using group. GitHub’s summary of this research is clear: Copilot helps developers complete tasks faster and reduces cognitive load, allowing them to focus on more valuable issues.

Of course, this does not mean every team can unconditionally replicate the “55% speedup” figure. However, it sufficiently indicates a direction: coding itself is transitioning from a bottleneck to a channel.

Once coding costs significantly decrease, the most expensive aspects within an organization will no longer be “implementation” but will gradually become these issues:

• Is the requirement correctly identified?
• Is the priority correctly arranged?
• Is the success criterion correctly defined?
• Is the user problem correctly understood?
• Is the post-launch validation correctly conducted?

In the past, many teams could cover up judgment issues by relying on “limited development resources.” Even if the direction was slightly off, it would take weeks or months to produce, allowing for natural organizational corrections. That is no longer the case.

When PRDs can be quickly expanded by AI, prototypes can be rapidly generated, test scripts can be quickly completed, and development tasks can be advanced in parallel by multiple agents, organizations must confront a question for the first time: If the direction is wrong, you will produce errors faster, more completely, and with higher quality.

This is why it is said that Gemma 4 and Cursor 3 are rewriting not the code but the product decision chain. They make execution lighter, forcing judgment to emerge as the real core cost.

III. What is the Product Decision Chain, and Why is it Being Rewritten in the AI Era?

The product decision chain is not some abstract term. It is the chain of all key judgments that connects a product from “an idea” to “a launched result.” It typically includes at least six stages:

1. Discovering the problem;
2. Defining requirements;
3. Prioritizing;
4. Designing and implementing;
5. Validating post-launch;
6. Reviewing and iterating.

Many internet organizations formed their experiences under conditions of “high implementation costs.” Therefore, teams naturally focus a lot of energy on resource coordination, development scheduling, version rhythm, and launch nodes. However, when AI rapidly lowers implementation costs, the first problems in the entire chain often do not arise from “step 4 not being done” but rather from the first three steps and the last two steps: Did you identify the wrong problem, prioritize incorrectly, or define the success criteria wrongly?

The real change is not that “tools have become stronger” but that the focus of software production has shifted. In the past, the competition was about who had higher development efficiency; now it is about who has a shorter, more accurate, and verifiable judgment chain.

Three changes are occurring here:

First, from “output scarcity” to “judgment scarcity.”

When output is slow, organizations naturally emphasize execution; when output is fast, organizations must emphasize judgment. Because once execution is no longer scarce, the ability to judge what is worth executing becomes the truly scarce resource.

Second, from “version-driven” to “verification-driven.”

In the past, many products worked according to version rhythms: monthly versions, bi-weekly versions, promotional versions. However, with the emergence of AI, the critical rhythm has become hypothesis verification. Can you eliminate obvious errors before entering large-scale development through interviews, data, prototypes, and small-scale experiments?

Third, from “doing features” to “training systems.”

In the future, excellent teams will not just create individual features but will continuously train an organizational system: it must learn to identify which user problems are worth solving, which feedback is merely emotional noise, which metric changes are superficial, and which are genuinely structural issues. Therefore, the core differences among teams in the future will not only be about “whether they have integrated AI” but also about “whether they have trained themselves to be a better judgment system.”

IV. Why is it More Dangerous to Make Decisions on a Whim as AI Becomes Stronger?

Many people mistakenly believe that because AI can quickly produce prototypes, write code, complete tests, and run processes, organizations can become more agile, bolder, and even more suited to “do first and see later.”

On the surface, this is true, but in reality, the risks are greater.

Because the “do first and see later” approach assumes one premise: the cost of errors is still manageable.

However, this premise is disappearing. Not because AI has increased development costs, but precisely because AI has enhanced the organization’s ability to simultaneously pursue multiple erroneous directions.

In the past, a team might have been able to seriously work on only one major feature in a week. Now, if the product manager describes quickly enough, the designer produces drafts quickly enough, and the development and agent workbench cooperate quickly enough, the team could potentially pursue three, five, or even more directions in the same week. The problem is that this does not mean the organization has become smarter; it simply means the organization is better at parallel result generation. If the decision-making mechanism has not been upgraded, it does not mean greater agility but rather faster and larger-scale mistakes.

This is also why, in the AI era, “listening to what users say” is no longer sufficient. Because user expression does not equate to user tasks; user suggestions do not equate to product direction; user attitudes do not equate to user behavior.

Today, the real danger is not the lack of user feedback, but rather that teams find it too easy to translate surface feedback directly into execution actions. Once you translate “a user’s statement” directly into “a requirement,” and then hand it over to AI for rapid implementation, you will end up with a very complete, seemingly reasonable but directionally incorrect feature.

True product capability is not about “making AI faster at producing what users say” but rather about “faster identification of what users have not clearly articulated and what teams are likely to misjudge.”

V. Excellent Product Teams are Becoming More Like Evaluation Teams

This judgment may sound counterintuitive, but it is actually very fitting today.

Because modern software organizations increasingly resemble a system that is continuously trained and evaluated.

On the surface, you are making products, but in reality, you are constantly doing four things:

First, sampling: you choose whose voices to listen to.

The quality of a system’s training largely depends on what data you feed it. Product decisions are no different. Are you only listening to core users, the boss’s opinions, sales reports, or are you also listening to new users, churned users, low-frequency users, and users of alternative solutions? If your sampling is wrong, all subsequent judgments will be skewed.

Second, labeling: how you define “good problems” and “bad problems.”

Organizations do not inherently know what constitutes high-quality requirements. They must have their own labeling standards: what constitutes a true pain point, what constitutes a pseudo-demand; what constitutes a high priority, what constitutes emotional noise; what constitutes a system breakpoint that must be repaired, what constitutes an acceptable individual difference.

Third, evaluation: do you have a judgment framework that does not rely on feelings?

Without evaluation, there is no optimization. The same is true for products. Without a structured evaluation mechanism, what you see is often just “some people like it,” “some people complain,” “the data is average,” or “it feels okay.” But none of these help you determine whether the problem lies in task definition, information architecture, interaction paths, copy expectations, or value realization itself.

Fourth, bad case: do you treat errors as high-value assets?

Excellent systems are not afraid of bad cases; often, they rely on them. Because those areas that repeatedly produce errors are the ones most worth supplementing with rules, samples, and designs. Excellent product teams are no different. Do not treat user complaints, churn paths, alternative actions, and abandonment behaviors merely as customer service material; they are essentially all decision bad cases. The sooner someone turns these bad cases into rules, samples, experiments, and organizational consensus, the faster they will establish their judgment moat.

Thus, the core competency of future excellent product teams will, in a sense, shift from “managing requirements” to “managing organizational-level training loops.”

VI. What is Really Being Rewritten is Not a Position, But Four Key Stages

If we break down the “rewriting of the product decision chain,” you will see more clearly where this change is occurring.

First Layer: Requirement Discovery, Rewritten from “Collecting Opinions” to “Identifying Decision Risks.”

In the past, many teams liked to open requirement pools, look at feedback walls, check work orders, and analyze competitors for requirement discovery. While these are not useless, the more critical question in the AI era has become:

• What is the biggest risk in this decision?
• If we misunderstand, what will we waste?
• If we prioritize incorrectly, which key paths will be harmed?

If we only solve superficial problems, will the real issues remain in the system?

In other words, requirement discovery is no longer just about “seeing if users want it” but more like a risk identification process.

Second Layer: Requirement Definition, Rewritten from “Human-readable PRD” to “Machine-executable Specifications.”

In the past, the main audience for PRDs was humans: designers, developers, testers, and operations. This is no longer entirely the case. Increasingly, PRDs, task lists, and acceptance criteria will be directly consumed by AI. This means that vague expressions, unclear boundaries, ambiguous success criteria, and undefined inputs and outputs will be directly amplified into execution noise.

In the future, good PRDs will not only be “clear for humans” but will also strive to be “not misinterpreted by machines.”

Third Layer: Prioritization, Rewritten from “Experience-based Decisions” to “Evidence-weighted.”

AI will increase the supply of features but will not automatically give you the correct priorities. Thus, prioritization will become even more important than before. The truly robust prioritization should not only consider the boss’s preferences, competitor actions, or isolated feedback but should combine three types of evidence:

1. Behavioral evidence: Where do users drop off, jump, or abandon?
2. Interview evidence: Why do users do this?
3. Outcome evidence: Does this matter for retention, conversion, cost, or satisfaction?

Fourth Layer: Post-launch Review, Rewritten from “Project Closure” to “Continuous Evaluation.”

In the past, post-launch reviews were often project summary meetings. What do they look like today? They resemble evaluation meetings more. The questions are no longer, “Is the project completed?” but rather:

• What hypothesis did this change validate?
• Which user behaviors really changed?
• Which were just short-term stimuli?
• Which bad cases still exist?

Should the next round address root causes or surface issues?

This is why excellent teams will increasingly resemble evaluation teams. Because as execution speed is accelerated by AI, the true determinant of success will be who can complete the “verification-correction-reverification” loop faster.

VII. Stay Calm: Gemma 4 and Cursor 3 Will Not Automatically Lead to Good Products

The industry is particularly prone to falling into two extremes at this stage.

One is excessive optimism: “With such strong tools, efficiency issues will be resolved, and product innovation will become easier.”

The other is excessive pessimism: “AI can do everything, and product managers and programmers are doomed.”

Both views are too simplistic.

Gemma 4 is powerful, and Cursor 3 is also strong, but neither will accomplish the following for you:

• Determine the real user problems that need to be solved;
• Judge whether a requirement is only significant in a small sample;
• Distinguish whether what users say is emotion, preference, or a rigid task;
• Decide what constitutes a worthwhile question to invest in.

In other words, while Gemma 4 and Cursor 3 can help you prototype faster, write processes quicker, and advance agent work, they will not answer the truly critical question:

Is this really the problem we should be solving?

And this question is precisely what determines whether a product organization will be undermined by its own efficiency.

VIII. A Practical Methodology for Chinese Mobile Internet Teams

At this point, let’s provide a practical methodology that can be directly applied. This is not about vaguely saying “embrace AI” or “do more research” as empty platitudes, but rather a practical framework suitable for today’s collaboration among product, design, development, and AI teams.

I call it: The New Six-Step Decision Chain Method.

The goal is simple:

To let AI amplify correct judgments rather than amplify erroneous demands.

Step 1: Define the “Decision Object” First, Not the “Function Object.”

Don’t start by asking, “Should we do this feature?” Instead, ask, “What is the real decision we need to make this time?”

For example, do not write:

“Research whether users like the upgrade of the collection feature.”

Instead, write:

“Determine whether new users are reluctant to form a saving habit due to a lack of secondary retrieval value, thus deciding whether to prioritize changing the entrance, adjusting the information architecture, or temporarily not continuing to push this feature.”

Changing from “doing features” to “making judgments” is the first step.

Step 2: Use Data to Find Anomalies, Then Use Interviews to Explain Anomalies.

Do not reverse this process. First, look at funnels, retention, paths, abandonment points, and bounce points to find the truly worthy research anomalies; then conduct interviews, accompany observations, and task retrospectives to explain why users behave this way.

Quantitative data tells you “where it is wrong,” while qualitative data tells you “why it is wrong.”

Step 3: Conduct Interviews Focused on Five Aspects: “Task—Trigger—Path—Obstacles—Alternatives.”

Do not start by asking users, “What do you want?” Instead, ask:

• What task are you trying to complete?
• What triggered you to do this?
• How do you usually complete it step by step?
• At which step do you feel most frustrated, slow, or likely to give up?
• If you did not use our product, what would you do?

User interviews are better at helping you understand experiences, motivations, behaviors, and obstacles rather than directly giving you the optimal solution.

Step 4: Write Requirements as “Machine-executable Specifications,” Not Abstract Visions.

In the future, when you write PRDs, you must at least include four types of content:

1. Task boundaries: what will be solved and what will not;
2. Inputs and outputs: what input will agents, developers, and designers receive, and what should the output be;
3. Success criteria: what results count as effective and what do not;
4. Risk list: which scenarios are prone to misjudgment and which user types cannot be obscured by averages.

Because agent-first tools will directly consume this information. The more vague you write, the greater the execution deviation.

Step 5: Use AI to Quickly Generate Multiple “Disposable Prototypes,” Not to Quickly Create a “Seemingly Complete Formal Plan.”

One of AI’s greatest values is not to help you finish a plan faster but to help you compare multiple directions at a lower cost in parallel. Therefore, do not let AI serve “final decisions” directly; instead, let it serve “error elimination” first.

A more appropriate action is:

• Generate three directions for the same problem first;
• Each direction only reaches the minimum verification granularity;
• Let real users run tasks to see which one approaches the correct path more closely;

Then decide where to allocate resources.

Step 6: After Launching, Do Not Just Review; Create a “Bad Case Library.”

After each launch, at least document three types of bad cases:

1. Users clearly saw it but did not act;
2. Users acted but did not complete;
3. Users completed but did not form a habit.

Then ask four questions:

1. Was the task definition wrong, or was the path design wrong?
2. Was the expectation management wrong, or was the value realization wrong?
3. Is it a problem for a specific type of user, or is it a problem for the entire path?
4. Should the next round address experience, or should it revisit the requirements themselves?

The purpose of this is to turn project experiences into organizational-level judgment assets.

IX. Where Will the True Competition for Product Teams Occur in the Next 12 Months?

In the coming year, the industry will certainly continue to discuss model strengths, token costs, agent capabilities, local deployments, context lengths, and open-source vs. closed-source paths. All of these are important. However, for the vast majority of Chinese mobile internet teams, the real differentiators will not be “who uses Gemma 4 first” or “who upgrades to Cursor 3 first.”

The true differentiators will be:

• Who upgrades user research from “listening to opinions” to “finding root causes” first;
• Who upgrades PRDs from “human documents” to “machine-executable specifications” first;
• Who upgrades reviews from “project summaries” to “continuous evaluation systems” first;
• Who first accepts the reality: in the AI era, the most expensive thing is not writing code, but making judgments.

Gemma 4 makes high-performance open models easier to enter local devices, IDEs, and agent workflows; Cursor 3 pushes multi-agent parallelism, cross-repo collaboration, and local-cloud cooperation to a higher abstraction level. Together, they indicate that software production is shedding the scarcity of line-level code and instead exposing the shortcomings of organizational judgment.

Thus, what truly deserves vigilance is not that AI is too strong; rather, it is that you are still using outdated decision-making methods to manage an organization whose execution speed has already been accelerated by AI.

Conclusion

The excitement surrounding Gemma 4 and Cursor 3 is certainly warranted.

However, if you only understand them as “two stronger AI tools have arrived,” you are only seeing the surface.

The real wave is: code is being accelerated by AI, and decision-making is being held accountable by AI.

There will no longer be so many excuses to say:

• “Let’s just do this requirement and see.”
• “Didn’t users all say this?”
• “Let’s launch it and see; we can fix it later.”
• “Development schedules are long anyway; we can think while doing.”

Because now, things are done too quickly. So fast that any erroneous judgment cannot be naturally diluted by processes; so fast that organizations must first upgrade their judgment systems to enjoy the execution dividends of AI.

Therefore, do not regard Gemma 4 and Cursor 3 merely as development news. The true message they convey to the entire industry is:

In the future, the most expensive thing is not code; the most valuable thing is not prompts. The most valuable thing is a shorter, more accurate, and self-correcting product decision chain.

Whoever rebuilds this chain first will truly deserve the efficiency of the AI era.