DEV Community: Osman Ahmadzai

I made AI coding agents race each other, and the fast one wasn't the one I expected

Osman Ahmadzai — Mon, 05 Oct 2026 07:26:37 +0000

Every few days someone tells me which coding agent is "obviously the best". They always have a benchmark to back it up. And the benchmark is always run on code that has nothing to do with mine.

I got tired of nodding along, so I built a small thing to settle it the dumb way: give them all the same task at the same time and watch.

It's called Agent Derby, and this is what a race looks like.

The first race

I typed "build a playable snake game in the browser", picked three Claude models, and hit start.

Sonnet 5.5 was finished in 17 seconds. I hadn't even finished reading what the other two were doing.

Haiku 4.5 came in at 31 seconds.

Opus 5.5 took two and a half minutes and cost about ten times as much as either of them.

So Opus lost, right? Well. Then I played the games.

Sonnet's game works, and that is all it does. A square, a dot, a score.

Opus built a start screen, sound effects, a pause button and a mute key. It wrote about six times as much code. Nobody asked for any of that, and it's also clearly the one you'd want to ship.

That's the thing a score table can't tell you. "Fastest" and "best" were two different models, and I only found out because I could actually play all three.

It's one task. It proves nothing in general. But it changed how I think about picking a model, which is more than any leaderboard has done for me.

What it actually does

You type a task and choose who races. Everyone gets the exact same prompt at the exact same moment.

Each agent works in its own sandbox, a private copy of the project. They can't see each other's work and they can't write to your real code. I was nervous about letting three agents loose with every permission switched on, so on macOS and Linux the operating system itself blocks them from writing anywhere else.

While they run, you see every lane at once: what each one is reading, editing or running, with the clock, tokens and cost ticking.

When one finishes, whatever it built just starts up in its lane. Web apps open in a frame. Terminal programs get a real terminal. No copying commands, no "now run npm install".

Then you get the numbers lined up next to each other.

If you like one result, you can keep it as a new branch or a folder. It never merges anything for you.

One rule I was stubborn about

If an agent's CLI doesn't report a number, the app says "not reported".

Not zero. Not a guess. Not a dash that looks like zero.

It sounds like a small thing, but comparison tools get untrustworthy fast when they quietly fill in blanks. If the cost is an estimate, it's labelled as an estimate.

Things that surprised me while building it

Some models take a long time to say anything. One model sat silent for minutes between steps and timed out twice. I assumed my sandbox had broken it. It hadn't. It was just slow that day. The other lanes carried on without noticing, which is exactly what I wanted to be true, but it was a nervous ten minutes.

Agents do unexpected things when left alone. One of them, asked to build a game, decided to start a web server and go looking for a browser to test it in. Fair enough, honestly.

"Is it playable?" is harder to check than it sounds. My first automated check pressed arrow keys and declared one game broken. It wasn't broken. It had a Start button.

Try it

You need Node and git.

npx https://github.com/osmanahmadxai/agent-derby/releases/latest/download/agent-derby.tgz

It uses the agent CLIs you're already logged in to, so there are no API keys involved. If you don't have any agent installed, there are built-in demo agents that run a scripted race for free, so you can see how it works first.

There's also a terminal version that splits your screen into one pane per agent, and a desktop app.

What's not finished

I'd rather tell you than have you find out:

I've only properly tested Claude Code. Codex CLI and Gemini CLI are wired up, but I haven't had a real logged-in run with either yet. They may break.
Windows has no sandbox yet and is basically untested.
The desktop builds aren't code-signed, so your OS will complain the first time.

And for full disclosure: I built this with Claude Code. Which means an AI coding agent helped write the tool that judges AI coding agents. Make of that what you will.

The repo

It's MIT licensed and all of it is here: github.com/osmanahmadxai/agent-derby

If you race something, tell me what happened. I'm especially curious whether the ranking flips on a harder task than snake. My guess is yes.

Syncle: keep any two databases in sync, live and across engines

Osman Ahmadzai — Thu, 23 Jul 2026 18:07:39 +0000

You have a row in Postgres. You want that same row in MongoDB — not tonight in a batch job, but the instant it changes. And next month you'll want it in Redis too, and maybe POSTed to some webhook.

Today that's a Kafka cluster, a Debezium connector, a sink connector, a schema registry, and a weekend. For a job that is, at its heart, one sentence:

a source → one or more destinations → kept in sync.

Syncle is an open-source tool that does exactly that sentence, and nothing you didn't ask for. Connect your databases, draw a bridge from a source to one or more destinations, and the moment a row changes in the source it's written to every destination you linked. Any engine to any engine — PostgreSQL · MySQL/MariaDB · SQLite · MongoDB · Redis — plus HTTP endpoints when you need them.

This post is a tour of what it does and, for the curious, how it's built.

The core idea: a bridge

A bridge reads rows from a source and writes each one to its destinations. A destination is either:

another database — the headline feature. Postgres → MongoDB, MySQL → SQLite, MongoDB → Redis. One bridge can fan out to several databases at once, and bridges can chain (A → B → C).
an HTTP endpoint — POST/PUT/PATCH each row to a URL with a payload you design, for feeding a service instead of a database.

The interesting part isn't that it copies data — plenty of things copy data. It's the guarantees around how.

No duplicates, ever

Every database write is an idempotent upsert, keyed by columns you choose. So replays, retries, and at-least-once redeliveries never double-write. Under the hood each engine does it with its own native atomic operation:

Engine	Upsert
PostgreSQL / SQLite	`INSERT ... ON CONFLICT`
MySQL	`INSERT ... ON DUPLICATE KEY UPDATE`
MongoDB	`updateOne(filter, ..., { upsert: true })`

Inserts, updates, and deletes all propagate — a delete routes to a keyed delete on each target.

Missing table? It builds it

If the destination table or collection doesn't exist, Syncle creates it from the source's shape, translating types across the engine boundary (a Postgres timestamptz becomes something sensible in SQLite, a document in Mongo, a hash in Redis). Or you map columns yourself: write this column into that column over there, rename, drop, pick keys.

You pick how it fires

Three trigger modes, same everything-else:

Replay — a one-shot job. Stream all (or selected) rows once, then finish. Perfect for the initial backfill or a migration.
Watch — poll the source on a cursor (auto-increment id, an updated_at column, or a primary-key diff) and sync new rows as they appear. Works on every engine.
CDC — true change-data-capture straight from the database's change log, in real time, no polling: Postgres logical replication, MySQL binlog, MongoDB change streams, Redis keyspace notifications.

You build the whole thing visually — browse the source table, toggle columns, pick destinations, and watch a live preview of exactly what will be written before you commit.

Watch it happen

Reliability you can't see isn't reassuring, so every delivery shows up on a live timeline:

🟢 green — synced
🔴 red — failed
🟡 amber — skipped
⬜ slate — queued

Click any cell to see the exact row written, the result, timing, and any error. Runs survive restarts, resume where they stopped, and can be cancelled. You can skip rows by range, or retry only the failed ones in place — and watch the failed cells flip green.

Try it in one command

A fresh machine needs only Docker. Everything else — Node, Postgres, Redis — runs in containers:

curl -fsSL https://raw.githubusercontent.com/osmanahmadxai/SYNCLE/main/install.sh | sh -s -- up

That installs a native syncle command, builds the stack, and opens the GUI at http://localhost:3002. After that it's just:

syncle up      # start everything, open the GUI
syncle down    # stop it
syncle logs    # follow the logs
syncle update  # pull latest + rebuild

Prefer to run from source?

pnpm install                  # frontend + backend
docker compose up -d          # postgres (metadata) + redis (job queue)
pnpm start                    # env files + migrations + run the whole app

How it's built

Syncle is a pnpm monorepo with a strict one-way dependency flow: web → api → core.

syncle/
├─ packages/
│  └─ core/            @syncle/core — framework-agnostic domain (pure TS)
│     ├─ adapters/       DatabaseAdapter interface + one file per engine
│     │                  (raw drivers: pg, mysql2, better-sqlite3, mongodb, ioredis)
│     └─ hooks/          column mapping + cross-engine translation, payload
│                        transform, shared bridge schemas (Zod)
├─ apps/
│  ├─ api/             @syncle/api — NestJS backend
│  │  ├─ hooks/          bridge store · run processor · CDC providers ·
│  │  │                  sink router → database sink + HTTP delivery
│  │  ├─ connections/    Prisma-backed store · live adapter pool
│  │  └─ common/         crypto · Zod validation · exception filter
│  └─ web/             @syncle/web — Next.js 15 + shadcn/ui + TanStack
└─ docker-compose.yml  Postgres (metadata) + Redis (run queue)

A few design decisions did most of the work of keeping it small.

One sink, two destination kinds

Every trigger — replay, watch, CDC — funnels rows through a single sink router. It dispatches to the database sink (map columns → auto-create if needed → native upsert or keyed delete) or to HTTP delivery (template render → POST with retries). The runner, the timeline, and the exactly-once accounting don't care which. So adding a new kind of destination is one module, not a rewrite.

CDC behind one interface

Each engine captures change its own way — logical replication, binlog, change streams, keyspace notifications — but they all implement the same small contract:

interface CdcProvider {
  readiness(): Promise<Readiness>;   // is the source configured for capture?
  provision(): Promise<void>;        // create slot/publication if needed
  stream(): AsyncIterable<Change>;   // insert/update/delete, each tagged with its op
  cursor(): Cursor;                  // where we are, for resume
}

The service around them owns the run lifecycle and the shared dedupe → map → write → record → checkpoint pipeline. Adding a new engine's CDC is a single file.

Two data layers, two right tools

This is my favourite tension in the codebase. The databases you connect to have unknown, runtime-discovered schemas — so those adapters use raw drivers with fully parameterized queries. An ORM literally can't introspect an arbitrary schema it's never seen.

But Syncle's own store — saved connections, bridges, runs, deliveries — has a fixed schema we control. So that uses Prisma with migrations. Same app, opposite tools, each because of what it actually knows about the schema.

Durable runs

A replay run is one BullMQ job (jobId = runId). It streams the source a page at a time with keyset pagination (millions of rows, flat memory), syncs sequentially for natural backpressure, and checkpoints progress. A crash auto-resumes from where it left off.

The north star: adding an engine = implement DatabaseAdapter and register it. The connection form, schema browser, and feature gating all derive from that one registration.

A note on security

Syncle handles credentials, so a few things are non-negotiable:

Connection passwords and hook secrets are encrypted at rest (AES-256-GCM) and only ever returned to the browser redacted.
All user values are bound parameters; identifiers are dialect-quoted.
HTTP payloads are built by structured token substitution ({{column}}, {{$row}}, {{$op}}, …) — no string injection, no code execution.

It runs locally with no auth layer by default. Add authentication and restrict which destinations a bridge may write to before exposing it to an untrusted network.

The stack

NestJS · BullMQ + Redis · Prisma + PostgreSQL · Next.js 15 · React 19 · TypeScript · Tailwind · shadcn/ui · TanStack Query & Table · Monaco · React Flow · Zod · Vitest.

Try it

Repo: https://github.com/osmanahmadxai/SYNCLE
One-liner: curl -fsSL https://raw.githubusercontent.com/osmanahmadxai/SYNCLE/main/install.sh | sh -s -- up
License: MIT

If you've ever wanted "just keep these two databases in sync" without standing up a streaming platform to do it, I'd love for you to try it and tell me where it breaks. Issues and PRs welcome.

What's the messiest cross-database sync you've had to build by hand? Tell me in the comments.