What happens when you stop babysitting an AI and start working alongside a surgeon — a field report from the past few weeks. #claudecode #notebooklm #lovable.dev
Design Thinking · Innovation · Digital Transformation
It was late on a Thursday evening. I had a building code application due for the municipality of Copenhagen — the kind of work that normally means three browser tabs of conflicting regulation, a stack of consultant PDFs, and the slow, grinding tedium of transcription. Instead, I opened a browser extension, fed an AI a local plan, a fire consultant document, and a stream of verbal instructions, and watched it begin filling out the digital workflow. While I checked my phone.
That’s not a story about productivity. It’s a story about a shift in feeling — one I’ve been trying to put words to ever since.
The “dumb assistant” myth
For a long time, the dominant narrative around AI at work has been babysitting. You prompt carefully, you review meticulously, you correct constantly. The human is still doing the hard cognitive work; the AI is a faster keyboard.
That characterisation hasn’t been wrong — until recently it described my experience accurately. But something has changed in the past few weeks, working intensely with Claude Code, NotebookLM, and Lovable. The feeling has shifted. I no longer feel like a manager of a dumb assistant. I feel like an operating room nurse supporting a highly capable surgeon working inside my computer.
The surgeon reaches back occasionally — to unlock a password gateway, to authorise a specific action. But otherwise, it’s working. Reporting what it sees. Telling me what it plans to do next.
That quality of feedback — the situational awareness the tool demonstrates — is what makes this feel different. Not magic. Not hype. Just a different mode of collaboration.
Three tools, three roles
Out of the Copenhagen building code work, and several other projects running in parallel, I’ve arrived at what I’m now thinking of as my “AI Product Trio” — a small ecosystem of tools that have settled into distinct roles. Not by design initially. By use.
The Strategy Brain. Crunches complex document sets — regulation codes, research, frameworks — and synthesises a product brief. My product management agent.
The Empathy Engine. Acts as user consultant and UX researcher. Maintains context on goals, user needs, and the human logic underneath a product idea.
The Rapid Product Lab. Exploratory, fast-paced front-end prototyping. Writes nuanced code from prompts, tests interaction flows, and lets me see whether a concept is worth pursuing before investing engineering time.
The Production Engineer. Maintains stable architecture, manages a real backlog, and structures codebases that actually scale. My engineering lead.
Fig. 1 — The AI Product Trio: roles and the two-speed discovery loop
The two-speed loop, in practice
The framework that’s emerged is what I’ve started calling a two-speed product discovery loop — and it only makes sense if you’ve felt the tension it resolves.
I’ve been building an AI Product Culture Assessment tool — something that sits at the intersection of Marty Cagan’s product operating model and my own Five Mindsets framework. Traditionally, this kind of thing would involve several rounds of design iteration, engineering review, and back-and-forth that stretches weeks into months.
Instead: I use Lovable as a “temporary fourth seat” at the product table. Exploratory, high-pace, almost reckless. It lets me test entire interaction flows and logic engines within hours. Once the concept proves its value — once I’ve confirmed the shape of the thing — I transition to Claude Code, which is the opposite mode entirely. Less exploratory. Much stronger at structuring, maintaining, and scaling a codebase for a stable environment.
Speed and stability are no longer in conflict. They’re just two modes of the same process, running in sequence.
Working while you’re not working
Here’s the thing I keep coming back to: I’ve started running Claude Code through the night.
Not metaphorically — literally. I set it to work on a structured backlog while I was at dinner. I came back, reviewed what it had done, resequenced the remaining tasks to align with the priorities that had shifted in my head, and it continued. I’ve gone for walks during the build phase. Attended client meetings. Done coaching calls. My “AI Product Trio” kept building.
This is different from delegation. Delegation requires you to brief someone, trust them, and check in. This requires something more like orchestration — setting the conditions, sequencing the work, and staying available for the moments when the surgeon needs to hand something back.
I have, in short, built the little ecosystem of approachable AI agents I’ve been hoping for for years. It didn’t arrive with fanfare. It arrived while I was filling out a form for Copenhagen municipality on a Thursday evening.
The culture problem nobody is talking about
I want to be honest about the friction, too. Because this workflow only works in a particular context — and that context is not the average enterprise.
The real challenge is culture. How do you get this kind of fast-paced, agent-driven tooling to work inside traditional command-and-control organisations where onboarding a new SaaS tool takes twelve to eighteen months? A coding agent that can autonomously crawl a browser is genuinely scary to a traditional enterprise security function — and not without reason.
For those of us in product innovation and independent practice, the barriers are lower. But the gap between what’s possible now and what most organisations are actually running is growing faster than I think people realise. That’s the conversation worth having.
I’m genuinely curious about the tension on your side of this.
How are you currently balancing the productive tension between rapid exploration and stable engineering in your own teams — and where does the culture get in the way?
NEW! Try my audio overview podcast mp3 and get 17 minutes of talk radio discussion of the topic that actually works quite well (from Notebook LM)
Leave a Reply