Hi HN, I built this after watching Claude Code drive a browser for a mundane job: triaging user feedback on an internal admin page and updating statuses. It worked, but it was slow and expensive. Every click cost a full model turn in which the agent re-read the page and its own context before deciding what to do next.
jev-browse hands that loop to a small decision model instead. Your agent calls one function, fast_run(url, goal), from a browser-harness script. On each step, jev-browse snapshots the page's visible controls in one browser call, and asks TypeSafe's Jev (a "System One" model that returns typed choices with probabilities rather than generated text) which operation to perform and on which element, in a single ~0.3s request. When a field needs text that isn't literally in the goal, it asks a small text model (a local Ollama model, Claude Haiku via the CLI, or any OpenAI-compatible endpoint). The agent gets back an outcome, evidence, and a typed reason whenever jev-browse stops.
It's inspired by browser-use's jev-ultrafast demo, which showed that one typed choice per step is enough to drive real sites. jev-browse turns that into a tool agents use day to day: pluggable text backends with a known-answer health check, an interactive find/click/check mode, a gate before commit-like clicks (send, pay, delete), owned-tab isolation so it never touches your own tabs, and "hand back instead of guess" for iframes, uploads, auth walls and low-confidence steps.
Numbers, on my machine only, with outcomes checked by code rather than a model: on public-site tasks (Wikipedia navigation, a Google Flights search, a filter-and-open listing), Claude with jev-browse was 1.6–3.0× faster and 2.1–5.3× cheaper than the same Claude driving the browser itself, with the same pass rate. Almost all of the saving comes from fewer agent turns. Called from a plain script with no agent, a Wikipedia task takes about 4s and a fraction of a cent. The benchmark code is in the repo if you want to reproduce it or break it.
Caveats: page text is sent to TypeSafe (and to the text model if one is needed), so don't use it on sensitive pages. It doesn't handle canvas-heavy UIs, shadow DOM or cross-origin iframes yet; it hands those back. And "done" is a claim for your agent to verify, not proof.
MIT licensed. Setup is a copy-paste prompt for Claude Code or Codex. I'd love feedback, especially from people running agents against real web apps.
SerpApi needs to improve their hiring process, I've also seen others complain here on HN, where they would give you a software engineering test and just go silent after it's done.
Not even a rejection email, and when you reach out to recruiters/other software engineers there is always radio silence
I am just adding this comment here, because I've seen this comment added on other threads and they haven't done anything about it and I also went thru the same process assuming they would improve, but I also got no responses
We usually stop replying to people that gave us obvious red flags during the process. And our policy is to not reply back to share these red flags anymore. In the past, some people unfortunately can get outright aggressive when you try to share these.
Email me directly at julien _at_ serpapi.com and I can see where you are at.
I felt the need to talk about my experience with SerpAPI's hiring process because, quite frankly, it was no good.
First off, I was super excited when I applied at SerpAPI. I really wanted to be part of what you are building. I worked for 10 hours non-stop on the challenge you set up, even with my brother visiting after not seeing him for 2 years. But my excitement turned into confusion when I got no response - not once, but twice.
You mentioned "obvious red flags", which simply doesn't add up. Despite offering numerous referrals from past jobs and delivering work that is deserving of at least a reply, it feels as though I am being overlooked.
My conversations with others who have also applied to your organization reveal a similar experience of being disregarded. Respect and clear communication matter significantly to me, being neurodiverse, and while your attempts to keep things simple are acknowledged, these are not mere extras - they are fundamental. Companies such as Basecamp comprehend this need but my experiences suggest SerpAPI doesn't. Your silence paints a negative picture that contrasts with the image of SerpAPI you aspire.
I know you can make things better. Start by recognizing the hard work, and responding to applicants. We are not just forms on your website; we are individuals with genuine interest, deserving of respect. Also consider focusing more on candidates already deeply engaged with open-source.
> First off, I was super excited when I applied at SerpAPI. I really wanted to be part of what you are building. I worked for 10 hours non-stop on the challenge you set up, even with my brother visiting after not seeing him for 2 years. But my excitement turned into confusion when I got no response - not once, but twice.
Have you not received payment for the code challenge yet? Looking at our internal thread, we had issues with our bank with some tax information missing on your side (I know tax compliance is tricky), but I think it's fixed. Ping me if it's not the case. julien _at_ serpapi.com
> We are not just forms on your website
I am confused by that statement. There is no forms in our application, we only do emails. Can you point to what is the form you referring to? I dislike processes that require forms as well and we'll remove.
Our team is looking for a Senior Database Engineer with PostgreSQL experience to help scale, optimize and maintain our databases. As a Database Engineer on our team, you will focus on building up the PostgreSQL as a Service infrastructure. This includes building software to run the service at scale and will include building software around databases, like monitoring and alerting tools. Our engineering team follows agile principles in a test-driven development process. We are a remote-first team that values open collaboration and shared ownership.
One post per company, please. This is in the rules at the top.
Also, please don't get teammates or friends to upvote these. Promotional voting is against HN's rules, as explained in the FAQ: https://news.ycombinator.com/newsfaq.html.
Our team is looking for a Mobile Software Engineer with React Native experience to help build and maintain our mobile application that streamlines care management and helps improve health outcomes. You’ll be working on exciting projects like building a mobile app for healthcare organizations and patients, integrating with APIs, and automating builds for iOS and Android. Our engineering team follows agile principles in a test-driven development process. We are a remote-first team that values open collaboration and shared ownership.
CareMessage is looking for a Front End Software Engineer to help build the next generation of our web application to streamline care management and deliver interactive mobile programs to improve health outcomes. You will specialize in building responsive and elegant web applications that scale to millions of users in multiple languages.Our engineering team follows agile principles in a test driven development process. We are a remote first team that values open collaboration and shared ownership.
CareMessage (formerly YC W14) is looking for a Software Engineer with Ruby on Rails and/or Elixir experience to help build and maintain our web platform that streamlines care management and delivers interactive mobile programs to improve health outcomes. You’ll be working on exciting projects like optimizing our Sidekiq queuing system, improving and building new integrations with Twilio, building our customer analytics code, and helping improve and maintain our own API. Our engineering team follows agile principles in a test driven development process. We are a remote first team that values open collaboration and shared ownership.
Salary range based on experience from $80K to $120K.
QA Engineer (Automation) | CareMessage (YC W14) | REMOTE | FullTime
CareMessage is looking for a QA Automation Engineer to help with manual and automated quality assurance of the CareMessage web application and API. You will be responsible for entire features and will be a full-time member of the CareMessage Engineering team. Our engineering team follows agile principles in a test driven development process. We are a remote first team that values open collaboration and shared ownership.
More Info: http://grnh.se/4ikfq11
Software Engineer (Integrations - HL7) | CareMessage (YC W14) | REMOTE | FullTime
CareMessage is looking for a Software Engineer with HL7 interface experience to help build and maintain integration solutions for connecting CareMessage with leading EMR systems. You will help build integrations that provide a seamless experience across the CareMessage web application and leading EMR systems. These integrations play a key role in improving the customer experience with our product and ensuring user growth. Our engineering team follows agile principles in a test driven development process. We are a remote first team that values open collaboration and shared ownership.
Software Engineer (Back End) | CareMessage (YC W14) | REMOTE | FullTime
CareMessage is looking for a Software Engineer with Ruby on Rails experience to help build and maintain our web platform that streamlines care management and delivers interactive mobile programs to improve health outcomes. You’ll be working on exciting projects like optimizing our Sidekiq queuing system, improving and building new integrations with Twilio, building our customer analytics code, and helping improve and maintain our own API. Our engineering team follows agile principles in a test driven development process. We are a remote first team that values open collaboration and shared ownership.
CareMessage is looking for a Software Engineer with HL7 interface experience to help build and maintain integration solutions for connecting CareMessage with leading EMR systems. You will help build integrations that provide a seamless experience across the CareMessage web application and leading EMR systems. These integrations play a key role in improving the customer experience with our product and ensuring user growth. Our engineering team follows agile principles in a test driven development process. We are a remote first team that values open collaboration and shared ownership.
jev-browse hands that loop to a small decision model instead. Your agent calls one function, fast_run(url, goal), from a browser-harness script. On each step, jev-browse snapshots the page's visible controls in one browser call, and asks TypeSafe's Jev (a "System One" model that returns typed choices with probabilities rather than generated text) which operation to perform and on which element, in a single ~0.3s request. When a field needs text that isn't literally in the goal, it asks a small text model (a local Ollama model, Claude Haiku via the CLI, or any OpenAI-compatible endpoint). The agent gets back an outcome, evidence, and a typed reason whenever jev-browse stops.
It's inspired by browser-use's jev-ultrafast demo, which showed that one typed choice per step is enough to drive real sites. jev-browse turns that into a tool agents use day to day: pluggable text backends with a known-answer health check, an interactive find/click/check mode, a gate before commit-like clicks (send, pay, delete), owned-tab isolation so it never touches your own tabs, and "hand back instead of guess" for iframes, uploads, auth walls and low-confidence steps.
Numbers, on my machine only, with outcomes checked by code rather than a model: on public-site tasks (Wikipedia navigation, a Google Flights search, a filter-and-open listing), Claude with jev-browse was 1.6–3.0× faster and 2.1–5.3× cheaper than the same Claude driving the browser itself, with the same pass rate. Almost all of the saving comes from fewer agent turns. Called from a plain script with no agent, a Wikipedia task takes about 4s and a fraction of a cent. The benchmark code is in the repo if you want to reproduce it or break it.
Caveats: page text is sent to TypeSafe (and to the text model if one is needed), so don't use it on sensitive pages. It doesn't handle canvas-heavy UIs, shadow DOM or cross-origin iframes yet; it hands those back. And "done" is a claim for your agent to verify, not proof.
MIT licensed. Setup is a copy-paste prompt for Claude Code or Codex. I'd love feedback, especially from people running agents against real web apps.