TLDR: LLMs are genuinely useful as pair programming partners — not to write code for you, but to improve what you’ve written, catch bugs you’ve missed, explain code you’ve inherited, and document what you never got around to. Bigger models handle more context, and string templates keep your prompts clean. The real win is using them to chip away at technical debt.

I just finished Pair Programming with a Large Language Model on DeepLearning.AI. It’s a short course — about an hour — but it reframed how I think about using LLMs in my day-to-day coding workflow.

Here’s what stuck.

Model Size = Context Window

This was a new mental model for me. The course uses an analogy: the larger the animal, the more context it can hold.

A small model is like a goldfish — it can handle a few lines of code. A large model is like an elephant — it can reason over entire files, modules, or even small codebases in a single prompt.

This matters because the effectiveness of pair programming with an LLM is directly tied to how much context you can feed it. If your model can only see a single function, it can’t help you understand how that function fits into the larger architecture. If it can see the whole module, it can reason about dependencies, side effects, and design patterns.

Practical takeaway: Don’t waste a large model on tasks a small model can handle. But when you need holistic reasoning — refactoring, architecture review, debugging across files — reach for the biggest model you can.

String Templates Keep Things Clean

The course emphasises using string templates when constructing prompts programmatically. Instead of concatenating strings with f-strings or .format(), you define a template with clear placeholders and inject your code or context into it.

Why this matters:

  1. Separation of concerns — your prompt logic stays readable and your code input stays isolated.
  2. Reusability — you can swap out the code being analysed without touching the prompt structure.
  3. Debugging — when a prompt isn’t working, you can inspect the template and the injected content separately.

It’s a small discipline, but it compounds. Once you start building a library of prompt templates for common tasks, your workflow speeds up significantly.

The Four Pair Programming Scenarios

The core of the course — and the part I found most immediately useful — is a framework for how to use an LLM as a coding partner. It boils down to four scenarios:

1. Improve Your Code

Not all of us know every language’s idioms and best practices. I write Go, Python, Rust, and TypeScript — and I’m not equally fluent in all of them. An LLM can take working but rough code and suggest idiomatic improvements: better variable names, more efficient data structures, cleaner control flow.

The key insight: you’re not asking the model to write code from scratch. You’re giving it your working code and asking it to make it better. That’s a fundamentally different — and more reliable — use case.

2. Debug Your Code

Instead of staring at a stack trace for twenty minutes, paste your code and the error into the model. Ask it to identify the bug and explain why it’s happening.

This works especially well for the kind of bugs that are obvious in hindsight — off-by-one errors, incorrect type coercions, missing edge cases. The model spots them instantly because it doesn’t have your blind spots.

3. Explain Unfamiliar Code

We’ve all inherited codebases written by someone who left the company three years ago. Or opened a dependency’s source code to understand why it behaves a certain way.

Asking an LLM to walk through unfamiliar code line by line — explaining what each section does, what the author’s intent likely was, and where the gotchas are — is one of the highest-leverage uses I’ve found. It’s like having a patient, knowledgeable colleague who never gets tired of your questions.

4. Document Your Code

Let’s be honest: nobody enjoys writing documentation. But everyone suffers when it’s missing.

LLMs are surprisingly good at generating docstrings, README sections, and inline comments for code you give them. The trick is to review and edit what they produce rather than accepting it blindly — but starting from a draft is infinitely easier than starting from nothing.

Technical Debt Is the Real Opportunity

The final section of the course focuses on using LLMs to tackle technical debt, and I think this is where the real long-term value lies.

Technical debt accumulates silently — unclear variable names, missing tests, outdated patterns, functions that grew too large. No one schedules a sprint to clean up variable names. But an LLM can:

  • Refactor messy functions into smaller, well-named pieces.
  • Add type hints to untyped Python code.
  • Generate unit tests for untested functions.
  • Modernise old patterns to current language idioms.

The compounding effect is significant. Fifteen minutes a day of LLM-assisted cleanup adds up to a noticeably cleaner codebase within weeks.

This post is based on my notes from Pair Programming with a Large Language Model on DeepLearning.AI. If you write code daily and haven’t tried using an LLM as a structured pair programmer, it’s worth the hour.