DEV Community: Davron Yuldashev

Four agents, 77 projects, 90 minutes: the multi-agent Claude Code pattern I run in production

Davron Yuldashev — Fri, 29 May 2026 12:03:02 +0000

Last Tuesday I sat down to audit every dev project I'd written over the past few years. 77 of them. Old courier-logistics monorepos, abandoned starters, a clinical reasoning engine, half a dozen Telegram bots, a SaaS framework I keep reusing, two startups, a Rust process manager. Different stacks, different ages, different employers, different states of git hygiene.

I gave the job to four Claude Code agents working in parallel. They were done in about 90 minutes.

Below is the pattern they used, and why a version of it now runs inside a 2,200-commit production codebase at my day job.

Why one agent isn't enough

Single-agent Claude Code is fine until you hit one of three walls.

The context window starts choking on a big codebase. The work is wider than it is deep, and serial reading wastes wall-clock. You want the orchestrator to keep judgment, not get buried in file diffs.

A swarm fixes all three. Each agent gets a slice. The lead keeps the map.

The hard part isn't spawning agents. Spawning is one tool call. The hard part is making sure four of them don't trip over each other.

The pattern

Claude Code ships with two primitives that, combined, give you a clean swarm.

TeamCreate + named teammates. Each agent has a stable name (analyst1, designer, metrics) and joins a team with a shared task list.

SendMessage to coordinate. The lead addresses any teammate by name. Teammates idle between turns and wake when messaged.

Wire those to a TaskList and you have a coordination plane. Each task carries an owner field. Setting owner = analyst3 is your atomic lock. Until that field changes, the task belongs to that agent.

For the audit I made 77 tasks, one per project. I spawned four analyst teammates with the same prompt template: read the project at code level (not commit messages), parse Claude Code session transcripts if any exist, write a per-project dossier. Then let them loose.

The race condition I shipped on day one

First attempt: each teammate, on idle, runs TaskList, finds the lowest-ID task with no owner, claims it, does it, marks it complete, repeats.

That worked for the first ten minutes. Then two analysts grabbed the same task within the same second. The TaskUpdate that set the owner went through twice. Both did the work. The second one overwrote the first dossier with a slightly different version of the same content.

Classic optimistic-concurrency mistake. The fix is boring and reliable: stop racing for low-ID tasks. The lead pre-assigns owners on the entire remaining range before spinning the swarm back up.

I partitioned the remaining work into four contiguous blocks (#33–43, #46–56, #57–67, #68–77) and set every owner in advance. Now when any agent reads the list, every task is already claimed by someone. Nothing left to race for. Each agent processes its own block in ID order and reports back when the block is empty.

Zero collisions for the rest of the run.

What came out

Sixty dossier files. Twenty-two tagged showcase, thirty-eight supporting, seventeen skip. The skips were honest: client work where my commit share was under 10%, abandoned scaffolds, empty stubs. Bad data is worse than no data when the goal is a personal-brand audit.

The interesting findings weren't in the headline projects. They were in the cross-cuts. My boilerplate had quietly become the foundation under four products. The same codebase showed up in five different clients. On one healthcare CRM my commits totalled 962 out of 2,208 (top contributor), even though the surface-level metadata I'd been relying on said only about 700. Manual git history is lossy. A swarm with shared output catches the drift.

The production version

This isn't a hobby pattern. The same multi-agent Claude Code workflow runs in our healthcare CRM at the day job, on a 2,200-commit codebase. The CLAUDE.md there defines four custom subagents:

django-backend-specialist — owns models, views, URLs.
advertiser-frontend-developer — owns the advertiser dashboard.
patient-frontend-specialist — owns the patient portal.
linting-specialist — runs last, owns the diff.

There's an explicit inter-agent contract. When the backend changes a view, it reports the new endpoint, the URL, the response shape. The frontends know to ask for that data before they start. Linting runs at the end of the chain, not the middle. The orchestrator (me) holds the architecture. The agents hold the file diffs.

On one of the products I ship with this pattern, an internal-tools rebuild, about 29% of the commits are AI-authored under my direction. The other 71% are mine. The split is visible in git shortlog. Nothing to hide, nothing to inflate.

The honest part

This doesn't replace senior engineering judgment. The orchestrator still has to know what good looks like. When an analyst returns a weak dossier, you have to recognize it and ask for a redo. Two agents disagreeing? You resolve it.

What it does give you is leverage. One engineer with a swarm covers staff-level surface area. The bottleneck shifts from typing speed to judgment quality, which is the right bottleneck to have.

If you want to see what the swarm actually produced, the 60 dossiers live at davr.dev/projects. Each one is a code-level audit, not marketing copy.

I Built 6 Free Browser-Based Tools — 50+ Utilities, No Signup, No Tracking

Davron Yuldashev — Tue, 07 Apr 2026 05:00:06 +0000

All tools are free. Processing happens in your browser or on a private server. No accounts, no ads, no tracking.

Over the past 6 weeks I built a portfolio of free online utility tools at davrapps.dev. Here's what shipped and how it's built.

The Apps

🛠️ DevTools — 28 Developer Utilities

Every tool runs 100% client-side — nothing is sent to any server. Check the Network tab if you don't believe me.

Text & Data

JSON Formatter & Validator
YAML ↔ JSON Converter
TOML ↔ JSON Converter
Diff Checker — compare two texts side-by-side
Text Statistics — word count, reading time, character frequency
String Case Converter — camelCase, snake_case, SCREAMING_SNAKE, kebab-case
Lorem Ipsum Generator

Encoding & Crypto

Base64 Encode/Decode
URL Encoder/Decoder
HTML Entity Encoder/Decoder
Hash Generator — MD5, SHA-1, SHA-256, SHA-512 (Web Crypto API)
JWT Decoder — inspect header + payload without a secret
Password Generator — cryptographically secure
Image to Base64

Dev Helpers

Regex Tester — real-time matching with group highlighting
UUID Generator — bulk v4 UUIDs
Unix Timestamp Converter — epoch ↔ human-readable with timezone
Number Base Converter — binary, octal, decimal, hex
Cron Expression Parser — plain English explanations
SQL Formatter
CSS Minifier
Markdown Preview
Color Converter — HEX ↔ RGB ↔ HSL
CSS Gradient Generator — linear/radial/conic, CSS + Tailwind output
Tailwind CSS Color Explorer

👉 devtools.davrapps.dev

🖼️ ImgTools — 7 Image Utilities

Server-side processing with Sharp/libvips on a private VPS — files are never stored.

Compress — MozJPEG, up to 80% size reduction
Resize — custom dimensions + social media presets
Crop & Rotate
Format Convert — JPEG, PNG, WebP, AVIF, GIF, TIFF
Watermark — text or image
Background Removal

👉 imgtools.davrapps.dev

📄 PDFKit — 9 PDF Tools

No file size limits. No watermarks on output. No account needed.

Merge, Split, Compress, Rotate, PDF ↔ Image, Password Protect, Watermark, Add Page Numbers.

👉 pdfkit.davrapps.dev

🔲 QRKit — 8 QR Code Tools

Generate (with logo + custom colors), Scan (file or camera), WiFi QR, vCard QR, Batch Generator, Decode, Color Picker.

👉 qrkit.davrapps.dev

📸 Picefy — Screenshot Beautifier

Turn plain screenshots into polished visuals: gradient backgrounds, rounded corners, drop shadow, device frames. Export as PNG.

👉 picefy.davrapps.dev

📦 ShipKit — Next.js + Bun SaaS Boilerplate ($49)

Full-stack starter: Next.js 16, Bun, Elysia.js, Better Auth, Polar.sh payments, PostgreSQL + Drizzle ORM, shadcn/ui, i18n, dark mode.

👉 shipkit.davrapps.dev

Monetization

App	Free limit	Pro
DevTools	Unlimited	—
ImgTools	5 ops/day	$3/mo
PDFKit	5 ops/day	$5/mo
QRKit	5 ops/day	Coming soon
Picefy	5 exports/day	$5/mo
ShipKit	—	$49 one-time

Payments via Polar.sh (Stripe under the hood, but with a much better OSS-friendly DX).

Tech Stack

All apps share the same foundation:

Next.js 16 (App Router, SSG for all tool pages)
Bun runtime + package manager
Elysia.js API layer (Bun-native, ~3x faster than Express in benchmarks)
Better Auth — email/password + OAuth, sessions in PostgreSQL
shadcn/ui + Tailwind CSS — every app has dark/light mode
PostgreSQL + Drizzle ORM
i18n via next-intl (EN/RU/UZ)

Deployed on a Hetzner CAX21 ARM (~$8/mo total for all 6 apps). Each app is a systemd service behind nginx, its own port pair.

Key Decisions

Client-side by default. For anything that doesn't need a server (formatters, converters, hash generators), everything stays in the browser. Zero upload risk, zero server cost.

SEO-first architecture. Each tool has its own URL, unique meta tags, FAQ with JSON-LD structured data. devtools.davrapps.dev/en/json-formatter and devtools.davrapps.dev/en/uuid-generator each target different search queries rather than competing as a single page.

One server, many apps. Rather than pay per-app VPS costs, everything runs on one ARM machine. Total infra cost for 6 apps + 14 services: ~$8/mo.

Current Status

6 apps live, 50+ total tools
MRR: $5 (early days)
Backlinks: 2 merged awesome-list PRs, 7 more open
Starting to appear in Brave/Bing — Google indexation in progress

What tools do you wish existed? Drop a comment — I might build it next.

I built a process manager with built-in crash detection and AI auto-fix (PM2 alternative)

Davron Yuldashev — Sat, 14 Mar 2026 10:42:06 +0000

You deploy a service, it crashes at 3 AM. You get a Sentry alert, SSH in, dig through logs, try to figure out what happened. Or you pay $26/month for Sentry plus integrate the SDK into every project.

I wanted crash detection and recovery built directly into the process manager — no extra services, no SDK, no dashboards. So I built Velos.

When a process crashes or throws an unhandled error, Velos detects it, runs AI analysis on the logs and stack trace, and sends a Telegram message with two buttons: Fix and Ignore. Tap Fix — an agent reads the logs, inspects the code, diffs recent changes, proposes a fix, and reports back. All without waking up your laptop.

How the crash flow works

Process crashes (or stderr matches panic/traceback/FATAL pattern)
  → Velos daemon detects it
  → AI analysis runs (Anthropic or any OpenAI-compatible API)
  → Telegram notification with [Fix] [Ignore] buttons
  → You tap Fix
  → Agentic loop starts: reads files, inspects git diff, runs commands
  → Result sent back to Telegram

Nothing happens without your approval. The agent has tools to read/edit files, run commands, and inspect git history — but it only acts when you tap Fix.

This also works for runtime errors before a crash. Velos watches stderr for panic/traceback/FATAL/ERROR patterns and fires an alert without waiting for the process to die. Closer to what Sentry does — but zero SDK, zero extra service.

Why Zig for the daemon?

Process management is fundamentally a systems problem: fork/exec, Unix sockets, signal handling, CPU/RAM monitoring via syscalls. Zig gives full control with zero runtime overhead — no hidden allocations, no GC, comptime metaprogramming for tight control over the binary.

The result: ~3 MB RAM idle, ~65 KB per managed process. PM2 sits at ~60 MB baseline because of V8.

Architecture:

Zig daemon (fork/exec, IPC, monitoring)
    ↓  C ABI FFI
Rust shell (CLI, REST API, MCP server, log engine, AI)

Zig core compiles to a static library (libvelos_core.a), linked into the Rust binary via C ABI FFI. Single binary, zero runtime dependencies.

IPC uses a binary protocol — 7-byte header (magic 0xVE10) + MessagePack payload over a Unix socket.

Smart Log Engine

Pattern clustering, error rate tracking, anomaly detection — runs fully local, zero LLM cost.

velos logs myapp --summary
# → "47 errors in last 10m, 3 patterns detected:
#    [1] DB connection timeout (×31)
#    [2] Rate limit exceeded (×12)
#    [3] File not found (×4)"

Instead of scrolling through thousands of raw log lines, you get a digest.

MCP server (for local AI workflows)

Velos also ships with a native MCP server — 13 tools for Claude Desktop or Claude Code to manage your local processes directly:

{
  "mcpServers": {
    "velos": {
      "command": "velos",
      "args": ["mcp", "start"]
    }
  }
}

Tools include: start_process, stop_process, restart_process, get_logs, health_check, get_metrics, search_logs, analyze_crash, and more. Useful for local dev environments where your AI agent is already running on the same machine.

Install

curl -fsSL https://releases.velospm.dev/install.sh | bash

Or Homebrew:

brew install Dave93/tap/velos

Current state

Velos is at v0.1.14, production-ready on macOS and Linux. Windows support is on the roadmap.

What's coming next:

XDG Base Directory compliance (tracking: #10)
Plugin system
Web dashboard
Benchmark suite vs PM2/supervisord/systemd

GitHub: Dave93/velos
Docs: velospm.dev

Happy to answer questions about the crash detection system, the Zig/Rust architecture, or the design decisions. What would you have done differently?