Make tools,
not tasks.
I'm an AI/ML Strategist at AWS, working with EdTech companies. Four times a CTO before that. I help teams turn AI from a demo into a process they can run without me — then I write down how it worked.
The model was never the hard part
Four times a CTO. These days I build the tools that build the software.
I've been shipping software since 1997 and spent most of it in education technology — four of those runs as a CTO. Today I'm an AI/ML Strategist at Amazon Web Services, working with EdTech companies on what to actually do with these models.
The short version of what I've learned: the model was never the hard part. The order is. My team takes a product team from an idea to market research, an Amazon-style PRFAQ, a requirements doc, and a clickable prototype in a single three-hour working session — not because the AI drafts quickly, but because the stakeholders are in the room correcting each artifact as it's written, and because there's a gate at every seam.
That toolkit is open source through AWS Samples. It runs in Kiro, Claude Code, and Cursor; making it portable took one short adapter file each — which told me something. The process was the asset all along.
Nights and weekends, same idea at smaller stakes. A hand-me-down Mac mini in my basement runs the agents that maintain my notes, triage my mail against rules I can actually read, and keep the house running. When one of them is wrong, I fix the document, not the output.
Make Tools, Not Tasks
Twenty years building software, four times a CTO, and I don't write the code anymore. I notice friction, ask an AI to solve it, throw most of it away, and keep the few tools worth reusing.
read the essay → Field notesAn Idea to a Prototype in an Afternoon
A product team walks in with an idea and walks out three hours later with market research, a PRFAQ, a requirements doc, and a clickable prototype. The toolkit drafts each one; the room makes it right.
read it → First principlesFast, Good, or Cheap
My eval said 100 percent. The honest version said 70.8, and the ranking inverted. Six principles and a worked example for choosing the models that drive your agents.
read it → EssayMy Dad's Old Computer Runs My House
The life and death of software subscriptions, seen from one house: a hand-me-down Mac mini, an AI companion, and the return of fixable things.
read the essay → Field notesA Markdown Editor of My Own
A Mac app that thinks like vim, renders like a technical journal, and exports like it works in an office. Nobody sells that, so we built it in six days — and the interesting parts are the failures.
read the build → Technical companionThe Pocket Fleet: How It Actually Works
Headscale on a $10 server, a fleet-native fork of Blink, mosh sessions that survive elevators, and claude -p as the whole RPC protocol.
Idea → Prototype Toolkit
The written process behind the three-hour session: market research, PRFAQ, requirements, and a clickable prototype, with a check at every seam. Runs in Kiro, Claude Code, and Cursor.
Mac appMarkdown Editor
A native Markdown editor with vim motions, real math rendering, and export that survives contact with an office. Built in six days because nothing on the market fit.
ToolingEval Harness
Repeat-trial model evaluation with honest statistics — Clopper-Pearson intervals instead of a single flattering number. Built after an eval told me 100 percent and meant 70.8.
ToolingCeremony Clip
Finds the four seconds that matter inside a two-hour graduation recording, cuts the clip, scores it, and checks its own mix. Written the night my daughter's video failed.
ToolingImage Kit
A local image-manipulation toolkit built for AI agents rather than people: inspect, transform, upscale, repair faces, and strip metadata — all on the machine, nothing uploaded.
Not seriousDad Jokes
Every portfolio needs one thing that isn't trying to prove anything. Sometimes you just need a good groan.
Earlier
Two degrees, one of them useful in a way I didn't expect
Advising a team on this?
I take on a small number of advisory engagements — mostly EdTech teams trying to get past the demo and into something they can actually run. Email is the fastest way to reach me.
Nate Ober