A few weeks ago I sat down to build "will AI take my job," the tool. The honest first question I asked myself wasn't "how do I build this" — it was "why would anyone use this instead of just asking Claude?"
Because they wouldn't. Not if all I built was five text boxes (title, years of experience, skills...) feeding a prompt. That's a worse version of a chat window. Anyone can open Claude right now and get a more nuanced answer to "is my job at risk" than a form ever will.
So the product only had a reason to exist if it did something a five-minute chat session structurally can't: gather real evidence about you, not just take your word for it.
Two ways in
- Type your job title, years, skills, and location — the traditional flow.
- Or just give it your GitHub username. No login, no OAuth, no scraping. It reads your public repos — languages, topics, commit recency — and infers your actual skill profile from what you've built, not what you'd claim in a form.
A resume is what you say about yourself. A commit history is what you actually did.
Zero LLM calls, on purpose
The scoring itself never touches an LLM. No API call, no token cost, no non-determinism.
Under the hood it's a deterministic engine over a hand-curated knowledge base — 75+ roles, each broken into the specific tasks ("atoms") that make up a normal week in that job, scored against real BLS labor market data (actually fetched and verified against government projections, not fabricated). Run the same input twice, get the exact same result twice.
The part that took the most iteration
Not the engine. The honesty.
Early on, the "gap" recommendations were skill-generic — a nurse and a CTO with the same missing skill got byte-identical advice. Fixed by grounding every recommendation in a real, rotating part of that specific role's actual week.
Later, I generated a real sample PDF and actually read it back instead of trusting the code was "obviously correct." Found a card that rendered nearly empty because a skill had no matching course in the learning database — directly undermining the report's own promise. Fixed with an honest fallback instead of a hole.
Then, once it was live: a genuinely 0%-match score crashed the PDF renderer outright (react-pdf throws on a zero-length arc). That's not a hypothetical edge case — it's a real, common outcome for someone changing careers. Found it, fixed it.
Deploying it surfaced its own honesty problem: the "weekly counter" — a real, non-fabricated count of checks that week — was silently failing in production because it wrote to a local file on a filesystem that doesn't persist on serverless infra. Fixed by routing it through a Google Sheet in the background instead.
None of this is dramatic. It's the unglamorous 80% of actually shipping something, and most of what I learned building this had nothing to do with AI at all.
Try it
Career Radar — free, no signup →
Paste your GitHub username or type your title. The only thing that ever asks for an email is unlocking the full breakdown or downloading a job-posting comparison, and nothing is ever emailed to you even then.
Curious what a technical audience makes of the "evidence over self-report" framing, and whether zero-LLM-at-runtime reads as a real design decision or a gimmick. Tell me I'm wrong about something.
Top comments (2)
The evidence framing holds, but both signals you read describe the repository more than the person. The language split comes from linguist counting bytes on the default branch, so one committed bundle or a vendored directory can make a Python author read as a JavaScript one; and if commit recency comes from a repo-level field like
pushed_at, it advances on a push to any branch including Dependabot's, so a repo nobody has touched in a year keeps looking current. That is the opposite failure from the private-repo case raised above: it reads active and plausible instead of sparse, so nothing prompts the user to doubt the profile.Loved the deterministic approach—ditching LLM hallucinations for cold, hard GitHub metadata and BLS data makes the scoring far more objective than self-reported resumes.
A few quick thoughts:
Takeaway: Evidence-based skill mapping using public telemetry beats prompt engineering every time. Zero API latency and predictable outputs are huge pluses.
Suggestion: Consider adding a weight-decay factor for older commits, or supporting local git log ingestion. Senior devs often spend months in private org repos or architecture work, which can make public GitHub activity look misleadingly sparse.
Question: How do you plan to keep the job/task knowledge base updated as tech stacks rapidly evolve, without needing constant manual rule maintenance?
On the staleness & AI detection debate:
Static rules will inevitably go stale, but the logic stays fresh if you decouple deterministic execution from automated pipeline updates for the data layer. As for spotting AI vs. human code—pure syntax analysis won't cut it, but deterministic systems can flag AI usage by looking at telemetry and commit dynamics (e.g., massive 500-line single drops vs. human micro-diffs over time).
Great build!