Building an Autonomous Job-Application Agent: A Multi-Model Architecture for ATS Form Automation

I applied for this job using AI. Here's what I built. Opendoor's challenge: "Apply to this AI Ops Engineer role using ONLY AI and we'll fast-track you to interview." So, I built a fully autonomous job application agent from scratch in less than 24 hours. The Architecture Each layer uses the right model for the job: → Claude Haiku — JD parsing + form field mapping (classification, lowest cost) → Claude Sonnet — skill gap analysis + cover letter (reasoning required) → Claude Opus — tailored resume generation (quality matters here) → Playwright — browser automation, form filling, file uploads The Hard Engineering Problems 🔹 ATS form detection — built a generic extractor capturing role="combobox", role="radiogroup", hidden file inputs, and ARIA widgets across Rippling, Greenhouse, Lever and Workday 🔹 Two-stage field mapping — 34 deterministic rules handle known fields (name, email, pronouns, EEO) with zero API cost. Only custom/unknown fields go to Claude. Eliminates hallucination where it matters most 🔹 Combobox option reading — options don't exist in the DOM until activated. Built a function that reads aria-controls, opens the field, reads up to 50 real options, matches via exact → prefix → partial priority 🔹 Hidden file inputs — 3-attempt uploader: direct set_input_files → JS visibility injection → Playwright CDP file chooser intercept 🔹 Human-in-the-loop checkpoint — agent pauses after submission for Cloudflare verification, then resumes on terminal Enter 🔹 Full audit trail — every Claude prompt, response, and field fill logged to structured markdown. Full replay of every decision Skill Gap Analysis Before generating documents, the agent classifies every JD requirement as HAVE / PARTIAL / MISSING — and suggests a concrete project with deliverable and first step to close each gap. Cost per run: ~$0.20. Runtime: under 3 minutes. What's Next → ATS-specific adapter modules with pre-mapped selectors → Run-to-run field pattern learning to eliminate repeat LLM calls → Reliability benchmarking across ATS platforms → Checkpoint/retry recovery for dynamic DOM and session failures Code drops once the next improvements land. Follow to stay updated. #AIEngineering #LLM #Anthropic #Claude #Playwright #AgentArchitecture #Python #Automation #AIAgents #AIops

Fact-Check

This is a personal project writeup, so most of it is unverifiable first-hand claims (I can't confirm someone actually built this, ran it, or that Opendoor fast-tracked them). What I can check is whether the underlying premise and technical details are accurate.

Premise plausibility:

• Opendoor does have a real, active "AI Operations" team where teams default to AI to solve problems, and an Operations AI Engineer role focused on building AI-powered workflows and automation across operations, based in Toronto. So a role along these lines genuinely exists. I found no independent confirmation of the specific "apply using only AI and we'll fast-track you" challenge — that detail rests entirely on the poster's account. Opendoor

Technical claims — these check out as accurate descriptions of real tools/concepts:

• ARIA roles like role="combobox" and role="radiogroup" are real, standard accessibility attributes used across form-heavy sites — accurately described.
• Greenhouse, Lever, Workday, and Rippling are all real, widely-used ATS (applicant tracking system) platforms.
• Playwright's set_input_files is a real API method for file uploads; CDP-level file chooser interception is also a real, documented Playwright/Chrome DevTools Protocol capability. The "3-attempt uploader" approach is a legitimate engineering pattern for handling stubborn hidden file inputs.
• Human-in-the-loop pausing for Cloudflare bot-verification is a realistic and common workaround, since headless browser automation routinely triggers Cloudflare challenges.
• Model tiering (cheap model for classification, mid-tier for reasoning, top-tier for generation) is a standard, sensible cost/quality tradeoff pattern — not exaggerated.

Unverifiable / can't be fact-checked:

• The $0.20 cost per run and under-3-minute runtime are self-reported figures with no way to independently confirm.
• Whether this specific project exists in a public repo — the post says "code drops once the next improvements land," meaning there's currently nothing to verify it against.

No factual red flags or fabricated technical details — everything described is technically coherent and consistent with real tools. The main caveat is that the outcome claims (built it, it works, it was fast-tracked) are self-reported and not independently checkable.