Hello, Shi Yang, welcome to Kedaibiao Lizheng. Let's introduce Shi Yang. Shi Yang is the head of Trae. In my understanding, Trae is currently the second largest AI coding tool in the world.

Overpraised. I think in terms of size, it is indeed a very large product. Yes, yes, yes. Where do you want to be humble? Compared to size, we hope to be the second or first largest in terms of reputation. From our perspective, we still have a lot to learn from the leading products, such as Claude Code and Cursor, which currently have excellent reputations and are well-recognized. We are working hard to achieve a world-leading level not only in volume but also in user experience.

I think a very remarkable point is that when Copilot first came out, my personal feeling is that Trae has actually surpassed Copilot this year, even in the Tab experience that Copilot itself emphasizes so much, the overall effect is superior. This is not easy, because Copilot is also backed by a company like Microsoft, right?

Indeed, as you mentioned, Kedaibiao, we started developing this product in October 2024, and over the past year, we've gone from almost zero to our current state. We've made many breakthroughs in very detailed aspects. For example, as you just mentioned, Copilot initially focused most on code completion. It was the first in the industry to achieve this, and it started quite early, almost in 2022. Then, as model capabilities strengthened in 2023 and the industry's awareness of AI grew, people's perception of it also changed and improved. But later, I think in the entire industry, including Cursor and Trae, because startups are in a catch-up state, everyone has made many breakthroughs and attempts. I think from the perspective of completion, we initially could only do single-point completion, right? Or just a single function, where I write a name, and you roughly help me infer how the entire function should be implemented, or even just one line, yes, in the very early stages. Then it evolved to, for example, an entire function, and now to what's more common in the industry, for instance, many people use Cursor, and they have a very good experience with its Tab feature. Recently, it also published a new paper on RL, which means it can perform single-point completion. In other words, AI has become smarter; when you change one place, it can automatically parse and identify other affected areas and help you make changes. I think over the past year, we've reached the world's second-best level, with Cursor still leading us somewhat, both in terms of recognition and investment. In the past, I considered it the best in the industry. For us, besides Cursor, we've conducted benchmarks, and our experience is superior to most other products you can find in the industry. And this superiority, I think if Cursor is in a league of its own, we're probably at about 90% of its level. I won't comment on others, as it might seem like disparaging them, but in reality, others might have a significant gap from the top two. I believe users can see this from their actual usage experience, including our interviews with our own customers.

And within this, we feel our greatest effort lies in something that Chinese teams might be particularly good at. I believe Chinese teams, compared to American teams, are more adept at "composition on a given topic." For example, if a problem is presented, can you reproduce it or improve upon it, and at a lower cost? I think this is where Chinese teams excel. Silicon Valley teams might be more adept at defining a problem and initially providing an excellent solution for it. I don't think there's a hierarchy here; I believe this is something you gradually discover as you continuously gain understanding of the industry, products, and users. So, for us, over the past period, we've been in the process of catching up and learning from industry leaders. Therefore, we've done many things to achieve the level of world top-tier products, thus leveraging many advantages of Chinese engineering teams.

I've actually shared my understanding of this matter on various occasions. We at least believe that in the field of coding, it's an interplay of model, engineering, and product. In this AI era, especially in Silicon Valley, numerous new products and ideas emerge daily. But from my candid perspective, if we look at the true story, focusing on LM as the core, I think it's very clear that what can truly be used by users in daily life, one is definitely chatbots—that's a very certain thing. The other is probably AI coding. Chatbots, people have been discussing, "AI applications are just wrappers for AI models." I think chatbots are a very typical example because, in essence, right, they are just an overflow of the model. You just ask a question, and it answers your question; essentially, it's just a box. People often say, "Isn't it just a box?" It's a bit like Google, right? It's just a box, but its underlying capabilities determine that it can be a box, and it might be the optimal product form. But for coding, I think from the very beginning with Copilot, including Cursor, and now Claude Code, and potentially some newer products coming out later, we gradually see that the so-called wrapper is getting thicker. We can actually see that because writing code is not a simple interaction with AI. If we assume writing code is just an interaction with AI, then theoretically, I would use Artifacts, right? Even Claude, in the end, has products like Claude Code. I think it still requires many tools. For example, in the traditional sense, as long as you're not truly AGI today—for instance, if I ask a complex question like "help me build a Facebook" or "help me build a TikTok"—it can't do everything for you all at once. In this process, you still need file management, code review, debugging; all these problems still exist in the original tools. This is why we've spent a lot of time building AI into tools, trying to improve your past coding experience, rather than simply generating an app end-to-end directly. We can see some aspects where this is not achievable.

Okay, let me first address what I'm about to ask. People might say, "Aren't you just copying?" Hahaha, but there are thousands of teams that copy, yes, but only one has become the second largest. Only one has copied its way to second place. So, how exactly was this achieved? This matter, especially the combination of model, engineering, and product that you just mentioned, I really agree with. So I believe you can bring some very unique observations here.

I think we can discuss the point about "wrapping" or how we define what an application is. For example, we have Infra, right? As you just mentioned, whether it's databases or later Claude, or today's AI, I believe it's the foundation for all applications. Including from the PC era to the mobile era, and then to the AI era, how do we define the value of an application? Actually, from my personal perspective as a product manager, I would say a good application reduces the user's cost of use in their specific scenario. It's like the question you just asked: can't an iPhone take pictures? But why are there so many camera apps? It's because you'll find there's a type of user who, in their scenario, needs to spend more time, whether it's on the learning curve or daily operational costs, making it more complex. Or, when we scroll through TikTok, why is the pleasure so strong? I just need to do this. But in reality, we can have other forms, for example, after you take a picture, you send it to me via Airdrop, right? I think it's the same. So, I actually think the greatest significance of an application comes from when you discover a common usage or need for a group of people in a specific scenario, how you effectively encapsulate it to make these needs smoother, lower cost, and more enjoyable. I think this is the core value. I believe we build products around this thinking. This is the first point. I actually think whether it's a wrapper or not isn't important; the world, or the entire Internet, might just be 0/1 wrappers, right? Abstractly speaking, a car is also just making you go faster. Yes, so I think that's the first point.

So the second point is about the concept of copying that was just mentioned. First, I believe nothing is truly exclusive. Even with copyrights, user interfaces or applications are not. If we open all applications today, you'll find that within each category, there are all sorts of options—a huge number of camera apps, game apps, mobile games, and so on. But in the end, you'll find that only one or two are truly good, and only one or two will be widely accepted by users. So, I define "copying" as a neutral term. The final product forms in an industry might converge significantly because we constantly discover the optimal form in the process of serving users, and that optimal form is likely to be quite similar across products. I think that's the first point. Another point is how our product team thinks: there's no need to be different just for the sake of being different. I must "be different." It's like Steve Jobs might have said, "I want to be different," but his point of being different wasn't that a PC shouldn't look like a PC; it should look exactly like that. It's like a signature I had for a while: "A triangular wheel is beautiful, but I wish it were round." Thank you. So, a wheel is round; you can't say it's a triangle. But perhaps the difference lies in the context of the wheel—how big or small it is for a particular scenario. So, for us, if we define copying, we believe we have a huge gap compared to the leading players or products in the industry. There's no need for us to be different at this stage. In other words, we first need to become a round wheel. It might not look good, it might not be perfectly round, but we need to refine it. So, I think this is the first step: at least making people recognize you as an AI coding tool. We also went through the early stages where people would say, "This isn't good; you're copying Cursor; this and that." That's an inevitable phase. Because it's like saying, if I want to build an electric car today, I need to know how batteries are made, I need a chassis, I need wheels, and I need to put them all together. Another point we frankly admit is, first, I didn't come from a researcher background, and second, I had no prior connection to AI. I believe most of us have no connection to AI. I think learning from the best in the industry is a very fast way for us to progress. And then, when you invest more time and effort in this industry, you'll gain different insights. I think that's where the divergence begins to happen.

When do you think the divergence started? Or has it started?

We ourselves believe that divergence may have begun, but this still needs to be recognized and diverged by users. Let me first look at others from an external perspective. For example, Code is a fork of Cursor, right? That is, the initial consensus among everyone was that "everyone is doing Copilot." All sorts of plugins—maybe not now, but if we go back a few months, yes, there might have been a dozen or twenty plugins from various companies. Then it evolved from plugins to an AI IDE form like Cursor. And Claude Code is another divergence. I think Claude Code is also based on their understanding of models, their cooperation with Cursor—of course, this is my own guess—and after insights into users, they found that they could evolve from a Cursor-like form more towards a coding agent. And I think from our perspective, because we deal with all these challenges every day, deal with all this user feedback, and learn and understand other excellent products. Our current view is that divergence has also occurred. It may not be correct, or the point where we are trying to be different is, from my observation, AI coding has gone through 2.5 eras. From my perspective, the first era must be Copilot. Copilot was the first to truly make AI usable. And I think now, for most users, especially professional developers, the intensity of using coding agents is far greater than that of code completion. I think this is the first era.

Then the second era is the Cursor era. But Cursor actually did very good completion in its early days, and I think Cursor's completion is still the best in the world today. But what really made it famous was Claude 3.5, combined with its product form, and Andrej Karpathy's "vibe coding" tweet. So I think this is the second era. And from a product perspective, I think its best aspect is that if in the past we relied on integrating AI capabilities into the IDE, which was the Copilot era, doing so through plugins. Then I think the second era is about natively building AI capabilities into the IDE. That is, it forks itself—of course, we have to thank VS Code for being open source. So it forks from VS Code and truly integrates AI into the IDE. I think this is a huge step forward from a product perspective. Because you get more context, many interactions can be more native. This is from the product perspective.

So from a capacity perspective, what do you see as the main difference between the second generation and the first generation?

I think, first, because AI capabilities have become stronger, you need deeper interaction, not just simple completion. Perhaps I need to interact through dialogue, and you've given me many results. How do I apply these results to the current workspace? For example, if there's an error here, can I reference this error to my right-hand chat panel? I even need to know some underlying information that some plugins in my current IDE cannot access. I'm not necessarily saying this is entirely correct, but perhaps only the official Copilot can access the underlying APIs of the official VS Code, and other plugins cannot. So, at this point, if you fork one and directly implement it, you get more APIs, and you can do more things. I remember it being like this: it's like you're working at the application layer or the operating system layer? Yes, at least at the API layer, I can control all my environment. So, I think this is a downward progression. The core is that AI capabilities have become stronger, and you can leverage these API improvements to provide a better experience. Otherwise, if AI remains the same, giving you these APIs would be useless.

Understood, understood. This is indeed what you just said about engineering, product, and AI itself.

Yes, I think it's the intertwining of all three. And I think the beginning of the second generation was actually Q&A. It wasn't really an agent yet.

Oh, right. So, at that time, Cursor had an agent mode, but it also had a chat mode.

Yes, that's right. In fact, many people were initially drawn to the chat feature, meaning I could ask a question and it would answer me. Because I think the simplest and most impactful experience for me, as a programmer, especially in North America, is that Stack Overflow is indispensable, right? And you'd find a piece of code, wonder what it means, then copy-paste it, search first on Google, then Stack Overflow, find a bunch of information, maybe pick three from the first ten results, paste them back to see which one works, and then think about it. Or you'd ask the person next to you, right? That's generally how it goes.

Sometimes I'd also check YouTube.

Yes, basically those few logics. But I think the chat feature largely solved this scenario very well. That is, if I have a problem, I just ask it directly, and it usually provides some pretty good solutions.

And it can indeed get more information.

Yes, and actually, it goes back to the question we discussed at the beginning: a good product makes the entire process smoother for you. You see, in the past, you would copy-paste, then search, look through results one by one, find the right one, apply it back, and then check. Now, it's become: you see a problem, you directly ask the chat what the problem is, the chat gives you an answer, you apply it, and oh, it's correct, then you're done. If it's not correct, you ask again. So, your entire process is actually shortened a lot. Perhaps for a single instance, you only shorten it by 20-30%, but if you multiply that by 100 times, you'll find that your experience becomes incredibly good. So, I think from the very beginning with chat, and then gradually we started trying what I considered a "boss word" at that time—agent. From our perspective, it wasn't.

Right. But I think in the industry, the so-called Pioneer always has to define something, right?

I don't think "boss word" is a negative term; it just refers to a more pioneering person, an early adopter, who defines a term and lets everyone know, "Oh, that's what it is." At that time, I felt that an agent, for me, meant more automation, completing long chains, from a single action to possibly multiple actions, even just two actions. I think it did a lot of things like that. I was greatly impressed at the time. I remember clearly that in August 2023, when Claude 3.5 came out, we hadn't started working on IDEs yet; we only started our IDE development in October of last year.

October 2024.

Yes, we started in October 2024. I was truly shocked, and I immediately said that the future must develop in this direction. My bold prediction today is also, what will the ultimate AI coding product look like? I don't know, but it definitely won't look like Trae, it won't look like Cursor, and it won't look like Claude Code. I think it still has a long way to go. It's like how from the earliest VI to the final VS Code, you went through a long period of various editing software from different eras, and finally, it became that form. And it even forked into VS Code and JetBrains, right? It performs better in different languages. So, what we thought at the time was, at least we believed that plugins were definitely not the optimal form. And at that time, it seemed that the optimal form was something like building AI into your tool. I think this is the second era we witnessed. And then, even up to today, I think Cursor is still a very good product.

Yes.

And they made the agent capabilities stronger. And why do I say 2.5, not three eras? I think it goes back to Claude Code, which I think is one of my favorite products over the past period. From my perspective, it can't really be considered a product, but rather a model's showcase.

Actually, ChatGPT was also a model showcase at first.

Oh, yes, yes, yes, yes. That's exactly it. It's more like a showcase, and there are many things you can do with it. The best thing it does is to show you how you can use what might be the best code model in the world. I think that's a very good point. But if you define it as, for example, relying on Claude Code for all my development, I haven't seen anyone who can do that, just solely relying on Claude Code for their development. For instance, I find that a lot of people put Claude Code inside VS Code or Cursor, meaning they put it in their terminal. Because, for example, I need file management, I need to review certain code—once you've generated it, I need to look at the code and do a lot of previews. For example, how a frontend page I generated would look. You'll find it's very good, but it can't cover the entire experience of my development process. It's like a Raspberry Pi, right? That's the point. Or my other thought is that Claude Code is the VI of this era. VI is incredibly powerful and good, right? A true super user can achieve amazing things with it. Really, when I was at Facebook, for example, many very senior engineers were extremely proficient with VI. A power user would use it very, very well. But from a popular perspective, the ultimate winners are likely integrated environments like VS Code and JetBrains. What do they integrate? From my perspective, for example, file management is a big point, a compiler is a big point, and plugins are a big point. If you look at it from this perspective, I think Claude Code still has a long way to go for development. Of course, I think model capability is definitely a very important part. So from my perspective, what I envision as 3.0 should be based on the capabilities Claude has demonstrated today, whether it can encapsulate something similar to VS Code—meaning a VS Code 0.1 version of this era—that can handle the things we just talked about. For example, how do I do file management? You still need file management today. You still need to give AI many plugins because AI needs a lot of context. You still need to interact between humans and AI today. Although I think Claude Code has done quite well, it's not perfect. It's like more people are used to graphical interfaces and find it difficult to interact entirely within a terminal. So from this perspective, if Claude Code's demonstrated capabilities can go a step further, is there an opportunity? This is something our team is thinking about.

So, what do you think is the biggest difference between such a thing and today's Cursor? Can you just add some more buttons to the current Cursor to make it like that?

I think that's a very good question, and you've reminded me. My own view is that, not just Cursor, but building around the IDE form might be a big challenge. What is my ultimate goal as a developer? It's to deliver an application, whether it's a web application or a mobile app. If I'm delivering an application, the time I spend in the IDE probably accounts for about 30-40% of my entire process. Beyond that, I have many other tasks that are not within the IDE. For example, I might be doing DevOps, right? Including A/B testing, all these things might happen in a browser, or be generated in other clients. Arguing with product managers, all sorts of things like that, right? In Figma, in documentation, all sorts of these problems. So, coming back to this, how did you do it in the past? How did I, as a developer, do it? It was me, as a true human intelligence, interacting with different tools, meaning I was the orchestrator, knowing that I should be working here at this time, and there at that time. When I switch between different tools, the context is here, meaning I know this context, then I go into that tool, find a problem, and then come back. If we are aiming to solve the problem of generating software, delivering results, you'll find that the IDE is only a part of the entire process. The current form of Cursor or Trae is that we build AI into one tool, and then we find that we actually use multiple tools. Of course, you'll find that each tool also has its own tool or its own Copilot, right? But the problem is, you have to simple copy-paste the context back and forth between the AIs in those different tools. Many people use Cursor, including Trae, in this way. I first chat with ChatGPT, then write an MD, get the MD ready, paste it into Cursor or Trae, and then you help me generate. After it's generated, if I think it's good, I then maintain this MD. Suppose I need to bring this MD back into ChatGPT; I have to paste the whole thing in again. And when you paste it in, you actually have a loss of context. For example, that pile of code, or which part of the generated webpage looks good or bad—all sorts of context are actually very difficult because you have multimodal issues. How do I handle this image, or which piece of code, which error message am I referring to? In reality, it's all unknown. I think for the next generation, our own thinking is, should we build more tools into AI, rather than having each tool have an AI? This way, AI becomes at least connected to all contexts. It's not about whether it knows, but at least it has connections.

It might know.

Yes, there's a possibility of knowing. Yes, it has the possibility of knowing. But then it becomes a three-way interaction: human, AI, and context. What's the challenge here? As you just mentioned, although I've given the context to the AI, as a human, I don't know if the AI knows or doesn't know. I don't know how much it knows, especially where its attention truly lies. Yes, yes. There are all sorts of such problems. But if we can solve this problem well, it will mean that your entire process expands from a single tool to you interacting with AI to manipulate various tools to complete your development tasks. From our perspective, this is our divergence. Perhaps it's not necessarily correct, and perhaps we will encounter many challenges in this process, or even find that it might not make sense. But from our own perspective, this is what we hope to provide our users with in the future—a tool to do these things. I think this is what you just talked about: from copying to having your own divergence, or how to gain insight and think about this matter.

Hmm, I personally really agree with this divergence. And I'm not looking at it from a developer's perspective, because I can tell from our conversation that you're very focused on how developers can do things well in this context. From this perspective, I think SOLO seems to achieve two things: it allows developers to orchestrate more tools within a single interface to complete their development tasks more efficiently, and it also potentially allows ordinary people to achieve what they want using natural language. Do you think these are two different tasks, or essentially one task?

I think from an ultimate perspective, it could be one task. But in the current scenario, I believe they are definitely two types of tasks. From my own observation, there are several significant challenges. The first challenge is, how strong are the end-to-end capabilities of today's AI models? Let's talk about the "vibe coder." Today's AI capabilities can actually be used to create a Snake game, even a front-end and back-end separated Snake game, and it will do it very well, to a level where you can actually launch it. However, this is the limit of what a vibe coder can imagine and achieve. If it's a bit more complex, like "make me a front-end and back-end separated TikTok," it definitely cannot do it. That is, when you ask such a question, the upper limit it can reach is determined by the complexity of the question. From the perspective of software generation complexity, the greater the complexity, the more obvious the decay. We will see that many vibe coders with no coding experience currently have clear limitations. But we also see that when you possess sufficient professional skills, and when you learn how to ask better questions, you will find that these tools provide significant benefits. Regarding building a TikTok, as we just discussed, I would break this down into perhaps 1,000 tasks. It cannot build a TikTok, but if you tell it, "I need to set up a database table, and this is its structure," when you ask such a question, it's equivalent to asking it to build a Snake game. But what's the prerequisite? You need to know how to break down building a front-end and back-end separated TikTok into 100, or 1,000, problems similar in complexity to a Snake game, and ask them to the AI. This is the first step.

The second step is that even if you can ask such questions, errors will still occur during the process. When errors occur, you need professional skills to correct them. But for someone with no coding experience, who can only ask for a Snake game, they're truly clueless—they'll wonder, "What is this?" They won't even look at the code. Yes, they can't understand it, and they can't even look at it. But for professionals, why is their experience so good? It's because they can identify the problem at a glance. You might just add a sentence, saying, "Don't write it this way; maybe we can write it differently," and with that approach, it just works. A student with no development experience definitely wouldn't be able to figure that out. There's a knowledge gap. Yes, or a skill gap. You've been professionally trained. I often tell my product colleagues internally that everyone can clearly and beautifully define what the day after tomorrow will be like. Hahaha, but today we are facing the task of building products for tomorrow's people. How do I leverage today's capabilities to make tomorrow's people happy? The day after tomorrow is all AGI, yes, we all know that, right? So, what about tomorrow? I think this is very, very important. From this perspective, when I, as a professional developer, ask a question, can I better enable other professional developers? Originally, you had to break it down into 1,000 tasks; I'm trying to help you break it down into, say, 500 tasks. That is, the problem becomes larger, but I can still achieve it. I think this is the first thing we can do.

The second is that when an error occurs, it can quickly inform me, improving my efficiency. It can tell me where the problem occurred and provide quick feedback, which is responsive. A more "boss word" term is "human in the loop." I can tell you what the problem is, and we can work together to solve it. What's the second thing? Collaboration, right? First, you need to treat it as a human, "be a human." For example, when you ask your colleague, you might say, "Hey, can you help me do this?" But even your colleague might encounter problems during the process, saying, "Oh no, this is wrong, let's not do it this way, you should use this framework, or this latest version." I think this is about how to give feedback more quickly, and based on that feedback, iterate more quickly. This is a very important point. And you'll find that these things are meaningless to the so-called "vibe coder." Then, building on this, we further improve. Simply put, if it says, "I'm done." Then you'll have a few questions. The first question is, "What did you write?" Hahaha, I have to take a look, right? There are several ways to look: look at your code, look at your generated output. Your code might be in the IDE, and if you're a frontend developer, you might need a browser to see your generated output. If you're on mobile, I might need an emulator to see all these things. How quickly can I let my users see this? That's why I say Claude Code is 2.5. And now? I still have to open the browser to see those things. Why do I say that traditionally, IDE-based tools, no matter how much you add, are essentially editors? The core of an editor is to improve the typing experience. But in reality, if AI capabilities advance further, more of your interaction will happen through dialogue, meaning I ask questions. You truly treat it as a person. For example, you are the AI, and I am the one saying, "Kedaibiao, help me do something." I need to ask questions clearly; the clearer the description, the more accurate your output will be.

What's the second thing? Review is far more important than typing. I need to manage up effectively, I need to show my thought process, I need to tell you what I'm going to do next, but I also need to control the extent of this—I can't ask for permission for every little thing. Yes, we think the most important thing, first, is your experience in the chat. You ask a question, and it might work for ten, twenty minutes, or even an hour. And you'll find that the output, its experience, is different from what you get in ChatGPT. No matter how long a question you ask ChatGPT, it'll give you three to four thousand words at most, right? Reading a three to four thousand-word article takes two to three minutes if you're fast, or five minutes if you read carefully. But if you look at something generated by a 20-minute coding agent, it could easily be hundreds of thousands of lines, right? How do you review that? You didn't have this challenge before. You find, "Oh, this thing doesn't work." How can you quickly find where the error was made? And it's always just a little off, right? You have to go back, back, back, a very long way. How do you deal with these things? From a UI perspective, do you need to abstract? That is, perhaps I need to summarize large chunks of content. What did I roughly do in this section, what did I change, what kind of errors might have occurred? This actually increases the user's efficiency. And when I find an error, how can I quickly jump to, say, the IDE, jump to the web browser, and build into these tools, and open them? In fact, it's a next-generation plugin system. If the previous generation was about making plugins for VS Code, this generation is about making plugins for your AI. What is the form of this plugin? We don't know. What is its most perfect form? We don't know. What we can leverage today are still existing tools. We might combine the IDE and AI, or the browser and AI. But in reality, they are too heavy because they are not designed for AI. AI doesn't actually need so many highlights; highlights are for humans. And that means if you give it Markdown, it might already solve the problem. Then it becomes another problem: the tools on the right are for humans. Humans are also very important because humans need to review this. What we are improving is the review experience. When you improve the review experience, and you don't need so many operations, then my process will be very, very simplified, and my speed will be very, very fast.

I have an imperfect analogy: the plugins for AI coding tools might be like mini-programs. You open them when you need them, and when you don't, you don't care at all. And mini-programs are very heavy on review but light on operations. You generally don't want to do complex operations within a mini-program, right? Most things done in mini-programs are things like payments, quick ordering, or ordering food—things that aren't very operation-heavy.

Actually, I think in future AI coding plugins, you might only need to click once or twice to take a look. This is what we might see in the future. So, what we actually need to do is, first, help you communicate better with AI; second, help you better review the results produced by AI; and third, how to better help AI by providing more tools and context. Yes, what I mean by making plugins for AI, I think, is these three things. This is from Solo's perspective and where we believe the next generation of products should go. At the same time, you also asked earlier, we believe that "vibe coders" and professional coders cannot be merged at this stage. Because whenever you want to build a serious app, the human involvement will be very high. The vibe coder's demand is that they cannot have such a high level of participation because their capabilities cannot support them in doing so. Yes, and then it becomes that you are actually separate. The greatest significance of an application comes from when you discover a common need for a group of people in a specific scenario, how you effectively encapsulate it to make these needs smoother, lower cost, and more enjoyable. I think this is the core value.

If we take stock of current AI programming or vibe coding tools, Trae from ByteDance is undoubtedly the world's second-best, both in terms of user base and quality. However, when Trae is mentioned, many people's first impression is that it's a copycat, and that it's cheap. This was my impression too in the past. But over the past year, we've visibly seen Trae's quality improve with each iteration, while many other tools, such as Copilot and Windsurf, have fallen behind. This made me curious, and today I bring this very sharp question.

Chinese teams, compared to American teams, are more adept at "composition on a given topic." The problem is presented, and then the question is whether you can reproduce it, or improve upon it, and at a lower cost.

Actually, Shi Yang and I have known each other for a long time, and our backgrounds are quite similar. In our past conversations, Shi Yang has been very open about copying, but in his mind, copying is just a means. It's simply to allow the team, as a latecomer, to avoid detours, quickly make up for shortcomings, and provide everyone with a usable tool.

A triangular wheel is beautiful, but I wish it were round.

But standing today, everything that could be copied has been copied. What's more important now is to test the team. We delved deep into Shi Yang's understanding, and he summarized for me why, in his mind, AI programming has reached the 2.5 era today, and what the 3.0 form will look like. I also strongly agree.

The current form of Cursor or Trae is that we build AI into one tool, and we find that we actually use multiple tools. Should we build more tools into AI, rather than having each tool have an AI?

The ultimate AI coding product will definitely not look like Trae, it will not look like Cursor, and it will not look like Claude Code. It still has a long way to go.

If you want to understand AI programming, or where top AI tools will go next, what kind of work they will automate, then you shouldn't miss this video. Let's begin.