sneefle

I posted a version of this a few months ago that was just "a bot that applies to jobs". The thing I actually spent the time since on is narrower and, I think, the only interesting part: checking whether the application arrived.

The failure mode that pushed me into it: a submit that returns a cheerful success page but never registers. The form silently drops the file, or the endpoint 400s behind an XHR and the SPA renders the confirmation anyway. From the outside those look identical to a successful application, so you sit there for three weeks assuming you were passed over.

So after the submit we go back and look for evidence the other side produced, not evidence we produced. "We clicked the button" is worthless, it is just reading back our own input. What counts is a confirmation email to the relay address, the application appearing in the ATS's own tracking, that kind of thing. We show three states rather than one: landed, still verifying, did not land.

It applies on the employer's real ATS (Greenhouse, Lever, Workday, Ashby, iCIMS, SmartRecruiters) via a cloud browser rather than emailing a PDF somewhere.

The honest part: the third state is not rare. Building it made my own numbers look considerably worse, and I still think showing it is the right call, but I go back and forth on whether a smaller confirmed number reads as more trustworthy or just as a weaker product. Genuinely interested in what people here think about that specific tradeoff.

Happy to go into the verification signals in detail if that is the useful bit.

we run screen-driven agents against web forms in production and the failure mode that took us longest to find wasn't navigation, it was commits that don't commit. a react controlled select can render the right value after a click while the framework's internal state never updated, so every pixel says done and the submitted payload says null. vision-only verification passes because the screen genuinely looks correct.

curious how you handle that class without DOM access. screenshot-after-action catches missing UI feedback, but when the UI itself is lying about form state the only reliable tells we found were downstream: the confirmation page, an outbound request, an email arriving. do your verification events ever consume anything besides pixels, or do you lean on the human approval gates for the risky commits?

Timing couldn't be more perfect, yes. Visibility and getting it in front of the people is proving to be a bit challenging atm only. so far, trying to push on LinkedIn and find direct leads for open-to-work folks. :D