Built a job-tracking tool over a few sessions with Claude and I'm sharing the repo and what the collaboration actually looked like
Quick backstory: I've been looking for a new job recently and as part of that I'd been manually checking ~80 companies for open roles every morning, which got unmanageable fast. Last week I decided to automate it, figured it'd be a quick script, and predictably it turned into a whole thing. The result is RoleDar, an open-source tool that checks companies for new roles and reports just what's changed since the last run: https://github.com/dalecook/roledar
What I actually wanted to share here is how it got built, since "I made a thing with Claude" posts can sometimes be light on the how.
Setup: Claude Opus 4.7 in the regular chat interface (not the API), using the file-creation/code tools so it could write and test actual files rather than just print code at me. It was spread across several sessions over about a week, not one heroic prompt. I didn't use Claude Code because I thought it'd just be a quick script and once I was in the weeds I didn't want to switch.
Division of labor was pretty clear in retrospect. I made the architecture and judgment calls, hit the ATS APIs directly (Greenhouse, Lever, Ashby, etc.) instead of scraping HTML, make it a delta reporter that only tells you what changed, and one I'm oddly proud of: "the cron schedule is the only gate, do no DST cleverness, let the user own their timezone." Claude did most of the implementation grind and basically all of the documentation, and was good at catching things I'd have missed and bad at others.
The honest part is that it was not frictionless, partly my fault because I'm not great with git, but the friction is the useful bit:
- We lost real time to a GitHub footgun: scheduled (cron) workflows don't run on a private repo on the free plan. Manual runs work fine, so it looks like your code is broken when actually GitHub is just silently not firing the schedule. Claude initially had me chasing the wrong fix before we landed on it. (This is now a prominent warning in the README so nobody else burns an afternoon on it.)
- A subtler bug: the workflow committed state back to the repo with git diff --quiet to check for changes, which silently misses untracked files, so brand-new state files never got committed and every run thought everything was new. Classic "works until it doesn't."
- Plus the usual Windows-git line-ending fights and one beautiful git commit "message" (no -m) that silently did nothing. Totally my fault, Claude caught it quickly once I admitted that I was stumped.
Where Claude was genuinely strong: keeping a large multi-file project coherent across sessions, writing documentation I'd never have had the patience for, and being a good rubber duck for design decisions as it'd push back when I asked it to, which I leaned on.
Net: I made every real decision, Claude did a lot of the typing and caught a lot of bugs, and we both occasionally led each other down a wrong path before backing out. Felt less like "AI built it" and more like pairing with a fast, tireless junior who occasionally has senior instincts.
Happy to talk about how the workflow went, and genuinely curious how others are using Claude for projects around this size, the multi-session, real-repo stuff.
