How I build
What the AI in my workflow does, and where I stay on the hook
Why this page exists
Anyone publishing work built with AI owes the reader a straight answer about which parts the AI built. This page is that answer.
It also answers the sharper version of the question, which is the one worth asking: if a model drafted it, what am I contributing? Short answer: the tooling moved the labor, not the judgment. What follows is the longer one.
The stack
Next.js 16, React 19, and Tailwind 4, deployed on Vercel, with Resend handling mail from the contact form. Claude Code, an agent that works directly in a repository from the command line, does most of the building. GitHub Copilot drafts inline where a whole-file agent would be overkill.
That is the whole list, and it is deliberately unexciting. Nothing here was picked for being new.
Where the line sits
The split is clean enough to state outright, so here it is stated outright.
What the tools do
First drafts. Restructuring. The mechanical half of research and code. The tenth revision of a paragraph that was already fine at the third. They are genuinely good at turning a blank file into a defensible starting point in minutes.
What I do
Decide what is true. Every figure on this site traces to something I can produce on request, and every claim about a program I ran is one I would repeat in front of the people who were in the room.
Deciding what is true is the entire discipline. A model will write a confident, well-formed sentence about a result it has no way to know, and it will do it in the same voice it uses for everything else. Catching that is not a clever prompt. It is a person reading each line and asking where the line came from, which is why the check is a standing step here and not an occasional one.
The skill library
30 shipped skills. A skill here is a written procedure an agent loads before it starts: what the task is, what good output looks like, which constraints it may not break, and how it checks its own work at the end. Think of it as the difference between asking a contractor to build a deck and handing them the drawings, the code requirements, and the inspection checklist.
Most encode methodology I use in enterprise work: competency modeling, assessment design, change management. One is public enough to check. The resume-tailoring skill builds a tailored resume from a single store of evidence rather than from the last version of the document, so a claim gets corrected once and every later draft inherits the correction instead of re-importing the error.
Every skill shares that shape: constraints stated up front, an evaluation step built into the skill itself, reusable structure rather than one-off output. It buys the only thing worth building a library for: the tenth engagement opens where the first one closed.
Worked example
Scoping a proof-of-value pilot
A proof-of-value (PoV) is the time-boxed paid pilot an enterprise runs before committing to a platform. Scope one badly and it ends in a stalemate over whether anything was proven. That is an expensive way to learn nothing.
The teardown on the Work page lays out a 30-day version: discovery questions grouped by stakeholder, the value hypothesis the pilot has to test, how adoption gets measured while it runs, and the executive readout that closes it. The structure came together in an agent session. The content came from having sat in these, and it is the part that took years rather than an afternoon: which questions surface the real evaluation criteria, which numbers a sponsor will accept, and what to cut when the readout gets twenty minutes instead of an hour.
Live and checkableRead it end to end: the 30-day PoV scope →
The work itself
This page covers method. The Work page covers outcomes: the programs, what they measured, and what changed.
See the work