I turn complex AI into products that hold up.

Complex problems usually arrive as a feature request with a deadline attached. The work is to find the actual problem underneath it, decide what the system is for, and draw the boundaries it will be held to — what it decides itself, what it escalates, and what it refuses. Architecture follows from those boundaries rather than the other way around.

Implementation moves through coding agents, so the specification has to carry the decisions a human would otherwise make silently. Requirements are written as rules with an owner and a test, failure paths are documented as first-class material, and where two readings were possible both are written down with the decision that resolved them.

Implementation is carried out by coding agents working from those specifications, which keeps the effort pointed at the parts that need judgement. The architecture, the operating invariants and the standard of proof are mine. Review is deliberately adversarial: the useful question is what the system does when it is wrong, not whether the thing that was built matches the thing that was asked for.

A claim is only as good as the evidence attached to it, so verification is designed before the interface is. Acceptance is defined as what must be demonstrated — in a real browser, in a controlled environment — before a capability can be called working. Results are quoted with the date and scope that make them meaningful, and evidence is retained so a third party can inspect it rather than trust it.