Backend engineer with 15+ years of commercial PHP. I design and build high-load services and APIs — and I publish the reusable parts as open source.

• 10 years in ad-tech: advertising networks with RTB (Real-Time Bidding) integrations, buying and selling traffic — MySQL for operational data, ClickHouse for impression analytics, Redis/Memcached for caching.
• Now: product development on Yii3 / PHP 8.5 with Clean Architecture (Domain / Application / Infrastructure / Endpoint, boundaries enforced statically by Deptrac), plus support and refactoring of large Yii2 legacy systems.
• LLM in production: the application acts as an MCP server — assistants connect over Model Context Protocol and call domain tools via tool-calling, guarded by per-user RBAC and an audit log.
• I care about the things that are invisible until they break: retries, idempotency, exactly-once delivery, backpressure, mutation-tested code.

Languages

Frameworks

Data

Infrastructure & Real-time

Quality

Reusable PHP 8.3+ libraries with hardened CI/CD, SemVer, backward-compatibility checks, and tests on Testo with mutation testing (MSI 85–100%).

How does one person ship this many? Not by cutting corners — the volume is a side effect of a repeatable process, not the goal. The process is public in php-package-toolkit and explained in Workflow below.

Five that show the range:

The honest answer to "how does one person publish this many packages?" is that the agent does the mechanical work inside a rulebook a human wrote — and that rulebook is php-package-toolkit, open source, so the claim is auditable rather than asserted.

The loop

1. Scaffold from contract, not from scratch. An agent generates each package from versioned templates plus a machine-checked rulebook (AGENTS.md). File layout, code style, CI pipeline, doc structure, and security rules are a fixed contract, never a per-project decision.
2. Write, then gate. The agent writes the code, tests, and docs, then runs the same gate every package must pass: Psalm level 1 with zero suppressions, mutation testing (MSI 85–100% — line coverage is not enough; the toolkit's ER-003 writeup covers the difference), backward-compatibility checks before every major, SHA-pinned hardened CI, and Testo tests with property-based coverage where invariants exist.
3. Human owns the judgment. I design the API, decide the abstractions and layer boundaries, review every change, and own release decisions. The agent never merges, tags, or publishes on its own — those are explicit human gates encoded in the skill workflows that drive each step.

What the agent makes cheap is execution, not judgment. Deciding what the right abstraction for a transactional outbox or a deterministic A/B engine looks like is the part I bring; the toolkit makes shipping it a matter of hours instead of weeks, without lowering the bar.

• A fitness / training platform backend (Yii3, PHP 8.5, PostgreSQL) — activity tracking with .fit file parsing, duels and leagues, JWT auth, S3 storage, real-time via Centrifugo, transactional outbox for event delivery. Strict Clean Architecture layering enforced by Deptrac; built on my own packages.
• A Yii3 product backend (PHP 8.5, MySQL / ClickHouse / Memcached) — admin panel, REST API with OpenAPI, RBAC, multi-language, media pipeline, and an MCP server that lets LLM assistants operate the product safely.

• Low-latency, high-load services where milliseconds and correctness both matter
• Distributed patterns done properly: outbox, idempotency, retries with backoff, bulkheads
• Libraries other people can depend on — documented, versioned, mutation-tested
• Making LLMs a first-class, permission-aware part of a backend rather than a bolt-on