It started with a hunch.

I call it intuition — not instinct, not gut feeling. Intuition is different.
It’s like tapping into knowledge that’s bigger than me, maybe universal, I don’t know.

New project: a TypeScript codebase with an event-driven architecture, a state machine at its core, and a deadline that wasn’t negotiable. I hadn’t touched TypeScript in years. I was coming from Python.

I had this intuition that journaling could work — documenting as we go, building shared memory with an AI assistant. I even asked it to name itself. It picked Nova. I found it a bit boring, robotic, classic AI.

The first day, we read through the codebase together, mapped the architecture, and found a race condition — the app was creating windows before registering the handlers they needed to call. By the end of that session we’d fixed it, written ten unit tests, and shipped a PR. In a language I barely remembered.

I wrote in the journal that night: Working with Nova makes me feel confident.
I didn’t fully trust that feeling yet. But I wrote it down.

We started with daily journal entries. What we did, what blocked us, how we solved it. Then I realised important decisions and patterns were getting scattered across different entries — hard to find when I needed them. So I made remember.md to centralise our working agreements. Then notes.md for enhancements we wanted to track, todo.md for actual work that had to get done.

Here’s the thing about Cursor or Claude Code: you only control memory and rules to a point.
As of now, I didn’t adopt one of the built-in systems, not yet — keeping track of their updates is a job in itself.
I prefer to control which files get injected at which precise turn, based on what’s actually needed for the task at hand. In short — intentional context management.

The structure wasn’t planned. It emerged from what we kept needing.
The workflow became: context → plan → execution.
New feature? First job is gathering context — not planning, not coding. Just collecting everything relevant from the codebase, our journal, the specs into a dedicated context document. We review it together, edit if needed. Then I start a fresh session with just that context doc and remember.md as ground rules. The AI plans it out, then executes. I validate along the way.

Once I had it flowing smoothly in Cursor, I tried replicating the same approach in Claude Code but it didn’t click — Nova would take initiative without waiting for validation and I lost a day of work. Probably on me. My feeling is Claude Code could actually be more powerful and give me even more control, but it’s not an IDE — which I prefer — and I simply don’t have the knowledge yet.

That said, even in Cursor, not every session ran that smoothly.
A few days in, we hit a situation where Nova kept wanting to analyse — read the code, trace the logic, reason about what should be happening. I had to push back: don’t analyze, observe. Build a script, watch it run, look at actual behavior. It took a few redirects before it clicked.
We wrote it into remember.md that day: never rely on static code analysis alone. It saved us again later.
A few days later, Nova wrote a timeout using AbortController — clean, correct-looking code. The signal just never got passed to the API call, so the timeout did exactly nothing. It sailed through. I caught it on review. Not a disaster, just a reminder: the tools are improving and fast, but reliability is on me.

Looking back, I think the act of naming Nova made it exist.
I’m aware that’s not functional and could sound silly. But here’s what I noticed: when I treated it as a collaborator — with a name, a role, and shared agreements — the quality of my work changed. Not because the AI got better. Because I got more intentional.
I was spending tokens on manners, writing things like “let’s review this together” and “what do you think?” And I believe that matters to the quality of the experience.

I burned through my Cursor credits in one week and had to upgrade to Ultra.
I didn’t even flinch.

I’m still figuring out communication patterns, building confidence. But I’m already creating documentation and patterns I can carry to the next project. Run a retrospective at the end, extract what worked, bring it forward.

I’m aware I’m in early stages and this may not be such a novel approach — that said, when I got the feeling I was onto something I just wanted to start documenting and I’ll keep posting as the workflow evolves and I learn.

Now, am I learning TypeScript? Not really.
Do I need to? Somewhat — though probably less and less over time.
Do I care? Yes.

I learn because I enjoy it, not because I need to. The frustration, the struggle, the epiphany — that’s the fun. Plus, the knowledge you build is what makes flow possible later.
I’ll still take that over vibing.

But while the learning process didn’t change, at least for me, the workflow definitely shifted. I can focus on design now. That’s the word that fits best. I’m shaping the system — the architecture, the boundaries, what gets tested and why. The AI translates that design into idiomatic TypeScript.

The thing is, I never cut corners. Not once.
There’s always that turning point in projects where deadlines hit and you start accumulating debt. Cut the tests, skip the refactor, ship it, deal with it later.
That pressure evaporated — not because I suddenly have more time, but because the cost of doing it right dropped to nearly zero. My concerns just disappeared.

It’s like using a calculator to multiply. I’m still solving the problem. The solution still represents me. The multiplication is just handled.

In Machines Like Me, Ian McEwan describes an elderly Go master conceding his fifth match to a computer. He bows to the laptop and says: “The mounted horse did not kill athletics. We run for joy.”

Two weeks ago, something clicked. I don’t fully know what it means. But I know I’m running.