I help teams get important work moving.
Bring me a workflow buried in a backlog, held together by workarounds, or dependent on one person. We start with a case the team already understands and build a system the people doing the job can use and change.
I’ve built production systems and led company-wide platform changes. At NerdWallet, I led a data warehouse transition that cut the time to backfill historical data from weeks to under 48 hours.
What clients could do
The search case is public. The other examples are client systems; identifying details stay private.
-
Challenge a search result
A team searching about 200,000 expert profiles could see why a result ranked, challenge it, and change the ranking. I built the search and the trace they used to inspect it. Read the technical case.
-
Correct a failed case without writing code
I built a workflow that let domain experts run a real case and show what should have happened. The case became a check: an implementation error could be repaired against it, while any rule change still needed human approval. Read how the correction loop works.
-
Start a review from the evidence
I built a system that assembled 360-degree feedback, the team's skills rubric, and past reviews into a draft. The manager revised it and still owned the review. See the client systems.
Public work you can inspect
Client work is often private. The code and papers below are public.
-
Repo-Native Alignment
An agent working in an unfamiliar repository can find what a change touches, locate related code, and recover the business reason behind it before editing.
-
Sketch-CE
When a system gets a case wrong, the domain expert can show what should have happened without translating it into code. Sketch-CE turns that correction into a check an agent can work against while people keep control of the business rule.
-
Unified Hi-Fi Control
One knob on my couch controls four audio systems. The project connects that knob to the web, Apple clients, and MCP. I use it every day.
Hard questions from the work
-
How do we know we're building the right thing?
Start with what someone should be able to do. Then choose what to build and what result would tell you it worked.
-
Why didn't cheaper output make the work better?
When one task gets cheaper, evaluation, exceptions, and judgment often become more important.
-
Why does the agent keep making the same mistake?
How to preserve a failed case so the next run behaves differently.
Bring me one case that shows the problem
Tell me what should have happened, who knows the work, and where the current process failed. I'll tell you whether I can help.