1. The Quantitative Change AI IDEs Have Brought

AI generates a large amount of code that enters engineering work. AI IDEs are simply too good to use: from naming completion in the past, to generating function implementations, and now to delivering the code for an entire feature. You do not even need to know how to write code — through chatting you can complete many software iteration tasks. Code delivery has never been this easy.

Aggressive teams have already embraced AI IDEs. Introducing AI IDEs across the board is different from a personal experiment; the choices of B-side (enterprise) users are closely tied to the transformation of social productivity. AI IDEs are no longer an individual, local choice — they are being adopted at large scale and universally, and are gradually becoming one of the cornerstones of software development.

Only those who think critically and adapt will survive. This post is a set of my thoughts on AI IDEs; here “AI IDE” refers to Cursor and similar AI-driven coding agents that can complete tasks automatically.

2. The Relationship with AI IDEs

I found a rather interesting model to describe AI IDEs.

The development of AI has always advanced around two cores, alternating between them: rules and statistics. And the AI IDE connects these two cores.

Code is, in fact, rules: sequence, loop, and conditional judgment are all rules abstracted in advance by programming-language designers, and programmers merely combine them to implement concrete functionality. The usage scenarios of software are the dataset; statistics over historical datasets yields a model.

The AI IDE, based on model capability, designs general-purpose code expected to adapt to all scenarios, then validates the dataset in real scenarios.

Humans trained the model based on statistics, and the AI IDE obtains rules based on the model.

3. We Are Training Software

At CES 2026, Jensen Huang said in his keynote, “You no longer write software, you train software.” What he meant is that software is no longer static but is a GPU agent that can perceive and adapt.

“training the software” instantly brought back my experience of using Cursor to develop intelligent alert-handling software.

At first, I dumped all the requirements and all the features to be implemented on Cursor at once and had it generate the entire project for me. The speed and quality of Cursor’s implementation satisfied me greatly. A week’s worth of work could be done in a single morning. But as the requirements piled up, I found that communication with Cursor was always off, so much so that I kept scolding it; it would politely apologize and keep fixing, yet the problem remained.

This deviation came from:

1. My description was unclear and we never aligned, so I had Cursor generate a document first, confirm it, and then implement. But what Cursor implemented still was not what I wanted
2. The software was unusable in real testing, and Cursor and I fell into an endless loop of fixing bugs and testing

At present, what I use to resolve this deviation with Cursor is an approach similar to “training software”:

1. Split into modules first. With a clear module division, the scope Cursor needs to modify each time is small, and the results are better
2. Set an example for each module. The instruction I give Cursor most often now is “refer to project xxx” — in fact, “xxx” was also generated by Cursor. For complex projects, I first have Cursor write a working demo to validate the key modules, and use that as a reference
3. Test early — do not wait until Cursor has finished implementing before testing. I go from simple to complex, gradually giving Cursor my test feedback, and then it continues writing

Is this not “training software”? Using code that the AI IDE itself generated to train the AI IDE to produce more accurate code; feeding the AI IDE real scenarios so that it strengthens in the direction I want.

4. Who Is More Likely to Become a Super Individual

AI IDEs only raise the floor for engineers; they do not narrow the gap between engineers. Super individuals will emerge.

A super individual may be not merely a 10x engineer but a 100x or 1000x engineer — the communication cost of a distributed team is far higher than that of a single entity. A super individual can independently complete the overall delivery of a complex engineering project.

An ordinary engineer is more like a student being led by the nose by an AI IDE, fixated only on the final result rather than on software engineering’s most fundamental requirements: high cohesion and low coupling, maintainability, extensibility. A senior engineer has been through a great deal of coding practice and project engineering and has a deeper understanding of how complex projects evolve, making it more likely that they can complete an extremely complex project alone.

The capability of AI IDEs will make ordinary engineers miss out on opportunities to learn coding and practice engineering, mistaking the tool’s capability for their own. Every master has necessarily gone through a great deal of hands-on practice and grown through rapid iteration.

Therefore, I believe that, given the same rate of acceptance (learning rate) and the same degree of effort (training intensity), a senior engineer is more likely than an ordinary engineer to become a super individual. The only thing a senior engineer needs to do is step out of the comfortable path and put AI as high in priority as possible, rather than merely chatting with AI.

5. What We Can Do

Try it actively. Although everyone around me is using Cursor, I believe there are still many people who have never tried an AI IDE or this kind of super agent. Give it a try: if you can pay, buy the most expensive one; if you cannot, use the one with the most users. You may open up a new horizon and see a different world.

Delegate to agents in tiers. For some projects I hand the whole thing over to an AI IDE to complete, but for others I do not. For projects that require long-term iterative maintenance and have high reliability requirements, I only let the AI IDE handle function-level implementation and finding and fixing bugs. The degree of AI IDE adoption can differ from project to project.

Refactor the architecture to align with AI IDEs. The company has already adopted them and they are production-ready; the future has arrived — though we do not know exactly when, it is inevitable that agents will take over software development, and alignment is the only option. To let models understand better, adopt consensus-based design, narrow the scope, and align on prompts (documentation, all kinds of naming, comments). To execute better, export via MCP, add observability, and let the AI IDE quickly generate code and engineering that are directly usable.

Quantitative change leads to qualitative change, but not necessarily a good one. Finally, a concern of mine: as large amounts of AI IDE-generated code pour into code repositories, both the volume of code and its complexity are rising sharply. How is the quality of the whole project guaranteed? Is the test set complete? Will only agents have the ability to maintain it — and only one particular agent? Is the project still ours? The answer is left for you to think about.