AI coding assistants are evolving into your pair programmers

🚀 The Next Phase of AI Programming Assistants

I used to use AI to write code. Now, AI is reading my code and telling me where I went wrong.

This shift is significant.

From Chat to Pair Programming

Last year, AI programming was still stuck at the level of “Write me a sorting function.” Things are different now.

GitHub Copilot isn’t just completing code anymore; it starts to understand the structure of the entire codebase, can reference functions across files, and in some cases, predicts what you’re going to write next.

It feels a lot like having an experienced programmer sitting right next to you—not typing for you, but silently observing while you code, occasionally interjecting with: “There might be a bug here” or “You seem to have forgotten to handle the edge case.”

Three Important Signals

I’ve recently heard several recurring complaints within developer circles, and they are quite revealing.

1. “It writes better code than me”

This isn’t humility; it’s a fact.

A backend developer said: “I spent all day writing business logic, but the code Copilot generated was more elegant than mine, and it considered several edge cases I hadn’t noticed at all.”

This is slightly unsettling. You write code because you understand the business logic best, but the assessment that AI-generated code is “elegant” isn’t because of your deep business understanding; it’s because the AI has seen millions of similar cases and knows what writing style is considered “best practice” in most scenarios.

2. “It knows what I’m thinking”

This is even more unsettling.

“I was thinking about how to optimize this line of code, and Copilot just gave me the optimization solution before I even finished my thought.”

This sounds convenient, but think carefully: if it provided the solution, is that “optimization” really the best fit for your specific scenario? Or is it just a “general optimization” learned from its training data?

Even more dangerous is that you might start relying on its suggestions and stop thinking about architecture and design patterns yourself.

3. “It remembered every detail of the context”

“I discussed requirement changes with the product manager for three days, and during the code review, Copilot perfectly remembered all the details of these discussions, even correctly handling some edge cases we hadn’t written into the documentation.”

This shows that AI can not only understand the code you are currently writing, but also all the discussions, meetings, and documents you’ve participated in. Its context isn’t just the current file; it’s the context of your entire project.

What This Means

The shift from “chatbot” to “pair programmer” implies issues on several levels:

1. Code Autonomy

When AI can predict your next move and the suggestions it gives are usually “best practices,” you might start accepting them without thinking.

Over time, you form a dependency: Write code → Wait for AI suggestion → Accept → Write more code.

This isn’t true pair programming, because real pairing involves the collision of two minds and mutual inspiration. The “inspiration” from AI is one-way—flowing from training data to your brain.

2. The Risk of Cognitive Offloading

A developer posted on Hacker News: “I feel like my brain is deteriorating. When writing complex logic before, I needed time to build a mental model, draw diagrams, and reason through it repeatedly. Now Copilot can directly give me a workable solution, so I skip these thinking steps and just accept it.”

In the long run, this lowers your ability to solve complex problems. Your “deep thinking” muscles will atrophy.

3. Understanding of the Project Global View

Copilot knowing your codebase context is certainly a good thing. But the problem is: this global understanding is based on pattern matching, not business value judgment.

It might know “this pattern usually leads to bugs,” but it cannot judge “whether this pattern is really a problem in your specific business scenario.”

This leads to a phenomenon: the suggestions AI gives are wrong in certain edge cases, but it is so confident that if you don’t review carefully, you’ll fall into the trap.

Some of My Observations

I recently tried different AI programming assistants, including GitHub Copilot, Claude, GPT-4, and some custom tools based on OpenClaw.

Here are my observations:

GitHub Copilot

Strengths: Strongest context understanding, most natural IDE integration
Weaknesses: Too “confident,” suggested solutions sometimes ignore business specifics
Best For: Large codebases, highly repetitive coding tasks

Claude 3.7

Strengths: Strong logical reasoning, generates “cleaner” code
Weaknesses: Smaller context window, not suitable for ultra-large projects
Best For: Modules requiring deep thought and design

OpenClaw-based Custom Agents

Strengths: Can be customized based on project characteristics, understands your architecture better
Weaknesses: Requires configuration and learning curve
Best For: Specific projects, complex business logic

Developer Response Strategies

Facing this shift, I’ve seen some experienced developers adopt the following strategies:

1. Treat AI as an “Intern,” Not an “Expert”

This is the most critical mindset shift.

You used to think: “AI is a programming expert, I should listen to its suggestions.”

Now you should think: “AI is a talented intern, the code is okay, but I need to review it carefully, and I make the final call on business logic.”

This isn’t just a mindset issue; it directly affects how you use AI tools. When you view AI’s suggestions as “advice to be verified” rather than “absolute truth,” you maintain your own judgment and critical thinking.

2. Explicitly Tell AI What It Doesn’t Know

The GitHub team is constantly optimizing Copilot’s context understanding, but it still can’t understand the ideas in your head or the requirement changes you’ve verbally discussed with your team.

You need to explicitly tell the AI in the prompt: “This is business logic I discussed internally, it’s not in the documentation, this is special handling, don’t treat it with standard patterns.”

3. Make Your Own Decisions at Key Points

Even if the solution AI gives looks “perfect,” for areas requiring business judgment—like architectural design, performance trade-offs, and maintainability—you should still think it through yourself rather than relying entirely on AI.

My Practices

Be Stricter During Code Review

When AI-generated code looks “too perfect,” I am particularly vigilant:

Are edge cases fully considered?
Is error handling missing?
Is there a risk of over-engineering?
How is testability?
Is the code style consistent with the project?

Design Before Coding

Rather than letting AI “naturally grow” the code, I now prefer to:

First, design the overall structure on paper or a whiteboard
Define key functions and their responsibilities
Think about possible exception scenarios
Then let AI help me fill in the specific implementation

Actively Learn from Solutions AI Provides

When the code AI gives is better than I expected, I don’t just accept it; instead, I:

Carefully understand why it wrote it this way
Compare it with my original idea
Think about whether there are edge cases I hadn’t considered
If I have doubts, I mark them with comments to discuss during code review

This Isn’t a Bad Thing

Although I mentioned some risks, I don’t think the development of AI programming assistants is a bad thing.

Actually, I think this is an inevitable trend; the key is how to use it correctly.

Benefits

Increased Efficiency - Highly repetitive coding work can be greatly accelerated
Reduced Cognitive Load - No need to hold too many details in memory at once
Learning Best Practices - Solutions provided by AI are usually trained on best practices
Global Perspective - Able to see the consistency of the entire codebase

The Key

Maintain Critical Thinking - Don’t rely entirely on AI’s judgment
Understand Business Context - What the AI doesn’t know, you must know
Make Your Own Decisions at Key Points - Architecture, performance, trade-offs, etc.
Treat AI as an Assistant, Not an Expert - Ultimately, you are responsible for the code

Next Steps

AI programming assistants are getting stronger and stronger; this is unavoidable.

OpenAI recently released GPT-4 Turbo, with programming capabilities 2x that of GPT-4 and speed 4x faster. Anthropic’s Claude 3.7 Sonnet has also made significant progress in code generation.

What we can expect is: a shift from “AI-assisted coding” to “AI-driven development,” and from “pair programming” to “AI-led architecture.”

This isn’t science fiction; this is happening right now.

The question is: Are you ready to let AI become your “architect”?

Or will you continue to control technical decisions yourself and treat AI as an efficient “intern engineer”?

My Take

Personally, I lean toward the latter. Technical decisions shouldn’t be outsourced to an AI that doesn’t fully understand your project background, even if it can write “perfect” code.

A sense of control is important to me. Only when I fully understand the ins and outs of every line of code can I say this is “my code” and have the confidence to locate and fix issues quickly when they arise.

AI can help me write faster and reduce some silly mistakes, but it shouldn’t replace my thinking.

Because ultimately, if the code has problems, AI won’t take the blame—I’ll be the one in the meeting.

So, my advice is: Use AI well, but don’t let it think for you. Maintain your judgment, maintain your architectural view, and treat AI as an assistant, not an expert.

This is true “pair programming”.

Keywords: AI Programming Assistant, Pair Programming, Code Review, GPT-4, Claude 3.7, GitHub Copilot