A friend of mine texted me this weekend. He’s technical, he pays for Claude, and after I walked him through how Fitcheck works, he sent back the reply every founder secretly loves:
“Lots of steps for something I could automate with Claude.”
He pointed Claude at our job board, asked it to find him roles, and hit “Loading jobs…” because his assistant’s fetcher doesn’t render JavaScript. So it searched the market for him in chat instead, once, while he watched.
I love this objection because half of it is right, and the half that’s wrong is wrong in ways you only discover on day ten, not day one. Let’s take it seriously.
What an assistant genuinely does well
First, the concession, because part of this is real. If you get alerts from one or two boards and you’re looking casually, a scheduled prompt that reads those emails each morning and flags the right titles in the right places is genuinely useful. At that volume you’ll eyeball the results anyway. And assistants are excellent at the last mile: tailoring your resume, researching the company, drafting outreach, rehearsing the interview.
But notice the ceiling. An alert email carries a title, a company, a location, and sometimes a pay line. The criteria that actually decide mostly aren’t in it: only about 1 in 6 postings discloses both pay and work mode on the full posting, and the email teaser typically carries less still. Inbox triage is really a title screen. To apply your actual bar, something has to open the real posting behind each link. Hold that thought.
Discovery is more interesting, because your assistant can genuinely get into some boards now. Indeed ships an official read-only connector for Claude, and community-built servers scrape others with varying reliability and terms-of-service risk. But even the biggest board is still one board, and a connector is a queryable source, not a pipeline: you ask, it searches, and it returns what that board maintains. It keeps no standing search or alerts of its own, and it’s one board at a time, deduplicated by nobody. A connector turns “go find me jobs” into a query you can run by hand, and the distance from manual query to cross-market pipeline is everything below.
If a title screen on a light alert stream is all you need, set up the scheduled prompt. You don’t need us yet. The plan falls apart when the search gets serious. Here are the five places it happens.
1. The link in the alert isn’t the job
Job-alert emails mostly contain tracking-wrapped links back to the board that sent them, not to the employer’s actual posting. Follow one and you land on the board’s copy: a syndicated snapshot, sometimes stale, sometimes three hops from the source. An assistant lands there; it can try to push on toward the source, one posting at a time, when nothing blocks the way. A board connector starts there too: it may hand you an application link that points outward, but nothing maintains the relationship between the board’s copy and the employer’s source.
Fitcheck treats the board’s copy as a pointer, not an answer. Postings are resolved to the employer’s own career site wherever the source can be reached: the listing the company itself maintains, the one with the full description, the one that changes when the details change and disappears when the role is filled. Boards syndicate; employers publish. If a role is about to cost you an evening, the source is the version worth judging.
That resolution is genuinely hard: redirects, bot checks, expired listings, and titles that don’t quite match on the other side. “Have the agent open a browser, log in as me, and go look” works for one posting as a demo. A normal alert volume is hundreds of postings a week. Major boards actively block automated browsing of logged-in sessions, and paying agent time per posting is an expensive, fragile way to read job ads at volume.
2. A job search is a database problem wearing a chat costume
The same role arrives from four boards under three slightly different titles. Was it already scored last Tuesday? Did you skip it? Is it even still open? One in four postings is gone within a week, and one in eight postings that look open has been sitting for 90 days or more. An email can’t tell you whether the job behind it is alive. Answering that requires infrastructure that re-checks postings at the source over time.
Assistants do have memory across chats now, and you can pin your criteria in their instructions. Both are real, and neither is this. Chat memory may recall the posting you talked about; it is not a ledger that must recognize all four hundred postings it has shown you, every time, including the ones you never discussed. Deduplication is a database guarantee, not a recollection. Rebuild that properly and you’re maintaining a posting store, a seen-list, and a liveness checker. Congratulations: you’re writing a job-search service.
3. The same job should get the same score, from the same facts
Two problems hide inside “let the model judge my inbox,” and the louder one isn’t the model.
The first problem is the facts. An alert email is a teaser. Fitcheck doesn’t score the email; it works from the resolved posting at the employer’s own site: the full description, the stated pay, the declared work mode and location, and whether the role is still open. Judge from the email and you’re judging from the headline.
The second problem is the judging. Ask a model to grade 50 postings today and 50 tomorrow and the bar drifts. That’s fine for brainstorming and bad for a pipeline you’re trusting to filter things out, because a filter you don’t trust is a filter you re-check by hand, which was the whole thing you were trying to stop doing.
Fitcheck’s matching is deliberately boring: the criteria you define at setup, checked against the resolved posting, the same way every time, with the reasons shown. Change your criteria and the scores change with them; the variation belongs to you, not to the model. Postings land in three buckets: Apply, Review, or Skip. When you disagree with a call, you can see which rule fired and fix the rule, not re-roll the dice.
4. The whole point is what happens when you’re not looking
When my friend pressed his assistant on this, it gave him an answer I couldn’t have written better: it only works when he opens a chat. The job market doesn’t wait for that. Postings open and close between your sessions, and the fastest disappear within days.
An ordinary chat is a pull model: it works when you ask. A service is an interrupt model: it works while you sleep and speaks up only when something clears your bar. Scheduled assistant runs narrow this gap, and they’re worth setting up. Read the fine print, though: browser-based schedules only fire while your machine is awake with the browser open, cloud schedules don’t carry your local logged-in browser sessions with them, and these are young features with usage limits and shifting capabilities. Either way, a daily batch job assembled from prompts is still checking a moving market on a timer, without shared infrastructure watching the source.
5. Your inbox is one input. Fitcheck runs on three.
Everything above assumes the jobs you should see arrive by email. Plenty never do. Not every company sends every opening to the big boards, and many roles are published only on the employer’s own career site. Fitcheck’s second input is JobWeb’s own job board, 600,000+ live postings sourced directly from thousands of employer career sites, including companies and government agencies the alert boards never see. Your criteria run against that inventory automatically, without a single email involved.
The third input is other people. One person’s alerts cover a slice of the market; the pool covers far more of it, and one seeker’s skipped posting is another seeker’s Apply. An inbox workflow sees only what your alert providers choose to send, and every connector you add is another integration you operate, not a pool. Shared discovery isn’t something an individual setup can reproduce on its own, because its value comes from other people’s data.
Your assistant will tell you it can do all this
It will. My friend pasted an earlier version of this argument into his assistant, and it replied, in effect, “I can automate that.” Of course it did. Chat models are agreeable, and they’re judging the demo: one inbox, one morning, everything fresh. Day ten is where the plan dies, and the model has never lived a day ten.
So don’t argue with it. Ask it questions:
- How will you open the posting behind each tracking link, at volume, when the boards block automated sessions?
- Where will you keep every posting you’ve already shown me, so the same role from four boards doesn’t come back four times?
- How will you know a posting is still open before I spend an evening on it?
- Will posting number 400 get judged by the same bar as posting number 4? Show me the rule.
- What happens on the days I don’t open a chat?
A good assistant will give you thoughtful answers to all five. Read them closely: they’re plans for building infrastructure. That’s the tell. The moment the automation gets real, it stops being a prompt and becomes a service, run either by you as a second job or by a company whose whole business is running it. A prompt is not a pipeline.
Which surfaces the strongest version of the objection: skip the prompts, have Claude build the pipeline itself. It genuinely can write most of that code. But the first working version of the code is not the hard part. A job-search pipeline is an operations problem wearing a software costume: sources that change under you, bot defenses that adapt, resolution logic that needs repair the week a big employer redesigns its career site. Software you build is software you run. And even a flawless self-built pipeline starts with only the sources you connect and the data you collect. Claude can write every line and still can’t conjure an existing corpus or a shared pool.
The short version
To score this fairly, the left column is the objection’s best case: not just connectors switched on, but anything you’re willing to build and operate around them.
| Task | Assistant, plus what you build | Purpose-built service |
|---|---|---|
| Read a morning's alert emails | Yes | Yes |
| Reach the employer's original posting | Possible case by case; reliable resolution at volume requires infrastructure | Built into the pipeline |
| Know whether a posting is still open | Point-in-time checks; monitoring must be built | Monitored and rechecked over time |
| Remember every posting you've seen across boards | Not without building it | Yes |
| Score consistently, with inspectable rules | Prompt judgment drifts; rules must be built | Deterministic, reasons shown |
| Work while you're not looking | On a timer, batch | Continuously |
| See jobs that never hit the alert boards | Only via sources you connect and operate | Sourced from employer career sites |
| Learn from other job seekers | Not alone; it requires other participants and a shared dataset | Yes |
| Tailor your resume and prep interviews | Excellent | No, and it shouldn't |
The data behind the argument
The urgency numbers in this post aren’t vibes. We measure posting lifespans daily across 3,300+ employer career sites: a quarter of postings vanish within a week, and posting age is one of the clearest signals you can check before you invest an evening in an application. The rest of the series is at the job posting statistics hub.
Use both
This isn’t assistant versus service. The right setup is a pipeline: Fitcheck works from the alerts you forward, its own board, and the shared pool, resolves and scores what appears, and hands you a short list. Your assistant then does what it’s genuinely great at, turning the two or three roles worth pursuing into applications and interviews. Automate the funnel with infrastructure. Automate the craft with AI.