I'm a generalist. I build across software, construction and AI — and the conviction underneath all of it is the same: well-designed systems let teams do work that would otherwise be impossible.
AI does not fail because it is stupid. It fails because of what is missing around it — the wrong tools, the wrong grounding, the wrong substrate, no feedback loop. Raw intelligence is not the bottleneck. Equipment is.
Get the equipment right and the model becomes a colleague. Get it wrong and you've got an expensive intern who can't find the kitchen.
R · I · G · H · T · S
RIGHTS is the practical guideline I follow when I build AI systems that have to do real work. Six factors — refinement loop, iteration loop, grounding, human cooperation, tools, substrate — every one of which has to be properly in place for the system to land.
It works as a diagnostic too: when an output isn't good, walk the letters and find the factor that's missing. Most "AI doesn't work" stories are one factor dragging the whole product down.
Read the breakdown →I built Olive by applying RIGHTS end to end: an autonomous assistant that measures, prices, drafts, and reports — accurately, from email in to deliverable out.
It works because of the toolbelt around it.
Don't slot AI into your existing Python and JSON infrastructure. Flip the relationship.
The AI should be the thing doing the thinking. Python mechanics and JSON schemas should exist to complement the AI — playbooks and guidelines, not dependencies the model is forced to obey. That inversion is the unlock. It lets your stack work on problems like a member of the team, instead of waiting for a colleague to start typing.
If you point to hallucinations and AI errors as the reason not to adopt — you may as well stop hiring humans, because they make mistakes too. The right answer is to be pro-adoption and pro-risk-mitigation at the same time: train the model to be brilliant, and make the sandbox around it even better.
A great employee in a well-designed environment will outperform a perfect one with no guardrails. And there is no perfect one.
For the last few decades, the only way to use the tools on your computer was to type and click. Now it is speaking to your computer like you speak to a colleague.
Software, construction, finance, design, policy, retrofit science — each domain looks complete from inside itself, and incomplete from anywhere else. The interesting problems live in the gaps. The polymath approach is not a CV summary; it is the working method.
We are in the early years of a long transition. The interfaces that will define the next decade are not screens we click on — they are systems we speak to, ones that hold context and run work alongside us. The leverage is no longer in being the most technically skilled person in the room. It is in being the person who designs the room.
I build because I think well-equipped teams can do work that nobody currently believes is possible — in construction, in housing, in software, in policy. I would rather work on those problems than write about them.
Open to conversations with people building in those directions.