Experiments with AI as a Pair Programmer
How do you get started with AI? Collaborate with it as a pair programmer. Build the system you want to use. Read: "Everything Starts Out Looking Like a Toy" #259
Hi, I’m Greg 👋! I write weekly product essays, including system “handshakes”, the expectations for workflow, and the jobs to be done for data. What is Data Operations? was the first post in the series.
This week’s toy: revisit MacPaint art from the 1980s - it still looks great. Edition 259 of this newsletter is here - it’s July 14, 2025.
Thanks for reading! Let me know if there’s a topic you’d like me to cover.
The Big Idea
A short long-form essay about data things
⚙️ Experiments with AI as a Pair Programmer
I have many ideas that I want to build. But it’s not always easy to estimate the level of effort to build. I’ve often gotten stuck halfway through an idea and struggled to create it at a level of engineering polish that felt usable.
Pair programming with AI feels like a solid way to approach this problem. Prototyping is easy with AI, and for many personal tasks or small projects I can do it myself. For larger ideas, I can get started without as much help from the engineering side.
Working with AI doesn’t make the work go away, and in some cases creates more loops than it would otherwise. But it does remove blocks. If you have a sense for developing already and keep the AI aligned through context, you can speed up your process dramatically.
Build like a developer
Having a solid structure when working with AI improves the outcomes you get. This won’t be news to you if you’ve ever worked on an engineering project.
To start the project, I write clear stories or tickets, kind of like mini product requirements. You can do this manually or through prompting. I keep everything neat by using a dedicated GitHub branch for each story. (It’s good to have an undo when things go wrong.)
AI agents get lost from task to task without a static memory, so I create a Markdown file to act as the agent context. Think of this as a constantly evolving brief to remind AI when it loses its place due to memory constraints or a new session.
Our context includes the big picture, what features I want, what’s done, and what comes next. The goal is to keep everything as simple and human-readable as possible so AI can get caught up when it loses its place.
Running Development Sessions
The development session when working with an AI looks like this. I use Cursor and GitHub, and this should work for many different kinds of setups.
At the beginning of the process I vibe-code a CLI (command line interface) to do a lot of the tasks in the dev workflow. This also lets me ask the AI to do a deterministic thing and know that it’s going to take action in a repeatable way.
Each dev session, we run a command that completes these tasks:
Open the Markdown context.
Identify the next ticket or story.
Make sure the AI is primed with the right context.
Kick off the session with a single focused task.
This process helps to limit the potential issues inherent in the process, and makes it easier to roll back to the last good commit.
At the end of the session, we wrap things up with another command.
Staying (Mostly) Disciplined
One of the challenges of having an always-on dev partner is the lure of building yet another improvement. I definitely get tempted by new ideas and shiny new features. Scope creep is real.
But so is the ability to “add this story to the backlog” which at least removes the impulse for the moment and helps you to feel you haven’t forgotten the idea.
The biggest shift for me was the mindset change. Creating a reliable rhythm for development makes it much easier to size and solve the work in a methodical order.
Using AI as a Junior Engineer
One trick that helps is thinking of the AI partner as an inexperienced developer. Our goal together is to create and maintain momentum while building at a high quality level.
When there’s a bug, I isolate it in the same way I would when talking to a human developer. Isolate it, simplify the scope, and talk it through:
> “Okay, we’re hitting an edge case. Let’s zoom in on just this one function.”
Or:
> “Let’s ignore the UI for now—can you just write the business logic?”
This helps the AI stay grounded and makes debugging way easier.
Debugging Together
Debugging with the AI is surprisingly effective once I got the hang of it. Run the code, hit an error, and then you share the traceback or logs directly with the AI. Instead of asking, “What’s wrong?” Write, “here’s the error we’re seeing, what’s the most likely cause?”
I test things in small chunks and verify each piece before stacking more logic on top. Sometimes I prompt the AI to write test cases for me so we both stay on the same page.
This feels less like asking Google for an answer and more like pair programming with someone who never gets tired.
Building a Custom Toolkit
There are some artifacts that I build with every project now that are reusable CLI tools and helper scripts:
`gen-ticket`: to scaffold a new story`update-context`: to automatically refresh the Markdown file`start-session`: to open everything I needed with one command
These are the building blocks for a mini operating system for collaboration. They make it much easier for me to ask for an atomic task and confirm that it is completed.
Tradeoffs and Gotchas
This setup isn’t perfect. A few things often go wrong in the iterations I’ve tried so far:
when I forget to update the context, the AI often goes in the wrong direction.
If I dump too much into the context, it gets overwhelmed or distracted.
If my instructions are not clear, I get code that “kind of works” but isn't quite right.
These are human problems (human behind the keyboard, that is), not AI problems. The structure helps me avoid most issues, and the rest I just treat as normal development hiccups.
From Overthinker to Builder
I am really enjoying the increased focus on building. Working with the AI forces me to *do* more than *think*. It rewards small, testable ideas and iterative progress.
This process is helping me practice collaborating with non-AI developers, too. I need to be clear, specific, and outcome-focused - all habits that carry over into my regular work.
Why This Matters
I didn’t build this system to be clever. I built it because I was tired of waiting. I wanted to test ideas, ship faster, and stay in flow.
It’s my experiment (ongoing) of how to improve and collaborate with AI.
What’s the takeaway? If you’re a product person, solo builder, or just someone with ideas and no time to waste - I hope this gives you a jumping-off point. Start small. Stay organized. Talk to your tools. And don’t be afraid to treat the AI like a teammate.
Links for Reading and Sharing
These are links that caught my 👀
1/ Build the context you need - Context Engineering is the skill you need to build to work with AI. This means creating the memory and knowledge AI needs to stay focused on your tasks, and scaffolding the environment so that it doesn’t hallucinate (or when it does, you know).
2/ You still need to think securely - You might get excited about using MCP (Model Context Protocol), and Simon Willison would like to remind you of some of the dangers, particularly when connecting to MCP servers you don’t know well.
3/ When books and nerds collide - You get an algorithm for a better bookshelf.
What to do next
Hit reply if you’ve got links to share, data stories, or want to say hello.
The next big thing always starts out being dismissed as a “toy.” - Chris Dixon