AI Pair Programming Tools
From autocomplete to a collaborator
AI pair programming tools (GitHub Copilot, Cursor, Windsurf, Amazon Q Developer, Replit's Ghostwriter) evolved from simple next-token autocomplete into something closer to an actual collaborator — one that can read an entire repository's context, propose multi-file edits, run tests, and iterate on failures. The shift happened in roughly three stages: single-line completions (2021), full-function and multi-line suggestions with repo-aware context (2022-2023), and agentic editing where the tool plans a change, edits several files, and verifies its own work (2024 onward).
How repo-aware context actually works
A naive code-completion model only sees the current file up to the cursor. Modern pair-programming tools instead build a retrieval index over the whole repository — embedding functions, classes, and recently-edited files — and inject the most relevant chunks into the prompt alongside the cursor position. This is why Copilot in VS Code 'knows' about a sibling utility function defined in another file: it isn't magic, it's RAG applied to your codebase, with a ranking step that favors recently-opened and recently-edited files since those correlate strongly with what you're currently working on.
The real productivity gain is in boilerplate, not novel logic
Agentic editing: plan, edit, run, fix
Tools like Cursor's Composer and Windsurf's Cascade operate in an agentic loop rather than single-shot completion: given a natural-language instruction, the model proposes a plan, edits multiple files, runs the test suite or linter, reads the output, and iterates if something fails — all without the developer manually copy-pasting between a chat window and the editor. This loop is the same ReAct-style pattern used in general-purpose coding agents, just scoped tightly to a local IDE session with direct filesystem and terminal tool access.
1. Parse instruction: "add input validation to the signup endpoint"
2. Retrieve relevant files (signup route, validation utils, existing tests)
3. Propose a diff across N files
4. Apply diff to a staged working copy
5. Run: npm test -- signup
6. If tests fail: read failure output, revise diff, go to 4
7. If tests pass: present diff for human review/approvalFailure modes worth knowing
The most common failure isn't syntactically broken code — it's confidently wrong code that compiles and passes a shallow glance: hallucinated library APIs that don't exist, subtly wrong edge-case handling, or silently dropping an error-handling branch that existed in the original. Because the suggestion looks plausible and matches surrounding style, these errors slip past review more easily than a human's obviously-wrong first draft would. Teams that adopt these tools well tend to pair them with stronger test coverage and smaller diffs, specifically to catch this class of failure.
Completion-style vs agentic-style tools
| Dimension | Completion-style (classic Copilot) | Agentic (Cursor Composer, Cascade) |
|---|---|---|
| Scope | Single file, near the cursor | Multiple files across the repo |
| Verification | None — developer reviews manually | Runs tests/linters itself, iterates on failure |
| Latency per suggestion | ~100-300ms | Seconds to minutes (multi-step loop) |
| Best for | In-flow small edits, boilerplate | Larger, well-specified multi-file changes |
What's Next?
As these tools get better at planning and self-verification, the bottleneck shifts from writing code to specifying intent clearly and reviewing diffs efficiently — a skill much closer to technical project management than typing speed.
I build these systems professionally.
Whether it's a RAG pipeline, analytics migration, or AI workflow — let's talk.