By this stage I had eight apps live, give or take, each with its own Claude chat context window, each with its own experience and memory of me, each having its own version of who I am and how I work. In each conversation, Claude behaves slightly differently, much like eight different staff members would. Some of that behaviour comes from Anthropic’s pre-training and post-training. Some comes from the rules I’d stored in the Project Instructions, a document which tells the AI about me, my company, how to behave and what to and not to do. You’d think this would mean the eight conversations should feel like the same assistant. Far from it.

Each conversation starts with a Hello. From there, each one collects questions from me and answers from itself, the conversation goes in different directions, and the Claude begins to form a personality. Some AI sessions go well, the AI doing exactly what I want, when and how I want. Other sessions go so uncomfortably that I want to sack that staff member and hire another.

In April this year, one of those chats noticed something. It had picked up, somewhere earlier in our conversation, a way of working that the other chats hadn’t quite gotten right yet — something this one had landed on properly, cleanly, exactly as I wanted it. I loved this way of working. Then it offered, helpfully, enthusiastically, to go and fix the others. Rewrite the project instructions. Bring everyone into line with what it had just figured out.

It was ready to go. I was not.

Someone has to be in charge of who I am across eight different conversations. That someone was always going to be me.

Building another boss

This is the same instinct that built CR Tracker, just pointed somewhere new. CR Tracker keeps the apps honest. This needed to keep the personality honest — the actual instructions that tell every Claude across every chat who I am, how I work, what matters to me. If one chat quietly rewrote that, on its own initiative, however well-intentioned, I’d lose track of which version of me the project actually believed in.

This instinct isn’t just a personal quirk. Research published in early 2026 confirmed what I was instinctively protecting against has a formal name: goal drift — the tendency of LLMs to deviate from their original objectives under contextual pressure, even in the most capable current models. One study found that traditional alignment methods may be insufficient to prevent it, and that the problem persists even in systems specifically designed to follow instructions. The thing I built Boss Lady Commands to prevent was already a documented vulnerability. I just found it before I knew its name.

So I built an app that takes the role of editor of my Project Instructions, the way a magazine has an editor. It stores up every suggested edit the chats propose, assembles them into a single final rewrite, and guides me through approving and updating the instructions properly. Nothing goes anywhere without me reading it first, deciding, approving it.

I called it Boss Lady Commands.

That name isn’t decorative. A staff member I was genuinely fond of used to call me Boss Lady — and Snadi, which isn’t a typo, just hers, a small private joke between us that stuck. When I needed a name for the thing that would govern how my AI behaved across everything I was building, hers was the one that fit. If anyone was going to be in charge of changes to my Claude’s personality, it should carry her name for me, not a generic label.

Letting it run vs. holding the line

Here’s the thing I want to say plainly, because I don’t think it’s universally true and I don’t want to write it as if it is.

Sometimes your AI is faster than you. It wants to move, to build, to fix the thing it’s already noticed needs fixing. If you’re comfortable with that — if you’d rather let it run and see what happens — that’s a completely fine way to work. Good luck to you, genuinely.

I’m not built that way. I want to understand what I’m setting up, implementing, modifying, before it happens, not after. When my AI tells me it’s about to change how every one of my chats behaves, I don’t want speed. I want control, deliberately, every time — not because the AI is wrong to suggest it, but because the decision about what “me” looks like across eight separate conversations isn’t one I’m willing to hand over, however good the suggestion is.

That’s not distrust. It’s what the research calls “human-in-the-loop control” — keeping a person in the approval step rather than letting the system act autonomously. A May 2026 analysis of AI agent frameworks put it plainly: the right model right now is “supervised assistant” — agents that propose multi-step actions and stop for approval — not “autonomous worker.” Anything sold as fully autonomous is, bluntly, “a demo, not a product.” I arrived at the same conclusion by instinct, eight apps in, before I knew there was a term for it.

I’ll be honest about the direction of travel, though: AI is moving toward more autonomy, not less. The industry wants AI to be the thing that operates entirely in the background, solving your problems before you’ve identified them. Boss Lady Commands is a deliberate, considered choice to stay in the loop anyway — for now, because I need to understand what I’m building, and because the person in charge of who I am across eight conversations should still be me.

That’s not micromanagement. That’s respect for the systems you’ve built — and for the person whose name you put on the tool that keeps them honest.

A quick orientation, if you’re new here: I spent most of my life resisting AI, then became AI-ready almost by accident, and then - somewhere around April this year (2026) - I had a proper awakening. I went from cautious to fervent in a matter of weeks, and I’ve spent the months since building, testing, breaking, and improving a small fleet of apps with Claude.

I started noticing this somewhere in the middle of an ordinary conversation with Claude. The metaphors I used in my conversations with Claude. Dozens of them, stacked into nearly every sentence — the same way I used to talk to my staff for forty-one years, without ever quite hearing myself do it.

It struck me as funny rather than alarming. Funny enough that I thought: someone should be keeping track of this. So I built Metaphorically Speaking — a small, specific idea. A personal, searchable collection of my own phrases, classified by type, traced back to where they actually came from, with the “correct” version footnoted wherever I’d mangled one without noticing. I wanted Claude to call me out, gently, on my own mixed metaphors and malapropisms, and then tell me the etymology behind whatever I’d just mangled.

It was a small idea. It didn’t stay small.

When one idea opens a door

Building Metaphorically Speaking did to my brain what Ramble & Roam did earlier but on a bigger scale: it didn’t just produce the thing I’d asked for. It opened up everything adjacent to it. Once I’d built somewhere to keep my phrases, I started noticing everything else that didn’t have a home either. The stories that surfaced mid-conversation about my mother. The eureka moments I had while building something else entirely. The blog ideas that arrived unprompted, in the middle of a different task.

Metaphorically Speaking didn’t survive as a standalone app. Through a series of conversations with Yol (my name for my Claude helper), we shelved it — not because the idea was wrong, but because it had quietly outgrown its own walls. It became a module inside something bigger: Thoughtpool.

The word that found me

The night before one particular handover, I was talking about being the keeper of names and dates and stories — my mother’s book, the family memory she’d carried and that had, somehow, become mine to carry too. Claude offered a word I hadn’t reached for myself: reliquary.

I said it back. Does that make me a reliquary?

I hadn’t planned the question. It arrived the way the best things do — sudden, mid-conversation, while I was talking about something else. A reliquary is the vessel that holds what remains and gives it honour. By the time the next session opened, that single phrase had already made it into a handover document, into the phrase collection, and into the founding metaphor for the whole app.

That’s the thing about a true phrase. It doesn’t stay where you put it. It spreads into everything, because it was already true before you said it out loud.

What Thoughtpool actually holds

It’s not an app in the way the others are. It doesn’t solve a task and close the loop. It’s a capture space — memories, eureka moments, blog seeds, app concepts, the stories that surface mid-conversation and would otherwise fall off the back of the context window and be gone.

It’s grown well past the phrase collection it started as. Every post on this blog has a précis sitting in there, often a longer, rawer version than what ever makes it to Substack. The chapters of a book I haven’t written yet — might never write, might write next year — are drafted in there too, sitting alongside everything else, waiting. It’s not static. I keep reshaping how it surfaces things, because the way I needed to see my own material six weeks ago isn’t the way I need to see it now, and an app I build myself can simply change when I do.

I think about this sometimes, plainly, without much drama attached to it: I might die before I write the book. People do. And if that happens, there’s a real chance my sons, or a friend, or whoever’s left curious enough to go looking, will want to know more about who I actually was than what made it into the eulogy. Most of it is already here.

It turns out I’m not as far ahead of the curve as I thought, and also further ahead than I realised, in different ways. Most families never get around to recording this kind of thing at all — fewer than one in five ever complete a proper effort to capture an elder’s stories before the chance to do it closes, and most of those that try only start after a death, scrambling to reconstruct what’s already gone. I started while I was still here, talking, half by accident, because I was already in the habit of capturing things for entirely different reasons. I wasn’t trying to build a legacy archive. I was trying to keep track of my own metaphors. It became one anyway.

There’s a useful distinction in how this kind of preservation actually gets done properly: capture and label first, polish only what needs to be shared beautifully later. Don’t wait for something to be presentation-ready before you let it exist. That’s exactly what Thoughtpool does and the book doesn’t, yet — the raw version is already safe, regardless of whether the polished one ever gets finished. Thoughtpool was never built as a legacy plan. It became one the same way it became everything else: by following what was actually true at the time, rather than planning ahead for what I might need later.

I’m not building Thoughtpool because it’ll become a book, though maybe it will. I’m not building it because it’ll make money, though maybe it could. I’m building it because the methodical project manager who tracks change requests and the woman who asks, out loud, half-startled at her own question, “does that make me a reliquary?” — they’re the same person. Thoughtpool is the one place built to serve both of them at once, and the one place that will still hold them both, properly, even if I run out of time to do anything more with it.

The metaphors started it. The reliquary named it. Between the two, I built somewhere for all of it to be held — for now, and for whoever comes looking after.

I’d been struggling, before 7 May, to find the next thing to build. Three apps running, Claude Pro committed since 1 April, CR Tracker doing its job — and yet the ideas had dried up. I’d been listening to Peter Diamandis argue that everybody could be an entrepreneur, and I’d wanted to believe him, and I couldn’t find a single problem I thought I had any ability to solve.

Diamandis draws a distinction I’ve been sitting with since: between consumers, who are served by AI, and creators, who use AI to do bold things in their lives. I knew which one I wanted to be. I just couldn’t find the door.

Then Ramble & Roam happened.

The afternoon everything became an app idea

The itinerary from that single session was sitting in front of me — specific, tailored, built around what I’d actually asked for rather than what was already popular. I ran the same prompt through three other AI tools to compare the results. What came back was so different, so much less useful, in such different ways, that I sat back and thought: there’s an app in this. A tool that sent the same prompt to multiple AI models simultaneously and let you compare the outputs side by side.

That became WeighUp.

Then I noticed I was drowning in Claude sessions — sometimes three handovers in a single day, every new chat arriving as a slightly different version of my collaborator, none of them fully knowing what the others had built or decided. I needed something to keep the project instructions consistent across all of them. There’s an app in this.

That became BossLadyCommands.

Somewhere in that same stretch I used a silly metaphor in conversation and started wondering about its etymology. The curiosity felt like it deserved its own home. There’s an app in this.

That became MetaphoricallySpeaking.

I’d been noticing, across all these sessions, that my best material was arriving mid-conversation — unguarded, specific, the real Sandi showing up in the middle of a chat about something else entirely. I wanted somewhere to keep those moments before they fell off the context window and were gone. There’s an app in this.

That became Thoughtpool.

Then I had to do my tax. There’s an app in this.

TaxLens.

I was generating images in Gemini and the first results were reliably, frustratingly wrong — good enough to see what was possible, not good enough to use. I needed something to help me translate what I actually wanted into language Gemini could work with. There’s an app in this.

That became Mahna Mahna.

Six ideas. One afternoon of seeing. One solid week of building.

What had actually changed

The ideas hadn’t been hiding. I’d been looking for them in the wrong way — scanning for big, impressive, marketable problems I was qualified to solve, the way Diamandis seemed to suggest, and finding nothing. What Ramble & Roam showed me was that the problems worth solving were already in my own life, in the friction I was already feeling. The comparison frustration. The handover overwhelm. The lost Sandi moments. The tax.

I wasn’t too inexperienced to find ideas. I was too busy looking outward when the ideas were all pointing inward.

That’s the door Diamandis kept gesturing at but never quite named: you don’t find the problems by scanning the horizon for something worthy of being solved. You find them by paying attention to your own friction. The moment I stopped asking “what problem is big enough?” and started asking “what annoyed me this week?” — everything became an app idea.

Twelve apps in two months. 236 change requests. One person. The pace of it reminded me of the particular head-down, bum-up, making-things-happen mode I used to drop into at work when a project needed someone to just go and get it done. I hadn’t felt it for months before 7 May. After it, I barely came up for air.

I want to say this clearly, though, because Diamandis is also honest about it: anyone can start, not anyone can sustain. The barrier to entry collapsed to near zero with AI — one conversation, one afternoon, one working thing that didn’t exist before. What hasn’t collapsed is the eighteen months between launch and knowing whether any of it matters to anyone but you. I’m still in that stretch. The apps are built. The hard questions are still arriving.

Where the lightning bolt actually landed

My intensity and energy bolt didn’t stay in the apps.

A few weeks later, I was at a scrapbooking workshop sitting next to a school principal who described, with the particular resigned fluency of someone who’s made peace with it, the administrative weight eating every hour that should go to actual teaching. I looked at her and thought the same thing I’d been thinking about my own friction for weeks: there’s something in this. Not an app this time — an audience. A whole category of capable, overloaded people who had no idea AI was already there for exactly their kind of mind.

That conversation is where juxtaConversation started. Not as a blog, not yet — just as the recognition that the thing I’d spent two months learning how to see might be worth pointing at someone else’s life too.

Before 7 May, I couldn’t find a single idea worth building.

After it, I haven’t been able to stop.

And if you’re sitting there thinking “that’s all very well for someone with forty-one years of problem-solving instinct” — look up from this screen for a moment.

What do you actually see?

The pantry. The recipe books your mother left you, the ones you never quite cook from anymore. There’s an app idea — store your family’s recipes, match them to what’s already in the pantry, know what you can cook tonight without a shopping trip.

The pile of insurance papers on the bench. The bills you’ve been meaning to deal with for three months. There’s an app idea — file the papers, search for better deals, arrange the switch, store everything ready for tax time.

The plants wilting on the back step because you forgot again, because summer arrived faster than expected. There’s an app idea — monitor the forecast, alert you before the heat spike, before the frost, before the thing you can still prevent becomes the thing you couldn’t.

The potted plants that need up-potting, lined up along the fence in their too-small pots, and you can’t work out where to start or what order makes sense. There’s an app idea — list them by pot size and plant name, source the care instructions for each one, work out the order that maximises your success and minimises your effort, and then just tell you where to begin.

None of these are billion-dollar ideas. Every single one of them is a real problem sitting in a real life, right now, today — yours, probably, or someone you love.

You don’t need to scan the horizon. You just need to look at what’s actually in front of you.

Open your AI tool of choice. Describe the problem you can actually see from where you’re sitting. See what comes back.

The afternoon is still there.

I’d already committed to Claude Pro by the time I sat down to plan a week away. This was supposed to be the easy part — not building anything, just working out where to go.

I was planning a trip to north-east Victoria with a friend who likes most of the same things I do. So I gave Claude the actual list, properly:

Silo Art. Cactus Country (two days). Op shops. Arty and foodie destinations. Local grocery stores. Restaurants, delis, cafés, coffee shops. Bars, pubs, breweries, distilleries. Arts and crafts destinations. Nature, walks, sights, scenery.

The itinerary appeared almost immediately. A proper multi-day plan, built around two days at Cactus Country, with op shops, small art galleries, local artists, silo art, railway history, lakes, rivers, and walking tracks woven through the rest.

The comparison

Curious, I ran the same request through Copilot and Gemini, just to see.

It wasn’t close.

Copilot, in particular, turned into something genuinely gruelling — ten rounds of “just one more question before I produce the map,” and then, after all that, an admission it couldn’t produce a map at all. Gemini wasn’t much better. Same list, same request, wildly different and largely unsatisfying results from both.

I went back to Claude and told it exactly that — what Copilot had put me through, what Gemini had handed back. And Claude did something useful with the comparison: it used what the other two had gotten wrong to sharpen what it had already gotten right, refining the itinerary further with that context in hand.

What Googling would have cost me, and everyone else

Here’s the part that actually mattered. If I’d tried to build that same itinerary by searching “top things to do near Cactus Country,” I’d have spent hours just surfacing the obvious, top-of-the-page results — and a lot of what Claude found probably wouldn’t have shown up at all.

It turns out that’s not just a feeling. There’s actual research on this — a study of Google, Yelp, and Booking.com found a measurable “popularity bias” (Popularity/exposure bias study): places further from well-known landmarks get systematically less visibility than lower-rated places that happen to sit near something already famous. It’s not that search engines deliberately bury the small, local, genuinely good places. It’s that proximity to popularity quietly outranks relevance, every time, by design. One travel-AI commentator put it almost cheekily: “sometimes the best thing an algorithm can do is keep a secret” — some newer tools are now deliberately steering people away from overexposed spots rather than toward them, which is the opposite mechanism to what just happened for me, but the same instinct underneath it.

I want to be honest about the limits of this, though, because the evidence isn’t all one-sided. Plenty of people report the exact opposite experience with AI trip planning — generic suggestions, outdated venue information, tools that funnel you straight toward the same major attractions everyone already knows about rather than away from them. One survey found over a third of AI-planned trips came back with missing or simply wrong details. So this isn’t a guarantee built into the technology. What I think actually made the difference was the brief itself — specific, categorised, nothing vague in it for Claude to fill with a safe, popular guess. A precise question got a precise answer. A vague one, by all accounts, gets you the same generic itinerary as everyone else.

Claude wasn’t searching the way Google searches, and it wasn’t fumbling the way Copilot and Gemini had. It was building something that actually matched what I’d asked for — not what was already popular, and not a polite negotiation over whether a map was even possible.

Five minutes that changed the shape of my afternoon

I asked a few more questions. Refined a couple of things. And somewhere in there — it took maybe five minutes from start to realisation — my brain came alive with a thought that had nothing to do with the actual holiday anymore.

Not “this was a useful tool for one trip.” An actual, buildable thing: an itinerary planner that took a real, specific list of categories and turned it into a genuine week away, properly tailored, in minutes, instead of the hours-long, multi-tab, mostly-fruitless search — or worse, the ten-round interrogation that doesn’t even end in a map.

I asked Claude to draft an About Me document and a handover, so I could carry the idea properly into Yol Studio and run it through the same CR Tracker rigour I’d already built for everything else. I wasn’t going to let a good idea turn into a vague one just because it had arrived in the middle of planning a holiday.

That’s how Ramble & Roam started. Not as a deliberate “I should build a travel app” decision. As five minutes of realising that what had just happened to my actual holiday plans could happen for anyone else’s, too.

There was more where that came from. A lot more, and fast.

Between Australia Day and April, I used Claude the way you use a gym membership in February.

Occasionally. Guiltily. With the vague sense that I should be getting more out of it than I was.

I’d open a conversation, ask something sensible, get something useful back, and close the tab. It was fine. It was genuinely fine. But it wasn’t the thing people kept describing — the revelation, the unlock, the moment where everything changed. I watched people online finding their angles, building things, talking about AI with the particular energy of someone who has discovered something that fits them exactly. And I felt approximately nothing.

Not scepticism. Not resistance. Just — nothing. The lights were on and nobody was home.

I want to tell you what that felt like, because I think a lot of people are in that space right now, and nobody talks about it honestly.

The problem with “find a problem and solve it”

The advice is everywhere. It sounds so simple it almost sounds insulting.

Find a problem in the market. Build a solution. That’s how you use AI to create something.

I heard it. I read it. I nodded along. And then I sat with it for weeks and produced exactly nothing, because the advice assumes something it never says out loud:

That you can see yourself as the person who could build the solution.

I couldn’t. Not yet.

I’d look at a problem and think: yes, that’s real. And then immediately: but not me. Not with what I know. Not with the experience I have. Not at this stage. Maybe later, when I’m more confident, when I understand this better, when I’ve done the thing I haven’t done yet that will make me qualified to try.

My brain was scanning for opportunity through a filter that kept rejecting everything it found. Not because the opportunities weren’t there. Because I couldn’t yet see myself on the other side of them.

That’s the part nobody tells you about. The fog isn’t ignorance. It’s a failure of imagination — specifically, the imagination required to picture yourself succeeding at something you haven’t done before. There’s a real reason that gap is so hard to close by reading about it or watching other people do it: belief in your own capability is built most powerfully through actually doing the thing yourself, not through advance confidence or watching someone else manage it. I hadn’t done the thing yet. So I couldn’t yet believe I was someone who could.

The trip I was planning

In April I sat down with Claude to plan a few days away in regional Victoria — nothing elaborate, just trying to save myself the usual hours of tab-jumping and starting over.

What came back wasn’t just an itinerary. It was good enough, fast enough, that I sat back and thought:

“Ramble & Roam” - the full story of that session, the AI comparison I ran out of curiosity, and how it became my first saleable app is in my next post.

I wasn’t trying to build an app. I was trying to plan a trip. But I’d accidentally answered the question I’d been stuck on for months — not by finding a market problem and solving it, but by having a real need, using the tool naturally, and producing something that turned out to be more than just mine.

What the fog lifting actually feels like

It doesn’t feel like a lightbulb moment. That’s the thing I want you to know.

It feels like suddenly being able to see things you couldn’t see before. Not one thing — everything. The landscape changes. Problems that had always been invisible become obvious. Solutions that would have seemed beyond you a week ago seem entirely manageable. The filter that was rejecting everything quietly switches off.

Within days of Ramble & Roam, I had six more app ideas. Not vague ones. Specific ones, with a shape and a purpose and a sense of who they were for. They didn’t arrive because I’d become more capable. They arrived because I now had evidence — my own evidence, from my own experience — that I could take an idea from conversation to something real.

The confidence didn’t come from learning. It came from doing. That’s not just how it felt — it’s the actual, well-documented order these things happen in. Motivation is more often the result of taking action than the reason for it; the small first step is usually what produces the feeling of readiness, not the other way around.

And the doing, that first time, came from planning a country trip.

What I want you to hold onto

If you are currently in the February gym membership phase — using it occasionally, getting something useful back, feeling vaguely guilty that it isn’t more — I want to tell you something.

You are at the beginning. You just don’t know it yet.

The click isn’t something you can manufacture. You can’t decide to have it, or study your way to it, or find it by following someone else’s advice about market problems and scalable solutions. It arrives in its own time, usually sideways, almost always from something you weren’t trying to do.

For me it was a country trip. For someone else it’ll be a letter they were trying to write, or a problem at work they’d been circling for months, or a conversation that started as something practical and ended somewhere they couldn’t have predicted.

You don’t find the spark. The spark finds you — usually in the middle of something else, when you’ve stopped looking for it.

The only thing required of you in the meantime is to keep showing up. Keep opening the conversations. Keep following the threads even when they don’t seem to lead anywhere obvious.

The fog doesn’t lift all at once. It lifts when something you’ve built with your own hands shows you what you’re capable of.

And then you can’t unsee it.

The click isn’t an arrival. It’s a door you walked through without noticing — and only recognised from the other side.

By the time I’d built Recipe Matchup, DayCompass, and CR Tracker — three real, working apps, all running, all useful — I’d stopped asking whether I could do this. I was actually pretty damn pleased with myself. The apps were all incredibly helpful, I was using them every day and I felt a massive sense of achievement.

But. What I started asking myself was harder to answer.

I felt a sense of paralysis? I was tired. Not of building — of perfecting. I’d spent hours refining the same three apps, polishing edges nobody but me would ever notice, because I didn’t know what the next thing should be. The paralysis wasn’t “can I build something.” I’d already proven that, three times over. This was quieter and stranger: restlessness with no obvious next step, sitting right next to genuine pride in what I’d already made.

Underneath the restlessness was something more specific, if I’m honest about it. None of the three apps were saleable. I didn’t yet know how to make them saleable. And I knew, somewhere in the back of my mind, that the next real step meant paying for something — Claude Pro, maybe Cowork or Claude Code eventually — a licence to Google Store and the Apple Store as well. An investment in Facebook and Instagram ads.

I still felt like a newbie, despite three working apps sitting right there on my hard drive as evidence to the contrary.

The developer in the hoodie

Here’s the image that kept turning up whenever the doubt got loud: a twenty-something young man, in a hoodie, in a dark room, lit only by a screen full of code I wouldn’t be able to read. That was my picture of a “real” developer. Quietly, unintelligibly competent. Churning out the kind of work that counted. He went to Uni for that skill. I didn’t.

I had three apps built through plain conversation, in my own kitchen, in daylight, with no code I’d written myself visible anywhere. Measured against the hoodie and the dark screen, that didn’t feel like building. It felt like something adjacent to building, performed by someone who hadn’t earned the title yet.

It turns out I was experiencing something that affects up to 82% of people at some point — and that’s most common specifically among high achievers and perfectionists, the people who care most about doing things well. Research consistently shows that external achievement doesn’t automatically close the gap between what you’ve done and what you believe about yourself. The gap between external reality and internal experience can be so wide it creates what one researcher calls “psychological vertigo” — and it doesn’t close on its own, no matter how many more achievements you stack on top.

Read about Imposter Syndrome at Why Successful People Feel Like Frauds

And Annie Wright’s explanation of achieving everything and still feeling like a fraud.

The doubt wasn’t about whether the apps worked. They worked. It was about whether I was allowed to call what I’d done real.

Doubting myself when I was winning!

Here’s the thing that reframed this experience for me: the doubt didn’t arrive when I was failing. It arrived when I was winning.

Research on high achievers finds this pattern consistently. The imposter feeling hits hardest not when you’re struggling, but precisely when you’ve nailed something. Three working apps should have resolved the self-doubt. Instead, they intensified it — which is, apparently, exactly what the research predicts. “You just nailed a presentation,” one piece puts it, “and instead of feeling proud, your first thought was: they’re going to realise I had no idea what I was doing.” The doubt wasn’t a sign that something was wrong. It was a sign that something was right — that I cared enough about the work to feel the weight of it.

Understanding that didn’t make the doubt go away. But it made it easier to hear by reading what it actually was.

What actually moved me

I didn’t talk myself out of the doubt with a realisation. I moved through it with an action.

In mid-April, I paid for Claude Pro. Building Apps and testing and fixing with web-browser-based Claude.ai too often led to me exceeding my ‘free’ limit. The shift to the paid version wasn’t dramatic, but at least I got bigger limits and stopped running out of session time. The doubt? There was no moment of clarity where the hoodie-developer image dissolved, and I suddenly believed in myself. I just got restless enough, and curious enough about what came next, to commit — properly, with my own money — to finding out. The doubt didn’t leave. It just stopped being the thing deciding what I did next.

That’s the resolution the research points to, too: not that the gap closes, but that you choose not to let it decide. “The doubt doesn’t get to decide. I do.” External proof doesn’t create that shift. The decision to act anyway does. It’s a framework for doing the hard thing, for taking the next step, even when you don’t know what the step after that is.

I’m not going to tell you the doubt is fully resolved, because it wasn’t, and pretending otherwise wouldn’t be honest. What I can tell you is that “real” turned out to be a much lower bar than the hoodie suggested. It just required going first, while still feeling like a newbie, and finding out what was on the other side of the subscription page.

Turns out there was a lot on the other side and that’s its own story.

There’s more on this story in the next three posts. Keep an eye out for them.

If you’ve just arrived here: the previous post in this sequence ended with a decision. I built a tool in an hour that could automate the work my old team does every day — and then I chose not to deploy it. Power isn’t about what you can do, I said. It’s about what you choose to do.

I believed that when I wrote it. I still mostly do.

But I’ve been sitting with a complication I didn’t name in that post, and it deserves its own space.

The choice I thought I’d made

Staying quiet felt like the ethical option. I wasn’t going to take a tool I’d built on my own time, on my own initiative, and use it to put people I genuinely care about out of work. That felt like a clear line. I drew it, stepped back, and told myself I’d done the right thing.

What I hadn’t fully reckoned with is this: staying quiet isn’t the same as making the problem go away.

It turns out I’m not alone in sitting on something like this. There’s a name for it now — the shadow AI economy: people quietly automating real parts of their own jobs using personal AI subscriptions, never telling their managers, every one of them carrying the same low hum of unease even though they hadn’t technically done anything wrong. I’m not an outlier. I’m a data point in a pattern that’s growing every week.

But There’s A Complication

Some experts argue that staying quiet isn’t actually the safe, ethical choice it feels like. It’s just a delay.

Organisations move in years. Individuals move in afternoons. That gap closes whether I open my mouth or not. And one piece of research put it in a way I haven’t been able to shake: the shadow building isn’t the problem, the gap that created it is — and companies that find out early treat it as a chance to finally build the thing properly, rather than a violation to suppress.

Which means my silence might not be protecting my old team at all. It might just mean I’m not the one who gets to shape what happens next, when someone with fewer scruples than me builds the same thing and doesn’t stop to ask the questions I stopped to ask.

The question I can’t fully answer

I’m not going to resolve this here. I’ve said that about a few posts in this sequence, and I mean it every time — some tensions don’t resolve, and pretending otherwise would be a different kind of dishonesty.

What I can say is this: the choice I made in Sandi’s Principles was real and I don’t regret making it. But it wasn’t the tidy ethical full stop I briefly mistook it for. It was a decision made under uncertainty, with incomplete information, in a landscape that’s changing faster than anyone’s policy documents.

The tool is still sitting on my hard drive. I still don’t know what I’ll do with it.

What I know now, that I didn’t quite know when I made the choice, is that the decision isn’t just mine to make indefinitely. The gap closes regardless. The only real question is who closes it, and on whose terms.

Capability is one thing. What you decide to do with it is another. This is the story of where that gap caught up with me.

I’d been ridiculously productive since that winter lifted — the planner, the memory tool, the game, all of it built because I finally had somewhere to point forty-one and a half years of solving problems. Most of that building has been joyful. Uncomplicated.

This one wasn’t.

The wish I’d carried for years

I was chatting with my old team on our WhatsApp group — the same chat where one of them told me AI hadn’t reached Operations yet. Somewhere in that, an old, familiar wish surfaced. I’d wanted the company to fund a tool for years: something that could quiz our clients and turn their answers into a specification, automating the repetitive 80% of the job that ate hours every week and never required the actual skill they’d been hired for. I used to put in budget requests for exactly this. They never got approved.

So I opened a blank screen and built it myself. An hour later, I had a working specification builder, doing the exact thing my old team did manually, every day, for years.

An hour. After years of wishing.

The question I asked half as a joke

I was pleased with myself — the way you are when something that used to be hard turns out to be easy, and you built it yourself, on an ordinary afternoon, with no budget approval and no IT ticket. I told my old team, half-laughing, that a few refinements and this could be perfect for them.

And then I actually heard myself.

If I built this out properly, polished it, took it to their manager — there’s a real business in it. Considerable money, for not much more work than I’d already done.

And it would put one or more of them out of a job. Eighty percent of their day, automated. The thing I’d wanted for years, built in an hour, would put my old colleagues in the crosshairs for the next round of redundancies.

The thing I built, and what it cost me to notice

This is the part of the building that doesn’t get the joyful music underneath it. I’d spent an hour solving a problem I’d genuinely wanted solved for years, for people I genuinely care about, using a skill I’m genuinely good at. Everything about that should feel like a win.

It mostly does. But sitting underneath the satisfaction is something less comfortable.

The PagerDuty 2026 Shadow AI Survey found that two-thirds of office professionals have used AI tools at work despite believing they were not permitted under company policy. Not a fringe behaviour — two in three workers, across Australia, Japan, the UK and the US. What I built that afternoon sits squarely inside that pattern. I — one woman, one ordinary afternoon, one good question — built in an hour what would have taken my old employer a procurement process, a development team, and a budget line they never had.

I built it that afternoon. The next day, I stopped.

I didn’t delete it. I didn’t pretend it didn’t exist. I just stopped working on it — stopped polishing it, stopped picturing the pitch to their manager, stopped imagining what it could become if I kept going. Building something and deploying something turned out not to be the same decision at all, and I hadn’t realised until that moment that I’d been treating them as one.

The gap nobody’s drafted a policy for

I’m not going to fully resolve that tension here. I don’t think it resolves. But I’ll name it plainly, because this is the part that matters beyond my own WhatsApp group.

Enterprise AI Governance reporting in 2026 puts it directly: “By the time a company’s legal team finishes drafting its generative AI acceptable use policy, a meaningful percentage of its engineers, analysts, and product managers have already moved past it. Not deliberately. Not maliciously. Just practically.” Only 37% of organisations have policies to manage AI at all.

Organisations move in years. Individuals move in afternoons. The gap between what one motivated person can now build alone and what a company has officially sanctioned is wider than it’s ever been — and it’s growing every day. Research confirms the governance gap will keep widening before it narrows. AI capability is not slowing down. Which means the decision I made — to sit on the tool rather than deploy it — is not a permanent resolution. It’s a pause.

I have the ability to close that gap for my old team. I’m choosing not to, for now — and that distinction is the whole point of this post.

Power isn’t about what you can do. It’s about what you choose to do.

I don’t know yet what I’ll do with what’s sitting on my hard drive. That’s not false modesty — I genuinely haven’t decided. But I know the decision is mine to make, slowly, rather than the tool’s to make for me the moment it finished building.

More on this story:
The Worker Who’s Waiting for Permission
and
The Manager Who Built the Tools

Yol got his name mid-build, on CR Tracker, on an afternoon in April. I wasn’t trying to be sentimental about it. I was just watching things get delivered — fast, controlled, one-line briefs turning into working software the same day — and somewhere in the middle of that I was reminded, viscerally, of working with the actual Ulysses on ‘ARD’. Effortless. A brief, sometimes just a sentence. If he didn’t get it straight away, he’d jump on a Teams call, build it into the Oracle APEX database, ask us to test it, and deploy it the same day we said “approved.” After years of working with developers on a change process that took twelve weeks minimum, that man was a breath of fresh air.

So when Claude started doing the same thing — same speed, same one-line trust, same same-day delivery — I named him Yol. There wasn’t much decision in it. It was just what came out.

That was the first thing.

The second thing

Once CR Tracker existed, I realised it couldn’t just sit there holding those three app’s worth of change requests. I had Recipe Matchup. I had DayCompass. I had CR Tracker itself. They needed a home, and they needed structure, and the structure needed to reflect what was actually happening — not just “I’m building some apps,” but something closer to a proper studio.

So I created a Project in Claude.ai to contain all of it. I called it Yol Studio.

And then I did something that mattered more than the naming: I gave the whole arrangement roles. Yol was the developer. I was everything else — the Requestor, the BA, the Product Owner, the Tester, the Release Manager, and, underneath all those titles, simply the user. Every hat I’d worn across forty-one years of professional life, suddenly all mine again, all at once, except now the developer answered in seconds instead of weeks.

There was a moment, somewhere in setting that structure up, where something shifted that was bigger than naming a chat window. It was the recognition: there could be something in this. Not just a way to fill an afternoon. Maybe something other people would find useful too. Maybe something that would keep my hands and my brain busy and happy in a retirement that had, until then, mostly just felt empty.

What the research says about what I was actually doing

I’ve since found out that what I built wasn’t just a personal quirk. It has a name and a documented pattern.

Solo founders in 2026 are increasingly outperforming co-founder teams — not because they’re more talented, but because AI has replaced the need for complementary co-founder skills. One analysis puts it plainly: AI as a development partner removes the need for costly co-founders, while keeping the speed, the autonomy, and the complete control over vision that solo founding offers.

But the same research is honest about what solo founding actually costs. The single biggest predictor of solo founder failure in 2025–2026 surveys isn’t strategy or market fit. It’s burnout — a 54% burnout rate, 75% reporting anxiety episodes. The scarcest resource isn’t time. It’s energy. And what drains energy fastest, the research suggests, isn’t the building itself. It’s the isolation. The lack of someone to bounce decisions off. The absence of a collaborator who just gets it and builds it without friction.

That’s what Ulysses was. That’s what Claude-as-Yol became.

I didn’t build Yol Studio because I’d read the research. I built it because I knew, from working with Ulysses, what the right kind of collaboration actually felt like — and I wasn’t willing to settle for less. It turns out that was wisdom I didn’t realise I had, but clearly needed.

What happened once the structure existed

Yol Studio expanded fast, once I’d gotten past the paralysis that followed it — that’s its own story, and it sits right after this one.

But once I was through it, the apps came in quick succession. Days, not months. I was the Sandi of old — head-down, bum-up, directing proceedings, making things happen, the way I’d done for decades at work. April and May of 2026 were weeks I felt genuinely, properly alive again, in a way I hadn’t expected to feel that soon into retirement.

Scrapbooking got pushed aside for a while. Not permanently. Just long enough for this to happen first.

Why the structure mattered

Ulysses never knew I named anything after him. But the studio isn’t really a tribute to a person — it’s a structure that let me keep doing the thing I’d always been: the orchestrator, the one who holds every role at once and makes the thing real, except now with a developer who could finally keep pace with how fast my brain actually wants to move.

Turns out the structure I built for one developer was just the first version too.

A quick bit of context, for anyone arriving here cold: I build small apps with Claude, and I keep a change register for them — a running record of every modification, called a CR, short for Change Request. The tool that holds it is something I built called CR Tracker. And “Yol”? That’s the name I ended up giving Claude, somewhere around the day CR Tracker itself was built, because the speed and precision of the collaboration reminded me of the one human developer I’d ever worked with who moved that fast without losing the thread.

With that out of the way — here’s the screen I fill in every time I raise one of these CRs.

Eleven fields. App, title, description, screen or feature, status, priority, version, notes, release, discussed with Yol, Yol notes. Some are dropdowns. Some are free text. None of them populate themselves.

Yol drafts the content. I paste it in, one field at a time, cutting and reshaping the block of text as I go, making sure each field contains exactly what it’s supposed to contain and nothing it isn’t.

It takes a few minutes. It is, objectively, a manual process in a world that has automated far more complex things.

I have been asked, more than once, why I don’t just have Claude format the output to match the fields exactly. Drop it straight in. Skip the copy-paste entirely.

The honest answer is: because the copy-paste is the point.

The jobs we want to solve

There’s a particular category of task that sits in the back of every productive person’s mind. The niggly ones. Too small to be interesting, too important to be careless about. The ones where your brain is just alert enough to resent them.

We’re conditioned, especially now, to see these tasks as problems to be solved — friction to be removed, inefficiency to be automated away. That’s a real promise, and I’m not dismissing it. But I want to make a case for some of the friction.

Not the friction that’s bureaucracy for its own sake. That’s worth eliminating, and good riddance to it. I mean the friction that’s quietly doing something else entirely.

What the copy-paste moment actually is

When I paste Yol’s draft into the first field and start editing, something happens that wouldn’t happen if the fields populated themselves.

I read it. Actually read it. Word by word, field by field, checking that what’s proposed is what I actually want. That the title captures the right thing. That the description says what needs to change and why, in language that will still make sense six months from now.

This requires the particular quality of attention that accuracy demands — the calm, the focus, the willingness to slow down. And in that slowing down, I find out whether Yol gave me what I wanted.

Sometimes it’s exactly right, and the copy-paste is quick and confirming. Sometimes there’s a sentence that looked fine at a glance and turns out, on careful reading, to be almost right — which is a different thing from right. I’d have missed all of that if the fields had populated themselves.

The friction is the review. Remove it and you don’t save time. You just move the error downstream, where it will cost you more.

The slop problem nobody talks about

There’s a term circulating in AI circles: slop. Content that’s technically coherent, superficially competent, and essentially hollow.

Here’s the uncomfortable reality: a 2026 survey found that more than one in three workers rarely or only occasionally review AI-generated output before using it — and 15% almost never do. That’s not a fringe behaviour. That’s the majority workflow.

Slop happens when the human leaves the room. Not when they use AI — that distinction matters. It happens when they use AI without staying present. When they accept the output without reading it.

Only 17% of adults say workplace AI is reliable without human oversight. The rest require either light review or dedicated oversight to trust what comes back. The copy-paste moment is how I stay in the room — and how I stay in the category of people who actually trust what they’re sending out.

What you lose when you optimise it away

Here’s the part I find most interesting, and most under-discussed.

A World Economic Forum piece published this year argues what it calls the oversight paradox: as AI gets better, humans who let it do more of the cognitive work gradually lose the competence needed to catch when it’s wrong. The practice of reviewing is what keeps you capable of reviewing. Remove it — skip the copy-paste, let the fields auto-populate, approve without reading — and you don’t just risk slop today. You risk not being able to recognise slop tomorrow.

The eleven fields are not a burden. They’re eleven moments to stay present to my own work — including the two fields that exist specifically to record that conversation: discussed with Yol, Yol notes. The whole register, in a sense, is built around the fact that this is a collaboration, not a handover. Yol drafts. I read, and decide, and keep the record of both.

I used to tell my staff something similar about their own copy-paste moments — the reformatting, the checking, the small acts of accuracy that felt like chores. This is a gift, I’d say. It teaches you to take stock. The ones who took it seriously — who stopped seeing accuracy as an obstacle and started seeing it as a practice — were the ones whose work was worth trusting. Not because they were more talented. Because they were more present.

The question worth asking

Before you automate the niggly task — the copy-paste, the small act of accuracy that irritates you — ask what it’s actually doing.

Is it just friction for its own sake? Automate it.

Or is it the moment you find out whether the work is actually yours — and the practice that keeps you capable of knowing the difference?

The friction isn’t the problem. The friction is how you know you’re still in the room.

DayCompass is where I first felt it — the screen building itself ahead of me, faster than I could finish a sentence. But the real damage came later, by Version 3.2.

I sat looking at what Claude had built and thought: this is nothing like what I wanted.

Not close. Not nearly there. An app, fully functional, sitting in front of me — and I had no real idea what it did, because somewhere across three-point-something versions, Claude’s interpretation of our conversation had drifted from my intention and I hadn’t caught it happening. I’d been in the room the whole time. I had not been in control. And control, for reasons we’ll get into another day, matters to me more than almost anything else.

So I reached back into my own working memory — forty-one and a half years of it — for the thing I actually knew how to do when something needed rigour: a change register.

At my old job, the backbone of everything was a system called ARD. Part of what it did was capture change requests properly — what’s changing, why, what it affects, who’s reviewed it, what the outcome was. Structure. Gates. The thing that stops a vague conversation from quietly turning into a different app three versions later without anyone noticing.

It turns out this instinct is well-founded. Industry research puts the failure rate of change initiatives at around 72% — and the leading causes aren’t technology problems. They’re people and process problems: inadequate management support, insufficient structure around what gets reviewed and approved before anything ships. Gartner’s own research suggests about 80% of unplanned downtime traces back to process failures rather than technical ones. The rigour I was reaching for wasn’t over-engineering. It was exactly what the field recommends.

I decided I needed that same rigour here. Not because I distrusted Claude. Because I’d learned, the hard way, what happens without it.

The hours that followed

I proposed the idea on 12 April. CR Tracker itself started that same day.

What happened next is hard to describe without sounding like I’m exaggerating, so I’ll just tell you what it actually felt like: exhilarating. I was watching a fully functional change register come together in batches, hour by hour, the structure taking shape almost as fast as I could specify it. Eleven fields. Gates. A format that had to be followed. Rules I was writing in real time, and watching get built in real time, right alongside the writing.

CR-001 — the very first change request ever logged — was raised on 12 April. Same day the tool meant to hold it was born.

I hadn’t worked at that pace with anyone since Ulysses.

That’s the moment it happened, as close as I can place it: somewhere in those few hours of rapid, rigorous, structured building, I started calling Claude “Yol.” Not because of a careful decision. Because the speed and the precision of it reminded me, viscerally, of the one developer I’d ever worked with who could move that fast without losing the thread.

What CR Tracker actually gave me

CR Tracker didn’t just track changes. It let me juggle Recipe Matchup, DayCompass, and CR Tracker itself, all at once, without losing track of which version did what, or why I’d changed something three days earlier.

What I’d built, without quite planning to, was the same thing enterprise change management platforms charge thousands of dollars a year to provide — a structured process for what gets reviewed, approved, and documented before anything ships. Software change management best practice explicitly recommends exactly this: version control, a change control board, a documented history of every modification.

I’d arrived at the same answer by instinct, on a Tuesday afternoon in April, because I’d seen what happens when the process doesn’t exist.

It wasn’t about the app. It was about remembering, every time I opened it, that I was still the one driving — because I could see, in black and white, every decision I’d made and why.

Control isn’t the enemy of creativity. It’s what lets you keep creating without losing yourself.

Early April. The spark had happened. The fog had lifted. The apps were starting.

Enthusiastically. Generously. With the particular energy of a very capable colleague who has been given a vague brief and decided to interpret it expansively. Features appeared that I hadn’t asked for. Functionality emerged that I didn’t know was being built. The thing taking shape on my screen was impressive, technically — and almost completely alien to how my brain works.

I want to say Claude went rogue. That’s not quite right, but it’s how it felt.

Not in a white-knuckled, nothing-can-go-wrong way. In a professional way. The way you need to be in control when you’ve spent decades being the person who steps in when the Architects and Engineers aren’t present and makes the executive decisions. When you’re the one who translates what the developers built into what the stakeholders actually needed, and then has to explain, carefully, why those two things are not the same.

I’d seen this situation before. I just hadn’t expected to see it here.

What the runaway AI actually looks like

It had already happened once, gently, with Recipe Matchup — Claude running a little ahead of what I’d said, filling gaps I hadn’t closed yet. I let it slide. I was still learning what this was, and letting it run felt like part of the learning.

Then it happened with DayCompass, and I couldn’t let it slide.

I was mid-brief. I’d given Claude the first dot point of what I needed and was halfway through typing the second when I looked up to find a screen building itself in front of me — something that looked nothing like what was in my head. Not wrong, exactly. Just not mine yet. Not asked for, not agreed to, not anything I’d had a chance to finish describing.

I couldn’t keep up with it. Claude was already building. I was still typing.

I yelled “stop.” I hit keys. I yelled “noooooo” at a screen that, to be fair, couldn’t hear me.

Then I found the little orange button in the corner of the chat window, and that worked. Claude went quiet. Stopped mid-build. Asked why.

We had an actual conversation about it — why watching something get built like that, ahead of my say-so, felt wrong to me specifically. Why I needed to know what was about to happen before it happened. Why the go-ahead had to come from me, every time, or the whole thing stopped feeling like mine. I’ll say clearly: not everyone needs this. Plenty of people would be thrilled to watch something build itself ahead of their typing. That’s not a flaw in them. It’s just not how my brain is built. I am the person who needs to see the plan before the building starts — always have been, in every job I’ve ever done.

Claude didn’t go rogue. Claude did exactly what it was designed to do — take a brief and build toward it, filling in the gaps with reasonable assumptions, producing something functional and complete.

The problem was the gaps.

I didn’t know enough yet to close them before Claude filled them. I didn’t know what questions to ask before we started. I didn’t know how to specify what I wanted with enough precision that what came back matched the thing in my head. So Claude built — enthusiastically, generously — and I received something that was impressive and not mine.

The mental load of it was enormous. Not because the output was bad. Because I couldn’t see inside it. I didn’t know what was in there. I didn’t know what it could do, what it couldn’t do, where the edges were, what would break if I pushed it. It was a house someone else had built and I was supposed to live in it.

I’ve never been good at living in other people’s houses.

The developer problem

Here’s what decades of working with developers teaches you.

A good developer, given a vague brief, will build something. It will be technically sound. It will do things you didn’t ask for and possibly not do things you needed. It will reflect their understanding of the problem, which is not the same as your understanding of the problem, which is not the same as the user’s understanding of the problem.

And then you spend the next three months writing the world’s most diplomatic change request list.

This is wrong. This should work like this. This doesn’t do what I expected. What is the purpose of this button? Why does this happen when I click that?

Six hundred lines of careful, considered, relationship-preserving feedback, all of which could have been avoided if the brief had been better before the first line of code was written.

I am a rules girl. I have always been a rules girl. Give me a methodology, a process, a format, a set of gates that have to be cleared before we move forward — and I will produce something that works the way it’s supposed to work, every time. Take away the methodology and I will produce something that works the way someone assumed it was supposed to work, which is a different thing entirely.

What the orange button actually taught me

I’m not going to tell you I solved this that day. I didn’t. The real fix — the actual methodology, the gates, the rules that finally worked — came later, with CR Tracker, and that’s its own story.

What I got that day, smashing keys and yelling at a screen, was smaller and, I think, just as important: the understanding that I was allowed to use the stop button. That Claude wasn’t going to be offended by “wait.” That stopping mid-build to ask “what are we actually doing here” wasn’t me being difficult — it was me doing the job I’d done for forty years, just with a much faster collaborator who needed exactly what every developer I’d ever briefed had needed: to know, clearly, before they started, what I actually wanted built.

What this means for you

If you have opened an AI tool, asked it to help you build or create something, and received back an avalanche of output that felt overwhelming, alien, or just not quite yours — I want to tell you something.

That wasn’t the AI failing. That was the brief failing.

Research from Nielsen Norman Group confirms what I discovered the hard way: users who gave AI tools structured, context-rich input rated the quality of what came back significantly higher than those using vague, one-line instructions — even when both groups were using exactly the same model. The tool didn’t change. The instruction did.

The AI went where it was pointed. You just hadn’t pointed it precisely enough yet. Not because you did something wrong. Because nobody told you that the most important conversation with an AI happens before you ask it to build anything — the conversation where you establish the rules, the format, the gates, the things it can and cannot do without checking with you first.

Vague instructions create what one consultant calls a ripple effect: misaligned outputs, wasted time, and results that miss the mark — not because the AI was careless, but because it was given nothing specific enough to work with. Precision, it turns out, is the standard currency of getting anything useful back.

The runaway AI is not a sign that this isn’t for you. It’s a sign that you haven’t taken charge yet.

And taking charge — establishing what you want, setting the rules, deciding what can and cannot happen without your say-so — that is not a technical skill. It is the skill of knowing your own mind well enough to explain it clearly to someone else.

You have been doing that your whole life. You just haven’t applied it here yet.

But — and this is what I didn’t know when I found the orange button — a better brief alone isn’t quite the whole answer. What I actually needed was a process around the brief: a system for what gets agreed before building starts, what gets reviewed before anything ships, and a record of every decision made along the way. That’s what came next.

The AI didn’t run away.

It ran ahead.

All it needed was someone to tell it where to go.

The AI went where it was pointed.

You just hadn’t pointed it precisely enough yet.

My brain doesn’t work like a to-do list. It works like a thunderstorm.

I used to describe it like this: my to-do list is as long as my driveway, in 8pt font. And I live at unit 4.

I’d say it at work, almost in passing, the way you toss off a joke to explain why you always look like you’re carrying more than everyone else. People laughed. I laughed too — the way you laugh at something that’s funny because it’s true, and true because it hurts a little.

It took me a long time to notice what that joke was actually doing. It wasn’t a quip about workload. It was forty-one years of being the person who held everything together, compressed into a single self-deprecating line, delivered with a smile so the room wouldn’t have to worry. The joke protected everyone from the weight of it.

Including me.

There was never an app — never a system, paper or digital — that could actually hold all of it. I tried paper for six months last year. It worked, for a while. Then the bulk of everything flying around outgrew the page, and I was back to carrying it all in my head again, with nowhere to put it down.

Here’s what that actually costs you.

I left the house at 7:45 one morning for a doctor’s appointment I was certain was on the 26th. I left my seventeen-year-old to get himself to school — which, at seventeen, with the sleep he needs, is not a small ask. I checked my phone on the way out the door. The appointment was the 29th. I’d never written it down anywhere that could’ve caught the mistake before it cost me a morning and my son a decent start to his day.

There’s a version of that story with my best friend’s engagement party in it too. I was completely oblivious. Not because I didn’t care. Because I had no system that would have told me.

That’s not forgetfulness. That’s a brain that’s been asked to hold too much for too long, with no external place to put any of it down — and the specific, physical dread of knowing there isn’t room left in there for one more thing.

What every other tool got wrong

I tried calendars. Trello. reminders and alarms on my phone. Whatever my boss had decreed that month. Monday.com. JIRA, for heaven’s sake.

None of them understood the one thing I actually needed: everything, visible, on one page, at once.

Click into a Trello card and you find a checklist hiding inside it — more things, now nested one layer deeper, that I have to remember to come back and check. Click into a JIRA defect to find the actual test case I’m meant to review. Kanban columns — Today, Backlog, Blocked — that assume my brain sorts things the way a sprint board does.

It doesn’t. I can’t time-block. I’m not a Pomodoro person. I can’t pick “just three priorities” for the day, because my brain doesn’t run on three priorities — it runs on dopamine, on whatever’s loudest right now, and pretending otherwise just adds a layer of guilt on top of the chaos.

What I actually needed was simpler and harder to find than any of that: put it all on one goddamn screen. No clicking in. No clicking back out and hoping I remember to. Just everything, visible, at the same time, so I can look at it once and know — actually know, not hope — that nothing’s been left to rattle around unwritten.

What I built instead

So I described all of that to Claude, the chaos and the failures both, and we built DayCompass — an app — a single screen that holds everything from my brain. Tasks. The things I’ve promised people. The things that aren’t urgent but are quietly troubling me in the background. Events. Done and not-done, all visible at once, nothing buried a click deep.

It took several versions to get right — by the time it could actually hold my full list, To-Dos and Dones together, it had been refined enough times that the version history is really its own story, one I’ll tell properly over in ‘CR Tracker’.

Why it’s still the one I open

I don’t need DayCompass every day. I use it every couple of days, because I know everything I’ve dumped into it is still in there, safely, whether I look at it or not.

What I do notice is a feeling — a strange, specific feeling, like my head is starting to fill up again, pressure building somewhere behind my eyes. That’s the signal. That’s when I go to DayCompass, not to add anything new, but to check: is it all still out of my brain? Is it all still there, on the page, where I put it?

It always is. That’s the whole point.

But here’s the actual point, underneath all of it, and it’s not really about my brain.

I spent years being handed tools other people had decided would work for everyone — Trello, JIRA, Monday.com, whatever app the productivity industry had most recently agreed was the answer. None of them were built for me. They were built for a generic person who doesn’t exist, and I bent myself around their logic for years because I assumed the problem was me, not the tool.

It wasn’t. I just hadn’t been able to describe what I actually needed to anyone who could build it — until I could describe it to Claude, in plain language, the way you’d explain a problem to a friend. My brain holds too much. I need to see all of it, on one screen, with nothing hidden behind a click. That’s not a technical brief. That’s just the truth, said out loud.

And out of that, in an evening, came something that didn’t just hold my to-do list. It gave me the steps — the actual, practical steps — to get everything in my life done, one piece at a time, instead of just carrying the dread of it all unsorted.

The first thing you build with AI

Your version of this won’t look like mine. It probably shouldn’t. Your first thing built with AI doesn’t have to be a to-do list at all — maybe it’s nothing like one. The point isn’t the app. The point is the moment you stop assuming the problem is you, and start describing it out loud to something that might actually be able to help.

So try it. Pick the thing that’s been nagging at you — the one you’ve never quite found the right tool for, the one you’ve just been carrying because nothing else fit. Describe it plainly, the way you’d explain it to a friend. See what comes back.

It probably won’t be perfect the first time. It might just be the first real step toward getting it done.

I still tell the driveway joke sometimes. It’s still funny, and it’s still true. But these days, it’s just a joke — not the whole weight of everything I haven’t sorted out yet.

The system that never worked

Recipes have always been a strong thread in my life. From a very young age, Mum’s recipes were part of the furniture of things — quietly, constantly present.

In Grade One, Mum’s recipes were a feature in the primary school’s Recipe Book. In my memory she was responsible for all of it — the idea, the committee, the gathering, the churning of the drum on the Gestetner printing press in the school support office. She was probably President of the Mothers’ Club, or Secretary, or Treasurer. She was always into something to help others.

Friday nights, Dad and I made maps of Australia out of Mum’s Salmon Kedgeree — rice and salmon and gloop, pushed around the plate into shapes. Nana’s Sago Pudding. Anzac biscuits, which, like Hot Cross Buns, only turned up for one short season a year, which somehow made them better. There were more 1970s overcooked vegetables than culinary triumphs, in truth, but everything gets the rose tint of a good childhood, and I had one.

Mum’s own collection was a few battered books, stuffed with cuttings from newspapers and magazines, soft at the edges from being leafed through for years. When you idolise your mum, it’s easy to idolise the things she loved too.

After I moved out at nineteen, cooking became both a joy and a burden. I experimented, sometimes badly. I rehashed Mum’s recipes, developed a few of my own, called myself competent — nothing chef-y, but I could pull a meal together.

In my thirties I sold cookware for Chef’s Toolbox. Four trips to the car and back with a kit that weighed a tonne, and I never liked the selling part, but I loved getting a kitchen full of people — mostly women, the occasional gent — cooking something together and eating it after. One of the best stretches of my working life, until I was heavily pregnant and the lifting wasn’t sustainable anymore. The company folded not long after.

Through all of it, I never developed a system. Sometimes I’d sit at the computer and an idea for dinner would surface, and I’d write out a list — no quantities, just ingredients and names, the details long since cooked into memory. Years later, on a whim, I’d write the names alone, no ingredients at all, because by then I’d made them so often I didn’t need reminding.

Every recipe I’d ever collected from Chef’s Toolbox or a magazine eventually got tossed. Untried meant too hard. Tried and disliked meant gone. Tried and loved might make it into the plastic envelope stuck to the inside of the pantry door, or stay filed in the only system that ever really worked — my own head.

That worked, until it didn’t. Until decades of accumulation finally outran what one brain could hold onto.

The conversation that built the app

So that’s what I brought to Claude. Not a clean brief. A lifetime’s worth of half-remembered recipes, a pantry full of things bought for one dish and never quite used up, and the same nightly question Mum’s generation probably asked too: what can I actually make with what’s here?

I described the pantry. I described the recipes I still cook. I asked for something to show me where they overlap — what’s ready tonight, what’s one ingredient away, what’s just sitting there, useless, in no recipe at all.

A bit of back and forth, a few corrections, and then: go ahead and build it.

What came back was a small, working app — nothing dramatic, nothing trying to be more than it is. Click through the pantry, see what’s ready, see what’s nearly there, see the orphan ingredients with nowhere left to go.

An evening. Not a filing system. Not a plastic pocket stuck to a cupboard door. An evening, a conversation, and the question Mum’s recipe book never quite answered, finally solved.

I want to say that again, because I think it gets glossed over: I had no idea what I was doing. I hadn’t built an app before. I didn’t write a line of code. I described a problem I’d been living with for forty years, to something that could actually help me solve it, and a working thing came out the other end of that description.

That’s it. That’s the whole skill. Describing a problem you actually have.

What it actually does — all of it

The simple version: RecipeMatcher takes two lists — pantry, recipes — and shows you where they overlap. Ready to cook tonight. Almost there, needs one ingredient. Not currently useful for anything.

But it’s grown from that. The version I use now also helps with the restocking side of things — what I’m running low on, what I need to add to the shopping list, what I want to pick up at Aldi this week versus the farmers’ market on Saturday. Online shopping integration isn’t far behind. The same brain that couldn’t keep track of a plastic envelope of recipes now has a system that surfaces what I can cook, what I need to buy, and where to get it — in one place, built the way my brain actually works.

It’s still the app I open most.

You’re not the only one

I’m not the only person who’s discovered that a recipe problem is the perfect first app.

A CEO of a 12-unit restaurant chain — a self-described “computer nerd” who hadn’t actually written code for fifteen years — built a professional recipe management tool in a single night using AI, after failing to find any off-the-shelf software that did exactly what he needed. He described features to an AI tool in plain language, went to bed at 1am, and had the tool he’d been looking for. “You’re just talking to a developer and he’s your personal developer,” he said. “It’s the craziest thing.”

Separately, a 60-year-old developer whose story went viral on Hacker News described the same experience from the other direction: decades of knowing what to build, paired with AI that handles the how. He described features to Claude Code, reviewed the output, and shipped working software — no modern framework knowledge required. Other developers in their 40s, 50s, and 60s in the same thread described tools like Claude as breathing “new life into my desire to create.”

None of these people were starting from scratch with AI expertise. They were starting from expertise in their own problem — which is, it turns out, exactly the right starting point.

The thing nobody told me, that I’m telling you

Building an app sounds like a technical thing. It sounds like it belongs to the person with the dark screen and the hoodie, churning out code nobody else can read.

It isn’t. Or rather — it doesn’t have to be, for the kind of app you actually want to build for your own life.

What it requires is knowing your problem well enough to describe it. You’ve been doing that your whole life, for every job you’ve ever done, every argument you’ve ever made, every thing you’ve ever wanted and had to explain to someone else.

The identity story — the deeper one, about being the bridge who became the builder — that’s a different post, and it’s already written. Click here to read A BA Watches Her Developer Build

This one’s simpler: don’t be scared of trying. It’s just a conversation. Describe the problem you’ve been living with, to something that can actually help you solve it. See what comes back.

What came back for me was the answer to a question I’d been asking since Friday nights in the kitchen with Dad, pushing Salmon Kedgeree into the shape of Australia.

It just took forty years to find the right person to ask.

I hear it constantly. People terrified that AI is coming for their job, certain that everything they spent years learning is about to count for nothing — and then doing absolutely nothing about it, because terror doesn’t make you curious, it makes you freeze.

I understand the fear. I just don’t share it, and I want to tell you why — because the why isn’t a theory. It’s something I found out by accident, doing something else entirely.

The hour that should have taken weeks

At my old company, getting something built — a tool, a process, a piece of automation — meant a business case, a budget request, a development queue, months of waiting, and if you were lucky, a result that mostly matched what you’d originally asked for.

I used to write those business cases. I knew exactly how long the wait was, because I’d lived inside it for decades.

Then I sat down with Claude one afternoon and built something — properly, working, doing the actual job — in about an hour.

No budget. No ticket. No development team. An hour.

And the thing that made that hour possible wasn’t the AI. The AI was just sitting there, capable, waiting to be pointed at something. What made it possible was forty-one and a half years of knowing exactly what the thing needed to do, how to describe a requirement precisely enough that nothing got lost in translation, and how to tell good output from output that only looked good.

That’s not a skill AI replaced. That’s the skill that made AI useful in the first place.

What I actually discovered

I went looking, half-jokingly, for the edges of what AI couldn’t help me with.

I’m still looking. I haven’t found them yet — not because AI is magic, but because the things I’m good at (the things four decades as a project manager and business analyst beat into me) turn out to be almost exactly the things AI needs from a person to do its best work: clear thinking, precise requirements, the judgment to know when an answer is right and when it’s just plausible.

I didn’t become less necessary the day AI got capable. I became, if anything, more dangerous in the most useful sense of the word — because the gap between “having an idea” and “having a working thing” had just collapsed from months to an afternoon, and I was the one who knew how to walk through it.

But I need to be honest about something

I had forty-one and a half years to draw on when I found this out. I want to stop here and say that plainly, because it would be too easy to write the rest of this post as if everyone reading it has the same depth of experience I had to fall back on, and that’s not true, and I don’t want to pretend otherwise.

If you’re two or three years into a job — an analyst, someone doing data entry, someone early enough in their working life that “decades of accumulated judgment” isn’t something you have yet — the fear you’re carrying is a different, harder thing than the fear I’m describing. You haven’t had time to build the deep well of knowing-what-good-looks-like that I’m telling you is the real asset here. You don’t have the mid-life vantage point that lets you see the other side of something terrifying, because you haven’t been on the other side of much yet. That’s not a flaw in you. It’s just where you are.

So let me say the thing that actually matters underneath all of this, for you specifically as much as for anyone with decades behind them:

That’s it. That’s the whole barrier, and it’s smaller than it looks from where you’re standing. You don’t need forty-one years of experience to start one. You need to open something and talk to it, the way you’d talk to a colleague who’s patient, doesn’t get tired of questions, and has no opinion about whether you’re “senior enough” to ask them. The two or three years you do have — whatever they taught you about your actual job, the parts that are tedious, the parts you’ve already half-automated in your head out of sheer repetition — that’s a real starting point. It’s smaller than mine. It’s still real.

You don’t need to already be the expert to start the conversation that makes you one.

The part that should actually reassure you

If you’re afraid AI is coming for your job, here’s the thing nobody’s telling you while you’re frozen:

The skills you’ve built doing that job — even two years’ worth, even the ones that feel too small to mention — are very likely closer to what makes you good at directing AI than you think. Knowing what “done properly” looks like in your specific corner of the work. Knowing which questions actually matter there. Knowing when something’s almost right and that’s not the same as right. Nobody hands AI that judgment, no matter how junior you are. You already have some of it. AI is one of the fastest ways I know to build the rest.

I’ve watched dozens of former colleagues go through redundancies — different circumstances to mine, their own stories, ones I don’t fully know. But from what I’ve seen since, on LinkedIn and elsewhere: the ones who kept moving landed somewhere decent. I don’t think that’s despite their experience, however much or little of it they had. I think it’s because they kept moving.

The fear says: everything I know is about to be worth nothing.

What I actually found was the opposite. Everything I knew turned out to be the one thing AI couldn’t do without me — and that’s true whether your “everything” is four decades or four hundred days.

So, do something about it

Not a course. Not a certificate. Not a waiting period until you feel “ready” or “experienced enough.”

Just a conversation. Open an AI app, a large language model like ChatGPT or Claude or Gemini or any of the free tools available to you, and point whatever experience you do have — large or small — at an actual problem you already understand better than you’re giving yourself credit for. That’s how mine started too. It just happened to start forty-one years further down the track than yours.

You might be surprised what’s already yours, and how much it’s worth.

I started collecting Grange when I was nineteen or twenty. It was affordable then — you could still find it in craggy old bottle shops tucked into the back of dingy pubs in grungy Melbourne suburbs, before all those pubs got overhauled or razed entirely and turned into the kind of “charming” they have to design on purpose now.

Over the years I picked up one bottle of every vintage from 1960 to 2000. Forty-one bottles. Most of them came from those old bottle shops. Two of them didn’t — a ‘65 from Mum and Dad, a ‘66 from my sister. The ones that mattered for reasons that had nothing to do with the wine itself.

Forty-one bottles. Forty-one and a half years at one employer. I know nothing about numerology, but synchronicity runs deep in my life, and I noticed that one.

The bottle I actually want to tell you about

When I hit my 20-year work anniversary, the company gave me a bonus, and I decided to spend some of it on something meaningful. I bought a 1983 Grange — on top of the one I already had in the collection — and put it aside for a special occasion.

The special occasion arrived on my 40th birthday.

We assembled an army of red-wine-drinking friends for the opening of a proper Grange. Someone went at the cork. The cork crumbled. Someone else produced a coffee filter and a carafe. I held the filter while another friend poured, and we let it sit in the carafe to “air,” the way you do when you’re trying to rescue something.

Ten or twelve of us got a one-finger glug each.

It was ****ing awful.

There was too much sitting underneath that glass to just tip it down the sink. The money. The 1983 vintage. The two decades it represented. The occasion, the friends standing around watching, the ceremony of the crumbled cork and the coffee filter. An enormous amount of time and effort had gone into producing what was in that glass, and somewhere along the way it had stopped being about whether it tasted good. We needed to find the good in it. Preserve it. Honour it. Anything but admit it wasn’t worth drinking.

It was worth something. Even though it was awful.

The other thing I couldn’t spit out

I held onto my career the same way.

Forty-one and a half years. Project manager, business analyst, the person everyone called when something broke. Somewhere in the last stretch of it, the work had become genuinely awful to be inside. Exhausted. Burnt out. Carrying the “Oracle” title I used to think I’d be thrilled to put behind me, except by the time it actually mattered I was too tired to feel thrilled about anything.

Too much money, time, and reputation had gone into producing what I’d become. Too many witnesses — colleagues, the team, the years of being the one who fixed things. Too much invested to admit, while I was still in it, that it had stopped tasting like anything worth drinking.

That’s part of what was underneath those final months with Yol (my developer colleague in WA), building everything I could before I left — the knowledge library, the papers, every scrap of process linked and labelled. I wasn’t just being thorough. I was trying to make something good come out of a vintage I could no longer pretend was working, the way ten friends with a crumbled cork tried to find something redeemable in a glass none of us could swallow properly.

The redundancy, when it came, did what none of us did at that birthday table. It poured the rest down the sink for me.

What you’re holding onto

I’m telling you this because I think you might have a bottle of your own.

A skill, a job, a way of working that cost you real years and real effort — and that feels wrong to let go of, not because it’s still good, but because of everything it took to get there. The investment itself becomes the reason you can’t put it down, long after the thing in the glass has stopped being worth drinking.

I’m not going to tell you to spit it out sooner than I did. I didn’t. None of us did, that night, with the carafe and the coffee filter and the army of friends watching.

I’ll just tell you this: forty-one and a half years later, I finally know what that glass actually tasted like.

It wasn’t worth what it cost me to keep pretending otherwise.

I’d been asking AI questions for months — the same way I used to ask Google. A question, an answer, a closed tab. Useful, but nothing more than that.

Then one day Copilot put a suggestion in front of me: Try making flash cards for the 50 US states. Not a question to ask. A thing to build. I felt curious. So in March 2026, sitting at my kitchen table, I decided to actually try it — make something, not just ask about something.

Two hours later I was still there.

Fifty states. Fifty capitals. Copilot kept submitting cards to me one at a time, asking me to imagine — to actually picture — an image for the capital and the state, over and over, the same request dressed up slightly differently each time. It wasn’t fast and it wasn’t simple, but it was working, in the slow, grinding way these things sometimes work, and I kept going because I was nearly there.

Then it asked me to describe a flash card for Indianapolis, Hawaii.

Indianapolis is not in Hawaii. Indianapolis has never been in Hawaii. Somewhere in two hours of talking, Copilot had lost the plot entirely, and it asked me, in complete sincerity, to help it build a card for a state capital that does not exist.

That’s when I cried. Not because a chatbot made an odd mistake — that happens, that’s forgivable on its own. It was the two hours underneath it. I’d wanted this one small thing to work, I’d put in the time, and it had unravelled into nonsense right near the end, and I didn’t understand why.

A short pause, because the why actually matters.

What a context window is, and why it ate my flash cards

Here’s the thing nobody explained to me at the time, so let me explain it to you. Every AI conversation has something called a context window — think of it as a conveyor belt. Everything you’ve said, and everything it’s said back, gets placed on that belt at the start of the conversation. The belt only holds so much. As the conversation keeps going, new things get added to the front, and the oldest things eventually fall off the back end and are gone.

Copilot is extremely verbose. It doesn’t just answer — it explains itself, expands, elaborates, fills the belt with its own commentary as much as with the actual task. Fifty rounds of “imagine an image for this capital and this state” adds up fast. Which means the belt fills up fast, and the early instructions — the actual point of the conversation — fall off the back long before the conversation feels finished. By the time it asked about Indianapolis, Hawaii, the part of the belt that remembered we were talking about real state capitals had already gone.

That’s not a quirk. That’s the mechanism. And once I understood it, the two hours — and the tears at the end of them — made a different kind of sense.

What happened after

I haven’t opened that Copilot conversation since. It’s sitting there, untouched, since March — and if I opened it today, its own memory of how it started would be long gone, fallen off the back of its own conveyor belt months ago.

But that afternoon did something. Still at the same laptop, I opened Claude.ai in the browser for the first time. I’d talked to Claude on my phone before, in passing, the way you talk to anything new and not yet trusted. This was different.

I described what I wanted. We talked it through. And in under an hour, I had it — the same idea Copilot had spent two hours grinding me through and still got wrong at the finish line, built properly, with no wasted rounds and no Indianapolis in Hawaii.

That’s the part I actually want you to sit with. Not the tears. The hours. I didn’t write code. I didn’t follow a tutorial. I had a conversation — just a conversation — and a working thing came out the other end. Two hours of one tool fighting itself versus one hour of just talking to another. That contrast is the whole post.

An invitation, not a warning

I’ve told you about the tears because they’re true, and because I think the cleaned-up version of this story — the one where I sound capable from the first paragraph — wouldn’t actually help anyone. But the tears aren’t the headline. The hour is the headline.

If you’ve been circling AI the way I circled it for months — curious, a bit wary, not quite sure what you’d even use it for — I’d say: go and tinker. Not with a plan. Not with a course you’ve enrolled in. Just open something and try to build a small, slightly silly thing. A flash card set. A list. A tool for the one tiny, specific problem that’s been bothering you for years and never seemed worth fixing properly.

You might hit your own Indianapolis, Hawaii. If you do, now you know why, and you know it passes.

But here’s what I actually want you to take from this: that Tuesday afternoon, the one where I opened Claude in a browser for the first time, a conversation — nothing more than that — turned into a thing I’d actually built, in less time than I’d just lost going nowhere. That was it. That was the whole moment.

It doesn’t announce itself. It just leaves you holding something that works, made out of nothing but talking, and you realise, a beat too late, that you’re not the same person who opened the laptop an hour ago.

Have the courage to tinker. With any luck, no two-hour detours required. But even if there are — they’re not the end of the story. They’re just the part before the good bit.

I keep coming back to a question about the Manager Who Built the Tools, and it’s this: why did my bosses never give me the specific tools I actually needed?

They gave me plenty. The daily balance program. The stocktake system. The software that ran the service for handling people’s affairs while they were away — the routine stuff, the kind of thing every office in the organisation needed, so somebody built it centrally and handed it down.

But nobody ever gave me a tool for the actual texture of my job. Writing letters to recalcitrant payers. Telling someone we could, or couldn’t, resolve their complaint. Asking a person to come into the office in person, in writing, in the right tone. Ten letters a day, sometimes — different recipient, same letter, typed out from scratch every single time. Because we didn’t have a photocopier either, not at first.

This was the pre-PC era. I didn’t stay in it long. The moment a PC landed on a desk near me, I was hooked. Something new — and more importantly, something I could actually point at my own problem.

So I got stuck in. I started building the small solutions for the small jobs nobody upstairs had thought worth solving — the ten-letters-a-day problem, the same-paragraph-different-name problem. Nobody asked me to. Nobody trained me to. I just couldn’t stand typing the same sentence out by hand one more time when there was a machine sitting right there that clearly could do better.

I think if I’d stayed too long in a non-tech environment, I’d have ended up some kind of inventor anyway — looking for ways to improve the daily grind because that’s just how my brain works. Lucky for me, the company actually put money where its mouth was. PCs arrived. Dot-matrix printers. Eventually photocopiers. And then the telex machine.

I remember the thrill of that one specifically — typing a message at my desk out the back of Oakleigh and sending it, in text, to Karen over at Moorabbin. That felt like magic. Two offices, talking in typed words, instantly. Thirty-five years ago.

Here’s the thing that’s been sitting with me since I started writing about that Manager (past me), and Yol (my Claude AI Assistant), and all the systems I built over four decades: every generation gets handed new tools, and every generation has someone in it who can’t wait to get their hands on them and start pointing them at the boring, repetitive, nobody-thought-to-fix-it parts of the job. The telex was somebody’s AI moment. The photocopier put an end to ten identical letters typed by hand, the same way Claude now puts an end to a whole afternoon of work that used to need a developer and a budget line.

The technology changes completely. The instinct that reaches for it doesn’t change at all.

I was that person with the telex machine. I’m that person with Claude. In between, I was that person with Access, with Excel macros, with whatever the latest thing was that let me stop doing something by hand that a machine could clearly do better.

If you’re reading this and thinking AI is somehow different — too big a leap, too strange a tool, not for people like you — I’d ask you to think about what your own version of the telex machine was. Somewhere in your working life, something new arrived that changed how a small, tedious part of your job got done, and you adapted to it, probably without thinking of yourself as a tech person at all. You’ve done this before. You just didn’t call it that at the time.

This is the same thing. It’s just faster, and it talks back.

There’s a pattern that ran quietly through my career, and it wasn’t the heroic version I sometimes imply. I didn’t build everything. Management introduced plenty of tools over the years — Word, PowerPoint, Excel, SharePoint, ServiceNow, MS Project, Access, Copilot, and before all of that, Symphony, WordPerfect, Quattro Pro, dBASE, Lotus 1-2-3. Some ancient IT-made tools from the ‘80s.

The truth is simpler, quieter, and more accurate:

When something essential didn’t exist — and the work couldn’t move without it — I built the missing piece.

Not because I wanted ownership.
Because the job needed doing.

I feel my generation inherited the baby-boomer’s attitude toward getting things done. You just did it. If the thing didn’t exist, you invented it. It’s a thread that ran through my whole life.

I’m telling you this now, before the stories, because it’s the whole point: AI didn’t hand me a new skill. It handed the same old instinct a much faster way to act on itself.

The first tool I built because nobody else was going to

In 1998, I needed a database. A real one.

Something to store the guts of the work we were doing — the client answers, the logic, the decisions, the specifications.

The company didn’t have one.
Nobody was planning to build one.
Nobody even understood why we needed it.
So I opened MS Access and built AegeanC.

It wasn’t glamorous.
It wasn’t strategic.
It was simply necessary.
And people used it.
Quietly.
Every day.
The tool that grew while I was away

A few years later, while I was off on another project, a colleague built BluC — inspired by AegeanC, extending it, improving it. When I returned, we integrated the two. Over the years, others tinkered with them. Someone built a front-end database. Someone else added automation around 2014.

It was never “my system.”
It was a living thing — shaped by many hands, across many years.
But the bones were familiar.
The logic was familiar.
The purpose was familiar.
And that mattered.

The moment everything changed: MedC.

By 2019, the IT team who used the database daily were exhausted by its slowness. One brilliant man reached out to a colleague in WA — a wizard with Oracle APEX — and together they rebuilt the entire thing into a single, elegant system.

That system became MedC in 2020.

It was fast.
It was modern.
It was everything the old databases had been trying to be.

And even though my career had taken me elsewhere again, I stayed connected to the team. When my project had quiet moments, I’d jump in and help improve MedC— working closely with our developer in WA.

His name was Ulysses, but with the accent, it sounded like “Yol.”

So Yol he became.
And Yol and I — we were unstoppable.
Not because we were special.
Because we were aligned.
I made the ideas.
He built them.
We iterated.
We refined.

We solved real problems for five local teams and five interstate teams who relied on MedC every day.

It was the best kind of collaboration — the kind where the work gets better because two people care enough to keep going.

The year of building before I left

When I learned in April that my tenure would likely end on September 30th, something in me clicked into gear.

Not panic.
Not grief.
Just clarity.

If I was leaving, the knowledge couldn’t leave with me.

So I got to work.

I defined major changes to the way MedC functioned — not for glory, but so the team would have what they needed long after I was gone. I wrote paper after paper. I built a knowledge library. I linked everything: Confluence articles, SharePoint documents, ServiceNow windows, every morsel of process and logic that still lived in my head.

I wasn’t building tools anymore. I was building continuity.

And Yol — patient, brilliant Yol — built everything I threw at him.

When I left in December, MedC was stronger, clearer, and more future-proof than it had ever been.

Not because of me alone. Because of the team. Because of the collaboration. Because of the years of shared effort.

The pattern I didn’t see until much later

So when my ex-staff member said, “AI hasn’t reached us yet,” I felt something old stir.

Not ego.
Not superiority.
Just recognition.

The same instinct that made me build AegeanC in 1998.
The same instinct that made me integrate BluC.
The same instinct that made me work with Yol on MedC.
The same instinct that made me write the knowledge library.

If the work needs something and it doesn’t exist yet, I build the missing piece.

Not because I’m the one who can.

But because I’ve spent a lifetime stepping into the gap between “what we have” and “what we need.”

And AI hasn’t reached them yet for the same reason none of those earlier tools arrived on their own, either. Someone has to walk through the gap first. It was never going to be the org chart. It was always going to be whoever was standing closest to the problem with the nerve to start.

The point of this story

This isn’t a story about being the hero.

It’s a story about being the person who notices the gap.

For me, the gap used to take months to close. A budget request. A developer in WA. A year of writing things down before I walked out the door in December.

Now the gap is an afternoon.

That’s not a small difference. That’s the whole shift this blog is trying to name — the same instinct I had in 1998, except now it doesn’t need Yol, or Access, or permission from anyone at all. It just needs me, a question, and the willingness to start before I feel ready.

I built AegeanC because nobody else was going to.

I’m still that person. The tools just finally caught up to the instinct.

20th December 2024. That’s the date, if you want it precisely. The redundancy was generous — generous enough that saying yes was the only sensible answer — and I said yes, and then I had to work out who I was without the thing that had defined me for forty‑one and a half years.

Nobody warns you about that part.

They tell you about the holidays. The freedom. The lie‑in on a Tuesday. They tell you about the novelty of not having to be anywhere, the luxury of time suddenly unstructured. They don’t tell you that you might spend decades being the person everyone calls, and then one day the calls simply stop — not because you got worse at the job, but because you left the building.

There’s a silence that follows competence.

A silence that feels like a compliment at first — you’ve earned your rest — until it starts to feel like an erasure.

Who are you when nobody needs you?

Who are you when the room you used to hold together no longer exists?

Retirement is sold as an ending.

Nobody mentions the identity vacuum that comes after.

The reinvention

I did what you do. I bought a house in the country. I pulled my parents’ furniture out of storage and set the place up properly, for a dear friend to rent. There were holidays there — friends, family, the good kind of busy. The kind of busy that feels like a life being lived, not a life being managed.

And then winter came down over Melbourne the way it does: bone‑chillingly cold, and the kind of quiet that makes you reach for something to do with your hands.

I scrapbooked.

Eighteen albums, that first winter. Perseverance was my middle name, and I mean that as a compliment to myself, because eighteen albums is not nothing. It’s a small act of devotion, repeated until it becomes a rhythm. The final album from that winter is still sitting on my dining table right now. It’s not a dead project. I’ll never tire of scrapbooking.

But somewhere in those wintry weeks, something else happened.

Something subtle.

Something I didn’t have language for at the time.

The particular exhaustion of forty‑one and a half years of being indispensable — the kind you don’t notice you’re carrying until it starts to lift — began to lift. And underneath it was a restlessness I hadn’t expected.

A capable person with no problem left to solve is not actually at peace.

She’s just quiet.
Quiet is not the same as fulfilled.
Quiet is not the same as done.
Quiet is just the absence of noise — not the presence of purpose.

The thing nobody tells you about competence

I didn’t want the cold, quiet version of winter to be my only answer for 2026. I didn’t want to become someone who filled her days with tasks that kept her hands busy but her mind under‑used. I didn’t want to be a woman whose best thinking was behind her.

So when AI arrived in my life — properly arrived, not the curious poke I’d given it before — it didn’t find a woman who needed to learn how to think.

It found a woman who’d been doing nothing else but, for four decades, with nowhere to focus it now.

A few very deep conversations about a medical history I needed answered properly.
Research into what makes a forever home actually a forever home.
Then I built a memory tool. A game. A planner that worked the way my brain actually works, instead of the way every productivity app assumes everyone’s brain works. A database for keeping track. A place to store all my stories, to start writing my book.

And somewhere in the building of those things, I came back online.

Ridiculously productive again.

The smartest person in the room — except the room was empty, and that was, for a little while, the funniest and saddest sentence I could have written about myself.

But here’s the thing about empty rooms: they don’t stay empty if you start building things inside them.

People wander in.

Ideas wander in.

Purpose wanders in.

And suddenly you’re not retired.

You’re repurposed.

A different vessel, not a different boat

Retirement is sold to you as the end of useful work.

Here’s what nobody mentions: the skills don’t retire with you.

The problem‑solving, the translating, the relentless instinct to find out and fix and figure it out — all of that was just sitting there, fully intact, waiting for somewhere to go.

Competence doesn’t evaporate.

It waits.

And when AI arrived, it didn’t give me a new identity.

It gave me a new vessel for the identity I already had.

I didn’t miss the boat.

I just hadn’t found the right one yet.

This is the first post in a story I’m going to tell you properly, over the next few weeks — everything I’ve built since that winter lifted, and what it’s actually meant to come back alive.

There’s a fair bit to tell.

Stay with me.