AI agent backlash: same script as the 2009 jQuery thread

It is 7am in Amsterdam and someone on the team has dropped a link into Slack. Ask HN: Why is the HN crowd so anti-AI? One hundred and nine points, climbing. Beneath it, four hundred comments about hallucinations, junior devs who cannot debug, and the cost of tokens. We read the first ten replies. One of us types back: I have read this thread before. In 2009. It was about jQuery.

The 2009 thread, line by line

HN in 2008 through 2010 ran a recurring argument against jQuery. The shape was always the same. You do not need a 90 kilobyte framework to call document.getElementById. Junior developers using jQuery will never understand the DOM. The selector engine is a black box. People are pasting code they do not understand. The abstraction papers over bad markup and bad design.

Some of those things were true. $().each in a tight loop did kill pages. Selector chains hid quadratic queries. A whole generation of front-end developers learned $(this) before they learned this. The complaints were not paranoid. They were correct, in the small.

And jQuery still won, in the large. It shipped most of the web from 2007 to about 2015. The complaint thread did not bend the adoption curve by one degree.

The 2026 thread, line by line

Open the current Ask HN and replace every instance of jQuery with AI agent. The arguments survive the substitution intact. The model is a black box. Vibe coders will never learn to debug. Tokens are absurdly expensive. The agent papers over bad data and undisciplined process. People are shipping code they cannot read.

Some of those things are also true. Last week the same HN front page carried Did Claude increase bugs in rsync?. That post was not a vibe. It was a claim about a real codebase, attached to a real bisect. We took it seriously in our own review queue the next morning.

So the skeptics are not wrong. They are doing what they did in 2009. They are right in the small and wrong about which black boxes win.

What the 2009 critics got right, and what they missed

Re-reading those old threads now, the skeptics had one durable point. Use it where it pays, build the boring path where it does not. The teams who shipped well in 2010 were the ones who used jQuery for the four things it actually solved (event normalisation, AJAX, animation, DOM traversal) and stayed on vanilla everywhere else. The teams who shipped badly used $() for getElementById and then complained about page weight.

The same rule applies now. The agents in our production stack that earn their cost are the ones we built like utility belts, not oracles. The ones we tried to ship as oracles got returned to the bench.

Three places we now build agents that pass the 2009 sniff test

1. Invoice chase, with a deterministic spine

The agent does not decide who to chase. A SQL query against the invoice database decides. Status = sent, due_date < today minus 7, no payment received. That returns a list. The agent reads each row, drafts an email in the client's tone, and shows the draft for one-click approval. There is a cost ceiling per day. There is a human gate. The whole thing is auditable as a flat log.

This is the part of the system a 2009 skeptic would have approved of. The hard decisions live in code you can read. The soft work, the wording, is where the model earns its keep.

select id, client_id, amount, due_date
from invoices
where status = 'sent'
  and due_date < current_date - interval '7 days'
  and paid_at is null
order by due_date asc;

2. Legacy migration scout, not migrator

When a client lands with a Drupal 7 site (end of life since January 2025, and yes, we still see them in the wild) we do not point an agent at the codebase and ask it to migrate. We ask it to read. List every custom module. List every hook implementation. List every content type and the modules that touch it. Output a flat checklist a human can verify line by line in thirty seconds each.

The migration plan still belongs to a senior developer. The agent collapses the discovery work from three days to forty minutes. A 2009 skeptic would call this glorified grep with better prose, and they would be correct, and we would still ship it.

3. RAG with citations and a refusal budget

Answers from the client's documentation come back with file paths and line numbers attached. The agent refuses to answer when the retrieval score sits below a threshold. We log every refusal. We treat the refusal rate as a product metric, not a bug.

The 2009 version of this is a search engine that returns ten links. The 2026 version is a search engine that returns one sentence, three links, and an honest I do not know when the corpus is silent. The honest I do not know is the part most teams skip. It is also the part that makes the system trustable.

The pattern under all three

None of these systems treat the model as the decision-maker. SQL decides who to chase. The migration plan is owned by a human. The refusal threshold is a number in a config file. The model writes prose, reads structure, and asks for help when it should. It is jQuery in 2026 clothes. It handles the cross-browser quirks of natural language so the rest of the stack can stay boring.

Read the HN thread again with that lens. The complaints about magic are really complaints about systems where the model was given authority it had not earned. The complaints about cost are really complaints about prompts that should have been SQL. The complaints about junior developers are really complaints about a hiring market that has not caught up with what the tool actually is.

When we built the invoice-chase agent for a Rotterdam accounting firm, the thing we ran into was exactly this: the first version let the model decide which clients to chase, and it occasionally chased people who had paid by bank transfer that morning. We moved the decision into a SQL query against the AR ledger and the embarrassing emails stopped. The model still writes the prose. It just does not pick the targets.

The smallest thing you can do today: open the last AI agent you shipped, find one place where the model decides something a SQL query could decide, and move that decision out of the prompt and into the database. Then read the 2009 jQuery thread on HN and notice you have read it before.