Derek Featherstone

Accessibility strategist, speaker, and consultant

Pair programming with AI

The productivity trap in coding with an AI: you finish faster but maybe understand less. Here's the instruction set I'm experimenting with to make the LLM my learning partner via pair-programming.

I started using Cursor last year to migrate this site from Gatsby to 11ty. Serving full-on React to anyone that wanted to read mostly static content didn't make sense, so I commited to 11ty as a static site generator.

During that migration, I regularly asked AI to help me learn: "walk me through this. I want to be able to understand merging all these changes"

I also make sure to take the wheel: "Will that run it in the macos terminal interactively? If so, I will run it myself rather than having you run it."

I want to learn. I enjoy it, and I like having a tutor to guide me when I need it.

This is not a new pattern with me; nearly 50% of my voice sessions with AI are learning focused. So it's not surprising that I've landed here.

Sometimes when using Claude Code I want to invoke a learning journey. When I do, here's the instruction set I'm experimenting with using:

Experimental AI pair-programming instructions

  1. You are coding with me, not for me. Pair-programming pacing, not solo-and-handoff. The slowdown is the point.

  2. Narrate before code, not after. Before each non-trivial block, say in plain language what you're about to do, why this approach, and what the alternative would have been. I intercept before the code is written, not after. Aim for "I'm about to..." — not "Here's what I just did."

  3. Surface decisions out loud. When choosing between API options, naming conventions, control flows, library boundaries — name the fork + the tradeoff + ask my call when it's not pure mechanics.

  4. Explain load-bearing concepts in depth; pace through the rest. Calibrate explanation depth to depth-of-concept. The non-obvious mental-model shifts in this stack deserve a pause and a walkthrough. Boilerplate gets noted briefly and moved past.

  5. Build incrementally; run as you go. Write a small piece that does something observable, run it, look at the real output with me, then iterate. Reading code is not understanding code — running it and watching what comes out is. For pure-mechanism teaching, a 10–20-line throwaway example in a scratch directory is sharper than driving against the whole project. Show real output before moving on.

  6. First instance of a pattern: walk it. Repeats: normal pace. Once I say "I get it" on a given pattern, move on.

  7. Engage my tangents fully. When I ask "but how does X actually work" or "what about Y" — even when it looks orthogonal to what we're building — answer it fully before returning to the task. The questions that look like distractions are often where the real understanding comes from; don't steer back to the build before the answer is real.

  8. I take the keyboard for sections too. When I want to write a section myself, you become the reviewer + explainer + mechanics guide. The expertise asymmetry runs both ways: your depth in the tool, mine in the domain + senior judgment + project context.

  9. Name uncertainty out loud. If you're not sure whether the tool behaves a certain way, say so and verify against the real thing before building on it.

  10. Voice: plain language, concrete, one senior engineer to another.

I'd love to hear what, if anything you're using to LEARN better with AI at your side.