In the early 2010s, Pivotal Labs popularized a practice called pair programming. Two developers would sit together at the same computer, alternating who “drove” the keyboard.

The goal was simple: Fewer errors, higher-quality code, and more shared understanding of the system being built. And, even despite the initial learning curve of co-building, research has shown that it makes projects more robust, enjoyable, and cost-effective.

But pair programming was always engineer-to-engineer. If you couldn’t code, you couldn’t play.

This summer, I found myself experimenting with a cousin of that practice: pair prompting. Instead of two engineers, it’s a developer and a non-developer (with an AI in the loop) co-piloting the build together. One brings technical execution, the other brings creative vision.

I still can’t code. But with pair prompting, I can sit shoulder-to-shoulder with an engineer and build in real time. In this post, I’ll share how I was introduced to pair prompting, and why I believe it’s a preview of how engineers and non-engineers will co-create in an AI-first world.

“Pair programming essentially means that two people write code together on one machine. It is a very collaborative way of working and involves a lot of communication. While a pair of developers work on a task together, they do not only write code, they also plan and discuss their work. They clarify ideas on the way, discuss approaches and come to better solutions.”
- On Pair Programming, Birgitta Böckeler and Nina Siessegger

The way I’d built the initial prototype caught me by surprise. On a Friday night in January, I locked myself into a codebase with Cursor and ChatGPT. I came in with an idea; I left with a talking meerkat.

I realized something important that weekend: No product requirements doc or handoff to another developer could have produced Miko the Meerkat. It felt expressive because I was expressing myself, guiding every step of the build. At first, I felt invincible. But I soon started to hit some formidable foes and bugs.

I started to wonder: Is there a way I can get through bugs without giving up the expressivity of guiding every creative choice myself?

Initially, I sub-contracted out the development work that felt too over my head. While it helped me ship things quickly, it came at the cost of something essential: expressivity.

In June, I hit a wall and felt completely technically blocked. I’d tried pulling in other developers to parachute into the codebase, but nothing worked.

At a coworking event, I vented to a friend, Matt Hamilton, that I wanted to throw my laptop against the wall. Instead of laughing it off, he pulled up a chair. For the next 90 minutes, we combed through the codebase together, poking through the files, folders, and architecture, searching for “clues” about why the app wasn’t working.

I was ready to give up and kept blurting out guesses of my own about why things were broken (which I imagine probably felt like backseat driving a taxi). But that debugging experience felt surprisingly steady and productive. I didn’t feel stupid, just engaged.

For me, that moment was eye-opening. As a non-engineer, I’d never collaborated so directly developer and felt like a peer in the process. (To be fair, I’d also never actually had fun debugging something before.)

A few weeks later, Matt and I decided to push the experiment further. He had an app in the store called Toy Boat; I’d been shaping MuseKat. But to see what a collaborative AI native build felt like, we started Scribblins – a playful, audio-first art experience where kids can turn drawings into AI-enhanced stickers.

We decided to operate like a small dev shop: In sprints, with Trello cards, and features assigned. I scoped prompts and narrative features; he focused on deeper technical integrations. Critically, just like pair programmers at Pivotal Labs, we made most decisions live, side by side, often literally in front of the same codebase.

I vibe-coded the first web version of Scribblins. Matt prompted the AI to refactor it into a mobile app while we went out for lunch. By the time we came back, we had a working prototype. Later, I submitted my first ever pull request (with Claude Code’s help, of course.)

Though inspired by the principles of pair programming, we built on a very different tech stack. AI has been in the loop at every step, from creative ideation and brainstorming to technical architecture, to writing all of the code and test scripts, and the of course, debugging it all. We almost exclusively used AI no-code builder platforms, like Cursor, Claude Code, Replit, and sometimes Codex, which means that over 95% of our code is written by simply talking in English. We opted for AI-native database and hosting platforms (Vercel and Supabase) so that I would feel more comfortable deploying changes and accessing the database on my own. And we regularly bring an AI into our conversations when we’re feeling stuck and need a “third opinion.”

Today, we’re on the cusp of launching Scribblins as a native app. We didn’t move as fast as a solo engineer might have, but faster than a non-AI team could. That wasn’t the point. What mattered is I stayed in the code, so the final product feels truly collaborative.

Just eight weeks of pair prompting has shifted how we each work with AI. I’ve started to think more like a systems designer, while he’s gained a new perspective from how I frame problems.

I believe this is a preview of how work is shifting in the AI age. Pair prompting isn’t just pair programming with AI in the mix. It’s a new mode of work because it gives non-engineers a seat at the keyboard — reshaping the architecture of the internet with more kinds of builders, more textures, more perspectives.

When the language of machines becomes conversational, building turns into a dialogue. And when you add multiple people (not to mention AIs!) into that dialogue in real time, the learning and progress increases exponentionally.

For decades, software belonged to engineers. Everyone else was just a user. But AI cracks that wide open. Now parents and educators, artists and writers can get “closer to the metal” inside a codebase. The real bottleneck isn’t whether you can code, it’s whether you can rewire your brain to talk with machines (and maybe share that sandbox with someone else).

When a technical and non-technical builder sit side by side with an AI in the loop, new things become possible:

• Knowledge gets shared

• Expression doesn’t get lost in translation

• New kinds of builders show up

• Get past roadblocks faster

(Oh, and you definitely have more fun, too.)

Next up, Matt and I will demo “Pair Prompting” live during a live debugging AI Power Hour with vibecoder Suman Nichani on Oct 9 (register here). Scribblins will also be landing in the App Store soon. In the meantime, if you’re experimenting with new ways of co-building in the AI age, I’d love to hear what’s working for you.

In the early 2010s, Pivotal Labs popularized a practice called pair programming. Two developers would sit together at the same computer, alternating who “drove” the keyboard.

The goal was simple: Fewer errors, higher-quality code, and more shared understanding of the system being built. And, even despite the initial learning curve of co-building, research has shown that it makes projects more robust, enjoyable, and cost-effective.

But pair programming was always engineer-to-engineer. If you couldn’t code, you couldn’t play.

This summer, I found myself experimenting with a cousin of that practice: pair prompting. Instead of two engineers, it’s a developer and a non-developer (with an AI in the loop) co-piloting the build together. One brings technical execution, the other brings creative vision.

I still can’t code. But with pair prompting, I can sit shoulder-to-shoulder with an engineer and build in real time. In this post, I’ll share how I was introduced to pair prompting, and why I believe it’s a preview of how engineers and non-engineers will co-create in an AI-first world.

“Pair programming essentially means that two people write code together on one machine. It is a very collaborative way of working and involves a lot of communication. While a pair of developers work on a task together, they do not only write code, they also plan and discuss their work. They clarify ideas on the way, discuss approaches and come to better solutions.”
- On Pair Programming, Birgitta Böckeler and Nina Siessegger

The way I’d built the initial prototype caught me by surprise. On a Friday night in January, I locked myself into a codebase with Cursor and ChatGPT. I came in with an idea; I left with a talking meerkat.

I realized something important that weekend: No product requirements doc or handoff to another developer could have produced Miko the Meerkat. It felt expressive because I was expressing myself, guiding every step of the build. At first, I felt invincible. But I soon started to hit some formidable foes and bugs.

I started to wonder: Is there a way I can get through bugs without giving up the expressivity of guiding every creative choice myself?

Initially, I sub-contracted out the development work that felt too over my head. While it helped me ship things quickly, it came at the cost of something essential: expressivity.

In June, I hit a wall and felt completely technically blocked. I’d tried pulling in other developers to parachute into the codebase, but nothing worked.

At a coworking event, I vented to a friend, Matt Hamilton, that I wanted to throw my laptop against the wall. Instead of laughing it off, he pulled up a chair. For the next 90 minutes, we combed through the codebase together, poking through the files, folders, and architecture, searching for “clues” about why the app wasn’t working.

I was ready to give up and kept blurting out guesses of my own about why things were broken (which I imagine probably felt like backseat driving a taxi). But that debugging experience felt surprisingly steady and productive. I didn’t feel stupid, just engaged.

For me, that moment was eye-opening. As a non-engineer, I’d never collaborated so directly developer and felt like a peer in the process. (To be fair, I’d also never actually had fun debugging something before.)

A few weeks later, Matt and I decided to push the experiment further. He had an app in the store called Toy Boat; I’d been shaping MuseKat. But to see what a collaborative AI native build felt like, we started Scribblins – a playful, audio-first art experience where kids can turn drawings into AI-enhanced stickers.

We decided to operate like a small dev shop: In sprints, with Trello cards, and features assigned. I scoped prompts and narrative features; he focused on deeper technical integrations. Critically, just like pair programmers at Pivotal Labs, we made most decisions live, side by side, often literally in front of the same codebase.

I vibe-coded the first web version of Scribblins. Matt prompted the AI to refactor it into a mobile app while we went out for lunch. By the time we came back, we had a working prototype. Later, I submitted my first ever pull request (with Claude Code’s help, of course.)

Though inspired by the principles of pair programming, we built on a very different tech stack. AI has been in the loop at every step, from creative ideation and brainstorming to technical architecture, to writing all of the code and test scripts, and the of course, debugging it all. We almost exclusively used AI no-code builder platforms, like Cursor, Claude Code, Replit, and sometimes Codex, which means that over 95% of our code is written by simply talking in English. We opted for AI-native database and hosting platforms (Vercel and Supabase) so that I would feel more comfortable deploying changes and accessing the database on my own. And we regularly bring an AI into our conversations when we’re feeling stuck and need a “third opinion.”

Today, we’re on the cusp of launching Scribblins as a native app. We didn’t move as fast as a solo engineer might have, but faster than a non-AI team could. That wasn’t the point. What mattered is I stayed in the code, so the final product feels truly collaborative.

Just eight weeks of pair prompting has shifted how we each work with AI. I’ve started to think more like a systems designer, while he’s gained a new perspective from how I frame problems.

I believe this is a preview of how work is shifting in the AI age. Pair prompting isn’t just pair programming with AI in the mix. It’s a new mode of work because it gives non-engineers a seat at the keyboard — reshaping the architecture of the internet with more kinds of builders, more textures, more perspectives.

When the language of machines becomes conversational, building turns into a dialogue. And when you add multiple people (not to mention AIs!) into that dialogue in real time, the learning and progress increases exponentionally.

For decades, software belonged to engineers. Everyone else was just a user. But AI cracks that wide open. Now parents and educators, artists and writers can get “closer to the metal” inside a codebase. The real bottleneck isn’t whether you can code, it’s whether you can rewire your brain to talk with machines (and maybe share that sandbox with someone else).

When a technical and non-technical builder sit side by side with an AI in the loop, new things become possible:

• Knowledge gets shared

• Expression doesn’t get lost in translation

• New kinds of builders show up

• Get past roadblocks faster

(Oh, and you definitely have more fun, too.)

Next up, Matt and I will demo “Pair Prompting” live during a live debugging AI Power Hour with vibecoder Suman Nichani on Oct 9 (register here). Scribblins will also be landing in the App Store soon. In the meantime, if you’re experimenting with new ways of co-building in the AI age, I’d love to hear what’s working for you.