Your Coding Agent Should Be Doing Your Job Research

souvikde.tech@gmail.com — Sun, 27 Sep 2026 00:00:00 GMT

If you write code, you probably have Claude Code, Codex, or OpenCode installed.I personally use both claude code and opencode daily for my work and side projects.

But the last time I was looking for a job, I didn't use it once. I did all the research by hand, like it was 2015.

Looking back, that's kind of ridiculous. Interviews were stressful, sure, but the stuff that actually wore me down was everything around them. I'd have a dozen tabs open at any point, spread across job boards, careers pages and review sites. If I found a role I liked, there was nowhere good to put it. I tried bookmarks for a while, then a spreadsheet that I stopped updating after a week.

The research was worse. Before applying anywhere I wanted to know what the company was actually like: what stack they use, and whether people who work there seem happy. Each of those was another search and more tabs, and somehow an hour would be gone. Some days it felt less like job hunting and more like data entry.

That's exactly the kind of work I hand off to an agent when I'm coding. It just never occurred to me to do it for my job search.

Bring your own agent

So I'm building JobScout. That's the working name, anyway. The site lives at findmejob.xyz, which should tell you how settled the name is.

It connects to the AI agents you already run locally, like Claude Code, OpenCode, and Codex. You don't need another subscription or another account for yet another "AI-powered" job tool. It just uses the agent you already have.

The idea is that you shouldn't be the one opening twelve tabs to decide if a company is worth applying to. You point your agent at the company and let it do the digging, then read what it found.

Later I want the agent to help with applications too. Not mass-applying to a hundred jobs, though. More like drafting something for a specific role, which you read and fix before anything gets sent.

Underneath all of that, it's the thing I wanted during my last search. You save companies you're interested in, shortlist the ones you really want, and the research stays attached to each one. When I open it I can see where I am and what I still need to look into, instead of hunting for a link I know I saved somewhere.

I'm mostly building it for myself. But I doubt I'm the only one who's had this problem.

Try it out

One thing I should be upfront about: this is still very much in development. A lot of what I described above isn't built yet. It's what I'm working toward, and I'm hoping to ship those pieces soon. So if you try it now, you're getting an early version, rough edges included.

If you're job hunting and already use a coding agent, you can download it from findmejob.xyz. I'd really like to hear what works and what doesn't, and which agent you'd want it to support best. That kind of feedback will shape what I build next.

Oh, and the name will probably change. Honestly, writing this post is partly a way to make myself finish it.

Read the full article on souvik.de →

An Introduction to Glee: A Spec-First Framework for Event-Driven APIs

souvikde.tech@gmail.com — Tue, 15 Sep 2026 00:00:00 GMT

Note: Glee was archived on August 4, 2025 and is no longer maintained. I'm keeping this walkthrough around as a reference — it's a useful example of building with a spec-first mindset. This post originally appeared on the AsyncAPI blog.

During my time working full-time on AsyncAPI, I helped build a framework called Glee. This post is a broad introduction to what Glee does, why a spec-first approach is worth your attention, and how to spin up a working WebSocket API in a few minutes.

What is Glee?

Glee is a spec-first framework for building server-side, event-driven applications. The core idea is that your AsyncAPI specification is the single source of truth, and Glee does the plumbing around it — creating connections, managing message flow, and keeping everything wired to the spec — so you can focus on business logic instead of connection management.

Two things stand out:

Your code, spec, and docs stay in sync. Because the spec drives everything, you can't quietly drift away from it. When the API evolves, the specification and documentation move with it.
Connection management is handled for you. Performance, scalability, and resilience concerns are off your plate, so you spend your time on the logic that actually matters to your users.

Getting started

Let's build something concrete: a WebSocket server that receives the current time and the client's name, then replies with a greeting based on the hour.

You'll need Node.js and npm. Check they're installed:

node -v
npm -v

Create a Glee project

The quickest way to scaffold a project is the official AsyncAPI CLI. It creates the directory for you, so run it from wherever you want the app to live:

asyncapi new glee

You can install the CLI via npm or grab binaries from the releases page.

Define the spec

Because Glee is spec-first, you start with the spec — not the code. Here's a minimal AsyncAPI 3.0.0 document that describes our greet API:

asyncapi: 3.0.0
info:
  title: Greet Bot
  version: 0.1.0
servers:
  websockets:
    host: '0.0.0.0:3000'
    protocol: ws
channels:
  greet:
    address: greet
    messages:
      onGreet.message:
        $ref: '#/components/messages/time'
      subscribe.message:
        $ref: '#/components/messages/greet'
operations:
  onGreet: # operationId
    action: receive
    channel:
      $ref: '#/channels/greet'
    messages:
      - $ref: '#/components/messages/time'
  greet.subscribe:
    action: send
    channel:
      $ref: '#/channels/greet'
    messages:
      - $ref: '#/components/messages/greet'
components:
  messages:
    time:
      payload:
        type: object
        properties:
          currentTime:
            type: number
          name:
            type: string
    greet:
      payload:
        type: string

The important bit is the operationId. Glee uses it to connect the spec to your business logic: whenever the /greet channel receives a message, Glee calls the function with that operationId. In other words, the spec doesn't just describe the API — it names the entry points your code plugs into.

Write the operation function

Create functions/onGreet.js with the greeting logic. Every file in functions/ is a handler that exports an async function taking an event parameter, which gives you access to the payload and server details:

export default async function (event) {
  const { name, currentTime } = event.payload;
  const hour = new Date(currentTime).getHours();

  let response = "";
  if (hour < 12) {
    response = `Good Morning ${name}`;
  } else if (hour < 18) {
    response = `Good Afternoon ${name}`;
  } else {
    response = `Good Evening ${name}`;
  }

  return {
    reply: [
      {
        payload: response,
      },
    ],
  };
}

Run and test

Start the app:

npm run dev
# or
npm run start

Then point a WebSocket client at the server (I used Postman) and send a message with a currentTime and name. You should get a greeting back based on the time of day.

Wrapping up

That's the whole loop: define the spec, map operations to functions, and run. There's a full working example in the Greet Bot repo if you want to poke around.

Glee was evolving quickly and supported MQTT and WebSocket while I worked on it, but the project has since been archived. The ideas behind it — spec-first development, code and docs that can't drift apart — are still worth carrying into whatever you build next.

You can read the original version of this post on the AsyncAPI blog, and find the archived source in asyncapi-archived-repos/glee.