DEV Community: Blaine

[Boost]

Blaine — Fri, 13 Mar 2026 19:22:09 +0000

HuntOS: an automated job application tool; and my experience vibe coding

Blaine ・ Mar 13

HuntOS: an automated job application tool; and my experience vibe coding

Blaine — Fri, 13 Mar 2026 19:04:49 +0000

A few months ago, a close friend of mine lost his job. The kicker? He wasn't just laid off; he was essentially replaced by an AI programming agent. It was a wake-up call. I wanted to understand exactly where my own profile fit in this rapidly shifting market, but the manual process of searching and applying is a soul-crushing grind.

At the same time, my day job involved a lot of work with browser automation and form-filling. I realized I could combine these two worlds.

The result is HuntOS: a local-first, automated job application tool. But the real story isn't just what it does—it's how it was built.

The $10 Stack: Vibe Coding into Reality

This project is a testament to how "vibe coding" has changed the game. I built HuntOS with just a $10 GitHub Copilot subscription, the Zed editor, and a dream.

When I say I "built" it, I mean I didn't manually write a single line of code.

Using the AI features in Zed, I acted more like a systems architect than a coder. I provided the high-level design, described the infrastructure, and let the agents do the heavy lifting. I primarily used Claude 3.5 Sonnet for the bulk of the logic and Claude 3 Opus for the more complex architectural puzzles.

Even the logo you see at the top of the README? That was vibe-coded as an SVG. I described the look I wanted, and the agent generated the math and the tags.

The Recipe: How to Replicate This Success

If you want to build something similar, here is the "cooking recipe" I followed. It’s less about syntax and more about managing context:

The Blueprint: I started with a high-level DESIGN.md. This served as the source of truth for the entire system.
The Specs: From that blueprint, I generated individual technical specs inside a Design folder. Each file focused on a specific sub-system.
The Agents: For every new feature, I created a new Zed Agent.
Context Management: I grouped similar features into the same chat histories. When a chat reached its context limit, I would have the agent summarize the current state, start a new agent session with that summary, and continue. This kept the "brain" focused on the task at hand without getting lost in the noise of unrelated features.
The Workflow: This following video perfectly encapsulates the workflow I used. Even though I didn't see it until after I started, it’s a great visual guide for this style of development.

The most shocking part? The total time investment was about 2 weeks with multiple gaps. In reality, it was roughly 4 days of work, 2 hours per day. That’s 8 hours to go from a dream to a working automated job application OS.

What is HuntOS?

HuntOS is designed to be your personal career command center. It handles the tedious parts of the job search so you can focus on the interviews.

Job Board Scraping: It pulls listings from LinkedIn, Greenhouse, and others.
Tailored Resumes: It uses agents to generate Markdown and PDF resumes specifically for each job description.
Browser Automation: Using Chrome DevTools Protocol (CDP), it actually navigates to the forms and fills them out.
Audit Trails: It takes screenshots of every step the agent takes, so you can see exactly what happened during an automated application.

PS: I don't speak german but added that to my profile anyways.

Performance: How Good is the Agent?

Since I didn't write the code, I have to judge the agent as if it were a junior developer I hired.

Code Quality

Note: I am still looking into the best ways to quantitatively measure this. Some strategies I'm considering are running complexity analysis, looking at test coverage (which the agent also has to write!), and using automated linting tools to see how "clean" the output is. For now, the "vibe" is that it is surprisingly modular.

Project Quality

The agent exceeded my expectations in several areas:

Resume Generation: It correctly identified my most relevant projects and experience, perfectly adhering to the Markdown templates I provided.
Job Discovery: It successfully scraped positions based on my specific preferences like location, compensation, and role type.
Submission Rate: I’ve achieved a 65% successful submission rate so far.
The "Rough Edges": It’s not perfect. It still struggles with sites that require a login or have very strict form validation. Interestingly, using Qwen 3.5 A30B, I noticed it would occasionally try to type "Two" into a field that expected an integer. Also, the screenshot logic isn't 100% accurate yet, so some logs are a bit fuzzy.

High Tech, Low Cost

One of my main goals was to keep the project accessible. We use a "local-first" approach:

SQLite for all data storage (no expensive cloud DBs).
Self-hostable models: It supports Ollama and LMStudio, meaning you can run the "brains" of the operation on your own hardware.
Smart Model Routing: You can use cheaper models for simple tasks and save the "expensive" tokens for the complex reasoning.

The Bill: What did this actually cost?

To go from an empty folder to a fully functional, agent-driven OS, the financial investment was minimal:

GitHub Copilot Subscription: $10 (The primary "engine" for the Zed agents).
LLM API Costs: ~$0 (By using self-hostable models and free-tier/low-cost tokens).
Manual Labor: $0 (Zero lines of code written by hand).
Electricity: TBD (My roommates haven't seen the bill yet, but my GPU fans were spinning so fast I’m pretty sure the living room hovered a few inches off the ground).

Seriously, the marginal impact on the electricity bill is probably the most expensive part of the stack, and even then, I'm splitting it three ways. Sorry guys.

The "Agentic" Shift

Building HuntOS showed me just how strong AI agents have become. We are reaching a point where the barrier between an idea and a working prototype is thinner than ever.

The shift in programming paradigms reminds me of how we moved from manual "stick shift" vehicles to automatic ones. In the past, you had to be intimately involved in every gear change—writing every line of code by hand. Now, we are moving toward an "automatic" experience where the AI handles the mechanics of the transmission. You still need to know how to drive, where you're going, and when to hit the brakes, but you aren't bogged down by the manual labor of the gearbox.

We still need a "driver" for now, but I can see a future where "Full Self-Driving" for software becomes a reality. In that world, the only real contribution from the human "driver" is to decide which destination actually generates the most value.

How to use HuntOS

If you want to try this out yourself, here is the quick-start guide:

Install Bun: Ensure you have the bun runtime installed locally.
Install Chrome: You’ll need google-chrome-stable for the browser automation.
Start it up: Run the bun start script. You should see a Chrome instance launch.
Login: In that specific Chrome instance, log in to your LinkedIn account.
Navigate: Go to the HuntOS landing page in your local browser and follow the onboarding instructions.

The "Agentic" Shift

However, this experience also taught me that software engineering isn't dead—it's evolving.

While I didn't write the lines of code, I had to spend a lot of time thinking about infrastructure, data flow, and how to prompt the agents effectively. You still need to understand the "why" behind the code to debug issues and maintain a coherent architecture. You have to guide the "vibe" so the project doesn't turn into a spaghetti mess.

Open Sourcing the Dream

I’m excited to announce that HuntOS is now open source. I invite individual contributors to help expand on the functionalities of the software and make into something practical that people can actually use. (Also I ran out of credits so....)

The License: I’ve released this under a license that ensures it stays free for individuals. It should not be used for profit or by companies looking to charge for these tools. This is by the people, for the people.

You can find the project here:

Blakeinstein / HuntOS

Tool to auto apply to jobs

HuntOS

Automated job application OS — powered by AI agents, browser automation, and a fully local stack.

What is HuntOS?

HuntOS is a local-first, agent-driven job application platform. It combines a SvelteKit UI, Mastra AI agents, and Chrome DevTools Protocol automation to research job listings, tailor resumes, and submit applications — while you focus on what matters.

Capability	Details
Job board scraping	LinkedIn, Greenhouse, and generic boards
Resume generation	Agent-tailored Markdown + PDF per application
Browser automation	Full CDP-driven form filling and submission
Kanban pipeline	Track every application from research to offer
Audit trail	Per-run annotated screenshots and action logs
Fully local	SQLite databases, no cloud storage required

Usage Guide

Install Bun: Ensure you have the bun runtime installed locally.
Install Chrome: You’ll need google-chrome-stable for the browser automation.
Start it up: Run the bun start script. You should see a Chrome instance launch.
Login: In that specific Chrome instance…

View on GitHub

Final Thoughts

We live in a world where AI can take jobs, but it can also give us the tools to find new ones faster than ever. HuntOS started as a way to help a friend and understand the market, but it turned into a lesson in the power of modern development.

Whether you're a seasoned engineer or someone with just an idea, the tools are there. All you need is a few dollars and the right prompts.

Happy hunting!

Using the new Native Dialog API as a reusable component in Vue 3

Blaine — Thu, 15 Jun 2023 01:51:58 +0000

📝 The Native HTML Dialog

We've all heard the buzz around browser native dialogs which are now widely supported across all modern browsers. Now you no longer need to depend on third party packages to achieve a user friendly dialog/popover experience.

Now if you are just here for the code, here it is below. However, if you are here to understand how we got here, stick to the end!

<script setup lang="ts">
import { ref } from 'vue';

const dialog = ref<HTMLDialogElement>();

const props = defineProps({
  classes: {
    type: String,
    default: "",
  },
});

const visible = ref(false);

const showModal = () => {
  dialog.value?.showModal();
  visible.value = true;
};

defineExpose({
  show: showModal,
  close: (returnVal?: string): void => dialog.value?.close(returnVal),
  visible,
});
</script>

<template>
  <dialog
    ref="dialog"
    @close="visible = false"
  >
    <form
      v-if="visible"
      method="dialog"
      :class="{
        [props.classes]: props.classes,
      }"
    >
      <slot />
    </form>
  </dialog>
</template>

👷 The Breakdown

The new Dialog API is pretty straightforward. As seen from the MDN Page, all you need to get started is a simple <dialog> element. Any reference to this element will have programatic access to the function .showModal() to toggle the dialog, so you could do this with a button!.

Vanilla HTML

Lets take a look at the provided example

<dialog open>
  <p>Greetings, one and all!</p>
  <form method="dialog">
    <button>OK</button>
  </form>
</dialog>

Do note the additional comment on MDN,

Because this dialog was opened via the open attribute, it is non-modal. In this example, when the dialog is dismissed, no method is provided to re-open it. Opening dialogs via HTMLDialogElement.show() is preferred over the toggling of the boolean open attribute.

So although this is a good demonstration of the result, programatic access is suggested.

Looking closer, other than the open attribute, we have

A form component, with method="dialog". This is a new form method, which on form submission, automatically closes the dialog with a submit event.
Accessibility, pressing tab will toggle only through the form elements in the dialog.
The dialog content will be shown in a new layer, which can be visualized from the browsers dev tools.

🤖 Difference between show and showModal

There are two ways to open the dialog.

.show() will toggle open the dialog, but
- Esc will not close the element.
- Backdrop will not be darkened (default styling).
.showModal() will toggle open the dialog in the modal mode,
- Esc will close the modal
- Backdrop will be darkened in default styling. (The styling can be changed).

⛵️ Bringing in Vue

Lets be real, you are probably not working on a project with vanilla HTML, it is nice but does not scale. You might be using a Frontend library, probably something among React, Vue or Svelte. I will be covering Vue here, but the design pattern should be similar in Svelte. Pretty sure, React folk don't have to worry about not using Third Party packages :P.

A simple solution in Vue is to just slap a <slot />, have a two way binding to the open attribute via props and call it a day. Lets look at this example

<script setup lang="ts">
const props = defineProps<{
   open: boolean
}>();
</script>

<template>
<dialog :open="props.open">
  <form method="dialog">
    <slot />
  </form>
</dialog>
</template>

This is a good enough solution but lets see if we can do better!

💪 Trying to do better

We will try to

Adhere to using programmatic access.
See if we can mount the child component only when the modal is open, so that any mount hooks run only when needed.

To achieve the first we shall use a ref. This way we get a ref to the dialog element, to be able to call the showModal function. We avoid ids, because we want this re-usable! Plus avoid document.querySelector makes it SSR safe?. Don't quote me on that.

<script setup lang="ts">
import { ref } from 'vue';

const dialog = ref<HTMLDialogElement>();
....
</script>
<template>
<dialog
    ref="dialog"
>
   ...
</dialog>
</template>

We then declare a function to call showModal(), then expose that function to parent components via defineExpose().

const showModal = () => {
  dialog.value?.showModal();
};

defineExpose({
  show: showModal
});

The parent component can then bind a ref to the modal and toggle dialog as needed.

import Modal from 'path/to/Modal.vue';

const modal = ref<InstanceType<typeof Modal>>();

const showModal = () => modal.value?.show();

With that complete lets also get conditional loading so that mount hooks work proper (otherwise this is equivalent to a v-show)

We create a state called visible and toggle that when state of dialog changes. We shall set visible to true, when we show the modal, and use the close event to toggle it to false.

<script setup lang="ts">
...
const visible = ref(false);

const showModal = () => {
  dialog.value?.showModal();
  visible.value = true;
};
...
</script>
<template>
  <dialog
    ref="dialog"
    @close="visible = false"
  >
    <form
      v-if="visible"
      method="dialog"
    >
      <slot />
    </form>
  </dialog>
</template>

and there's that! Note that if you still want a cleaner approach, you can still use the open prop for conditional rendering as well as the open attribute but do note that some of the accessibility will be lost.

<script setup lang="ts">
const props = defineProps<{
   open: boolean
}>();
</script>

<template>
<dialog :open="props.open">
  <form v-if="props.open" method="dialog">
    <slot />
  </form>
</dialog>
</template>

the final result is the code at the very start of the guide!

🎨 With DaisyUI and TailwindCSS!

DaisyUI v3 supports native modals! Here is a quick custom component with slots and styles to make life easier for you!

<script setup lang="ts">
import { ref } from 'vue';

const dialog = ref<HTMLDialogElement>();

const props = defineProps({
  confirmText: {
    type: String,
    default: 'Confirm',
  },
  cancelText: {
    type: String,
    default: 'Cancel',
  },
  hideConfirm: {
    type: Boolean,
    default: false,
  },
  showCancel: {
    type: Boolean,
    default: false,
  },
  classes: {
    type: String,
    default: '',
  },
});

const emit = defineEmits(['confirm', 'cancel']);

const cancel = () => {
  dialog.value?.close();
  emit('cancel');
};

const confirm = () => {
  dialog.value?.close();
  emit('confirm');
};

const visible = ref(false);

const showModal = () => {
  dialog.value?.showModal();
  visible.value = true;
};

defineExpose({
  show: showModal,
  close: (returnVal?: string): void => dialog.value?.close(returnVal),
  visible,
});
</script>

<template>
  <dialog
    ref="dialog"
    class="modal modal-bottom sm:modal-middle"
    @close="visible = false"
  >
    <form
      v-if="visible"
      method="dialog"
      :class="{
        'modal-box rounded-none p-4': true,
        [props.classes]: props.classes,
      }"
    >
      <slot />

      <div class="modal-action" v-if="!props.hideConfirm || props.showCancel">
        <slot name="footer" />
        <slot name="actionButtons">
          <button
            v-if="props.showCancel"
            value="false"
            class="btn"
            @click.prevent="cancel"
          >
            {{ props.cancelText }}
          </button>
          <button
            v-if="!props.hideConfirm"
            value="true"
            class="btn btn-primary"
            @click.prevent="confirm"
          >
            {{ props.confirmText }}
          </button>
        </slot>
      </div>
    </form>
    <form method="dialog" class="modal-backdrop">
      <button>close</button>
    </form>
  </dialog>
</template>

Here is a stackblitz for the same

Closing

Thanks so much for reading! If you have any improvements on the above do share in the comments. As for me, I really love the new native dialog, and the future things coming to vanilla HTML, like the Popover element bring simpler tooltips and page transitions which may enable frameworks like astro to simplify page transitions via CSS where JS libraries like SWUP which takeover client side page navigation are the only way to transition.