Problem: Why does AI coding make you more tired, not less? The problem is not the model — you have reversed "generate" and "verify" —— Trove problem library

Symptom

The most expensive lesson I ever paid was a one-and-a-half-hour bug hunt.

A flaky failure kept happening, and I was too lazy to switch models, so I asked a cheap model to investigate. It was diligent: digging through logs, tracing call chains, listing possible causes.

Every time it said "it might be here," I had to stop and verify whether it was right.

Twenty minutes a round, three rounds in, it had led me astray three times. Finally I switched to a top-tier model; it re-read the same context and pinpointed it in two minutes: "The third-level cache has no invalidation; it is serving stale values."

The problem: locating a bug is a verification task, and I gave it to a cheap model; fixing it is a generation task, which a cheap model could handle. I had the whole thing backwards. Time, money, and patience — all three went down the drain.

I kept thinking about this, and it was not a one-off mistake: it is the same trap most people fall into when they start using AI for coding.

I have watched colleagues use AI like a search engine: paste the error, the AI explains it, copy the official-docs approach, it fails; ask again, fail again. After a morning, they conclude: "AI coding is all hype.

" I have also seen the opposite: a friend who never reviewed AI-written code before committing, until the AI wrote "overwrite" where he meant "delete" — and his test assertion only checked the status code, so the tests were still green.

If any of this sounds familiar — AI seems to make everything faster, yet your time is not saved, and you feel more tired — this article is for you. It is not a tool tutorial. It is the consensus a few people reached by actually using AI coding in real projects, paying with their own mistakes: your problem is not that the model is not good enough; it is that your rhythm is wrong.

Cause

Start with a first principle: generation is cheap, verification is expensive.

AI generates a line of code in milliseconds for a fraction of a cent. Verifying that line — reading it, understanding the context, judging edge cases, thinking through how it could break — costs the most expensive resource you have: attention and time. So the total cost of AI coding is:

Whoever does the verification is the cost center. Pushing verification onto "it looks right" means every second you save now will be paid back double in future bugs.

Following this principle, almost every "using AI makes me more tired" symptom can be explained:

• The order is reversed. The right rhythm is "I think first → AI runs → I verify." Most people actually run "AI first → I look later": the AI has already generated thousands of lines before you start judging whether this is what you wanted — doing the most expensive verification work at the worst possible time.
• The models are reversed. Verification tasks (bug locating, review, gatekeeping) get cheap models; generation tasks (write per requirements, batch edits) get expensive ones. A cost mismatch: the cheap model cannot see clearly, so you verify on its behalf; the expensive model burns money on "generation," which is not where money should be spent.
• Context is not free. Every sentence you add to a prompt is a cost paid by every later turn in the conversation; the longer the resident context, the lower the cache hit rate. Someone pastes 20K lines of logs and asks "why does this fail" — blowing out the window in one move, then blaming the model for "not remembering."
• Half-baked usage. Two-line prompts, business rules never explained, no testing or observability foundation. The AI works sometimes, breaks tomorrow — and that is not the AI's fault. The foundation was never laid.

Solution

Each experience below follows the same shape: phenomenon → practice → why. None of it is one person's opinion — these are patterns that recur across many independent practices.

Experience 1: Classify tasks first — cheap models for generation, the most expensive brain for verification

Phenomenon: At first I treated the premium model like "a nice car I only drive on weekends," letting cheap models do everyday work. The result: cheap models thought everything "looked fine" — which means they verified nothing.

Practice: Split work into two kinds: generation — write code per requirements, batch refactors, produce assets; mid-tier models are the workhorse: fast, cheap, low cost of retrying after mistakes.

Verification — code review, QA, locating tricky bugs, creative gatekeeping; use the top tier, do not economize.

Why: Bug fixing is the easiest place to get this backwards, because it is really two actions: locating is verification, fixing is generation. Locating means searching the whole codebase for clues — you read far more than you write, so use the expensive model.

Once located, the fix is often three lines; a cheap model handles that easily.

Most people do the opposite: the cheap model cannot locate anything in half an hour, they get angry, switch to the expensive model and redo the whole pass — paying both ends, exactly like my "tuition" story.

Experience 2: Make "I think first, let the AI run, I check" muscle memory

Phenomenon: When interviewing for AI-coding-adjacent roles, I dread candidates who talk about AI like a news broadcast: context window, reasoning model, multimodal, MCP — one buzzword after another.

Ask "how do you actually use AI to write code, and how do you judge whether it is right?" and they go vague immediately.

Practice: The test for whether someone really uses AI is one sentence: does "I think first, let the AI run, I check/judge" appear naturally in their answers? On "the model is slow": "switch to a faster one" is a spectator;

"is it slow in reading context, reasoning, or output?

Prefill slow → trim context; reasoning slow → turn off reasoning; decode slow → cap output" is a driver.

Why: Knowing AI is not about how many model names you can recite; it is about whether you can fit AI into your engineering process. AI is an executor, not a decision-maker.

The moment you hand over the decision, efficiency is governed by it — and it does not have your context.

Experience 3: Verification needs "what to assert", not "did it run"

Phenomenon: When using AI to write tests, its default assertion is: assert resp.status_code == 200. The API responds, tests are green — but is the business right? Is the order total correct? Is the discount stacking order correct?

Were the points issued correctly?

None of that is asserted.

Practice: What you need to assert is the business result, not the HTTP status.

For a promotion "spend 300 get 50 off, 20% member discount, plus a 20-yuan coupon": assert expected = (300 - 50) * 0.8 - 20, assert the discount sequence fullcut_discount_coupon, assert whether the risk-control rule fired.

The AI cannot write these assertions — it does not know your business rules. You have to explain them.

Why: "What to assert" has never been a syntax problem; it is a business-understanding problem. Even humans often cannot state it clearly, so of course the AI guesses.

In verification tasks, the most valuable part is not having the AI write assertions — it is you explaining the business rules clearly.

The clearer you are, the more useful the AI's verification; if you are lazy, the AI guesses for you, and you clean up after it.

Experience 4: Context economics — sentence by sentence, ask "would deleting this change the behavior?"

Phenomenon: When I first wrote Agent configs, I wanted to cram every note in. The resident context grew and grew, and the model got "dumber": cache hit rate dropped, every turn was slower and pricier, and it kept getting distracted by filler.

Practice: Run one test on your resident prompt, sentence by sentence: if deleting this sentence would not change the AI's behavior, delete it now. Remove encouragements like "Be thorough and careful"; remove filler prefixes like "This is crucial because…";

remove duplicated step descriptions. Also prefer positive phrasing: "read the file before editing", not "do not forget to read the file" — negative phrasing makes the forbidden behavior more "accessible" to the model.

Why: Every sentence added to a prompt is a cost paid by every later turn; deleting one line of filler pays off across the whole session. The same rule applies to skills: if a skill does not solve a problem other skills cannot solve, delete it.

A skill library is not a collection; every skill is a resident cost.

Experience 5: Persist your rulings, so the AI does not step on the same rake every round

Phenomenon: AI code review used to annoy me: the same low-priority issue got reported as high every round. Either I ignored it (review becomes noise), or I explained it again every time (burning tokens). Until I realized: it was not the AI's fault — I had never given it a "ruling baseline."

Practice: Persist review standards in a git-tracked file: "missing auth on an internal tool downgrades to low", "generated files weight 0, business logic weight 1". When the AI hits these patterns, it must downgrade per the entry and cite it.

Pair this with calibration questions: can you construct a counterexample?

Would another reviewer pass it? Is it a defect or personal preference? Is the evidence within the blast radius?

Why: The AI has no long-term memory; every round it is guessing your standards. Write the rulings down and it stops guessing; otherwise it falls back to generic training-data standards, which usually do not match your project.

Persistence is the only way to turn the AI from "needs teaching every time" into "taught once, remembers" — this applies to Agent configs, code review, and test assertions alike.

How to start (checklist)

1. Do a task classification today: list your common AI uses, label them "generation / verification", and switch verification tasks to your best model;
2. Before asking the AI to work, spend 30 seconds writing "what I want it to do, and what the acceptance criteria are", then let it run;
3. Audit your test assertions: are any asserting "it ran" instead of "the result is right"? Add the business rules;
4. Do one subtraction pass on your resident prompt: ask "would deleting this change the behavior?" and delete everything that would not;
5. Write down the most recent "the AI keeps stepping on the same rake" ruling so it can cite it next time.

Closing: A word from the heart: I am not writing this to talk you out of using AI — quite the opposite, I use it more and more aggressively.

I just hope you do not pay the one-and-a-half-hour tuition like I did to learn that AI coding efficiency does not depend on the model; it depends on which part of the "think, run, verify" rhythm you handed to whom. Get this straight, and AI goes from "works sometimes" to "reliably saves time" — the gap is one classification, one subtraction, one act of persistence.