More Than Vibing

I’ve spent most of my career in technology — starting and running business units at Microsoft, leading executive roles at early-stage companies in IoT, VR, and AI. I’ve sat in plenty of product reviews, been a senior product manager, worked with brilliant engineers, and watched software get built — from the outside. But I’ve never been a developer. I don’t write code. And for most of my career, that distinction — business leader versus builder — felt permanent.

About two years ago, I had an idea for an application I wanted to build: a family operating system. Not a photo album, not a group chat, but something genuinely useful for how distributed families could function better and thrive together despite distances — stories, milestones, shared media, games you could play together online, a visual family map, a way to capture and preserve personal history before it’s lost. I called it Kinsaga.

A year ago, I took a first run at it. It was rough going. The tools were capable, the AI assistants were impressive in isolated bursts, but the experience of actually building something coherent — with persistent architecture, real data, a working interface, deployed to the internet — felt just out of reach. So I waited, probably longer than I should have. I used that time to study the competitive landscape carefully, to get very clear on what I wanted to build and why existing products fell short. And I kept watching the AI tooling evolve.

When I finally felt ready to try again, the experience was so different from that first attempt that I’m still a little astonished by it.

The descriptive term that has taken over this kind of AI-assisted building is everywhere — “vibe coding” — a term that implies you describe a feeling, a rough direction, and let the AI improvise the rest. I can absolutely see why a developer would call it that. But that’s not what this was for me. The distinction matters: because the quality of what gets built depends entirely on the quality of the thinking that guides it.

The Workflow

My working environment during this project was three screens running simultaneously. On my browser I had Kinsaga itself — the live prototype, updating in near-real time — along with tabs for GoDaddy, Railway, and Cloudflare. In a second window I had Cursor, the AI-powered coding environment. And in a third, I had Claude.

The technology stack the recommendations converged on: React and TypeScript on the front end, Node.js on the back end, PostgreSQL for the database, Railway for hosting. Once I had that foundation agreed upon, everything else could be built on top of it. I could not have invented those choices myself — but had no problem deciding, based on the answers I was getting back.

Genuinely Stopped in My Tracks

I want to try to describe what it’s like to watch Cursor work, because I don’t think I can convey the experience without acknowledging that it genuinely stopped me in my tracks the first time I saw it.

You give Cursor a prompt. And then it starts talking to itself. It reads existing files in the codebase. It reasons about what needs to change and why. It writes new code, then reviews what it wrote, catches its own mistakes, revises them. It checks whether the application will build. It considers edge cases. It narrates its own thinking as it goes.

Watching this process — an AI agent autonomously navigating a complex software project, making real decisions, self-correcting in real time — I was, and I don’t use this word lightly, gob-smacked. It also gave me a profound new appreciation for what developers have been doing all along. The craft, the patience, the systematic thinking required to build software well — I understood it differently after watching an AI replicate it step by step.

When Cursor finished a step, it would produce a summary of exactly what it had done: which files it had changed, what logic it had added, what edge cases it had handled. I would copy that summary and bring it back to Claude. Claude and I would then test the result together — and this is where the collaboration got genuinely interesting.

Product Thinking at the Center

One thing I want to be clear about: this project was not purely a coding exercise. A substantial portion of the conversation with Claude was about product decisions, user experience, and design.

Should the sidebar navigation be organized by category or flattened into a single list? What should the monthly games leaderboard look like, and how should it handle tie-breaking? When a user uploads a photo, what information should they be prompted to add? These are not technical questions. They are product questions, and Claude engaged with them as a genuine thought partner — offering recommendations when I asked, pushing back when it had a different view, flagging implications I hadn’t considered, but putting me in the driver’s seat.

I found myself in a rhythm that felt natural surprisingly quickly. Describe the intent. Discuss the options. Make a decision. Build it. Test it. Refine it. This is exactly how I’ve always worked with product and engineering teams — except that the team was now an AI, available at any hour, with total recall of everything we’d discussed, and no calendar conflicts.

There were rough edges, of course. Some features took multiple iterations to get right. There were bugs, encoding issues, database migrations that didn’t run on the first try, timezone edge cases in a leaderboard calculation that caused month navigation to display the wrong labels. Each of these required diagnosis, a fix, and a re-test. The process is iterative by nature — but the iterations are fast, and the feedback loop is tight enough that forward momentum rarely stalled for long.

For Me, and Maybe for You

Kinsaga is now a working MVP application, deployed to the internet, with real infrastructure. Here is what got built:

I did not write a single line of code to produce any of it.

What I did was think clearly about what I wanted, communicate it precisely, evaluate what came back, and make good decisions about what to do next. Those are skills I’ve spent a career developing. It turns out they transfer remarkably well to AI-assisted software development.

The implication of this — for any experienced business professional who has had an application idea they assumed required a technical co-founder — is significant. The barrier between “I have an idea” and “I have a working product” has dropped dramatically. It has not disappeared: you still need clarity of thought, patience with iteration, and a genuine willingness to engage with the details. But the requirement that you personally understand how to write TypeScript, configure a PostgreSQL schema, or set up cloud storage? That requirement is gone.

If you’ve spent years developing those skills in business, you may be closer to being a builder than you ever realized.