Profile loaded: Nikhil Kapadia.
Senior software engineer. Agent orchestrator.
The rest is in the logs.
▼ CONTINUE| Level | 29 |
| Class | Senior Software Engineer (base) · Agent Orchestrator (class change, 2026) |
| Guild | Talix |
| Specialty | Full-stack product engineering |
| Passive | Systemize (Lv. MAX): anything repetitive gets pulled into a system. |
I'm Nikhil, a senior software engineer in Toronto. I've spent eight years shipping full-stack product: React and TypeScript up front, Python, Node and PHP behind it, from a live trading platform with Stripe billing to the AI features at BombBomb. On the side I run Talix, a small invoicing product, and build the tools you'll find under Side Quests.
The through-line is how I handle repetition. Anything that keeps costing me attention, a question I keep answering, a cleanup I keep running, a judgment call I keep making, gets pulled out of my hands and into a system: a watcher, a cron job, an agent with written rules. Over the years that habit has produced release monitors, self-maintaining machines, a versioned personal rulebook (Argus), and eventually the fleet: when coding agents got good, my own job was simply the biggest repetition left.
What I'm like to work with: I ship features at every size the same way, tests first, then the code that makes them pass. When a verification habit proves it earns its keep, I write it down as an agent skill, so the fleet reviews code, architecture, and even prose the way I would. A meaningful share of my review comments are about two pixels of drift, and I stand by every one of them.
Off duty I read a lot of Korean webcomics, which you may have guessed from the interface you're using. The status window is a joke that is also true: I really do treat life as a game with legible rules. It's working.
The economics of software engineering changed in the span of about two years. Agents now write competent code, and most of the industry is still arguing about what that means for the profession. I skipped the argument. Agents take the repetitive work, and that's fine by me.
I moved to the layer the new economics actually reward: orchestration, verification, and the systems that make agent output trustworthy. In practice, I run a fleet of coding agents. Work arrives as tasks on a board, each routed to the cheapest model tier that can handle the judgment it requires, and no result is accepted on the agent's word. Every claim of "done" is verified by something that didn't do the work.
The models are commodities. The system around them is the durable advantage, and building that system is what this page documents.
The system has a name. Open ⟨ ARGUS ⟩
Argus is the repo that runs my fleet, named for the watchman with a hundred eyes. It holds the rules every agent on my machine loads before it touches anything: how work gets scoped, what requires my name on it, and how a claim becomes a fact. The repo stays private because it's the machinery. The shape of it isn't a secret:
"A gate that has only ever passed is a guess." Break it on purpose, watch it fail, then trust it.
"A worker reporting done starts verification. It never ends the work."
"Never present a skipped check as green." Every check reports pass, fail, blocked, or not run.
Currently at v3.9. The version only moves when a rule survives contact with a real failure.
One ordinary review prompt spawned 5 agents, which recursively spawned 928 more. A single session, 367 MB of transcripts. The lesson wasn't "be more careful." It was that prose constrains nothing. Delegation caps now live in config, where an agent can't talk its way past them.
What it left behind: a rule I still use. If a safeguard only exists as a sentence, it doesn't exist.
I mined every agent transcript on my machine, 2,610 sessions across four tools, to check whether my agents actually follow my rules or I just believe they do. My first attempt rested on broken methodology, so I threw it out and redid it properly.
Findings: zero unauthorized commits or pushes across 460 commits and 281 pushes · 26 sessions caught claiming done without running a test · 36 of 43 installed skills retired once the data showed they'd never been used.
Day-job bug: email verification quietly logged users back in, but billing ran on a separate host that didn't share the session. Purchases fell back to the wrong state, and in the worst path provisioning could charge the card before throwing. The rebuild moved signup state into user-scoped Redis with a TTL and a marker that only exists once provisioning has actually succeeded.
What holds it now: 128 tests and a regression test that fails when the bug is reintroduced. A gate that has proven it can fail.
Trial completion reported success while another web host still held stale access: a race between provisioning, cache propagation, and the user's first request. Three attempts were closed without merging. The fourth centralized provisioning, invalidated caches across hosts, and made replays idempotent.
Held in place by a 244-line integration test covering access, roles, replays, and plan changes. The dead branches were part of the fix.
A region dropdown had an obvious one-line fix. The failure survived it, resurfaced in a second purchase-flow resolver, then again through browser autofill and native address fields. The pass that finally killed it handled unique, ambiguous, and unknown region codes, and documented the real stakes: a payment method could be stored with no subscription attached to it.
Lesson: the visible symptom is never the whole bug. Fix the class, not the instance.
The open-source gateway my fleet runs on was missing its enforcement layer, so I forked it and built one: checkpointing with claim fencing (a successor can't take over a task until its predecessor's process actually exits), a fail-closed handshake between dispatcher and workers, and workspace leases granted at dispatch instead of discovered as conflicts at runtime.
Verified: differential test sweep, branch vs base. Identical failure sets, zero caused by my diff.
It started as "an app like GitHub, but not GitHub": a desktop tool that renders local branch diffs the way a pull request does. I had a working Tauri + React app the first night, then spent two weeks iterating from screenshots: multi-repo workspaces, IDE-grade syntax highlighting, a commits-ahead view, and a kanban board that dispatches my agent fleet from inside the app. Then I shipped it properly: code-signed, notarized, auto-updating.
Status: on my dock, running my agents. The repo is under Side Quests.
I built a CLI where one command brings up parallel, isolated instances of a full production-style stack on a single machine: per-instance frontend, backend and MySQL, shared Postgres services, local HTTPS hostnames, OIDC auth, database cloning and seeding, and a git worktree per instance. Then I hardened it until any teammate could run it without my machine's quirks.
Best bug: cloned databases sharing IDs caused cross-instance data bleed. Isolation is a claim. I verified it.
After a major framework upgrade, the app had to match the reference environment exactly. I turned visual QA into an agent loop: annotated screenshots drive the agent, Storybook parity stories pin components, and the diff between branch and staging becomes the work queue. Down to font weights and hover colors.
The reference is evidence. The loop ends when the diff does.
Talix is the guild. Its main product is talix.app, invoicing that gets out of your way. I run it with zero marketing spend.
This paragraph is the marketing.