I asked Claude Code to remove jQuery. It failed miserably

How did you have it testing its code changes? Did you tell it to use Playwright or agent-browser or anything like that?

If coding agents can't test the code as they're editing it they're no different from pasting your entire codebase into ChatGPT and crossing your fingers.

At one point you mention it hadn't run "npm test" - did it run that once you directly told it to?

I start every one of my coding agent sessions with "run uv run pytest" purely to confirm that it can run the tests and seed the idea with it that tests exist and matter to me.

Your post ends with a screenshot showing you debating a C# syntax thing with the bot. I recommend telling it "write code that demonstrates if this works or not" in cases like that.

Not surprised. The amount of jQuery pasta code from the 2010s the models are trained on make it probably look like all jQuery-specific stuff is plain JavaScript. Plus in my experience (and lucky for me as a mostly FE dev) AIs suck at all things frontend (relative to other scenarios). They just never got trained on the real, rendered output in the browser so they can't "see" and complete the feedback loop during training. Most tests in Javascript projects genereate <div>-soup - so the AI gets trained on that output as a feedback, vs. the actual browser rendered image.

You don't remove jQuery. EVER. You'll lose all the $.

> Why AI is so bad at vanilla JS and HTML, when there's no React/Vue in a project?

Because we're still paying for Brendan Eich's mistakes 30 years later (though Brendan isn't, apparently), and even an LLM trained on an unfathomably-large corpus of code by experts at hundreds of millions of dollars of expense can't unscrew it. What, like, even is a language's standard library, man?

> The moment you point it at a real, existing codebase - even a small one - everything falls apart

That's not been my experience with running Claude to create production code. Plan mode is absolutely your friend, as is tuning your memory files and prompts. You'll need to do code reviews as before, and when it makes changes that you don't like (like patching in unit tests), you need to correct it.

Also, we use hexagonal architecture, so there are clean patterns for it to gather context from. FWIW, I work in Python, not JS, so when Claude was trained on it, there weren't twenty wildly different flavor-of-the-week-fifteen-years-ago frameworks and libraries to confuse it.

If JS sucks to write as a human, it will suck even more to write as a LLM.

For any AI post, there seems like that one person for whom it worked great, and a whole lot where it didn't. Your mileage may vary...

Some things AI does well, many things it may be not worth the effort entailed, and some where it downright sucks and may even be harmful. The question is will it ever change the curve to where it is useful most of the time?

Refactoring jQuery to vanilla JS was one of my first AI dev experiences a couple of years ago and it was great.

Removing jQuery isn’t a mechanical find-and-replace task.

jQuery is often deeply intertwined with: • Event delegation patterns • Implicit DOM readiness assumptions • Legacy plugin ecosystems • Cross-browser workarounds

An LLM can translate $(selector).addClass() to element.classList.add(). But it struggles when behavior depends on subtle timing, plugin side effects, or undocumented coupling.

The hard part isn’t syntax replacement. It’s preserving behavioral invariants across the app.

AI is decent at scaffolding migrations, but for legacy front-end codebases, you still need test coverage and incremental refactors. Otherwise it’s easy to “remove jQuery” and silently break UX flows.

Removing jQuery is a great task and one I hope to implement in some of my JavaScript code bases. Thank you for this post. I don't know exactly why but I've found these agents to be less useful when it's counterintuitive from popular coding methods. Although there are many reasons why replacing jQuery is a great idea, coding agents may fail on this because so much of their training data requires jQuery. For example, many top comments on StackOverflow utilize jQuery, perhaps to address the same logic you are trying to replace.

That sounds like a realistic outcome for a real engineer, too.

Were you using --dangerously-skip-permissions or were you approving every edit and every tool use?

Which tools did it use?

If doing it directly fails (not surprising) wouldn't the next thing (maybe the first thing) to do was to have AI write a codemod to do what needed to be done then apply the codemod? Then all you need to do is get the codemod right and apply it to as many files as you need. Seems much more predictable and context-efficient.

jQuery simply turned the tables and executed a `$( ".Claude_Code" ).remove();`. Now Anthropic's services are down across several regions and emergency meetings are being held with stakeholders.

jQuery: It's Going Absolutely Nowhere™

Its a slot machine, you need to revert the changes and try again!

Seeing some of the pictures where OP says "MOTHERFUCKER" in the prompts and how simplistic some of the questions provided are gives me a feeling that CC is being used incorrectly.

My experience with 4.6 has been that it gobbles up tokens like crazy but it's pretty smart otherwise. Even the latest LLMs need a lot of context to know what they're working on, which versions to target, access to some MCP like Context7 to get up to date documentations(especially for js/ts).

My non-tech friends have a tendency to talk to AI like a person and then complain about the quality of the answers and I always tell them: ask your question, with one or two follow-ups max then start a new conversation. Also, provide as much relevant context as possible to get the best answer, even if it seems obvious. I'd expect a SWE to already be aware of this stuff.

I've been able to find obscure edge cases thanks to Claude and I've also had it produce code that does the opposite of what I asked even with a clear prompt, but that's the nature of LLMs.

This sounds like something I would have done with sed

>Not exactly rewriting a fucking C compiler in Rust from scratch or whatever they claimed it did.

Proof that web dev is harder than compiler dev ;)

For real though, I do think web has a higher cognitive load than other types of programming. I always thought it was weird, but the stuff people said was hard (making an online multiplayer game) turned out to be way easier than the stuff people said was easy (I still have no idea how React works after learning it 9 times).

Also I think compilers are surprisingly straightforward. At least unoptimized ones. It's about translation, which is basically a functional thing. Whereas frontend web dev is all about infinite global implementation details screwing each other over in real time with race conditions.

> Also, why not run "npm run test" at some point? We have tons of tests. I even have an integration test that crawls the entire fucking app recusrively link-by-link in a headless browser and reports on JS errors. CLAUDE.md has all the info.

I'm a little baffled by this post. The author claims to have "Wrote a comprehensive CLAUDE.md with detailed instructions." and yet didn't have "run the tests" anywhere? I realize this post is going to be a playground for bashing on AI but I just wish the prompt was published or even better, if it's open source let other people try. Seems like the perfect case to throw claude code in a wiggum loop at overnight.

suprise factor zero.

You're holding it wrong. I just spent 14 hours (high on coke) working with Claude to generate an agent orchestration framework that has already increased my output to 20x over just using Copilot. Adapt or you'll be left behind and forever part of the permanent underclass.

  The moment you point it at a real, existing codebase - even a small one - everything falls apart.

Not my experience. It excels in existing codebases too.

I often ask it "I have this bug. Why?" And it almost always figures it out and fixes it. Huge code base.

Codex user, not Claude Code.