Vibe coding a Hacker News job board

Every month, Hacker News runs two threads: Who is hiring?, where companies post jobs, and Who wants to be hired?, where people post themselves.

A long time ago, I set up a small process to extract and parse these listings to monitor the tech job market. With the recent release of projects like HackerTube and HackerBooks, I was inspired to do the same for the hiring threads: give the process a proper interface, open source it, and share it.

Then I thought: what better opportunity to try out vibe coding for the first time?

I present hackerjobs: every post since January 2026, turned into fields you can filter on (role, pay, location, remote or not, technologies, company stage, industry), with a link back to the original post on every card.

The hiring board: filters for kind of work, arrangement, pay and seniority on the left, job cards with roles, location and technologies on the right — The hiring board

Vibe coding & cost

The setup is simple. I spun up Claude Code (model: Opus 5.5; effort: medium), pointed it at my old code, and asked Claude to turn it into a proper job board (and make no mistakes!). A few hours and countless clarifications later, we had a job board.

Here’s an overview of the Claude Code usage for the session:

Total cost:            $86.53
Total duration (API):  2h 6m 18s
Total duration (wall): 8h 58m 54s
Total code changes:    7486 lines added, 789 lines removed
Usage by model:
    claude-haiku-5-5:  240.4k input, 25.3k output, 0 cache read, 0 cache write, 9 web search ($0.1267)
    claude-opus-5-5:  3.6k input, 817.9k output, 263.9m cache read, 2.2m cache write ($86.40)

On top of that, because heuristic parsing wasn’t good enough, I used the Anthropic API (model: Haiku 5.5) to parse every post since January (8,231 of them). All my experimenting, prompt iterations and re-parses included, I’ve spent about $12 on the API.

Friction

Claude jumped right into coding without any planning beforehand. I had to manually stop it and establish a process. Claude’s eagerness was a recurring issue throughout the process: assuming a design for the UI before my review, starting parsing before the extracted fields were approved, etc. A skill that defines an SOP for creating ground-up projects will likely prevent these issues.

UI details were poorly handled. Claude is really good at front-end development in broad strokes, but it doesn’t seem to pay attention to, or care about, the details: off-center text, missing padding in buttons and between components, and so on. However, every issue was fixed quickly once I pointed it out.

I felt like a babysitter. Even though Claude was doing most of the work, I found myself constantly on standby waiting to test a new iteration of the UI or spot-check a set of parsing. Perhaps because I’m still a vibe-coding noob, I didn’t feel as productive as I would’ve liked.

The ideal workflow I’d imagined was Claude and me working in parallel, neither ever blocked on the other, with me checking in once in a while to do the work that needs a human. The reality is not quite there, yet that goal felt reachable with the right harness.

Will I vibe code again?

Absolutely! This was an incredibly fun experience with a few small hiccups. And building a product like this from zero to prod in one day? That’s remarkable. I still take a relatively conservative stance on using AI in my larger, more serious projects. But for fun things like this, vibe coding totally changes the game.

(PS: After I’d built the board, I came across a similar project, HNHIRING, by Jordi Noguera. It’s worth a look, so I want to give it a shout-out.)