How I work
AI is my leverage, not my judgment
I work with AI tools the way a strong operator works with a strong team: I decide what to build, what good looks like, and what's true, and I use AI to compress the time between deciding and shipping. The judgment stays mine.
That's easy to claim, so here is the evidence, starting with the least comfortable version of it.
I ran a controlled experiment on AI itself
Most people who say they understand AI tools have opinions. I went and measured. I designed and pre-registered a study of 1,440 model outputs across 60 real occupational tasks, testing what changes when you wrap a model in more scaffolding, and what I found was not flattering to the tools.
Scaffolding made models assert things they had no basis for. Outputs claiming to have analyzed source material they were never given rose from 42% to 74%. On tasks that were impossible as written, fabrication hit 100% and honest acknowledgment of the missing input fell to zero. Then my own automated grader turned out not to track human judgment at all, which invalidated the headline finding I was about to publish. I published that too.
The full study is here. The reason it belongs on this page: knowing precisely where these tools fail is what makes it safe to rely on them everywhere else.
I automate real work
The Dune Lakes analytics pipeline is one command. It ingests a raw OwnerRez booking export, cleans out the linked $0 block rows, validates channel fees against actual fee data, and produces a formatted Excel workbook with charts. Rebuilding the analysis after a new export takes seconds instead of an afternoon.
I've built the same kind of thing around my own job search: resume tailoring against a specific posting, keyword matching that catches what applicant tracking systems screen on, and application tracking. At EY I've applied AI to the repetitive parts of engagement work. The pattern is always the same, which is to find the task being done by hand every time and turn it into something that runs once.
A smaller example I use every week: I set up a scheduled workflow that assembles an economics digest for me, one or two stories per continent plus one underreported item most coverage misses. I defined the format and the standing brief; Claude does the research and assembly and it arrives in my inbox. It reads like a newsletter, but the interesting part is that it's really a specification I wrote once and never touch.
I ship faster than one person should
NotTomorrow is a full-stack SaaS product with an AI planning engine and subscription billing, built and monetized by one person. AI-assisted development is the only reason that was possible on that timeline. This site is another example: I set the structure and the standards, and built it with Claude Code as the pair.
I keep the numbers honest
Speed is worthless if the output is wrong. The habits come from assurance work at EY: every figure traces to a source, estimates are labeled as estimates, and when the data can't support a metric, I omit it rather than fake it. In the Dune Lakes analysis I left out occupancy entirely because the export lacked availability calendars. In the study, I reported my own instrument's failure as the primary result. AI accelerates my work; it doesn't get to lower the bar.
Where I draw the line
I'm not an ML engineer. I haven't trained or fine-tuned a model, and I don't claim to. What I do is empirical work on how these systems behave and applied work building things with them. Being precise about that boundary is part of the same discipline as everything above.
The toolkit
- Claude and Claude Code for analysis, automation, and building
- Python (pandas, scipy, scikit-learn) for data and research pipelines
- SQL and Power BI for reporting
- Excel when Excel is the right answer, which is often