Searching for a job in the AI era, part 2: where the AI got it wrong, and the real numbers

Part 2 of a series. Part 1 covered the
setup and the first 16 days.

This post covers days 17 to 25 of my journey in search of a new job.

I left you at the end of part one with the description of my setup and some numbers.
Since then, I'm still jobless, but things seem to be moving somehow.
As for the fun part, the tech one: I've discovered more things that the AI was getting wrong,
I started using data properly, and I decided to burn more tokens of my Max subscription improving
the overall workflow.

Locations got misread, both ways

I live in Florence and I would like to keep working remotely or somewhere near-ish.
Because of this, the location filter matters more than any other,
as it is the "first line of defence" against what I'm not interested in.
The numbers I got from the first 2 weeks told me that about 40% of the roles I dropped failed on location.
That number was big enough to make me want to look closer at it.

The first question was: is there something worth saving in that 40%?

A closer analysis showed that some misreads were happening during the filtering process.
The first ones weren't even the AI's fault.
Some job sources are aggregators (websites, Telegram channels, reposters...), and
they confused the filters, letting some office jobs through.
A posting in Florence, South Carolina, even got "confused" with Florence, Italy.
The first set of fixes improved the filtering rules, so other Italian cities
only pass if there is an explicit remote statement in the posting text.
Hybrid postings get filtered out if they're not within a 20–30 minute car ride,
and, most importantly, it's now clear that US Florence is not IT Florence.

The worse misreads went the other way. The AI dropped postings, or parked them in limbo,
because it misread where the company would hire.

I noticed this because I kept checking postings myself during the job queue triage I run every morning.
One day I went through nine of them by hand, checking each company's own application form to make sure
that applying from Europe or Italy really was not an option.
Three moved from limbo to the "to apply" queue because of AI misinterpretation.

That was the part that worried me: we were dropping good jobs.

The fix changed what counts as evidence. Before a location drop, a script
now opens the company's own application form (Greenhouse, Lever, Ashby, etc.) and a cheap model looks for
real rejection reasons.
Only a restriction quoted from the company's own posting ("this position is open to UK only")
or form can drop a posting.
If the form can't be read, the posting comes to me with a note: "location check?".
The next day, another three roles moved to "to apply" because their forms had no country gate anywhere.

I honestly prefer to look at more postings than lose something good because a location is misinterpreted.

Of the 31 postings checked by 8 November, 6 were dropped and 25 came to me, most because their form couldn't be read. Some got "saved", and I even applied
to a couple of them.
I read more, and I lose less.

The sessions now argue with each other and improve my quality of life (and my CVs)

I run several Claude Code sessions, each with its own area: the night pipeline, the triage,
the applications. Since 7 November they review each other's work under written rules, and
I approve the result. There is also a dedicated post for it.

The goal was to simplify the flow and my life, providing a more refined result instead of forcing me
to merge the conversations from multiple chats into a single mental thread.
Additionally, some session scopes overlap, and each can benefit from the info stored in the other's context.

In practice the output is better: each session has to convince the others, so what reaches me
has more depth than what one session writes alone.

On the job search, CVs, cover letters and form answers now go through one to four
"council" review rounds on the applications that matter most. In the last few days those rounds caught errors that would confuse the
recipient, claims my notes didn't back, and dates that contradicted my public CV.

Let me be clear: as I said, I was reviewing every CV and cover letter "manually" or "humanly",
but it's really easy to get tired or miss something when it's the fifth CV or letter you review.
Context changes between them and you continuously go back and forth to check that the angle
of the cover letter is correct or that the claims in the CV are actually useful.
The council rounds made the result that was getting to me more refined, less prone to errors
and in need of fewer changes on my side.
Every claim still has to come from a file of facts about my work, which I write and correct
myself. On 9 November alone I added nine new facts while preparing applications.

The CVs themselves changed shape too, and the sessions argued that change through as well.
Until last week my public CV followed the same two-page rules as the ones I send. Now
the CV on this site is the long version: more space for roles, side projects, talks and
skills, with no explicit page limit besides common sense, as no one wants to read a wall of text.
It also acts as a template for every CV I send, keeping roles, section labels and dates,
and only the content inside each section changes for the job.
A reader who opens my site after reading a CV finds the same story, just less condensed.

The method has already had its first outside "review" from a reader of the post on the council.
The question was fair, and it turned into an improvement that recently went live in the council repository.
The FAQ has the details.

The night job is dead, long live the night job!

The night job was a sequence of steps: scan, then judge what the scan found, then report.
If one step broke, recovering required my intervention the next morning.

I know. It was fragile. In my defence, I was sort of more interested in starting to
apply to jobs than in making this more robust.

Now the steps follow a producer/consumer pattern that lets the queues work at any time
if something is ready to be processed.
This also allows parallel processing of the queues, which is nice and speeds things up.
If something is "wrong" in the queue, it's a non-blocking error: it just gets skipped and logged.
This keeps things always on the move without losing anything.

Everything runs every 30 minutes: not really "live processing", but it works for me.

A comment on part 1 pointed me to
ats-scrapers by kalil0321, an open-source
project that publishes dumps of the postings on Greenhouse, Lever and Ashby.
As I said earlier, postings can reach me through aggregators that cut the description and hide the company's own
page. Now, when a posting comes from an aggregator, the judge looks it up in the dump
and finds the original posting on the company's own job board (if available).
The judge reads the real description, and the location check can read the company's form.
On the first test, it found the company page for 120 of 634 postings. Thank you for the tip, commenter.

The real numbers

Part 1 said the scanner had made about 167,000 downloads. That number was honest but not
useful: it counts the same posting again every night it's still open. From 31 October the
scan also counts distinct postings.

For now, the data tell me that:

• Replies come fast or not at all. The median time to a first reply is 2 days. Two applications have had no answer after 21 days; 26 are still waiting.
• Many roles are old when I find them. The median posting was 31 days old when I applied, but I apply a median of 3 days after the scan finds it.
• Where the applications came from. Of 38 applications, 26 started on a company's own job board. Those 26 brought 7 replies and 4 of the 5 interviews.
• Location is still the main reason I drop a role: 42 of 117 drops, 36%.

All of it runs inside my Claude Max plan; I pay no extra for the night jobs.

Where my time goes

The job review keeps getting faster, and the AI suggestions more reliable.
That's my feeling at least, not a measurement, as nothing times it.

Applying is the opposite, and it surprised me. I expected it to get quicker. Especially considering
that there are posts around the internet on how to basically auto-apply to job boards.
I timed 19 applications: the median was 62 minutes each (from opening the posting to pressing submit), from 12 to 111, and 18 hours in total.
The slowest step is most often the same: my review of the CV and the cover letter, where
new facts about my own work come up and the draft changes. The recent applications took
longer, not shorter, because of letters, essays and review rounds. I hope the council
saves me rewrites over time, but only time will tell.

Applications are where I stay the gatekeeper. I said it in part 1 and it's still true: I
want to be sure of what I'm applying to and how. The AI finds, filters, drafts and reviews.
I review, fix, reject, decide, and ultimately I'm still the one who presses submit.

Numbers as of 8 November 2026, day 25.