Thoughts on software engineering, payments, and building products.
An agent is only as capable as the tools you give it, and tools are where a lot of the real engineering (and the real risk) seems to live. Here is how I have been thinking about building safe, focused MCP tools for payment operations.
Agents produce code faster than anyone can read it, and the deepest cost is comprehension debt, not bugs: software that runs while no one understands it. Verification can let you trust code you never read; that is necessary, and it is not the same as understanding it. What property-based testing, simulation, and proof can buy, and what they can't.
Five agentic coding patterns I keep reaching for (sequential, operator, split-and-merge, agent teams, and headless), plus the CLAUDE.md, subagents, slash commands, and plan-first machinery I lean on to make delegation repeatable and verifiable. A snapshot of my current workflow, not a prescription.
Why a one-shot RAG pipeline hit its ceiling on real regulatory questions, and how rebuilding Ordinance as an agent put the engineering in the harness around the model.
The model is just one input into a running agent. The harness around it (prompt, tools, context, subagents) is, in my experience, the engineering discipline that tends to decide whether an agent ships.
How I built Ordinance — a retrieval-augmented generation system that answers questions about HK compliance with cited, verifiable responses across 224 government documents.
Welcome to my blog. I'll be writing about software engineering, payments, and building products.