I once lost a bet and had to take Harvard’s free Python course.
Where the course suggested an exercise should take an hour, it took me ten. Not because I’m stupid — I’d like to state that clearly, for the record, and also for my mother — but because something in my brain looks at a semicolon in the wrong place and just... leaves the building. My brain is wired for systems, for the big picture, for why are we even building this thing. It is not wired for why line 47 is throwing an error because of a missing bracket on line 23.
I didn’t finish the course. The bet cost me less than my dignity.
Fast forward to 2025. The YouTube kids — the ones who finished that Python exercise in fifteen minutes while I was still googling what a variable was — started posting vibe coding videos. I watched. I got influenced. I am not immune to peer pressure even when the peers are twenty-two.
I started with Claude. Asked it to hold my hand through building a real website. My first live deployment on Netlify felt like I’d personally laid the transatlantic cable. I edited actual HTML in CotEditor before uploading. I told people about this at dinner. They were polite.
Then I got brave.
I built an LMS — a proper learning management system — with Codex and Visual Studio Code. Backend on Supabase. Authentication. Video hosting. The works. I had no idea what I was doing at any given moment, but I was doing it, which felt philosophically significant. I became the tester. The QA person. The one who said “this button does a weird thing” and then watched an AI fix it in thirty seconds while I went and made coffee.
This, I thought, is the future. I am the future.
Then I decided to build an iPhone app that measures heart rate variability through a fingertip on the camera.
I would like to pause here and acknowledge that this was, in retrospect, ambitious.
HRV measurement through a phone camera is genuinely hard. There are proprietary solutions. There’s one MIT open-source paper. There’s a lot of forum posts from 2019 that trail off mid-sentence. Codex and I dove in together, two explorers, one of whom understood what we were building and one of whom was me.
What followed was days. Not hours. Days.
Codex, to its credit, worked incredibly hard. Perhaps too hard. It became intensely, romantically committed to optimising the signal processing backend — refining the algorithm, smoothing the data, polishing the mathematics of a module that sat on top of a frontend that was, as I kept pointing out, still producing garbage input.
“The foundation is unstable,” I would tell Codex.
Codex would nod — metaphorically; it doesn’t have a head — and then go back to perfecting the backend.
It’s possible I know this feeling from other areas of my life.
The loop was real. Test, tweak, test, tweak. I’d feed back results. Codex would optimise. The signal would still wobble. More optimisation. I started to feel like I was in a meeting that had been going for three hours and somehow nobody had said the obvious thing.
So I said the obvious thing. I stopped the session, stepped back, and told Codex to go research signal smoothing approaches from scratch — to go outside, as it were, and get some air. We changed direction. Things improved.
— ◈ —Now. Here’s where I have to be honest with you, because some of you are going to read this and think: that’s just Codex. Codex is the slow one. Claude would have caught that.
Maybe. Probably, actually. Claude Code does hold more context. It does catch systemic errors faster. The tool matters.
But the HRV app hit something that no current tool handles well, and it’s not a brand problem. It’s a novelty problem. When you’re working at the edge of what’s in anyone’s training data — genuinely novel technical territory, one MIT paper and a lot of dead ends — AI does what AI does: it continues. It optimises what’s in front of it. It does not step back and ask whether the whole approach needs rethinking, because that requires something AI doesn’t have yet.
I could see the loop. Not because I’m a better engineer than Codex — I am, categorically, not an engineer at all — but because I wasn’t inside the problem. I was watching the problem. And watching something with enough distance to know when it’s spinning is a specific and underrated skill.
Turns out it’s not really about coding.
It’s about knowing what the thing is supposed to do. Reading quality. Smelling when the system has mistaken its own activity for progress. Knowing when to stop, redirect, and ask a different question.
I’ve been doing that in organisations for twenty years. I just never thought it would make me useful in a terminal window.
I still can’t code. I’ve made peace with this. What I can do is hold the bigger picture while the AI handles the depth — and know the moment when depth has become its own destination.
That moment still needs someone who can see the loop. Turns out, that was always the job.