Stop Using AI to Apply. Start Using It to Choose.

There is a version of "AI for your job search" that is loud, crowded, and quietly hurting the people who use it: point a bot at a job board and let it fire off hundreds of applications.

There is a second version almost nobody is selling: use AI to figure out which twenty roles are worth your attention, then apply to those like a human who actually wants the job.

The first one is losing. The second one is the whole opportunity.

Auto-apply is detectable, and it is being detected

The people on the receiving end have noticed. From a hiring engineer on Hacker News, in a thread about how job searches were going:

If you're using the new "AI Tools" to auto-apply, especially if there are additional questions asked in the application that you use AI to auto-fill — it's relatively easy to spot, and is an immediate disqualifier for me. (fwiw — it may seem like it's providing good/unique answers, but if you get 100 applications from people using ~similar tools, guess what, many of the answers are ~similar or follow the same format.)

Source. The mechanism is worth sitting with: individually, the output looks fine. In aggregate — which is the only way a hiring manager sees it — a hundred applications generated by five popular tools converge on the same phrasings and the same structure. You cannot see the tell from inside your own application. They see nothing but the tell.

The same dynamic is visible from the employer side of the pipeline generally: a flood of automated applications makes every individual application cheaper to ignore. Tools that promise to help you apply to 400 jobs are, collectively, the reason applying to 400 jobs stopped working.

The arms race you cannot win

The pitch for auto-apply assumes volume is the constraint. It is not, and it has not been for a while.

Employers already receive hundreds of applications per opening. Adding automation to your side does not increase your share of attention — it increases the noise that the filtering on their side is tuned to reject. You are optimizing the one variable that is not scarce, in a contest where the other party controls the filter.

Meanwhile the actually scarce things stay scarce: knowing which companies are genuinely growing a team rather than backfilling churn, knowing whether a role has been open since March, knowing which of your skills are the ones this specific market is paying for. Those are research problems. They are exactly what a language model with live data is good at, and exactly what no one has time to do manually across a thousand listings.

What "use it to choose" actually looks like

Here is the work that used to be too expensive to do by hand, and now takes a sentence.

Find the fresh slice

About half of engineering listings are more than a month old — we measured it across seven roles and the range was 48% to 62%. Filtering to the last week or two removes most of the dead weight before you spend anything.

"Show me backend roles posted in the last 7 days,
fully remote, $170k+. Group them by company."

Detect real growth, not churn

One open role tells you nothing. Five open roles across three teams tells you a company is actually expanding, which changes both your odds and what the job will be like when you get there.

"Which companies have posted 3 or more engineering roles
in the last 30 days? Show me what functions they're hiring."

Price yourself honestly

Salary conversations go badly when your number comes from a forum anecdote. They go well when it comes from the actual distribution of what is being advertised right now for your stack and level.

"What's the salary range on senior Go roles posted
in the last month? Break it down by remote vs on-site."

Find the gap between your skills and the market's

Not "what should I learn next" in the abstract — what appears in the postings you want, that is missing from your resume.

"Across senior platform engineering roles paying over
$180k, which skills appear most often? I know Python,
Postgres, and AWS. What am I missing?"

Prepare for the interview with evidence

A company's job postings are the most honest public document it produces. They reveal the stack, the team structure, and the problems being worked on, because those things have to be accurate enough to attract the right engineer.

"Pull every engineering role this company has posted
this year. What does the hiring pattern tell me about
their architecture and where the team is headed?"

Where the data comes from

None of the above works if the model is answering from training data. Ask a plain chatbot who is hiring Rust engineers and you will get a confident list of companies that were hiring whenever its training run ended.

Connecting a live source fixes this. The JobDataLake MCP server gives Claude, Cursor, and other MCP-compatible assistants direct access to 1.8M+ indexed listings from 25,000+ companies, updated hourly, with salary normalized to USD and skills and seniority extracted as structured fields. It is free for 500 searches a day and needs no signup. Setup runs about a minute: Claude Desktop, Claude Code, Cursor, or any other client.

The important property is not that it is fast. It is that the assistant is reasoning over real postings with real dates and real numbers, so its answers can be checked — and so can the ones it gets wrong.

Then write the application yourself

Having used AI to pick twenty roles worth wanting, do not hand it the last mile.

Answer the screening questions properly — the hiring engineer above was blunt about this, and he is right that those questions are the first round of the interview, not paperwork. Reference something specific about the company that you could only know by looking. Send fewer, later, better.

The advantage is not that AI writes your cover letter faster than the next candidate's AI. It is that you showed up to the right twenty conversations having done research nobody else bothered to do, and then sounded like a person.

The summary

• Volume is not your constraint. Automating it makes the shared problem worse and marks your application as machine-made.
• Selection is your constraint. It is a research problem, it is genuinely hard by hand, and it is what these tools are actually good at.
• Live data is the requirement. A model reasoning from training data will confidently describe a job market that no longer exists.
• Keep the last mile human. That is the part being evaluated.

Use the machine for the thousand listings you were never going to read. Do the twenty that matter yourself.