I want to talk to everyone from the perspective of a product engineer about how to ensure that product code can continue to iterate, be easy to maintain, and not corrupt in an era where all code is generated by AI. Recently, Mole has released its 13th version. After reviewing the entire project, there are approximately 110000 lines of Swift product code, 73000 lines of testing code, and 3347 XCTests. The testing code is far more extensive than the code that was previously guaranteed by QA when writing business in the company. I have always adhered to the view that AI should test the code written by AI, not by humans. Introducing people into this stage will actually slow down the overall progress. Based on the above experience, I want to summarize what interesting things I have done to ensure that these codes can always implement functions very obediently between me and AI. 1. Even if AI can significantly improve the speed of code production, the technical architecture, layering, and similar abstractions of the product itself, as well as where to place what can be better extended and decoupled in the future, still require the judgment of engineers themselves. This can be discussed carefully with your best AI after the first version of the project can be launched, and the corresponding architecture can be set up and recorded in a document that can be sedimented and modified, continuously following the iteration of the project. 2. At present, my biggest reliance is still on single testing. 1.0 only had 56 XCTests, but by 1.13, there were already 3347. The testing code is about 66% of the production Swift code, but the quantity is only a result of casual statistics. I usually care more about whether the testing covers areas that are easy to assume, such as changes in files after scanning, process check failures, successful command returns but the app has not been updated at all, and old tasks come back very late to overwrite new results. Normally, it's not difficult to write, but the trouble is how to update in a timely manner for situations where the results appear to be correct but are actually incorrect. 3. Especially when fixing bugs, I will leave more things behind. In addition to fixing the problem, I will also add a regression test that causes the old code to fail, and then follow the same path to find if there are similar problems. Finally, I will rewrite why it started like this in the rules. Currently, Mole has more than 1000 submissions starting with fix, of which more than 900 have been submitted for testing. Many of the tests and rules are the experience left by users after stepping on them once. Perhaps I think this is the most valuable asset of the current project. 4. Testing can remember inputs and results, but cannot remember why a certain approach was abandoned at that time, so there is still a batch of Rules in the project, mainly recording functional boundaries, historical reasons, and areas that cannot be touched. For example, why do certain types of files prefer to be missed rather than automatically deleted, why some seemingly duplicate components cannot be merged casually, and which system data does not belong to Mole. There are too many rules and it takes a lot of context, so I break them down by module and only load them when I modify the relevant code, and then turn the frequently repeated checks into skills. Bugs will look for similar issues from previous fixes, design system review to see if the interface is getting more and more messy, and release is responsible for checking signatures, notarization, remote files, and update links, so there is no need to explain to AI from scratch every time. 5. Another useful method for me is to create fewer features that are not actually useful. Nowadays, it is too easy for AI to add a setting item, compatible branch, or background monitoring, which can be written in just a few minutes. The biggest reason for the corruption of the remaining state and maintenance costs is that. For example, Mole has set some rules for new features, such as minimizing resident overhead, not adding new privileges and system permissions, not continuing to add settings if there are reasonable default values, and not expanding the scope of updates and cleaning just because a new possibility is discovered. Often, there are many features that developers consider important but users do not care about at all. It is recommended to start from users and go to requirements, and not add entities unless necessary. 6. You need to make full use of Github's ability to automate actions, which will be your last resort. In fact, after writing the code, running it, and testing it green, it is not over yet. In my project, there is also a set of checks responsible for consistency between nine languages, website generation results, Appcast, Xcode projects, and public deployment files. Make verify will run these checks and tests together, and CI will be switched to a clean machine in the cloud and restarted. At the time of release, the local code, Git commit, signed installation package, online files, and actual updates received by users are also in several different states, which I will confirm separately. I have encountered situations before where the source code is completely correct, but old files are still provided online. It is easy to think too early that it has been completed just by looking at a green result, but there is actually an error. 7. All of the above, if anything special needs to be said, is that I did not interfere with the execution process at all. Each step was automatically verified by AI, and if there were any errors, AI would automatically solve them. However, necessary process checkpoints would be set at different times for AI to verify and obtain clear results before confirming approval. The rules would be continuously iterated to maintain the freshness of existing rules, and old logic would be removed in a timely manner to synchronize and upgrade the verification logic with the business code. Perhaps, this is the ability that I believe engineers in the AI era need to cultivate more. How to make the code written by AI better maintained, clearer, and more scalable, even if it doesn't corrupt for half a year, a year, or two, and will become more obedient and more in line with the wishes of developers, also establishing a solid foundation for multi-agent collaborative development. The joy of handwriting code before is gone, but fortunately, it makes up for some of the boredom in the pure AICoding process and allows engineers to continue their professionalism.