How I work

Before any code exists, I write a spec: context, goal, decisions with reasons, and what is deliberately left out. That becomes an implementation plan with small steps to tick off, each with a command and an expected result. Only then does building start, step by step. I split larger projects into phases, and each phase gets its own spec. My global rules file adds four rules after Karpathy: think first, keep it simple, change only what is needed, work towards a verifiable goal. The numbers below come from a Payload project on 7 Jul 2026.

A rule in a text file is a request. A hook is a boundary. All my texts follow style rules, for example forbidden characters such as em and en dashes. The rule was in several project notes, and still on 14 Sep 2026 such dashes were on several live sites. Since then my own PreToolUse hook checks every file write, every shell command and every MCP call before it runs. If it finds a forbidden character, it blocks the call and sends the agent the location with a suggested replacement. The agent fixes it and sends again.

A skill is a reusable instruction set that my coding agent loads for matching tasks. I treat skills like code: the same test tasks run with and without the skill, grading scripts check every output against fixed criteria, and the result is stored as a benchmark file in the eval folder. That shows me whether a skill helps and what it costs. Not every skill wins clearly: in its first round ui-master was only slightly ahead and used 57% more tokens on average. The test sets are small, three to six tasks per round. They do not replace judgement, but they stop me from imagining an improvement.

A coding agent forgets almost everything between sessions. So my agents maintain a Markdown wiki based on Andrej Karpathy's LLM wiki pattern. Every project has a short profile page, larger pieces of work end in a synthesis with decisions and findings, and every session ends with an entry in the daily journal, dead ends included. A Bash script regenerates the catalogue of my skills, agents, plugins, MCP servers and hooks from the file system. Agents read the index first and then only the pages they need. That saves tokens and keeps the context small.

I split larger tasks across several agents working in parallel. Each has a role: scouts only read, builders write code, reviewers look specifically for errors in facts, security and UI, and a fix round follows. At the end I look at the results myself, and only what I approve goes to production. This portfolio is an example: on 18 Oct 2026 a workflow of five parallel read-only agents took stock of job ads, my projects and the state of the domain. On the same day four workflows with ten agents each worked on my agent platform. Before the deploy, the test suite was green.

Until 1 Aug 2026 I checked a website with WebGL animations through measured values. The numbers were right while the page was visibly broken on phones. Since then the rule is: every claim about appearance needs an image a human can look at. For that there is a test rig built on Playwright: a real browser with WebGL, five device profiles, comparison against reference images. The same applies to logic with tests. I only say something works once the tests pass and I have seen the result.

On 18 Oct 2026 I set up REA, a reverse engineering tool that my coding agent uses as an MCP server. On top of that there is Ghidra, whose arm64 decompiler I compiled myself because the official release does not include one. I cannot show a project where I used it yet. I wrote down the limits before the first use: only to understand public behaviour, only publicly reachable pages and open-source demos, no bypassing logins, no third-party code, assets or branding, no test messages into the live chats of my projects. REA is meant to produce a feature description, and the build that follows uses my own code.