AI generates code to avoid the pit: the database operation code must not be directly executed online

1. Preface
The whole process of WordPress tag synchronization script debugging, database damage, and data recovery has made me deeply realize that the AI generation code is extremely efficient, but it definitely does not have the security of the production environment, especially the code that operates the database. Blind execution will cause devastating data accidents.
Many developers are accustomed to relying on AI to quickly generate scripts, repair code, and adapt versions, but ignore the limitations of AI: no business cognition, no environmental adaptation, no risk judgment, and like redundancy optimization. This article combines my real stepping accidents to deeply analyze the safety hazards of AI code, and gives a specification for review, testing and implementation that can be implemented.
Reference: WP 6.9 Label Synchronization Script In WP 7.0 Failure to Completely Troubleshoot and Solve Records
Reference: Alibaba Cloud RDS database is damaged by misoperation, complete backup and recovery practical pit guide

2. Real accident review caused by this AI code
All the data problems this time are all derived from the direct execution of the unaudited AI generation code, and a total of 4 types of serious accidents:

1. AI blindly adds high-risk deletion logic, resulting in large-scale data loss
   My original script only does read-only detection + adds English tags, zero deletion, and zero modification logic. In order to ‘optimize the code and clean up dirty data’, AI actively added the logic of full database circular query and batch delete without language tags.
   Under the large amount of 8000+ tags, the logic is extremely low in query efficiency, resulting in a stuck script; after forced termination, a large number of Chang English labels have been mistakenly judged to be dirty data deleted, and there are only 2 English labels left from 8000+, and the data is almost completely destroyed (as shown in Figure 1).
2. AI version adaptation error, generate incompatibility code
   The AI misjudged the bottom-level API of WP7.0 to be fully reconstructed, abandoned the original stable script, and actively rewrites the Polylang translation binding logic.
   After rewriting the code, a series of problems such as API parameter error, label no language attribution, false translation binding, background count failure, etc., the original normal function is completely paralyzed.
3. AI logic is messed up, new redundant data is added
   Some AI generates script logic loopholes, which cannot accurately determine the translation relationship, and repeatedly creates Chinese labels incorrectly, resulting in an abnormal increase in the number of Chinese labels by 100+, breaking the balance of the original data (as shown in Figure 2).
4. AI cache cognitive lack, blindly rewrite valid code
   This core fault is a false script caused by the cache residue. The AI cannot recognize the site cache environment, and it is directly judged to be a code compatibility problem.

3. Four core defects of AI generation database operation code

1. no environmental perception ability
   AI cannot recognize your WP version, plug-in version, cache configuration, data volume, and can only output general-purpose template code, which is very prone to version incompatibility and environment incompatibility (as shown in Figure 4).

[root@iZ23wv7v5ggZ www.shuijingwanwq.com]# php polylang-batch-zh-to-en-tags.php
PHP Fatal error:  Uncaught TypeError: reset(): Argument #1 ($array) must be of type array, int given in /data/wwwroot/www.shuijingwanwq.com/wp-content/plugins/polylang/src/api.php:429
Stack trace:
<h1>0 /data/wwwroot/www.shuijingwanwq.com/wp-content/plugins/polylang/src/api.php(429): reset()</h1>
<h1>1 /data/wwwroot/www.shuijingwanwq.com/polylang-batch-zh-to-en-tags.php(63): pll_save_term_translations()</h1>
<h1>2 {main}</h1>
thrown in /data/wwwroot/www.shuijingwanwq.com/wp-content/plugins/polylang/src/api.php on line 429

2. No business logic
   AI does not know that the core appeal of your script is ‘only add, do not delete, and do not modify the original data’, and will add cleaning, optimization, and deduplication logic as smart, and destroy the original business rules (as shown in Figure 5).
3. Risk-free control mechanism
   The deletion, update, and writing of the database code generated by AI have no pre-checking, no data backup, and no fault tolerance mechanism. Once an error is made, it is irreversible data damage (as shown in Figure 6).
4. Prefer redundant ‘optimization’, superfluous
   In order to look more perfect, the AI will actively add unnecessary cleaning, verification, and adaptation logic, and simple needs are complicated, which greatly increases the error report and risk probability (as shown in Figure 7).

4. The AI code that developers must guard to use is iron law (specific for database operation)

1. High-risk prerequisite: no backup, no execution
   Any AI code involving database writing, updating, deleting, and replacing must first complete the full database backup, which is the last line of defense and cannot be omitted.
2. Manual review, eliminating redundant high-risk logic
   The AI code must be intensively read line by line, key screening: Delete delete, WPDB write, batch clearing, data coverage and other high-risk logic, non-essential optimization and cleaning logic are all deleted, and the simplest core function is retained.
3. Priority test environment verification, direct online is prohibited
   Conditions must first run the test in the test server and local environment, observe the log output and data changes, and then deploy the production environment after confirming that there is no abnormality.
4. Prioritize the native stable code
   The old code that was originally running stably, after the version upgrade, will give priority to checking cache, configuration, and environmental problems. Don’t blindly rewrite stable code with AI.
5. Strictly control script permissions, prohibit full library operation
   Custom scripts try to only read and add new operations to prevent high-risk logic such as batch deletion, full library update, and data clearing, and avoid data damage from the root cause.

The final perception
AI is an efficient auxiliary tool, but it is definitely not a safety standard for the production environment. Code compatibility, business rationality, and data security can only be controlled by the developers themselves.
The tragic experience of spending most of the day’s investigation, repairing data, and debugging scripts confirms a sentence: AI can help you write code, but it will not help you bear the consequences of data accidents.
Note: Countless guarantees, countless apology, but not! !
In the future development, rational use of AI, prudent trial code, and adherence to the bottom line of backup is the core key to avoiding stepping on pits.