AI doesn't change what hard engineering leadership looks like — it just makes weak engineering leadership more expensive.
I lead engineering on a regulated cross-border payments program. I build open-source infrastructure for AI agents that touch real systems — Approva, Codencer, Rhodd. I write here when something I've seen often enough becomes worth naming. Sixteen years inside engineering teams, eight of them leading.
Recent short pieces.
The dangerous agent failure is not always a bad answer. Sometimes it is public input reaching private context.
GitLost showed a crafted public GitHub issue steering an agent with cross-repo read access into posting a private README as a public comment — no stolen credentials, just a context-separation failure. The agent runs on a service-account permission model, not a user one, so no patch closes it; the fix is architectural. If public text can steer private access, the permission model is already broken.
Read →The best hire is not always someone you can manage easily. Sometimes it is someone you would be willing to report to.
Strong leaders create leverage by hiring near-peers who turn direction into daily operating decisions, instead of task-takers who route every decision back through you. A near-peer multiplies judgment; a task-taker multiplies coordination. Hire only for delegation and you become the ceiling on everything the team can do.
Read →A model can get smarter and still make your system less reliable. That is what weak tool contracts do.
The newest Claude models regressed on one edit tool — inventing fields that did not match the schema, failing ~20% of the time in a real agentic session. Smarter model, worse tool behavior, only visible in a long history. The fix is not a better prompt; it is stricter schemas and runtimes that fail loudly. The tool contract is part of the product's intelligence.
Read →Essays worth the time.
Infrastructure I'm building.
Human approval for risky AI agent actions — with passkey identity, scoped capabilities, and a verifiable audit trail.
A persistent daemon that manages, executes, validates, and audits tasks performed by external coding agents.
Turns architecture definitions into production-ready code, infrastructure, and CI/CD pipelines. Zero boilerplate.
Things outside the day job — music, mentoring, a book in progress, older essays.
Engineering is not the only thing I think about. The Elsewhere page collects the parts of my work that do not fit a portfolio frame — a progressive metal project, mentoring work at h.careers, a Russian-language book on career growth in IT, older essays.
Visit Elsewhere →