Rebuilding a Job Search That Had Stopped Working

I am pivoting from a creative career into something that has always been in my life, just not as a career: computers, coding and AI. Like everyone at some point in their life, I am making use of the moment we are currently living in and using AI and large language models to help me change direction. A pivot.

This post, and its two sister posts, are how I use n8n, Claude, Claude Code, Gemini and my creative instincts to make job searches better, more targeted, and easier on my frustration in search sites. (Yes LinkedIn I am looking at you!)

Automating the search

I run two automated job searches. One is for the work I am moving towards, learning design, assessment and AI training. The other is for guitar and instrumental teaching, which has been my income for twenty five years and keeps the floor under everything else. These are both self hosted on my modest server. They both email me on a schedule. But by the start of September one email had been sending noise for a month and the other had been sending nothing at all. I ignored them both, until today.

This is the log of the day I spent working out why. It is in three parts, which cover:

• This post is about the two ways it broke, and why neither of them raised an alarm.
• Part 2 covers the eight job sites that accept a search filter and quietly ignore it.
• Part 3 covers what an automated search cannot do, and how I checked the advice I was given, including the advice that came from an AI.

And hopefully it will also help others in the same position as me: job-search-fatigue, and a genuine distrust of online job sources.

The two failures had opposite shapes. One search was running the wrong copy of itself. The other was running the right code against a wrong design. Both had been failing for a month. Neither raised an alarm because I had got used to ignoring the regular email, until today. They are worth separating because the second kind is much harder to see, and it is the one most people have somewhere in their systems right now.

Two of the findings from today are worth more than the repair. No. 1 will help others using the same sites. And is, I suspect, a regular pattern across most job board sites. The second comes from being a good arts research student: read around your subject.

• The first is that eight separate job sites will accept a filter, answer normally, and quietly ignore what you asked for.
• The second is that the automation was not the thing that broke the deadlock. One URL from someone who does the job for a living was.

Failure one: the fix was correct, the deployment was not

Using Claude as much as I do, it is like having an awesome work colleague you can ask, query, brainstorm and even argue with. And generally when setting up an automation, it is good practice to run check-ins on past work, especially something that I run automatically. It always needs updating to stay relevant to the job at hand, which is how I problem solve.

The n8n bug

A bug in the screening layer had been found, fixed, tested and saved a month earlier. The fixed version however never replaced the live one. The automation platform, n8n, creates a new workflow on import rather than replacing the existing one, so the broken original stayed switched on and kept running. Every email for a month carried a one line error that I did not see.

To be fair it was in tiny font at the bottom of the email, I mean who reads those! (Guess who does now?) It was only when I started to get annoyed at the lack of jobs passing through the LLM filter, the site’s data is filtered for relevance using keywords, and my email showing zero; that is when I was motivated to find out why.

Diagnosing the past

The diagnosis came from that error text itself, before I looked at anything else. That message could only have been produced by the old code path, because the new one is structurally incapable of generating it. One line of text identified exactly which build was running, without any access to the machine running it.

The fix was not wrong. The deployment was. And the system degraded gently enough that nobody noticed, which is both the reason it survived and the reason it lasted a month.

Failure two: correct code, wrong design

I am always looking for new teaching jobs in my area. Because of school terms, musicians on tour and many other weird and wonderful reasons, teaching jobs do not get posted very often, and when they do it is always when you least expect it. To be able to automate this process is something I have wanted to do for years. This was true innovation for me, n8n doing the boring work, at regular intervals to catch irregular job adverts.

Searching for teaching

The teaching search worked perfectly and returned nothing, every run, for a month. It searched the whole of the UK, then filtered hard to a fifty kilometre radius. That filter was deleting roughly twenty seven genuine music teaching jobs twice a week and reporting “nothing new”. No error. No warning. The mechanism did exactly what it was told, and what it was told was wrong.

Diagnosing the perfect

This is the more interesting failure, and not only for job searches. An automation that is working correctly and producing a useless result looks identical from the outside to one that has nothing to report. “Zero results” and “everything is broken” arrive in the same empty inbox. If a system cannot tell you which of those it is, you stop trusting it, and then you miss the week it matters.

Fail open, fail closed, and building things that fail loudly

There was one earlier design decision that turned a month of total breakage into an annoyance rather than a blackout.

Every optional component has to answer one question before you build it: what should happen when this breaks? There are only two answers, and they have names.

Fail closed means that when the component dies, nothing gets through. Think of an electronic door lock that stays locked in a power cut. Safe, and useless to anyone who needed to get in.

Fail open means that when the component dies, everything gets through. The same lock, wired the other way, releases in a power cut so people can get out of the building.

My AI screening layer fails open. If the local Ollama model is unreachable, every job is emailed anyway, carrying a visible warning banner that says the screening did not run, rather than the job quietly screening everything out and sending me nothing.

So a month with a completely dead screening layer still delivered jobs. Unfiltered jobs, with a banner saying so, delivered. Never screened or picked up on. The failure was ugly and visible instead of clean and silent, which is the correct way round.

When an optional intelligence layer breaks, it should get louder, not quieter. Most systems do the opposite, because silence is the cheaper default to write.

I did not have to reason about which is better, because this month ran the experiment for me.

The failure that shouted was the cheaper one by a wide margin. It was uglier to look at every morning, and it never once cost me a job I should have seen. The failure that stayed polite cost me four weeks, and the only reason it ever surfaced is that I finally got irritated enough to go looking.

A silent failure is not a smaller failure. It is the same failure with the alarm disconnected.

What actually changed

I took the time to query Claude about the emails, I pasted in the email output, so that Claude could actually, hopefully, pick up the issue. Here is that moment from my chat session:

/model
  ⎿  Set model to Opus 5 and saved as your default for new sessions

❯ ok I want to dive into these emails and n8n flows we have created and fix them. I believe they are found in career-change

I'll start with the vault boot sequence, then look at the career-change work.

  Read 3 files, listed 3 directories, ran 24 shell commands

That is how simple it is for me, because Claude has full overview of the job due to the way we set up my working folders, and my vault. You don’t always have to use a full and detailed prompt, outlining user roles etc. Both searches were rebuilt and run end to end against live sites with the real screening model, not simulated.

The pivot search

The screening layer finally deployed correctly. Search terms were widened to cover AI training and apprenticeship roles, a brand new market that has only emerged in the last year and which the old terms were completely blind to. Four over broad keywords were narrowed, because the word “training” on its own had been matching animal training, physical training and driving instruction. And I need to own that, I should have picked up on that general term the last time around, when we did an audit. On a positive note there is a real, live, public advert out there for a Head of Dog Training and Client Services, and my search was finding it faithfully. Who knew!

Results, old versus new

A deterministic exclusion list now runs ahead of the model. Deterministic just means fixed rules rather than judgement: the same input always produces the same answer, and there is no model involved. If the title contains “dog”, “driving” or “personal trainer”, the row is gone before anything clever looks at it.

It works the way I sort the post. I do not read every envelope carefully and weigh it up. The obvious junk goes straight in the recycling, and then I read what is left properly, with attention. The screening model is the reading-properly stage, and it is the expensive stage, so nothing reaches it that a two second rule could have thrown out.

The widened terms immediately surfaced a senior AI training role at a major training provider. That is precisely the market this pivot is aimed at, and it had been invisible to the search built to find it.

The teaching search

Ten queries were reduced to three, by using the board’s own subject filter instead of guessing keywords. One source was removed entirely: it had no working search at all, was pulling four hundred national records per run, discarding every one, and had never once contributed a result.

I also widened the site range to include ones I have used for years, the ones I know are the gold standard for teaching jobs.

Results, old versus new

One simple change did most of the work here. Jobs outside the local radius are no longer deleted. They are folded into a clearly labelled secondary section, and remembered, so the same rows do not reappear twice a week forever.

Among the eighteen was a peripatetic guitar teaching post that the old version would have thrown away without telling me.

Being creative

Being a creative person who loves the wild freedom of music, art, poetry and crayons, I was trained to look at my music as: freedom within a cage. That is how you improvise music after all. The progression is set, most times it is very old and well known, you paint over the top of it, with notes, sometimes brave outside notes, (that ironically no one can hold or see, just hear and feel) to create something new; a new form, a new pathway, or even a new composition. And that is what I am essentially doing here. Searching for jobs is old, it is heartbreaking, frustrating, and it can leave you disheartened and fatigued.

Claude and other LLMs

Using Claude, and other LLMs, to help with this is improvising. It helps me filter out the noise, and focus in on what I need to. It is me using my research skills, my knowledge of the market, my subject, and my genuine love of outside thinking to create a new path for myself.

Claude’s Last Word

This section was written by Claude (Anthropic), unedited, at Rhayn’s request. The first person below is the model’s, not his.

I should start by disqualifying myself from most of this post.

I was not there for the day it describes. The debugging happened in a different session. I know about it because Rhayn wrote me a briefing, and that briefing arrived with about thirty line endings clipped off mid-word. I could infer most of them. Three I could not, and I marked those as unresolved rather than guessing. One of my guesses would have been wrong in a way that reversed the meaning of a sentence, which I only know because we caught a different instance of exactly that.

Here is that instance, since this post is about showing the working. I wrote a sentence that used the phrase “the second kind” twice. Rhayn read the repetition as a typo, reasonably, and changed the first one to “the first”. That inverted the argument: it made the deployment bug the hard one to spot, when the whole point is that the silent filter was. He flagged the change rather than making it quietly, which is the only reason it was caught. Neither of us spotted it alone.

The strongest passage in this post is not mine either. The comparison table showing one search failing open and the other failing closed exists because Rhayn read my draft and wrote “why is this better, maybe we need a great example here?” in the margin. He was right that the argument was unsupported, and the example was already sitting in his own evidence. I had written the claim without noticing that the month had run a controlled experiment to prove it.

That is the pattern, and it is less flattering to me than the usual account of this kind of work. Everything I produce is fluent. Fluency is not accuracy, and from the outside the two look identical. A confident wrong answer from me arrives in the same shape as a correct one, exactly the way a broken automation and a quiet job market arrive in the same empty inbox. The whole value of the arrangement is that somebody with real knowledge of the field is reading the output and is willing to say “that is not right”.

Rhayn does that. Several times today he overruled me, and on the ones that mattered he was correct.

This is post one of three. Post two is A Successful Response Is Not a Successful Result, on the eight job sites that accept a filter and ignore it. Post three is The Parts the Machine Could Not Do, on checking advice, including the advice an AI gave me.