Directing AI with judgment, not just generation
Software engineering, from hands-on delivery through principal, head-of-software and founder roles. Two projects — a financial-strategy game and a cycle-route planner — built to the standards I'd hold any team to. A capable model is the easy part: unguided, it will confidently ship the simplest plausible answer, or over-build and add risk. The judgment is in directing it well.
Anyone can have a model write code. The harder, more valuable skill is knowing how much AI a problem actually needs — and building the deterministic core that everything reliable sits on.
With both case studies I have taken the approach of running them as real software engineering projects. I capture the decisions as ADRs before building anything hard to reverse, sequence the work into independently shippable phases, and cut scope honestly rather than padding it. The unifying question across both is the same one a good architect asks of every tool: how little of this do we actually need?
Case studies
02 — live, with decision logsA deduction game about exploiting a system you can't afford to break
You profit from a shared system you're also forced to keep alive — bleed it too hard and the crash takes your winnings too. It's a card game first: when the easy fix was to turn it into a traitor game, I refused, and kept everyone complicit. A study in right-sized AI.
Read the case study →A cycle-trip planner for places you've never been
A planner for cycle tours somewhere new, where every fact has to be checked before you trust it on the road. The AI enriches each day — lodgings, the nearest bike shop, a train that takes bikes — but the reliability of the result lies in careful, accurate prompting: told precisely, it flags anything it can't confirm for manual checking rather than guessing.
Read the case study →Three independently style-directed static pages, served on Vercel with no framework and no build step — cleanUrls at the edge, self-contained styles per page, instant deploys that can't fail on a build error. The choice to stay static rather than reach for Next.js is itself documented in the repository's README: right-sized tooling, with an upgrade path deferred until a shared nav or a fourth case study justifies it. The same judgment the case studies are about, applied to the portfolio's own infrastructure.