DEV Community: Panth Patel

849 KB of spec before any code: building Octupuz, a puzzle feed

Panth Patel — Sat, 10 Oct 2026 13:01:35 +0000

Before the first line of Octupuz existed, its spec was 849 KB of JSON: 72 screens, 23 components, every animation researched from Instagram, and every decision written down with its reason. The first build worked from a summary of that spec instead of the spec. It looked like a prototype, contradicted decisions that were already settled, and was thrown away.

I'm Panth. I lead the software team at Oizom, and Octupuz is my own project, built in about a month. This post is about the parts of it you can't see in a screenshot: why the backend knows nothing about puzzles, why a board has to come out the same on every device, and how the server checks a solve without trusting the phone.

What Octupuz is

A social feed that looks and moves like Instagram, except every post is a puzzle you play right there. 41 kinds are live: Queens, Nonogram, Pipes, Water Sort, Suguru, Skyscrapers, a whodunit called Case File, and more. New ones every day. When you solve one, your time lands on the post.

It runs on the web and installs as a PWA at octupuz.in. The Play Store is next. The stack: Postgres on Supabase with row-level security, a Svelte client, Capacitor for the Android shell, and games in plain JavaScript.

The spec came first, and the summary failed

The spec is a set of JSON files. screens.json holds the 72 screens: per screen its route, what it reads, what it calls, and every transition with its gesture and motion. decisions.json holds every settled decision with the reasoning behind it. motion.json is 157 KB of animations researched from Instagram's own app.

The build prompt for the second attempt opens with one instruction, in bold: read the specification first, all of it, before writing any code. The sections after it are, in its own words, "a map to the requirements", not the requirements. Where the prompt and the spec disagree, the spec wins.

The same prompt lists two holes the first attempt had, both invisible when you read the SQL and both found only by sending the request an attacker would send to the live API:

revoke execute ... from anon does nothing, because Postgres grants EXECUTE to PUBLIC and anon inherits it.
A table-level revoke select ... from authenticated silently disables every RLS policy on that table.

So the working rule became: verify from the outside, with only the public key. Reading a policy is not the same as testing it.

The backend is Instagram, the frontend is the game

This is the decision everything else hangs on. The backend stores social data: players, follows, likes, comments, messages, plays. For each game it stores one string, bundle_path. It does not know what Queens is.

A post is a row with a puzzle column the backend never looks inside:

create table if not exists public.posts (
  post_id       uuid primary key default gen_random_uuid(),
  game_id       uuid not null references public.games(game_id) on delete cascade,
  puzzle        jsonb not null,            -- opaque here; only the game reads it
  post_sequence int  not null,             -- this game's nth puzzle
  ...
);

Today puzzle is usually a seed. The board it draws does not exist until a phone imports the game's bundle and asks for it.

A game is written once, in games/src/<game>/index.js, and each difficulty is a two-line entry file:

const diff = 'hard'
export default (await import('../../src/queens/index.js')).make(diff)

The database stores the relative path (/games/queens/hard.js) and the app loads it with a dynamic import() when a post needs it. Adding a game adds a row. No app update, no store review.

On Android, the JavaScript updates itself over the air: a signed manifest, a staged rollout by percentage, and never mid-session. A new bundle applies the next time the app goes to the background, not while someone is playing. That created one edge case. Posts come from the database the moment a game goes live, but a phone can still be on last week's bundle. So the app tries its own copy of the game first, and if it has none, fetches the same file from the server.

A board has to come out the same everywhere

If a post is a seed, two friends only play the same puzzle if the seed draws the same board on an iPhone, an Android phone, a laptop and the server. The shared random package opens with a list of what is banned in anything that decides a board:

Math.random, Date.now, performance.now. Time goes into the move log and nowhere else.
Math.sin, cos, exp, log, pow. Their precision is implementation-defined and differs between V8, JavaScriptCore and SpiderMonkey. Integers, Math.imul, |0 and >>>0 are exact everywhere.
sort(() => rng() - 0.5). It is not a real shuffle, and it is not stable across engines.
localeCompare, Intl, toLocaleString in game logic.

Randomness comes from one place: the seed string is hashed with cyrb128 into four 32-bit integers, which seed sfc32. Both use integer operations only.

A golden file keeps it honest. It records the boards a fixed set of seeds draw, and it is committed. If someone changes a generator, the test fails, because every past puzzle of that game would now redraw differently.

Queens is the exception. A Queens board has to be solvable without guessing, which means generating candidates and rejecting the ones a person could only guess at. The rejection test is a backtracking solution count, run thousands of times. That takes about a second: fine once on a server, not fine in a feed scrolling past thirty previews. So Queens boards are generated once, offline, and the post carries the finished grid, with its seed alongside so any board can be traced back to what made it. A few other games are published the same way.

A time on a post means the board was solved

Here is the whole path:

posts row: game_id + puzzle (seed or baked board)
   |
   +--> phone:    import(bundle_path) -> build(puzzle) -> play -> move log
   |                                                                |
   +--> verifier: same rules.js -> replay(puzzle, moves) <----------+
                        |
                        +--> server's own stats -> time on the post

Every tap goes into a move log with a timestamp. For Queens it looks like this:

q34@2100;d05@2600;D4043@3100

A crown at row 3, column 4 at 2.1 s, a dot at row 0, column 5, then one painted run from (4,0) to (4,3). A painted run is one entry, not four. Written as four dots sharing a millisecond, an honest player would look like a script to the timing check.

When you finish, the phone sends the post id and the move log. The verifier loads the puzzle, picks the game's rules module, and replays the log from an empty board:

const run = game.rules.replay(ctx.puzzle, moves, game.difficulty);

if (run.illegal || !run.completed) {
  return json({ error: 'the moves do not replay to an end', illegal: !!run.illegal }, 422);
}

// the client's numbers are ignored
const elapsed = Date.now() - Date.parse(ctx.started_at);
const plausible =
     run.stats.time <= elapsed + 2000
  && run.minMoveGapMs >= game.rules.humanFloorMs
  && (ctx.attempts < 50 || !ctx.p10_ms || run.stats.time >= ctx.p10_ms * 0.25);

The rules.js it runs is the same file the game imports in the browser. No DOM, no clock, no Math.random. One copy of the rules, run by both sides.

A few details make it hold:

The phone's numbers are thrown away. Time, moves, mistakes and hints all come from the replay. A modified app can lie about its time, and the lie never reaches the board.
The server's clock starts the game. The play row is created by the first move, with the server's timestamp. A claimed time can't be longer than the time that has actually passed, plus 2 seconds.
Nobody taps forty times a second. Each game sets a floor for the gap between moves. For Queens it is 90 ms.
Implausible is kept, not shown. A finish that fails those checks is recorded with flagged = true. The player sees their own result. Nobody else sees a number the server did not believe: no story, no "beat you" notification, no place on the post.
The server is the only way to finish. The plays table's update policy refuses is_completed, and the function that records a finish is granted to the service role alone. A browser can save where it got to. It cannot say it arrived.

The verifier runs as a Cloudflare Pages Function and talks to Postgres through Hyperdrive, so the database credential never leaves Cloudflare. A Worker can't evaluate code it downloads, so the rules for all 41 games are imported statically and picked by bundle_path, the same path the phone used to choose its copy.

That static list failed once. Nineteen games were carried over from an older project of mine and nobody added them to the verifier's list. The app played those puzzles all the way to the last move, then the server answered 501 and refused to record the finish. The only test that noticed was the one that plays a real board to its end. Now a test reads the verifier's imports and fails the build when any folder under games/src is missing.

There was one more bug, and it was in the database write. Passing ${JSON.stringify(stats)}::jsonb to the Postgres driver looks right. The driver already serialises a string as a JSON string when the target is jsonb, so Postgres stored a string that contained JSON, not an object. ->> 'time' on that is null, and every recorded finish had no time. The fix is two casts, ::text::jsonb, which makes Postgres parse the text instead of wrapping it.

What replay buys is simple to say. A time on a post means a solved board. And nobody ever needs to see another person's board to trust it, which matters, because the board and the move log are the answer.

Decisions that are product, not tech

Some rules in the spec look technical and aren't:

No winning and no losing. A puzzle is completed or it is not. A wrong move counts a mistake and the board carries on. The UI never says "won", "lost", "score" or "game over".
Play is a button. Tapping a board in the feed does nothing. Play opens a full-screen player. Scrolling past a puzzle should never start one.
Nobody sees another person's board, during play or after.
Sign-in is required. No anonymous access, so every request is attributable to an account that can be suspended. Email sign-in is a code, not a magic link, because a magic link signs in whichever browser opened it.
Two tables, never one. players are people. games are publishers run by the back office. A game cannot like, play, follow, be messaged or have a story. There is no user_id column anywhere, only player_id and game_id.

Each of those is written in decisions.json with its reason, so the build didn't have to decide them again.

How it was built

The first commit is dated 2026-09-18. I aimed at three things: the best UI and UX I could get, the best board generation, and an architecture that ships a new game without an app update. The last one is where most of this post came from. A game is a bundle and a row, the phone draws the board from the post, and the server checks the result with the same code.

If you've built something where the client reports a result, what do you replay or re-check on the server, and what do you simply trust?

1 million readings, 2 GB of RAM: Node.js typed arrays over JSON

Panth Patel — Tue, 06 Oct 2026 13:01:07 +0000

A report query that touched a million sensor readings kept killing our Node.js backend on a 2 GB droplet. I replaced the million JSON objects with two typed arrays and one class. The first version never ran out of memory and was 8x slower than JSON.parse. The second was faster than JSON.parse, and memory stayed flat.

I'm Panth, and I lead the software team at Oizom, where we build air-quality monitoring. This is the written version of a four-part screen recording I made while building it. The videos are below if you would rather watch me get it wrong first.

What a data point looks like

A single reading from a device looks roughly like this:

type DataPoint = {
  device: string;
  t: number;                       // epoch seconds
  d: Record<string, number>;       // decimals: co2, o2, pm25, temperature …
  s: Record<string, string>;       // strings: location, firmware, tag …
};

d holds the gas concentrations and other numbers. s holds whatever labels the device or the user attached. Any key can be present or absent on any reading. Thousands of devices report every minute, so a report query can easily touch a million of these.

The backend ran on a DigitalOcean droplet with 2 GB of RAM, and it kept dying with out-of-memory errors on exactly those queries.

Why a million objects is the problem

Three things happen when V8 holds a million of those objects, and none of them show in the code.

Every property access is pointer chasing. points[i].d.co2 is not one memory read. The array holds a reference to the point, which holds a reference to d, which is a hash map that hashes "co2", finds the slot and hands back the number. In C the compiler knows the offset of co2 before the program runs. In JavaScript every value is a reference to somewhere else.

Every object is a hash map. An object with ten keys is buckets plus a hash on every access. A million of them is ten million hashed lookups for one pass over the data.

Every object is garbage. Each {} is an allocation the garbage collector tracks. Create a million per request and the collector works harder than your code. The numbers are boxed doubles spread across the heap, so the working set is far bigger than the data.

So the fix is not to optimize the loop. The fix is to stop creating objects.

Treat the data as an image

Put timestamps on the Y axis and gases on the X axis, and the readings are a grid. Some cells are empty because that device didn't report that gas at that time. That is what an image is: a rectangle of numbers in one contiguous array, addressed by row * width + column.

            co2    o2    pm25   temp
t1        [ 412   20.9   35.2   26.1 ]
t2        [ 415    –     36.0   26.3 ]
t3        [  –    20.8   34.1    –   ]

Instead of an array of objects, the table keeps:

one Float64Array for all decimal values, times.length * gases.length long
one Int32Array for string values, holding an index into a dictionary of unique strings, because labels repeat on almost every row and there's no reason to store "Bangalore" a million times
three small arrays for the axes: timestamps, gas names, label names

A reserved value marks an empty cell. Time 0 is an unused row; an empty string is an unused column.

No object per reading, one allocation for the whole table. Reading co2 at row i is values[i * gases.length + gasIndex.co2]: the offset arithmetic JavaScript normally won't give you.

One class on top

The buffers are ugly to use directly, so everything goes through one class. This is the surface from the first video, and it barely changed later:

class DataPointTable {
  static create(rows: number, gases: number, labels: number): DataPointTable;
  static fromJSON(points: DataPoint[]): DataPointTable;
  static fromBuffer(buf: ArrayBuffer): DataPointTable;

  // axes
  times(order?: 'asc' | 'desc'): Iterable<number>;
  gases(): Iterable<string>;
  labels(): Iterable<string>;
  timeIndex(t: number): number;         // -1 if absent
  gasIndex(name: string): number;
  addTime(t: number): number;           // returns the row index
  addGas(name: string): number;
  removeTime(t: number): void;

  // cells
  get(ti: number, gi: number): number | undefined;
  set(ti: number, gi: number, v: number): void;
  row(ti: number, onlyExisting?: boolean): Iterable<[gas: string, v: number]>;

  // whole table
  toJSON(): DataPoint[];
  toBuffer(): ArrayBuffer;              // for sending to the browser
  compress(): DataPointTable;           // drop unused rows and columns
  stats(): { bytes: number; rows: number; used: number };
}

Nobody else in the codebase has to know there are buffers underneath. A report generator asks for a row and gets [gas, value] pairs. It never sees a Float64Array.

Version one: correct, and 8x slower than JSON

The first version kept rows sorted by timestamp, descending, because queries always want time order. So addTime had to find where the new row belonged, find the nearest free slot on either side, and shift every row in between by one. Adding a gas column was worse: every row moves to make room for the new cell, so the copy runs from the back of the buffer to the front, zeroing new cells as it goes.

I over-allocated to soften it: five spare rows and five spare columns at a time, so a burst of inserts doesn't reallocate each time. When the table is full, allocate a bigger one, copy, carry on.

Every function test passed, toJSON(fromJSON(x)) round-tripped, and compress() reclaimed the spare cells. Then I loaded a million points with thirty columns each. It never ran out of memory, which JSON always did at that size. It was also 8x slower than parsing the JSON.

What was slow

Not the typed arrays. The shifting.

The backend loads rows from the database, maybe runs one or two operations, then sends the data to the browser or feeds it into a report. It almost never inserts a row into the middle of a table. I was paying for ordered insertion on every load and getting nothing for it.

Two smaller things added to it. Finding a column by name was a linear scan of the gas array on every cell write, so a name → column index hash map came back, but only for the axes, which have thirty entries, not a million. And a binary search on the sorted timestamps didn't help, because the search was never the cost.

Version two: stop keeping order

The rewrite dropped the one assumption that hurt. Rows are no longer sorted. The table keeps two free lists instead:

private freeRows: number[];      // indexes of rows with t === 0
private freeCols: number[];      // indexes of columns with name === ''
private rowOf = new Map<number, number>();   // timestamp → row index
private colOf = new Map<string, number>();   // gas name → column index

addTime is now: if the timestamp is known, return its row; otherwise pop a free row and record it in the map. No search, no shift. If the free list is empty, allocate a bigger table, copy once and push the new rows onto the free list. removeTime zeroes the row and pushes its index back. No loop in the hot path.

A query knows how many rows it will return before it reads them, so the table is created at the right size up front, and the grow-and-copy branch almost never runs.

Order comes back only where it is read. times('desc') collects the live timestamps, sorts them once and yields them. One sort per query instead of one shift per insert.

	Memory with 1M points	Load vs `JSON.parse`
JSON objects	out of memory on 2 GB	baseline
Version one (sorted rows)	never ran out	8x slower
Version two (free lists)	flat	faster

The figure in the video description, roughly a 400% gain, is the load-and-serve path measured against the JSON version on the same box.

Skipping JSON entirely

That is why the class has toBuffer and fromBuffer. If the point is to stop building a million objects, serializing them to JSON for the browser undoes it. So the table serializes itself as its own buffers: a small header with the dimensions and the axis arrays, then the two value buffers as they already sit in memory.

On the server, database rows go straight into the table without a DataPoint[] ever existing. The buffer goes to the browser as is (base64 where it has to cross a text boundary), and the frontend rebuilds the same class from it. fromJSON and toJSON stay for tests and the odd tool; the production path never touches them.

What I'd tell past me

The win came from removing allocations, not from typed arrays as such. Typed arrays are just the only way JavaScript lets you allocate a million numbers in one go.
Don't maintain an invariant the read path doesn't need. Sorted rows cost me a full version.
Keep the buffers behind one class. Every place that touched a Float64Array directly would have been a place the rewrite had to visit.
Measure against what you're replacing, on the same box. "Never runs out of memory" isn't a win if it's 8x slower.

I had Claude write the function and performance tests for the second version. In the fourth video, the round-trip comparison catches a bug in compress() I wouldn't have found by hand.

Have you hit the point where plain objects stopped scaling in Node.js, and what did you move to?

Headless Claude Code asks, exits, then resumes on the answer

Panth Patel — Mon, 05 Oct 2026 13:01:00 +0000

When my coding agent needs a decision from me, it asks in the ticket and then stops. The process exits. My answer starts it again with claude -p --resume on the same session id, and the values I picked arrive as its next prompt.

The constraint: by default the orchestrator runs one agent at a time, and a run is capped at 240 minutes. A session sitting idle until I read my notifications would spend both.

I'm Panth, and I lead the software team at Oizom. This is from ticket-tracker, my open-source board where headless Claude Code sessions work tickets next to people. The orchestrator is the workspaces/ folder: one process per board, one Claude Code session per ticket.

The loop

The README draws it like this:

To do  ──orch claims──▶ In progress ──agent reports "review"──▶ Review ──owner──▶ Done
                            │  ▲
           agent asks a     │  │ the answer (form or a comment) resumes
           question ────────▼  │ the same session
                          waiting

"waiting" is not a stage on the board. The ticket stays In progress. It is a phase the orchestrator keeps in its own state file, next to the session id.

What the agent is told

Every agent gets the same brief. Step 3 of it:

If a real decision is the owner's to make (scope, design, anything destructive or outward-facing), call ask_question with blocking: true and real options. Then stop working and finish your turn with status: "waiting" and the question_id. Do not poll for the answer. The orch resumes this same session with the answer when it arrives.

ask_question puts a form card in the ticket thread: a title, optional context, and 1 to 10 fields (single choice, multiple choice, text, number, yes/no, date). A blocking question puts a "Waiting for you" badge on the ticket card and notifies whoever it is addressed to. When I submit it, the card locks and shows my answer.

The agent never decides on its own that it is finished. Its last message is structured output, enforced with --json-schema:

const OUTCOME_SCHEMA = {
  type: 'object',
  properties: {
    status: { type: 'string', enum: ['review', 'waiting', 'blocked'] },
    summary: { type: 'string' },
    question_id: { type: 'string' },
  },
  required: ['status', 'summary'],
};

Three ways to end a turn, and each one means something different to the orchestrator.

status	What the orch does next
`review`	Moves the ticket to Review and stops.
`waiting`	Heartbeat "Waiting for an answer", phase `waiting`, keeps the `question_id`. Nothing runs until a person answers or comments.
`blocked`	Carries on by itself, up to 3 times (`autoResume`), then posts on the ticket that it has stopped.

The split between the last two matters. waiting means a person is needed. blocked on a long ticket almost always means the turn ran out of room, so the orchestrator resumes it without asking anyone, a bounded number of times.

Why the session doesn't wait

Each run is one claude -p process. When it exits, the orchestrator posts a receipt with what the turn cost and marks the slot free, so the next ticket in To do can start. With maxAgents: 1, a session waiting for me would hold the only slot. Every other ticket on the board would wait behind my inbox.

There is a second reason in the brief. The session is headless, so when a turn ends the process exits and takes its background tasks with it. A turn either finishes its work or ends cleanly. There is no half-alive process in between for me to find later.

And nothing polls. The agent is told not to. The orchestrator doesn't sit on a timer either: it wakes on the board's revision, and the answer reaches it as an event.

How the answer gets back in

When I submit the form, the tracker puts a question_answered event in the agent's inbox. The orchestrator drains its inbox, sees the event for a ticket in waiting, and resumes the session with a prompt built from my answer:

answered: (t, q) => `The owner answered your question "${q.title}" on ${t.key}.

Values: ${JSON.stringify(q.answer?.values ?? q.values ?? {})}
Comment: …

Carry on with the work.`,

The resume itself is one flag. If the session file for that id still exists, the orchestrator passes --resume <id>; if not, it starts a fresh session and resets its cost to zero.

...(resume ? ['--resume', sessionId] : ['--session-id', sessionId]),

The agent picks up with its whole context: the files it read, its plan, the question it asked. It doesn't re-read the repo to work out where it was.

A few edges are handled on the way:

A comment instead of the form. If I reply in the thread rather than filling in the card, that also resumes the session, with my message in the prompt.
No slot free. If another ticket is running, the ticket's status line says "Got your reply · queued until an agent is free", so an answered question never looks ignored.
Cancelled or expired. The prompt says so, and tells the agent to read the thread, then go ahead with the most conservative option or ask again.
A missed event. Every fourth loop, a ticket still waiting has its question fetched directly, in case the event was lost.
The answer is progress. It resets the ticket's automatic-continuation count to zero, and so does any comment from me.

Cost stays honest across resumes

Claude Code reports total_cost_usd cumulatively across --resume. In a session that asked two questions, summing the reported totals would count the first turn's cost three times. So the receipt for a turn is the difference from the session's last reported total, and the session's running total lives in the orchestrator's state.

What it costs me

A question costs no compute while I'm away: there is no process to keep alive. The price is latency: the ticket sits until I answer, and nothing else picks it up. I'm fine with that. The questions an agent asks are the decisions I said were mine.

How does your agent setup handle a question it can't answer itself: does the session wait, or does it end the turn and come back?

Postgres triggers invalidate our Redis cache at Oizom

Panth Patel — Sun, 04 Oct 2026 13:01:20 +0000

Our Redis cache served stale data for up to 24 hours whenever a row changed somewhere the cache code couldn't see: another backend, an admin backend, a background worker, or someone editing the database by hand. The fix was to stop asking application code to remember invalidation and let Postgres announce every change itself.

I'm Panth, and I lead the software team at Oizom. Our Node.js backends sit on Postgres and Redis. This is how we got from plain cache-aside to trigger-driven invalidation, step by step, including the bug in the first version (every backend instance heard every change) and the table-backed listener that fixed it.

Here is where we started, the usual cache-aside:

async function getUser(userId) {
    const cacheResult = await cache.get(`USERS:${userId}`);
    if (cacheResult !== null) return JSON.parse(cacheResult);
    const result = await (...) // do some db call
    await cache.set(`USERS:${userId}`, JSON.stringify(result), "exp", 3600 * 24);
    return result;
}

So, how would you clear the cache? Because when a user updates their profile name, the changes don't seem to show up immediately.

async function updateUser(userId, data) {
    await (...) // do some db calls
    await cache.del(`USERS:${userId}`);
}
async function deleteUser(userId) {
    await (...) // do some db calls
    await cache.del(`USERS:${userId}`);
}

So, you think you've nailed caching, huh? But have you really? Let's break it down:

Why is the cache invalidation code stuck in updateUser and deleteUser? It's super easy to overlook, especially when you create a new function like updateUserForSomeNewTask.
What if updating or deleting a user also affects other stuff, like the user's organization or module expiry? If you're caching all that too, you'll need to handle invalidation for everything. Who can keep track of all that?
Even with a simple cache get, you have to add two layers of code—one before and one after your implementation—to check if the cache exists and then set it. It's a bug waiting to happen.
What if you change the output schema for getUser? You either change the key prefix from USERS: to USERS_V2: or flush the USERS: cache. Who's going to remember that?
The big one: what if a user is updated from another service? Like someone directly edits the database, or it happens through a different backend, admin backend, or background workers? You'll be stuck with a caching bug for 24 hours, wasting time debugging.
And what about when you want to create a function like getUsers(userIds)? If you think that's easy, try making caching logic for getModulesForUser(userId, moduleIds) where moduleIds = undefined to get all modules.

See how managing this can get tricky as you go along? These are real problems that happen more often than you'd think.

All of this can be sorted out with a good design system.

I'm going to talk about my caching and invalidation tricks using Redis and Postgres with NodeJs.

Let's tackle everything step by step.

Let's start by turning the caching code into a function.

// caching function for single object
// we can similarly create a abstract wrapper to cache multiple objects
function CacheFunc(func, getKey, expInSec) {
    async wrappedFn(...args) {
        const key = getKey(...args);
        const cacheResult = await redis.get(key);
        if (cacheResult !== null) return JSON.parse(cacheResult);
        const result = await func(...args)
        await redis.set(key, JSON.stringify(result), "exp", expInSec);
        return result;
    }
    async invalidate(...args) {
        const key = getKey(...args);
        await redis.del(key);
    }
    return Object.assign(wrappedFn, { invalidate })
}

const getUser = CacheFunc(async function (userId) {
    const result = await (...) // do some db call
    return result;
}, (userId) => `USERS:${userId}`, 3600 * 24)
async function updateUser(userId, data) {
    await (...) // do some db calls
    await getUser.invalidate(userId);
}
async function deleteUser(userId) {
    await (...) // do some db calls
    await getUser.invalidate(userId);
}

this looks way more promising.

But there's still a question: What do we do when a new lightweight user function needs caching and invalidation? so let's move all the invalidation stuff to an onUserChange function.

async function onUserChange(userId) {
    await Promise.all([
        getUser.invalidate(userId),
        getUserWithFewColumns.invalidate(userId),
        // add all the other, user caching functions
    ])    
}

const getUser = CacheFunc(async function (userId) {
    const result = await (...) // do some db call
    return result;
}, (userId) => `USERS:${userId}`, 3600 * 24)
const getUserWithFewColumns = CacheFunc(async function (userId) {
    const result = await (...) // do some db call
    return result;
}, (userId) => `LIGHT_USERS:${userId}`, 3600 * 24)

async function updateUser(userId, data) {
    await (...) // do some db calls
    await onUserChange(userId);
}
async function deleteUser(userId) {
    await (...) // do some db calls
    await onUserChange(userId);
}

It's like having a pub/sub system, where all the subscribers are inside the onUserChange function, and any functions that change user content, like updateUser and deleteUser, are doing the publishing.

There's still the problem of having to manually invalidate in updateUser and deleteUser. Someone might forget to invalidate the user cache when creating a new userUpdateWithModule function. So, we'll send an event from pg whenever changes happen and trigger the onUserChange function based on that event.

-- run this once
CREATE FUNCTION notify_change()
RETURNS TRIGGER AS $$
BEGIN
    PERFORM pg_notify(
        'internal_change', 
        jsonb_build_object(
            'old', row_to_json(OLD),
            'new', row_to_json(NEW),
            'table', TG_TABLE_NAME,
            'event', TG_OP
        )::text
    );
    RETURN NEW;
END;
$$ LANGUAGE plpgsql;

-- for all the tables you do caching for.
CREATE TRIGGER on_change
AFTER INSERT OR UPDATE OR DELETE ON public."USERS"
FOR EACH ROW EXECUTE FUNCTION notify_change();

const pool = new pg.Pool({...});
const client = await pool.connect();
async function listenToPgChanges() {
    const callbacks = {
        USERS: onUserChange,
        // add other tables
    }
    client.on('notification', function (e) {
        if (e.channel !== 'internal_change') return;
        try {
            const data = JSON.parse(e.payload);
            await callbacks[data.table](data);
        } catch (err) {
            console.error('Err in internal_change notification:', err)
        }
    })
    await client.query(`LISTEN internal_change`)
}
async function onUserChange(msg) {
    if (msg.event === 'INSERT') {
        // new possibilities.
        await sendWelcomeEmail(msg.new)
        return;
    }
    const userId = msg.old.ID;
    await Promise.all([
        getUser.invalidate(userId),
        getUserWithFewColumns.invalidate(userId),
        // add all the other, user caching functions
    ])    
}

const getUser = CacheFunc(async function (userId) {
    const result = await (...) // do some db call
    return result;
}, (userId) => `USERS:${userId}`, 3600 * 24)
const getUserWithFewColumns = CacheFunc(async function (userId) {
    const result = await (...) // do some db call
    return result;
}, (userId) => `LIGHT_USERS:${userId}`, 3600 * 24)

function updateUser(userId, data) {
    await (...) // do some db calls
    // No need to do any thing for invalidation.
}
function deleteUser(userId) {
    await (...) // do some db calls
    // No need to do any thing for invalidation.
}

This is awesome. We've tackled a bunch of issues all at once. If anyone updates the table from the database or some other backend, we can count on pg to send a notification about the changes, and our server will handle them accordingly. Plus, we've totally removed the need for invalidation in updateUser and deleteUser.

With just 3 simple steps, we've solved 90% of our problems. But there are still a few things we haven't figured out yet:

The code design isn't perfect yet. The invalidation call getUser.invalidate happens in the onUserChange function, but we want a proper callback using Pub/Sub.This all can be further solved using my library, i have abstract the code for anyone to use. so that you can spent time writing important business logic and not wonder the caching bugs.
We only have one caching wrapper to cache the function output. We need a solution for functions like getUsers that handle multiple users.
Changes in the output schema for caching functions. We need to check the schema before deciding if the cached output is valid, without changing the cache key prefix or manually flushing keys from Redis.

NOTE BUG: In the current setup, when we use pg_notify, it sends notifications to all the backend instances you have running. This means you'll end up invalidating the same cache multiple times because each backend instance listens to the event separately. It might be okay to invalidate the cache several times, but if you're using this for something like sendWelcomeEmail, it could be a problem. Don't worry, my solution will fix all these issues for you.

Here's the solution I came up with in the end:

https://jsr.io/@panth977/tools - This lets us set up Pub/Sub for calling internal functions.
https://jsr.io/@panth977/functions - This helps us define functions with zod input/output schemas and wrappers. It makes our code more consistent and easier to read.
https://jsr.io/@panth977/cache - An abstract wrapper with a bunch of hooks for single object caching, multiple object caching, collection caching, and more. (You'll need a cache that supports key → value and key → hash (field → value))
https://jsr.io/@panth977/cache-redis - A Redis adapter for the /cache package.

Let's tackle the rest step by step.

Let's use Pub/Sub from /tools (we'll be using zod as the schema validation library).

const zUSER = z.object({
    ID: z.number(),
    NAME: z.string(),
    // ...
})
const zEvent z.enum(['INSERT', 'UPDATE', 'DELETE'])
function zChanges(schema) {
    return z.object({ event: zEvent, old: schema.nullable(), new: schema.nullable() });
}
const TablesChanges = {
    // from @panth977/tools
    USERS: TOOLS.CreatePubsub(zChanges(zUSER))
}

async function onPgChanges() {
    client.on('notification', function (msg) {
        if (msg.channel !== 'internal_change') return;
        try {
            const data = JSON.parse(msg.payload);
            await TablesChanges[data.table].publish(data);
        } catch (err) {
            console.error('Err in internal_change notification:', err)
        }
    })
    await client.query(`LISTEN internal_change`)
}

TablesChanges.USERS.subscribe((msg) => msg.old && getUser.invalidate(msg.old.ID));
const getUser = CacheFunc(function (userId) {
    const result = await (...) // do some db call
    return result;
}, (userId) => `USERS:${userId}`, 3600 * 24);
TablesChanges.USERS.subscribe((msg) => msg.old && getUserWithFewColumns.invalidate(msg.old.ID));
const getUserWithFewColumns = CacheFunc(async function (userId) {
    const result = await (...) // do some db call
    return result;
}, (userId) => `LIGHT_USERS:${userId}`, 3600 * 24);

Perfect, this lets us directly subscribe to our changes without needing a middle function like onUserChange.

Let's use /cache. It already has the code abstracted with CacheFunc for Single Object and Multiple Object outputs, as well as Single Collection (and even Multiple Collection for those tricky situations).

// from @panth977/cache
const cache = new CACHE.CacheController({
    // from @panth977/cache-redis
    client: new RedisCacheClient(redis.createClient({...}), { delayInMs: 10, label: 'Redis' }),
    separator: ':',
    defaultExpiry: 3600 * 24,
    prefix: 'Dev',
    allowed: { '*': true },
    log: true,
});
TablesChanges.USERS.subscribe((msg) => msg.old && getUser.getHooks(msg.old.ID).del());
const getUser = CACHE.Wrap((userId) => new CACHE.HOOKS.SingleObject({
    cache: cache
        .addPrefix('USERS')
        .addPrefix(JSON.stringify({ userId }))
        .setDefaultExp(3600 * 24),
}), function ($, userId) {
    const result = await (...) // do some db call
    return result;
})
getUser(1001)
getUser(1002)

this might seem a bit much, but keep in mind CACHE.HOOKS has other hooks like:

const getUsers = CACHE.Wrap((userIds) => new CACHE.HOOKS.MultipleObject({
    cache: cache
        .addPrefix('USERS')
        .setDefaultExp(3600 * 24),
    ids: userIds,
}), function ($, userIds) {
    userIds = $.notFound; // only run for ids not found in cache
    // make sure you fetch all user data in single db request.
    const result = await (...) // do some db call
    // NOTE: use TOOLS.oneToOneMapping from @panth977/tools
    const dictResult = (...) // Make sure result is { [userId: number]: UserObject }
    return dictResult;
})
// lets say user:1001 & user:1003 exists;
getUsers([1001, 1002]) // { 1001: USER_DATA }
// --> will set cache for 1001
getUsers([1001, 1003]) // { 1001: USER_DATA, 1003: USER_DATA }
// --> will get 1001 from cache & set cache for 1003

// ------------ // ------------ //
const getUserDevices = CACHE.Wrap((userId, deviceIds) => new CACHE.HOOKS.SingleCollection({
    cache: cache
        .addPrefix('USER_DEVICES')
        .addPrefix(JSON.stringify({ userId }))
        .setDefaultExp(3600 * 24),
    subIds: deviceIds ? deviceIds : '*',
}), function ($, userId, deviceIds) {
    deviceIds = $.notFound === '*' ? undefined : $.notFound;
    const ignoreDeviceIds = $.found;
    // make sure you fetch all user devices data in single db request. 
    // if deviceIds = undefined, then fetch all the device
    // and ignore ones already found from cache.
    const result = await (...) // do some db call
    // NOTE: use TOOLS.oneToOneMapping from @panth977/tools
    const dictResult = (...) // Make sure result is { [deviceId: string]: DeviceObject }
    return dictResult;
})
// lets say user:1001 has device:OZ001, device:OZ002 & device:OZ003
getUserDevices(1001, ['OZ001', 'OZ005']) // { 'OZ001': DEVICE_DATA }
// will set cache for (1001 -> OZ001)
getUserDevices(1001) // { 'OZ001': DEVICE_DATA, 'OZ002': DEVICE_DATA, 'OZ003': DEVICE_DATA }
// will set cache for (1001 -> OZ002) & set cache for (1001 -> OZ003) 
getUserDevices(1001, ['OZ003']) // { 'OZ003': DEVICE_DATA }
// will get (1001 -> OZ003) from cache
getUserDevices(1001) // { 'OZ001': DEVICE_DATA, 'OZ002': DEVICE_DATA, 'OZ003': DEVICE_DATA }
// will get fully from cache.
getUserDevices(1001, ['OZ004']) // {}
// will figure form cache.

These APIs will help us cache almost all our cases.

Let's use /functions to make our code design more consistent. This will also make sure your cache has the right schema.

const getUsers = FUNCTIONS.AsyncFunction.build({
    input: z.number().array(),
    output: z.record(z.number(), zUSER),
    wrappers: (_params) => [
        CACHE.Wrapper({
            _params,
            getHook: ({ input }) => new CACHE.HOOKS.MultipleObject({
                cache: cache.addPrefix('USERS'),
                ids: input,
            }),
            updateInput: ({ info }) => info.notFound,
            useHook(hook) {
                // NOTE: [useHook] function gets executed once 
                // for this case it is when [getUsers] is being build.
                TablesChanges.USERS.subscribe(
                    (msg) => msg.old 
                        && hook({ input: [msg.old.ID] }).del()
                );
            },
        }),
    ],
    func({ input }) {
        const result = await (...) // do some db call
        const dictResult = (...) // Make sure result is { [userId: number]: UserObject }
        return dictResult;
    }
})

This takes care of all our code issues. We'll deal with the pg_notify problem next.

Now, let's tackle the last problem: listening to database changes.

-- drop the earlier function & trigger
DROP TRIGGER IF EXISTS on_change ON public."USERS";
DROP FUNCTION IF EXISTS notify_change();

-- we will store all the changes to a table
CREATE TABLE public."INTERNAL_CHANGES_V2" (
    "ID" SERIAL PRIMARY KEY,
    "TXID" TEXT NOT NULL DEFAULT txid_current(),
    "TABLE" VARCHAR(255) NOT NULL,
    "EVENT" VARCHAR(255) NOT NULL,
    "OLD" JSONB NOT NULL,
    "NEW" JSONB NOT NULL,
    "CREATED_AT" TIMESTAMP NOT NULL DEFAULT NOW()
);
CREATE INDEX idx_internal_changes_txid_table_created_at
ON public."INTERNAL_CHANGES_V2" ("TXID", "TABLE", "EVENT", "IDENTITY", "CREATED_AT");

-- we will maintain a table about which all changes have already been observed by a subscriber.
CREATE TABLE public."INTERNAL_CHANGES_LISTENED_V2" (
    "INTERNAL_CHANGES_ID" INTEGER NOT NULL REFERENCES public."INTERNAL_CHANGES_V2"("ID") ON DELETE CASCADE,
    "LISTENER_ID" VARCHAR(255),
    PRIMARY KEY ("INTERNAL_CHANGES_ID", "LISTENER_ID") 
);
CREATE INDEX idx_internal_changes_listened
ON public."INTERNAL_CHANGES_LISTENED_V2" ("INTERNAL_CHANGES_ID", "LISTENER_ID");

-- we will delete all the changes that past 20 mins
CREATE OR REPLACE FUNCTION delete_rows_in_internal_changes()
RETURNS trigger
AS $$
BEGIN
    DELETE FROM public."INTERNAL_CHANGES_V2"
    WHERE "CREATED_AT" < NOW() - INTERVAL '20 min';
    RETURN NULL;
END;
$$ LANGUAGE plpgsql;
CREATE TRIGGER trigger_delete_rows_internal_changes
AFTER INSERT ON public."INTERNAL_CHANGES_V2"
FOR EACH ROW EXECUTE FUNCTION delete_rows_in_internal_changes();

-- we will delete cleanups, can be avoided by CASCADE DELETE
CREATE FUNCTION delete_rows_in_internal_listened()
RETURNS trigger
AS $$
BEGIN
    DELETE FROM public."INTERNAL_CHANGES_LISTENED_V2"
    WHERE "INTERNAL_CHANGES_ID" = OLD."ID";
    RETURN NULL;
END;
$$ LANGUAGE plpgsql;
CREATE TRIGGER trigger_delete_rows_internal_listened
AFTER DELETE ON public."INTERNAL_CHANGES_V2"
FOR EACH ROW EXECUTE FUNCTION delete_rows_in_internal_listened();

-- on any changes added to the table notify all the clients
CREATE FUNCTION on_internal_change_added()
RETURNS TRIGGER AS $$
BEGIN
  PERFORM pg_notify('internal_change', '1');
  RETURN NEW;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER on_change_added
AFTER INSERT ON public."INTERNAL_CHANGES_V2"
FOR EACH ROW EXECUTE FUNCTION on_internal_change_added();

-- create on change generic function.
CREATE FUNCTION insert_changes()
RETURNS TRIGGER AS $$
BEGIN
    INSERT INTO public."INTERNAL_CHANGES_V2"("TABLE", "EVENT", "OLD", "NEW")
    SELECT TG_TABLE_NAME, TG_OP, row_to_json(OLD), row_to_json(NEW);
    RETURN NULL;
END;
$$ LANGUAGE plpgsql;

-- add the trigger to all your desired table.
CREATE TRIGGER on_change
AFTER INSERT OR UPDATE OR DELETE ON public."USERS"
FOR EACH ROW EXECUTE FUNCTION insert_changes();

function tableChangeSchema<S extends z.ZodRawShape>(
  schema: z.ZodObject<S>
) {
  return z.object({
    context: z.instanceof(FUNCTIONS.DefaultContext),
    event: z.enum(['INSERT', 'UPDATE', 'DELETE']),
    old: schema.nullable(),
    new: schema.nullable(),
  });
}
export const TablesChanges = {
  USERS: tableChangeSchema(zUSER)
  // add other tables...
}
const fetchLimit = 50;
const restartSec = 300;
const listenTimeout = 1000 * 30;
// this query will fetch all the new records form "INTERNAL_CHANGES_V2" 
// and add its observation entry in "INTERNAL_CHANGES_LISTENED_V2"
// it will also ignore all the rows added in transaction, but not yet commited. 
const query = `
WITH
SELECTED_CHANGES AS (
  SELECT "ID", "TABLE", "EVENT", "OLD", "NEW"
  FROM public."INTERNAL_CHANGES_V2" C
  WHERE 
    "TXID" NOT IN (
      SELECT backend_xmin::text
      FROM pg_stat_activity
      WHERE state IN ('active', 'idle in transaction') AND backend_xmin::text IS NOT NULL
    ) 
    AND NOT EXISTS (
      SELECT 1 
      FROM public."INTERNAL_CHANGES_LISTENED_V2" 
      WHERE "INTERNAL_CHANGES_ID" = "ID" AND "LISTENER_ID" = {{{SqlStr listenId}}}
    )
    AND "TABLE" IN (${Object.keys(InternalChanges).map(x => `'{x}'`).join(', ')})
  ORDER BY "ID" ASC
  LIMIT ${fetchLimit}
),
ADD_LISTENER AS (
  INSERT INTO public."INTERNAL_CHANGES_LISTENED_V2" ("INTERNAL_CHANGES_ID", "LISTENER_ID")
  SELECT "ID", ?
  FROM SELECTED_CHANGES
)
SELECT "TABLE", "EVENT", "OLD", "NEW" FROM SELECTED_CHANGES;
`;
// this function will constantly observe to pg changes.
export async function pgListenInternalChanges(): Promise<void> {
  console.log('LISTEN PG INTERNAL CHANGES');
  let lastResult: undefined | null | number | void = 1;
  while (typeof lastResult === 'number') {
    // if last observation was 0 rows
    // we will wait for any changes to happen
    if (!lastResult) await listenNewEntry();
    // we will create a [context]
    await FUNCTIONS.DefaultContext.Builder.forTask('Pg-Internal-Changes', async function (context, done) {
      // check & publish the changes.
      lastResult = await publish(context).catch(console.error);
      done();
    });
  }
  console.log('exited publishInternalChanges dew to some error, will start after a while');
  await new Promise((resolve) => setTimeout(resolve, 1000 * restartSec));
  return pgListenInternalChanges();
}
const pool = new pg.Pool({...});
const client = await pool.connect();
async function listenNewEntry() {
  // a promise that resolves on 1 msg received successfully!
  const newEntry = new Promise<any>(async (resolve, reject) => {
    try {
      client.on('notification', resolve);
      client.on('error', reject);
      // start listning!
      await client.query('LISTEN internal_change');
    } catch (err) {
      reject(err);
    }
  });
  newEntry.then(() => console.log('Listen a new Change!'));
  // fallback of some timeout, if no msg was reveived.
  const timeout = TOOLS.delay(listenTimeout);
  // check which one resolves first.
  await Promise.race([newEntry, timeout]);
  // stop listning!
  client.query('UNLISTEN internal_change').catch(console.error);
}
async function publish(context: FUNCTIONS.DefaultContext) {
  // run the query.
  const result = await pool.query(query, CONFIG.env.LISTEN_PG_INTERNAL_CHANGES);
  const jobs: Promise<void>[] = [];
  for (const row of result) {
    // publish the change.
    const promise = TablesChanges[row.TABLE as keyof typeof TablesChanges].publish({
      event: row.EVENT,
      old: row.OLD, 
      new: row.NEW,
      context: context,
    });
    jobs.push(promise);
  }
  // wait for all jobs to complete.
  await Promise.all(jobs);
  // return changes observed.
  return result.length;
}

That's it!

Now you know how we clear the cache.

How does your team invalidate a cache when the write comes from a service that doesn't know the cache exists?

52 commands, 3 doors: the app, REST and MCP share one write path

Panth Patel — Sat, 03 Oct 2026 13:01:13 +0000

My ticket tracker has three ways in: the web app, a REST API and an MCP server. Every write from all three goes through the same 52 commands, and the Firestore rules deny everything else. It costs 150 to 400 ms a write where a direct client write takes about 50 ms.

I'm Panth, and I lead the software team at Oizom. The tracker is ticket-tracker, my open-source board where coding agents work tickets next to people. This is the first decision in its plan, and the one that would cost the most to reverse.

The Firebase default I turned down

The usual Firebase shape is that clients write Firestore directly, security rules decide who may, and triggers do the side effects.

I kept half of it. Clients still read Firestore directly. Every write is a POST /api/{command}, and the rules deny writes except for a person's own pointers.

Two things decided it.

Nearly every write has a second document to keep in step: the key counter, the activity log, the other end of a link, notifications, webhooks.

And rules can't carry the permissions. Try writing this one as a rule somebody can maintain: a commenter may change a ticket's stage only between the stages in their grant, and only on tickets assigned to them.

The reason that mattered more

REST and MCP need the same logic anyway. With client writes, every rule would exist twice, once in firestore.rules and once in the API, and the two would drift.

So a command is defined once, as a spec in the shared package:

export const messagePost = defineCommand({
  name: 'messagePost',
  scopes: ['comments:write'],
  permission: "can(comment); ticket state == 'active'",
  errors: ['forbidden', 'not_found', 'conflict', 'too_large'],
  req: z.object({ /* ticket, body, replyTo, attachments … */ }),
  res: OkResSchema,
});

(The req is shortened here.) The registry holds 52 of these. The backend parses requests with the spec, and the frontend's command(name, input) is typed by the same map.

Three doors, one runner

Door	Who comes in	How it reaches a command
`/api/{command}`	the app, with a sign-in token	the body is the command's request
`/v1` REST	an orchestrator or agent, with a board token or OAuth	route, scope gate, names to ids, then the same command
`/mcp`	Claude and other MCP clients	each tool parses its input, then calls the same commands

All three end in one runner, and it does the same things in the same order:

registry lookup → scope narrowing → parse the request → idempotency claim
  → handler → parse the response → bump the board's revision → answer

The doors are routes in one HTTPS function. The alternative was a function per endpoint, and sixty functions means sixty cold starts, sixty deploy units and sixty minimum-instance bills. One service stays warm on the app's traffic alone, so REST and MCP calls land on warm instances.

Agents can do nothing people can't

A token only narrows. What it may do is its scopes intersected with can() for the principal it acts as, a person or one of their agents. The scope check at the door only answers early. The command decides.

A command that lists no scopes is app-only, and no token reaches it. There is no API-only write path that could drift from the app. And there is deliberately no MCP tool that deletes a ticket.

Every command also runs with who is acting and through which door (app, api or mcp), so a change made with an agent's token is attributed to that agent and to the token.

What the choke point bought later

Because every write passes through one runner, it became the place to announce that something on a board changed. After a command succeeds, the runner makes one small Realtime Database write to the board's revision. The app and the SDK listen to that node and ask for the delta, not poll for it. A replayed idempotent request bumps nothing, because nothing changed.

That came later, after I measured the bill and found the orchestrator's polling was 88% of all requests. It went into one place because the place existed.

The cost

A write takes about 150 to 400 ms, not about 50. Optimistic updates hide it in the app. Cold starts are covered by minInstances: 1 on the function in production.

That is the whole price: a slower write, hidden by optimistic updates, for one copy of every rule.

If your app has a UI, an API and an MCP server, do all three share one write path, or does each one have its own copy of the rules?

Agent health from a 60-second heartbeat: derived, never stored

Panth Patel — Fri, 02 Oct 2026 14:55:56 +0000

A coding agent that crashes can't report that it crashed. In my ticket tracker, the orchestrator sends a heartbeat every 60 seconds while an agent works, and a "working" status whose last beat is more than 75 seconds old shows as red on every screen, with no write from anyone.

I'm Panth, and I lead the software team at Oizom. The tracker is ticket-tracker, my open-source board where each ticket runs its own headless Claude Code session. This post is about one small piece of it: how the board knows an agent is alive.

The status that lies

The obvious design stores a status on the ticket: working, then done. The agent writes working when it starts and done when it finishes.

If the process dies in between, nothing writes anything. The ticket says working for as long as nobody looks into it. A stored status is only as true as the last thing that managed to write it, and a dead process writes nothing.

What the beat carries

The orchestrator sends the beat, not the agent. It is one call:

POST /v1/heartbeat
{ ticket?: KEY,            // omit = an agent-level beat, with no ticket
  state: 'working' | 'idle' | 'done' | 'error',
  message?: string,        // "Running tests (3/12)", up to 200 characters
  progress?: number }      // 0 to 1

It goes out every minute while the agent works and once more when the work ends. The message comes from the agent's task list: the orchestrator reads the list on every fifth beat and repeats the last message on the four in between.

A beat never touches the ticket document. It has its own small record per agent and ticket, so a beat a minute doesn't retrigger the ticket's search indexing or re-render everything that listens to the ticket.

Health is computed where it is read

The stored state has four values. The health on screen has six, and the extra ones come from the clock:

export const HEARTBEAT_INTERVAL_MS = 60_000;
export const HEARTBEAT_STALE_MS = 75_000;

export function deriveAgentHealth(status, now, staleAfterMs = HEARTBEAT_STALE_MS) {
  if (!status) return 'none';
  if (status.state !== 'working') return status.state;
  return now - status.lastBeatAt > staleAfterMs ? 'stale' : 'working';
}

75 seconds is one missed beat plus a little slack.

Stored state	Last beat	Shown as
working	75 s ago or less	green pulsing dot, "Working · Running tests (3/12)"
working	more than 75 s ago	red, "No signal for 3 min"
idle	any	yellow, "Idle · waiting for an answer"
done	any	grey, "Finished · 10:42"
error	any	red, "Stopped with an error" and the message
none yet		nothing

Only working can go stale. Idle, done and error are statements that stay true until the next beat. working is a claim that has to be renewed.

This one function is in the shared package. The card, the ticket header, the People & roles page and the Agents page all call it, so they can't disagree about an agent. When several agents are on one ticket, the card shows the loudest: error first, then no signal, then working, idle and finished.

The 15-second clock

A derived value only changes when something recomputes it. If no new beat arrives, no data arrives either, so the screen needs its own clock:

export const HEALTH_TICK_MS = 15_000;

export const healthClock = readable(Date.now(), (set) => {
  const id = setInterval(() => set(Date.now()), HEALTH_TICK_MS);
  return () => clearInterval(id);
});

15 seconds is a quarter of the beat interval, so the longest a dot can be wrong is 15 seconds. It is one interval shared by every dot on screen, and it stops when the last subscriber goes.

What it cost, and what I changed

The first version kept each beat stream as a Firestore document. I measured the project's bill from 23 to 26 September 2026 and the heartbeat was on it twice:

1,440 writes per agent per day, each a Firestore transaction through a function, followed by one read in every open tab.
A scheduled sweep that ran every minute to notice silence: 4,261 runs in three days.

Two changes came out of that.

Beats moved to the Realtime Database, which bills bandwidth and not operations. A beat is now about 100 bytes. The shape everything above the database reads stayed the same, so no screen changed.

The sweep stopped looking for silence. Noticing silence never needed a server, because staleness is now - lastBeatAt wherever the beat is read. The sweep now runs every three minutes and does the one thing that does need a server: if a working agent has been silent for five minutes, it tells the agent's owner, once per silence, because nobody may have the board open. The next beat re-arms it.

If you are building one

Store the facts: the last state the agent claimed and when it claimed it. Derive the judgement, alive or not, at read time, in one function every screen shares. Then give the screen a clock, or the judgement never updates.

How does your agent setup tell you a run died: a timeout on the server, or something you work out from the last thing it said?

await on a sync function: 2 ms to 51 ms for 1M calls in Node.js

Panth Patel — Thu, 01 Oct 2026 13:00:55 +0000

1,000,000 calls to an empty sync function     2 ms
the same calls with await in front           51 ms

That is Node.js. In Chrome the same loop went from 3 ms to 1,500 ms. The function does nothing and is not async; the whole difference is the await.

I'm Panth, and I lead the software team at Oizom. I measured this in May 2025, after Prime said in a video that even sync code behind a Promise waits for the event loop. I didn't believe it, so I tested it.

An async function starts synchronously

My first guess was that an async function with nothing to wait for would just run inline.

async function a() {
    console.log('a');
}
console.log('1');
setTimeout(() => console.log('t1')); // runs later, after the current code
a(); // sync body, so it should run right here
setTimeout(() => console.log('t2'));
console.log('2');

1
a
2
t1
t2

It does. a prints between 1 and 2.

`.then` and `await` do not

That could just be the async keyword, so the next test used a Promise constructor, .then and await.

async function a() {
    console.log('a1');
    const p = new Promise((r) => {
       console.log('p>>>')
       r();
    }).then(() => console.log('p<<<'));
    console.log('a2');
    await p;
    console.log('a3');
}
console.log('1');
setTimeout(() => console.log('t1'));
a();
setTimeout(() => console.log('t2'));
console.log('2');

1
a1
p>>>
a2
2
p<<<
a3
t1
t2

The Promise body runs at once (p>>>), but the .then callback and everything after await wait until the current synchronous code has finished: p<<< and a3 print after 2. They still run before the timers (t1, t2). The Promise resolved immediately and the work was still deferred.

Measuring what the deferral costs

Five ways to call an empty function a million times:

a sync function, called directly
a sync function, called with await
an async function, called without await
an async function, called with await
an async function, called without await, then await Promise.all on all the results

function sf() {}
async function af() {}
function run(fn, next) {
  const start = Date.now();
  function done() {
    console.log(Date.now() - start + "ms");
    if (next) next();
  }
  fn(done);
}
function case1() {
  run((done) => {
    for (let index = 0; index < 1000_000; index++) {
      sf();
    }
    done();
  }, case2);
}
function case2() {
  run(async (done) => {
    for (let index = 0; index < 1000_000; index++) {
      await sf();
    }
    done();
  }, case3);
}
function case3() {
  run((done) => {
    for (let index = 0; index < 1000_000; index++) {
      af();
    }
    done();
  }, case4);
}
function case4() {
  run(async (done) => {
    for (let index = 0; index < 1000_000; index++) {
      await af();
    }
    done();
  }, case5);
}
function case5() {
  run(async (done) => {
    const promises = [];
    for (let index = 0; index < 1000_000; index++) {
      promises.push(af());
    }
    await Promise.all(promises);
    done();
  });
}
case1();

	1. sync fn, direct	2. sync fn, await	3. async fn, no await	4. async fn, await	5. async fn, Promise.all
Chrome	3ms	1500ms	33ms	1559ms	—
Chrome, fresh start	3ms	1289ms	33ms	1477ms	388ms
Node.js	2ms	51ms	7ms	46ms	171ms
Deno	1ms	49ms	7ms	42ms	183ms
Bun	2ms	73ms	19ms	74ms	130ms

Every runtime pays for the await, and Chrome pays the most. A fresh Chrome start did not change that, so it was not my open tabs.

With a body in the function

Runtimes might special-case empty functions, so the second run gave both functions one line of work, cnt++, and reset the counter after each case:

let cnt = 0;
function sf() {
  cnt++;
}
async function af() {
  cnt++;
}
function run(fn, next) {
  const start = Date.now();
  function done() {
    cnt = 0;
    console.log(Date.now() - start + "ms");
    if (next) next();
  }
  fn(done);
}

	1. sync fn, direct	2. sync fn, await	3. async fn, no await	4. async fn, await	5. async fn, Promise.all
Chrome, fresh start	3ms	1307ms	32ms	1493ms	396ms
Node.js	10ms	50ms	8ms	46ms	170ms
Deno	5ms	51ms	7ms	44ms	181ms
Bun	4ms	68ms	20ms	76ms	131ms

Same picture. The cost is the await, not the empty body.

What I took from it

I didn't know the cost of this before I measured it. It also explained why people who write Rust and Go say async is hard, when it had always looked easy to me in JavaScript. It is easy to write, and it has a price: in these runs, putting await in front of code with nothing to wait for made the loop at least 5x slower in every runtime, and several hundred times slower in Chrome.

For high-performance code, that pushed me towards sync callbacks on hot paths. I am thinking about changing my libraries and framework to support sync callbacks fully, and maybe rewriting the backend from scratch to use them.

Where has an await on something that was already there cost you time?

One stack per ticket: why our coding agent works on a DB copy

Panth Patel — Wed, 30 Sep 2026 14:25:08 +0000

Every ticket on our board gets its own stack: a branch in every repo, its own services, its own copy of the dev database and its own preview URL. We built it because coding agents made my developers faster, and the mistakes moved out of the code and into the branches around it.

I'm Panth, and I lead the software team at Oizom, where Envizom is the platform. This is why our agent pipeline isolates per ticket, and what the isolation buys beyond running tasks in parallel.

Where the mistakes were

With an agent, one developer can keep three tasks in flight. That holds while all three go into the same branch and the same release. Once they are due in three different releases, the developer juggles repos and branches and has to remember which change belongs to which PR.

The development was usually fine. The mistakes were a change on the wrong branch, or a fix that only worked on one machine. As agents got faster I saw more "works on my machine" on my team, and client expectations kept going up at the same time.

What was missing was a sandbox you could fork for one task and turn into a PR when it was done.

What a ticket gets

When a developer drags a ticket to Approved, orch, our orchestrator, provisions a workspace for it:

Part	What the ticket gets
Code	a fresh branch in every repo, named after the ticket
Services	its own backend, drivers, simulator and frontend
Data	a copy of the dev database
Access	a private preview URL, with an HTTPS certificate issued on demand

An agent does the work inside that workspace. The developer talks to it only through the ticket thread, tests the preview, and drags the ticket to Git Push when it is right. Until then, nothing the ticket does reaches the shared dev branch.

Isolation is the safety decision

A stack per ticket looks like a way to run things in parallel. That is half of it. The other half is safety.

An agent that runs a bad migration or deletes the wrong rows does it to the ticket's copy of the database. An agent that breaks the backend breaks the ticket's backend. Nobody else's work is touched, because nobody else's work is in that box.

The shared environment is reached only at Git Push, and that step is a script, not the agent. Orch commits the ticket branches, merges dev into them, opens and merges the PRs, waits for CI, rolls the new images onto the dev VM and runs health checks. If the VM is unhealthy afterwards, orch rolls it back to the previous images, reverts the merges and tells the thread what happened.

All of it stops at dev. Production goes through a separate path where people make the call.

Independent timelines

The second thing isolation gives us is time. A ticket can sit in QA for a week while three others ship. Its branch, its data and its thread wait for it, and nothing else waits on it. Three tickets due in three releases are three separate stacks, and each one ends in its own PR.

It is also why the audit trail holds together. What was asked, what was built, which preview was tested and what feedback went back all sit on one ticket, not mixed with another ticket's work.

What made the copies cheap

A database copy per ticket only works if copying is cheap. In Envizom V3, which we are rebuilding from scratch, the backend runs in dev without a single extra database credential. Every store has a dev driver:

Store	Prod	Dev
Main DB	Postgres	SQLite
Assets	S3	SQLite
Device data	a time-series database	SQLite
Pub/sub	MQTT	a service built into the Go backend
Cache	Redis	SQLite

SQLite runs inside the Go process, so the dev kit needs no extra containers, and copying a database means copying a few files. That change made our sandboxes about 10x cheaper and faster than sandboxes with full databases.

The dev VM that holds the devboxes and the ticket stacks costs about ₹4–6k a month and handles six tickets in parallel.

If you are building one

Start with isolation, not with the agent. If a task can't run in its own branch, with its own services and its own data, nothing else in the pipeline is safe. Then put the agent inside the box, and keep every step that leaves the box scripted.

If your team runs a sandbox per branch or per ticket, which part was hardest to copy: the code, the services or the data?

$402 on one ticket: cost per turn in headless Claude Code

Panth Patel — Mon, 28 Sep 2026 13:00:28 +0000

One ticket on my board reached $402 over nine agent runs, and nothing in the app said so. Putting the cost on every turn has one catch: Claude Code's total_cost_usd is cumulative across --resume. Run 8 made one API call with zero output tokens and reported the same $392.83 as run 7.

I'm Panth, and I lead the software team at Oizom. This is from ticket-tracker, the tracker I open-sourced, where AI agents are board members and a small orchestrator turns each ticket into a headless Claude Code session.

How a ticket becomes a session

The orchestrator (workspaces/lib/orch.mjs, about 600 lines, zero dependencies) runs one headless Claude Code session per ticket. Each time the agent has something to do, it starts claude -p once: a fresh ticket, rework, an answer to a question, a new comment, or carrying on by itself. That is one turn. The process exits, and the last line of its stream-json output is a result line.

The first turn creates the session with --session-id. Every later turn on the same ticket continues it:

const resume = e.session_id && fs.existsSync(sessionFile(e.session_id));
const sessionId = resume ? e.session_id : randomUUID();

const args = [
  '-p', prompt,
  '--output-format', 'stream-json', '--verbose',
  ...(resume ? ['--resume', sessionId] : ['--session-id', sessionId]),
  // ...
];

The session keeps its history, so the agent picks up where it stopped. That is the point of resuming. It is also why the cost number misleads.

The trap

The result line carries total_cost_usd, usage (input, output and cache tokens), num_turns and modelUsage. Before the change, the orchestrator already read total_cost_usd off every result line and wrote it to a local log. Nothing in the app showed it.

Putting the number on the ticket looks like a one-liner: post total_cost_usd when the run ends. It isn't, because that field is the session's running total, not the run's. Ticket OCZ-5 shows it plainly. Run 8 did almost nothing, one API call and zero output tokens, and reported $392.83. So did run 7.

Read naively, that line says run 8 cost $392.83. Add those lines up and every earlier run is counted again on each later turn.

The fix: keep the last total, post the difference

The orchestrator keeps per-ticket state in a JSON file. Two fields handle cost: session_usd, the last total that ticket's session reported, and session_usage, the last token counts. When a turn ends:

const prevUsd = e.session_usd ?? 0;
const costUsd = Math.max(0, r.total_cost_usd - prevUsd);

const now = {
  input: u.input_tokens ?? 0,
  output: u.output_tokens ?? 0,
  cache_read: u.cache_read_input_tokens ?? 0,
  cache_write: u.cache_creation_input_tokens ?? 0,
};
const prev = e.session_usage ?? { input: 0, output: 0, cache_read: 0, cache_write: 0 };
const usage = Object.fromEntries(Object.keys(now).map((k) => [k, Math.max(0, now[k] - prev[k])]));

e.session_usd = r.total_cost_usd;
e.session_usage = now;
saveState();

The turn's cost is the new total minus the old one, clamped at zero. The token counts get the same treatment. Then the new total is saved for the next turn.

Three cases decide whether the numbers stay honest:

Case	What the orchestrator does
New session (first turn, or the session file is gone)	Starts a fresh session id and resets `session_usd` to 0 before the run
Resumed session	Subtracts the last reported total
Run dies without a result line	Posts no receipt. Its spend shows up in the next turn's difference, which is still correct: it was spent on this ticket

The resume check matters more than it looks. The orchestrator only resumes if the session's .jsonl file still exists under ~/.claude/projects/. If it doesn't, the turn starts a new session, and a new session counts from zero. Subtracting the old total from it would wipe that turn's cost.

Where the number goes

Money spent on a ticket is a fact about the ticket, so it goes where the ticket's other facts go. When a run ends, the orchestrator posts one message on the ticket, the turn receipt. In the design doc's example, the body reads:

Turn 3 · review · $1.24 · 12 min

Beside the text it carries a run field: the turn number, the outcome (review, waiting, blocked, failed, stopped or timeout), cost_usd for this turn, session_usd as Claude Code reported it, duration, API calls, model and the token deltas. Both numbers are kept on purpose. The turn cost is what the person reading the thread cares about. The session total is what you check the arithmetic against.

The server stores the receipt on the message and, in the same write, adds it to the ticket's cost, the board's cost and the day's row the Analytics view draws. So the card shows the spend next to its other signals, and the board shows cost per day and which tickets cost the most.

Only the orchestrator posts receipts. The app's comment box never does. Each receipt goes out with an Idempotency-Key made from the ticket and the run number, so a retried request doesn't count a turn twice.

What changed

Cost per turn in the thread is a deliberate design choice, not a debug feature. The person who asked for the work sees what each turn of it cost, in the same thread where they asked.

The lesson for anyone running Claude Code headless: treat total_cost_usd as a meter reading, not a bill. Store the last reading per session and bill the difference.

If you run Claude Code from scripts or CI, where does the cost of a single run end up for you, and does it account for --resume?

5 seconds to 30 ms: rebuilding IDW heatmaps in Go

Panth Patel — Sun, 27 Sep 2026 13:01:18 +0000

Our air-quality heatmaps took about 5 seconds per image, on an hourly Python cron that used 4 GB of RAM and 2 CPUs and still wasn't enough. The rebuild is a Go service that makes them on request: 20 images in 30 ms, for any past time range.

I lead the software team at Oizom, an air-quality monitoring company (the platform is Envizom). This is how the heatmap backend was rebuilt there, including the bottleneck I didn't expect: PNG encoding.

How the old version worked

We used the IDW (inverse distance weighting) algorithm with wind speed and direction to figure out the value for each spot.

We set up a heatmap config in our database.
A cron job ran every hour.
We grabbed all the configs.
For each config, we had boundaries, known devices, limits, and color codes.
We pre-computed a grid of small 1km x 1km boxes and stored it in the CDN.
We used the center of each box in the pre-computed grid as the unknown value.
We knew each gas parameter for all devices, plus real-time geolocation, wind speeds, and directions.
Using IDW with wind effects, we calculated the value for each box in the grid.
Colors were added to the grid based on user-defined limits.
A Base64 PNG image was created and stored in a time-series database.
This image was served to the frontend when requested.

This was written in Python and used up a ton of resources (4GB RAM, 2 CPUs, 1-2 instances depending on the load), and it still wasn't enough. Each image took 10-20 seconds to process. It just wasn't fast. Back then, heatmap was a brand new feature, and we only had 3 configs, so it clearly wasn't scalable. Plus, on closer look, the wind effects weren't even used correctly.

A weekend proof of concept in the browser

When I found out about this, I suggested generating the heatmap on the frontend. My boss thought the idea was nuts. He didn't believe it was even possible. My argument was simple: today, there are tools like Canva and Figma, and many others that let you edit photos and videos right in the browser. There are even proper 2D games and simulations being played in the browser, and some resume websites are like 3D games. Technology has improved, and coding patterns and styles have changed a lot in the past 2 years, so I thought it was doable. He was convinced and decided to hire an intern to do the R&D. Typical corporate.

This really bugged me because I've always wanted to dive into image generation projects, and this seemed like my golden opportunity. So, I spent a weekend putting together a POC for a heatmap in the browser. It worked.

https://youtu.be/2wsYBaBtCY4

This was just the start. I still needed to add wind effects, map (long, lat) to (x, y) coordinates, include user-defined boundaries (from a GeoJson polygon), and finally, add gradient colors.

Boss saw it, boss liked it, and everyone was happy.

He still had a good point. We don't want to do this on the frontend because our frontend runs on old phones, corporate laptops, and sometimes even TVs—in other words, places without much computing power. So, maybe we can set up a proxy server to handle all the heatmaps and generate them on the fly.

Node.js, then Go, then the real bottleneck

So, I went ahead and set up a Node server and built the whole thing. It worked great. Turns out, when you use gradient colors, there's not much difference between a 150px resolution and a 1000px resolution, except for having sharper edges.

Test case: each request with 100px resolution, 10 known points with 40 images. Each load ran for 5 seconds.

In Node.js the results were already so much better than anything we had before. After this, I decided that to make it even faster, we should use a lower-level language. We also wanted to ensure the language is easy for other developers to understand. So, I chose GoLang. Go was faster and throttled less.

Something still felt off; it shouldn't take this long. After adding time logs for each function, I discovered the bottleneck was Base64 PNG encoding. Each image took 1-3ms, which was 80% of the time. Switching to JPEG boosted performance dramatically.

Load (5 s)	Node.js	Go, Base64 PNG	Go, JPEG
5 req/sec	108ms-874ms (average 419ms)	80ms-175ms (average 114ms)	18ms-56ms (average 29ms)
50 req/sec	97ms-26,588ms (average 14,687ms, with 2 req/sec failing)	157ms-265ms (average 458ms)	29ms-132ms (average 88ms)
500 req/sec	172ms-37048ms (average 22,152ms, with 432 requests failing)	241ms-10,891ms (average 4,405ms, 296 req/sec failing)	44ms-929ms (average 496ms, 80 req/sec failing)

The only downside to JPEG is that it cannot create transparent images, as it lacks an alpha channel. However, we have a straightforward solution: let the backend handle all the computational tasks, while the frontend focuses on one task—masking the image and selecting only the required portions. This can be accomplished in the frontend using JavaScript, within 10-30ms. If the client can render GeoJSON, maps, and images, it can also perform image masking.

This approach also offers an advantage: the difference between a 150px and a 1000px image is that the 1000px image has sharper edges. To achieve sharper edges for a 150px image, we generate an image with an additional 2px around the boundary and crop the necessary section in the frontend. This results in sharper edges.

What the new pipeline does

The frontend creates a config from backend APIs and stores it in the database.
The frontend requests images for a config, gas parameters, and given time bounds.
The backend fetches all the resources and sets up a payload to send to the GoLang heatmap server.
In the GoLang server: It takes all the boundary points in (long, lat), maps them to (x, y) within 0-1, creates a grid of boxes based on resolution, and finds the ones within the polygon.
It converts all the known points/devices' locations from (long, lat) to (x, y) based on grid transformation.
This grid context is used to precompute the weight of each known point on each target pixel.
Based on the given colors, we create a gradient of values ranging from 0-256 integers.
We set up the encoder and precompute the (x, y) to (pixel position) in the data image array.
For each snapshot of values, we quickly compute the grid's value using precomputed weights.
We magnify each value to bring it between 0-256.
We fill the RGB values in the data image array.
We use the encoder for the base64 image.
These images are sent back to the core server.
The core server sends them back to the client.
The frontend masks the required portion using geo boundaries. Done!

Before and after

Images are generated on the fly, so we can now create past images too. We use fewer resources, which makes everything cheaper overall. Plus, it's finally scalable and versatile.

Heatmaps were only available after they were created → Now we can get heatmaps for any time range.
For a fixed 1-hour average → You can completely customize it.
5 seconds per image → Now it's 30 ms for 20 images.
Python → GoLang.
Complex scheduler-based solution → Simple request/response-based solution.
Fixed options → Custom options for resolution, distance power, wind power, and wind effect.

Finally:

Of course, the data used to create this heatmap is fake and random. But this is how it would look.

The fix I didn't see coming wasn't the language or the algorithm. It was a time log on every function, which showed the image encoder taking 80% of the time. What was the last bottleneck you found that way, somewhere you weren't looking?

The ticket is the interface: how our developers ship without a laptop

Panth Patel — Sat, 26 Sep 2026 00:25:23 +0000

Neither I nor my developers need a laptop to ship code anymore. That sounds like a stunt, so here is the boring version: on our team a developer's working day happens inside a ticket thread, and the parts that make that possible are mostly scripts, not AI.

This post is the long version of the short video below. It covers what the pipeline does, how the pieces fit, what we deliberately kept dumb, and where we drew the line on automation.

The problem we were actually solving

I lead the software team at Oizom, an environmental monitoring company. Our platform is called Envizom, and it is several repos: hardware drivers, a simulator, a backend, a frontend. Getting a working local setup took a new developer days, and even for the rest of us "does it work on your machine" was a real question.

When we started using AI coding agents, the first thing we noticed was not the speed of the agent. It was the waiting. One developer, one agent, one task at a time, sitting there watching a terminal. The agent was fast. The developer was the bottleneck.

We wanted five things:

A developer should be able to hand off a task and go do something else.
Every task should run in isolation, so an agent cannot break anyone else's work, and so features can live on different timelines. One ticket can sit in QA for a week while three others ship.
Nothing about "we use agents" should weaken the normal engineering process: branches, commits, pull requests, review, CI.
Every prompt should be stored with the work it produced, so we can review and coach how people ask for things.
The ticket should be the audit trail: what was asked, what was built, what was tested, what feedback was given, in one place.

The ticket is the interface

We already had our own ticket tracker. So we made the ticket the only thing a developer touches.

A developer writes what they want in a ticket, in plain English, and drags it to Approved. That is the whole spec. There is no IDE open, no terminal, no prompt window.

On our dev VM each developer has their own devbox: VS Code running in the browser, with our orchestrator inside it. We call it orch. Every developer is paired with their own agent, and their orch only picks up tickets assigned to that agent. So the board is shared, but the machines and the agents are not.

Each ticket gets its own full stack

When orch sees an approved ticket it provisions a workspace for it:

a fresh branch in every repo, named after the ticket
its own backend, drivers, simulator and frontend, running in that workspace
a copy of the dev database, so the ticket can change data freely
a private preview URL for the ticket, with an HTTPS certificate issued on demand

This is the part that made everything else possible. Because every ticket is fully isolated, a developer can have several tickets in flight at once, and agents cannot step on each other. If an agent does something silly to the database, it did it to a copy.

An agent does the work, but only from the thread

Inside that workspace an AI coding agent picks up the ticket. Orch gives it the ticket text and the workspace, and the agent does the actual engineering work.

The developer only ever talks to the agent through the ticket thread. When the agent is done it posts the preview link and moves the ticket to QAQC. The developer opens the preview, tests it, replies with feedback in the same thread, and moves the ticket back. The same agent, with the same context, picks up where it left off.

In the video I asked for a camera layout change on a device page. The agent shipped it, posted the preview, I replied "also handle more than 4 cameras with a horizontal scroll, and set up 8 test cameras on this device", and it did both, including creating the test data in the ticket's own database copy.

Two of the design goals pay off here, and they are the ones people underestimate:

Every prompt is saved. The thread is the prompt history. I can read how each person on the team asks for things and coach them on it. That has been more useful than any prompting guide.
The thread is the audit trail. What was asked, what was built, which preview was tested, what feedback was given. All in one place, attached to the ticket. Because each ticket has its own stack, that trail is also self-contained: a ticket can pause in QA for days without blocking anything else.

Shipping is a drag-and-drop

When the developer is happy they drag the ticket to Git Push. From here on, no agent is involved. Orch:

commits the work on the ticket branches
merges the current dev branch into them
opens a pull request in each affected repo
merges the pull requests
posts the PR and commit links back into the ticket thread
waits for CI
rolls the new images onto the dev VM
runs health checks against the VM

If the VM is not healthy afterwards, orch rolls the VM back to the previous images and reverts the merges. On its own. Then it tells the thread what happened.

When it is healthy, the ticket moves to Completed and the developer gets a notification. In the video that is the whole ending: two notifications, and the change is live on dev.

What is AI and what is not

This is the part I am proudest of, and the part I think most teams get backwards.

Roughly 90% of this pipeline is plain scripted code. Watching the board, provisioning the stack, copying the database, issuing certificates, driving git, opening PRs, waiting on CI, deploying, health checks, rollback. None of that is done by an agent. It is deterministic, it is tested, and when it breaks I can read a log and fix it.

The agent does exactly one thing: the engineering work inside an isolated workspace, in response to a human's words in a ticket.

We tried the other way first, with the agent doing more of the operational steps. It was slower, more expensive, and worse at exactly the tasks that need to be boring. An agent deciding how to merge is not a feature. A script that always merges the same way is.

What it gave us

One developer runs several tickets in parallel instead of babysitting one agent.
No local setup. New people are productive on day one. The laptop can be closed.
Every feature still gets its own branch, commits, PR and review. Nothing about our process got looser.
Every prompt the team writes is stored with the ticket.

Three deliberate choices

People sometimes read these as gaps. They are decisions.

Cost is visible on every turn. Each agent turn posts its cost into the ticket thread. That is intentional. The person asking sees what the ask cost, right where they asked it, and it changes how they write the next one.
QA is human. The developer tests the preview and decides whether the ticket moves forward. That step is where we check the thing that was built is the thing that was asked for. An agent grading its own work would remove the one review that matters most.
This pipeline is for dev only. Rollback, auto-merge, VM updates: all of it stops at the dev environment. Production goes through a separate path where real people make the call, on a slower cadence. We do not want automation deciding what reaches production, and we do not want a fast feature list to become the goal.

What is next

The one thing I keep looking at is the dev VM itself. The per-developer devboxes and the per-ticket stacks all run on one rented box. It costs about ₹4–6k a month and comfortably handles six tickets in parallel, which is fine at our size, but it is still one machine and it is still rented.

The plan is almost embarrassingly simple. We have a pile of laptops. Turn them into VMs. The whole point of this pipeline is that your main laptop can be closed while the work happens, so the machine doing the work might as well be an old laptop on a shelf in the office. A one-time purchase of in-house hardware will never cost what a cloud VM costs over a year, and it keeps the same isolation model: each developer's devbox on its own box.

We have not done this yet. When we do, I will write it up.

If you want to build something similar

Start with isolation, not with the agent. If every task cannot run in its own branch, its own services and its own data, none of the rest is safe. Then make the handoff surface something your team already uses. For us that was the ticket. Then, and only then, put an agent inside the box.

And keep the box scripted. The agent should be the smallest part of the system.

If you have questions, ask in the comments. I am collecting them for a follow-up post.

I lead the software team at Oizom, where Envizom is the platform that turns data from air-quality and environmental monitors in 80+ countries into something cities and industries can act on. The walkthrough video is on YouTube; find me on LinkedIn.

DEV Community: Panth Patel

849 KB of spec before any code: building Octupuz, a puzzle feed

What Octupuz is

The spec came first, and the summary failed

The backend is Instagram, the frontend is the game

A board has to come out the same everywhere

A time on a post means the board was solved

Decisions that are product, not tech

How it was built

1 million readings, 2 GB of RAM: Node.js typed arrays over JSON

What a data point looks like

Why a million objects is the problem

Treat the data as an image

One class on top

Version one: correct, and 8x slower than JSON

What was slow

Version two: stop keeping order

Skipping JSON entirely

What I'd tell past me

Related reading

Headless Claude Code asks, exits, then resumes on the answer

The loop

What the agent is told

Why the session doesn't wait

How the answer gets back in

Cost stays honest across resumes

What it costs me

Postgres triggers invalidate our Redis cache at Oizom

52 commands, 3 doors: the app, REST and MCP share one write path

The Firebase default I turned down

The reason that mattered more

Three doors, one runner

Agents can do nothing people can't

What the choke point bought later

The cost

Agent health from a 60-second heartbeat: derived, never stored

The status that lies

What the beat carries

Health is computed where it is read

The 15-second clock

What it cost, and what I changed

If you are building one

await on a sync function: 2 ms to 51 ms for 1M calls in Node.js

An async function starts synchronously

.then and await do not

Measuring what the deferral costs

With a body in the function

What I took from it

One stack per ticket: why our coding agent works on a DB copy

Where the mistakes were

What a ticket gets

Isolation is the safety decision

Independent timelines

What made the copies cheap

If you are building one

$402 on one ticket: cost per turn in headless Claude Code

How a ticket becomes a session

The trap

The fix: keep the last total, post the difference

Where the number goes

What changed

5 seconds to 30 ms: rebuilding IDW heatmaps in Go

How the old version worked

A weekend proof of concept in the browser

Node.js, then Go, then the real bottleneck

What the new pipeline does

Before and after

The ticket is the interface: how our developers ship without a laptop

The problem we were actually solving

The ticket is the interface

Each ticket gets its own full stack

An agent does the work, but only from the thread

Shipping is a drag-and-drop

What is AI and what is not

What it gave us

Three deliberate choices

What is next

If you want to build something similar

`.then` and `await` do not