Should I ever apply an AI-suggested edit without checking it?

For a read-only query or a throwaway staging site, the cost of being wrong is low. On a live database or production config, run the four steps. The check takes minutes; an outage doesn't.

Which of the four steps is the fastest?

Restating the edit in plain language. It needs no terminal and catches the most. If you can't say what the change does, you've found the problem before running anything.

How do I reproduce a bug an AI says it is fixing?

For SQL, run EXPLAIN on the slow query first. For PHP or .htaccess, trigger the broken behaviour and capture the error. If you can't reproduce it, the edit may be solving a problem you don't have.

AI-suggested edits: a four-step check before you apply

The chat panel returns a diff. You asked why the shop's product archive takes four seconds to render, and the answer is one line of SQL you didn't write and only half recognize. It looks plausible. It also touches a table with 480,000 rows on a live legacy site. Applying an AI-suggested edit you don't fully understand is how a Tuesday afternoon becomes a Tuesday evening.

The reflex is to either apply it on faith or reject it on principle. Both are wrong. An AI-suggested edit is a hypothesis, and hypotheses get tested before they ship. Here is the four-step check we run before applying anything we can't explain from memory.

Restate the edit in your own words

Before anything runs, write the edit back in plain language. If you can't, you don't understand it yet, and that is the whole signal. Say the suggestion is:

ALTER TABLE wp_postmeta
  ADD INDEX meta_key_value (meta_key(191), meta_value(100));

The plain-language restatement: "add a composite index so lookups filtering on meta_key and meta_value together stop scanning the whole table." Now the parts you glossed over surface on their own. Why 191? Why 100? The 191 is the utf8mb4 prefix-length ceiling under the older 767-byte index limit. The 100 is an arbitrary prefix on a longtext column that can't be indexed in full. Those aren't trivia. They change what the index can actually do.

An AI-suggested edit phrased as a confident one-liner hides its assumptions. Restating it is how you make them visible.

Reproduce the bug before you trust the fix

An edit fixes something. Confirm that something is real, and that it is the thing you think it is. For a slow query, that means running EXPLAIN before you touch anything:

EXPLAIN SELECT post_id FROM wp_postmeta
WHERE meta_key = '_wc_average_rating' AND meta_value > '4';

The output that matters:

type: ALL
possible_keys: meta_key
rows: 481204
Extra: Using where

type: ALL and 481,204 rows scanned confirms the full-table scan. The AI-suggested edit now has a problem it is demonstrably solving. Worth noting in passing: meta_value is text, so > '4' is a string comparison, not a numeric one. That is a second bug the index won't fix, and you only see it because you read the query closely enough to reproduce it.

If the EXPLAIN had shown type: ref and a few hundred rows, the edit would be solving a problem you don't have, and you'd have caught it here for the cost of one read-only query. Reproduction is cheap. Regret is not.

Trace what else touches the change

A change has a blast radius. Find it before you apply, not after. Start with what already exists:

SHOW INDEX FROM wp_postmeta;

WordPress ships wp_postmeta with indexes on post_id and meta_key already, as the database description spells out. A new composite index is not free: every INSERT and UPDATE to the table now maintains another B-tree, and on a write-heavy store that cost is real and permanent. You are trading write speed for read speed. That trade might be correct here. The point is to make it knowingly.

The same step applies outside the database. If the AI-suggested edit is a rewrite rule in .htaccess, ask what other rules sit above it and whether the order changes. If it is a line in wp-config.php, ask which plugins read that constant. The discipline is identical: name everything downstream of the change before it lands.

On MySQL 5.6 and earlier, or on any table still using MyISAM, ALTER TABLE ... ADD INDEX copies the entire table and blocks writes for the duration. On a 480k-row wp_postmeta that can mean the storefront throwing errors for a minute or more. Check the engine and version first. MySQL's online DDL is what makes this operation safe, and it is not universal.

Apply with an exit already in place

The first three steps are about understanding the edit. The fourth is about surviving it being wrong anyway. Before you run the change, make sure you can undo it without thinking. For a schema change, that means a snapshot of the table definition and a written DROP INDEX rollback line, kept next to the ALTER. For a file edit, it means a copy of the original committed somewhere you trust, not a .bak you'll forget exists.

An exit you have to improvise under pressure is not an exit. The time to write the rollback is while you are calm, before the edit goes near production.

When we built Pier we ran into this exact thing. The way we ended up handling it was to make every edit, AI-suggested or hand-typed, land as an entry in version history, so the revert is one click and the diff stays readable. The MySQL editor shows the EXPLAIN plan and the existing indexes in the same panel as the suggestion, which is mostly steps two and three with less tab-switching.

Next time the chat hands you a line you can't read, run step one on its own: restate the edit in plain language before you do anything else. If the sentence won't come, you have found your answer for free.