Where surprise bugs come from

Assistants don't write worse code than people. They write plausible code faster than people can check it, and plausible-but-unverified is where surprise bugs live. After a lot of extension work built this way — ours and others' — the failures cluster into seven patterns. Each has a cheap countermeasure. None of the countermeasures is new; assistants just removed the old excuse (time) for skipping them.

01 / 07

Code you can't explain

If you can't state what a change does and doesn't do, you didn't review it — you witnessed it. Habit: review against the spec, not against your mood. No spec, no merge.

02 / 07

The helpful refactor

Ask for a button, receive a button plus a "cleaned up" auth module. Assistants drift into adjacent code with the best intentions, and the surprise bug ships in the part you didn't ask for. Habit: explicit non-goals. "Do not touch X" belongs in every request, and a diff that wanders is a diff you reject even when it's pretty.

03 / 07

Tests that agree with the code

Ask the author of the code for tests and you'll get tests that pass — they were written by looking at what the code does. They verify the implementation, not the intent. Habit: acceptance criteria come from the spec, before the code exists. Best of all: for any bug fix, demand the test that fails on the old code first. A regression test that never failed proves nothing.

04 / 07

Sunny-day engineering

Assistants write the happy path with conviction. What happens when the file is missing, the network times out, the response is garbage? Unless you said, the answer is "something," discovered in production. Habit: failure behaviour goes in the spec. The words that save you are fails closed and keeps last-good. A fetch that validates before it overwrites is one line of intent; recovering from the alternative is a bad afternoon.

05 / 07

Goldfish memory

Every assistant session starts from nothing. Left unmanaged, each one reinvents your conventions, re-decides your decisions, and disagrees with last month. The bugs this produces are the subtlest — two features, same repo, different assumptions. Habit: the repo is the memory. Decisions, conventions, and handovers live in files the next session reads first. If it's only in the conversation, it's already lost.

06 / 07

The big bang

A thousand-line change that "does the whole feature" cannot be reviewed, only trusted. Habit: small mergeable increments, pushed early. If the work gets cut off halfway, half should already be safe on main — and reviewable at the size a human actually reads.

07 / 07

"Tests pass" is not "it works"

The most modern bug of all: everything green, deploy skipped, or deployed but never loaded in a browser, or loaded but the config the tests faked isn't the config production has. Habit: verify at the boundary the user touches. Load the page. Click the button. Curl the endpoint. The definition of done is observed behaviour, not a green checkmark.

The theme

Every pitfall is the same pitfall: letting output outrun verification. The discipline that prevents it fits on an index card — spec first, small diffs, tests from intent, fail closed, write it down, check the real thing. Owners of long-lived systems have always worked this way. Assistants don't change the discipline. They just make it astonishingly cheap to follow — and astonishingly easy to skip.