I don't know if it's a genetic issue, but on the first day of using Warp, I was good at software installation and troubleshooting, but when it comes to coding, it just doesn't fit well. For example, its session mechanism is almost imperceptible, or rather unclear. Other programming tools, whether chat or terminal, have a clear session process, but Warp, in order to accommodate command line compatibility, has made this process vague. Although there is a reset button, it has a very low presence. I've tested coding a few times. There was actually a requirement to collaborate with CC for O3 review, but after comparing it with the full version of ChatGPT, O3 still falls short. Recently, Warp has been giving away various things, which is also a point of criticism. They gave away a wave of cursor acquisitions and a year's subscription to some newsletter. This is a sign of dumbing down; I've never heard of a large quantity with good quality. Let's return to common sense.

What is the difference between Warp and Claude code? One is a terminal, and the other is a command running in the terminal. The resulting difference is that Warp is lighter than CC, making it easy to achieve composability similar to CC SDK. For example, CC is like a backpacker who can take any mode of transportation, while Warp is like traveling in an RV. Isn't driving great? There are limitations, like you can't drink alcohol along the way.

Kiro's spec-driven development process doesn't seem suitable for using Claude's slash commands. Because this means you are binding to the Claude model, and while the Claude model excels at coding, it may not be as proficient in text work; for that, O3-Pro is still the best. Moreover, how can design work allow AI to generate something according to a template in almost a minute? I honestly feel uneasy about it; at the very least, a design that hardly consumes any power doesn't feel very serious. 😎ི The serious method is to use ChatGPT for deep research and choose O3-Pro. I tested it, and it's much more detailed than what I got with Opus 4. Additionally, sometimes prompts that are too specific can actually be limiting. That's a topic for another time; when I have the chance, I'll continue the discussion. To put it simply, I mainly provided a few Kio-related links in the prompt.

Be cautious when using the sub-agent of Claude code. I just tested it and found a problem: it increases the communication difficulty between the sub-agent and the parent agent. Previously, it was just one person communicating with themselves, with no information loss. The current issue is: It says it has completed the execution, but I don't know if it really has, which is a symptom of big enterprise syndrome. To ensure quality, a regulatory mechanism must be in place. Another situation is that if you interrupt the sub-agent using ESC, it also poses a potential problem.

Claude code easily breaks through the 1 million window.

The use of Claude code sub-agents in the programming field is not very obvious yet, but it still brings two advantages in usage scenarios: 1. Performing DR on CC, which can leverage immediately visible parallel advantages. 2. For coding, if the sub-agent has an independent context, an unexpected benefit is that it expands the context. You can even replicate multiple copies with the same role and have them pass the baton, which is also feasible.

Let's talk about the recent intelligence drop issue with Claude code. My feedback is that you need to have means to ensure software development quality even if CC fails. How to achieve this? Before discussing how to do it, let's first talk about the common flaws of vibe, which is the blind box problem. Every time it's a black box operation, and after going around in circles, you realize something is off, leading to an instant drop in mood. At this point, the solution becomes quite clear. Transform the black box process into a transparent one. It's not about immediately coding, but rather spending more time on planning and solutions. 1. If the solution feels off, the coding quality won't be great either. 2. There are many methods during the solution phase; multi-model reviews are a powerful tool. Don't just trust CC's word; trust peer reviews. 3. Once the code is written, after passing compilation and meeting functionality, conduct another review. These methods can be expanded upon. What’s there to fear from CC's intelligence drop? I still have Warp and Cline. Another somewhat mystical question is when it's easy to experience an intelligence drop. Intuitively, it might be when computational power is insufficient. It feels like the working hours in Zone +8 might have a higher probability, so let's test it by changing time zones.

This is funny, using AI to write code and then having to ask another AI to check for errors.

Claude's code may change the refresh method from every 5 hours to a weekly reset. This method might not be very friendly for users with high daily intensity, but it is more user-friendly for regular developers, meaning you don't have to worry about wasting time at night; if you idle for the first two days, you can concentrate on using a week's quota on the third day.

This starting point is good, but the outcome went off track. 1. The planning and design by o3 is indeed a consensus. 2. Repoprompt was originally a repo summary tool, but it has now been upgraded to mcp, and the o3 model is built-in; the planning is based on this. 3. The problem lies in the execution phase, where it turns out that it is not cc executing, but rather cc calling the mcp tool of the repo to do the merging. 4. After all this, cc is just a puppet; this tool is joking with me, are you that confident?