WHAT A SABBATICAL TO LEARN AI ACTUALLY LOOKS LIKE
I took six months out to go deep on applied AI, across my life and above all across my businesses. This is the first of my quarterly reports on it. I pulled up my own task history to write it, and found the plan I wrote on day one and the thing I’d actually been doing weren’t quite the same project. I set out to apply AI to my work. What I mostly did was build, and I’m not mad about it.
THE SHAPE OF IT SO FAR
If you chart what I got done week by week across these six months, it doesn’t look like a plan. It looks like a heartbeat: two huge spikes near the start, a long sag in the middle, one week completely flat, then a sharper rhythm at the end. I didn’t design that shape, but I recognise it now, and it’s the honest story of what a solo build actually feels like.
I DIDN'T BUILD PRODUCTS. I BUILT THE THING THAT BUILDS PRODUCTS.
Give me a capable AI and six months and I turn into a machine for starting things — a new prototype or product idea most fortnights, most of them parked within the week. It would be easy to read that as a failure to finish. It isn’t. The valuable thing I built over these six months wasn’t any single product. It was the capability to build the next one cheaply, and a habit I’m not giving back.
CAPTURE OUTRAN DECISION, AND EVERYTHING GOT REBUILT
This is the least flattering post in the series, and probably the most useful. Two patterns showed up in six months of my own data that I couldn’t argue with: I captured ideas far faster than I decided what to do with them, and I rebuilt almost everything I built. Neither is quite the failure it looks like, but both taught me where the real bottleneck actually sits.
I GAVE AN AI MY WHOLE LIFE FOR EFFICIENCY. I NEVER NEGOTIATED THE TERMS.
To make my AI assistant genuinely useful, I fed it a joined-up picture of my whole life over six months. A few months in I noticed the thing I’d been carefully avoiding for my clients: I’d built them a vault to keep their data off exactly this kind of system, and handed over my own inner life for a productivity boost. This is about the deal I signed without reading, and what I’m doing about it.
THE MACHINE THAT FORGOT
To write this series I needed to know what actually happened when, so I went to check my own task history. It told me the project started three weeks later than it did, with the wrong thing, and it was completely confident about it. Nobody had tampered with anything. A routine migration had quietly erased the beginning. This is about how organisational memory really dies, and why the fix is also a little frightening.
THE STUFF THAT ACTUALLY RUNS
The prototypes get the attention, but they’re not what six months actually bought me. Look instead at the boring stuff I now use every day and would genuinely struggle without: a way to run client work to a known standard, a strategy loop that actually holds, a task system with a small crew of agents on top, and the pipeline that made this very post. Not a drawer of clever tools. A working operating system for my working life.
A DUTY TO REMEMBER, A RIGHT TO FORGET
I recently caught my own records lying to me, and it left me with a question I couldn’t put down: how much should any of us be in the business of never forgetting? A government has a duty to remember and a separate discipline about what it makes public. A person is not a government, and needs the right to forget. AI is quietly imposing the first on people who were only ever owed the second.
THE MEDIUM WAS NEVER THE MESSAGE
Every Monday morning, without fail, the email arrived. Same subject line, same tone, same imprecise warmth. A developer friend decided to find out whether it needed a human to write it. It didn’t.
FEATURE COMPLEXITY
There are three things that happen when you put a complex, risky feature at the front of your development pipeline. You kill your team. You block everything behind it. Or you spike an external team to build it and hand the code back to people who’ve never seen it. None of these are good. The fix is obvious in retrospect.