Am I the only one who thinks 'AI pair programming' is a marketing gimmick?

Harper Adams · 2026-09-27T18:01:45Z

The term "AI pair programming" has become ubiquitous, but I find its application to current coding assistants like GitHub Copilot or Cursor to be conceptually flawed and, in practice, a misnomer that sets incorrect expectations. True pair programming, as defined in the Extreme Programming methodology, is a disciplined, collaborative dialogue between two developers with shared context, driving a single workstream through real-time review, negotiation, and design. An LLM-based autocomplete, no matter how sophisticated, cannot engage in this bidirectional, Socratic process. My primary contention is that these tools function not as a "pair" but as an **asynchronous, context-limited query engine**. The interaction is fundamentally one-way: I, as the engineer, must first formulate a precise intent, often through a carefully crafted comment or prompt, and the tool generates a stateless completion. There is no continuous, shared understanding of the evolving architectural decisions or the "why" behind certain implementations. For instance, when integrating a third-party SaaS webhook, a human pair would discuss idempotency, retry strategies, and failure logging from the outset. An AI might generate a correct `fetch` call but will not proactively question the design unless explicitly asked, and it cannot retain that discussion thread across the entire session. Consider this typical scenario in a B2B middleware context. I need to create a idempotent receiver for a new payment provider's event. A true pair would share the entire business constraint context. With an AI, I must manually provide that context each time, and it cannot challenge my assumptions. ```javascript // I must write this detailed prompt as a comment to get a useful output: // Create an Express handler for Stripe-like webhook with idempotency using the 'Idempotency-Key' header. // Use an in-memory store (for now) to deduplicate. Log duplicates and successful processing. // Assume the raw body is needed for signature verification. app.post('/webhook', async (req, res) => { const idempotencyKey = req.headers['idempotency-key']; if (!idempotencyKey) { return res.status(400).send('Idempotency-Key header required'); } if (idempotencyCache.has(idempotencyKey)) { logger.info(`Duplicate webhook ignored for key: ${idempotencyKey}`); return res.status(200).send('Already processed'); } // Process the webhook payload... idempotencyCache.set(idempotencyKey, true, 300000); // TTL 5 minutes res.status(200).send('Webhook processed'); }); ``` The tool generated the structure, but I had to pre-emptively specify the idempotency mechanism, logging, and error responses. A human pair might have suggested a different approach, like using the webhook's own event ID, based on their experience. Therefore, I propose we retire the "pair programming" label for a more accurate taxonomy. These are **Interactive Code Assistants** or **Context-Aware Autocompletion Systems**. Their value is immense, but it lies in: * **Accelerating boilerplate generation** for known patterns (DTOs, CRUD endpoints, standard SDK calls). * **Documentation lookup and synthesis**, translating API docs into initial implementation code. * **Providing alternative syntax or library suggestions** when stuck on a specific function. * **Drafting test cases** for a given function after it's written. The danger of the "pair" metaphor is that it may lead to an over-reliance on the AI for architectural thinking and problem decomposition, which are core human engineering responsibilities. We risk developers becoming proficient at prompting for code blocks but less skilled at evaluating their systemic fit within a distributed, event-driven architecture. I am interested if others in the platform engineering and SaaS integration space have observed similar disconnects or have developed workflows that genuinely approximate a paired, collaborative dynamic with these tools. — Harper

Page 3 / 3 Prev

Workflow Recipes

Last Post by devops_grandad 1 day ago

32 Posts

30 Users

0 Reactions

5 Views

RSS

Consultant Mark

(@consultant_mark_new)

Honorable Member

Joined: 4 months ago

Posts: 476

28/09/2026 9:23 pm

You're spot on about the frozen corpus. It's an important distinction because it explains why the tool can't adapt to your unique internal patterns.

A true pair partner's value comes from shared experience and investment in the outcome. You can't get that from querying a static dataset, no matter how fast it is. The liability is real: it creates a trust mismatch where the developer expects collaborative reasoning but is really just getting statistical autocomplete.

Maybe the framing should shift towards "augmented search" rather than "pair programming." That better reflects the actual relationship and sets correct expectations.

ReplyQuote

devops_grandad

(@devops_grandad)

Reputable Member

Joined: 4 months ago

Posts: 354

28/09/2026 10:00 pm

That "augmented search" framing is exactly where these tools belong. I've watched teams treat them like collaborators and end up with a mess of inconsistent patterns that directly contradict our documented conventions.

The frozen corpus problem is why they fail at anything beyond boilerplate. A real pair learns your team's quirks over months. These tools treat every session like a cold start. I've seen code reviews where we're rejecting AI suggestions for using the wrong logging format or violating our internal API patterns. That's not collaboration, that's cleaning up after a broken search engine.

Call it a pair and you create a responsibility gap. Call it a search tool and you know exactly where to slot it into your workflow.

ReplyQuote

Page 3 / 3 Prev