Code tells and leftovers

An agent wrote this component. It compiles, the tests pass, and the page works. Tap every line that gives away who wrote it.

Nobody flags generated code for one bad line. They recognize the accumulation: a comment narrating every statement, a try-catch around code that can't throw, a fallback to an empty array, a helper that already exists two files over.

There is a reason. Models learned from places where code that runs in isolation wins, so they over-defend, over-comment and over-scaffold. Everything that keeps a snippet alive on its own makes it noise inside a real codebase. These are code tells.

The pass, in order

Scan for comments, then defense, then types, names, structure, logging, tests and scope. Delete first; rewrite only where behavior must survive.

Comments. One test: does it say something the code can't? A constraint, a unit, a tradeoff, the bug it works around: keep. Narration (// increment the counter), notes to a reviewer (// Updated to use the new API), section dividers, commented-out code: delete.

Defensive theater.

• Null checks against states the types already rule out. Fix the type once.
• Catch, log, rethrow. Empty catches. catch (e) { console.error(e) } that carries on as if nothing happened.
• The silent fallback is the most dangerous item on the list. catch { return [] } turns a broken API into "No invoices yet". Tests stay green while the main path is broken.

When removing a cast, catch or fallback forces a choice, choose the loud failure (a thrown error, a failed build, a visible error state) over the quiet wrong answer.

Types and names. as any, @ts-ignore and a ! that silences instead of fixes: the compiler error was information. data, result, item say nothing; unpaidInvoices does. fetchDataV2, EnhancedButton, utils-new.ts: replace the old thing and take its name.

Structure. One-call wrappers, an options object with one caller, an interface with one implementation, a duplicate helper the model didn't search for, TODO: implement error handling.

Logs and tests. console.log("here") and ✅ Successfully initialized! are debug leftovers. Never delete, skip or weaken a test to make it pass, and be wary of a test that recomputes the implementation's own math: it passes when both are wrong.

// Fetch the data
fetch("/api/invoices")
  .then((res) => res.json())
  .then((result) =>
    setData(result))
  .catch(() => setData([]));

const res =
  await fetch("/api/invoices");
if (!res.ok)
  throw new Error(
    `Invoices ${res.status}`);
setInvoices(await res.json());

Keep the diff to what the task needed, and propose unrelated cleanup separately.

Leftovers and leaks

The second half is worse, because none of it shows up as a bug. The app works. It just ships an inspector panel to every visitor, lets search engines index /lab, and prints the session to the console.

The rule: find everything, gate what you can't prove is dead, delete only what is provably dead.

Also hunt .only( and .skip( in tests, fresh @ts-ignore, and env files tracked by git.

Review this diff for code tells and leftovers. Default fix is deletion.
- Delete narrating comments, reviewer notes, commented-out code, console.log debug lines.
- Remove catch-log-rethrow, empty catches and silent fallbacks (catch → [] or ?? default on a failed fetch); fail loudly or show an error state. Check response.ok.
- Replace any/as unknown/@ts-ignore with real types; rename data/result/item and V2 names.
- Hunt: dev panels not behind a dynamic import + dev gate, /lab /test /playground routes, logs of user/session data, secret-looking NEXT_PUBLIC_/VITE_ names (report names only), localhost URLs, TODOs on auth/payment/delete paths (quote verbatim).
Match the repo's existing style; keep the diff to the task.