Where career-ops is going

[santifer]

Right now, every one of us runs this search alone, in the dark. You scan boards, evaluate roles, and burn tokens doing it — and across the community, thousands of people are spending those same tokens re-evaluating the exact same listings, in parallel, blind to each other. The role you just discarded as a bad fit is someone else's dream job — and that signal just evaporates. We're all solving the same problem from zero, over and over.

That's the thing worth fixing: none of us has visibility into what the rest of us already learned.

So here's the direction. The open-source career-ops stays exactly what it is — open, local, and yours. On top of it, there's an optional, opt-in shared layer in the works: a way for the community to stop re-doing each other's work and start seeing the job market together — better matches, far less wasted effort and tokens, for everyone who chooses to join. Less "everyone alone with a flashlight," more "a shared map."

What will never change, no matter what we build:

• Your data is yours. Local stays local. The shared layer is opt-in, always — nothing leaves your machine unless you say so.
• You're always in the driver's seat. career-ops drafts; you review and you hit submit. It will never apply to jobs for you behind your back.
• It answers to you. Every decision here is made for the person doing the searching — to help you get hired. That's the whole point, and it's not up for negotiation.

The shared layer runs as a separate service (it takes real infrastructure to operate), so the core stays light and local — but it's built for this community, not instead of it.

Want to help? Scanner providers, new languages and markets, CLI support, docs and fixes are all welcome in the core. Bigger ideas — automation, integrations, the shared layer — drop them in the comments here and let's shape them together.

[drkalexander1]

Really excited about this direction. I might be reading this as more of a recommendation system than you're envisioning — correct me if I'm off base — but if so:

Cold start seems like the central tension — how are you thinking about that? The value only compounds once there's enough signal density, but early users are contributing to a mostly empty pool.

Are you envisioning similarity primarily across users (people like me preferred these role types) or across jobs (this listing is structurally similar to these others)? Or both layers?

And is the shared layer more of a live lookup at evaluation time, or an async enrichment that gets pulled periodically — like a community-built signal that supplements your local scores?

One thing I'm really hopeful about with more signal density: role title normalization across companies. "Senior MLE at Stripe" vs "Staff Engineer, ML Platform at Meta" can be the same job at the same level, but you'd never know from the titles alone. In aggregate, community evaluations could make that mapping transparent in a way no single person's search ever could.

The other angle that feels natural here is recruiter and networking signal — not just what jobs exist, but who's actually responsive, which roles are moving fast, which teams are actively hiring vs. just collecting applications. That kind of meta-signal is almost impossible to build alone but emerges quickly from a community.

[ManishVangara]

Love the "shared map" vision. One thing I'm struggling to understand is where the network effect comes from given how personalized career-ops is today.

From what I can tell, the evaluation is heavily based on a user's CV, career story, preferences, strengths, and goals. Metrics like CV match, level fit, and career alignment seem inherently profile-dependent. Even if Person A and Person B are targeting the same role, A's evaluation is still being computed against A's profile. B would still need to run the evaluation against their own profile to know whether it's a good fit.

That makes me wonder whether the real shared value comes less from the evaluations themselves and more from the metadata around them: company research, recruiter responsiveness, compensation intelligence, hidden requirements, posting legitimacy, application outcomes, etc.

Also, if human evaluations become part of the signal, how do we prevent subjective opinions and biases from being amplified across the network?

Curious how you think about those tradeoffs, because right now it feels like the most valuable outputs of career-ops are highly personalized, while the most shareable outputs are the job and market-level insights around them.

[jeffallen007]

US user willing to support

This is really great. I love what you've accomplished and your vision for expanding this open source automated job search tool.

I'd be happy to help from a US market and English language perspective. I'm a product leader and data scientist, so those would be the roles that I would be searching for (if/when seeding the shared role space with data) and/or pulling from shared data.

Recent Usage Limit Issues

Sharing data to solve "re-evaluating the exact same listings, in parallel, blind to each other" is a great idea to solve recent Claude Code usage limits I've been running up against. Right now, I actually am mostly unable to use the tool (very recently). I'm on the $20 pro plan and hesitant to upgrade to the $100-$200 Max plan.

Challenges Sync'ing Repo Changes / Updates

I haven't yet been able to keep my "personalized repo" updated with new changes you have been on-goingly making. The reason for this is that I wanted to make changes to some of the common / shared files, so I'm concerned that if I update then my changes will be overwritten. I should probably do a merge and inspect conflicts but I haven't had time to do this. Or alternatively, send my changes as feature requests for all (haven't had time for this yet). I'm also not a "software engineer" by training (my coding experience came through data science work), so merges are not my strength (lol).

The "outdated common code base" is probably an issue for me as you evolve the repo in the direction you've described (probably a challenge I can over come though).

Some questions to consider:

• How many users are actively (at least weekly, daily better) using this open source repo?
• What is their geographic coverage?
• What is their role / title focus?
• Seniority level?

I'm asking because this level of scale is likely important to being able to consistently accumulate enough data coverage that makes the shared / available job descriptions meaningful / optimal (recency is key here). I've noticed that sometimes the websearch finds stale job roles and pulling from a shared cache of data could amplify this.

Let me know if I can be of any support.

Jeff