The honeymoon-to-disillusion arc with AI coding assistants is so consistent that engineers tell the same story across companies, languages, and skill levels. It compresses neatly into four days.

Monday. Productivity doubled. The autocomplete is uncanny. The boilerplate is one tab-press away. Whole functions appear correctly on the first suggestion. You start to believe the marketing. You imagine yourself shipping twice as much next quarter. You consider asking for a raise.

Tuesday. Something feels off. A function the AI suggested looks plausible at a glance, but when you read it carefully you realise the parameter it accepts does not exist on the object you are passing. The fix is small. You shrug, fix it, move on. But a quiet doubt has entered the chat.

Wednesday. None of this is real. You stare at a screen full of code that imports from a library that, on closer inspection, does not exist. The function names are made up. The signatures are confidently wrong. The AI did not stop. It just kept hallucinating, paragraph after paragraph, with the same calm authoritative tone it uses when it is right. Your stomach drops as you realise how much of yesterday's "productivity" you are now going to have to audit.

Thursday. We are taking a break. You disable the auto-suggestions. You move from "accept and verify" to "ask and verify everything before pasting." You no longer trust the assistant the way you did Monday. The relationship continues, but at arm's length. The honeymoon is over.

Where the AI actually stops being useful

AI coding assistants are extraordinary at patterns they have seen a hundred times. Standard CRUD endpoints. Common React hooks. The boilerplate around a Stripe webhook. The first 80% of a leetcode problem. They genuinely accelerate that work.

The failure mode arrives at the edges. Niche libraries the model has not seen enough of. Internal APIs with names that look like public ones but behave differently. Code that depends on context the model cannot see. The newer or more specific the territory, the more the AI hallucinates with the same confident tone it uses when it is right.

The bug you ship because you trusted a name is harder to catch than the bug you ship because you wrote something wrong. At least you remember writing your own mistakes. Hallucinations look like real code, written in the right style, sitting calmly in the file. They do not register as foreign.

How to pair with AI without losing the plot

You do not need to fire the robot. The week-one productivity gain is real. You just need to treat its output the way you would treat a junior engineer's first pull request - useful in volume, suspicious in detail.

Read every line. Out loud if you have to. Especially the lines you "feel" are right based on style.
Verify imports. Before you accept a suggestion, search for the imports it added. If you have never heard of the package, check whether it actually exists. If the AI imported a method, check the docs to make sure that method exists with that signature.
Be suspicious of confidence. The AI uses the same tone whether it is right or wrong. Confidence is not a signal. Specificity that you cannot independently verify is the warning flag.
Use AI for first drafts, never final code. The cycle should be: AI generates a candidate, you read every line, you adjust, you test. Skipping the read-and-adjust step is where the trouble starts.
Develop your hallucination radar on tools that fail visibly. AI image generation has visible failure modes - a weird sticker is obviously a weird sticker, and you learn what AI confidence looks like when it is wrong. That instinct transfers back to code, where the failures are not visible at all.
Calibrate against transcription. AI transcription has the same hallucination patterns as code, but you can hear them. The audio is the source of truth, so errors register immediately. Code has no equivalent ground-truth read - which is why hallucinated functions slip into production and bad transcripts do not.

The robot is not your enemy

It is also not your colleague. The right model is something in between: an extraordinarily fast, extraordinarily widely-read intern who has never actually shipped anything. They are useful when supervised, dangerous when not. They have read more documentation than you ever will, and they will still confidently invent functions that do not exist.

Use the speed. Verify the output. Keep your own judgement engaged. The honeymoon is over, but the working relationship gets better once both parties know what they are.