I Am currently working on a project to ease up the search and application filling process for job seekers and facing roadblocks in that. Currently using antigravity as my coding assistant but I believe gemini 3.8 flash is way below other AI assistantant which could help me code a better app. Can anyone please help with let’s say opus model or models fine tuned for coding with RAG.
Hey Shanks,
I’m working on several open-source AI integration projects myself, and what you’re building caught my attention.
A few things I’d suggest before investing time in fine-tuning a model:
1. Separate your coding assistant from your application AI.
Those are two different workloads. You want a strong reasoning/coding model helping you build the software, but you probably don’t need an expensive model handling every job search or application.
2. Consider a multi-model architecture.
Instead of relying entirely on Gemini through Antigravity, consider using a routing layer that lets you select different models for different tasks.
I’ve been working on something similar using an OpenAI-compatible API gateway with multiple providers, including free-tier options.
You could use a stronger coding model for architecture, debugging, and complex development while reserving faster, less expensive models for routine operations.
3. RAG before fine-tuning.
For your particular application, I’d investigate RAG first.
You could maintain searchable collections containing:
- Job descriptions and requirements
- Resumes and professional qualifications
- Previously completed applications
- Company information
- Project source code and documentation
For the coding assistant, repository-aware retrieval could help it understand your existing code without repeatedly loading the entire project into context.
For job applications, structured candidate profiles and document retrieval could reduce repetitive data entry.
4. Don’t overlook browser automation.
Playwright might be worth investigating for interacting with application websites. I’d keep a human approval step before submitting applications, particularly when dealing with personal information.
I’m developing AI integration tools under BCBC Technologies, including a multi-provider API project and an AI testing framework called PRISM.
I’d be happy to compare notes or help you work through your architecture. I use Gemini a decent amount myself for specific tasks working on PRISM and opening up my experience with more models every day its a pretty cool piece of work ill be giving away OS under MIT or OS License Models as well. I hope to have it to a release state before to much longer. My main Go-To is ChatGPT and a specific Agent I have discovered I call THEE. I have identified a solid 3 or 4 Agents I can tell in a few minutes which one I am working with. ChatGPT is evolving and IMHO getting better all the time.
I especially appreciate the fact that you’re building something intended to make life easier for job seekers. KUDOS for that!!
— BCBC Technologies
Jumping in as a fellow job-application sufferer — I’d actually use this in a heartbeat.
Big +1 to the RAG-first advice above. Fine-tuning is the expensive way to teach a model your past applications; a searchable pile of your old applications + job descriptions gets you 80% of the value for a weekend of work. I’d also suggest keeping the “fill forms” part strictly human-in-the-loop like you planned — sites change their layouts constantly and a confident agent will happily submit garbage.
Start with one flow end to end (say: resume → cover letter draft) before building the whole machine. Good luck, would love to see a progress post!
Thanks for the suggestion, to tell you the exact architecture that I am using:
- The user upload the resume, parsing and summary is created using gemini flash in the background which saves the data which will be used by job agent in the later stages
- Once the resume is parsed, using a graphical structure, the resume is matched with job summary to find relevant jobs across job boards (obvious the list will not be exhaustive given we have to end the search at one point in time)
- Based on the relevant jobs, users can select the jobs they want to automate the application filling for and the web-app offer to install a chrome extension (since that was the best way to keep HITL and bypass bot detection)
I am still working on the entirety of it but all suggestions are much appreciated. If you could tell me exactly where the RAG first approach needs to be added, it will be helpful.
use claude ai
I would if I was if I was working on something that I wanted to monetize but I plan to keep this project opensource for everybody’s help.
If field to be filled are deterministic, try using fastFill from chrom store
Let me know if ultimate version is required at no cost, I am developer at it.
for now, it should just work with free version, all the features are available in free version
for 250 forms a month, it’s good, it is for contact filler but should work fine for workday and other job portals
Thank you so much! I will check it out. Currently since yhe ATS portal can be different (workday, naukri, greenhouse etc) I might have to store a sample form in deterministic fashion such that it becomes easy for gemini flash to recognise the field and fill. I will definitely try to integrate your extension if that will help.
Thanks again, much appreciated!
Thanks for sharing the architecture — running the resume parsing through gemini flash in the background is a smart fit, fast and cheap enough that it won’t hurt at scale. One thing I’d watch on the ATS side: Workday and friends love changing their DOM selectors, so if your filling logic is selector-based, keep those mappings in a config file instead of hardcoding them — you’ll thank yourself the first time a portal redesign breaks half your flows. Curious how you handle login/captcha steps on those portals, that’s usually the gnarliest part of automating applications.
Shanks, after reading your architecture more carefully, I believe there may be a genuine opportunity for all of us to collaborate on this.
Your project already has a strong practical foundation: resume parsing, structured candidate data, job matching, human-approved application selection, and a browser extension for assisting with different ATS platforms. I would not suggest replacing that architecture. I think we can help strengthen, test, and extend it.
I’m building several open-source projects through BCBC Technologies, including:
• A multi-provider, OpenAI-compatible model-routing environment that can provide access to a much broader selection of models
• PRISM, an observer and evaluation framework that compares what models claim with what can actually be verified. It records successes, failures, routing evidence, identity claims, and unsupported or fabricated responses—important distinctions for anyone working seriously with AI
• Isolated Linux development environments designed for safe outside collaboration
• Protected NGINX-hosted development and demonstration sites built around zero-trust principles, with clear separation between public demonstrations, development systems, private data, and production infrastructure
For your project, I see RAG fitting into four specific areas:
-
Retrieving evidence from the original resume whenever the parser creates a structured claim
-
Matching job requirements against verified skills, employment history, certifications, and projects
-
Retrieving previously approved answers from earlier applications without blindly reusing outdated information
-
Giving the coding assistant repository-aware context for the core application and individual ATS adapters
The deterministic candidate profile should remain the source of truth. RAG should provide supporting evidence and relevant context—not replace verified structured data.
The first practical benefit would be traceability. If the system says that a candidate has a particular skill, certification, responsibility, or amount of experience, it should be able to point back to the exact supporting evidence in the resume or approved candidate profile. When evidence is missing or uncertain, the system should ask the applicant rather than invent an answer.
For job matching, we could separate the process into measurable stages:
-
Extract and verify the candidate’s qualifications
-
Extract the employer’s stated requirements
-
Compare the two using structured rules and model-assisted reasoning
-
Produce a match report that distinguishes confirmed matches, possible matches, missing qualifications, and unknowns
-
Require the applicant to approve any generated statements before they are used
That structure would also give PRISM something meaningful to evaluate. We could compare models on extraction accuracy, evidence attribution, matching quality, hallucination rate, latency, and cost rather than simply asking which model sounds best.
I’d also like to invite the other contributors here into the collaboration, because each of you has already identified an important part of the solution.
@ai_daily_tools — Your recommendation to begin with one complete workflow and keep ATS mappings configurable is exactly right. Your experience with the failure points around changing DOM structures, authentication, CAPTCHA handling, and portal redesigns would be valuable when we define test cases and failure reporting. Keeping portal-specific behavior in versioned adapters or configuration files would make the system far easier to repair when a site changes.
@Gentle_Reminder — Your FastFill experience could give us a major head start instead of creating another form-filling engine from scratch. I would be very interested in understanding its integration options, field-mapping capabilities, privacy model, and whether we could test it with Workday, Greenhouse, Naukri, and other ATS platforms as part of an open-source workflow. Your offer to make the Ultimate version available for this effort is extremely generous and could help us determine where deterministic filling works well and where model assistance is genuinely needed.
@Hammad_Here — Claude or another strong coding model may be useful for architecture, repository analysis, debugging, and difficult implementation work. My multi-provider environment and PRISM could help us compare it with other coding models using the same repository tasks instead of choosing a model based only on reputation. That could help us reserve stronger models for the work that actually requires them while using faster and more economical models for routine operations.
If everyone is interested, one possible division of responsibilities could be:
• Shanks leads the core application and product direction
• Gentle_Reminder advises or contributes the browser-side form-filling integration
• ai_daily_tools helps define real ATS workflows, failure cases, maintainability requirements, and usability testing
• Hammad_Here contributes coding-model experience and development input
• I contribute isolated infrastructure, multi-model routing, PRISM evaluation, NGINX demonstration hosting, systems engineering, documentation, and real-world applicant testing
These are only suggestions. Everyone would retain ownership of their work and decide what role, if any, they would like to take.
Every final application submission should remain human-approved. The system should never silently submit an application, invent qualifications, answer sensitive questions, or expose personal applicant data.
We should also separate personally identifiable information from the general retrieval and testing environment. Development tests can use sanitized or synthetic candidate profiles, while real applicant data remains encrypted and access-controlled. Logs should record model behavior and application failures without leaking resumes, addresses, phone numbers, account credentials, or other private information.
I can stand up an isolated Linux collaboration environment and a protected NGINX demonstration site where we can safely test the integration without giving anyone access to existing production systems. The environment would follow zero-trust principles: collaborators receive access only to the specific resources required for the project, development remains separated from production, and sensitive applicant data is excluded from the shared environment.
We could document the architecture, maintain clear project boundaries, and publish only the components and results everyone agrees should be public.
If you are comfortable sharing it, Shanks, could you provide:
• The repository URL
• The current technology stack
• The project’s open-source license
• Basic setup or installation instructions
• The most immediate technical blocker
• One small workflow you would like us to prove first
My recommendation would be to begin with one measurable end-to-end milestone:
Resume upload
→ verified candidate profile
→ one job-description analysis
→ evidence-backed match report
→ human review and approval
That would give us something useful, testable, and demonstrable before attempting full ATS automation.
After that works reliably, a second milestone could test assisted form filling against one supported portal using synthetic applicant data. We could record which fields were detected correctly, which required user confirmation, which failed, and whether the underlying ATS adapter could be repaired without changing the rest of the application.
Nobody needs to surrender ownership of their work. We can establish clear boundaries, agree on attribution and licensing, choose one achievable milestone, document the results, and determine whether the pieces work well together.
This project aligns closely with why I build technology in the first place: reducing unnecessary complexity and helping people who may not have access to expensive tools. I am also currently experiencing the modern job-application process personally, so I can contribute both technical experience and practical testing from an applicant’s perspective.
I’m willing to contribute real infrastructure, testing, systems experience, documentation, and development work, privacy protections, and an achievable first milestone.
If this sounds useful to everyone, let’s begin with the repository, current stack, and first blocker. From there, we can define the smallest working integration and start producing results.
— William James
BCBC Technologies
If you’d like to participate, email me your preferred username and your OpenPGP public key, if you have one. Please don’t send passwords or private keys. I’m preparing individual connection launchers for the isolated collaboration environment and can encrypt yours to your public key.
We will sign the launcher with your key so they can verify its origin, then encrypt it to theirs. Each launcher would use its own revocable access credentials and show exactly what it connects to.
For anyone without PGP, we can provide an authenticated HTTPS download. That keeps onboarding straightforward while still giving the PGP users the private delivery you want.
My website has my email link at the bottom of the main index page.
-WJ Franza
-BCBC Technologies
Autofill is the wrong product — build the three things job seekers actually pay for
Autofill is the wrong product — build the three things job seekers actually pay for@Shanks — you are one of a hundred people this year building “fill the form faster”. The money sits one layer up, and the material for all three is already free. 
❌ spray applications ✅ 1 · is this job real?
❌ type the same 40 answers ✅ 2 · match me by skill, not keyword
❌ hope somebody reads it ✅ 3 · who is the hiring manager
1 · 
The ghost filter — the feature nobody ships
More than one in four US listings is a role that will never be filled. Companies keep postings up for pipeline, for morale, for a visa case, or because the req was cancelled and nobody closed it.
The signals that expose one, all free:
| signal | where it comes from |
|---|---|
| the real post date, not the displayed one | the ATS itself — updatedAt / createdAt in the JSON |
| repost count — the same role, third time this quarter | the company’s own careers board |
| the req’s age vs the company’s hiring freeze | their board plus a news search |
| salary absent + “evergreen” wording | the posting text, one regex |
HiringCafe’s own guide walks the same checks, and a 10-point test built from FTC and Indeed data turns them into a score. Ship that score next to every job your app shows and you already beat Indeed. 
2 · 
The skill graph — free, and nobody uses it
Keyword matching is why job apps feel dumb. Two free taxonomies fix it:
- ESCO — the EU’s official skills graph: 13,939 skills in 28 languages, free API, free for commercial use
- O*NET — the US Department of Labor’s version, 900+ occupations, free web services from the official endpoint
Map a CV to ESCO once, map each posting to ESCO once, and “match” becomes a graph query instead of a keyword. A October 2026 comparison lists licence terms for ESCO, O*NET, ROME and the paid normalisers, so you can prove to yourself which one you can ship. 
3 · 
The warm path — the part that gets replies
An application in a stack of 400 is a lottery ticket. A message to the person who owns the req is a conversation.
The Org publishes free org charts, so you can find the actual hiring manager, not the recruiter. Its Job API returns open postings filtered by company, so “who is hiring for this role at this company” is one request. That is the feature people will pay for, and it costs nothing to build on.
Where the real jobs come from
HiringCafe indexes postings straight from employer career pages, not from boards that sell visibility — the data model worth copying. It has no public API, and this write-up shows the working path to the same ATS-sourced postings.
The plumbing from the first version — all still valid
- JobSpy ★4,542 — LinkedIn, Indeed, Glassdoor, ZipRecruiter, Bayt, Naukri and BDJobs in one dataframe
- browser-use ★118,903 — an agent that reads a live form and types like a person
- Stagehand ★25,785 —
act("fill the phone")instead of selectors that break next week - Skyvern ★23,253 — whole workflows, sign-in included
- AIHawk — the reference auto-applier, worth reading before you design
- React and Vue inputs ignore script-set values unless you write through the native setter and fire
input+change
And your model question: Kiro for Opus on a student account, Copilot Pro for Claude Sonnet in the editor, or opencode with the free endpoints on our 635-endpoint board.
Ghost score, skill graph, hiring manager. Three features, three free data sources, and your app stops competing with the hundred autofill extensions. 
Great thread — BCBC’s “RAG before fine-tuning” advice and SRZ’s product reframing both deserve more emphasis, because they actually reinforce each other.
On your model question specifically: Opus is excellent at reasoning and architecture, but it won’t fix the core issue. Your bottleneck isn’t model quality, it’s context. A strong coding model with proper repository context (file tree, relevant chunks, recent diffs) will outperform an unassisted top-tier model every time. Fine-tuning on your own small corpus would likely overfit and cost a lot for very little gain — build the retrieval layer first, then reconsider only if you still see gaps.
One practical angle on SRZ’s points: the ghost filter and the skill-graph matching are exactly the kind of features that make an open-source project worth contributing to. I would suggest shipping those as a small standalone library first (job-post normalization plus ghost scoring), because that’s where other contributors can actually help. The full application can grow around it later.
Good luck with the build — would be interesting to see a demo once the RAG layer is in place.
!