I Built an AI Job-Hunting Pipeline: From 1,500 Listings to a Few Targeted Applications

A career-changer in his forties built his own AI pipeline to take control of his job search. This year, the system evaluated over 1,500 job listings — 1,539 were automatically filtered out — and he ended up submitting only a handful of applications. That lopsided ratio is exactly what the system was designed to achieve: not to apply more, but to apply precisely.

Why Build It From Scratch

His career background is anything but conventional: five years at Lloyds Bank, eight years as a postal worker, two years as a Windows systems administrator, and currently working on Amazon's print production line. He recently completed a BSc in Computing and IT from the Open University in the UK — but he has never held an official software developer title. He's looking for his first development role, and it has to be fully remote.

For career changers, job platforms are especially exhausting. His requirements are strict, and he's never held the title he's applying for. No suitable tool existed on the market, so he built one himself.

How the Five-Stage Pipeline Works

The system is structured in five layers, each one serving the goal of precision.

Collection and Deduplication

The first stage collects data from sixteen APIs and RSS feeds, then uses Playwright to scrape platforms that don't offer an API — including Indeed, StepStone, LinkedIn with saved sessions, and Germany's Federal Employment Agency (Arbeitsagentur). All results flow into a deduplicated store, ensuring no listing is ever processed twice. A single LinkedIn scrape can return 112 results.

Playwright is a browser automation framework developed by Microsoft that supports Chromium, Firefox, and WebKit. It can control web pages just like a real user — clicking, filling out forms, waiting for dynamic content to load. Its advantage over traditional scrapers (like requests + BeautifulSoup) is its ability to handle modern job pages that rely heavily on JavaScript rendering. "Saved sessions" means persisting cookies and local storage after login, avoiding repeated sign-ins and reducing the risk of triggering anti-bot mechanisms. RSS feeds are a lighter-weight alternative — many job platforms provide standardized RSS feeds that can deliver new listings periodically without simulating a browser. Using both approaches together maximizes source coverage.

Hard-Rule Filtering

Before any model gets involved, cheap rules do the first round of elimination: "Senior" in the title? Rejected. City outside commuting range? Rejected. Requires three or more years of experience? Not the right level. The author deliberately avoids calling any model in this step — rules are free and auditable, which is a critical engineering trade-off.

AI Scoring

Only listings that pass the hard filters are sent to a language model. The model evaluates each role against the author's "honest personal profile," including constraints that typically don't surface until an interview. For example, a customer-facing role requiring "negotiation-level written and spoken German" isn't a fit — his written German is only B1. But internal team communication in German is fine; his spoken German is C1. This level of granular self-assessment is what allows the model to make reliable judgments.

The "language model" here refers to large language models (LLMs) like GPT-4 or Claude. Their core billing unit is the token — roughly a fragment of text, approximately 4 characters per token in English, denser in other languages. Processing a single job listing via API typically consumes hundreds to thousands of tokens, and costs add up quickly at scale. This is the fundamental reason the author insists on front-loading hard rules: let rules eliminate 80–90% of obviously unqualified listings first, then let the model focus its "judgment" on the edge cases that genuinely require semantic understanding — controlling cost while concentrating model capacity where it matters.

Verifying the Real Text

This stage was, in the author's words, "learned in blood." Aggregator platform titles are often misleadingly polished: six seemingly perfect LinkedIn candidates were all eliminated once he read the actual job postings. A listing labeled "Junior" actually required five years of experience. A listing labeled "Remote" actually required three days a week in another city. The rule is now absolute — no listing enters the application queue until the real job posting has been loaded and read.

The business model of job aggregator platforms incentivizes click-through rates over information accuracy. These platforms batch-sync listings from employer websites and ATS systems via API or scraping, but syncing has latency, and platforms often reprocess titles and descriptions to improve search rankings. Common distortions include: marking a role requiring C1 German as "English OK," labeling hybrid roles with regular on-site requirements as "Remote," or advertising mid-level roles requiring five years of experience as "Junior" to attract more applicants. In an automated pipeline, these distortions are amplified — without verification, bulk applications waste enormous amounts of a candidate's time on clearly mismatched roles.

The Last Mile Belongs to a Human

The fifth stage is human. The author personally opens each URL, personally reads the listing, then writes each application according to the specific requirements of that form. No mass emails, no templated submissions. "When applying becomes expensive, you actually read" — that's precisely the effect the whole system is designed to create.

Lessons From a Career Changer

The author distilled several principles worth borrowing from his experience.

Hard-filter with rules first, then call the model. Rules cost nothing; tokens cost money. Front-loading cheap judgments is a fundamental practice for controlling costs and maintaining explainability.

Never let AI generate job listings from thin air. Ask a model "what jobs are available?" and it will fabricate convincing-looking listings — complete with plausible URLs. So this pipeline only evaluates content the scraper actually loaded. The model's job is to judge, not to find. This is an important reminder for anyone using LLMs for information retrieval.

The last mile must be human. The pipeline's goal is to make you more selective, not lazier.

For career changers, the pipeline itself is the portfolio. The author had been waiting for a project that would prove he could write software. He eventually realized the most honest evidence had been running all along: Python code with tests, real scrapers, deduplication logic, CI — a system used every day with real consequences. Related tools are open source: job-sweep is the scraping toolkit, and remote-job-engine handles search and scoring, with an SQL Query Builder running as a live online demo.

Keep the Tools in Your Own Hands

The author is looking for a junior or associate role in AI, automation, or data — fully remote, based in Germany or the UK (he is a British citizen).

The takeaway for job seekers is straightforward: before trusting a job platform, build your own tool. Platforms are not designed around your interests — but a pipeline you wrote yourself is, because you built it for you. For anyone at a career inflection point who has the technical ability, "productizing" the job search solves a real pain point and simultaneously creates the most compelling proof of skill you could offer.

Background Note

This problem is known in the AI field as "hallucination": language models learn the format and phrasing of job listings during training, so when asked to enumerate positions, they can fluently generate structurally complete content with plausible company names and URLs — but this content is fundamentally a statistical recombination, not a retrieval of real-world state. Unlike search engines, LLMs have no real-time index and cannot verify the accuracy of what they generate. Strictly limiting the model's role to "evaluator" rather than "retriever" is one of the key engineering principles for using LLMs in production systems today — and it is also the core motivation behind the rise of RAG (Retrieval-Augmented Generation) architecture: retrieve real documents first, then let the model answer based on those documents.