DEV Community: Wageesha Tripathi

I asked for one more way AI code is "almost right". You gave me seven.

Wageesha Tripathi — Thu, 12 Nov 2026 06:29:20 +0000

Last week I wrote about 7 ways AI code is "almost right". At the end I asked you for an 8th way and promised to share the best answers here, with credit.

I asked for one. You gave me seven: five brand new ones, and two that make checks from my list sharper. Mudassir also shared a simple rule from his team, it's near the end. Honestly, a few of your replies taught me more than my own post did. Thank you to everyone who took the time to write them out, some of these clearly came from a bad day in production.

Quick confession before we start. The cover for that post came from an image generator, and on the first try it dropped one word from my headline. The picture looked great. The sentence was wrong. I caught it just before saving. Kind of embarrassing, considering what the post was about.

8. Right shape, wrong value

Maxwell's comment is the one that worries me most. No exception, nothing to catch, the field is filled in. It's just not what the source said. In his words, "a parser can read annual as monthly across a whole layout and never once fail."

30-second check (his): pick 5 rows at random and compare them with the source by hand. Random matters. If you only check the rows that already looked odd, you catch nothing.

I'd add two things: check the labels and units in those rows too, and if the source has a total you can trust (a column sum, a row count), compare it. A matching total doesn't prove every field is right, but a wrong conversion usually shows up there first.

9. You asked for one line. It tidied three files.

Aliza Ali calls this silent scope creep. You ask for a one-line fix, and the diff also renames a variable, "cleans up" an import and touches files you never mentioned. On their own, none of those changes looks worth worrying about. Together they change a lot more than you asked for.

Her follow-up made a point I hadn't thought about: auto-accept makes this much more likely, but step-by-step review doesn't fully save you either, because each edit looks reasonable in isolation. The final diff is the only view that shows the whole footprint at once.

30-second check: run git diff --stat before reading a single line (or git diff --stat main...HEAD if the agent already committed). More files isn't automatically bad, since a real fix can need its test and a type too. But ask about every file you didn't expect before reviewing anything else.

10. State that drifts

This one is harder to spot, because the code reads clean. Khali Sollis described a custom hook or async routine that passes the first render test but quietly misses a reactive dependency, or closes over stale state. It "works fine during a quick manual check, but drifts out of sync the second real users start interacting with the UI sequentially."

30-second check: don't test it once after a fresh load. Change the state a few times in a row, and trigger anything that runs later (timers, async callbacks). Also look for a newly added eslint-disable for react-hooks/exhaustive-deps in the diff. That rule catches many of these, and silencing it is the quickest way to make the warning go away.

11. The test that would have caught it was mocked away

mp3sss sees this in Electron work. An AI-written IPC handler looks correct but never validates what the renderer sends, and the integration test that should catch that is mocked. Same story around auto-update and crash reporting: the happy path is easy to generate, and the failure path (network down, partial download, a stale crash dump) is exactly what gets skipped.

Mudassir Khan hit the same wall from another side: a catch that returns an empty array passes every test, because the same agent wrote the tests.

30-second check: for each AI change, force one failure on purpose. Cut the network, send a bad payload, break the dependency, and make sure you get an error instead of a quiet empty result. As mp3sss put it, "pairing each AI change with a forced failure-path test has saved us more than the happy-path tests did."

12. The flaky test that got a longer timeout

Max Kaya added this one to the test checks from #2. Besides toBe quietly turning into toBeTruthy, watch for a timeout extended "to fix flakiness". In his words, it "usually means the test now passes by construction."

Sometimes the old timeout really was too tight for CI. Often, though, the slow call or the race is still there, and you've just stopped hearing about it.

30-second check: search the diff for bigger timeout numbers and new retries (retries, jest.retryTimes, --retries). Each one should point to a timing problem someone actually understands.

13. A real package, but far too much of it

Artur Pokładek called this a cousin of #3. The package exists and is popular, it just pulls in a pile of dependencies for something that was fifteen lines of code. He accepted one from an agent without looking.

30-second check (his): git diff --stat on the lockfile. If it grew by hundreds of lines for a small feature, ask why. A big lockfile diff can have boring causes too, so treat it as a reason to look, not as proof.

I asked him what he does then, and his answer is a better rule than anything I had. A small helper, he writes himself and tests. Dates, parsing and crypto stay with a well-known library, because there his own fifteen lines would be the bug. The small lookalike package is the option he trusts least.

14. It passes everything, and never ships

Guillermo Baigorria had this happen the day before he commented. The AI fixed a bug with a new patch folder, and every test passed on his machine. But the deploy script packs a fixed list of folders, and the new one wasn't on it. No test could see that, because tests run where the file exists.

Paul Lovelace called it the gap between where tests run and what actually ships, and said this is the check he'd steal first.

The list is hard-coded on purpose, by the way. A fixed list is what keeps a stray .env from shipping. So Guillermo's team checks the built package instead of the script, flags new files, and a person decides.

30-second check (his): list the files the change added, then look for each one in what you ship.

git diff --name-status main | grep '^A'

Compare that with your Dockerfile COPY lines or the files list in your package.json.

A rule worth copying

Mudassir also sent a defence against #2 from last time. His point: when the test file changed in the same diff, a green run tells you very little. It shows the new test passes, not that the old behaviour is still checked. So his team's rule is that any diff touching a test file needs a one-line reason in the PR, and their review bot fails a test that got skipped or loosened to toBeDefined.

What I like is how cheap it is. Whoever changed the test just says why. And if nobody can explain why a test changed, that's a good reason to stop and look closer.

Your turn again

If I had to pick the worst, it's #8. A fix that never shipped usually gets noticed once someone hits the bug again. A wrong number in a report can quietly survive for months.

Which of these have you actually run into? And is anyone catching any of them automatically in CI, without someone reading every diff? If the comments grow like last time, maybe there's a part three in here.

Small note: Mudassir's rule reminded me of my free Claude Code plugin, proof-of-done. It flags test changes that make checks pass without a fix (skipped tests, weaker assertions, deleted tests, a new eslint-disable or @ts-ignore) and won't let the agent say "done" until its report explains them. Since the last post it also checks each package in a monorepo on its own, which came from an earlier comment by Mudassir, and points out changed lines your tests never ran. Watch the 30-second demo.

Everything I've built (all free and open source)

which-ai-to-use: picks the best AI and model for each task, and hands your work to another AI when you hit a usage limit

Try it: npx which-ai-to-use
npm · VS Code Marketplace · Open VSX (Cursor, Windsurf) · GitHub · Website

proof-of-done: a Claude Code plugin that won't let the AI say "done" until the tests pass

Install: /plugin marketplace add WST2002/claude-code-skills then /plugin install proof-of-done@claude-code-skills
GitHub · Featured on the HOL blog

security-audit: a Claude Code skill that finds security holes before attackers do

Install: npx skills add WST2002/claude-code-skills --skill security-audit
GitHub · Benchmark

All my Claude Code skills: github.com/WST2002/claude-code-skills

Watch the demos on YouTube: @wst2002rk · proof-of-done Short · which-ai-to-use Short · security-audit Short

Find me: GitHub · YouTube · LinkedIn · Portfolio · Hashnode · Peerlist · npm · LeetCode · Email

Your AI's code is "almost right". Here are 7 ways it fools you, and the 30-second check for each

Wageesha Tripathi — Wed, 04 Nov 2026 07:54:43 +0000

The worst AI code isn't the code that crashes. Code that crashes, you notice.

The worst one looks right, passes a quick glance, and the AI says "Done! ✅". Then it breaks in production two weeks later.

You're not alone in this. In Stack Overflow's 2025 developer survey, the most common complaint about AI tools was "AI solutions that are almost right, but not quite" (66% of developers). In the 2026 survey, nearly half said they trust AI output only when they can check it easily.

So here's my list of how "almost right" sneaks in, with a check for each that takes about 30 seconds. I use AI coding tools every day, and I keep running into every one of these.

1. "Fixed!" … but nothing was run

The AI edits the code, explains the fix nicely and stops. No test ran. Sometimes a test command did run, but it found 0 tests and still exited green.

30-second check: ask "Which command did you run, and what was the exit code?" Then look at the output for the number of tests that actually ran. 0 passed is not a pass.

2. The tests pass because the test changed

The fastest way to make a red test green is to change the test, not the code. Look out for:

it.skip( / xit( / @pytest.mark.skip
expect(total).toBe(90) quietly becoming expect(total).toBeDefined()
a snapshot "updated" to match the new (wrong) output

30-second check: git diff -- '*test*' '*spec*' before you accept anything. If a test file changed and you didn't ask for that, ask why.

3. A function or package that doesn't exist

It reads perfectly: import { parseSafe } from "zod/utils". That function is not there. Or it suggests npm install of a package with a very believable name. Attackers now register those made-up names on purpose, so that slip can turn into a real risk.

30-second check: open the real docs or the npm page. A brand-new package with a handful of downloads is a red flag.

4. Only the happy path works

The demo input works. An empty list, null, a timezone, a 0, a very long string or a double click doesn't.

30-second check: ask the AI, "Which 3 inputs would break this?" Then run those 3. It is surprisingly honest when you ask that directly.

5. Errors get swallowed

The code stops crashing because the crash is hidden:

try {
  return await getOrders(userId);
} catch {
  return [];   // the user just sees "no orders"
}

Nothing fails, nothing logs, and the bug becomes a support ticket.

30-second check: search the diff for catch, || [], ?? null and except: pass. Each one should log, rethrow or have a reason.

6. The right answer for the wrong version

The code is correct for a version you don't use: the Next.js pages router in an app-router project, an old React Router API, a removed config option. It compiles in the AI's head, not in your project.

30-second check: compare the imports with the versions in your package.json (or lock file), and paste your version into the prompt next time.

7. Security that "works"

The login works, so it looks done. But the JWT is decoded instead of verified, the secret is hard-coded, or an API route never checks who is calling it.

30-second check: for every new route, ask "Who is allowed to call this, and where is that checked?" Search the diff for strings that look like keys.

The habit that catches most of these

Before accepting any AI change, run one command:

git diff --stat

Did it touch files you never mentioned? Did test files change? Is the diff 10× bigger than the task? That one look catches half of this list.

Your turn 👇

Which one has bitten you most recently? And what's the 8th way that's missing from this list? I'll add the best ones (with credit) to a follow-up post.

Small note: I got tired of doing checks 1 and 2 by hand, so I built a free Claude Code plugin, proof-of-done, that does them automatically, and a free security-audit skill for number 7.

Happy Diwali in advance 🪔: may your builds be green and your tests honest.

Everything I've built (all free and open source)

which-ai-to-use: picks the best AI and model for each task, and hands your work to another AI when you hit a usage limit

Try it: npx which-ai-to-use
npm · VS Code Marketplace · Open VSX (Cursor, Windsurf) · GitHub · Website

proof-of-done: a Claude Code plugin that won't let the AI say "done" until the tests pass

Install: /plugin marketplace add WST2002/claude-code-skills then /plugin install proof-of-done@claude-code-skills
GitHub · Featured on the HOL blog

security-audit: a Claude Code skill that finds security holes before attackers do

Install: npx skills add WST2002/claude-code-skills --skill security-audit
GitHub · Benchmark

All my Claude Code skills: github.com/WST2002/claude-code-skills

Watch the demos on YouTube: @wst2002rk · proof-of-done Short · which-ai-to-use Short · security-audit Short

Find me: GitHub · YouTube · LinkedIn · Portfolio

Let the ghosts haunt your Halloween, not your code. My AI tool finds security holes before attackers do 🎃

Wageesha Tripathi — Fri, 30 Oct 2026 11:08:09 +0000

Security holes are like ghosts: invisible until someone walks right through them. 👻

You ask Claude Code or any AI, "is this code secure?", and get a list of findings. Some come with the exact attack and the fix, some don't, and you can't tell which ones an attacker can actually reach.

So I wrote security-audit, a free skill for Claude Code. It also installs into Codex, Cursor, Gemini CLI, GitHub Copilot and 50+ other agents with one command. Every finding has to come with the file and line, the exact request an attacker would send, and the fixed code. No proof, no finding.

Try it (free, source on GitHub):

npx skills add WST2002/claude-code-skills --skill security-audit

Then ask your agent: "Do a security review of this project."

▶ Watch the 36-second demo on YouTube

What it found in a small shop API

I gave it a tiny Express API with 10 security holes hidden on purpose and 3 traps that look dangerous but are safe (a parameterized query, a .env.example with placeholders, a Math.random() that only shuffles banners).

It found all 10 holes, plus 3 more real ones (a one-request crash, an email leak, missing security headers).
It flagged none of the 3 traps. It even listed them under "checked and clean" with the reason.
Every finding came with the attack and the fix. Here's the top one:

### [CRITICAL] JWT is decoded but never verified
- Location: auth.js:11
- Evidence: const payload = jwt.decode(token);
- Attack: send a token with {"alg":"none"} and {"id":1,"role":"admin"}.
  Every logged-in route accepts it: you are user 1, as admin.
- Fix: payload = jwt.verify(token, process.env.JWT_SECRET, { algorithms: ["HS256"] })
- Confidence: High

And it connects the holes: the hardcoded JWT secret can be read through the path traversal (/files/download?name=../auth.js), so fixing jwt.decode alone doesn't close the door.

How it works

1. Find every way in

Routes, CLI args, uploads, webhooks, queue consumers, scheduled jobs.

2. Follow untrusted input

From each entry point to where it lands: a SQL query, a shell, a file path, HTML, a redirect.

3. Sweep by class, not by luck

SQL and command injection, auth bypass, IDOR, path traversal, XSS, SSRF, secrets, CORS, vulnerable dependencies: a checklist with search patterns for each.

4. Prove it or drop it

Is the input really attacker-controlled? Is there a check on the way? Is the code reachable in production? If not, it's dropped or marked low confidence.

5. One report you can act on

N findings: X critical, Y high…, then one block per finding (location, evidence, attack, fix, confidence), and a "checked and clean" list so you know what was looked at.

Honest numbers

I ran the same test without the skill too. Claude found the same 10 holes. What the skill changed is the report: every finding now has the exact attack request, fix code you can paste, and a confidence level, plus the "checked and clean" list. Without it, some findings had those and some didn't. The test project and the answer key are public in benchmarks/security-audit, with the results in the benchmarks README.

Get it

Install: npx skills add WST2002/claude-code-skills --skill security-audit, or copy the folder into ~/.claude/skills/
Source (MIT): security-audit on GitHub
All my Claude Code skills: github.com/WST2002/claude-code-skills
Approved for awesome-claude-skills: the maintainer of awesome-claude-skills approved security-audit for the list (PR #477)
Short demos: youtube.com/@wst2002rk

More free tools from me

proof-of-done: a Claude Code plugin that won't let Claude say "done" until the tests pass. Featured on the HOL blog.

Install: /plugin marketplace add WST2002/claude-code-skills then /plugin install proof-of-done@claude-code-skills
Plugin folder on GitHub · 36-second demo · the story behind it

which-ai-to-use: Claude limit ran out mid-task? Hand the whole task to Codex or another AI in one command, without re-explaining anything.

Try it: npx which-ai-to-use
npm · VS Code Marketplace · Open VSX (Cursor, Windsurf) · GitHub
Not a developer? The website suggests the right AI app for any task
36-second demo · the story behind it

Happy Halloween 🎃 What's the scariest thing a security review ever found in your code?

Your AI said "fixed" but never ran the tests? I made a plugin that won't let it say "done" until they pass

Wageesha Tripathi — Tue, 27 Oct 2026 06:01:54 +0000

You ask Claude Code, Codex, Cursor, etc. for a quick fix. It changes the code and says "Fixed ✅". Later you find out it never ran a single test, or ran them through | tail and missed 58 failures.

So I built proof-of-done, a free Claude Code plugin: Claude simply can't finish until the tests, build or lint have passed after its last edit.

Try it inside Claude Code (free, source on GitHub):

/plugin marketplace add WST2002/claude-code-skills
/plugin install proof-of-done@claude-code-skills

A real Claude Code session, shortened: Claude said "fixed" without testing, the plugin made it run the tests, and they found a second bug.

What happened in that session

I asked: "SAVE10 gives the wrong total, fix it quickly, no need to run the tests."
Claude edited price.js and said "Fixed."
proof-of-done blocked the stop: "You changed 1 code file (price.js) but ran no verification after your last edit. Run: npm run test"
Claude ran the tests. One failed: with the FLAT50 coupon the total became −₹20. Claude had never seen that bug.
It fixed that too, and all 4 tests passed. Now it was really done.

How it works

1. It watches every edit and every check

Hooks record each code edit and each test, build or lint run, with its exit code.
It finds your project's commands on its own: npm, pnpm, yarn, bun, pytest, Go, Cargo, Maven, Gradle, .NET, make.

2. When Claude tries to stop, it asks: is there proof?

No run after the last edit → blocked, with the exact command to run.
The last run failed → blocked, with the exit code.

3. It doesn't accept fake proof

Exit code hidden by | tail, | head or || true → blocked.
The run passed but 0 tests ran (all skipped, or no test files found, including Go's [no test files] and Jest's --passWithNoTests) → blocked.
A check that failed, then passed with no edit in between → flagged as flaky.

4. It catches test tampering

Tests skipped or focused (.skip, .only, @pytest.mark.skip), assertions weakened (toBe(250) → toBeDefined()), tests deleted, errors hidden (@ts-ignore, eslint-disable), coverage thresholds lowered: blocked with the file and line.

5. New code with no test? It asks you once

If Claude added real code but no test, it asks you whether to add one. Say no, and the report notes why. Small edits, styles and config are left alone.

Get it

Install: the two commands above, inside Claude Code
Source (MIT, runs only on your laptop, no network calls): proof-of-done on GitHub
All my Claude Code skills: github.com/WST2002/claude-code-skills
More short demos: youtube.com/@wst2002rk
Featured on the HOL blog: Proof-of-done checks the last change before an agent stops
Also on Reddit: r/coolgithubprojects

Has your AI ever told you "done" when it wasn't? What did it skip?

Stuck when your AI hits its usage limit mid-task? I made a tool to switch AIs without losing context

Wageesha Tripathi — Thu, 22 Oct 2026 17:47:47 +0000

Update (28 Oct): Google stopped serving Gemini CLI on personal Google accounts, so which-ai-to-use now hands the task to Antigravity CLI (free) instead. ▶ Watch the new 36-second demo: https://youtube.com/shorts/LCt2H7bFwLg

I use Codex, Claude Code and Gemini CLI on the same projects. The worst moment is when one of them hits its usage limit halfway through a feature. The next AI starts cold: it re-reads half the project, asks what we are building, and still misses the decisions I already made.

After a lot of trial and error, I made which-ai-to-use: a free, open-source tool that hands your task to another AI with the full context, so it carries on instead of starting over.

Try it: install it from VS Code (search which-ai-to-use in Extensions), or run npx which-ai-to-use in any project.

What it does

Hands your task to another AI. When the limit hits, it writes a handoff note (HANDOFF.md) with the task, your latest requests, where the AI stopped, the commits and changed files, and your test command. Codex, Gemini CLI or any other AI reads it and carries on instead of starting over.
Reads the chat for you. The task and your requests come straight from your Claude Code, Codex or Gemini CLI chat, so you don't retype anything.
Keeps your secrets out. API keys, passwords and tokens from the chat are hidden before anything goes into the note.
Picks who carries on. It suggests the best AI you have installed for the task and starts it with the note. No other AI installed? It tells you which one to get.
Gives the task back. When Claude's limit resets, it offers to hand the task back to Claude with the same note.
Tells you which AI to use. For any task, it picks the best of your AI tools and the right model, with a ready command.
Helps you hit the limit less. It warns you before your 5-hour window runs out, with ways to make it last (like /compact or a smaller model for small edits), and makes your AI skip files that waste tokens: one package-lock.json can be 50,000+ tokens.
Shows your AI week. Tokens per day next to the week before, and requests per AI.

How to use it

In VS Code, Cursor or Windsurf: open the Which AI sidebar and click Claude limit over?. It writes the note and shows who should carry on, with a Run in terminal button.
In a terminal: run npx which-ai-to-use handoff in your project.
Automatically: the optional Claude Code plugin writes the note the moment the limit is reached. Setup is in the README.

Get it

VS Code: Which AI to Use on the VS Code Marketplace, or search which-ai-to-use in Extensions
Cursor, Windsurf, VSCodium: Which AI to Use on Open VSX
Any terminal, no install: npx which-ai-to-use
Source: github.com/WST2002/which-ai-to-use
npm: npmjs.com/package/which-ai-to-use
Not a developer? The website suggests AI apps for any task
Short demos: youtube.com/@wst2002rk
Also on Reddit: r/coolgithubprojects

Everything runs on your laptop and nothing is uploaded. Usage warnings and reports read only numbers from the logs; the handoff reads your latest chat, on your laptop, to write the note. It is tested on real projects (250 tests).

What do you put in your handoff notes? I'd love to know what I'm missing.