AI Job Hunter

I Didn't Want to Build Another Job Search Tool

There are many websites in the market that help people find jobs.

So that wasn't actually the problem I wanted to solve.

What mattered to me was what happens to a job opportunity after it is found.

Is the company really the employer? Is the same opportunity posted somewhere else? Does the job actually match the person's skills? Can we find useful information about the company before applying?

That led to the idea behind AI Job Hunter.

I am building it as an opportunity intelligence system rather than another simple job-search interface.

The idea is to take messy job information and gradually turn it into something a person — or another automated workflow — can actually work with.

And I am building it one working piece at a time.

---

Where the Project Stands

Building — Version 1

The first working part of AI Job Hunter is now running.

At this stage, the system can take a job posting, preserve the original information, extract useful facts from it, and make those results available through a FastAPI API.

That may sound simple.

It is.

And that's intentional.

Before adding AI models, databases, automation platforms, and other services, I wanted to make sure the foundation worked properly.

So the first workflow looks like this:

Job Posting
     ↓
Raw Document
     ↓
Evidence Extraction
     ↓
Structured Evidence
     ↓
FastAPI API
     ↓
JSON Response

Step 1: Save the Original Job Posting

The first question I had was surprisingly basic:

What happens to the original job posting once we start processing it?

I didn't want the system to immediately read the posting, extract a few facts, and then lose the original information.

So I created a RawDocument.

Think of it as the system's original copy of what came in.

A RawDocument records things such as:

• Where the information came from
• What type of document it is
• The original content
• The source URL, when available
• When the document entered the system
• A unique ID for the document

For example, if a job posting says:

Workflow Automation Specialist. 

We need someone with Python, n8n and FastAPI. 

This is a fully remote position.

The first thing AI Job Hunter does is preserve that information as a source document.

Nothing has been interpreted yet.

We are simply making sure we know what we started with.

---

Step 2: Turn the Job Posting into Evidence

Once we have the original document, we can start asking a more useful question:

What facts can we find inside it?

This is where the Evidence model comes in.

Instead of keeping everything as one large block of text, AI Job Hunter can identify individual pieces of information.

For example:

Job Title
Workflow Automation Specialist

Technology
Python

Technology
n8n

Technology
FastAPI

Remote Policy
Remote

Step 3: Build the Evidence Extraction Pipeline

With RawDocument and Evidence in place, I needed something to connect them.

That's the job of the Job Evidence Extractor.

Its job is straightforward:

Raw Job Posting
       ↓
Read the document
       ↓
Find useful facts
       ↓
Create Evidence objects

At this stage, the extractor can identify information such as job titles, technologies, skills, and remote-work information.

The important thing is that the extracted evidence keeps a connection to the original document.

That gives us a much better foundation for the later stages of the project.

Instead of simply asking AI:

"Is this a good job?"

we can eventually build a system that has actual information to work with.

Step 4: Test the Pipeline

I didn't want to assume that the pipeline worked just because the code ran.

So I added automated tests using pytest.

The tests check the individual pieces of the system and then check that they work together.

The current test suite covers:

• Creating a RawDocument
• Creating an Evidence object
• Extracting evidence from a job posting
• Checking that the API is running
• Sending a job posting through the API and checking the response

The current result is:

5 passed

This gives us an important safety net.

As AI Job Hunter becomes more complicated, we can run the tests again and quickly see whether a change has broken something that was already working.

Step 5: Give the Pipeline an API

At this point I had a working Python pipeline.

But there was another problem.

How does another application actually use it?

I didn't want the next part of the system to need direct access to Python code.

That's where FastAPI comes in.

FastAPI allows us to put a web API around the Python application.

In simple terms, another application can send AI Job Hunter a job posting and ask:

"Can you extract the useful information from this?"

AI Job Hunter processes the request and sends the result back as structured JSON.

The current API has two endpoints:

GET  /health

POST /jobs/extract-evidence

The first checks whether the application is running.

The second sends a job posting through the evidence extraction pipeline.

Seeing the System Work

One of the useful things about FastAPI is that it automatically gives us interactive API documentation.

During development, I can open:

http://127.0.0.1:8000/docs

and interact with the API directly in a browser.

For example, I can send a job posting containing:

Workflow Automation Specialist

We need someone with Python, n8n and FastAPI.

This is a fully remote position.

The API processes it and returns structured evidence.

That gives us a simple way to see the pipeline working from outside the Python code itself.

The Architecture So Far

At this point, the first part of AI Job Hunter looks like this:

flowchart TD
    A[Job Posting] --> B[RawDocument]
    B --> C[Job Evidence Extractor]
    C --> D[Structured Evidence]
    D --> E[FastAPI API]
    E --> F[JSON Result]

The diagram shows the basic path a job posting takes through the system.

The original information is preserved first. The extractor then turns useful information into structured evidence. FastAPI makes that capability available to other applications through an API.

The Technology Behind the First Version

The first working version uses:

Python — the programming language used to build the application.

FastAPI — the framework used to expose the application through a web API.

Pydantic — used to define and validate the structured data moving through the API.

pytest — used to automatically test the application.

Uvicorn — the server used to run the FastAPI application during development.

These are the technologies I have actually used in the current implementation.

Other technologies are planned as the system grows.

What's Coming Next

The current pipeline is only the foundation.

The larger system is intended to move toward something like:

Job Sources
     ↓
Data Collection
     ↓
Raw Documents
     ↓
Evidence Extraction
     ↓
Company Research
     ↓
Duplicate Detection
     ↓
Skill Matching
     ↓
Opportunity Scoring
     ↓
Recommendations
     ↓
Application Workflow   

Technologies such as n8n, Supabase, Gemini AI, Playwright, and Next.js are part of the planned architecture.

They are not being presented as completed features yet.

I will add each one to the working system as I implement and test it.

That's an important part of this project.

I'm not documenting a finished product after the fact. I'm documenting the system while I build it.

Why Build It This Way?

There is a temptation with AI projects to start with the AI.

I decided to start with the data.

If we don't know what information entered the system, or where an extracted fact came from, it becomes much harder to trust whatever comes out at the other end.

So AI Job Hunter is being built from the inside out:

Preserve the information
          ↓
Extract the facts
          ↓
Test the pipeline
          ↓
Expose the capability
          ↓
Add automation
          ↓
Add AI reasoning
          ↓
Build the larger workflow

The objective is not simply to make AI find jobs.

The objective is to build a system that can understand an opportunity, explain why it is relevant, and eventually help move it toward an application.

This page will continue to evolve as each part of that system becomes real.