The Senior Engineer’s Guide to Working With AI Pair Programmers

I’ve been writing software for over twenty years. In that time I’ve pair-programmed with junior developers, offshore contractors, sleep-deprived colleagues at 2am, and now — increasingly — with AI tools like GitHub Copilot, Cursor, and Claude Code. The dynamics are surprisingly similar. And the mistakes engineers make with AI assistants are the same ones they made when they first started managing junior developers.

This is not a guide to prompting tricks. It’s a guide to working with AI the way a senior engineer actually should — with appropriate trust, healthy scepticism, and the discipline to maintain code quality even when the suggestions come fast and feel free.

The mental model that changes everything

Stop thinking of AI coding tools as autocomplete. That framing leads you to accept suggestions passively — the way you accept a tab completion. Instead, treat the AI like a very fast, very confident junior developer who has read an enormous amount of code but has never shipped anything to production and has no memory of your last conversation.

That junior developer is genuinely useful. They can scaffold boilerplate quickly, recall API signatures you’ve forgotten, write a first draft of a test suite, and propose implementations you might not have considered. But they also:

• Don’t know your domain or your constraints
• Have no sense of what “good” looks like in your specific codebase
• Will confidently write code that is subtly wrong
• Won’t tell you when they’re guessing

Once you internalise this, you stop being surprised when the suggestion is off. You review it the way you’d review a PR from someone you trust but haven’t fully verified yet.

When to lean on it, when to push back

AI tools are excellent at high-signal, low-stakes tasks: generating repetitive code, writing docstrings, translating between languages or frameworks, filling in test cases for known behaviour. The quality-to-effort ratio is genuinely good here. Use it freely.

They are unreliable for anything that requires deep context about your system: architectural decisions, cross-cutting concerns, security-sensitive code, performance-critical paths. Not because the model is bad, but because it cannot see what you see. It doesn’t know your deployment model, your SLA, your team’s conventions, or the three incidents you’ve had in the past year that shape how you think about error handling.

A useful heuristic: if you couldn’t explain to a colleague why the suggestion is correct without looking it up, don’t commit it. The speed benefit evaporates the moment you introduce a bug that costs three hours to debug.

Prompting is specification

The quality of the output is directly proportional to the quality of your input. Vague prompts produce vague code. If you ask for “a function that handles the payment flow,” you’ll get something generic that doesn’t fit your system. If you ask for “a function that validates a Stripe webhook payload, checks the event type against a whitelist defined in config, and returns a typed result object — throw on signature failure, return an error variant on unrecognised event type,” you’ll get something far more useful.

This is, of course, just good specification practice. The discipline of writing a clear prompt is the same discipline as writing a clear ticket or a clear interface contract. If you find yourself struggling to prompt the AI effectively, it’s often a sign that you haven’t thought through the problem clearly yourself yet — and that’s valuable information regardless of what the AI produces.

Reviewing AI output is not optional

The most dangerous pattern I see in teams adopting AI tools is the assumption that generated code is reviewed code. It isn’t. Generated code is a first draft. It needs the same scrutiny as any other code you didn’t write yourself — arguably more, because it arrives with none of the context that a human author would have embedded in variable names, commit messages, and PR descriptions.

Specifically, watch for:

• Hallucinated APIs — the model may reference methods or parameters that don’t exist in the version of the library you’re using
• Silent failure modes — error handling that swallows exceptions or returns null where your system expects a typed error
• Ignored conventions — the model doesn’t know your team’s naming conventions, layer boundaries, or module structure unless you tell it
• Security assumptions — input validation, auth checks, and data sanitisation that are present in training data examples but not appropriate for your context
• Test coverage that tests the implementation, not the behaviour — AI-generated tests often assert what the code does rather than what it should do

None of these are reasons to avoid AI tools. They’re reasons to treat the output as a starting point, not a finished product.

Keeping the codebase coherent

The subtlest long-term risk of AI-assisted development is entropy. When multiple engineers use AI tools independently, each accepting suggestions that are locally reasonable but globally inconsistent, the codebase quietly accumulates contradictions: three different patterns for handling the same type of error, four ways of structuring a service class, inconsistent naming that makes search harder and onboarding slower.

The mitigation isn’t to stop using AI tools. It’s to be deliberate about codifying your standards. That means:

• Writing and maintaining architecture decision records so the AI (and your team) has context to work within
• Using linters and formatters that enforce the non-negotiables automatically
• Doing periodic codebase reviews — not just PR reviews — to catch drift before it compounds
• Establishing shared prompting patterns for common tasks, so the team gets consistent output

Teams that do this well use AI to move faster within a defined structure. Teams that don’t end up with velocity that’s real in the short term and expensive in the long term.

The skill that still matters most

Everything above assumes you already have strong engineering judgement. That’s the thing AI cannot replace, and the thing that becomes more valuable as AI tools improve, not less. Knowing when a suggested abstraction is premature. Recognising that the solution to a performance problem isn’t optimising the query but rethinking the data model. Understanding that the right answer to a complex requirement is a simpler system, not a more sophisticated one.

AI tools amplify what you bring to the table. If you bring strong fundamentals and good instincts, you’ll produce better output faster. If you bring gaps in understanding, those gaps will be amplified too — faster, at scale, across the whole codebase.

The senior engineer’s job in the AI era isn’t to compete with the tools. It’s to be the person in the room who knows what good looks like, and who uses every available tool — including AI — to get there.

---

Alfred Eperjesi is a senior software engineer and architect with 20+ years of experience. Cloudomation helps engineering teams adopt AI development tools with the discipline and guardrails to make the results sustainable. Talk to us if your team is navigating this transition.